Free Reconciliation Error Detector

Most close-cycle pain starts with a shape mismatch. Money arrives as a single settlement while the ledger is written per transaction. Say one deposit of $47,312.18 standing for 218 captures, 6 refunds and a fee the provider took on the way out. Nothing joins them until somebody pulls the settlement report and expands it. Until then the bank line matches no invoice, the invoices show as unpaid, and the difference between the gross the ledger expected and the net the bank received looks like a discrepancy when it is the fee doing exactly what the contract says.

The standing arrangement is a person, a spreadsheet and the last working day of the month. It functions, and what it costs is repeatability: the matching logic exists in one head, the exceptions are resolved by memory of what happened last time, and the evidence of a decision is a cell that used to be red. That model degrades quietly with volume. Two providers, three currencies and a refund window that crosses a month end turn a two-hour task into a two-day one, and the first sign is usually that the close slips by a day rather than that anything is wrong.

The residual is the part worth designing before it appears. Every close leaves a small difference nobody can attribute, and the failure is to leave it open. Set a threshold under which an unexplained difference is written off, name the account it goes to, require a reason code on each one, and review the codes quarterly rather than the individual amounts. A recurring $12 rounding difference on one provider is a configuration fix. The same $12 spread across forty reason-free write-offs is a control gap, and only the reason code tells the two apart.