Line Item or Line Item Subset or Line Item Subset mapping to Accounts

J_wheeler

Hi, Anaplan friends,

 

In the attached file, there are three options for simple P&L by Stores. May I know what factors need to be considered in choosing one out of these three options ? What determines which option you should choose ? What motivates you to apply option 3 where you need to take three steps to derive ??

Your cooperation would be much appreciated.

Thanks !

 

John

line_item_subset_24653.xlsx

PaulRitner

Hi John,

 

Here's how I think about the three options you listed, particulary with respect to the primary P&L, BS, or Cash Flows resident in most or all FP&A models:

1.  P&L Rows as Line Items:  this is my preferred method for most clients because it looks nicer and we can embed formulas in the Parent Line Items that aren't simple addition (which isn't the case for Line Item Subsets and Lists/Hierarchies) (a good example is Net Income).  The only challenge here is if the line items are very detailed and change often... because the client would then possibly have to open the hood on the module too often (I still prefer this approach anyway, but it depends on the gifts & talents of the client's Anaplan Admins...)

 

2.  P&L Rows as a Line Item Subset:  This implies we're doing #1 above, and is commonly used for either ancilary or directly related activities of the primary report.  Some examples where we commonly use line item subsets include: CM/YTD reporting, mappings, data staging, some data inputs, and snapshots.  Line Item subsets can vastly reduce otherwise redundant maintenance, as well as simplify formulas (e.g. Collect()), but there are formatting limitations that some clients are luke warm on, and some reports don't work quite as well when based on a LIS... depends on aggregation/formula complexity in the source module.

 

3.  P&L Rows as a List (i.e. the P&L section of the Accounts Hierarchy):  I really really dislike using lists for the P&L rows in Anaplan, because, as stated above, Anaplan parent list items can only aggregate using addition.  For a P&L, this means that the Net Income line, for example, can't be calculated correctly unless we flip the signs on either Revenue or Expense (i.e. show one of them as a negative number)... which diminishes user experience (for me, its a non-starter).  In addition, when using a list/hierarchy for the P&L, in partiucular, it becomes very difficult to include KPI's in the report (which isn't an issue when using Line Items).  There are other drawbacks, but the last one I'll bore you with is this:  When using the Accounts Hierarchy as the P&L rows, the formula for linking in all the data can be very long depending on how many modules/line items you need to aggregate into the (often single) P&L line item.. this can create troubleshooting challenges.  Notwithstanding this diatribe, certain analytics & inputs are often facilitated by having the Accounts hierarchy resident in the module.  For example, if the need is to present for review & edit, say, Expense by Department & Account, then using a hierarchy to input & summarize is not only easy, but low maintenance & usually easy to map into summary reports.

 

Cheers!