I guess I'd need to understand the use-case a little more. I'm sure your solution is the best one. It's just that every FP&A model that I've built used the traditional structured hierarchy and subsequent LIS if necessary. But as we all know, not every use-case is the same.
I might be wrong but it sounds to me like this would make for a really good best-practice article! (would love to learn more about this approach!)
We initially followed the LIS approach but there were some challenges as I highlighted earlier. Biggest challenge was to retain the formatting of output module as per which used LIS. I know we can retain the formatting sometimes but that sometime was not our time.
Hence we had to create Line items even for the final output module and let go advantages of LIS. It was lengthy and laborious but it worked out in our case
P.S: Ours was Ragged hierarchy and not a structured/balanced one
it is possible to do like that. But you'll have to proceed in a specific way, subsetizing your list and pulling the data from the calculation modules. For example you'll have a payroll module and another for travel & expenses where you make the actual calculations.
Then, in your P&L module, you can create 2 line items: Payroll, T&E, dimensioned by subsets of your accounts list. Now in these two line items you can pull from line items of the payroll and T&E module, SUMMING [SUM:] on the account that want for each LI.
Finally create a third line item in your P&L module called total with the whole list and just add every other line items.
Take a look at the app "Planning Budgeting and Forecasting for SaaS", it is built this way (the P&L module is P&L Data).
However, the reason why line items are often used is that you can easily transform them into a list with line item subset. If you don't know about it, read the article below before choosing the path above. LIS are usually a good way to design a P&L.
LIS are indeed very powerful but here are some findings from my experience.
We found ourselves in a situation where Client wanted to see Alignment of P&L to be Line item based and not list based. We had already gone ahead with Line item subset way but that gave a feel of list based P&L - meaning there was more indentation of few Key nodes which threw our Client off.
Another challenge was that there was one key metric part of P&L (rate/case) where we had to change the summary - which was not possible with LIS.
So had to create line items manually for each Key Account Node.