Opening Balance vs Closing Balance Explained

Get those two numbers and the equation that connects them, and you can tell at a glance whether a statement holds together — or whether a transaction has gone missing somewhere in the middle.

What the opening balance actually is

The opening balance is the account's value at the first moment of the period the statement covers. On a monthly statement dated 1–31 March, it's whatever the balance was at the close of business on 28 February, carried into March untouched. You'll often see it labelled "balance brought forward", "opening balance", or simply "b/f" near the top of the first page, before the first dated transaction.

Two things are worth being precise about. First, the opening balance is not the balance on the day you happen to open the statement — it's the balance at the start of the period the document reports on. Second, it should match the previous statement's closing balance to the penny. March's opening balance is February's closing balance. If those two don't agree, something has gone wrong between periods, and every figure that follows inherits the error.

For business accounts, the opening balance is also the starting point when you set up an account in software like Xero, QuickBooks or Zoho Books. You enter the opening balance as the date you go live, and the running balance grows from there. Key it wrong and your books will be out by that amount forever, even if every transaction after it is perfect.

What the closing balance actually is

The closing balance is the account's value at the end of the period — the figure the bank prints last, after the final transaction has cleared. It's labelled "closing balance", "balance carried forward", or "c/f". This number then becomes the opening balance of the next statement, which is how an account's history chains together month after month with no gaps.

Here's the part people skip over: the closing balance isn't an independent figure the bank looks up separately. It's the result of the opening balance plus everything that happened during the period. If you took the opening balance and applied every credit and debit by hand, you'd land on the closing balance yourself. When you don't, a transaction is either missing, duplicated, or misread — and the closing balance is the first place that shows.

The equation that ties them together

There's a single identity sitting underneath every statement, and it's the whole reason these two figures matter together rather than separately:

Opening balance + money in − money out = closing balance.

That's it. Everything else is detail. The bank applies this rule line by line in the running-balance column — the value on the far right that updates after each transaction. The running balance is just the opening balance with each transaction folded in, one at a time, until the last row equals the closing balance. Think of opening and closing as the two ends of a thread, and the running balance as the thread itself, passing through every transaction in order.

Because the running balance recalculates after each line, it carries a quiet superpower: it can reveal a transaction you never even saw. Add up the visible debits and credits and the totals might look fine, yet a single dropped line still throws the closing balance out. The running balance is the only part of a statement that catches an entry that simply isn't there — there's no row to eyeball, so the gap only shows in the numbers that don't add up.

A worked example

Numbers make this concrete. Say an account opens the month at 1,000.00 — that's the opening balance, brought forward from last month's close. Four things happen during the period:

Now run the equation. Money in over the month is 600.00 + 150.00 = 750.00. Money out is 450.00 + 64.50 = 514.50. So: 1,000.00 + 750.00 − 514.50 = 1,235.50. That matches the closing balance the running-balance column lands on. The statement reconciles — the period is internally consistent and nothing's gone astray.

Now picture the 27 March refund being dropped when the statement is copied or extracted. The visible transactions still total cleanly among themselves, but your recomputed closing balance comes out at 1,085.50 against a printed 1,235.50 — a 150.00 gap. That gap is the missing refund announcing itself. You'd never spot it by scanning the rows, because the row isn't there to scan. The arithmetic is what flags it.

Why this matters when you convert a PDF statement

This is where the opening-versus-closing relationship stops being theory. When you convert a bank-statement PDF to Excel or CSV, the goal isn't just to copy the numbers out — it's to copy them out *correctly and completely*. A converter that loses one transaction, splits an amount across the wrong column, or fumbles a figure on a scanned page produces a spreadsheet that looks finished but doesn't add up.

Export Bank Statement runs that check for you. Every statement you convert is verified against its own opening and closing balances: the tool recomputes opening balance + transactions and confirms the result equals the printed closing balance. If it doesn't, the statement is flagged as not reconciling, so you find the missing or misread line before you import it — not three weeks later when your books won't balance. That reconciliation check is the part most converters skip entirely; they extract, and leave the verifying to you.

It works on PDFs from any bank, including scanned and photographed statements through OCR, and exports in the native bank-import CSV formats for Xero, QuickBooks and Zoho Books. To be straight about the workflow: the tool converts and verifies, then you import the CSV into your accounting software. It doesn't push transactions through a live bank-feed API — that's a different mechanism that needs partner certification. Convert, check the totals reconcile, import.

CTA: Convert a bank statement and check it reconciles — free to start, files deleted after processing.