How to Reconcile Conflicting Updates From Multiple Source Systems
Decide which system owns each data point, then build processes to detect and resolve mismatches.
When two systems show different numbers for the same thing, the fix is rarely just a software problem. You need to agree on which system is allowed to say what. Then build your process around that decision.
Why source systems reliably disagree with each other
At finance close, the billing system and the general ledger can show different figures even though no money has moved. That gap does not, by itself, mean something broke. Systems built for different jobs describe the same event in different ways. A CRM may record revenue when a deal is signed. A billing platform records it when payment arrives.
Timing creates another kind of disagreement. One system may refresh at midnight and another at 2am. A report run at 9am is then comparing two different snapshots. Each snapshot may be correct on its own, yet the two disagree side by side. ShipShape Data discusses timing differences and schema changes — changes to the structure of a database — as common sources of disagreement. Neither requires anything to have gone wrong in the business.
Structure drift makes the gap harder to spot. A source field gets renamed or resized. But the pipeline — the automated path that moves data between systems — keeps its old mapping. So totals drift apart. Smaller differences also pile up across thousands of records: duplicate customer IDs, currency conversions applied twice, different rounding rules. These causes can look the same but need very different fixes. Treating every mismatch as a broken pipeline hides that distinction.
Why the problem gets harder as more systems are added
Each extra source adds more than another dataset to check. It raises the number of possible conflicts. It also raises new questions about which source gets to say what a value is. Business data passes through point-of-sale systems, warehouses, planning systems, ledgers, and reporting layers. Comparing two endpoints may reveal a difference without showing where it started.
Datagaps describes a customer request to compare more than two datasets at once. That request exposed the limits of many existing reconciliation tools, which were built only to compare pairs. KPMG's 2025 SOX Survey found that the number of in-scope systems grew from FY22 to FY24 while the share of automated controls declined. The directional finding is blunt: more systems do not automatically bring more automation to keep them aligned.
The scope also reaches beyond money into item counts, shipments, units, and calculated performance measures. Even correct data may differ because of delayed updates, partial loads, or rounding. As sources multiply, those ordinary variances create more chances for false alarms. Reconciliation must therefore tell the difference between meaningful conflicts and expected differences.
What you have to decide before asking which system is right
Before any process can resolve a conflict, the business must decide which source holds the official answer for the item being compared. ShipShape Data puts the requirement plainly: "You must first decide which system serves as the primary source of truth for each specific figure. If you do not have that anchor, every disagreement becomes a debate." A comparison can show that two values differ, but it cannot supply that authority on its own.
Authority belongs to individual data elements within a system, not to whole systems. The planning system may govern invoice amounts while the CRM governs customer status. That authority map must reflect what each source is entitled to say about the business. That is a business decision before it becomes a technical rule.
Matching records does not settle their meaning either. One system may hold a person's application, another their licensing progress, and another their support history. A shared key can connect the records without explaining how they relate to the same process. Machine learning — software that spots patterns from past data — can identify which source has won past disputes most often. But that pattern is only a stand-in for authority. Without human confirmation, it carries the bias of past decisions into future ones.
The key distinction is between a timing gap and a definition gap. A timing gap may close when the slower system catches up or when a data feed is replayed. A definition gap requires human agreement about what a field means and which definition governs. Waiting cannot settle that. No correction is valid until the meaning is agreed.
How to detect conflicts reliably before they spread
Once authority is set, detection needs a repeatable process. ShipShape Data advises mapping the process before automating it. Reconciliation often fails when steps are skipped, even with the right software. The sequence is: pull data from each source, convert it into a shared structure, match records on an agreed key, label each result as matched, missing, or mismatched, then route exceptions to the people responsible for that data.
The labels must be useful for investigation. A missing record points to a different question from a value mismatch on the same key. Duplicates, date mismatches, and status differences also need to stay separate. Tolerances — defined limits within which a difference is acceptable — account for expected rounding, delayed updates, and partial loads. Without them, reviewers spend time checking differences in data that is actually correct.
The comparison must also expose patterns across the full path. Datagaps describes comparing data across several systems at once so discrepancies can be seen together. Visual patterns can reveal exceptions that cluster around one upstream source or time window, pointing toward a shared cause. The reconciliation log must preserve what was compared, what matched, what was flagged, and when. That record supports both investigation and audit.
Routing exceptions to the right person with enough context to decide
A detected exception is not yet a decision. If it reaches a reviewer as a bare row of conflicting values, the reviewer still has to work out what those values mean for the business. The queue is only as useful as the context it shows: the source values side by side, the matching key, and which system is authoritative for that element. It should also show downstream effects and whether a similar exception has come up before.
The likely cause determines where the exception goes. A timing gap may need waiting or a feed replay. A mapping error needs a pipeline fix. A definition conflict belongs with someone authorized to decide which business meaning governs. A genuine data error needs a correction with an audit trail. When owners are named, status and actions are recorded, and work is tracked through resolution, those paths become a controlled process instead of email threads.
Owners must be named before the process runs, or exceptions can sit unresolved while wrong data reaches downstream reports. Permission to inspect a problem must also remain separate from permission to change a record. Machine learning can link exceptions across runs to show whether one upstream feed repeatedly produces the same mismatch. Exceptions that keep coming back without a root-cause diagnosis are the main source of unresolved reconciliation work.
Why controlling the correction step matters as much as detection
An unexplained correction can become the next source of conflict. If an adjustment records no reason, the same investigation may be needed again next period. ShipShape Data describes the final reconciliation step as resolving the discrepancy and documenting its cause.
The decision path must be traceable from detection through outcome. It must show which source was authoritative. It must show what the reviewer saw, what they decided, and who approved the correction. It must also show what changed and what the measured outcome was, including failed or inconclusive resolutions. Financial services, healthcare, and insurance require an audit record of what happened to unmatched data and who authorized the response. Recording only successful matches leaves out the decisions that matter most.
AI-assisted matching and classification make this requirement more pressing. AI can influence classifications and estimates before traditional controls operate. That leaves a gap between a controlled final output and evidence of how it was reached. Recommendations therefore need visible evidence and stated assumptions that reviewers can inspect and override. Approvals, quality standards, risk limits, and exception owners must be set up before a discrepancy appears.
What a well-governed reconciliation process looks like from start to finish
The process starts before any records are compared. The business names the authoritative source for each element and the conditions under which that authority can be overridden. It then defines the comparison grain — aligning sources to the same key, currency, time window, and unit of measure. This keeps differences in snapshots or measures from being flagged as errors.
Timing gaps get a defined window in which they can resolve. Rounding differences get a set tolerance. Mapping errors go to the engineering team. Genuine data errors go to a named owner who has the authority to correct them. Any exception that needs human judgment carries the values, authority designation, likely cause, downstream impact, and recurrence history. The reviewer can then investigate with context already assembled.
Review and correction stay as separate stages. Reviewers inspect the evidence. Named approvers authorize changes within limits set in advance. The record shows why the discrepancy happened, what was decided, what was approved, and what changed. Measured outcomes show whether the resolution worked, failed, or remained inconclusive.
The next cycle builds on that record. Exceptions that keep coming from one source guide root-cause diagnosis and upstream fixes. That way, downstream adjustments do not have to continue indefinitely. Starting with one named process, one accountable owner, and one measurable outcome gives the work a clear scope. Investigation and recommendations can show their quality before corrections are authorized more broadly.
How a context graph changes what reconciliation can accomplish
That process still needs to work across separate systems. Many conflicts persist because no system connects what the records mean for the same person, process, and decision. A context graph — a map of explicit relationships between records — addresses that gap. For the person whose records span application, licensing, and support systems, a shared ID establishes identity but not the relationship between those activities. The graph connects their meaning so the available data can inform the reconciliation decision.
Making those relationships explicit also gives authority rules a practical role. Authority per element can be enforced by the system instead of remaining in a policy that no tool applies. Decision records — records that link evidence, recommendations, human reasoning, approvals, actions, and measured outcomes — connect correction history into institutional memory for the next cycle. Failed or inconclusive results are included.
A model-agnostic architecture — one that is not locked to a single AI model — allows models to be swapped or upgraded. The organization keeps its authority maps, business rules, and correction history. The context graph supplies the missing context while business judgment remains necessary. Scale follows from preserving meaning and governed decisions.
