Best practice - Accounts

1)  Has anyone seen Accounts (e.g. P&L accounts) being defined as List instead of Line Items?

2)  When these accounts are defined as List, how do you define the formula for accounts that require calculation, e.g. Profit?

3)  Is a Dummy Line Item required?  Can we do without Line Item?

 

Star_0-1585256106533.png

 

 

Tagged:

Answers

  • @Star 

    For me it's the opposite. I rarely see accounts as line items.

    Rather, the accounts are aggregated or filtered to create the line items you're referring to like revenue, COGS, and Margin.

    In that case, you don't need an extra line item, although if you have different modules calculating the same KPI's like COGS, then you may want to consider using a line item subset.

    Lot's of ways you can go with that.

    I suppose it depends more on your use case.

     

  • Hi,

     

    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.

    https://community.anaplan.com/t5/Best-Practices/Line-Item-Subsets-Demystified/ta-p/54309

     

  • Hi, @Star 

     

    https://community.anaplan.com/t5/Best-Practices/Changing-the-Sign-for-Aggregation/ta-p/53812

     

    This article may relate to your topic. This is a great trick.

     

    I hope this helps you.

     

    Taichi

  • @nathan_rudman 

     

    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.

     

  • @JaredDolich Find my response to Nathan's Reply. Would love to hear your thoughts as well on limitations of Line Item Subsets.

  • @Misbah 

    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!)

  • "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."

     

    this is not possible with lists either.

  • @JaredDolich 

     

    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