Overview
Reconciliation is the control that confirms that two records of the same transaction agree. The bank statement and the cash book. The sub-ledger and the general ledger. The intercompany receivable and the corresponding intercompany payable. The payment processor settlement and the revenue ledger. The marketplace payout and the orders it relates to. When these records agree, the financial position is confirmed. When they do not, the discrepancy needs to be found, explained, and resolved before the numbers can be trusted.
At low transaction volumes, reconciliation is manual and manageable. At the transaction volumes that modern financial operations handle — thousands of bank transactions per month, millions of payment processor records, hundreds of intercompany transactions across a group — manual reconciliation is neither practical nor reliable. The matching work that takes a person hours to complete for a small dataset takes days or weeks for a large one. The errors that manual matching introduces — missed matches, duplicate matches, incorrectly resolved exceptions — compound rather than reduce as volume grows.
Reconciliation software automates the matching process — applying configurable matching rules to identify corresponding records across datasets, clearing matched items automatically, and surfacing unmatched items as exceptions that require human attention. The operations and finance team focus on the exceptions — the items that genuinely need investigation — rather than on the matching work that can and should be done by the system.
We build custom reconciliation software for finance teams, operations functions, and treasury teams that need matching capability specific to their data characteristics, their matching logic, and the systems they work with — rather than a generic reconciliation tool configured around what a standard product allows.
Reconciliation Types We Build For
Bank reconciliation. Matching bank statement transactions against the cash book or general ledger entries that correspond to them — identifying matched pairs, flagging unmatched items on either side, and tracking the timing differences between bank value date and book posting date that produce temporary reconciling items. For organisations with high bank transaction volumes — multiple accounts, multiple currencies, high daily transaction counts — automated bank reconciliation matching reduces the time required from hours to minutes and eliminates the matching errors that manual bank reconciliation produces.
Bank reconciliation for businesses with complex bank structures — multiple accounts across multiple banks, multi-currency accounts, notional pooling arrangements — requires matching logic that handles the account structure correctly, aggregating positions across accounts where the reconciliation is performed at the pool level and reconciling individually where it is performed at the account level.
Payment processor reconciliation. Matching payment processor settlement records — Stripe, Mollie, Adyen, PayPal — against the revenue and receivables records in the accounting system. Payment processor reconciliation has specific characteristics that make it harder than simple two-way matching: settlements are net of fees and may aggregate multiple transactions into a single settlement; refunds and chargebacks appear as separate records that need to be matched against the original transaction; settlement timing differs from transaction timing and the lag varies by processor and by payment method.
We build payment processor reconciliation logic that handles these characteristics correctly — matching gross transaction amounts to accounting records, reconciling fees separately, linking refunds and chargebacks to originating transactions, and handling the settlement aggregation that processors apply in ways that a simple transaction-by-transaction matching approach cannot.
Intercompany reconciliation. Matching intercompany receivables in one entity against intercompany payables in the counterpart entity — confirming that every intercompany transaction has been recorded on both sides, in the correct amounts, with consistent timing, and that the net intercompany position across the group eliminates correctly in consolidation.
Intercompany reconciliation at group scale — many entities, many intercompany relationships, transactions in multiple currencies — is one of the most time-consuming reconciliation processes in the close cycle when managed manually. Automated intercompany reconciliation that matches positions across entities, identifies mismatches, and routes discrepancies to the entities responsible for resolving them reduces close cycle time and produces the clean intercompany elimination that group consolidation requires.
Marketplace and channel reconciliation. Matching marketplace payouts — Bol.com settlements, Amazon disbursements — against the order and fee records they relate to. Marketplace reconciliation requires understanding the specific settlement model of each marketplace: the fee structure, the refund handling, the advertising spend deductions, and the settlement timing that determines which orders are included in each payout.
Sub-ledger to general ledger reconciliation. Matching the balances in sub-ledgers — accounts receivable, accounts payable, fixed assets, inventory — against the control accounts in the general ledger. Sub-ledger to general ledger reconciliation is a fundamental accounting control that confirms the integrity of the ledger structure and is typically required as part of the monthly close.
Ledger to ledger reconciliation. Matching account balances or transaction records between two general ledger instances — between the operational accounting system and the consolidation system, between the group accounting system and the statutory entity system, between the ERP and the management reporting database. Ledger to ledger reconciliation surfaces the differences that arise from different posting rules, different cut-off treatments, and different chart of accounts structures between systems.
Position and trade reconciliation. For trading businesses and financial institutions, matching trade records between internal systems and broker or counterparty confirmations — confirming that every trade is recorded consistently on both sides, that position calculations are consistent across systems, and that the mark-to-market valuation basis is applied consistently.
Matching Logic and Configuration
The matching engine is the core of a reconciliation system. Its effectiveness depends on the flexibility of the matching rules it supports and the accuracy with which those rules identify genuine matches without generating false positives.
Exact matching. The simplest and most reliable matching basis — records that share identical values on defined match keys are automatically matched. Transaction reference numbers, payment references, and invoice numbers are common exact match keys. Exact matching clears the straightforward cases quickly and leaves the harder cases for more sophisticated matching logic.
Tolerance-based matching. Records that match on reference keys but differ by a small amount — within a defined tolerance — are matched with the tolerance difference flagged as a reconciling item. Tolerance matching handles the rounding differences, foreign exchange translation differences, and minor fee deductions that prevent exact matching on amount while the underlying transaction is genuinely the same.
Composite matching. Matching on combinations of fields — date and amount, reference prefix and amount range, counterparty and amount and approximate date — that together identify a match even when no single field is a reliable match key. Composite matching handles the cases where transaction references are inconsistently applied and amount-based matching needs date and counterparty context to be reliable.
Aggregation matching. Matching a single record on one side against multiple records on the other — a bank settlement that aggregates multiple individual transactions, an intercompany payment that settles multiple invoices, a marketplace payout that covers multiple orders. Aggregation matching identifies the combination of records on one side that sums to the amount on the other, within defined tolerance, and matches them as a group.
Fuzzy and pattern matching. For reconciliations where reference data is inconsistently formatted — payment references with variable formatting, descriptions that contain the reference embedded in free text — pattern matching and fuzzy string matching extract the match key from the inconsistently formatted field and use it for matching.
Machine learning-assisted matching. For high-volume reconciliations with complex and variable matching patterns, machine learning models trained on historical matched data identify likely matches for items that rule-based matching does not resolve. ML-assisted matching handles the long tail of matching edge cases that are too varied to specify as explicit rules.
Exception Management
The matched items are not the interesting part of a reconciliation. The exceptions — the items that the matching engine could not match — are where the reconciliation work actually happens.
Exception classification. Unmatched items are classified by the likely reason for the mismatch — timing difference, missing transaction, duplicate entry, data quality issue, genuine discrepancy — based on the characteristics of the item and the pattern of similar exceptions in prior periods. Classification guides the investigation and resolution approach.
Ageing and escalation. Exceptions are aged from the date they first appeared. Exceptions that have been outstanding for more than a defined period are escalated — to a more senior reviewer, to the counterpart entity, to the business unit responsible for the underlying activity. Ageing and escalation prevent exceptions from remaining unresolved indefinitely.
Investigation workflow. Exceptions are investigated within the reconciliation system — notes, supporting documentation, and the resolution action are recorded against the exception rather than in email or separate spreadsheets. The investigation history is visible to reviewers and auditors without requiring reconstruction from email threads.
Bulk resolution. For exceptions that share a common resolution — a set of timing differences that will clear next period, a batch of items that result from a known system issue — bulk resolution applies the same resolution to all items in the set rather than requiring each to be resolved individually.
Resolution tracking. Resolved exceptions are tracked through to confirmation that the resolution was correct — a timing difference that resolved in the following period, a missing transaction that was subsequently posted, a duplicate that was reversed. Resolution tracking confirms that the exception was genuinely resolved rather than administratively closed.
Reporting and Audit
Reconciliation status reporting. The current status of every reconciliation — matched items, open exceptions, aged exceptions, resolved exceptions — in the aggregate view that gives the controller and the audit committee visibility across the full reconciliation landscape, and in the detail view that supports investigation of specific accounts or specific exception types.
Matching statistics. Auto-match rate, exception rate, average exception resolution time, and the trend in these metrics over time — showing whether the matching logic is improving, whether exception volumes are growing, and whether resolution times are within acceptable bounds.
Audit-ready documentation. Reconciliation documentation in the format that external auditors require — matched items with the match basis documented, open exceptions with the age, the investigation notes, and the expected resolution, and the reconciliation sign-off chain that confirms the reconciliation was reviewed and approved. Audit-ready documentation is produced automatically from the reconciliation system rather than assembled manually at year-end.
Regulatory reporting support. For financial institutions and regulated businesses, reconciliation status reporting in the formats required by regulatory submissions — confirmation that specific accounts are reconciled, documentation of the reconciliation methodology, and evidence of the controls applied to the reconciliation process.
Integration Points
Banking. Bank statement data via direct bank API integration — PSD2 open banking APIs, direct bank connectivity — and CAMT file processing for organisations whose banks provide SWIFT statement files. Bank statement data is the primary input for bank reconciliation.
Exact Online. General ledger and cash book data from Exact Online as the accounting-side input for bank and payment processor reconciliation. Journal entries for reconciling adjustments posted back to Exact Online via the API.
AFAS. Financial transaction data and sub-ledger balances from AFAS for organisations using AFAS as their primary financial system.
Twinfield. General ledger data from Twinfield for organisations using Twinfield for financial administration, including multi-entity data for intercompany reconciliation.
SAP. General ledger balances, sub-ledger data, and intercompany positions from SAP for organisations where SAP is the primary financial system.
Payment processors. Stripe, Mollie, Adyen, PayPal — settlement and transaction data via payment processor APIs for payment processor reconciliation.
Marketplaces. Bol.com, Amazon — payout and transaction data via marketplace APIs for marketplace reconciliation.
ERP and commerce systems. Order, invoice, and payment data from ERP and commerce systems as the business-side input for marketplace and payment processor reconciliation.
Technologies Used
- Rust / Axum — high-performance matching engine, large dataset processing, real-time matching for streaming transaction data
- C# / ASP.NET Core — reconciliation logic for complex business rules, ERP integration, Excel-based data import and export
- React / Next.js — reconciliation management interface, exception workflow, reporting dashboards
- TypeScript — type-safe frontend and API layer throughout
- SQL (PostgreSQL, MySQL) — reconciliation data storage, match history, exception tracking, audit trail
- Redis — matching job queuing, real-time exception status, processing coordination
- Exact Online / AFAS / Twinfield / SAP — accounting system integration for ledger data and journal posting
- Stripe / Mollie / Adyen — payment processor data integration
- Bol.com / Amazon APIs — marketplace settlement data integration
- PSD2 / CAMT — bank statement data integration
- OpenXML / EPPlus — Excel-based data import and reconciliation report export
The Cost of Unreconciled Items
Unreconciled items are not just an accounting tidiness problem. They represent uncertainty about the accuracy of the financial position — uncertainty that grows as unreconciled items age and their resolution becomes harder to establish. An unreconciled bank item from last month has a discoverable cause. An unreconciled bank item from last year may not. The discipline of timely reconciliation, enforced by software that surfaces exceptions immediately and tracks them to resolution, keeps the financial position confirmed rather than approximately known.
For businesses subject to audit, the reconciliation process and its documentation are examined directly. Auditors who find unreconciled items without documented investigation and resolution, or reconciliations that cannot be evidenced because the supporting documentation was maintained in spreadsheets that have since been overwritten, are auditors who raise findings. Reconciliation software that produces complete, auditable documentation as a byproduct of the reconciliation process eliminates this risk.
Reconciliation That Scales With Your Transaction Volume
Manual reconciliation does not scale. The time it requires grows with transaction volume, the errors it produces grow with complexity, and the documentation it produces is rarely audit-ready. Automated reconciliation scales with volume, improves in accuracy as matching rules are refined, and produces documentation that is audit-ready by construction.