Ledger Reconciliation: Why GL Balances Drift and How Finance Teams Correct Them

Ledger reconciliation is the process of comparing internal general ledger account balances against external data sources, including bank statements, PSP settlement reports, processor files, and subledger records, to identify and resolve discrepancies before the financial close. The core challenge is that GL entries and external payment data rarely align without adjustment. Timing differences, posting errors, account mapping failures, and payment fragmentation cause ledger balances to drift from the external records they are supposed to reflect.

For fintechs and payment companies operating across multiple payment processors, banks, and internal systems, ledger reconciliation is not a periodic cleanup task. It is a continuous control that determines whether the financial statements produced at period-end accurately represent the underlying payment activity.

Why ledger balances drift from external sources

Ledger reconciliation breaks arise from four structural causes: timing differences, posting errors, payment fragmentation, and duplicate or unrecorded entries. Each produces a different type of discrepancy between the general ledger and the external records it is supposed to reflect.

• Timing differences. A payment processed and recorded internally on one date may not settle at the bank or processor until one to three business days later. The internal ledger reflects the transaction; the external source does not yet confirm it. Until settlement appears in the bank statement or processor report, the ledger balance and the external balance disagree on the same set of transactions.
• Posting errors. When transactions are posted to the wrong GL account, recorded with an incorrect amount, or entered with reversed debits and credits, the ledger balance diverges from the correct figure without any corresponding change in the external source. Posting errors are particularly difficult to detect manually because the error is internal and does not produce an obvious external mismatch until a reconciliation is performed against the correct external record.
• Payment fragmentation. Each additional payment method a fintech or payment company operates introduces different settlement cycles, reconciliation workflows, chargeback procedures, and exception handling requirements, and this complexity compounds as new payment rails multiply. McKinsey estimates 3.6 trillion transactions are processed annually across global payment systems, with fragmentation growing as processors and methods multiply. Each new source adds a new category of potential ledger drift that must be tracked and reconciled separately.
• Duplicate and unrecorded entries. Duplicate journal entries create inflated GL balances that surface only when ledger totals are compared against external records. Unrecorded transactions, such as bank fees, processor deductions, or FX conversion charges not automatically posted to the GL, produce the opposite problem: the external record shows a deduction that the ledger does not reflect.

How data mapping connects external payment data to GL account structures

The most operationally difficult part of ledger reconciliation is not identifying that a discrepancy exists. It is mapping external payment data to the correct GL account structure so that automated matching can operate accurately.

Payment processors deliver settlement files using their own reference identifiers: settlement IDs, transaction IDs, payout IDs, and batch references. The general ledger records entries using GL account codes, journal entry references, and chart of accounts categories. These two identifier schemes share no common key. Reconciliation software must apply account mapping rules that translate processor output formats into the GL account structure before any matching can begin.

A well-structured chart of accounts is foundational to automation, reporting accuracy, and the ability to map source-system data into ledger structures. For fintechs and payment companies, this means the chart of accounts must be designed with payment operations in mind: clearing accounts for in-transit settlements, suspense accounts for unidentified items, and separate GL accounts for processor fees, chargebacks, refunds, and rolling reserve movements.

Rexi ingests settlement reports and processor files from multiple payment sources and applies configurable account mapping rules to route each transaction type to the correct GL account before the Reconciler agent begins matching against internal ledger entries.

Dig deeper: Multi-Provider Payment Reconciliation

How double-entry discrepancies surface in ledger reconciliation

A general ledger operates on double-entry accounting principles: every transaction produces a debit to one account and a credit to another. Ledger reconciliation surfaces double-entry discrepancies when debit and credit postings for a payment event do not balance, when entries are posted to the wrong side of the ledger, or when one leg of a journal entry is recorded without the corresponding leg.

In payment operations, double-entry discrepancies most commonly arise from processor fee deductions. When a PSP settles a gross transaction amount and deducts its fees before depositing the net amount, the internal ledger must record both the gross revenue and the fee expense as separate entries. If the fee expense entry is not recorded, the GL shows a higher net balance than the bank account contains. Reconciling the bank statement against the GL then surfaces the discrepancy as an amount variance that cannot be resolved without the missing journal entry.

Chargeback reversals create a similar double-entry reconciliation problem. A chargeback reverses a previously settled transaction, requiring a debit to accounts receivable and a credit to the original revenue account. When only one leg of the reversal is posted, the GL balance drifts from the processor’s reported balance, and the discrepancy does not resolve until both legs of the journal entry are confirmed and the corrective entry is approved.

What automated ledger reconciliation enables for period-close and audit readiness

Finance teams spend increasing time reconciling transactions across fragmented ERP systems, banking portals, payment processors, and procurement tools, with cash visibility becoming delayed or incomplete when staff rely on manual interventions to bridge gaps between systems. Automated ledger reconciliation eliminates this manual bridging by continuously matching external payment data against GL entries and surfacing discrepancies as exceptions rather than allowing them to accumulate as unresolved ledger drift through the close period.

KPMG identifies reconciliation as a core internal control activity requiring defined control objectives, investigation and resolution processes, and documented authority for each control operator. Automated ledger reconciliation produces the documentation these requirements demand: every match decision, every exception investigation, and every approved journal entry is recorded with timestamps and ownership, giving finance teams the audit trail they need to demonstrate that reconciliation ran on schedule, exceptions were investigated within defined timeframes, and corrective entries were approved before the period was closed.

For a complete overview of the software that automates reconciliation across ledgers, processors, and banks, see payment reconciliation software for fintech and payment companies.

How Rexi handles ledger reconciliation

Rexi applies configurable account mapping rules to translate settlement IDs, processor transaction references, and payout identifiers from external payment sources into the corresponding GL account codes before matching begins. The Reconciler agent compares external payment data against internal ledger entries at the account level, classifying exceptions by type: timing difference, amount variance, or posting error. Unmatched items are surfaced by the Investigator agent with the source data and journal entry context needed to determine the correct resolution (corrective entry, timing hold, or missing posting), and the Categorizer routes each exception to the right reviewer by type. The Auditor agent logs every match decision and journal entry approval with timestamps and ownership, producing the period-close documentation that ICFR controls require.

Frequently Asked Questions