A Balance Sheet Can Balance and Still Be Completely Wrong

Part 1 of Building Sales Scribe: What Accounting Software Teaches You About Correctness

Double-entry bookkeeping comes with a built-in check. Every transaction has two sides, debits must equal credits, and if the balance sheet doesn't balance, something has gone wrong.

It's a good check. It catches a lot. And it has a blind spot that's easy to forget: balancing proves the arithmetic, not the truth. Debits equal credits for any set of entries — including entries that are missing, entries that are inverted, and entries that were never there at all.

While building Sales Scribe, we kept running into figures that balanced perfectly and were wrong. Here are three of them, and what they taught us.

1. The year that wasn't there

Sales Scribe lets a business move across from another system part-way through its life. It brings in the opening position — what the business owned and owed on a particular date — and trades forward from there. We call that date the conversion date.

Now ask the software for a profit and loss report for the year before the conversion.

The ledger has no entries for that year. It was never on our system. But a report doesn't know the difference between "this business traded nothing" and "we weren't there to see it". A database query that adds up entries between two dates returns zero for both.

So the report showed a year of nil trading. It added up. The balance sheet for the same date showed nothing owned and nothing owed — and balanced, and passed its own internal check for being out of balance. The trial balance came out empty, with debits equal to credits. The aged debtors report said nobody owed the business anything, which reads like a business whose customers all pay on time.

Worst of all was the control-account reconciliation — the check an accountant runs first, to confirm the ledger agrees with itself. For any date before conversion, it reported every control account agreeing perfectly.

Every one of those answers was tidy, internally consistent, and false. None of them looked like an error. That's what made them dangerous.

The fix was to stop answering. For any period wholly before the conversion date, Sales Scribe now says the records don't cover it, rather than producing a number. Not a zero, and not a blank that looks like a zero: a plain statement that we weren't there.

Where the answer leaves the building, we're stricter still. A customer statement isn't a report you glance at — it's sent to a third party. So for a period we have no records of, the statement refuses outright rather than telling a customer they owed nothing. The same applies to anything stored permanently, and to VAT, because a nil VAT return is exactly the shape of something somebody files.

One more lesson came out of this. We first wired the rule into the reports we remembered. When we later went back and listed every report that accepts a date — found from the code rather than from memory — half of them didn't have it. So the rule now lives in one place, where a date range becomes a database query, rather than being copied into each report and relying on the next one to remember.

2. The import that could be read backwards

A business moving to Sales Scribe usually has its opening figures in a spreadsheet: a trial balance exported from its old system, with a column of debits and a column of credits.

Here's the trap. If the software reads the debit column as credits and the credit column as debits, every single balance comes out inverted. Assets become liabilities. Money owed to the business becomes money it owes.

And the trial balance still balances. Of course it does — swapping both columns preserves the equality exactly. Every downstream check that relies on debits equalling credits passes. There is nothing, anywhere later in the system, that can tell the correct import from the backwards one.

We proved this deliberately: the same file, imported with the columns read both ways, produces two positions that are exact mirror images of each other. Both balance.

So there's precisely one moment when the error can be caught — when a person is looking at the columns. Sales Scribe now shows the columns it has recognised, with a preview of the data, and asks the user to confirm the mapping before anything is imported. Recognising the columns automatically is a convenience. The confirmation is the guarantee.

For the same reason, we refuse a trial balance with a single signed column of figures. A single column doesn't say which way it means its signs, and the two readings are mirror images: every balance inverts, and it still balances.

3. Last year's overdraft

Accounts show two years side by side — this year, and last year for comparison.

Consider a bank account that was overdrawn by £3,000 last year and is £5,000 in funds this year. This year it's an asset. Last year it was a liability: the business owed the bank.

A simple way to build the comparison is to decide where each account belongs based on this year, and then show last year's figure beside it. That puts the bank account under assets in both years, with last year reading minus £3,000.

The balance sheet still balances. The total is right. But last year's assets and last year's liabilities are both understated by £3,000, because a debt has been presented as a negative asset. An accountant would show last year's overdraft as a liability, under the heading that applied last year.

So Sales Scribe classifies each year's figures on their own. The account appears on two lines — cash at bank this year, bank overdraft last year — each showing a dash in the year it doesn't belong. We tested the simpler version to be sure of the failure, and it produced exactly the misstatement: total assets of minus £3,000, with the statement balancing perfectly.

This isn't an edge case. Beyond bank accounts, a director's loan account regularly swings between the director owing the company and the company owing the director, and VAT can be owed or due back. These are among the figures an accountant looks at most closely.

What the three have in common

In each case, the system's own checks approved a wrong answer. Not because the checks were broken, but because they were answering a narrower question than the one that mattered. "Do debits equal credits?" is not the same question as "is this true?"

What we took from it:

Absence is not zero. When the data isn't there, say so. Don't let a query turn "we don't know" into a confident nil.

Some errors can only be caught at one moment. If a mistake will be invisible afterwards, the only defence is to stop and ask while a person can still see it.

Present each figure on its own terms. A number borrowed from a different context — this year's heading applied to last year's balance — can be arithmetically fine and still misleading.

Check against something independent. A figure checked only against itself will always agree. The control-account reconciliation is valuable precisely because it compares the ledger with the individual documents behind it — two separate records of the same money.

Balancing matters. It's just the first question, not the last one.