Chapter 58. The Arrangement Ledger

Arrangement Defined

What is an arrangement ID? This could be a very lengthy discussion in some circles, but for our purposes, let’s describe it as a specific customer contract. For example, if my company takes out a loan from the bank, that creates an arrangement. The arrangement ID might be simply composed of an ID from the source system that holds my loan details¹, and the loan number.²

By adding an arrangement ID onto the journals and the ledger, the balances accumulated now represent the balances for my loan. Within this same ledger, balances for any other loan are simply another set of rows.

Millions of “Ledgers”

The addition of this key has transformed the system from something containing a set of rows describing point in time balances for the entire company, or perhaps more accurately sets of rows describing each of the legal entities or companies, into a set of rows which describe an individual customer contract.

Let’s be clear; there is not just one row for each customer contract. There are multiple rows for each customer contract because each customer contract is composed of multiple balances. There is a row that represents the principle of the loan, another for the interest payable, another for the fee revenue, another for accrued taxes. Typically, the General Ledger account, in combination with the arrangement ID would make each row of the Arrangement Ledger unique.³

Thus the Arrangement Ledger would contain millions even tens or hundreds of millions of tiny little ledgers, each reflecting the position of an individual customer contract as of a point in time.

Transactions Versus Balances

But wait, you say; this sounds like a summary structure of some kind. And you would be right. Producing all the financial information from the transactions is unrealistic for a large bank. Insurance companies, even the largest, may be able to do so. This is because the business events with customers occur on average a few times a year. But banking transactions often occur multiple times each day, even each hour. In these instances, the volume is simply too high. Also, unlike insurance which requires tracking trends over longer periods of time, the value of the historical transaction data to banking is lower and diminishes very quickly.

Yet by creating an Arrangement Ledger, summarizing as an accommodation of the machine capacities, provides most of the benefits of the transaction data. Using the concepts explained in Movements is critical to managing the size of the Arrangement Ledger data store. Maintaining arrangement details with a pure balance based approach for a large organization is likely impossible, and likely too expensive for any but the smallest organizations.

Additional Attributes

Remember that by summarizing by a selected set of attributes – like the accounting code block in the general ledger above – we eliminate other views of the data. Thus creating these tiny ledgers is not very transformative in itself. The additional attributes that describe the customer and the contract are the items of interest for so many other types of financial reporting.

If, in addition to the accounting code block we use in the general ledger, we attempt to summarize by all the other attributes, we (1) begin to store the same values on multiple records, because the contract and customer attributes describe the entire arrangement, not the individual balances, (2) we create a “reclassification” nightmare as the attributes change, needing to move balances between these attributes, (3) we destroy the ability to show the values historically.

Our choice of the customer contract level – the arrangement level – is not by mistake. Rather, by summarizing to his level, we have preserved the ability to capture and report all these metrics, every summarized balance, by any attribute which describes the customer or contract.

For example, if the following were the balances for a simple General Ledger:

Figure 145. General Ledger Summary Record

At the General Ledger level, data is at a summarized level; the arrangement ID is not meaningful. This shows us that for account 60010, cost center 887, and the rest of the values, the balances as of this 9/10/2009 is 984,309.82.

The arrangement balances that make up this single summary balance might be the following. Note that there are three different arrangements, each with the same set of attributes that make up this one balance.

Figure 146. Arrangement Ledger Detail Balances

By just adding an Arrangement ID to the record, additional attributes can be stored in the arrangement ledger, without causing the balance to be shifted each time one of these other attributes changes. Because Arrangement ID must be unique, they can be used to link to additional information as is shown below on the Standard Arrangement Layout, or SAL records.

Figure 147. Sample Standard Arrangement Layout (SAL) records

In this case, each arrangement has four additional attributes associated with it. The SAL can contain as many attributes as necessary to produce needed reports. Anything that describes either the customer or the contract can be stored on these records. As long as the attributes can be linked to the arrangement ID, such as customer information, they can be used in reports at a summary or detailed level. As these attributes change, new SAL records are created with effective dates on each. Thus at report time it can be decided which version of SALs should be used for the report.

Then it would be possible to combine the amounts in the arrangement ledger, and the SAL, and produce a view of the arrangement balances such as this:

Figure 148. Summaries by SAL attributes

The three arrangement records were summarized based on the values of the four attributes in the SAL giving a total of eight different summaries. We have just simply “pivoted” the core financial data by any of the SAL attributes. Because these reports are produced from the same base set of data, they can always be reconciled and are consistent. We have just added an incredible level of flexibility to the core financial system.

By organizing our arrangement ledger in this manner, we have created a single system capable of producing thousands of summaries from the same consistent, controlled set of numbers that feeds today’s highly respected financial systems.