Run reconciliation as a permanent control, not an exception process
Delivery guarantees fail silently. A scheduled comparison of expected and actual populations—with an owner for every kind of difference—is part of the architecture, not cleanup.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
Customer creation, order status and performance segments move between a CRM, an ERP and a data platform. Each flow has retries and alerts, yet users discover the differences months later: customers still pending in the CRM that exist in the ERP, segments never removed, a company missing from an invoice load.
02Decision drivers
- D01
Any delivery mechanism can lose, duplicate or reorder
- D02
Differences found by users destroy trust in the data
- D03
Repair needs an owner, not a shared inbox
- D04
Reruns and repairs must be safe
03Options considered
Ad-hoc checks when someone complains
Low-volume, low-stakes flows
Cost: Divergence accumulates unseenRely on delivery guarantees and alerts
Flows with end-to-end exactly-once semantics
Cost: Alerts see failed calls, not records that never arrivedScheduled reconciliation with classified differences
Any flow whose divergence has a business cost
Cost: Needs comparison keys, a tolerance, a cadence and owners04Decision
For every flow whose divergence has a business cost, define a reconciliation contract: the expected population, the comparison key, the attributes compared, the tolerance, the cadence, and an owner and repair action for each class of difference—match, difference, missing, unexpected. Run it on a schedule, publish the result as a business-state measure, and make every repair idempotent so a rerun never makes things worse.
05Consequences
- Silent divergence becomes visible within one cadence.
- Every class of difference has an owner and an action; nothing lands in a shared inbox.
- Reconciliation results are measured like any other process KPI.
- Integration design must provide stable comparison keys from the start.
06Revisit when
A flow moves inside one transactional system.
Divergence in the flow has no business cost.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Data case / 03Writing analytical signals back into operational CRMA writeback contract for derived KPIs and segments: account grain, read-only in the CRM, stamped with freshness and version, reconciled against what was published—and turned into exactly one task per signal.
- Data case / 04Designing reliable segmentation with reconciliationA segmentation contract with an explicit eligible population, removals as first-class changes and a reconciliation that compares expected and actual membership after every run.
- Automation case / 06Designing a reconciler for stale downstream stateA scheduled reconciler that derives expected downstream state, compares it with what exists, and closes stale actions within guardrails—dry run, blast-radius limit, protected records and an owner review.