What is audit workpaper automation?

Audit workpaper automation reads the evidence you already hold and populates the fields of an audit working paper from it, rather than drafting a new document. The distinguishing feature of a reviewable implementation is that every populated value carries a reference to the specific evidence it came from, and any field the evidence does not answer is left blank rather than filled with a plausible guess.

Does an AI-filled workpaper satisfy PCAOB audit documentation requirements?

PCAOB AS 1215 requires documentation sufficient for an experienced auditor with no prior connection to the engagement to understand the work performed and the evidence supporting the conclusions. An AI-filled workpaper meets that test only if each value is traceable to identified evidence and the preparer reviews and accepts it. Generated text with no evidence reference does not meet it, whoever or whatever produced it.

Is evidence uploaded to a server for processing?

In NextGen GRC's default Private / On-device mode, no. The template, the reference example and the evidence are read in the browser and the model runs on the device, so nothing leaves the machine. An optional Fast / Quality mode sends the selected fields and evidence excerpts to a configured cloud inference service; it is off by default, requires an explicit choice, and the resulting evidence pack records which engine produced the document.

What happens to formulas and formatting in the template?

The workbook is filled in place, so sheets, formatting, named ranges and formulas are preserved. Cells that compute their own value are refused rather than overwritten, and the post-write verification reports any formula that was lost. The model proposes values; it never chooses the destination cell.

← Back to Blog

SOX & ITGCSeptember 20, 2026 · 12 min read · By NextGen GRC Consultants

Audit Workpaper Automation: Fill Your Own Template From Evidence, With a Citation on Every Value

        Key takeaway: Drafting a workpaper and filling one are different problems. A general-purpose AI will happily write you a SOC 1 memo that reads beautifully and cites nothing. A workpaper that survives review has to be your template, populated from your evidence, with a reference on every value and a blank wherever the evidence runs out. That last part — leaving gaps as gaps — is the hard requirement, and it is the one most automation quietly fails.
      

The blank template was never the hard part

Ask any IT auditor what consumes a testing cycle and almost nobody says "writing the memo". The template already exists. It has been reviewed, it carries the firm's phrasing, its sheets are laid out the way the reviewer expects, and half its cells compute from the other half. What consumes the cycle is the transcription: reading a 40-page SOC 1 report, a ticket export and a sampling note, deciding which sentence answers which field, and typing it in — 60 or 80 times, across every sheet, without losing track of where each value came from.

This is why "AI writes your audit documentation" has been an underwhelming promise. A model that produces a new document has solved the easy half. You now hold a fluent memo that does not match your template, does not tie to your evidence, and cannot be reviewed without redoing the work you were trying to avoid.

What reviewable automation actually has to do

PCAOB AS 1215 sets the bar in one sentence: documentation must let an experienced auditor with no previous connection to the engagement understand the work performed, the evidence obtained, and the conclusions reached. Notice what that requires of each individual value in a workpaper — not that it be correct-sounding, but that its support be locatable.

That single requirement rules out most of what gets marketed as audit documentation automation. If a tool produces a value and you cannot point at the evidence behind it, the value has failed AS 1215 regardless of whether it happens to be right. And a reviewer cannot tell a lucky guess from a supported fact by reading either one.

So a workpaper automation worth using has to hold four lines at once:

It fills your template, in the template's own file, not a new document shaped like it.
Every value carries its evidence reference — which document, which extract.
Anything it cannot support is withheld, not written.
The blanks are preserved as blanks, because a blank is a finding: it is the field you still need evidence for.

Three inputs, and why the middle one is unusual

NextGen GRC's Workpaper Composer (previously called Document Autofill) takes three things:

The blank document — your .xlsx or .docx, filled in place. .txt and .md export as Markdown.
A completed example of the same document, for a different subject — optional, strongly recommended.
The evidence — PDF, Word, Excel, CSV, text; as many files as you have.

The second input is the one people ask about. Why supply a completed workpaper from a different engagement? Because it teaches shape and phrasing that no instruction can convey: how long an answer should be, whether "Scope" wants one line or a paragraph, what register the firm writes in. A prior-year memo is the fastest way to say "like this".

        The risk that creates, and how it is handled: a reference document is full of another client's facts. The obvious failure mode is that those facts leak into your workpaper — the prior year's service auditor, the prior year's dates, the prior year's opinion. Workpaper Composer detects values that appear to have been copied from the reference rather than drawn from the evidence and withholds them, listing each one in the fill record with the value it proposed. The reference is used for shape; the facts must come from your evidence or they do not get written.
      

A citation on every value, or the value is not written

Each evidence file is given an identifier. Each answer must name the identifier it came from. This is enforced deterministically, after the model has answered and before anything is written:

An answer citing no evidence is demoted to a gap.
An answer citing an evidence id that does not exist is rejected outright — a fabricated citation is worse than none, because it survives a skim.
An answer for a field the template never asked for is dropped.

None of those checks depend on the model having complied with its instructions, which is the point. The model proposes; a deterministic layer decides. When you open the filled workbook, every populated cell has a traceable source, and the fill record tells you which evidence extract it was.

Gaps stay gaps

This is the discipline that makes the output reviewable, and it is worth stating plainly because it runs against what automation usually optimises for. If the evidence does not answer a field, Workpaper Composer leaves it blank and says why. It does not infer, it does not carry the value across from the reference document, and it does not produce a confident sentence to fill the space.

A blank cell is not a failure of the tool. It is the tool telling you which evidence you still have to go and get — which is exactly the list you want before you close fieldwork, and exactly the list that a document with no blanks in it has hidden from you.

What must never happen to the file

An audit workpaper is a controlled artefact. Three properties are protected mechanically rather than by instruction:

The model never chooses the destination. Sheet and cell come from the template's own structure. A model that proposed its own target cell would be able to write anywhere in the workbook; it cannot, because the destination is never read from its answer.
Formula cells are refused, not overwritten. A cell that computes its own value is skipped and recorded as refused, with the formula it protected. After writing, the workbook is re-read and any lost formula is reported as a problem.
The file keeps its own identity. Sheets, formatting, named ranges, data validation, comments and hyperlinks survive, because the template is filled in place rather than reconstructed.

Where the work happens — and why the deliverable says so

By default, everything runs on your device. The template, the reference and the evidence are read in the browser; the model runs locally; nothing is uploaded. For teams whose evidence includes user names, ticket detail and client identifiers, that is not a preference but a precondition — it is the same architecture behind GrcAI, our private on-device assistant.

There is an optional Fast / Quality mode that sends the selected fields and evidence excerpts to a configured cloud inference service, for machines that cannot run a capable model locally. It is off by default, it requires an explicit choice, and it shows a disclosure naming what is sent before the first use.

        What the evidence pack claims: the exported pack states which engine produced the document. A run on the local engine says the work was done entirely on the device and nothing was uploaded. A run on the cloud engine names the service and states that the template fields and evidence excerpts were sent to it. The claim is recorded from the engine that actually answered, not from whatever the selector happens to say when you export — because a false statement about where audit evidence went is the worst possible thing to put inside an audit deliverable.
      

What comes out

A single ZIP, assembled on the device:

The filled document in its original format, plus a Markdown rendering that always opens.
A fill record — every field, the value written, the evidence behind it, and the status: filled, gap, withheld as uncited, or withheld as a suspected copy from the reference.
The inputs, so the pack is self-contained and a reviewer is not chasing attachments.
A SHA-256 manifest covering every file in the pack, so tampering after the fact is detectable. (Digests require a secure context; over plain HTTP the pack says the hashes were not computed rather than pretending otherwise.)

A worked example: the SOC 1 service auditor memo

Take a memo your team completes for every material service organisation. Inputs: your blank memo, last year's completed memo for a different provider, and this year's SOC 1 Type 2 report.

Field	Outcome	Why
Report period	Filled, cited to the SOC 1 extract	Stated explicitly in the report
Service auditor	Withheld	The proposed value matched the reference memo — a different engagement's auditor
Opinion	Filled, cited	Drawn from the opinion paragraph of your evidence
Subservice organisations	Filled, cited	Named in the report, with the carve-out method identified
CUEC compliance conclusion	Gap	The report lists the complementary user entity controls; whether you perform them is not in the evidence. This is the field a reviewer would have challenged anyway

Four fields supported, one correctly refused, one honestly blank. The blank is the useful output: it is a concrete task — evidence the CUECs — rather than a sentence someone would have had to unpick in review.

Reviewing an AI-filled workpaper

Automation moves the work; it does not remove the sign-off. Before a filled workpaper goes into the binder:

Read the withheld list first. It is short and it is where the interesting problems are.
Spot-check three citations back to the source document. If they tie, the mechanism is working; if one does not, stop and look at the evidence selection.
Treat every gap as an open item with an owner, not as a formatting blemish.
Confirm the provenance line matches the engine you intended to use.
Sign it yourself. Under AS 1215 and the IIA Standards, the preparer is a person. That has not changed and should not.

What this does not do

Worth saying, because automation that oversells itself costs more time than it saves:

It does not form conclusions. It populates fields from evidence; whether the control is effective remains the auditor's judgement.
It does not find evidence you did not give it. Give it the ticket export and the sampling note, or the fields that depend on them will be gaps.
It does not fix an ambiguous template. A field labelled "Comments" with no indication of what belongs there will produce a weak answer or a gap, exactly as it would for a new joiner.
It does not replace review, and the citation trail exists precisely so review is fast rather than optional.

The bottom line

The question to ask any audit documentation tool is not "can it write a memo". It is: when it writes a value, can you find the evidence behind it — and when it cannot find evidence, does it tell you, or does it write something anyway?

Workpaper Composer is built around the second half of that question. Your template, your evidence, a citation on every value, gaps left as gaps, and nothing leaving your machine unless you deliberately choose otherwise.

Try it with the samples: open Workpaper Composer and use the built-in fictional set — a blank SOC 1 memo, a completed example for a different client, and a SOC 1 extract. The example is deliberately built so the leak check has something real to catch.

References & further reading

PCAOB AS 1215, Audit Documentation — the "experienced auditor" standard that governs what a workpaper must make understandable.
PCAOB AS 1105, Audit Evidence — sufficiency and appropriateness of evidence, and the relevance of its source.
PCAOB AS 2201, An Audit of Internal Control Over Financial Reporting — the ICFR framework ITGC testing sits inside.
AICPA, SOC Suite of Services — SOC 1/2/3 reporting, including complementary user entity controls.
IIA, Global Internal Audit Standards — documenting information and supporting engagement conclusions.
COSO, Internal Control — Integrated Framework — the control framework most SOX programmes map to.

External links are provided for reference and are not affiliated with NextGen GRC. Standards are cited as at the date of publication; always work from the current text.