What You Must Know About Financial Statements

Your actual accounting financial statements are automatically synchronized; shouldn’t your FP&A forecasted financial statements behave the same way?

‍As late as the early eighties computerized accounting was only viable, due to large expense and complexity, in large organizations. I remember my first controller job at a small manufacturing company where everything was done manually, from typing customer invoices on a typewriter, entering inventory movements (receipts, issues, scrap etc.) on inventory index cards, filed in a metal cabinet, to posting all transactions in a manual general ledger, housed in a post binder that looked like this:

The pages inside this post binder ledger looked similar to this one:

Each page in this post binder represented a GL account and every row represented an entry to that account. It worked like this:Each sub-system like inventory, sales, purchasing and others had its own manual sub-ledger. At the end of the day, the accountant would add up all daily transactions in each sub ledger and create a summary general ledger entry for that sub-ledger (e.g., inventory).Then, every summary journal entry would be posted (i.e., handwritten) in the GL post binder. This meant spreading the entries to all relevant ledger pages. Each GL account affected by these summary transactions would receive an entry on its individual page in a new row, in either the debit or credit column of the page.Some of these accounts were income statement accounts, some were balance sheet accounts. You had to know which accounts to use and precisely make the entries on the right pages in this GL post binder, in either the debit or credit column. If you ran out of page space in a particular account you had to unscrew the posts from the binder and insert additional blank pages, not exactly what I would call fun, but that was the only way to manage the accounting system in those days.At the end of each accounting period the accountant would perform a manual ‘trial balance’, that is, they would list all accounts that had any activity during the period with their period beginning balances in debit and credit columns, then to the right, the period activity (either debit or credit) and then in the rightmost debit and credit columns, the calculated ending period balances.Then both the debit and credit columns would be added up on an adding machine and they had to match. Any discrepancy indicated one or more errors in individual account postings. This is where the real fun began - finding and correcting the errors, all in a manual system with no assistance from automation. I don’t think many accountants today would last long on the job if they had to revert to manual accounting.Finally, after the trial balance (I think that’s why they call it a trial balance - it was all about trial and error, or ‘trying’ to ‘balance’, referring to the original Latin term “bilancio del libro”) was run again and no errors were found, financial statements were compiled from the period-end GL account balances. The income statement and balance sheet templates had a list of GL accounts to be included and hopefully, no errors were made during this process.The end result was a balance sheet and income statement which were released to management and to external parties when needed. The two statements were synchronized to one another which meant that all changes to income statement accounts affecting balance sheet accounts were reflected in the balance sheet. It was the accuracy of all manual transaction postings in the GL that implied this synchronization.Consider the following examples:

• Changes to ‘Retained earnings – Current’ on the balance sheet originate from the income statement summary (i.e., current period net profit or loss).

• Changes to the Accounts Receivable balance during the period result from sales shown on the income statement.

• The increase to accumulated depreciation of an asset on the balance sheet is a result of the asset period depreciation appearing on the income statement.

There are numerous transactions appearing on the income statement that affect the balance sheet presentation and using manual journal entry principles ensured that the two statements were tightly synchronized.The process would then repeat for every accounting period and the financial statements would continue to remain synchronized to one another as long as there were no errors. Note that in those days the Statement of Cash Flows was not required by the SEC and smaller companies did not produce it either.This sounds like a lot of work, and it really was, but this is how your typical SMB (Small and Medium Sized Business) accounting was done prior to the introduction of personal computers in business.When the IBM PC came on the scene in August of 1981 everything changed. It was the first time that small businesses were able to acquire such technology and with the aid of a rapidly increasing number of software applications they were finally able to transition to computerized accounting, evolving through the decades to what we call today accounting and ERP software.What computerized accounting, from the very beginning until present time, has in common with classical, manual accounting, is that financial statements produced in the system (either manual or computerized) are synchronized with one another. All transactions, when posted to the general ledger, affect both the income statement and the balance sheet according to accounting rules built into the system, following GAAP.In the case of manual accounting, these rules were primarily kept in desktop procedures and also in accountants’ heads, which is not the best internal control, and usually very error prone. In the case of computerized accounting, automated transactions in a database environment and built-in accounting rules provides greater accuracy, and a lot less tedious and extremely time-consuming work.In the next installment we will see how synchronized financial statements, always present in computerized accounting and ERP software are also becoming a core feature of FP&A software solutions.Alan Hart, MBA, is Principal Consultant at Pacific Shine Group in Portland, Oregon, with responsibility for client business development and hands-on client project implementations. Prior to starting Pacific Shine Group, he worked in various executive accounting and finance positions with technology and growth companies. Notable is his 18 years in the hi-tech manufacturing industry where he served as Controller, Vice President of Finance and CFO of several privately as well as publicly held companies in the Hi-Tech industry, such as Hybrid Arts, Inc., Hamilton Bay Associates and Syncronys Software.  In his role in management consulting, Alan has worked in diverse industries and with a variety of clients, including fortune 1000 companies such as Boeing, Delta Airlines, Intel, Wyndham Worldwide and others, as well as many mid-market organizations such as Guitar Center, Ducommun AeroStructures, Cypress Semiconductor, TriQuint Semiconductor and others.Combining his skills and experience in engineering with deep understanding of technical accounting, he is able to assist small and medium-size manufacturing companies establish GAAP compliant accounting and reporting systems.