Sampling was never good practice. It was a concession to cost.
No auditor believes that testing 40 transactions out of 200,000 is a better way to understand a control than testing all 200,000. They test 40 because a person has to open each one, and a person cannot open 200,000. Every control framework in general use is shaped around that limit: pick a sample, test the sample, extrapolate, document the extrapolation.
The limit has moved. At customers running agents on the ledger, controls are applied to the full population and tested continuously, and the auditor pulls 100% of the journal population through the API rather than a sample of it. Companies at $500M ARR have completed audits on that footing.
of the journal population extracted for testing through the API, rather than a sample
ARR at customers that have completed audits with agents posting to the ledger throughout
control report a month, listing what was checked, what passed and what was flagged
Controls that test their own instructions
The genuinely new part is not automated checking of outputs. Rules engines have done that for years, and they share a blind spot: they verify that work matched the configuration without ever asking whether the configuration still matches policy.
Audit agents in Light are read-only by design. They inspect everything and change nothing, and they verify 2 different things. First, the output: does what the executive agents produced comply with policy. Second, the directive: do the instructions those agents are running on still comply with policy.
The second check is the one that catches real problems. An admin edited the Accrual Agent's instructions to skip anything under €20,000, reasonably enough, to save time at close. Every entry the agent subsequently produced was correct, so output testing would have passed it. The audit agent compared the instruction against policy, caught the mismatch, and flagged it in that month's control report together with the policy it broke, before the missing entries became a restatement.
That is a control operating on intent rather than on artefacts, and it is not something a sample of 40 transactions can find.
Auditors at customers with $500M ARR pull 100% of the journal population through the API. Not a sample of it.
Segregation of duties, mechanically
Segregation of duties is normally enforced by role configuration and verified by inspection of that configuration. It works until somebody accumulates permissions over 3 years of role changes and nobody re-inspects.
Each agent holds its own principal. Everything it does is tracked against that identity rather than disappearing into a shared service account, and a creation and update log ties the agent back to the human who made it and to anyone who has changed it since. Executive agents act within roles and approval limits the company sets. Audit agents cannot act at all. The separation is structural rather than configured, which makes it testable as a fact about the system instead of an assertion about its settings.
Old model
Sample and extrapolate
Test 40 items, document the method, infer the population. The control is evidenced by the testing rather than by the record.
Light's model
Test the population, continuously
Controls apply to every transaction. Audit agents verify outputs and the instructions behind them, and report monthly on what passed and what was flagged.
What changes
Reliance sets scope
Tested controls earn reliance, and reliance shrinks substantive testing to match the risk that actually remains.
Why this changes the cost of an audit
Controls-based auditing has a straightforward economic logic that rarely gets to operate. Controls that can be relied on reduce the substantive testing required, because the risk they cover is already addressed. In practice, reliance is hard to earn: the controls are manual, the evidence is a document describing them, and testing them is often more work than testing the transactions directly.
Controls applied to the full population, executed automatically, logged at every run and testable down to the agent that performed them are a different proposition. They meet what the standards actually ask for. Reliance follows, scope narrows, and the substantive work contracts to the areas where judgment genuinely lives.
The corollary matters as much: an engagement priced as though these controls do not exist, or hedged against agents editing a ledger that cannot be edited in place, is describing a different system. Part of being ready is an auditor who reads the ledger as it is.
The shift in what a controller does
A controller's week has historically been consumed by evidencing controls: pulling samples, assembling support, writing memos describing what was tested and why the conclusion holds.
When the control runs continuously and reports on itself, that work stops. What replaces it is designing the controls in the first place, deciding what the thresholds are, what an exception looks like, which policies the agents are checked against, and reviewing the monthly report of what got flagged.
That is a more senior job than the one it replaced. The teams doing this well are not the ones who automated their existing control matrix. They rewrote it for a system that can test everything, and stopped designing around a sampling constraint that no longer applies.
See how audits work in Light, whether an agent can be audited, the agents that run under policy, or book a demo.