Multi-Step Reconciliation

Multi-step reconciliation is the practice of reconciling a flow of money across several systems in sequence, matching each stage to the next, so that a single transaction can be followed from the moment it starts to the moment it lands in the bank and the accounts. A card sale, for example, may be checked from the order system to the payment processor's record, from there to the processor's settlement report, then to the bank deposit, and finally to the general ledger. The term is practitioner language used by finance-operations teams and reconciliation software vendors, not a formal accounting standard.

Related labels include "two-way", "three-way" and "n-way" reconciliation, which count how many data sources are compared. Multi-step reconciliation builds on transaction reconciliation at each link and on balance reconciliation at the end points. It is common in e-commerce, marketplaces, remittances, lending and any business where money passes through intermediaries before reaching the company's account.

Think of a parcel sent across the country. It is scanned when collected, at the regional depot, at the local depot and on delivery. If it never arrives, the scans show exactly where it was last seen. Checking only "sent" against "delivered" would tell you that a parcel is missing, but not where to look.

Money moving through a business works the same way. Instead of comparing only the first record with the last, each hand-off is checked: did every sale reach the processor, did every processed payment get settled, did every settlement reach the bank? When something goes wrong, the gap shows up at a specific link in the chain.

An online merchant that accepts cards often runs these steps:

1. Orders to payments. Each order in the shop system is matched to an authorised payment from the payment service provider, catching orders shipped without payment.
2. Payments to settlement report. Each captured payment is matched to a line in the PSP's settlement report, which also lists refunds, chargebacks and fees.
3. Settlement report to bank. The net payout shown in the report is matched to the deposit on the bank statement; see settlement reconciliation.
4. Bank to ledger. The deposit, the gross sales, and the fees are posted to the correct ledger accounts, completing bank reconciliation.

At each step the totals should roll forward. A simple control is to check that every amount is accounted for between the first and last stage:

• $S_{\text{gross}}$ is gross captured sales; $R$ is refunds; $C$ is chargebacks; $F$ is processing fees.
• $P_{\text{bank}}$ is payouts received in the bank.
• $O$ is amounts still open: settled but not yet paid out, or held in a reserve.

Worked example: sales of 100,000, refunds of 3,000, chargebacks of 1,000 and fees of 2,500 should equal 93,500. If 90,000 has reached the bank and the PSP shows 3,500 held in a rolling reserve, the chain is complete. If only 2,000 is shown as held, 1,500 is missing and the step-by-step matches show at which link it was lost.

A widely used fixed-form version is the three-way reconciliation of trust or client accounts. Law firms, property agents and escrow companies compare three figures: the adjusted bank balance of the trust account, the firm's trust account journal, and the total of all individual client ledgers. All three must agree. Rules for lawyers' trust accounts vary by US state; Iowa, for example, requires a full three-way reconciliation each month under Iowa Court Rule 45.2. Payment firms apply the same logic to customer funds held in a trust account or safeguarding account, and procurement teams use a different "three-way match" of purchase order, goods receipt and supplier invoice before paying accounts payable.

• Money transfer. A cross-border transfer is matched from customer pay-in, to the prefunded balance at the payout partner, to the partner's payout confirmation, to the nostro account statement.
• Marketplaces and platforms. Buyer payments are matched to seller balances, then to seller payouts and the platform's commission, often across a for-benefit-of account.
• Payment orchestration. Merchants using payment orchestration across several processors add a step that normalises each processor's reports before matching.
• Stablecoin flows. A fiat deposit is matched to a mint or on-chain transfer, then to the customer's wallet credit and finally to reserve movements.

The chain works only if a reference survives each hop. Firms therefore pass an order ID or payment ID into every downstream call and store each provider's own reference alongside it. Steps run at different speeds: authorisations are immediate, settlement takes a day or more, bank deposits follow, so each link needs its own cut-off and an "in transit" bucket for items not yet expected to match. Teams usually automate the chain through a reconciliation API or dedicated software, report a match rate for each step, and route breaks to the team that owns that link. The end result feeds the account-level sign-off in account reconciliation and supports payment reconciliation against invoices.

• Iowa Judicial Branch: Trust Accounts