I'm looking to implement a global cloud-based ERP system (NetSuite, Oracle Fusion Cloud, etc.). For the "natural account" segment, I'm torn between the two classic approaches: - "thick" or "fat" natural account ... all account-based disclosures (e.g. PP&E roll-forwards) can be done based on ledger accounts - "thin" natural account ... segment only has balances required for the face of the financial statements, all other information resides in subledgers Can someone point me in the direction of resources that can help me think through this tradeoff?
Thick vs thin natural account dimension ... resources to help me think through tradeoffs?
Answers
Great question Michael and I'll be interested to see how people answer this question as well. I don't know of any particular resources, but can wax philosophic here. As you allude, in the old days, account structures required very long strings of account values, with multiple segments- I recall deciding between 8 or 9 'segments' in my COA
Now, dimensions rule the game - you still 'tag' the transaction with the transactional information you wish to capture but it's not held in the GL string. For example, the account number still exists of course, but dimensions such as location, department, customer, vendor, employee, item, project, class, etc.are tagged to the transactions for easy report writing later - you can use prebuilt reports or build your own reports in these cloud based ERP systems such as the ones you mention.
Besides GL accounts, the vendors will also offer statistical accounts as well for tracking non financial data, e.g., headcount.
I believe all the vendors will encourage a thin natural account set up. Good luck with your implementation.
The rest of my flexfield is much further along, so fortunately this is primarily a natural account field issue I'm having.
From my perspective, the question of thin vs. thick natural account is a question about when you want
A thin setup makes your journal entry templates smaller and less varied (i.e. any "PP&E" related transaction can just book to the one "PP&E" account) but makes your financial reporting process more Excel dependent (e.g. download your PP&E account transactions into spreadsheet, tag them as one movement type or another, then compile footnotes).
A thick setup requires larger or more varied journal entry templates (because each transaction might hit a different sub-account) but much easier reporting (because the relevant footnote information is available right from the trial balance).
ERP vendors can mitigate each of these risks:
1) If you can export transaction types from subledgers, that eases the reporting pain of a thin-ledger setup.
2) If you can point subledger transaction types to multiple accounts, that reduces the need for many manual journal entry templates in a thick-ledger setup.
Thoughts?
Filed Under:
Accounting