One Payment, Three Ledgers: Where Reconciliation Actually Breaks

In payment processing, a single transaction generates three distinct records: one for the company's product ledger, another for the processor's settlement data, and the third for the bank statement. Each record represents a different fact about the transaction, and reconciling them is crucial for maintaining accurate financial records.

The product ledger records the economic event as perceived by the application, including aspects like capture, refunds, fees, reserves, chargebacks, or corrections. It should maintain the customer-facing and accounting consequences even if an external provider changes in the future.

Processors have their own perspective on the transaction. They generate settlement data that determines which transactions and adjustments were included in a payout. For example, Stripe provides immutable balance transactions and allows automatic payouts to retain their association with the containing transactions. On the other hand, Adyen's settlement details include settled payments, fees, corrections, payouts, and a payout reference that may appear on the bank statement.

The bank statement is the final record that proves the cash movement. However, it cannot explain the composition of a processor batch, nor can the processor prove that a credit reached the bank by simply marking a payment as settled. This separation of records is essential in payment system engineering because the integration call that moves money and the evidence that closes the books have different owners.

Reconciliation is the process that compares these three facts, preserves the mismatches, and proves what happened at every boundary. A useful design should establish invariants across the product ledger, the processor settlement record, and the bank statement. These invariants ensure that the sum of all economic events matches across all systems.

To implement reconciliation effectively, start by defining a currency and a reconciliation window. Then, establish equations that must hold true after accounting for factors such as cutoffs, fees, reserves, refunds, chargebacks, corrections, and foreign-exchange effects. These equations serve as boundary invariants that must be maintained throughout the reconciliation process.

When a mismatch occurs, it is essential to determine whether the payment was included in a closed settlement batch. If not, the first invariant may still be open due to factors like the provider's cutoff, reserve policy, or status mapping. If the payment was included in a closed batch, locate the payout reference and compare the batch net amount with the expected bank credit.

If there is still an absence, the discrepancy should be marked as awaiting_bank_evidence rather than a generic failed flag. This distinction changes the recovery action, as a ledger mapping defect may require a replay from immutable source events, while a missing bank credit requires investigation from the provider or bank.