Automating audit workpapers and evidence

An audit is evidence collection at scale: pull a sample from the population, gather the documents behind each item, tie those figures back to the ledger, then assemble a workpaper a reviewer can sign. AI does the collecting, the extraction, and the tie-out, and it drafts the workpaper. It does not decide whether the item passed. That judgement stays with the auditor, and the trail has to show why.

Most of an auditor’s clock goes to the part before any judgement happens. Someone requests a document from the client, waits, receives a PDF that does not match the naming convention, extracts three numbers from it, keys them into a spreadsheet next to the ledger balance, and checks whether the difference is explained. Repeat forty times per control. The thinking is quick once the evidence is in front of you. Getting it in front of you is the expensive part, and it is where automation earns its place.

Sampling has to be reproducible before it is smart

The first temptation is to point a model at the population and let it choose the “risky” items. Resist it a little. An audit sample has to survive a reviewer asking why this invoice and not that one, and “the model scored it higher” is not an answer you can put in a workpaper on its own.

What works is a documented selection method with the model feeding it, not replacing it. Risk-weight the population using features you can name: vendor newness, amount relative to the account’s history, manual journal versus system-posted, edits after period close, round-number amounts, activity in the last days before quarter-end. Then draw the sample with a method you can defend.

• Fix the random seed so the same population and the same parameters always produce the same sample. A sample nobody can regenerate is not evidence.
• Keep monetary-unit or attribute sampling where the standard calls for it, and let the risk score decide the stratification rather than the selection itself.
• Record the population as of a point in time. If the ledger is still moving, snapshot it, hash the snapshot, and sample from the hash. Sampling from a live table means your evidence describes a population that no longer exists.

The point-in-time discipline is the same one that bites feature pipelines. If you re-run the selection a week later against a table that has absorbed late adjustments, you get a different sample and a reviewer who cannot reconcile your workpaper to anything. Freeze the population, then sample.

Evidence collection and extraction do the heavy lifting

Once an item is selected, the system requests and gathers its support: the invoice, the contract, the bank confirmation, the goods-receipt note, the approval email. This is the same extraction problem that shows up everywhere in finance operations, and it fails the same way. A total misread by one digit, a date in the wrong format, a counterparty name that three documents spell three ways.

Two things keep it honest. First, extract with per-field confidence and treat a low-confidence amount as unresolved rather than trusting it quietly. A wrong number that looks like a right one is the failure that costs you a qualified opinion. Second, resolve entities against a canonical table. “Acme Corp”, “ACME CORPORATION” and “Acme Ltd” have to become one counterparty before you can tie a confirmation to an invoice to a ledger line, because the join key is a name nobody standardised.

Every extracted value carries a reference back to its source: the document, the page, the coordinates on that page. That reference is what makes the eventual workpaper checkable. When a reviewer clicks the balance in the workpaper, it should open the exact spot on the exact PDF the figure came from. Here the lineage is the whole deliverable. A figure a reviewer cannot trace back is a figure they cannot rely on.

The tie-out and the workpaper are where trust is won or lost

A tie-out compares two independent sources and records the difference. Invoice to ledger, confirmation to book balance, contract value to the amortisation schedule. Automating this is straightforward arithmetic once extraction and entity resolution are solid. Making it trustworthy is about what you do with the residual.

• Anything below the materiality threshold reconciles and closes automatically, with the two sources and the difference logged.
• Anything above it stays an open exception and routes to a human, ranked by size and by the risk score that pulled the item.
• A tie-out that could not resolve its join key is never counted as a pass. Unmatched is an exception, not a silent success.

Set a false-positive budget the same way you would for alert triage. If the tolerance is too tight, every rounding difference becomes an exception and the auditor drowns. Too loose and real misstatements slip through. Calibrate against a set of prior-year workpapers where you already know the outcome, and tune until the flag rate matches what the team can actually review.

Then the assembly. The model drafts the workpaper: the control description, the sample basis, the tie-out results, the exceptions and their disposition. The rule that keeps it safe is simple. The draft may not state a figure that is not backed by an extracted value with a source reference. Numbers come from the evidence layer, never from the model’s own prose. A sentence carrying a balance without a link to its origin fails validation before a reviewer opens the file.

What you end up with is not straight-through processing, and it should not be. The reviewer still forms the opinion. But they open a workpaper where the sample is reproducible, every figure links to its source document, the tie-outs are done, and the only items in their queue are the exceptions that need a person. The machine did the collection. The judgement, and the accountability for it, stayed where it belongs.