A mid-market manufacturer had SAP and Exact running side by side. Here is the reconciliation pipeline that closed the books two weeks earlier.
The company had two ERPs and a good reason for each of them. SAP had been there since before the current management team arrived, it ran operations: purchase orders, production runs, goods receipts, inventory movements. Exact came in four years ago when the finance director joined from a firm that used it and preferred it for general ledger, AP, AR, and consolidation. Both systems worked well. The problem was the seam between them.
Every month-end, a finance analyst spent three days reconciling the two. SAP knew about the goods received. Exact knew about the invoice. Getting them to agree on the same cost, in the same period, attributed to the same cost centre, required a spreadsheet the analyst had built over two years and updated by hand with every edge case she discovered. She was the only person who fully understood it. When she took two weeks off in August, the month-end close slipped by eleven days.
Why the seam exists
Dual-ERP setups are more common than most companies admit. They usually arrive via acquisition (the acquired company kept its system), via department autonomy (finance chose one tool, operations chose another), or via inertia (a migration was planned and never completed). In each case, the two systems develop independent data models: different cost centre codes, different supplier IDs, different period definitions, different rounding rules.
The reconciliation spreadsheet is not a workaround, it is the institutional memory of every decision made when those models diverged. The analyst who built it was not being inefficient. She was doing the only sensible thing available: capturing the logic that no one had written down anywhere else.
The problem is that institutional memory in a spreadsheet is invisible, fragile, and locked to one person. It cannot be automated. It cannot be audited. And it cannot run itself when that person is on holiday.
What the data mismatch looked like
When we mapped the reconciliation spreadsheet, we found four recurring mismatch types that accounted for almost all of the manual work.
The first was timing: SAP booked goods received the day they arrived at the warehouse. Exact booked the invoice the day it was approved, which could be anywhere from two days to three weeks later. The same transaction appeared in different periods depending on which system you were looking at.
The second was supplier mapping: SAP had 340 supplier records. Exact had 298. The difference was not 42 missing suppliers, it was 42 suppliers who existed in both systems under different names, different reference codes, or both. The analyst’s spreadsheet contained a manual lookup table that matched them. The lookup table had 38 entries. Four suppliers were still being matched by eye every month.
The third was cost centre structure: the two systems used different hierarchies. SAP tracked costs at the production line level. Exact tracked them at the department level. The analyst had built a mapping between them. It was correct for the current structure. It had not been updated when a department was reorganised in January.
The fourth was rounding: SAP stored unit costs to four decimal places. Exact stored them to two. On high-volume lines, the cumulative rounding difference was large enough to trigger an audit query. The analyst had a formula to reconcile it. Nobody else knew what it did.
The reconciliation pipeline we built
We did not try to replace either ERP. That conversation exists at a different level of the organisation and on a different timeline. What we built was a reconciliation layer that sat between the two systems and did, automatically and transparently, what the spreadsheet was doing manually and implicitly.
The first step was formalising the supplier mapping. We extracted the analyst’s lookup table, validated it against both systems, resolved the four unmatched suppliers with her in a two-hour session, and rebuilt it as a proper reference table with a clear owner and a process for updating it when new suppliers are added. That table now lives in the data layer, not in a spreadsheet on her desktop.
The second step was handling timing. We built the pipeline around goods receipt date as the canonical transaction date, the point at which the liability actually arose, and matched invoices to receipts rather than booking them independently. This is standard accrual logic, but it had never been enforced between the two systems. Invoices that arrived in a different period from the receipt are now flagged automatically rather than reconciled by hand.
The third step was cost centre mapping. We rebuilt the hierarchy mapping as a versioned structure, so that when a reorganisation happens, the old mapping stays valid for historical periods and the new mapping applies from the effective date forward. The January reorganisation was backdated correctly in about forty minutes.
The fourth step was rounding. We chose SAP’s four-decimal precision as the canonical value and built an explicit rounding reconciliation that shows, for any period, the total rounding difference by product line. It is transparent, auditable, and small enough, once consistently applied, that it has not triggered an audit query since go-live.
What changed after go-live
The month-end close that had taken three days of analyst time now runs overnight. The pipeline pulls from both ERPs, applies the mapping and timing rules, produces the reconciled trial balance, and flags any line that requires human review. In the first month after go-live, there were fourteen flagged lines. In the third month, there were three.
The analyst still owns the process. She reviews the flagged lines, approves the reconciliation, and signs off the close. But her three days are now four hours, and those four hours are spent on the things that actually require judgement rather than on manual matching.
The close that had been slipping to day twelve of the following month now closes on day four. Finance has two additional weeks of consolidated data before the board pack goes out. The audit trail is complete, versioned, and readable by anyone, not just the person who built the spreadsheet.
The analyst told us, at the three-month review, that she had finally been able to take a proper holiday. The August eleven-day slip did not happen again. Someone else ran the close while she was away, using the pipeline documentation, without calling her once.
If you are running a similar dual-system setup and want to understand what your own reconciliation gap is costing, the ROI calculator takes three inputs and shows you the annual cost of the manual work, the datareaches alternative, and the payback period. Most teams are surprised by how quickly the number adds up.