Every controller who has done bank reconciliation manually has encountered the same frustration: the bank feed and the general ledger describe the same financial events in completely different ways. The entry that the bank records as "ACH DEBIT PAYLOCITY 052606 TRN:892411" has no obvious relationship to the journal entry the payroll run created in the accounting software. Yet they are the same transaction.
This article explains the specific technical and institutional reasons why this gap exists -- not to assign blame, but because understanding the root causes of the mismatch is necessary to understanding what any reconciliation process (manual or automated) is actually doing.
How Banks Format Transaction Descriptions
Banks generate transaction descriptions for operational purposes, not for accounting clarity. The description in a bank feed is produced by the payment messaging system that processed the transaction -- typically ACH, wire, or card network messaging standards -- and it carries the information that payment systems use to route, identify, and audit transactions.
An ACH transaction description, for example, includes the company entry description (a short text field set by the originating bank or payment processor), a transaction ID, and possibly a trace number. None of these fields were designed to help an accountant match the transaction to a general ledger entry. They were designed to let the bank's operations team identify and investigate the payment if there is a question or dispute.
The result is that bank descriptions often include: abbreviated company names that differ from the vendor name in the accounting software; transaction IDs that are internal to the payment processor and invisible to the accounting software; batch identifiers that aggregate multiple underlying transactions; and codes that encode routing information in a format meaningful only to the sending bank.
Different banks format the same type of transaction differently. A payroll ACH from one bank might appear as "PAYROLL ACH PAYLOCITY 052606" while another bank formats the same transaction as "ACH CR PAYROLL 089040 PAYLOCITY INC." Both refer to the same payroll processor and the same payroll run, but the string comparison between them and the accounting software description will fail.
How General Ledgers Format Transaction Records
General ledger entries are formatted by the accounting software's data model and the conventions of the team that operates it. A payroll journal entry in the accounting software typically includes: a reference number tied to the payroll run (generated by the payroll processor), a description written by the person who booked the entry, the date the entry was created in the accounting system, and the accounts and amounts that reflect the gross-to-net breakdown.
Several aspects of this format differ systematically from the bank feed. First, the date: the payroll journal entry is booked on the payroll processing date, which may be two business days before the bank settlement date. Second, the amount: the journal entry records gross payroll (before employee deductions), while the bank feed records the net settlement wire (after all deductions). Third, the description: the journal entry description is written in the accounting team's internal shorthand, which may have no relationship to the bank's description format.
These are not errors. They are correct representations of the same event from two different institutional perspectives. The payroll processor processes gross payroll on one date; the bank settles the net wire on another date. Both records are accurate. They simply describe different aspects of the same underlying transaction in formats optimized for different purposes.
The Timing Gap
Settlement timing is one of the most consistent sources of reconciliation exceptions. Different payment types have different settlement timelines:
- ACH debits: typically T+1 to T+2 from the transaction initiation date
- Wire transfers: same-day or next-day depending on cutoff times
- Card transactions: typically T+1 for posting, but may appear in the feed on the authorization date
- Check payments: T+2 to T+5 depending on when the check is presented
The accounting software entry is typically created on the transaction date -- when the invoice was paid, when payroll was processed, when the expense report was submitted. The bank feed entry appears on the settlement date, which may be 1 to 5 business days later.
This means that for any given day's bank statement, some entries correspond to transactions that were recorded in the accounting system on prior days, and some transactions recorded in the accounting system on that day will not appear in the bank feed until future days. A rigid matching algorithm that requires bank date to equal GL entry date will fail on a significant percentage of correct matches.
The Aggregation Problem
Many payment types aggregate multiple underlying transactions into a single bank line. Payroll is the most common example: the payroll processor sends one net settlement wire representing hundreds of individual employee paychecks. The bank feed shows one entry; the general ledger might have 12 entries across payroll expense accounts, tax liability accounts, and benefits accounts.
Other common aggregations: merchant card settlement batches (all card transactions from a given day are settled as a single wire), virtual card programs (multiple vendor payments are settled in daily batches), and multi-currency conversion settlements (multiple foreign currency transactions are converted and settled as a single domestic wire).
Matching aggregated bank entries to disaggregated ledger entries requires a one-to-many or many-to-one matching logic that manual processes handle slowly and inconsistently. The reconciler has to know that a single bank line corresponds to a set of ledger entries that, when summed, equal the bank line amount -- and has to identify which entries are in that set.
How Automated Reconciliation Bridges the Gap
Automated reconciliation systems bridge the bank-to-ledger gap by applying matching logic that accounts for all of the structural differences described above:
Fuzzy description matching: Rather than requiring exact string equality between bank description and ledger description, automated systems apply normalization (remove transaction IDs and batch codes), entity extraction (identify the vendor name across different formatting conventions), and learned matching (associate bank description patterns with ledger description patterns based on historical confirmed matches).
Date tolerance: Automated matching uses a date window (typically 3 to 5 business days) rather than exact date equality, accommodating settlement timing differences across payment types.
One-to-many matching: Automated systems can match a single bank entry to a set of ledger entries where the amounts sum to the bank entry total, handling payroll aggregation, card batch settlements, and similar patterns.
Pattern learning: Automated systems that process a company's transactions over multiple months learn the specific mapping conventions between that company's bank descriptions and their ledger counterparts. The match rate improves over time as the system learns vendor-specific patterns.
The gap between bank feed and general ledger is not a problem that will be solved by better accounting software or better bank feed formatting -- both systems are optimized for their own purposes, and those purposes will continue to differ. The reconciliation layer that bridges them is a permanent part of the close process. The question is whether that layer is implemented as a manual human effort or as an automated matching system with a human exception queue.
