How to Reconcile Bank Feeds Without Guesswork
A bank feed is not a general ledger. It is an external record of cash movement, delivered with incomplete descriptions, inconsistent posting dates, and occasional duplicates. If a processor settlement lands for $9,842.16, the feed proves that cash arrived. It does not, by itself, prove which sales, fees, refunds, and timing differences created that amount.
That distinction is the foundation of how to reconcile bank feeds correctly. The objective is not to clear a screen full of transactions. It is to establish a repeatable, evidence-backed link between each bank movement and the accounting entries that explain it - until the cleared bank balance and ledger balance reconcile to $0.00.
Start with a controlled opening balance
Reconciliation begins before the first new transaction is categorized. Confirm the opening balance in the ledger agrees with the bank statement ending balance from the prior completed period. If it does not, do not force the difference into an expense account or an opening-balance adjustment without evidence.
An incorrect opening balance contaminates every reconciliation that follows. The apparent mismatch may be a previously uncleared transaction, a duplicate import, a bank account that was merged incorrectly, or a journal entry posted directly to cash. Identify the original cause, document the correction, and preserve the adjustment trail.
For businesses with several operating accounts, savings accounts, credit cards, and loan accounts, reconcile each account independently. Transfers should then connect the two sides of the movement. A $25,000 transfer from operating cash to payroll cash is not income in one account and an expense in the other. It is one transfer with two matched entries.
How to reconcile bank feeds using transaction evidence
A durable workflow moves from ingestion to matching, classification, review, and lock. Each stage has a different job.
First, ingest transactions without rewriting the source record. Retain the bank-provided amount, posted date, description, account identifier, and a stable transaction ID where available. Normalization can make descriptions easier to read, but the original row remains the evidence.
Next, identify whether the transaction has an existing accounting counterpart. The strongest match is not simply the closest date and amount. It considers the transaction type, payment reference, source account, counterparty, expected settlement timing, and whether the proposed match would violate accounting logic.
A practical matching hierarchy looks like this:
| Priority | Match type | Example | | --- | --- | --- | | 1 | Exact one-to-one | A $1,250 ACH vendor payment matches an approved bill payment. | | 2 | Transfer pair | A transfer out of operating cash matches a transfer into payroll cash. | | 3 | Grouped settlement | One processor deposit matches multiple sales, refunds, and fees. | | 4 | Split transaction | A loan payment separates principal reduction from interest expense. | | 5 | Review exception | An unfamiliar debit remains unmatched until supported by evidence. |
This order matters. Categorizing first and matching later often creates duplicate revenue, duplicate expenses, or cash balances that look right only because the error has been buried in a generic account.
Match settlements to their components
Processor settlements are a common source of false confidence. A payment processor may deposit net cash two or three days after customer charges, while deducting fees, reserves, chargebacks, or refunds. Booking the entire deposit as revenue makes the bank reconciliation appear clean but distorts both the income statement and cash-flow analysis.
Instead, construct the settlement from its components. For example, $10,000 of customer payments less $300 of refunds and $157.84 of processing fees produces a $9,542.16 net deposit. The deposit should match the bank feed, while the gross sales, refunds, and fees remain separately visible in the ledger.
The same principle applies to payroll. The bank feed may show a single payroll debit, while the accounting record needs wages, employer taxes, employee withholdings, benefits, and payroll liabilities. Cash is one movement. Financial truth may require several entries.
Use rules for repetition, not for uncertainty
Rules are valuable when they are deterministic and replayable. A recurring bank service fee from the same financial institution, a monthly software subscription, or a known loan debit can be classified consistently when the conditions are explicit.
A reliable rule specifies what it sees and what it does. It might apply only when the bank account is operating cash, the description contains a defined merchant identifier, the amount falls within an expected range, and no existing match is present. It then assigns a specific account, tax treatment, and counterparty.
Avoid broad rules such as “anything containing ACH goes to payroll” or “all deposits are sales.” Those rules may process quickly, but they convert ambiguity into silent ledger errors. A bank feed description is often a weak signal, particularly for ACH activity, payment facilitators, and wire transfers.
Rules should also be versioned. If a rule changes in July, you need to know whether it should apply only to future transactions or whether prior periods should be replayed. Deterministic systems make that decision visible: the same source rows and the same rule version produce the same accounting result every time.
Reconcile timing, not just totals
A bank balance is a point-in-time fact. The ledger must explain that fact while recognizing timing differences correctly. Outstanding checks, deposits in transit, card transactions pending settlement, and month-end processor batches can create legitimate differences between book activity and bank activity.
The key is to distinguish a documented timing difference from an unexplained exception. A check issued on June 29 that clears July 3 may be validly outstanding at June close. A $4,600 debit with no invoice, approval, or counterparty evidence is not a timing difference. It is an exception requiring investigation.
Use a reconciliation schedule that makes this visible:
| Reconciliation item | Treatment | | --- | --- | | Bank statement ending balance | Starting external cash balance | | Plus deposits in transit | Recorded receipts not yet cleared by the bank | | Less outstanding payments | Recorded disbursements not yet cleared by the bank | | Adjusted bank balance | Must equal the reconciled ledger cash balance |
For day-level cash forecasting, this discipline becomes operational rather than historical. Expected invoice collections should not be treated as bank cash until they settle. Approved bills may affect a forward cash forecast before they clear, but they should remain distinct from cleared bank movements. Mixing these states produces a forecast that is neither a cash view nor an accounting view.
Investigate exceptions with a defined queue
Every unmatched transaction needs a disposition. Do not let exceptions accumulate until month-end, when context has faded and close pressure encourages guesswork. Review them on a defined cadence, ideally daily for high-volume accounts and at least weekly for lower-volume accounts.
The exception queue should show the source transaction, suggested matches if any, current accounting treatment, owner, age, and supporting evidence. It should also separate transactions that are merely pending from those that require a decision.
Common exceptions include duplicate feed rows, reversed ACH payments, bank fees netted from deposits, owner contributions, intercompany transfers, loan proceeds, merchant disputes, and transactions booked to the wrong cash account. Each has a different accounting treatment. Treating all unmatched items as miscellaneous expense is fast, but it destroys provenance and makes later analysis unreliable.
When a correction is necessary, correct the underlying entry rather than creating a compensating plug. A clean audit trail should answer three questions: what changed, why it changed, and which source evidence supports the change.
Close only when the reconciliation can be replayed
A completed reconciliation is more than a green status indicator. It is a controlled state in which the bank statement balance, cleared ledger balance, and documented reconciling items agree. Once the period is reviewed, lock it or require explicit approval for changes.
That control does not mean prior periods can never change. It means changes are intentional. If a late bank correction or an accounting error requires reopening a closed month, the system should retain the original state, record the adjustment, and show the impact on the income statement, balance sheet, and cash-flow view.
This is where a unified system such as Shekl is designed to help: bank rows, accounting rules, reconciliations, and forward cash projections operate from the same transaction-level evidence. Every number traces back to its rows, while deterministic rules ensure that a replay does not produce a different answer because a model inferred a new one.
Keep the bank feed in its proper role
Bank feeds are one of the most useful inputs in the finance stack because they show what actually cleared. But they are not a substitute for bills, invoices, settlement reports, payroll records, or approval workflows. Their value comes from connecting those records to confirmed cash movement with disciplined matching and review.
The useful question is not, “Have all bank transactions been categorized?” It is, “Can every cleared dollar be explained, matched, and replayed without judgment calls?” When the answer is yes, your cash balance becomes a reliable operating fact - and a stronger base for every forecast and decision that follows.