Bank register vs general ledger: why your cash balance should tie to the register

Your cash balance should be read from a bank register that you have reconciled to the bank statement, not from whatever the general ledger's cash account happens to total. The register is a line-by-line record of what actually moved through one account, and each month you can prove it against a document the bank produced. The general ledger cash balance is the sum of everything anyone posted to that account, including manual journal entries, opening balances and misclassified transfers, and nothing outside your company checks it. When the two disagree, the reconciled register is right and the ledger has an error you need to find.

What's the difference between a bank register and the general ledger?

A bank register is the transaction list for a single bank or card account: date, payee, amount and running balance, the same shape as the statement. It's what a checkbook used to be.

The general ledger (GL) is the full double-entry record of the business, organized by account: cash, receivables, card liabilities, revenue, expenses, equity. Every transaction in a register should become a balanced entry in the GL, and the GL cash account for that bank should equal the register.

In a well-kept set of books they agree to the cent. The value of keeping them separate is that when they don't, the gap tells you something is wrong, and the register, being tied to an outside statement, tells you which side to trust.

How do one-legged transfers create phantom balances?

This is the most common and most expensive error, and it hides well.

A transfer between two of your own accounts has two legs. Paying a credit card from checking should reduce cash and reduce the card liability. If the payment is recorded only on the bank side, and coded as an expense instead of a transfer, the card liability never comes down.

Worked example (hypothetical): a company puts about $4,000 of software and travel on its card each month. The card feed records each purchase as an expense and an increase in the card liability. Each month the company pays the card in full from checking, and the bank feed's rule codes the $4,000 payment to 'Credit card expense'.

After twelve months:

• Expenses are overstated by $48,000. The purchases were expensed when made, and the payments were expensed again.
• The card liability in the GL is $48,000, while the card issuer's statement says $0.
• Cash is correct, which is why nobody notices. The bank register ties perfectly.

The fix is to record each payment as a transfer: debit the card liability, credit cash. The 'Payment received, thank you' line on the card feed must then be matched to that same transfer rather than booked on its own; book it separately and you've created a different error, a phantom credit on the card.

The rule of thumb: never read a credit card balance off the GL until the card register has been reconciled to the card statement.

How do duplicate imports and stray journals distort cash?

Duplicate imports happen when a CSV is imported for a period the live feed already covered, or when a reconnected feed backfills transactions that were already there. Every duplicated withdrawal understates cash and overstates expenses; every duplicated deposit does the reverse.

Stray journal entries are manual entries posted directly to the GL cash account: an opening balance entered twice, a year-end adjustment that should have gone to a different account, or a transfer between accounts entered as a journal and then imported again from the feed. These change GL cash without appearing in any register, which is exactly why the register is the better source.

A quick check: compare each bank's GL balance to its register balance at month-end. Any difference is, by definition, a posting that didn't come from the bank.

What are timing differences, and why aren't they errors?

Your register and the bank statement can legitimately differ at month-end because of timing:

• Outstanding checks and payments: you've recorded them, but they haven't cleared the bank.
• Deposits in transit: a payout initiated on the 31st that lands on the 2nd.
• Bank-originated items you haven't recorded yet: fees, interest, returned payments.

Reconciliation exists to separate these legitimate timing differences from real errors. Timing differences clear next month by themselves; errors don't.

How do you do a month-end bank reconciliation? A worked example

Here's a hypothetical operating account at October 31:

• Bank statement ending balance: $48,250.00
• Register balance before reconciling: $47,483.00

Step 1: Adjust the bank balance for timing items.

• Subtract outstanding checks: #1042 for $1,800 and #1045 for $950, totalling $2,750.
• Add the deposit in transit: a $3,200 processor payout initiated October 31 that arrived November 2.
• Adjusted bank balance: $48,250 − $2,750 + $3,200 = $48,700.00

Step 2: Tick off every register line against the statement. Working through October, you find three things that are in one record but not the other:

• A $1,240 software charge recorded twice, once from the feed and once from a CSV import. Delete the duplicate: +$1,240.
• A $35 wire fee on the statement that isn't in the register: −$35.
• $12 of interest on the statement that isn't in the register: +$12.

Step 3: Adjust the register. $47,483 + $1,240 − $35 + $12 = $48,700.00

Step 4: Confirm they match. Adjusted bank balance $48,700.00 equals adjusted register balance $48,700.00. The account is reconciled. Save the statement balance, the list of outstanding items and the adjustments with the reconciliation, so next month starts from a known point.

Step 5: Tie the GL to the register. Now look at the GL cash account for this bank. Suppose it shows $51,700.00, which is $3,000 more than the reconciled register. The register is proven against the bank, so the $3,000 is a GL-only posting. In this case it's a manual journal recording a $3,000 transfer from savings that was also imported from the bank feed. Reverse the journal and the GL equals the register.

Step 6: Repeat for every account, including cards and processors, and check that transfers between accounts net to zero: every 'out' leg has a matching 'in' leg in another account on or near the same date.

How often should you reconcile?

Monthly at minimum, to the statement, for every bank, card, loan and payment-processor account, before you rely on that month's financial statements. Many teams also do a lighter weekly check of register against live bank balance, which catches duplicates and missing lines while the list of candidates is short. The longer an error sits, the more entries pile up on top of it; a one-legged transfer from fourteen months ago is a much bigger job than one from last week.

Which warning signs suggest your GL cash is wrong?

• A credit card balance in your books that's higher than the card statement, often by a round multiple of your usual payment.
• Expenses that look high relative to what you actually spent.
• GL cash that differs from the bank for reasons nobody can name.
• A clearing or transfer account with a balance that keeps growing instead of returning to zero.
• Reconciliations marked complete with a small 'unexplained difference' carried forward month after month.

How does ClearBooks handle this?

ClearBooks treats each bank and card account's register as the authoritative record for cash and reconciles it against statement balances. The reconciliation and close tools are built around that model. For the wider list of errors this catches, see the 10 costliest bookkeeping mistakes, and for the weekly habit that keeps registers current, how to streamline bookkeeping.