A close that balances is not the same as a close that is right

First check, always, and it takes ten seconds. Open last month's finished file, take the closing balance of each account, and compare it to this month's opening balance. They should be identical to the penny.

When they are not, the cause is nearly always a backdated entry: someone posted or amended a transaction into a period you had already closed, and the prior month's file on your disk no longer matches the ledger. This is worth catching first because everything downstream inherits it. If the opening figure is wrong, every check you run afterwards passes against a wrong baseline, and you will spend the afternoon reconciling a difference that was already there when you started.

If you find a break, resolve it before touching anything else. A comparative that shows last month's figure differently from last month's own report is the fastest way to lose a client's confidence.

Before analysing an import, count it. The source system tells you how many transactions exist in the period. Your spreadsheet tells you how many rows arrived. Those two numbers should match, and you should check them for every single import: bank feed, card processor, payroll, invoicing, point of sale.

This catches a specific and common failure. Exports truncate. They hit a row cap, they time out partway, a date filter in the export screen quietly excluded the last day of the month, or someone downloaded page one of a paginated result. None of these announce themselves. The file opens, the columns look right, the totals look plausible, and it is short by 340 transactions that all happened to fall on the 31st.

Record the count you expected and the count you got, next to each other, in the working file. It is the cheapest audit trail you can leave for yourself.

Row counts catch a file that is too short. They also catch one that is too long, but not what got duplicated. Whenever a count runs high, or an export was re-run after a failure, check for repeats explicitly.

Duplicate on the combination that identifies a transaction, not on a single column. Date, amount, description and account together. A single-column check on amount alone flags every recurring subscription as a duplicate and buries the real finding in noise. The duplicate-finding walkthrough covers building the composite key.

The failure this catches is mundane and expensive. A download stalls, someone runs it again, and both files get pasted into the same tab. The ledger balances, because both copies are complete and internally consistent. The revenue is simply double.

This is the single most common silent error at month end.

Sort by date and look at both ends of the range. Every transaction should fall between the first and last day of the period. What you will find, more often than you expect, is a handful dated to the previous month, one or two dated to next year, and occasionally something dated 1900 or 1970, which is what an empty date cell becomes when a system fills a default.

Two distinct problems produce this. The first is genuine: transactions posted late, or an invoice raised in one period and dated to another. Those need a decision about which period they belong to, and the decision needs to be consistent with what you did last month. The second is technical: the date column is not a date at all. If your dates arrived from a CSV as text, or in a different regional order, sorting them puts 12/03 next to 12/11 and your period filter silently excludes half the month. Our guide on fixing dates in a spreadsheet covers diagnosing which of the two you have, and the tell is simple: if the column sorts alphabetically rather than chronologically, they are text.

The reason this error is so quiet is that a transaction excluded by a broken date filter does not appear anywhere. It is not a wrong number. It is a missing number, and nothing on the face of the report is short of anything.

Check the minimum value of every amount column. If a column that must contain refunds has no negative values, the sign convention has been lost somewhere in the import, and every refund in the period has been added to revenue rather than subtracted from it.

This is worse than a normal error because it moves the total by twice the amount. A £500 refund recorded as +£500 rather than -£500 overstates the month by £1,000. It also passes every reconciliation that only checks totals against a system that made the same mistake.

Different sources use opposite conventions, and the two that most often disagree are your payment processor and your accounting system. Decide which convention your working file uses, write it down at the top of the sheet, and confirm each import against it. Then check that credit notes, chargebacks and processor fees follow the same rule, since fees in particular are frequently delivered as positive numbers that need subtracting. Getting this wrong distorts gross margin more than almost any other single error, because it hits both sides of the calculation.

Now do the reconciliations proper: bank, accounts receivable, accounts payable, payroll clearing, VAT or sales tax control, and any suspense account.

Two habits matter here more than the mechanics. First, a control account should reconcile to a supporting listing, not to itself. Accounts receivable should equal the sum of the open invoices on the aged debtors report, item by item. A control account balance you have only checked against its own ledger has not been reconciled at all.

Second, look at the age of the reconciling items rather than only their total. A bank reconciliation showing a £2,000 difference made up of three cheques written last week is fine. The same £2,000 made up of eleven items, four of them more than six months old, is not a timing difference. It is a set of errors that have been carried forward because the net figure looked acceptable each month. Any item older than about ninety days needs an explanation, not a roll-forward. If reading a statement line by line is where the time goes, the bank statement tool will do the extraction and matching part.

List the numbers in your close that were typed rather than imported: accruals, prepayments, depreciation, an owner's adjustment, a stock valuation. For each one, search the workbook for that value and confirm it appears where you intended and nowhere else.

The error here is double-counting an adjustment. A prepayment gets entered as a journal in the accounting system and also as a manual line in the working spreadsheet, because two people, or the same person on two days, each thought it was outstanding. Both entries are correct in isolation. Together they are wrong, and the workbook still balances.

While you are there, check that any hard-coded number has not overwritten a formula. A typed value sitting in a column of calculations is the most durable error in bookkeeping, because it survives every recalculation and never changes when the inputs do.

Last, and it feels too trivial to write down until it costs you a quarter. Clear every filter, unhide every row and column, and re-read the totals.

A filtered range shows a total for what is visible. Some functions respect the filter and some ignore it, so two cells on the same sheet can legitimately disagree, and the one you copied is whichever you happened to click. The same applies to hidden rows, and to a total written to cover rows 2 to 400 in a table that has since grown to 460. We wrote up the full set of causes in why two people get different totals from the same spreadsheet.

Read the final totals from a clean, unfiltered sheet, and check the row count of the range your total covers against the row count of the data. If those two numbers agree, and every check above passed, the close is not just balanced. It is defensible.

None of this catches a transaction that was correctly imported, correctly dated, correctly signed and posted to the wrong account. Coding errors are invisible to structural checks, because the file is structurally perfect. They are found by reading the account and asking why a line moved against the same month last year. Nor does any of it validate a source system that was wrong before the export. These checks confirm that what happened in the source arrived intact in your file. Whether the source was right is a separate question.

Uploading the month's exports produces the row counts against source, the out-of-period dates, the duplicate candidates and the sign anomalies as a single checked report, without prompting. Every figure is computed twice by two independent engines, and anything the two disagree about is dropped rather than published. The accounting and bookkeeping use case shows what a month's close looks like through it.