The automation says “done”. Does the target system agree?

A hotel agent processes a direct booking. The workflow is green: API step successful, confirmation prepared, CRM updated. Later, reception notices that no reservation exists in the PMS.

The workflow completed. The hotel booking did not.

That gap is what reconciliation is for. Instead of checking only whether each technical step appeared successful, the process verifies whether the intended business state actually exists in the systems that matter.

Finance teams have always reconciled balances and transactions. AI automation often skips the same discipline because workflow tools provide reassuring green boxes. A green box tells you that a component reported success. It does not prove the full business outcome.

Automation reconciliation starts with a post-condition

You cannot reconcile a process until “finished” has a concrete definition.

For an appointment, the post-condition might be: exactly one calendar event exists with the correct customer, time and service; CRM stores the event ID; the customer confirmation references that appointment.

For a hotel reservation: the PMS has a confirmed reservation ID with correct dates and rate; the guest or CRM record is linked; the confirmation uses the same reservation reference.

For a sales follow-up: the mail provider accepted the message, CRM status changed and the next task exists.

A workflow status named success is not the post-condition. It can be one trigger to check it.

distributed workflows can end in partial and inconsistent states across systems; saga and compensating-transaction patterns exist to handle multi-step outcomes and failures.

Recommendation: define a machine-checkable post-condition for every automation where a missing action would matter.

Find missing, wrong and duplicate outcomes

A missing outcome means the agent intended an action but the target object is absent. Causes include timeouts, mapping errors, wrong destination or later deletion.

A wrong outcome exists but contains the wrong time, customer, price, quantity or status. The API write happened; the business state is still incorrect.

A duplicate means the desired outcome exists more than once. This is where reconciliation complements idempotency.

There is also a non-error that can look like one: eventual consistency. Some systems need seconds or minutes before a write becomes visible everywhere. Reconcile too quickly and you create a noisy alarm system.

Choose a delay based on business reality. A payment acknowledgement may need seconds; a nightly data sync may deserve a later check. The important thing is that the tolerance is explicit.

Reconciliation should be boring and deterministic where possible

If the question is “Does PMS reservation 88421 exist?”, you do not need a language model to improvise the answer.

A simple job can follow this sequence:

1. Persist intended state. Record what object or change the original case expected.
2. Read the target after an appropriate delay.
3. Compare the post-condition. Existence, key fields, count and cross-system references.
4. Apply defined tolerances. Normal sync delays, rounding or known manual transformations.
5. Recheck transient mismatches. Escalate persistent differences rather than every momentary delay.
6. Create an owned exception. Include customer/case, expected state, actual state, last successful step and who should investigate.

AI can help summarise messy logs or explain an exception. When exact IDs and fields exist, however, the verification itself is stronger as deterministic logic.

Do not let reconciliation overwrite legitimate human work

During an outage, a staff member manually moves an appointment from 14:00 to 15:00. The agent’s old intended state still says 14:00. The reconciliation job detects a mismatch.

Automatically “repairing” the event back to 14:00 would turn a useful control into a damaging one.

Use precedence and recency. Which action is newer? Was it performed by an authorised human? Did the agent run in degraded mode? Is the field safe to auto-correct?

An internal missing tag may be a good automatic repair. Customer times, pricing, payments and manually edited cases deserve a visible exception first.

Human handover in reconciliation is narrow by design. Humans should not recheck every successful transaction. They should receive the small set of differences the system cannot resolve safely.

A minimum pilot: one daily control loop

Choose a workflow that creates a clear target outcome many times per day. Store a target ID or stable business key for each intended action. Run reconciliation every fifteen minutes or at day-end depending on urgency.

Inject faults deliberately: remove one test record, change a field, create a duplicate and delay a sync. A useful control should catch the real discrepancies without escalating the expected delay.

Track post-condition success rate, missing/wrong/duplicate rate, false-alert rate, mean time to detect, mean time to business resolution, and exceptions with an assigned owner.

One particularly valuable metric is the number of business-incomplete cases that the original workflow did not report as an error. That is exactly the blind spot reconciliation is meant to expose.

The practical conclusion is that automation does not finish at 200 OK. It finishes when the target state is correct for the business and, where relevant, for the customer. Reconciliation is the control loop that makes that difference measurable.

Idempotency prevents many duplicates. A kill switch limits an active error. Reconciliation proves what happened afterwards.

Sources

• AWS — Saga patterns
• Microsoft — Compensating Transaction
• NIST SP 800-61 Rev. 3

---