An integration dashboard full of green ticks tells you the jobs ran. It does not tell you whether the order count in the commerce platform matches the ERP, whether every payment reached the ledger, or whether a record was quietly rejected three weeks ago.
That is what a reconciliation report is for. It compares what one system says with what another says, explains the differences, and gives someone the evidence to sign off. For any integration that carries money, inventory or regulated data, it is not an optional extra – it is how the business knows the integration works.
Three levels of reconciliation
Good reconciliation works at more than one level, because each catches problems the others miss.
| Level | Compares | Catches |
|---|---|---|
| Control totals | Counts and sums by period, entity, currency or category | Missing batches, duplicated loads, wrong periods |
| Record-level matching | Individual records by a shared identifier | Specific missing, duplicated or rejected records |
| Field-level comparison | Key fields on matched records | Records that exist in both systems but disagree – amount, status, date |
Control totals are cheap and should run every time. Record-level matching is the workhorse. Field-level comparison is reserved for the fields that matter most, such as amounts and statuses.
The shared identifier
Record-level reconciliation depends on being able to match a record in one system to its counterpart in the other. That means a shared identifier stored in both: the source record’s ID carried into the target, or an external ID on both sides.
If the integration was built without one, adding it is usually the first job. Matching on names, dates and amounts is possible, but it is slow, ambiguous and never fully trusted.
Timing differences are not errors
Systems rarely agree at every instant. An order placed at 23:59 may land in the ERP after midnight. A payment settles a day after it is captured. A journal posts in the next period.
A good report distinguishes:
- Timing differences – expected to clear within a defined window.
- Exceptions – differences that will not clear on their own and need action.
Reporting every timing difference as an error trains people to ignore the report. Define the windows, show items still within them separately, and escalate only what has aged past them.
What the report should show
A reconciliation report someone can act on usually includes:
- The period and scope – which systems, entities and record types.
- Control totals for each system, side by side, with the difference.
- Matched records – a count, not a list.
- Exceptions, each with the record identifier, the type of difference, its age, and an owner.
- Timing items still within their window.
- Trend – whether exceptions are growing or shrinking over time.
It should run on a schedule, be delivered to the people who own the exceptions, and keep a history so a past period can be re-examined.
Exception management
The report is only half the system. Exceptions need a workflow:
- Classify each exception: missing in target, missing in source, duplicate, field mismatch.
- Assign an owner by type – operations, finance, the integration team.
- Resolve at the source of the problem, not by editing the target to match.
- Record how it was resolved, so recurring causes can be fixed in the integration.
Recurring exceptions of the same type are a defect in the integration, not an operational task.
Building it in from the start
Reconciliation is much easier to design into an integration than to add later. From the first working interface:
- Carry source identifiers into the target.
- Log every batch and message with an ID.
- Record rejected records with the reason, rather than dropping them.
- Agree the control totals with finance or operations before testing starts, and use the reconciliation report as part of acceptance.
Illustrative scenario: from month-end spreadsheet to daily report
This scenario is a composite. It is representative of the reconciliation work we do, but it does not describe a specific client, and nothing in it is a reported result.
A multi-channel retailer’s finance team spends several days each month reconciling orders, refunds and payouts between its commerce platform, its payment provider and its ERP. Differences are found weeks after they happen, when the people involved no longer remember why.
The integration is changed to carry the commerce order ID into the ERP and the payment provider’s metadata. A daily job produces control totals by channel and currency, matches records across the three systems, and lists exceptions with owners – operations for missing orders, finance for amount mismatches. Settlement timing differences are shown separately with a defined clearing window. Month-end becomes a review of a short, already-worked exception list.
What a good outcome looks like: exceptions are found the day after they happen, recurring causes are fixed in the integration, and finance signs off the period with evidence rather than a spreadsheet.
Related reading
- Idempotent webhooks: duplicates, retries and out-of-order events
- ServiceNow ITFM integration: getting cost and finance data in and out
- Stripe integration beyond checkout
Working with eProxim
Reconciliation is built into the integrations eProxim delivers, because the systems we connect usually carry money. We design control totals, record matching and exception workflows that finance and operations can sign off against, and we add reconciliation to integrations other teams have built.
Need proof that your client’s systems agree? See our enterprise integration services, or start a partner conversation.