Journal Entry Testing for Independent Examiners: A 2026 Toolkit

Sometime this autumn, an examiner somewhere in England will take on a charity that was audited last year. Not because anything went wrong — because the rules moved. From 30 September 2026 the audit threshold for charities in England and Wales is expected to rise from £1 million of gross income to £1.5 million, and the government's own consultation expects around two thousand charities to step down from statutory audit to independent examination as a result.

That examiner inherits a set of books that a full audit team used to test with proper tooling — and a fee that will not stretch to the software the audit team used. This is the quiet squeeze in assurance work below the audit threshold: the standards expect real procedures, the fee expects Excel.

It is the same squeeze on the company side. The corporate audit exemption thresholds rose by roughly fifty per cent in April 2025, moving thousands of companies out of statutory audit. Plenty of those companies still want someone to look at the books properly — lenders ask, trustees ask, incoming investors ask. What they want is assurance-shaped work at review-engagement prices.

This post is about how to deliver that: what journal entry testing actually involves, why the tooling for it has historically been out of reach, and how we built the fourteen procedures of LedgerIQ's Examination Pack to close the gap.

What journal testing actually asks of you

Strip the standard back and the job is concrete. ISA 240 requires auditors to test journal entries on every engagement, regardless of assessed risk, because management override of controls is always possible. The guidance names the selection criteria that matter, and they are the same signals an experienced examiner scans for by instinct:

• Timing. Entries posted at period end, at weekends, or outside normal processing runs.
• Round sums and invented numbers. Figures that end too neatly, or whose digit patterns do not behave the way genuine transaction populations behave.
• Unusual account combinations. A journal touching a pairing of accounts that never appears together anywhere else in the year.
• Duplicates and reversals. The same amount posted twice, or posted and quietly reversed.
• Language. Narratives that say "adjustment", "correction", "reclass", "suspense".

None of this is conceptually hard. What makes it hard is arithmetic: a modest set of books contains three or four thousand postings a year. Scanning them by eye is not testing, it is sampling with extra steps. Real journal testing means running every criterion across every posting, and that is a computing job, not a judgement job. The judgement comes after — deciding which of the flagged items matter.

The tooling gap below the audit threshold

Audit firms solved the computing problem years ago. MindBridge, Inflo, CaseWare IDEA and TeamMate Analytics all run 100%-of-population testing, and they are genuinely good at it. They are also priced, licensed and onboarded for audit firms. If your practice signs off two hundred audits a year, the economics work. If you examine nine charities and review a dozen owner-managed companies, they do not — and the vendors know it, which is why none of them publish a price.

The frustrating part is that the underlying mathematics is not exotic. Benford's Law is a published distribution. Duplicate detection is careful grouping. Monetary unit sampling is thirty lines of arithmetic. What small practices have lacked is not the maths but the packaging: someone to run it over a general ledger export without an enterprise contract attached.

Fourteen procedures, one upload

That is what the Examination Pack in LedgerIQ is. You export the general ledger from whatever the client keeps their books in — Xero, QuickBooks, Sage, Pandle — and drop it in. Fourteen procedures run over every transaction, each presented as a numbered exhibit with a verdict stamp: clear, attention, or exceptions, with the flagged entries listed underneath. Four families of test do the work.

Digit forensics

The Benford exhibit tests the first two digits of every amount against the Benford distribution, using the Mean Absolute Deviation conformity bands from Mark Nigrini's Forensic Analytics — the standard reference for this work. Two companion exhibits go where frequency tests cannot: the summation test exposes a handful of abnormally large amounts hiding inside one digit group, and the round-number exhibit measures how much of the ledger ends in whole hundreds against what genuine billing patterns produce.

A word of honesty that belongs in every examiner's file note: digit nonconformity is a prompt, not a finding. Small populations, heavy standing charges and legitimate round-sum pricing all bend the curve. The exhibit says "ask why"; it never says "fraud".

Duplicates, outliers and sequences

Three exhibits handle the mechanical errors that turn into real money. Duplicate testing finds identical date-amount-counterparty postings, the same payment posted to two different accounts, and near-duplicates a few days apart. The Relative Size Factor test — largest amount per supplier divided by the second largest — is the classic decimal-slip detector: the £4,200 posted to a stationer whose next largest invoice is £45. Sequence-gap analysis reads document references and reports the invoice numbers that should exist but do not.

Timing, language and the once-only journal

The timing exhibit counts weekend-dated postings and measures how much of the year's value lands in the final three days of the period. The manual-journal exhibit isolates postings whose narrative carries adjustment language. And the rare-pairings exhibit reduces every double-entry journal to the account combinations it touches and flags the pairings that appear exactly once in the whole year with a profit-and-loss account on one side — the single most audit-shaped selection in the pack, and the one that most reliably surfaces the journal someone hoped nobody would look at.

The analytical review, made numerate

An independent examination leans on analytical procedures more than on detailed testing, and four exhibits give those procedures teeth. Recurring-payment detection builds a register of every counterparty paid on a rhythm — rent, insurance, subscriptions — and flags the expected payment that never arrived before year end, which is completeness evidence you can point at. Dependence analysis measures customer and supplier concentration properly, with a Herfindahl index rather than a hunch. Price-creep regression catches a supplier drifting upward inside a flat-looking category total. And a distribution-shift measure identifies accounts whose transaction profile changed character mid-year, which is the statistical version of the examiner's "this account feels different since March".

Sampling that stands up, and the working paper

Analytics narrow the field; the file still needs tested items. The pack's sampling desk draws a monetary unit sample — probability proportional to size, so every pound in the population has an equal chance of selection and large items are always in. The selection is seeded: run it again on the same file and you get the same sample, which matters the day someone reviews your file and asks how the sample was chosen.

Then the part that makes it billable. As you agree sampled items to evidence, you enter the audited values, and the pack projects the misstatement across the population — taint times sampling interval, the textbook method. One more click exports the whole examination as a print-ready working paper: the population profile, every procedure with its parameters and exceptions, the sample with an agreed-to-evidence column, and a prepared-by / reviewed-by sign-off block. It reads like the file the audit team would have left behind, because that is the point.

Why the ledger never leaving your laptop matters

Everything above computes in the browser, on your machine. The general ledger is parsed locally and is not uploaded to a server — there is no server that ever sees it. For most software this is a privacy nicety. For an examiner it is closer to a professional requirement, twice over.

Once for confidentiality: a charity's donor ledger or a company's full transaction history is exactly the data GDPR expects you to minimise the movement of, and "it never left my machine" is the shortest data-protection conversation you will ever have with a trustee board. And once for independence: no third party processes the client's records on your behalf, so there is no processor relationship to disclose and no sub-processor chain to diligence.

What it will not do

Three honest limits. First, it is analytics, not assurance: the pack produces evidence and a worklist, and the examination opinion remains entirely yours. Second, it needs transaction-level data — a summary export of period totals (Sage's summarised formats, for instance) carries no dates or lines to test, and the pack will tell you so rather than pretend. Third, the counterparty-based tests are only as sharp as the data: QuickBooks exports carry a proper counterparty column and test beautifully; Pandle and Sage narratives are attributed by text analysis, which is good but not perfect, and the pack marks inferred names so you know which is which.

Getting a ledger in

The workflow is deliberately boring. Export the general ledger for the period — the transaction-level report, not the summary — from Xero, QuickBooks, Sage or Pandle. Open LedgerIQ, upload it, open the Forensic tab, and the Examination Pack is the first entry. The same upload feeds the rest of LedgerIQ's forty-plus modules, several of which examiners lean on for the analytical-review side of the file: the Exceptions Register for anomaly review with materiality scaling, receivables roll-rates for the debtor conversation, and drift detection for the accounts that changed level mid-year.

LedgerIQ is available today and included on every IQ Suite plan — the plans are priced for small practices, not audit firms, and the examination work costs nothing beyond the plan itself. If the client's books live in IQ Books, our own bookkeeping software, the pack picks up real customer and supplier names on every posting and the journal-pairing test gets its sharpest data; but it was built for the world as it is, where the ledger arrives as a CSV from someone else's software.

The examiner taking on that stepped-down charity this autumn has a choice about what the file looks like: a spreadsheet with twenty ticked rows, or fourteen procedures over every posting, a defensible sample, and a working paper with their signature at the bottom. The second one used to be an enterprise purchase. It is not anymore.