Transforming existing financial services financial reporting applications is very challenging, particularly at scale.  The stakes are high.  The data in them has been gathered at great cost, the systems developed and tuned typically over years, they have been certified by auditors, and a wrong turn in them can threaten the market value and even the existence of the organization.

In a series of three videos, I try to make clear key things about these systems which I wish I had known before undertaking some of these projects.

The first video deals with the systems that feed the finance system, often called source systems.  The nature of large organizations is such that not all the functions needed by the organization can be performed in one system.  So over time we have built many systems, each a bit specialized, but the data from them is required in the core finance system.  This is because the core finance system has to give an enterprise perspective.

The income statement and balance sheet for an organization is to include ever material financial transaction for the organization over the period covered or as of the balance sheet date.

A Tranching Plan

“Tranche” means “a division or portion of a pool or whole.”  Dividing up and understanding the source systems which must feed the new finance system is a significant effort.  Doing so will provide a significant sense of what the overall project will look like.

Tranche Plan Dimensions

Dimensions of Source Systems

List of Source Systems

I suggest analysis of source systems begins by understanding what systems feed the existing financial system.  As noted, all material transactions should.  Some of these might reach the General Ledger via adjustments or manually entered values.  But most organizations know that is inefficient, and so in most cases, for significant systems, the feeds have been automated.

Start with just a list of all the source systems.  You can likely find a starting point for this list in the ledger itself.  It will likely have a code of some kind describing the source system, and all the data fed to the system from that source will use that code.

Percentage of Balance Sheet

Next rank the systems by a few differing dimensions.  The easier perhaps is percentage of balance sheet.  A petty system which at any point in time contains $100 is certainly lower priority than the commercial loan system.  This ranking is fairly easy to do.

The value of this ranking is knowing that converting systems representing a large portion of the balance sheet have much higher value than those with low balances.

Some complications can come from systems which might at any point in time have a low balance, but which process high volumes of transactions or values.  These attributes of the system start to develop the second dimension of the problem.

Value of Complexity

Ranking for this dimension is a little less straight-forward.  It deals with the value of the data in the system, and the use of that data for financial reporting processes.

A simple example is the difference between retail deposit systems, and commercial loan systems.  Retail deposit systems typically do not require a lot of financial analysis at the enterprise level.  The behaviors of the deposits tend to be fairly predictable, and the risk associated with them is typically low.

Commercial loan systems typically undergo much more scrutiny; the risk is so much higher.  Are these loans worth what they are booked at?  What are the possible groupings of risks around them?  What are the maturity dates for them?  And on and on it goes.

Another aspect of this ranking though can also be data and transaction volumes, in a negative way.  The retail deposit systems may present very high transaction volumes, which means the conversion to the new system may challenge the new ledger.  Thus this system may rank lower on the value of complexity for that reason as well as the uses of the data.

So the value of the commercial loan system is much higher than the retail deposit systems.

Required Perspectives

The last dimension is the perspectives required from that source system.  Modern Enterprise Financial System (at times called the General Ledger, as one piece of the enterprise needs) can present multiple perspectives.  For example, often the enterprise perspective is some generally accepted accounting perspective view, or GAAP.  This might be International Financial Reporting Standards, (IFRS) or US GAAP, or some other GAAP.

But the system may also need to produce a local GAAP.  Time periods required are an aspect of this.  Does it need to present daily views, or or monthly adequate?

If one is ambitious to attempt to present multiple consistent views in one system–in other words, if the enterprise is attempting a consolidated data supply chain–then the other perspectives to be produced from that source data should also be reflected.

These might include credit risk, management reporting, product control, regulatory reporting, and others.

Using this list, the project can make choices about what perspectives to focus on for a particular source.

The Need for Speed

This map becomes most useful when the project can find ways of parallelizing activities around these sources.  If accounting rules from each of these source systems can be located in parallel, the data needed to feed the new ledger extracts and balanced, processes created to extract and reconcile it consistently, and controls and timing understood, then the project will shorten the total time required to accomplish building and populating the new system.

This is episode 253 of Conversations with Kip, the best financial system vlog there is. Literally learn more–about ledgers and financial systems–at http://www.LedgerLearning.com

You can watch all past episodes in order at:

Next video in series