— September 28, 2017
Your ERP software doesn’t ask you to do that—why should your financial planning and budgeting solution be different?
Every accountant I’ve met has admitted to me that he or she had difficulties with manual, double-entry accounting principles when they first started out: they struggled with what GL accounts to use for a particular transaction, and more importantly, the transaction’s correct orientation, i.e., assigning amounts as either debits or credits in journal entries.
If you’re like me, you’ve had your share of journal entries that posted in the opposite direction of what you expected, requiring a reversal of the original entry and redoing it the right way. That is if you caught these errors. I’ll never know how many manual journal entries with these issues have gone undetected or hopefully were caught later in a review or audit.
To make my life easier when making journal entries, I came up with a ‘Universal Cheat Sheet’ many years ago to assist me with assigning the proper orientation to manual journal entries. It covered all possible journal entries in all areas and provided the correct debit/credit journal orientation. I just found an old graphic representation of it, and it looks like this:
I remember using this cheat sheet when making manual entries and not having to rely on memory. With experience, I was able to abandon this tool, learning to assign proper credits and debits to all entries on my own.
Now all modern accounting and ERP systems with an integrated GL are internally set up to cause all possible system transactions (e.g., sales, purchases, payments to employees, sales of assets, etc.) to automatically post to the correct GL accounts using the correct debit/credit orientation. The accounting department still performs a handful of manual journal entries, but the quantity pales in comparison with the vast number of automated journal entries originating from all enterprise activities.
With today’s computerized accounting systems, automatic postings of all enterprise transactions to a consolidated GL with accuracy, consistency and precise adherence to GAAP rules is expected, regardless of company size and the solution employed. It follows that finance’s planning and budgeting software solutions, entrusted to produce forecasted financial statements and other forecasted reports, should follow the same principles.
However, at the time of this writing, most planning and budgeting applications still expect their users to build their model using formulas, functions and links (just like in spreadsheet modeling) and there are no internal accounting rules forcing budget data to affect forecasted financial statements the way their accounting system counterparts do.
But I see a new trend emerging, one where enterprise planning and budgeting software solutions employ accounting rules, some of which are shown on the cheat sheet displayed above. These rules are built right into the software, causing all budget activities to post to the software’s internal budget GL in every relevant budget period, in the correct amounts, and of course, in the proper debit/credit orientation.
In this software architecture, a full set of forecasted (future period) financial statements can be produced accurately and completely, just like the actual accounting financial statements, using the same format and familiar look.