Payment reconciliation: explain every unmatched transaction

Build a repeatable comparison between provider records and your ledger using stable identifiers, explicit cut-offs and an owned exception queue.

Dark ledger stacks linked by indigo transaction paths and a reconciliation marker.

Payment reconciliation compares records that describe the same economic activity and explains the differences. It is not a single equality between a dashboard balance and a bank payout. Begin by naming the comparison: orders versus payments, payments versus ledger entries, or provider settlements versus bank receipts. Each has different timing, fees and exception rules.

Define the population before joining records

Record the source systems, timestamps, timezone and accounting period used by the comparison. State whether you are comparing created, captured, settled or refunded operations. Include currency and account boundaries in the key. Without a documented cut-off, a valid transaction near midnight can look missing simply because the two exports cover different windows.

Difference	First investigation	Possible resolution
Provider payment has no internal entry	Check ingestion history and the order's identifiers	Recover a missed transition through the approved repair path.
Amounts differ	Check fees, partial capture, refunds and currency	Explain components or open a genuine amount discrepancy.
Internal entry has no provider match	Check environment, provider account and pending status	Locate the source or investigate an unsupported entry.
Multiple candidate matches	Inspect stable identifiers and original operation	Resolve identity; do not silently pick the nearest amount.

Keep exceptions as work, not a hidden adjustment

Create a durable exception record with source identifiers, reason, first observation and owner. Separate timing differences from unexplained discrepancies, but revisit both. An exception that repeatedly rolls into the next report needs a deadline and escalation. Corrections should preserve the original entry and record who approved the adjustment; changing a historical number until totals match destroys the explanation.

Make the comparison repeatable

Retain the export references, query version and period definition so another reviewer can reproduce the result.
Test missing, duplicate, late, partially refunded and multi-currency examples in a controlled dataset.
Confirm that rerunning the same comparison updates existing exceptions instead of creating indistinguishable duplicates.

Summaries should show counts and values by currency, exception category and age. Avoid adding currencies into a single unexplained total. If a reporting conversion is needed, record the rate source and date separately from the underlying transaction amounts. Reconciliation is complete for a period only under an agreed definition of resolved and explicitly accepted outstanding items.

Frequently asked questions

How often should reconciliation run?

Choose a cadence from transaction volume, settlement timing and how quickly discrepancies must be detected. Daily operation is not a substitute for defining those requirements.

Can we match by customer, amount and date?

Those fields can assist investigation, but may not uniquely identify an operation. Prefer stable provider and internal identifiers and surface ambiguous matches.

Are fees always a discrepancy?

No. They may explain the difference between gross activity and net settlement. Represent them explicitly rather than changing transaction amounts.

Should a repair overwrite the original ledger row?

Prefer traceable corrections that preserve the original record and approval evidence. The appropriate accounting treatment must follow the system's agreed financial model.

What proves that the process works?

Known test discrepancies are detected, correctly classified and resolved through an owned workflow, and the same input population produces reproducible results.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →