Inside a 55-point audit control framework: what auditors actually check, and why each one has a legal source
Not a black box that flags 'anomalies.' A tour of the eight control families behind a modern document audit — compliance, arithmetic, fraud, recovery — each one tied to a named statute or standard.
"AI-powered fraud detection" is one of the most-claimed and least-explained phrases in financial software marketing. What does the software actually check? What law or standard says it should? A serious audit tool should be able to answer both questions for every single finding it produces — and if it cannot name the check and its legal basis, the finding is an opinion, not evidence.
The eight control families
1. Lot integrity
Before any content check runs, the batch itself is validated: missing documents, duplicate files, incomplete periods are declared explicitly rather than silently dropped. A control framework that quietly skips a file it cannot process is worse than one that flags the gap — silence looks identical to "nothing wrong" until someone asks the wrong question at the wrong moment.
2. Document compliance
Every jurisdiction has its own list of mandatory invoice fields, and they are genuinely different: French invoices must carry SIRET/SIREN identification and specific mentions under the Code de commerce and the CGI's annexe II; UK invoices fall under VAT Regulations 1995 (SI 1995/2518), regulation 14; US expense documentation must satisfy IRC §274(d)'s substantiation requirements (amount, date, place, business purpose). A control that checks "US rules" against a UK invoice is worse than useless — it produces false confidence.
3. Arithmetic and tax coherence
Line items must sum to the stated subtotal; net plus tax must equal the gross total; the tax rate charged must match what is legally valid for that supply type on that date. These sound trivial until you have seen how often they silently fail — a VAT rate correct on the invoice date but changed by the time anyone checks it, a multi-currency conversion that does not reconcile to the stated exchange rate.
4. Population analytics
Some fraud and error patterns are invisible at the single-document level and only appear across the full population: duplicate invoices under altered reference numbers, unusual clustering of amounts just under approval thresholds, and statistical distribution checks (a first-digit frequency analysis, sometimes called Benford's Law analysis, that the ACFE itself documents as a fraud-screening tool) applied to a large enough sample to be statistically meaningful.
5. Supplier and payment risk
Bank-detail changes on known suppliers, suppliers who appear once and are never revisited, wording patterns designed to rush a payment through without normal verification — these are the fraud-risk factors documented in professional auditing literature (ISA 240's own appendix of fraud risk indicators), operationalized as checks that run on every document rather than a sampled few.
6. Journal entries and ledger structure
For businesses whose accounting records are available at the ledger-entry level, structural checks apply: does every entry balance in debit and credit, is the chronological order internally consistent, is an entry's validation date logically after its posting date. These are dry, mechanical checks — exactly the kind that matter most because they are also the kind nobody enjoys re-verifying by hand.
7. Recoverable amounts
Distinct from risk detection: duplicate payments, credit notes issued but never applied against an invoice, early-payment discounts offered in the payment terms but never actually taken. These findings point to money the business can reasonably reclaim, not just a risk to monitor — a different category of output that a report should keep visibly separate from exposure findings.
8. Dormant liabilities
Aged credit balances and long-overdue payables sitting with no dispute and no resolution on file — the kind of stale position that accumulates quietly in a ledger nobody has fully reconciled in years.
Why "legal source" matters more than "AI-powered"
A finding that says "this invoice is missing a required field" is useful only if the reader can verify the requirement is real. A finding that cites IRC §274(d); 26 CFR 1.274-5 for a US substantiation gap, or VAT Regulations 1995, reg. 14(1)(g) for a UK sterling-total requirement, can be checked against the actual text of the law in minutes. That verifiability — not the presence of AI — is what separates a control framework auditors can rely on from a black box that "looks for anomalies."
What this kind of framework deliberately does not do
It does not render an opinion on the financial statements as a whole, does not reach a conclusion, and does not claim to detect fraud with certainty — it flags discrepancies that warrant investigation, with the evidence attached. A narrative summary can be generated from the findings to make the report readable, but the findings themselves are calculated by deterministic rule logic, never invented by a language model.
Related reading
- What an AP recovery audit actually costs in 2026: a market comparison
- One-off audit vs. subscription: when a snapshot beats a monthly report
FAQ
How many of these 55 checks apply to any single document?
It varies by jurisdiction and document type — a French invoice triggers France-specific compliance checks that a US expense receipt never will, while arithmetic and population-level checks apply broadly across jurisdictions. The applicable set is determined automatically per document, based on its own issue date and jurisdiction, not a one-size-fits-all list.
Do the legal sources stay current as laws change?
Each check is versioned with the date range it applies to, checked against the document's own issue date — not the date the audit runs. A US 1099 threshold that changed from one year to the next, for example, is applied based on when the payment was actually made, not when the report was generated.
Can two different runs of the same audit produce different results?
No — that is a deliberate design constraint. The same batch of documents run twice produces byte-identical findings, because every check is a pure, deterministic function of the document data. Nothing in the finding-generation step is produced by a language model, which is what makes the results reproducible and defensible.