Reconciliation continuity: recover processes without duplicate effects

Separate technical failures from business differences

This article develops a specific control within automated reconciliation, keeping the sale, settlement and confirmation of bank receipt separate.

A provider may respond successfully with an incomplete file. A download may fail even though the bank credit has already arrived. Integration health and collection status answer different questions; preserve both.

Classify incidents by source, entity, currency and period. Distinguish missing sources, incompatible formats, duplicate records, unevaluable rules and overdue credits. A record without sufficient evidence is neither a confirmed difference nor a reconciled item.

Establish coverage before closing

Track expected and received files, their cutoff and the last valid load. A completed process does not prove that all stores or payment methods are covered. Show the missing period alongside available results.

Agree on degraded operation: continue with complete sources, suspend a dependent calculation or route a case for review. Label partial closes explicitly. Do not silently reuse yesterday’s file as evidence for today’s close.

Recover a file without posting the settlement twice

Illustrative example: a merchant settlement file arrives complete, but the bank statement is unavailable at the cutoff. The process can validate sales and fees; it cannot confirm bank receipt. Coverage must show the missing source and period instead of classifying every operation as a monetary difference.

When the bank file arrives, retain the original batch and add a new evidence version. Repeat only checks that depended on that source. File identity alone cannot prevent duplicates: a provider may resend the same operations under a different filename. Operation, period and merchant identity are also required.

A failure after submitting an adjustment requires a different decision. Before resubmitting, check whether the receiving system already posted it. If this cannot be established, route the case for review and preserve the uncertainty. Retrying a read is usually recoverable; repeating a financial adjustment with an unknown outcome can duplicate its effect.

Test recovery at three points: before receiving a source, after calculating the result and after submitting an action. At each point require the same unique operation count and no repetition of confirmed actions. Recovery is complete when the close is reconstructed, not merely when the process is running again.

Recover from a verifiable checkpoint

Before retrying, identify the batch and effects already produced. An operation key should recognize the same event even when it arrives in another file. Reading data again differs from posting another adjustment, sending another notification or executing another movement.

Reprocess a limited population first. Compare record counts, amounts and open cases before and after recovery. Preserve rule versions and the population recalculated when rules change. Keep earlier results so a reviewer can explain why an outcome changed.

Assign ownership and exit conditions

Each failure type needs an owner, an operational deadline, required evidence and a permitted action. Technology can restore an integration; finance validates the business difference. A successful retry alone does not authorize closing the financial case.

Acceptance should demonstrate coverage, consistent balances and no duplicate effects. If a problem persists, prioritize the queue by due date and exposure rather than technical error count alone.

Rehearse recovery

Test late, duplicate and corrected files, mid-batch interruptions and format changes. Measure time to a usable close, items still unevaluable and duplicate effects detected.

Set source-specific freshness and recovery objectives. If loading is fast but human review takes days, resolution is the bottleneck. Improve the step that delays the actual close, not just the component generating an alert.

• Source recovered
• Operations deduplicated
• Bank outcome verified