Right number. Your team is still searching.

Why the path from a correct number to its underlying transactions is so long, and what work an additional data layer replaces.

A Finance Data Store is, first of all, one more layer: a separate data layer between source systems and Finance reports. It costs money, and it adds time to the daily close. Yet I am building one right now. A morning three hours before a board meeting shows why.

Shortly after eleven, Reto, the CFO, appears in the doorway of Karin, the head of Finance Architecture. At 2 pm, the board wants to know what drove the increase in a product's earnings in the third quarter. “Accounting and Management Accounting show the same number,” Reto says. “Before I explain why it increased, I need to know which transactions account for it.”

Two Excel files are open on Karin's screen, one from Accounting and one from Management Accounting. She requested both yesterday evening, sending both teams exactly the same request: trace the increase in earnings down to the individual transaction. Two thirds of the rows in Management Accounting's file are filled in; in Accounting's file, about half.

Karin thinks: The number is correct. Then, more quietly: Why does it take so long to show that? Marco, who leads Management Accounting, has spent the night searching with his team. A second team in Accounting worked on the same question. Marco's people have given up a night for a number that was already correct.

Why is the path from a correct number to its underlying transactions so long? I will come back to that. First, the objection that rightly comes up at this point.

Why add a layer when the general ledger is enough?

Anyone proposing a Finance Data Store hears the objection immediately, and it is a strong one. An additional layer is a copy. Someone has to operate it, pay for it and reconcile it too. It extends the daily close because it loads before anyone reads from it. And shared foundations already exist. SAP brings Financial and Management Accounting together on the same posting basis in the Universal Journal and calls it “one source of the truth”. If you want to move faster, the argument goes, remove layers instead of adding one.

I agree with half of that objection. The layer has a cost, and anyone who conceals it loses the CFO by the second paragraph. One transaction on Karin's screen shows whether the other half holds up.

Where the connection to the transaction is lost

At 1:10 pm, Karin takes the largest transaction from the list and traces it back through both files. In Management Accounting, it has a product key and a customer number. In Accounting, it has a document number from the general ledger. The reference to the original transaction in the core banking system is missing from both files. Both teams have manually reconstructed the same connection overnight, using amount, date and customer. It was the same work twice, at two desks, for the same number.

Karin sees the reason in the structure. A transaction reaches reports through several routes. After end-of-day processing, it lands in the journal and, alongside it, in a subledger. Extracts then pull it into Management Accounting, Legal Reporting and Risk. Each route takes what it needs for its calculation. Not every route carries the reference to the transaction.

For the 2 pm meeting, Karin proposes an immediate measure: “Show the largest transactions both files can already substantiate. And be open about what is still missing and why.” Reto shows the board those transactions and names the gap. He explains why the increase occurred at the next meeting.

The number was correct. What was missing was the link to the transaction, and two teams rebuilt it overnight.

The overnight work the store replaces

Here lies the answer to the objection, and it comes with a condition. A store does not help because it is another copy. It helps if it establishes the connection between transaction, posting and report once and preserves it. Business Events, the business occurrences behind a posting, Journal and Subledger remain distinct origins. The store takes them in with their references and records which posting belongs to which transaction. Accounting, Legal Reporting and Management Accounting then read from the same raw data and the same mapping.

The work it replaces is reconstructing the same connection at several desks and continually checking whether the extracts agree. What it newly requires belongs in the same calculation: loading time during the daily close, operations and a person who takes responsibility for the mapping.

For banks, there is a regulatory framework for this. BCBS 239 sets out the Basel Committee on Banking Supervision's principles on risk data. Since 2013, Principle 3 has required: “Risk data should be reconciled with bank’s sources, including accounting data where appropriate, to ensure that the risk data is accurate.” The principle does not prescribe an architecture. My conclusion from it: reconciliation with the source is easier when the connection to the source is preserved along the way.

If you preserve the link to the transaction once, you do not have to search for it night after night.

My field is Decision-to-Execution: the journey from decision to impact. Reto's more important decision comes after the meeting. He has to determine whether the product should receive more sales support and more budget next year. He can only make an informed decision once he knows which transactions account for the increase, and why.

Three effects I expect, rather than promise

I am currently working on a Finance Data Store. That is why I describe three further effects as expectations, not results.

First, the new capabilities make it through. Anyone introducing a new core banking system today should not map it into the old structures. It is more than the old system built with new technology: it delivers events and attributes the old framework did not know. Forcing them into that framework gives you new technology with the old limitations. They arrive in the store as Business Events, and the business functions decide what to make of them.

Second, the store protects the domains around it. Finance is no longer as static as it was thirty years ago. Products, rules and systems change continuously. Without a point in the middle, a change in the core banking system directly hits reports in Accounting, Legal Reporting and Management Accounting. With the store, it lands there first. It is one of several protective points, and one an organisation can deliberately build.

Third, Finance gains time during the day. Until now, processing has predominantly run at the end of the day, along with reconciliation and troubleshooting. Some data can only be used after end-of-day processing. Other data is available during the day. If it is held in one place, business functions can check early, for example whether the morning's transactions have arrived in full. An error discovered in the afternoon does not have to wait until the following morning.

Without a target architecture, the store becomes another copy

An obvious counterexample would be an organisation that preserves transaction references all the way into its reports and reliably reconciles all its extracts: surely it would not need a store. I do not share that view. Even there, someone must continually ensure that the different extracts remain consistent with one another. Intuitively, we take that for granted. It is not a given, and the work involved grows with the number of extracts.

A store does not arrive in one big bang. The old routes run alongside it for a time, and that is right. What matters is a clear target architecture and routes that develop towards it, report by report, until the old extracts are no longer needed. The store is not worthwhile without that target architecture. Then the old routes stay permanently, another is added, and reconstruction and consistency checks remain too. Nor is it worthwhile if nobody takes responsibility for the mapping. Then it really is just another copy. The question for the decision is: Which recurring work disappears, which operations are added, and when does each old route end?

In the next part of the series on databricks.now, I will show how the store itself checks: which checks follow a fixed rule, where an agent explains and where a person approves.

The line Karin writes at half past three

At half past three, Karin sits down in front of the two files again. She closes them and opens the requirements list for the store. At the top, she adds a line: the reference to the transaction is preserved all the way into the reports. Then she writes to Marco, telling him his team should leave early today. The next quarter will show whether that line holds up.

Ask to see five transactions

Take a metric that appears in two reports in your organisation. Ask both teams to show the five largest underlying transactions, and record how long it takes. Ask where someone creates a mapping by hand. Write to me about that point.

If you would like to examine this gap using a specific metric in your organisation, start with the Clarity Audit. Together, we look at the question, the factual foundation and responsibility for the next step.