Bank Reconciliation: Matching Your Statement to the Ledger

A bank reconciliation is the one your bookkeeper, your accountant, and eventually your bank all agree matters: cash in the bank against cash on your books. It sounds like it should always match. It almost never does on the day you check it, and that's fine, as long as you know why.

The mismatch is never random. It's a short, repeatable list: money the bank hasn't processed yet, money it charged that you haven't recorded, and occasionally a real error. Once you know which of those you're looking at, closing the gap takes minutes, not an afternoon.

This covers what causes each kind of difference, how to trace one when the two sides won't balance, a worked bank reconciliation statement with real numbers, and the part that trips up almost everyone now: reconciling a Stripe or PayPal payout, where gross and net are two different figures wearing the same transaction. For the broader process across every account, not just the bank, see how to reconcile accounts.

What causes a bank reconciliation gap

Six things account for almost every gap between a bank statement and a ledger. Three are timing: money already in one record but not yet the other. Three are information: something the bank knows that hasn't reached your books yet. None of them mean anyone made a mistake, though the sixth possibility, a genuine error, is exactly why you check.

How to find an out-of-balance reconciliation, step by step

Most of the time the two sides won't match on the first pass, and that's normal, not a red flag. Work through the differences in order rather than guessing, and the gap almost always resolves to one of the six causes above, or occasionally something that needs fixing for real.

1. Start from the bank's ending balance. It's the fact; your ledger is the thing you're checking against it, not the other way around.
2. Match every transaction you can. Tick off each deposit, withdrawal and transfer that appears identically on both the statement and the ledger.
3. List what the bank hasn't processed yet. Deposits in transit and outstanding checks are already in your books; give them their own line.
4. List what your ledger is missing. Bank fees, interest, NSF returns and standing orders show up on the statement before anyone logs them.
5. Recalculate both adjusted balances. Add and subtract until the adjusted bank balance and the adjusted book balance land on one figure.
6. Look for a duplicate or a transposed amount. A gap that survives every known adjustment is a real entry error, not a rounding issue.
7. Post the missing entries and file the worksheet. The fees, interest and NSF items need journal entries; keep the reconciliation with the statement it explains.

Steps three and four are where the causes above actually get used: they're the sort into timing versus information that turns "the numbers don't match" into a list of adjustments anyone can check, line by line.

A worked bank reconciliation

Here's a full bank reconciliation carried through with real dollar figures: a deposit in transit, an outstanding check, and four separate book-side adjustments, so you can see how each cause above actually lands in the arithmetic. Redo it against your own statement and it works the same way.

Both sides land on $63,555.00. The bank's balance was never wrong and neither was the ledger's; each was missing information the other side already had. The deposit in transit and the outstanding check are timing, they'll clear within days. The interest, the fee, the NSF item and the standing order are entries someone still has to book.

Reconciling payment processors: Stripe, PayPal and the gross-vs-net trap

A bank reconciliation used to mean cash and checks. Now the deposit line on most statements is a lump payout from Stripe, PayPal or a similar processor, and that single line represents dozens of underlying sales, each with a fee taken out before it reaches the bank. This step, sometimes called payment reconciliation, is where gross and net trip up most finance teams, whether the sales sit in a point-of-sale system, an e-commerce cart, or invoices paid through a checkout link.

Your invoicing or point-of-sale system recorded the full sale price, the gross amount. The processor takes its fee before sending anything to your bank, so what actually lands is the net amount, usually days later, batched with other transactions from the same payout cycle. Book the payout as one deposit equal to sales and the fees quietly vanish from your books instead of showing up as an expense.

The fix is booking the sale at gross when it happens, recording the processor's fee as its own expense line, and matching the payout, not the sale, to the bank deposit. We've built this exact matching logic before; see our document processing work for how automated matching handles high-volume, exception-based reconciliation like this.

Why processor payouts throw the count off

Two things make processor payouts harder to match than a straightforward check. The payout lands later than the sale, and it lands smaller than the sale. Both are documented, not guesswork, and knowing the actual numbers keeps you from treating a normal delay as a missing deposit.

A third factor compounds the first two: payout frequency. Daily payouts mean small, frequent lines that are easier to match one at a time. Weekly or manual payouts mean one large deposit covering a week of sales, which is harder to trace back to individual invoices if something in the batch looks wrong. Check your processor's payout schedule before assuming a gap is an error.

Stripe's standard settlement timing for US accounts is 2 business days from when a charge is captured to when the funds become available for payout, according to Stripe's own payout documentation (2026), though a brand-new account waits longer for its first payout, typically 7 to 14 days after the first payment. PayPal's standard transfer from your PayPal balance to your bank account takes 1 to 3 business days, per PayPal's help center (2026).

The split above is illustrative, not a published benchmark, but it matches the shape most finance teams describe: timing is still the biggest slice, processor payouts are now a close second, and genuine errors, the ones actually worth worrying about, are the smallest part of the pile.

Keeping the reconciliation from breaking every month

Most bank reconciliation software already automates the transaction matching. What it doesn't do on its own is post the missing entries or chase a standing order nobody logged, and that's usually still a person checking the same list, one month after the next.

A reconciliation that balances once and then breaks again next month is usually the same handful of habits repeating: nobody logs the standing order until reconciliation day, or the person who processes payments is also the one signing off on the reconciliation. None of that is complicated to fix. It just has to happen, every month, on schedule.

• Post the standing order and processor fee the same week they clear, not on reconciliation day. A stale bank fee is the single most common leftover item.
• Separate who processes payments from who reconciles them. One person doing both is how errors sit unnoticed for months.
• Reconcile the payout, not the sale. Match the bank deposit to what the processor actually sent, then reconcile gross sales to fees separately.
• Chase a recurring unexplained item, don't re-explain it. The same $85 gap every month is a process problem wearing a reconciliation costume.

Standing orders and processor fees are recurring vendor-side payments in disguise, which is why the same discipline shows up in the accounts payable process: what keeps a bill from slipping is what keeps a bank fee from sitting unexplained for two months.

This is close to what the reconciliation agent we build actually does: match the payout to the invoices, flag what doesn't line up, chase the standing order that's still unbooked, and get the bank reconciliation done in days instead of dragging into next month's close.

Frequently asked questions

The bottom line

A bank reconciliation gap is never a mystery once you sort it into its six causes: three timing, three information, and, occasionally, a real error. The worked example above shows the whole thing landing on one figure from both directions, and that's the target every time, not just when the numbers happen to cooperate.

Payment processors made this harder, not because the math changed, but because gross, net and payout timing are all thrown into the same bank line now. If your team still traces the same NSF item or the same processor fee by hand every month, that's exactly the kind of matching-flag-chase work worth putting a number on, before it quietly adds another day or two to next month's close.