Reconcile in the pipe, not in the report

What reconciling in the report looks like

Take record to report. Journals are posted in the ledger, extracted overnight, loaded into a data platform and modelled into the reports the board reads. If the only comparison happens at the end, a difference could have entered at any of those hops, on any day since the last close.

Finding it means tracing records back through each stage, usually in the first days of the close, by the people who are busiest then. When the cause cannot be found in time, the difference is cleared with a manual adjustment that nobody can fully explain a quarter later. The report is signed off, and the cause is still in the pipe.

What reconciling in the pipe looks like

Every hop proves its own work before it passes data on. Four checks do most of it.

• Count. Records sent equal records received, plus records held.
• Control totals. Amounts sent equal amounts received, by company and by currency.
• Key match. Each business key, such as a journal or invoice number, arrives exactly once, with no gaps and no duplicates.
• Hold, do not drop. A record that fails a check is held in a named queue with a reason and an owner, and released once it has been corrected. It never disappears into a log file.

The last check only works if someone looks after the queue. Each queue has a named owner in the business, a time by which held records are either released or escalated, and a short daily list of what is waiting and why. Without those, a queue becomes one more place for records to go missing, just with a better name.

What it changes at month-end

Nothing here removes the close. What changes is what the close starts from.

• Differences are found on the day they occur, while the people and the context are still available.
• The differences that remain at month-end are already listed, each with an owner and a reason, before the first day of the close.
• Fewer manual adjustments are needed to make the report agree with the ledger, because the report was built from data that already did.
• Auditors get evidence from every run, rather than a reconstruction after the event.

When a report and the ledger disagree, the question is no longer where the records went, but which held records have not yet been released. The second question can be answered the same morning.

Where the checks belong

The checks are part of each interface, not a separate tool added afterwards. They run on the integration platform you already license, whether that is MuleSoft, Boomi, Azure Integration Services or SAP Integration Suite, and they are written into the specification before the build starts. Each specification says what is counted, what is totalled, which field is the key, where held records go and who owns them.

Each run then writes its result to the interface register, so the register shows not only that an interface ran, but that the records on both sides matched.

What it does not replace

Account reconciliations, the review of accruals and the controller's judgement all still happen. Reconciling in the pipe does not replace review. It means review starts from complete data, rather than from a search for missing records.

Where to start

Pick the line that causes the most rework at month-end. Often that is the feed from the ledger into the board pack, or the payroll posting. Add counts and control totals at each hop, and a held-records queue with a named owner. Run it alongside the current process for a full close, then compare how much of that close was spent looking for differences. That comparison, in your own numbers, is the business case for the next line.