By Chris Bell, Product Manager, Record to Report
Every audit used to open the same way: with a request list. Dozens of items, weeks of assembly, a shared folder slowly filling with exported reports, screenshots, and spreadsheets rebuilt for the occasion. At a Light customer, the opening move is different. The auditor connects to the ledger through the API, extracts the full population of entries, and starts testing, because the evidence was assembled the moment the work happened.
The audit of a Light customer is not an archaeology project. Everything the auditor needs exists, structured and attributable, from the moment of the transaction, and it stays that way whether the audit starts next month or in 3 years. None of this is a roadmap promise: customers with $500M ARR have already completed audits running on Light.
ARR at customers that have already completed audits running on Light
of the journal population extracted through the API. The auditor tests the whole record, not a sample
later, the evidence is identical: structured, attributable, and extractable from the moment of the transaction
Audit-first architecture
3 structural properties of the platform do the work:
Property 1
The ledger is immutable
An entry, once posted, is never edited in place. A correction is a new entry that references the original, so the record only ever grows. The trial balance the auditor pulls today reconciles to the entries as they were posted, not as someone later remembered them.
History is only ever extended, never rewritten
Property 2
Every change carries an audit log
Not just entries: everything across the platform. Approvals, payments, master data, and the configuration itself. When an approval threshold changes, that change is logged with the same rigor as a journal entry, so the auditor can test not only the transactions but the controls that governed them, as they stood at any point in the year. Each logged action is attributable: which human or which agent acted, on what evidence, under which policy. This is why the trail gets stronger, not weaker, when agents do the mechanical work.
Every action attributable
Property 3
The record is extractable
Light exposes an open API, and auditors connect to it directly. Data that is stored but cannot leave the system comforts the vendor rather than the auditor, so Light works on a simple principle: anything the system stores, the auditor can extract.
The system stores everything
What fieldwork looks like
Those 3 properties change the shape of the auditor's week. Sampling from printouts is a concession to systems that cannot produce their whole record; against an open API, the full journal population is a query. The auditor pulls it, runs their own analytics over it, and chooses where to look closer. Tracing an item is a walk rather than an excavation: from the trial balance line to the entry, from the entry to the source document, the approval chain, and the policy that allowed the posting, every step recorded at the time it happened. The question "why was this posted" is answered by the log, in identical structure for every entry, whether a human posted it or an agent did.
Auditors can use the Audit role in the Light web app to download transactions in bulk when they need to process billions of transactions in their own audit system.
The platform's own controls arrive already tested. Light holds SOC 1 Type 2 and SOC 2 Type 2 reports, so the auditor starts from an examined baseline instead of a questionnaire.
The agent audits continuously
The auditor is no longer the first to test the ledger. Astra, Light's accounting agent, tests it continuously. Each entry is reconciled to its source and checked against policy as it posts, so an exception surfaces the moment it appears, not at quarter-end after it has hardened into a finding. The agent that does the mechanical accounting is the same one watching it.
The exception surfaces where the work already happens. Astra raises it in Slack, in Teams, or on mobile, in the thread the controller is already reading. There is no separate audit queue to open, no dashboard anyone has to remember to check.
The fix is a reply. The controller answers in chat, in 1 sentence, and Astra posts the correcting entry: referenced to the original, coded, logged with who approved it and why. The correction is not a detour around the audit trail. It is the audit trail, written the moment the question is asked.
The same door is open to the auditor. Light runs an MCP server, so a customer or their auditor connects their own chat interface straight to the ledger and does the work through it. The auditor asks, in plain language, for the entries behind a balance, the approvals behind a payment, the policy that allowed a posting, and the ledger answers, every query logged like any other access. The audit stops being a place the auditor visits and becomes a conversation they open whenever they want.
A different control mindset
A control used to mean a person performing a check on a schedule: a review signed at month-end, a reconciliation ticked at quarter-end, an exception found whenever someone looked. What the agent does all year is the same work under a different mindset. The check runs at the moment of the transaction, on every transaction, without being scheduled by anyone.
- Astra marks every transaction for completeness. Each source item is matched to its entry and each entry to its source as it posts, so a gap in the record surfaces as an exception the day it opens, not as a discovery at year-end. Completeness stops being an assertion the auditor proves by sampling and becomes a property the ledger demonstrates across the whole population.
- Astra flags every bill against its contract. Price, quantity, and terms are checked before approval, and a mismatch is written onto the record, where it stays. The 3-way match runs on 100% of bills as they arrive, not on the sample an audit team pulls months later.
- Astra comments on anomalies. An entry that breaks pattern (an unusual amount, a duplicate, a counterparty the ledger has not seen before) carries the agent's comment and its reasoning from the moment it posts. The year's exceptions arrive documented; nobody reconstructs them in fieldwork.
These are controls in the sense the auditing standards use the word: automated, applied to the full population, logged at every execution, and testable down to the agent itself. Tested controls earn reliance, and reliance sets scope: the substantive testing shrinks to match the risk that remains, which is the whole economic point of a controls-based audit. The auditors who have completed Light audits scope them exactly this way. An engagement priced as if these controls did not exist, or hedged against agents editing a ledger that nothing can edit, is a description of a different system than the one in front of it. Part of being audit-ready is an auditor who reads the ledger as it is.
The request list is the relic
From inside a Light audit, the traditional evidence package looks like the fax cover sheet: a ritual kept alive long after anyone remembered what problem it solved. The PDF exported "as of" a date nobody can reproduce. The spreadsheet named final. The screenshot proving a number existed at the moment of the screenshot. Every artifact on that list exists because the system of record could not be trusted to speak for itself. A ledger that cannot be edited in place, logs every change, and hands its full contents to the auditor on request has no need for the ritual.
Controllers come to this conversation carrying the belief that AI in the ledger makes the audit harder. The completed audits at customers with $500M ARR closed that question. What remains open is only scheduling: how many more closes a team spends assembling evidence by hand for a record that has been assembling its own all along.
Chris Bell is a Product Manager on the Record to Report team at Light, the agentic accounting platform. See how Light approaches security and compliance, or book a demo.