Payment reconciliation process flowchart (records to settlement)
Payment reconciliation process template for complete source capture, transaction and settlement matching, difference classification, controlled correction, rematch and audit evidence.
What the payment reconciliation process flowchart (records to settlement) process is
Payment reconciliation is not a comparison of two final totals. A defensible process traces internal transaction and ledger records through gateway or processor events, acquirer or network settlement detail, and the bank or settlement account. The workflow begins at a defined period and cutoff, collects each expected source, and checks completeness before matching begins. Missing files, partial batches and cutoff gaps loop back for recovery instead of being treated as zero activity. The reconciliation analyst then normalizes identifiers, batches, currencies and timestamps so differences in format do not become false financial exceptions. Matching at transaction and settlement level gives the control enough detail to explain why control totals agree or do not agree.
Classification comes before correction because timing, missing, duplicate, amount, fee and FX differences have different owners and remedies even when a summary makes them look alike. The analyst traces internal events and gathers participant evidence until the authoritative state and root cause are supportable. A timing item can wait for its expected settlement. A correction or financial adjustment takes a stricter route: the analyst prepares the entry and evidence, Finance / Settlement Control independently approves or returns it, and the authorized posting is made with an audit link before matching runs again. Preparation, approval and posting remain attributable instead of collapsing into one opaque adjustment ticket.
Closure occurs only after rematching and control-total review. An unresolved or aged exception is escalated with a named owner, then re-enters classification and investigation until it clears. Finance / Settlement Control confirms totals, fees and balances, and the period closes with the reconciliation, approvals and evidence retained together. Payment exception management handles an individual failed, duplicate, timeout or ambiguous payment that may need immediate action; this workflow proves the broader books and settlement position. Merchant monitoring and merchant risk assessment may use repeated fee, dispute or settlement findings as risk evidence, while merchant onboarding should establish the identifiers and settlement setup reconciliation depends on. Adapt source names, cutoffs, tolerances and approval levels without making the chart provider-specific.
What this flowchart covers
In this template
- Six stages from source capture through completeness checks, normalization, matching, investigation, controlled correction, rematch and evidence-based close
- Internal transaction and ledger records plus gateway or processor, acquirer or network, and bank or settlement sources
- Classification of timing, missing, duplicate, amount, fee and FX differences before assignment to the responsible participant or internal owner
- Investigation and escalation loops, with timing separated from supported corrections or accounting adjustments
- Independent approval followed by an attributable posting linked to the exception and evidence before rematch
- Aged-exception escalation, control totals, settlement balances and retained reconciliation and approval evidence
When to use this template
- Payment totals agree at a high level but the team cannot trace individual transactions from the internal platform to final settlement
- Missing files, delayed batches and timezone or identifier differences create recurring reconciliation noise and manual spreadsheet work
- Fee, FX, duplicate, amount and settlement differences are corrected before the authoritative state and responsible owner are established
- Manual journal or settlement adjustments lack evidence, independent approval, rematching or linkage to the original exception
- Payment exception management resolves individual incidents but recurring unmatched items are not trended into merchant monitoring or risk review
How it works
Define sources, cutoffs and completeness
Inventory every internal ledger, transaction event, gateway or processor report, acquirer or network settlement file, bank statement and settlement account used for the period. Record expected delivery times, file or batch counts, timezone and late-arrival treatment. Reconciliation should not start until missing or partial data is visible and assigned, even if matching continues provisionally.
Design transaction and settlement match keys
Choose stable identifiers and supporting fields for each leg, including amount, currency, event type, batch, date and participant reference. Normalize timestamps and currencies without overwriting the source values. Test captures, refunds, reversals, disputes, fees and multi-stage settlement so a valid lifecycle is not mistaken for a duplicate or missing payment.
Build a reason and ownership model
Define reason codes for timing, missing, duplicate, amount, fee, FX and other approved differences, with one responsible owner and target age for each. State which evidence confirms the authoritative state. A broad code such as unmatched is useful for intake but not for closure, trend analysis or deciding which participant must act.
Control corrections and adjustments
Define who prepares a correction or adjustment, who independently approves it and who posts it. Preserve the original value, reason and source evidence; link the authorized posting back to the exception and approval. Configure authority by materiality and risk under internal policy, then rerun matching after the posting rather than closing from an approval ticket alone.
Close with rematch and retained evidence
Set aging and materiality triggers for escalation, then confirm every cleared item on a new matching run. Reconcile transaction counts, gross and net amounts, fees, FX and settlement balances. Retain the source versions, exception record, participant evidence, correction, approval and rematch result together, and feed recurring operational patterns into payment exception and merchant monitoring reviews.
Frequently asked questions
What records should a payment reconciliation compare?
The exact sources depend on the payment model, but the process commonly compares internal payment events and ledger entries with gateway or processor records, acquirer or network settlement detail, and bank or settlement statements. Include refunds, reversals, disputes, fees, FX and adjustments where relevant, and define expected cutoffs and completeness for each source.
What are common payment reconciliation differences?
Common categories include timing or cutoff differences, missing records, duplicate records, amount or currency differences, fees, FX calculations, refunds, reversals, disputes and settlement posting errors. Classification matters because a normal timing item, a source-data defect and an accounting adjustment require different evidence, owners and approval.
When should a payment reconciliation adjustment be approved?
Approval should follow confirmation of the authoritative transaction state, root cause, affected amount, accounts, supporting evidence and the reason a timing resolution is insufficient. Keep preparation, independent approval and posting attributable to their owners. The approved entry must then be posted with its exception and evidence link, followed by a fresh match before the item can clear.
What is the difference between payment reconciliation and exception management?
Payment exception management responds to an individual failed, declined, duplicate, timeout, processing, amount or settlement problem and chooses a safe operational action. Payment reconciliation compares complete populations and financial records across participants to prove matching and settlement. The two should share identifiers, reason codes and findings, but neither replaces the other.
Where this process fits
In most operations this process follows Refund process flowchart template.
It is one step in Card payment lifecycle.
Step 1: Card payment process flowchart (purchase response to capture)
Step 2: Payment authorization process flowchart (request to capture)
Step 3: Card transaction lifecycle flowchart (initiation to monitoring)
Step 4: Payment clearing and settlement process flowchart template
Payment clearing and settlement process flowchart for record validation, position calculation, fund movement, merchant funding, mismatch investigation and approved correction posting.
Step 5: Payment reconciliation process flowchart (records to settlement) You are here
Payment reconciliation process template for complete source capture, transaction and settlement matching, difference classification, controlled correction, rematch and audit evidence.