Synchronisation tries to keep systems aligned. Reconciliation begins after alignment has already failed.
One database says the order was shipped. Another says it is still packed. A bank ledger records a transaction while a statement feed is missing it. Two agencies hold different addresses for the same person. A learner’s old assessment says “not secure,” while later independent work suggests the capability has changed.
At this point, copying one record over the other is not enough. The system first has to ask: which state is better supported, what happened between the two records, and what must be preserved when the conflict is repaired?
That is state reconciliation.
Reconciliation Starts With a Disagreement
Two systems can disagree for many reasons:
- one update arrived late;
- a message was duplicated;
- one side failed after partially completing a transition;
- two actors changed the same object independently;
- a manual correction was made in one place but not another;
- the systems use different definitions for what appears to be the same state.
The disagreement is therefore evidence. Before repairing it, we need to understand its type.
First Ask Whether the Two Records Mean the Same Thing
Some apparent conflicts are semantic rather than factual.
“Shipped” may mean “label created” in one system and “physically handed to carrier” in another. “Completed” may mean “workflow ended” to an operator and “customer received the result” to the receiver.
Reconciliation therefore starts with schema and meaning. If the fields do not represent the same state, forcing them to match can make the system less accurate.
Find the Authoritative Source — but Do Not Worship It
Many systems designate an authoritative source for a particular field: the ledger for settlement, the registry for legal status, the warehouse system for inventory location.
Authority makes reconciliation tractable. It tells the system which record normally wins.
But authority is not infallibility. The authoritative system can itself contain a bad observation or an incomplete transition. Good reconciliation preserves the ability to challenge the record with evidence.
History Often Resolves What Snapshots Cannot
Two current snapshots may conflict while their event histories explain why.
If System A shows “delivered” and System B shows “out for delivery,” the event trail may reveal a delivery scan that System B never consumed.
History lets us reconstruct sequence: what changed, when, under whose authority and with what acknowledgement.
This is one reason event logs and provenance matter. A state without history can be difficult to repair because the system knows that records differ but not how they diverged.
Some Conflicts Can Be Merged
Not every reconciliation requires choosing one side.
If two users independently add different non-conflicting notes to the same record, both changes may survive. If two branches update separate attributes, a merge may preserve both.
The challenge is knowing whether the changes are genuinely independent. Two edits to the same quantity or decision may require arbitration rather than automatic merging.
Some Conflicts Need a Winner
When two states cannot both be true, the system needs a conflict rule.
- authoritative source wins;
- newer valid event wins;
- higher-authority decision wins;
- verified physical observation wins;
- manual adjudication is required.
The rule must fit the domain. “Latest timestamp wins” can be convenient in software and disastrous in law, finance or safety-critical systems if the later record is not actually more authoritative.
Idempotency Prevents Repair From Creating a Second Error
Reconciliation often replays events or retries operations. That creates a danger: the repair action itself may be applied twice.
An idempotent operation can be repeated without multiplying the intended effect. Setting a status to “delivered” twice is different from charging a card twice.
Reliable reconciliation therefore distinguishes safe replay from actions that require duplicate detection.
Reconciliation Should Preserve Evidence
A bad repair overwrites the losing state and destroys the evidence of disagreement.
A better repair records:
- the conflicting states;
- the evidence used to decide;
- the rule or authority applied;
- the final reconciled state;
- the time of reconciliation;
- any unresolved uncertainty.
This turns a correction into institutional memory rather than silent erasure.
Worked Example: Financial Reconciliation
Finance makes reconciliation unusually visible because ledgers must prove that recorded claims line up with external evidence.
A company’s internal ledger may show one cash balance while the bank statement shows another. Outstanding payments, fees, timing differences or errors can explain the gap.
The purpose is not merely to force both numbers to match. It is to explain every difference until the two systems can be brought into a defensible relationship.
See Bank Reconciliation | How Financial Ledgers Prove That Both Sides Agree for the finance-specific case.
Worked Example: Learning Evidence
A student’s old diagnostic says a topic is weak. A new homework set is perfect. Should the learner state be changed to “mastered”?
Reconciliation asks whether the evidence is comparable. Was the homework independent? Was it completed immediately after teaching? Did the learner succeed under changed questions and delayed retrieval?
The two records may not conflict at all. They may describe different support conditions. A richer reconciled state might be: “accurate under guided/familiar conditions; independent transfer not yet verified.”
Worked Example: Two Institutions
Suppose one institution has updated a person’s status while a downstream agency still holds the old record.
The repair requires more than sending the new value. The receiving institution may need evidence of authority, effective date, identity and whether prior decisions made under the old state remain valid.
Cross-institution reconciliation therefore combines state, provenance and legal effect.
When Automatic Reconciliation Should Stop
Automation is valuable for routine differences. It should stop when the cost of a wrong merge exceeds the benefit of speed.
- identity is uncertain;
- two authoritative sources conflict;
- the transition may have legal or safety consequences;
- history is incomplete;
- the repair would be irreversible;
- the receiver disputes the system’s state.
These cases need adjudication rather than blind convergence.
A Reconciliation Sequence
- Detect disagreement.
- Confirm the records refer to the same object and meaning.
- Gather event history and provenance.
- Identify the authoritative owner for each field.
- Classify the conflict as mergeable, winner-required or adjudication-required.
- Apply the repair safely and idempotently.
- Propagate the reconciled state.
- Verify that downstream systems and the receiver now agree sufficiently.
- Preserve the reconciliation record.
Reconciliation Is the Repair Path for Distributed Truth
State synchronisation tries to prevent divergence. Reconciliation handles the divergence that remains.
The two mechanisms belong together because no large distributed system can assume perfect delivery, perfect clocks, perfect data or perfect humans.
Reconciliation is not making two records look the same. It is rebuilding one defensible account of reality from evidence that temporarily disagreed.
Continue through How Repair Routing Works, How State Synchronisation Works and the master How X Works hub.