On April 15th 2004, I flew to Buffalo, New York for the first time. I started on a project Rick had been working on for nine months, to build the next generation of the financial system for a very large, worldwide bank. I started by reviewing an existing reporting application, perhaps somewhat a test to see if I really knew anything, and was then assigned to install SAFR. The start of many large projects begins with attempting to gain traction. I think back to those days, as described by one man, with “…nostalgia for past days of obscurity.” Those were days of obscurity, when few had any idea what we were really attempting to do, and the work effort that would be involved.
Let’s start our analysis of the platform by examining the general ledger, and reviewing the basics of the posting process.
Figure 144. Financial Management Solution (FMS) Platform
- Business Unit
- Ledger
- Account
- Cost Center
- Product
- Customer Type
- Affiliate
- Source
- Book Code
- Currency
- Date
- Period
- Amount
In addition to these fields, journal entries – effectively the transactions – typically also have a date and time stamp, a journal entry number/unique identifier, preparer and approver user IDs, and perhaps a description, particularly for manual journal entries.
Let’s take a moment and properly orient ourselves with an example, one that includes scale.
Financial Services
Suppose we run a Financial Services company. Financial services includes banks, insurance, and financial markets. These types of institutions were at the forefront of developing modern accounting practices because the basic nature of their business is in many respects a general ledger. A portion of the money I deposit into an account (likely a name derived from its corresponding tracking device in the general ledger) is loaned to someone else, as represented in another account. The difference between the two accounts is the bank’s capital.
One shift we will have to make is that from the banks’ perspective, deposits aren’t assets; loans are. Deposits mean the bank has to pay you, the account holder, when you ask for it, similar to accounts payable. Loans means the bank can ask you to pay when they want, an account receivable. As we consider our example at scale, we’ll need to hold this in mind.
The reason a financial services company’s financial systems deal with scale is because, now instead of keeping track of one person’s financial statement, the company must keep track of thousands, hundreds of thousands, even millions of financial statements, or better said, financial position. Is that true you might ask? Consider the following.
Today’s banking financial systems do not keep track of each individual’s financial statement or position in total. Each portion of your personal financial position is broken up and held in different systems; or subsystems. The amount of your deposit on hand is held in one system; the Demand Deposit Account system (in the US). The amount of your home loan is held in the mortgage system.
Consistent with the subsystem architecture, in most cases your deposit account gets accumulated with lots of other deposit accounts, and one journal entry is sent to the general ledger system with all the activity – desposits or withdrawals – for today. The same happens with your mortgage. Your payment is accumulated with thousands or millions of others and sent to the general ledger system.
Thus the traditional financial system sits atop all these other subsystems and keeps track of the summary results. But as we have noted, the weakness of the subsystem architecture becomes clear as more and more attributes are needed for reporting. This need creates a proliferation of summary structures – effectively additional ledgers – to provide the answers. The accumulated affect becomes inflexible and unsupportable. An alternative approach is required. This is where the Arrangement Ledger comes in.
Parent Topic: Part 6. The Platform