How a US CPA firm would deploy AI in audit (peer-review safe)

A US mid-market CPA firm, Top 100 by revenue, three to five offices, roughly 300 audit and tax professionals, had been circling AI inside the audit practice for eighteen months. The circling got expensive in the last ninety days, for reasons that happened to the market, the regulators, and the firm's staffing at once.

On October 22, 2026, Thomson Reuters launched the next generation of CoCounsel for tax, audit, and accounting, with marketing that leaned on the phrase "knows the answer, and why it is right." The line restates what every audit partner already understood: a confident paragraph with no auditable basis is not audit evidence, no matter how well it reads. In the same window, MindBridge and a coalition of US audit firms publicly urged the PCAOB to issue clearer guidance on AI in audit, after signals from PCAOB staff that AI oversight is on the standard-setting agenda. Firms are deploying AI inside audit workflows faster than the standards are catching up, and the firms doing it quietly are hoping their next peer review and their next PCAOB inspection do not look too closely.

The firm's internal pressure matched the external one. The CPA pipeline is smaller than it was five years ago, hiring runs slower than attrition, and the second and third-year associates who used to draft risk assessments and walkthroughs are stretched. A pilot that was a nice-to-have in 2024 is now the only realistic path to shipping Q1 busy season on time without quality drift. The managing partner for audit gave the practice six months to pilot an AI system inside the audit workflow, or to decide the firm cannot responsibly ship AI into audit at all. The second answer is not acceptable to the market. The first is not acceptable to peer review unless the system is built very carefully. This case study is that system.

The obvious fix is to let seniors paste work paper narratives, risk assessments, and inquiries from ChatGPT, Copilot, or Gemini into the engagement file. Many firms are doing exactly this. It is also what every peer reviewer and PCAOB inspector is now trained to look for, and the fastest known path to a comment letter.

The reason is specific. Under AU-C 500 for private company audits and AS 1105 for public company audits, audit evidence must be sufficient and appropriate, traceable to its source, relevant to the assertion, and reliable enough that an experienced reviewer could reach the same conclusion from the same material. Under AU-C 230 and AS 1215, audit documentation must be clear enough that an experienced auditor with no previous connection to the engagement could understand the work performed, the evidence obtained, and the conclusions reached. SAS 145, effective for private company audit periods ending on or after December 15, 2023, raised the documentation bar for risk assessments specifically, and the current peer review cycle is already catching firms whose risk assessments do not match it.

A paragraph produced by a general-purpose chatbot does not meet any of this. It has no citation to source documents in the engagement file, no reference to the specific audit standard it supports, no retrieval path a reviewer could reconstruct, and no record of what the model was asked or what it saw. The output might be correct. The firm cannot show it is correct, and under the standards the firm has to be able to show it. This is the same pattern that stops most AI pilots from reaching production, written up in [why AI pilots fail to reach production](/blog/why-ai-pilots-dont-reach-production): a working demo is not the system that survives contact with the real workflow.

The firm's second instinct is to buy a horizontal point solution. Some are good, Thomson Reuters' CoCounsel is the most visible serious one. The trade-off is specific. A horizontal product covers the workflows it was built for, routes client data through the vendor's infrastructure, charges per user, and does not learn the firm's methodology, specialty-practice overlays, or prior-year judgments. Mid-market firms with distinctive practice areas, government, employee benefit plans, construction, auto dealerships, carry methodology no horizontal product encodes. For those firms the real decision is between stitching together three or four vendor products and building a custom system that fits their own workflow.

Five operational things need to be true at the end of the engagement, each phrased in terms the audit partners care about rather than terms engineers care about. The system is judged by whether these are true at go-live, not by whether the architecture is elegant.

Senior auditors can produce a first-pass draft of a planning risk assessment, an understanding of the entity and its environment, a walkthrough narrative, or an inquiry summary from the engagement's own client-provided documents in a fraction of the time it takes today, with every claim in the draft linked to the specific source document and the specific audit standard it supports. The reviewer sees the links first and the prose second.

Reviewers audit the AI output in less time than they spend reviewing a human-drafted version, because the system shows them exactly which document each sentence came from, which standard applies, what the model's confidence was, and whether a preparer accepted or edited each piece. The reviewer verifies the retrieval rather than re-performing it. Peer review and PCAOB inspection can trace, for any work paper, exactly what the system saw, what it produced, what the preparer accepted, what the reviewer approved, and when, as a queryable record.

The firm's methodology stays the firm's. The system embeds the firm's risk frameworks, sampling conventions, practice-area overlays, and prior-year conclusions, and the firm can update any of them without a vendor change-order. The system also fails safely: when a client document is missing, a standard interpretation is ambiguous, or the model's grounding is weak, it produces a flagged request to the preparer rather than a confident draft. Silent fallback to generic reasoning is the one behavior the firm cannot accept.

Four components, deployed inside the firm's existing audit platform (CCH ProSystem fx Engagement, Caseware, TeamMate, or Suralink depending on the stack) and the firm's own cloud tenant, with no new vendor at the center of the methodology. An audit firm's methodology does not belong on someone else's infrastructure, and an audit AI without the firm's methodology is a horizontal product the firm already decided not to buy.

The first component is a standards-grounded retrieval layer. It indexes the authoritative sources the firm's audit practice depends on: AICPA audit and attestation standards (AU-C, AT-C), PCAOB auditing standards for public company work, FASB Accounting Standards Codification references, GAO Yellow Book for government engagements, specialty industry audit guides, and the firm's own written methodology. Each retrieval returns the specific section, the governing paragraph, and the firm's internal interpretation when one exists. The retrieval is cite-first: the system will not generate a conclusion without a retrieved citation to anchor it.

The second component is an engagement-scoped document layer. Every client document in the engagement file (trial balance, GL detail, bank reconciliations, management letters, prior-year work papers, confirmations, contracts) is extracted, chunked by document type, and indexed per engagement. A draft prepared for Engagement A cannot pull evidence from Engagement B, even if the firm serves both and the facts overlap. Multi-tenant isolation is enforced in the retrieval layer in code, not in the model's system prompt.

The third component is the work paper drafter. For each supported work paper type, planning risk assessment, understanding of entity and environment per SAS 145, walkthrough narrative, substantive analytical procedure write-up, inquiry documentation, review memo, the drafter runs a short pipeline: retrieve standards, retrieve client documents, draft against the firm's template, link every assertion to its source, score confidence per section, and flag anything it cannot ground back to the preparer. The fourth component is the review and sign-off trail: every draft, every edit, every reviewer note, and every sign-off is captured as a structured record with inputs, outputs, model version, retrieval set, confidence scores, timestamps, and user. The record lives in the firm's data warehouse under the firm's identity controls, and peer review file assembly reads from it directly.

A manager assigns a new audit engagement, a mid-sized private manufacturer, to a second-year senior. The engagement folder is created in the firm's audit platform. The senior opens the AI panel and selects "Draft planning risk assessment and understanding of entity and environment."

The system first checks what it has. It confirms the trial balance is uploaded, flags the three documents it needs but does not yet see (prior-year audit report, current-year draft financials, management's revenue recognition memo), and queues the engagement for drafting as soon as those arrive. If a required input is missing, the system asks for it; nothing happens on inferred content.

Once the inputs are present the pipeline runs. The system retrieves the relevant audit standards (AU-C 315 for risk assessment, AU-C 240 for fraud consideration, AU-C 540 for estimates) plus the applicable sections of the firm's methodology on manufacturing engagements. It retrieves the client documents and prior-year work papers. It drafts the risk assessment section by section against the firm's template, in the firm's house style for review memos. For each paragraph, it links to the specific client document or standard it is relying on, and it writes a confidence score beside each identified risk. Where it cannot ground a claim, the paragraph becomes a flagged request to the preparer: "Need confirmation of inventory valuation method; prior-year memo describes FIFO, current-year draft financials describe weighted-average. Please confirm with the client controller."

The senior reviews the draft inside the platform. Each sentence has a hover state showing the source document, the paragraph referenced, and the standard supporting it. The senior accepts, edits, or rejects each section, and every edit is logged against the system's original output. When the senior is ready, the draft is routed to the manager for review; the manager sees the final text and the full provenance trail. The partner's final sign-off closes the record. The entire history is the audit documentation. If next year's peer reviewer asks what the firm did and why, the file answers it without reconstruction.

The underlying architecture has five layers, chosen for defensibility rather than cleverness. The retrieval layer uses two indexes. Audit standards are chunked at the paragraph level with the section and subsection preserved as metadata, so a retrieval returns "AU-C 315.A48" rather than "something near AU-C 315." Client documents are chunked by section headings for structured files and by semantic boundary for unstructured ones. Both indexes carry provenance metadata the model never sees but the audit log always does: source URI, extraction timestamp, hash, extractor version. For the engineering reasoning behind separating what the model sees from what the system records, see [context engineering for production LLM systems](/blog/context-engineering-production-llm-systems).

The reasoning layer sits above retrieval and is deliberately boring. A planner routes the request to the right template and the right retrieval set. A drafter runs the template section by section, calling the model with explicit instructions to cite each claim and to refuse rather than extrapolate when the retrieval is thin. A grounding verifier reads the draft back, extracts every assertion, and checks that each has a retrieved anchor; if an assertion has no anchor, the sentence is rewritten as a flagged request. The model is pinned per fiscal year, so a prior-year work paper can be re-run with the exact same model version if a reviewer or regulator asks.

The schema layer defines what a work paper is in the system. Each work paper is a structured object with typed sections, each carrying text, confidence score, source citations (document hash and location), standard citations (paragraph-level), author (human or system), reviewer, and sign-off state. The schema is version-controlled with the methodology. A methodology change is a schema change plus a migration, not a Word document update.

The audit-trail layer writes immutable records to the firm's data warehouse in three streams: input records (what the system was asked, what it could access, what retrievals it ran), output records (what the model produced per section, with confidence and citations), and decision records (which human accepted, edited, or rejected each piece and the reviewer notes attached). The warehouse is the firm's existing one, inside the firm's identity controls, with retention set to the longer of the firm's standard and any client contract. The compliance team queries it directly, not through a vendor dashboard. The deployment layer runs inside the firm's cloud account, co-located with the audit platform, with model vendors accessed over a private connection where available; no client data leaves the firm's tenant at rest, and prompt and response traffic is logged by the firm, not only by the vendor. The system runs the same guardrail classes any production LLM system should, covered in [pilot with guardrails, from first prompt to production](/blog/pilot-with-guardrails-deep-dive).

Four parts of the work resisted the first pass. The first was retrieval over audit standards. Reviewers do not accept "paragraph similar to AU-C 315"; they want the specific sub-paragraph that supports the specific conclusion. The first-pass embedding approach, chunk by headings and retrieve semantically, failed because adjacent paragraphs often say nearly the opposite thing (the general rule and the specific exception). The second pass added structural metadata and a re-ranker that prefers the paragraph where a cited term actually appears. The third pass added a tie-breaker on the firm's own interpretation documents, so when the standard is ambiguous the firm's position is retrieved alongside the standard itself.

The second hard part was numbers. The system is never allowed to produce a number that was not retrieved from a source document. Not an estimate, not a rounded figure, not a plausible-sounding dollar amount. The implementation is a post-draft check: a regex extracts every numeric value, each is matched against a retrieved document, and any value without a retrieved source causes the draft to fail and the section to regenerate under stricter instructions. This is slower than letting the model paraphrase figures from memory. It is also the one check that keeps the system usable in a professional engagement.

The third hard part was the distinction between model confidence and auditor professional judgment. Confidence scores are a useful signal to the preparer but they are not evidence. Reviewers initially read a 0.92 score as "the system is sure about this," which it is not; it means retrievals converged and generation was stable. The reviewer guidance makes the distinction explicit: a confidence score tells you how much of the draft to re-check first, not whether the conclusion is correct. The sign-off record always carries the human who accepted the piece. The model is never a signatory.

The fourth hard part was prior-year reliance. The standards require re-evaluation each year, not blind reuse. The first version retrieved prior-year work paper text aggressively, which produced drafts that read like last year's file with the date changed. The fix was a two-step retrieval: first retrieve prior-year identified risks and conclusions as reference only, flagged as prior-year in the context; then retrieve current-year documents for the actual drafting. The reviewer still confirms each carry-forward, but the draft now treats the prior year as reference rather than source.

Four reliability properties matter for audit use, each enforced in code. First, zero-fabrication on numbers: every numeric value in a draft must trace to a retrieved document, verified by the post-draft check. A system that fabricates even a single number is one the firm cannot deploy, and the check runs on every draft, not a sample.

Second, cite-first generation. The model is prompted and the pipeline is structured so that a conclusion without a citation does not get written. If retrieval is thin, the section becomes a flagged request to the preparer. A generative system under pressure to produce output will produce plausible output, which in audit is worse than no output. The failure mode we want is a request for more information, which is what human auditors already do when evidence is thin.

Third, reviewer sign-off is required before any AI-assisted content enters the final engagement file. The system can draft, suggest, and link; it cannot approve. Every sign-off is a human user with timestamp, and the sign-off cannot be overridden by the system or by a model prompt. The pattern is the same one described in [how a firm would prepare for ISO/IEC 42001 in six weeks](/blog/iso-42001-readiness-six-week-plan), where risk acceptance is always a named person, never the governance system itself.

Fourth, immutable audit log. Every retrieval, draft, edit, reviewer note, and sign-off is written to an append-only store the firm controls, queryable by engagement, preparer, standard, or model version. Peer review file assembly reads directly from the log. The log is the product: an audit firm's deliverable is work papers that defend themselves.

Three productionization choices turn the system into something the firm can operate for a full busy season. First, the system is pinned per fiscal year. The model version, standards index version, methodology version, and schema version used to draft each work paper are recorded with the work paper. A standards update mid-year does not retroactively change prior work. A model vendor change is a tracked event, not a background surprise.

Second, monitoring is specific to the audit use case. The three metrics that matter are grounding-rate (what percentage of draft assertions are anchored to retrievals), reviewer-edit rate (how much of system-drafted content the reviewer edits, broken down by section type and engagement partner), and time-to-first-review. A rising reviewer-edit rate on a specific section type is the earliest signal that methodology, retrieval, or the model is drifting; a sustained drift triggers a methodology review before the next engagement rolls over.

Third, change management is explicit and shared between engineering and the firm's audit methodology partner. A standards update, methodology change, or prompt change is a reviewed pull request against the governance repository, the schema, and the prompt library. The audit methodology partner signs off before the change ships. This is the step most firms try to skip. Skipping it is the fastest way to a peer review finding on consistency.

At the end of the engagement the firm did not reduce audit team headcount, and the system was not sold internally as a headcount-reduction project. The structural shift is more valuable and harder to copy. Senior auditors spend less time on first-pass drafting and more time on the parts of the audit that require professional judgment: inquiries, exception follow-up, management interactions, conclusions. The time reclaimed is spent on the work the standards actually ask the auditor to do.

Reviewers verify rather than re-perform. A traditional review of a human-drafted work paper requires re-tracing enough of the preparer's work to be comfortable with the conclusion. A review of a system-drafted work paper, with sentence-level source links and standard citations, is a verification exercise, faster and in the standards' terms more defensible. The firm's peer review file for the following cycle assembles itself. The reviewer who used to spend a week before peer review assembling exhibits now spends an afternoon running queries.

The firm's position in enterprise client conversations shifts. The CFO who asked whether the firm uses AI now hears a specific answer: the firm uses AI inside the audit, with cite-first drafting, human sign-off, immutable records, and alignment to AU-C 500 and AU-C 230, produced from the firm's own infrastructure. The response is less about catching up to a Thomson Reuters launch and more about describing a system the firm owns. The managing partner's six-month deadline is met, and the practice has a pilot that is defensible under peer review, not one quietly hidden from it.

What the firm owns at the end of six months: the source code for the pipeline, the retrieval indexes (standards and engagement documents), the schema for every supported work paper type, the prompt library, the methodology encoding, the audit-trail store, and the runbooks. The deployment lives in the firm's cloud account under the firm's identity provider. No vendor contract sits at the center of the system, and no renewal date threatens continuity.

The firm also owns the operating cadence. A quarterly methodology sync between the audit methodology partner and the engineering team keeps the system aligned with changes to standards and firm interpretations. A monthly review of reviewer-edit-rate patterns flags sections drifting against the methodology. An annual review of the model vendor and pinning strategy aligns with the firm's own risk management calendar.

What Stallwart retains no ownership over: the professional judgment on any audit, the sign-offs that attest the work (which have to be named firm employees under their licenses), the firm's methodology itself (which the firm authors and we only encode), and the opinions issued. Our role is to build the system that makes those professional acts defensible. The firm has to be the firm that performs them.

Three things from this engagement generalize to AI inside any evidence-based professional practice. First, cite-first beats answer-first by a wide margin for anything that lands in a work paper, a legal brief, a clinical note, or a regulated filing. Answer-first systems produce confident outputs that fail scrutiny. Cite-first systems produce slower outputs that survive it. Thomson Reuters' October 2026 marketing line is the same lesson restated from the vendor side.

Second, the methodology is the system. The LLM is the smallest decision in the architecture. The retrieval design, the schema, the citation enforcement, the audit log, and the methodology encoding are what make the system defensible. A team that treats the model as the project ships something impressive at the demo and indefensible at the audit.

Third, the deliverable in professional-services AI is the audit trail, not the content. The partner who signs the opinion signs on behalf of the firm, and the firm's exposure is defined by what it can show it did, not by what the model wrote. A system whose output is beautiful prose with no provenance fails the one test the profession actually runs. A system whose output is adequate prose with complete provenance is one the firm can defend.

If your firm is where this one was ninety days ago, with partner pressure, a staffing squeeze, a visible vendor launch, and a near-term peer review or PCAOB inspection on the calendar, the sequence is specific. Scope one work paper type (planning risk assessment is a strong first pick because SAS 145 raised the bar and the volume is high). Build cite-first drafting on that single work paper. Prove it passes an internal review the firm's own reviewer treats as a real peer review. Then widen, one work paper type at a time, with the methodology partner in the review loop on every change.

Do not deploy a horizontal chat assistant into the audit workflow and hope the preparer catches the problems. Preparers are not the control the standards ask for. The system has to be the control. For the broader question of how to evaluate an AI engineering partner for this kind of work, the test is specific: can they describe the audit trail and the citation enforcement in detail, before they describe the model. The post on [how to tell an AI engineering firm from a dev shop](/blog/ai-engineering-company-vs-dev-shop) walks through what else to look for.

Stallwart builds this kind of system end to end for US B2B professional services firms. We do not issue audit opinions, we do not sign work papers, and we do not replace the firm's methodology. We encode the methodology, build the retrieval and the schema, enforce the citation discipline in code, and hand over a system the firm's own engineers can run. If an enterprise client, a peer review, or a PCAOB inspection is already asking the question, the readiness work is the first move and the pilot follows it on a schedule the standards actually permit.