How Reconciliation Works
Reconciliation follows a structured, repeatable cycle that compares data from at least two independent sources for every transaction. The process begins after settlement is complete and raw transaction data is available from the payment processor. Each step narrows the gap between raw data and verified, audit-ready records.
Collect Source Data
Gather transaction reports from every relevant source: your payment processor's settlement file, your acquiring bank's statement, and your internal order management or accounting system. Formats vary—CSV, ISO 20022 XML, or proprietary APIs—so normalisation is often needed before matching begins.
Normalise and Map Fields
Align field names, date formats, currency codes, and transaction identifiers across all sources. A processor may label a field "merchant_ref" while your ERP calls it "order_id". Without consistent mapping, automated matching produces false positives and misses real discrepancies.
Match Transactions
Apply matching rules—typically on transaction ID, amount, currency, and date—to pair records from each source. Most platforms handle this via batch-processing, running nightly jobs that process thousands of records in minutes.
Identify Exceptions
Flag any transactions that cannot be matched: unmatched items, amount mismatches, duplicate entries, or records present in one source but absent from another. These exceptions form the reconciliation exception report for human review.
Investigate and Resolve
Finance or operations staff review each exception. Common resolutions include posting a manual adjustment, disputing a fee with the processor, or contesting a chargeback. Each resolution is documented for audit purposes.
Close the Period
Once all exceptions are resolved or formally acknowledged, the reconciliation period is closed. Closing entries are posted to the general ledger, and a sign-off record is created for compliance and audit trails.
Why Reconciliation Matters
For merchants and payment operations teams, reconciliation is not an administrative formality—it is a direct control over revenue integrity and regulatory compliance. Errors left undetected compound quickly at scale, and the cost of finding them months later is far higher than catching them daily.
According to industry research by Datos Insights, manual reconciliation errors account for an estimated $118 billion in annual losses across global commerce, spanning duplicate payments, missed chargebacks, and undetected fraud. A separate study by KPMG found that companies running automated reconciliation processes close their books up to 50% faster than those relying on spreadsheets, with materially fewer audit findings. The Association of Certified Fraud Examiners (ACFE) reports that organisations without strong reconciliation controls suffer fraud losses nearly twice as large as those with robust matching processes, simply because anomalies go undetected for longer.
Why daily beats monthly
A discrepancy discovered the same day it occurs takes minutes to trace. The same discrepancy found 30 days later may require reconstructing dozens of related transactions, contacting the processor, and re-opening closed batch records—a task that can take hours or days.
Reconciliation vs. Clearing
Reconciliation and clearing are closely related but operate at different stages of the payment lifecycle and serve different purposes. Understanding the distinction prevents confusion when diagnosing where a discrepancy originates.
| Dimension | Clearing | Reconciliation |
|---|---|---|
| What it does | Exchanges transaction data between banks to calculate net obligations | Verifies that recorded transactions match actual money movement |
| Who performs it | Card networks, ACH operators, central banks | Merchants, PSPs, and their finance teams |
| When it happens | Between authorization and settlement | After settlement, as a post-facto check |
| Output | Net settlement instructions for banks | Matched ledger entries + exception report |
| Failure impact | Transaction cannot settle | Discrepancy in books; potential financial loss |
| Automation | Fully automated by network infrastructure | Partially automated; exceptions need human review |
Types of Reconciliation
Several distinct reconciliation types exist in a typical payments stack, and most merchants need more than one. Each targets a different layer of the financial data chain.
Bank Reconciliation compares the merchant's internal cash ledger against the bank statement. It is the most common form and the foundation of any accounting close process.
Processor Reconciliation matches the payment processor's transaction-level report (amounts, fees, refunds, chargebacks) against the merchant's order management system. This is where most payment-specific discrepancies surface.
Intercompany Reconciliation is relevant to multi-entity businesses, ensuring that transactions between subsidiaries net to zero at the group level. Common in large retailers with separate legal entities per region.
Multi-Currency Reconciliation adds FX conversion logic, reconciling original transaction currencies against the settlement currency. Rounding differences and mid-day rate fluctuations create routine small variances that must be within defined tolerance bands.
Chargeback Reconciliation specifically tracks disputed transactions from initial chargeback notice through final resolution, confirming that won disputes are credited and lost disputes are properly expensed.
Best Practices
Sound reconciliation practice differs somewhat depending on your role. Merchants need operational discipline; developers need system design that makes reconciliation tractable at scale.
For Merchants
- Reconcile daily. Run the previous day's transactions against the processor settlement file every morning before the business day starts. Stale exceptions are expensive to resolve.
- Define tolerance thresholds. Currency rounding and minor timing differences produce unavoidable small variances. Set a documented tolerance (e.g., ±$0.01 per transaction or ±0.05% per batch) so staff focus on genuine errors.
- Keep a reconciliation log. Every exception and its resolution should be recorded with a timestamp, the staff member responsible, and the corrective action taken. This is your audit trail.
- Separate duties. The person who posts payments should not be the person who reconciles them. Segregation of duties is a basic fraud-prevention control endorsed by every major audit framework.
For Developers
- Preserve raw source files. Never overwrite the original processor export or bank statement. Store immutable copies so reconciliation can be re-run if a bug is found in matching logic.
- Use idempotent transaction IDs. Every transaction must carry a unique, stable identifier that survives retries, refunds, and partial captures. Without it, automated matching is unreliable.
- Build exception APIs. Reconciliation exceptions should be queryable via API so finance tools and dashboards can surface them without manual file exports. Design your schema with exception state (open, in-review, resolved) as a first-class field.
- Log every state change. Capture timestamps and actor IDs for every status transition on a transaction—authorized, captured, settled, refunded—so matching logic can account for multi-day lifecycles correctly.
Common Mistakes
Even experienced teams make predictable errors that create reconciliation headaches downstream.
1. Treating settlement date as transaction date. Authorization and settlement can fall on different calendar days, especially around weekends and holidays. Using the wrong date causes transactions to appear missing in one period and duplicated in the next.
2. Ignoring processing fees in the match. Processors net their fees from settlement amounts. If your system expects the gross authorization amount to match the settlement amount, every transaction will appear to have a discrepancy. Always account for interchange, scheme fees, and processor margins.
3. Not reconciling refunds and chargebacks separately. Refunds and chargebacks reduce settled amounts but originate from different workflows. Lumping them together masks the true chargeback rate and makes dispute management harder.
4. Relying on spreadsheets at volume. Manual spreadsheet reconciliation works below roughly 500 transactions per month. Above that threshold, formula errors, copy-paste mistakes, and file version conflicts introduce more errors than they catch.
5. Skipping reconciliation during peak periods. Black Friday, end-of-quarter pushes, and product launches are exactly when transaction volume spikes and when discrepancies are most likely. These are the worst times to defer reconciliation—not the best.
Reconciliation and Tagada
Tagada is a payment orchestration platform that routes transactions across multiple processors, acquirers, and payment methods. This multi-rail architecture makes reconciliation significantly more complex: a single customer order may touch three different processors depending on routing rules, currency, and fallback logic.
Unified reconciliation across all rails
Tagada normalises transaction data from every connected processor into a single unified event stream. Each transaction carries a consistent internal reference ID regardless of which acquirer processed it, making cross-processor reconciliation as straightforward as single-processor reconciliation. Finance teams get one settlement report instead of one per processor, with fees, refunds, and chargebacks already attributed to the correct rail.
When a transaction is retried across processors due to a soft decline, Tagada ensures only the successful leg appears in settlement data, preventing the phantom duplicate entries that cause false reconciliation failures in naive multi-processor setups. Adjustment entries for routing fees and currency conversion are exposed via API so they can be ingested directly into your accounting system without manual data entry.