---
title: "Bank Reconciliation: Matching Your Statement to the Ledger"
description: "Bank reconciliation explained: what causes each gap, a worked example that balances exactly, and how to reconcile Stripe and PayPal payouts to the penny."
author: "Monty Ali"
published: 2026-08-14
updated: 2026-08-14
category: "Finance Ops"
canonical: https://gitspark.com/blog/bank-reconciliation
source: Gitspark, https://gitspark.com
---

# Bank Reconciliation: Matching Your Statement to the Ledger

Bank reconciliation explained: what causes each gap between your statement and your books, a worked example that balances exactly, and how to reconcile Stripe and PayPal payouts.

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](/blog/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.

| Cause | Which side is behind | What it means |
| --- | --- | --- |
| Deposits in transit | Bank | You've recorded the deposit; the bank hasn't cleared it yet |
| Outstanding checks | Bank | You've written the check; it hasn't been cashed or cleared |
| Bank service charges | Books | The bank deducted a fee your ledger hasn't recorded |
| NSF (returned) checks | Books | A customer's check bounced; the bank reversed the deposit |
| Interest earned | Books | The bank credited interest your ledger hasn't picked up |
| Standing orders / direct debits | Books | A recurring payment cleared the bank before anyone logged it |

> **INFO:** Deposits in transit and outstanding checks are timing differences: they'll clear on their own within a day or two. Bank fees, NSF items, interest and standing orders are information gaps: your ledger needs an entry it doesn't have yet.

## 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.

| Item | Amount |
| --- | --- |
| Bank statement balance | $62,140.00 |
| + Deposits in transit | $4,275.00 |
| − Outstanding checks | −$2,860.00 |
| **Adjusted bank balance** | **$63,555.00** |
| Book balance (per ledger) | $64,140.00 |
| + Interest earned | $60.00 |
| − Bank service charge | −$85.00 |
| − NSF check returned | −$410.00 |
| − Standing order not yet recorded | −$150.00 |
| **Adjusted book balance** | **$63,555.00** |

![A bank statement marked up with pen check-marks and sticky notes flagging outstanding items, next to a calculator](https://images.gitspark.com/blog/content/bank-reconciliation-1786730719010.jpg)

*Every check mark on the statement is a transaction that matched. What's left is the reconciliation.*

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.

> **TIP:** Reconcile from the bank statement toward the books, not the other way around. The bank's record of what actually cleared is the fact; your ledger is the thing being checked against it.

## 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.

|  | Gross (what you sold) | Net (what hits the bank) |
| --- | --- | --- |
| Card sales, this batch | $10,000.00 | $10,000.00 |
| Processing fees | $0.00 | −$290.00 |
| Amount deposited | $10,000.00 | $9,710.00 |

> **WARN:** Don't reconcile a payout against the day's sales. Today's payout is a batch settling transactions from several days ago, so daily totals will never tie out. Match the payout to what the processor's own report says it sent, not to the calendar.

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](/work/document-processing) 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](https://docs.stripe.com/payouts) (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](https://www.paypal.com/us/cshelp/article/how-do-i-get-money-out-of-my-paypal-account-help394) (2026).

- **2 days** — Stripe settlement window
- **1-3 days** — PayPal payout to bank
- **6** — Common bank gap causes

**An illustrative breakdown of where a bank reconciliation gap comes from**

|  | Value |
| --- | --- |
| Timing (deposits/checks in transit) | 45% |
| Processor payout lag | 25% |
| Fees, interest, standing orders | 20% |
| Genuine errors | 10% |

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.

![A finance lead cross-checking a payment processor payout dashboard against a printed sales report](https://images.gitspark.com/blog/content/bank-reconciliation-1786730727940.jpg)

*The payout total, not the day's sales, is what should tie to the bank line.*

## 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](/blog/accounts-payable-process): what keeps a bill from slipping is what keeps a bank fee from sitting unexplained for two months.

**Price out the manual hours** See what tracing outstanding items and payout mismatches by hand actually costs your team each month. [Use the labor cost calculator](https://gitspark.com/tools/labor-cost-calculator)

This is close to what [the reconciliation agent we build](/#agents-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

### What is bank reconciliation?

Bank reconciliation is matching your bank statement to your own cash ledger and explaining any difference between the two. Most gaps are timing, deposits in transit or outstanding checks, or information the bank has that your books don't yet, like fees or interest. Both adjusted balances should land on the same figure when you're done.

### What causes a bank reconciliation to be out of balance?

Usually one of six things: deposits in transit, outstanding checks, bank service charges, NSF checks, interest earned, or an unrecorded standing order. If the gap survives every one of those adjustments, it's a real error, a duplicate entry or a misposted amount, and needs investigating rather than writing off.

### How do I reconcile a Stripe or PayPal payout?

Match the payout total to the bank deposit, not the day's sales. The payout is a net figure, sales minus processing fees, batched from transactions over the prior few days. Book gross sales and fees separately, then tie the net payout to what actually lands in the bank.

### What is a deposit in transit?

A deposit you've recorded in your books that the bank hasn't processed yet, usually because it was made near the end of the period. It's a timing difference, not an error, and it typically clears within a day or two once the bank's next statement is issued.

### What if my bank reconciliation still doesn't balance after every adjustment?

That's a real error, not a timing gap: a duplicate entry, a transposed amount, or an item posted to the wrong account. Recheck each transaction individually against the statement rather than re-running the totals; the mistake is almost always in one specific line, not the arithmetic.

### How often should I reconcile a bank account?

Monthly at minimum, matching your statement cycle. If transaction volume is high enough that a mismatch could sit for weeks before anyone notices, reconcile weekly instead. The longer an item goes unexplained, the harder it gets to trace back to its actual cause.

### Can bank reconciliation be automated?

Yes. Matching transactions and flagging what doesn't line up is rules-based work, well suited to automation, including matching processor payouts to the underlying sales. The judgment calls on genuine exceptions, like a disputed NSF item, still need a person; the matching itself usually doesn't.

### Is payment reconciliation the same as bank reconciliation?

Payment reconciliation is the version that involves a processor like Stripe or PayPal: matching a net payout back to the gross sales and fees that produced it. Bank reconciliation is the broader check, matching everything that hits the account, payouts included, against the bank statement. A payment reconciliation feeds into the bank reconciliation, not the other way around.

## 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.

**Worth automating, or not?** Bring your bank and processor reconciliation to a 30-minute call. If it's not worth building against, we'll say so. [Book a 30-min call](https://gitspark.com/#contact)