Skip to main content
Back to insights

Plan Reconciliation Before Launch

A successful API response or completed batch does not prove the destination reflects the intended business state.

  • Architecture
  • Integration

Arinao Tshamano16 October 20262 min read

A successful API response or completed batch does not prove the destination reflects the intended business state. A source may count ten orders sent, a transfer service count ten messages accepted, and a destination count only nine records applied. Each number can be true. Reconciliation compares the three stages with a common identifier and a defined time window.

What good engineering looks like

How will the team compare what the source sent with what the destination accepted? Answer this for a named workflow and an accountable team. Identify the information needed at the moment of decision, the system that can settle a dispute, and the route for correcting dependent copies. The technical design should make those business rules visible to the people who operate and support the handoff.

  • Define record identifiers, counts and business totals to compare.

  • Agree on timing and tolerances before the first production run.

  • Assign an owner and correction route for every mismatch.

  • A named owner for a rejected, delayed or repeated item.

  • Evidence that the receiving system applied the intended business state.

A practical starting point

  1. Choose one real case and write down its trigger, expected outcome and responsible team.

  2. Run a test containing a duplicate, a rejection and a delayed record.

  3. Confirm that the report explains the difference between sent, accepted and applied, and names who closes each open item. A balanced total without record-level traceability can still hide the wrong outcome.

  4. Record what the test exposed, who will resolve each open question and how the fix will be checked.

Keep the first design small enough to review with the people who run the process. Test an exception alongside the normal case. A successful transport test shows that data moved; it does not by itself prove that the receiving team can make the right decision or recover from a partial failure.

The decision to make

Reconciliation is a control for consequential transfers, not a substitute for fixing repeated defects at their source. Decide what level of timing, traceability and recovery this workflow actually needs. Document assumptions that remain untested and revisit the choice when a partner, process or business rule changes. The point is a dependable operating decision, not simply a working interface.

Explore Algoza's related services: https://algoza.co.za/services/integration

Apply the thinking

Working through a related technology decision?

Share the operational context, current systems, constraints, and decision you need to make.

Discuss a requirement