What AuditEngine actually generates, and what it deliberately doesn’t

In short. AuditEngine drafts lead schedules, analytical review packs, walkthrough narratives, and substantive procedure indexes from a trial balance and a small set of operator inputs. It does not form opinions, scope the audit, assess management bias, or make sufficiency judgments. The deliberate split is not a limitation, it is the architecture.

1. The pattern in current FRC inspection findings

If you read the last three years of Financial Reporting Council audit-quality reports straight through, you find a consistent texture. The headline numbers move; the underlying causes do not. Files fail second review for the same reasons: insufficient documentation of judgment, evidence that does not tie to the conclusion stated, a tone-at-the-top section that was clearly written backwards from the opinion, and analytical procedures that were performed but not retained.

These are not engagement-team competence problems. They are evidence-chain integrity problems. The judgment was probably formed correctly in someone’s head; the file does not show the working.

That observation is what AuditEngine is engineered around. Most of what goes wrong on inspected files is not about the conclusion. It is about the trail.

2. What AuditEngine actually generates

AuditEngine takes a trial balance upload and produces a structured set of working papers. The output is opinionated about format and disciplined about citation. The current output set:

• Lead schedules for every primary-statement caption, populated with prior-year comparators, classification mapping to a configurable chart of accounts, and a documented variance commentary draft.
• Analytical review pack covering ratio-based trend analysis, expectation versus actual, and a flagged-variance table calibrated against engagement-team-set thresholds.
• Walkthrough narratives in a standard template that references the relevant control objectives, drafted from operator-supplied process notes.
• Substantive procedure index mapping each material assertion to a procedure type, sample basis, and evidence requirement.
• Disclosure checklist generated from the applicable framework (IFRS, FRS 102, FRS 105), pre-populated with caption-to-disclosure references.

None of these are novel as artefacts. Every audit firm produces them. The difference is that AuditEngine produces them deterministically, in a consistent house style, with provenance metadata attached to each generated line. When the reviewer asks “where did this come from”, the file answers.

3. What AuditEngine deliberately does not do

This part matters more than the previous one.

• It does not form audit opinions. No opinion paragraph is generated. The opinion is the output of human judgment applied to the evidence, not a function the engine evaluates.
• It does not scope the audit. Materiality is operator-supplied. Risk identification is operator-driven. The engine does not infer scope from the trial balance because scope is not a property of the trial balance.
• It does not assess management bias. Section 540 estimate-testing involves an evaluation of indicators of possible bias. That evaluation requires context the engine does not have and is not asked to acquire.
• It does not conclude on sufficiency. ISA 330 paragraph 28 requires the auditor to conclude on whether sufficient appropriate evidence has been obtained. The engine assembles the index; the auditor concludes.
• It does not draft the going-concern conclusion. ISA 570 contemplates a careful weighing of management’s assessment against the auditor’s own analysis of indicators. A drafted paragraph would prejudice that.

Each of these is a hard rule, not a default. The engine refuses these tasks explicitly when prompted, and the refusal is itself logged.

4. The split between deterministic and judgmental

The architectural decision underlying AuditEngine is that audit work splits cleanly into two categories that should be handled differently.

The deterministic category covers tasks that have a correct answer given the inputs. Mapping a trial balance to a chart of accounts is deterministic. Computing year-on-year variance is deterministic. Drafting a walkthrough narrative from a process flowchart and a control matrix is largely deterministic, in that two competent auditors given the same inputs would produce documents that differ only in prose style. These tasks consume the majority of audit hours and yield the lowest variance in output quality. They are the right targets for tooling.

The judgmental category covers tasks where the answer depends on context the model cannot see and cannot reliably acquire. Scoping. Risk weighting. Reliance on internal controls. Severity classification of deficiencies. Going concern. Subsequent-events conclusions. Management-representation evaluation. These tasks consume fewer hours but determine audit-file outcome.

Mixing the two is the failure mode. A workpaper-generation tool that drafts a sufficiency conclusion has crossed the line. A scope-recommendation tool that points at line items above two percent of materiality has crossed the line. The engineering discipline is to refuse to cross it.

5. A practical walkthrough

Take a mid-market lending platform’s first statutory audit. Trial balance of around eight hundred general-ledger accounts. Two operating subsidiaries. FRS 102 reporter.

The audit team uploads the trial balance and confirms the chart-of-accounts mapping against an existing FRS 102 reference. AuditEngine produces lead schedules within minutes. The team reviews; nine accounts re-classify; the mapping is saved as the working version. A first analytical review pack is generated against prior-year comparators. The variance table flags eleven captions above the engagement-team-set threshold of fifteen percent and three captions whose trend is inconsistent with stated management commentary. The team reviews the flags.

At this point, six hours of partner-and-manager time has produced the lead schedules, analytical pack, and a first list of areas requiring substantive procedures. In a traditional file the same artefacts would arrive after one to two weeks of senior-associate work, often with inconsistent format and citation.

Now the engagement team takes over for the next four weeks. Risk register. Materiality. Scoping memorandum. Substantive testing strategy. Sampling. Re-performance. Confirmations. Estimate testing. Going-concern review. None of this is engine work. The file finishes with a partner-signed opinion and a working-paper trail whose deterministic components were produced consistently and whose judgmental components are visibly the product of named senior auditors.

6. Why the split survives FRC inspection

The FRC’s inspection methodology is, in essence, a sufficiency-and-judgment review. The deterministic components of a file rarely fail inspection; lead schedules and analytical review packs from any competent team will tie. What fails inspection is the visible judgment: did the auditor identify the right risks, did they design responses commensurate with those risks, did they evaluate the evidence appropriately, did they reach a defensible conclusion.

A file in which the deterministic work is consistent, well-formatted, and provenance-tagged frees the engagement team to spend its hours on the judgmental work. That is the entire benefit. The risk is when a team mistakes the engine’s deterministic output for completed audit work and stops there. AuditEngine is engineered to refuse to imply completeness. There is no “audit done” signal anywhere in its output.

7. The hard part is the refusal

The technical interesting part of AuditEngine is not what it generates. Lead-schedule generation is solved. The interesting part is what it refuses to generate, and how that refusal is enforced.

The engine maintains an explicit list of forbidden output types. Audit opinions, scope memoranda, materiality conclusions, sufficiency assertions, going-concern conclusions, fraud-risk overall assessments, and management-bias evaluations are all blocked at the prompt-construction layer. When an operator asks for any of these, the response is a structured refusal with a pointer to the relevant ISA paragraph and an explanation of why the engine declines.

This is not a safety feature in the marketing sense. It is a design decision that follows from the same idea that makes the architecture work. Audit work is divided into the part that benefits from consistency and the part that depends on judgment. Tooling that respects the division becomes deployable. Tooling that violates it becomes a file-quality risk.

8. Closing observation

The right test for an AI audit tool is not what it can do. It is what it refuses to do. Anything that will draft an opinion paragraph on request is a tool that does not understand the work. Anything that will scope an engagement from a trial balance is a tool that has read about audit but not done one. The deliberate negative space in the feature set is the thing that signals the design has been done by someone who has signed files.

AuditEngine is in production at auditengine.agency. Engagements are scoped through Atlas Verum.

— DK Buledi, May 2026