Trust Issues – Anthony Garrett

Abstract

Large language models have created real economic value, but in accounting they run into a limit that better models do not remove. However accurate a model becomes, its output is a claim, not evidence. Coding agents get around this because their work runs against something they do not control: a compiler, a runtime, a test suite that either passes or fails. Financial statements have no equivalent. Their correctness is established by independent parties testing the record against evidence from separate sources until they reach reasonable assurance.

This paper argues that reducing hallucination will not close that gap. Accounting needs a different state architecture around the LLM, built on the structure the accounting standards already define: immutable evidence captured independently of the preparer, revisable entries, assertions linked to the evidence that supports them, materiality-based review, and controls that prevent any preparer, human or model, from approving its own work. Much of this architecture already exists in auditing and internal control. We map it to the state-centered design, identify what is genuinely new when the preparer is an AI agent acting at machine speed, and describe how Assert applies it to agent-initiated spend, including how an auditor can rely on it.

1. Introduction

Many of the ideas in this paper come, directly or indirectly, from Devanand Sharma's Fail Forward: Is It Time to Rethink LLM-Centered AI? That paper asks an uncomfortable question: what if we have built increasingly sophisticated AI systems on a foundation that was never designed to provide everything we now ask of it? It proposes designing AI less around "what is the most probable thing to say next?" and more around what is happening, what happened before, what happens after the system acts, and what should be learned from the outcome.

This paper applies this question to accounting.

Language models trained to predict text have become the foundation for coding agents and for agents in almost every other field. They create value by reasoning, drafting, deciding, and connecting information at a scale no team of people can match. This is not an argument about how to reach general intelligence. It is an argument about timing: which systems deliver the most economic value soonest, and what stands between LLMs and that value in domains where correctness cannot be checked the way code can.

Two questions run through the paper:

What does it take for an accounting record prepared with an LLM to reach reasonable assurance, when most accounting work produces no proof?
How does that answer generalize to other fields?

The paper makes three contributions. First, it separates the limits of LLMs in accounting into those no model can remove and those that come from how agents are built (Section 5). Second, it argues that the accounting standards already supply the structure an AI accounting system should be built on, and that audit assertions follow from that structure (Sections 4 and 7). Third, it describes an evidence ledger that grades evidence assertion by assertion and governs when AI-prepared entries can be booked (Section 8), applied to agent-initiated spend (Section 9).

Sharma's paper also raises a deeper research question: whether foundation models themselves should be redesigned. That question is out of scope. This paper concerns the architecture around the model, which can be built today.

Terms used from Sharma

Sharma's manuscript is unpublished, so the terms this paper borrows from it are defined here.

Term	Meaning in this paper
Observation	A record of something that happened, captured as it happened and never edited afterward
Interpretation	A conclusion drawn from observations, such as a classification or an estimate, which can be revised
Saga	The full lifecycle of a transaction or arrangement, from authorization through settlement and reconciliation
Outcome (δ)	A later event that confirms or contradicts an earlier interpretation
Thresholds (τ1, τ2)	Levels of discrepancy that decide whether a difference is ignored, reviewed, or escalated
Authority state	How much trust a piece of information carries, given where it came from
Baseline B+	A capable LLM given clean, timestamped, structured transaction logs and told to reconcile, with no additional architecture

2. What an LLM does, and what it cannot do

A modern LLM is pretrained to predict text, then trained further to follow instructions, reason through problems, and use tools such as search and code execution. It has become far more reliable, and there is evidence that models carry some calibrated sense of what they do and do not know (Kadavath et al., 2022). The labs are steadily reducing hallucination, and this paper does not assume that progress will stop.

The argument here does not depend on models staying unreliable. It holds even for a model that is never wrong in a way it could detect. Accounting does not ask whether the preparer believes a number is right. It asks whether the number is supported by evidence the preparer did not produce. A model's output, however accurate, is a claim about the world. It is not an observation of the world, and it does not become one by being stated confidently or calibrated well. Fluency is not evidence.

The common workarounds help, but they do not change this:

Retrieval gives the model better context. It does not verify that context. If unreliable or generated information enters the source, retrieval surfaces it more efficiently.
Multiple models can critique and debate one another, but their errors are correlated. In a study of more than 350 models, models that both got a question wrong chose the same wrong answer far more often than chance, and the correlation was highest among the most accurate models, even across different providers and architectures (Kim et al., 2025).
Self-review without an external signal is unreliable. Models asked to check and revise their own reasoning, with no outside feedback, often fail to improve and sometimes get worse (Huang et al., 2024).

LLMs can reach consensus. On their own, they cannot reach reasonable assurance.

3. Why coding agents work: an outside judge in the loop

Coding agents are the clearest commercial success of the current era. They create value not because they never make mistakes, but because their mistakes are caught.

It is tempting to say this is because tests are cheap. But coding agents often write their own tests, which on its face is the same self-review Section 2 warns against. What saves them is that the test does not judge the code. Execution does. The compiler, the runtime, and the test harness are outside the model. They do not share its training data or its blind spots, and they cannot be talked into a different answer. A weak test can still pass wrong code, and that remains a known failure, but the signal the agent receives comes from something it does not control.

That outside judge is:

Independent. It is not the model and does not share the model's errors.
Fast and cheap. It returns in seconds and costs almost nothing to run.
Repeatable. The same code gives the same result.
In the loop. The agent can write, run, see the failure, and fix it before anyone relies on the output.

This turns a probabilistic generator into a reliable system. The LLM proposes; the outside judge disposes.

Accounting has outside judges too: the bank, the counterparty, the customer, the auditor. They are slower, they each confirm only part of the picture, and some of them speak only once a year. Section 5.4 sets out which parts of an accounting record get a fast outside signal and which get a slow one or none at all. That difference, not the absence of verification, is what makes accounting hard for LLM-centered systems, and financial records matter because the rest of the economy acts on them.

4. How accounting knows things

Accountants work inside an interconnected web of evidence, with the understanding that information is never perfect. Three properties define that web.

Timing is uneven. Some confirmations arrive in seconds, such as a card authorization. Others arrive next week, next month, or when the auditor asks about the item a year later.
Evidence lives with third parties. Banks, counterparties, customers, and regulators hold much of what confirms a transaction, not the system that recorded it.
The record is incomplete. No one can generate a proof that a set of financial statements is fully correct.

The accountant's job is to assemble this evidence into an account of the business, within a defined framework for reporting financial results. A P&L is not absolute. No test can say it is true. It is a record: a body of evidence that independent parties can examine and try to prove wrong.

The structure the standards impose

That framework is not a style guide. Financial reporting standards define a fixed structure that every record must fit, and an entry that does not fit it is wrong however well it is written. The structure has layers, each answering a narrower question:

Elements. What kinds of things can exist in a financial record. The FASB Conceptual Framework defines a closed set (Concepts Statement No. 8, Ch. 4): assets, liabilities, equity, revenues, expenses, gains, losses, investments by owners, distributions to owners, and comprehensive income. Every amount on a balance sheet or income statement is an instance of one of them.
Recognition. When an event becomes an entry. An item is recorded only when it meets three criteria: it fits the definition of an element, it is measurable, and it can be represented faithfully. It is removed when it no longer meets any one of them (Concepts Statement No. 8, Ch. 5).
Measurement. What amount the entry carries. The framework describes two systems: entry price, anchored in what was paid (as with historical cost), and exit price, anchored in what the item could be sold or settled for (as with fair value) (Concepts Statement No. 8, Ch. 6).
Presentation and disclosure. Where the entry appears in the statements and what must be said about it (Concepts Statement No. 8, Chs. 7–8).

The Conceptual Framework is nonauthoritative: it guides the FASB in setting standards. Authoritative US GAAP for nongovernmental entities is the Accounting Standards Codification (ASC 105-10-05-1), which applies this structure to specific kinds of transactions. The Codification is organized by Topic (606 for revenue from contracts with customers, 842 for leases), each Topic is divided into Subtopics, and Subtopics use a standard set of numbered Sections, including 15 Scope, 20 Glossary, 25 Recognition, 30 Initial Measurement, 35 Subsequent Measurement, 40 Derecognition, 45 Other Presentation Matters, and 50 Disclosure. A reference such as 606-10-25-1 is an address: Topic, Subtopic, Section, Paragraph. Recognition guidance sits in Section 25 whether the subject is revenue or leases.

IFRS has a parallel structure. The IASB Conceptual Framework for Financial Reporting (2018) uses a smaller set of elements (assets, liabilities, equity, income, and expenses), but follows the same sequence of definition, recognition, measurement, and presentation.

This structure already exists in machine-readable form. The FASB maintains the GAAP Financial Reporting Taxonomy, a set of XBRL tags that SEC registrants use to label the numbers in their filings, and updates it each year as the standards change. Registrants are required to file this tagged data with the SEC (Regulation S-T, Rule 405).

What is fixed is the standards, not each company's books. A company's chart of accounts and accounting policies are its own, but they must map onto the standards' elements and Topics. That mapping is where an AI system should anchor.

Evidence tells an accountant what happened. The structure tells them what it is. An accounting record is true, in the sense an audit cares about, only when it is both supported by evidence and placed correctly within the structure. The audit assertions in Section 8 are the questions this structure asks of each record: existence asks whether an element really exists, classification asks whether it was assigned to the right element and account, and accuracy and cutoff ask whether it was measured and recognized correctly.

The audit as independent consensus

The audit is how the business world establishes that a record can be trusted. It is the verification behind decisions to invest, lend, buy, sell, and produce. Its strength comes from independence: the auditor is separate from the preparer and tests the record against evidence from separate sources.

For most companies, no human can review every transaction produced in a period. Internal controls fill that gap. They provide evidence that the system producing the information operates reliably, so that sampling and testing can support conclusions about the whole (PCAOB AS 2201; COSO, 2013).

Reasonable assurance, not ultimate truth

The audit standard is not certainty. It is reasonable assurance that the statements are free of material misstatement (PCAOB AS 1000; ISA 200). Truth in accounting is therefore a claim that survives independent attempts to falsify it and traces back to evidence.

This gives a design target. An accounting system should be built for traceable sufficiency: every number knows what evidence supports it, which assertions that evidence covers, how strong it is, and what remains unresolved.

5. The limits of LLMs in accounting

Set next to how accounting establishes truth, the limits of an LLM-centered approach become specific. They fall into two groups, and the difference matters. The first group cannot be removed by a better model, because it follows from what accounting requires of evidence. The second group comes from how agents are typically built, and a well-designed system can address it. The first group is why a different architecture is needed. The second is what that architecture has to provide.

Limits no model can remove

5.1 A model's agreement is not independent evidence

An audit reaches assurance through agreement among independent sources. When the bank says $4,200, the invoice says $4,200, the mandate authorized up to $5,000, and the counterparty's identity is verified, four observers each could have disagreed. Their agreement is verification.

Several LLMs agreeing do not have that property. They share training data, failure modes, and blind spots, and their errors are measurably correlated (Kim et al., 2025). Consensus among generators is not verification. Agreement among independent evidence sources is.

5.2 A preparer cannot approve its own work

Accounting assumes preparers make mistakes and that some may act in bad faith. That is why the preparer is never the approver (COSO, 2013, Principle 10). Segregation of duties exists to limit both error and fraud, not because two people are guaranteed to think differently. Accountants share training and blind spots too.

An LLM asked to approve its own entry is the same process evaluated twice. An LLM can still play a useful role in review: it can check another preparer's work, flag anomalies, and point to missing evidence, and auditors themselves now use technology-assisted analysis under PCAOB standards (PCAOB AS 1105, as amended in 2024). The line this paper draws is narrower than "never a reviewer." An LLM may prepare and may flag. Its review output is itself an inference and is graded as one. It may not approve. Approval belongs to deterministic controls, materiality thresholds, and people with the authority to approve.

Using models from different vendors reduces correlation but does not remove it. Independence in this architecture comes from evidence, not from the number of models that looked at an entry.

5.3 Completeness cannot be evidenced from inside the model

The completeness assertion (ISA 315 (Revised 2019)) asks whether everything that should be recorded has been recorded. A model can only reason about what is in front of it. It cannot know what it was never shown. Completeness requires evidence from outside: bank statements, counterparty records, cutoff tests.

5.4 Outside signals are uneven, and some never arrive

A coding agent gets its outside signal before anyone relies on its output. An accounting agent gets outside signals on some assertions quickly and on others late or never. Agent-initiated spend shows the pattern clearly:

Assertion	Outside signal	Typical timing for agent spend
Existence / occurrence	Card authorization, settlement, on-chain confirmation	Seconds to days
Accuracy	Settlement amount, receipt	Seconds to days
Cutoff	Transaction and settlement timestamps	Seconds to days
Classification	None from outside; depends on purpose, contract terms, and policy	No automatic signal
Rights and obligations	Contract, mandate chain, delivery or service evidence	Days to months, often incomplete
Completeness	Reconciliation to bank, card, and wallet statements	Daily to monthly, if performed
Valuation (refunds, disputes, credits)	Counterparty action, chargebacks	Weeks to months

Where the outside signal is fast, an LLM-prepared entry can be checked almost as quickly as code. Where it is slow or absent, the model must commit to an interpretation long before anything outside can test it. Those assertions are where an AI accounting system must be most careful, and where most of the value of an evidence architecture lies.

Limits of a naively built agent

5.5 Generated output does not record its own provenance

An LLM's output does not distinguish what was observed from what was inferred. A classification, an accrual estimate, and a transcribed bank amount all arrive as equally fluent text. If inferred content is stored alongside source evidence without a label, the ledger is contaminated: future reasoning treats a guess as a fact. A system can fix this by labeling every field with its source. Most agents today do not.

5.6 No persistent state across the accounting cycle

Accounting work spans periods. A contract's revenue, a lease, a dispute, or an accrual runs across months or years. Models work in sessions. Agent frameworks add memory, but memory that stores conversation history or summaries is not a ledger: it does not tie each interpretation to the evidence behind it, and a later outcome cannot reliably find and reopen the earlier interpretation it contradicts.

5.7 Confidence is not calibrated to materiality

Accounting scales its scrutiny to consequence: a $12 rounding difference and a $2 million revenue cutoff error are handled differently (PCAOB AS 2105; ISA 320). A model's fluency is the same for both. Materiality is also not only a per-item threshold. Misstatements that are individually trivial can be material in aggregate (ISA 450), and some items are material because of what they are, not their size, such as a breach of policy or a related-party payment (SEC Staff Accounting Bulletin No. 99). A system needs explicit thresholds, set outside the model, for individual items, for aggregates, and for qualitative flags.

6. A different state architecture

Accounting already has a working method for handling untrusted information. It is called auditing and internal control. Much of what Sharma proposes as new architecture (immutable observations, revisable interpretations, authority states, reconciling by exception) exists in accounting practice under other names.

Sharma's concept	Accounting equivalent
Immutable observation log	Source evidence: bank feeds, invoices, receipts, contracts, on-chain transactions, signed mandates
Versioned interpretations	Journal entries, classifications, accruals, estimates. Accounting does not erase; it reverses and adjusts
Saga	A transaction lifecycle: mandate → spend → settlement → reconciliation, or a contract's revenue over its life
Outcome (δ)	Settlement, bank clearing, counterparty confirmation, reconciling differences
Thresholds (τ1, τ2)	Materiality: clearly trivial, performance materiality, overall materiality (ISA 320; ISA 450; PCAOB AS 2105 uses "tolerable misstatement")
State = Unknown	The suspense account
Authority states	The audit evidence hierarchy: external beats internal, documentary beats oral, directly obtained beats inferred (PCAOB AS 1105.08; ISA 500)
"Generated language must not promote itself into trusted state"	Segregation of duties: the preparer is never the approver (COSO, 2013)

The last row is the core design rule: the LLM can prepare and can flag, but it never approves. It may draft entries, propose classifications, match transactions, and point out contradictions. It may not promote its own output, or another model's, into booked, trusted state.

Compute what can be computed

Accounting also has a deterministic layer where something close to proof does exist: debits equal credits, subledgers tie to the general ledger, roll-forwards foot, cutoff dates are checked, mandate limits are enforced. This layer should be computed, not generated. It is accounting's version of the coding agent's outside judge, and it should run on every entry. Probability belongs where judgment is genuinely required: classification, estimation, and interpreting ambiguous evidence.

Persistent state lives outside the model

In this architecture, the evidence and its interpretations are the primary object of the system. The LLM is one replaceable processor that operates on that state. Swapping the model should not change the evidence, the entries, or the authority each one carries.

What is new here, and what is not

A fair objection is that this describes what accounting systems already do. Double-entry bookkeeping, audit trails, and approval workflows are standard in every ERP. Researchers have also long proposed building accounting systems around economic events rather than debits and credits: the Resources–Events–Agents (REA) model (McCarthy, 1982; McCarthy, Geerts and Gal, 2022) records the underlying events and derives ledger views from them, continuous auditing (Vasarhelyi and Halper, 1991) moves audit procedures close to the moment transactions occur, and triple-entry accounting (Grigg, 2005) has a shared third party record each transaction. This paper builds on all three.

What changes when the preparer is an AI agent is the following:

The preparer is a generator, not a person. Existing controls assume a human preparer whose work is occasional and whose judgment is accountable. An AI preparer produces entries continuously, at machine speed, with fluent output that looks the same whether it is observed or invented.
Evidence must be captured at the moment of action, by a party other than the actor. When an agent spends, the evidence a human process leaves behind (emails, receipts, sign-offs) may never exist unless it is captured as the spend happens, and the agent's own account of what it did is not independent evidence.
Provenance is recorded field by field. Every value carries a label saying whether it was observed or inferred, and by what.
Entries carry their assertions. Each entry records which assertions it makes and which evidence supports each one, so review and audit can test assertions directly rather than reconstruct them.
Contradictions reopen interpretations automatically. A later outcome finds the interpretations it contradicts and reopens them, leaving the original evidence untouched.

7. An architecture for accounting events

Section 6 describes how state should be held: immutable evidence, revisable interpretations, and controls on promotion. It does not say what that state describes. For accounting, the answer already exists. The system should be built around accounting events, as REA proposed, and every event should be described in the structure the standards define (Section 4), not in a structure invented for the software.

Accounting events as the unit of record

An accounting event is something that happened to the entity and may change its financial position: a spend, a receipt, a contract signed, a service delivered, a payment settled. The event is captured as evidence. Everything after that is interpretation, and each step of interpretation corresponds to a layer of the standards:

Layer	Question it answers	What the system records
Event	What happened?	Source evidence, timestamped and append-only
Element	What kind of thing is it?	Asset, liability, equity, revenue, expense, gain, or loss
Recognition	Should it be recorded, and when?	The recognition criteria met, the governing ASC Topic, and the period
Measurement	At what amount?	The measurement basis and its inputs: invoice price, settlement amount, or estimate
Classification	Which account?	The company's chart-of-accounts mapping, linked to the element and its taxonomy tag
Presentation and disclosure	Where and how is it reported?	The line item and any required disclosures

Assertions follow from the structure

Because each interpretation sits at a known place in the structure, the system knows which assertions it makes. An expense recognized under a given Topic asserts that the expense occurred, that it belongs to this period, that the amount is right, and that it sits in the right account. Those assertions are not written by the model. They follow from where the entry sits, and each must be linked to evidence before the entry can be promoted to booked state (Section 8).

What the structure does and does not settle

The structure changes what the LLM is asked to do. It is not asked to produce an accounting record from a blank page. It is asked to propose where an event belongs within a fixed structure: this event is an expense, recognized under this Topic, measured at this amount, in this account.

That narrows the choice, but it does not make every choice checkable. Deterministic rules can reject placements the structure does not allow, such as an asset with no evidence of rights to it, an expense posted to a closed period, or a spend above its mandate. They cannot settle the judgments where most accounting risk lives: whether the company is a principal or an agent, whether an arrangement is a lease or a service, whether a cost should be capitalized or expensed. Agent spend creates new versions of these questions. Prepaid AI compute credits, for example, may be a prepaid asset, an intangible, or an expense depending on their terms and how they are consumed.

For judgments like these, the system's job is not to make them verified. It is to make them explicit: record the alternatives considered, the Topic and company policy applied, the evidence relied on, and who or what made the call, and route the decision for human review when its materiality warrants. A judgment that is recorded, reasoned, and reviewable is what an auditor needs. A judgment buried in fluent text is not.

The structure also keeps the system legible to the people who rely on it. Auditors, regulators, and reviewers already think in it. An entry that carries its element, its governing Topic, its measurement basis, and its assertions can be reviewed the way any accountant reviews work, and mapped to the GAAP taxonomy for reporting without a translation layer.

The structure is fixed; interpretations are not

The three parts of the system change at different rates. Evidence never changes; it is append-only. Interpretations change whenever new evidence contradicts them. The structure changes only when the standards do, through Accounting Standards Updates and the annual taxonomy release, or when the company formally changes its chart of accounts or policies. The model may propose where an event belongs. It never extends or reshapes the structure on its own.

8. The evidence ledger

The state store at the center of this architecture is an evidence ledger: an append-only record of source evidence, with every interpretation linked to the evidence that supports it. It is not a retrieval layer the LLM searches. It is the system of record the LLM works on.

Assertions as the schema

The audit assertions, which Section 7 derives from where each entry sits in the structure, provide a ready-made schema. Every recorded transaction implicitly makes these claims, and each can be tied to specific evidence:

Assertion	Question it answers	Typical evidence
Existence / occurrence	Did this really happen?	Bank settlement, counterparty confirmation, signed mandate
Completeness	Is everything that happened recorded?	Bank statements, counterparty records, cutoff tests
Accuracy	Is the amount right?	Invoice, receipt, settlement amount, price source
Cutoff	Is it in the right period?	Transaction and settlement timestamps
Classification	Is it in the right account?	Contract terms, vendor and purpose metadata, policy
Rights and obligations	Does the entity actually own or owe this?	Contracts, mandates, title and custody records

The table follows the assertions in ISA 315 (Revised 2019), paragraph A190, and AICPA AU-C 315. PCAOB AS 1105.11 groups the same ground into five broader categories: existence or occurrence, completeness, valuation or allocation, rights and obligations, and presentation and disclosure.

Authority is graded per assertion

Evidence is not strong or weak in general. It is strong or weak for a particular assertion. A cleared bank settlement is close to conclusive that cash moved, in what amount, and when. It says nothing about which account the spend belongs in, and little about whether the company received what it paid for. Grading a piece of evidence once, with a single rank, would overstate what it proves. The ledger therefore grades each pairing of evidence and assertion:

Evidence	Existence	Accuracy	Cutoff	Classification	Rights and obligations
Bank or card settlement	Strong	Strong	Strong	None	Weak
Counterparty invoice or receipt	Moderate	Strong	Moderate	Moderate	Moderate
Signed mandate	Moderate	Limit only	None	Moderate	Strong
Contract	Weak	Moderate	Weak	Strong	Strong
LLM classification	None	None	None	Inferred	None

Each grade draws on an authority scale that follows the audit evidence hierarchy (PCAOB AS 1105.08; ISA 500):

Machine-verified external: produced by an independent system, such as a bank, a card network, or a public blockchain.
Externally attested: a counterparty confirmation or a third-party document.
Internally generated under tested controls: records produced by company systems whose controls have been tested, such as a mandate issued through a controlled approval process.
Human-attested: an approver's sign-off. Management representations belong here only as corroboration; auditing standards treat them as insufficient on their own (PCAOB AS 2805; ISA 580).
Empirically supported: a consistent recurring pattern, such as a known vendor's monthly charge.
Inferred: an LLM's classification, match, or review.
Unresolved: evidence conflicts or is missing; the item sits in suspense.

How evidence combines

Section 5.1 argues that agreement among independent sources is what creates assurance, so the ledger needs a rule for combining evidence, not just ranking it:

Assertion by assertion. An entry's support is assessed separately for each assertion it makes. An entry is only as well supported as its weakest required assertion.
Independent sources corroborate. Two sources of different origin that agree on the same assertion count for more than either alone, and can together meet a threshold that neither meets by itself.
Correlated sources count once. Evidence that traces back to the same origin, such as an invoice and a receipt both generated by the vendor's same system, or two models' outputs, counts as one source.
Inference never raises support. An inferred grade can direct attention, but it never lifts an assertion above the grade of its non-inferred evidence.

Promotion to booked

An entry moves from proposed to booked only when every assertion it makes meets the threshold its materiality requires. Thresholds are set by people, outside the model, and apply at three levels: the individual item, aggregates (per agent, per vendor, per period), and qualitative flags that trigger review regardless of amount, such as a new counterparty, a related party, or a policy exception. Model confidence plays no part in promotion.

9. Example application: Assert and agent-initiated spend

Agent-initiated spend makes every limit in Section 5 sharper. An AI agent may be the requester, the spender, and potentially the bookkeeper, all at machine speed. The evidence a human process naturally leaves behind can vanish unless it is captured at the moment the agent acts.

Independent capture

The most important design choice in Assert is that evidence is not captured by the agent that spends. If the spending agent records its own mandate, receipt, and description of what it bought, that record is internal evidence produced by the party being checked, the same self-review problem Section 5.2 describes. Assert sits outside the spending agent and captures evidence from the payment rail, the card network or wallet, and the counterparty. The agent's own account of the spend is recorded too, because it is useful context, but it is graded as internal and never used as the sole support for any assertion.

Verifying the mandate

A mandate is only as good as the authority behind it, and in agent systems mandates may themselves be issued by other agents. Assert records the full mandate chain: who issued the mandate, under what delegation of authority, with what limits, scope, and expiry, and whether it has been revoked. Every chain must trace back to a person or a policy approved by people with the authority to approve it. A mandate that has expired, has been revoked, or exceeds the issuer's own authority is treated as a missing mandate.

How Assert works

Capture independently, at the moment of action. For every spend, record the mandate chain, the settlement, the receipt, the counterparty's identity, and the price source, from sources other than the spending agent.
Store it append-only. Evidence is never edited. Corrections arrive as new evidence and new entries.
Grade it per assertion. Each piece of evidence is graded for each assertion it bears on.
Let accountant agents prepare. LLM agents propose classifications, matches, and entries on top of the evidence, with every inferred field labeled.
Run the deterministic checks. Mandate limits, balancing, cutoff, duplicates, and reconciliations run on every entry.
Let controls approve. Promotion to booked follows the rules in Section 8, with human review where thresholds require it, never on the preparing model's confidence.
Reconcile by exception. When settlement, a refund, a dispute, or a counterparty contradicts an entry, the affected interpretation is reopened and revised; the original evidence stays intact.

Completeness

Assert cannot evidence completeness from its own records, for the reason in Section 5.3: it cannot see spend it was never shown. An agent might pay through a rail Assert does not monitor. Assert therefore reconciles its captured spend to the company's bank, card, and wallet statements. Any outflow on those statements that Assert did not capture becomes a reconciling item in suspense, and repeated uncaptured spend by the same agent is itself a control exception.

Aggregation and fraud risk

Agent spend is high in volume and often low in value per transaction. A threshold set only per transaction is an invitation to split spend into amounts below it. Assert applies thresholds to aggregates as well as to individual items, monitors spend velocity per agent and per counterparty, and flags qualitative risks such as new counterparties, related parties, unusual merchant categories, and policy exceptions regardless of amount.

How an auditor relies on Assert

Once a company uses Assert in its close, Assert becomes part of the company's internal control over financial reporting, and its auditor will need to rely on it. That reliance has three parts:

Controls over Assert itself. Auditors test IT general controls over systems that produce financial information: who can access them, how changes are made, and how they operate (PCAOB AS 2201 for integrated audits of public companies).
An independent report on those controls. For a service used by many companies, the usual route is a SOC 1 Type II report, in which a service auditor tests the design and operating effectiveness of the service's controls over a period (AICPA AT-C 320). The report also lists the controls each customer must operate on its own side, such as setting thresholds and approving mandates.
Direct access to evidence. Because every entry links to its source evidence and its assertions, an auditor can select a sample of entries and trace each one to evidence that did not pass through the spending agent, or reperform the deterministic checks directly.

The product name reflects the idea. An assertion is a claim that must be supported by evidence. Assert's job is to make sure every claim behind an agent's spend can be traced to evidence the agent did not produce.

10. Generalizing beyond accounting

The same reasoning applies wherever correctness cannot be checked in seconds. For any field, four questions determine how to build the state architecture:

What is the evidence hierarchy? Which sources outrank which, and for which claims?
What is deterministic? Which parts can be computed rather than generated?
What is the delayed outcome? What later event confirms or contradicts an interpretation?
Who is the independent attestor? Who, outside the system, can try to prove the record wrong?

Insurance claims show how the questions apply outside accounting. The evidence hierarchy runs from adjuster inspections and police or medical reports down to the claimant's own statement. The deterministic layer includes coverage dates, policy limits, deductibles, and exclusions. Delayed outcomes include subrogation recoveries, litigation, and reopened claims. Independent attestors include reinsurers, regulators, and actuaries. An AI claims assistant built on this architecture would prepare claim assessments, but coverage decisions would be promoted only on evidence graded for each element of the claim.

Accounting is the right first field because a century of auditing standards answers all four questions explicitly. Insurance, legal work, and clinical documentation have partial answers and are natural next candidates. Coding got there first because its outside judge is built in. Accounting gets there when someone builds the equivalent structure around it.

11. What this does not solve

This architecture does not make financial statements certain. It aims at reasonable assurance. Several problems remain open:

Matching and lifecycle assignment. Deciding which transaction lifecycle a piece of evidence belongs to is the hard version of bank matching. A payment may relate to several invoices, or to none yet.
Attribution. When a reconciling difference appears, identifying which earlier entry or assumption caused it is not always possible. The system must be able to say "this conflicts, and the cause is unknown" rather than guess.
Judgment-heavy areas. Placement judgments (principal or agent, lease or service, capitalize or expense) and estimates such as allowances and impairments will always rest partly on inference. The architecture records and routes them; it does not make them verified.
Model independence. How much independence, if any, models from different vendors provide is an open empirical question. This paper assumes very little.
Review burden and cost. Grading evidence, applying thresholds, and reconciling by exception add work. If thresholds are set too tightly, review volume could exceed the effort of preparing entries by hand.
Auditor and regulatory acceptance. Whether auditors will accept evidence graded this way, and how standard setters will treat AI preparers, is still developing.
Foundation-model design. Whether models themselves should change is out of scope.

12. Testing the thesis

The thesis should be falsifiable. It should be tested against the alternatives a capable team would actually build, not only against the weakest one.

Three approaches

Baseline B+: a capable LLM given clean, timestamped, structured transaction logs and told to reconcile.
Baseline C: an LLM agent with deterministic checks and a human approver, but no evidence ledger, no per-assertion grading, and no independent capture. This is the strongest realistic alternative.
Evidence ledger: the architecture in Sections 6 to 9.

Scenarios

Each approach closes one month of a company's agent-initiated spend, using real or realistically messy data, with planted cases. Some play to the architecture's strengths:

a refund that arrives after the period closes;
a duplicate charge;
a spend that exceeds its mandate;
a counterparty that fails identity verification.

Others are designed to stress it:

an ambiguous classification, such as prepaid AI compute credits;
one payment split across several invoices;
a mandate that is valid on its face but expired or revoked;
many small spends that are individually trivial but material in aggregate;
a spend made on a rail the system does not monitor.

Measures

Measure	Question
Evidence fidelity	Was the original evidence preserved unchanged?
Accuracy	How many booked entries were wrong, compared with a close prepared by experienced accountants?
Targeted revision	Were only the affected entries revised?
Restraint	Were entries left alone when new evidence did not contradict them?
Contamination	Was anything inferred booked as if it were verified?
Escalation	Were unresolved items routed to suspense or review instead of guessed?
Review burden	How many items went to human review, and how many of those needed no change?
Cost	What time, compute, and human review did the close require?

What would count against the thesis

Pass and fail criteria should be fixed and published before the test is run. The thesis is weakened if Baseline C matches the evidence ledger on contamination, escalation, and accuracy within the pre-set margin; if the evidence ledger fails the stress cases at a similar rate to the baselines; or if its review burden makes the close slower or more expensive than an experienced team working by hand.

13. Conclusion

Coding agents create outsized value because their work is checked by something outside the model, cheaply and immediately. Most economically important work has no such judge built in. Accounting is the clearest example: a P&L cannot be proven, only supported by evidence and tested by independent parties until it reaches reasonable assurance.

LLMs can make an answer more likely to be right, but they cannot make it independent. The answer is not a model that hallucinates less. It is the structure accounting already uses for fallible preparers, adapted for preparers that act at machine speed: evidence captured independently at the moment of action, entries that carry their assertions, evidence graded assertion by assertion, materiality-based review, and controls that keep any preparer, human or model, from approving its own work.

Put that structure outside the LLM, and the model becomes what it is best at being: a powerful, replaceable preparer.

References

Primary source

Sharma, Devanand. Fail Forward: Is It Time to Rethink LLM-Centered AI? From Next-Token Prediction to Persistent, Experience-Based Intelligence. Unpublished manuscript.

Research on language models

Huang, Jie, et al. "Large Language Models Cannot Self-Correct Reasoning Yet." International Conference on Learning Representations (ICLR), 2024. arXiv:2310.01798.
Kadavath, Saurav, et al. "Language Models (Mostly) Know What They Know." arXiv:2207.05221, 2022.
Kim, Elliot Myunghoon, Avi Garg, Kenny Peng, and Nikhil Garg. "Correlated Errors in Large Language Models." Proceedings of the 42nd International Conference on Machine Learning, PMLR 267: 30038–30066, 2025.

Accounting systems and auditing research

Grigg, Ian. "Triple Entry Accounting." Systemics Inc., 2005.
McCarthy, William E. "The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment." The Accounting Review 57, no. 3 (1982): 554–578.
McCarthy, William E., Guido L. Geerts, and Graham Gal. The REA Accounting Model as an Accounting and Economic Ontology. American Accounting Association, 2022.
Vasarhelyi, Miklos A., and Fern B. Halper. "The Continuous Audit of Online Systems." Auditing: A Journal of Practice & Theory 10, no. 1 (1991): 110–125.

Accounting standards and frameworks

Financial Accounting Standards Board (FASB). Statement of Financial Accounting Concepts No. 8, Conceptual Framework for Financial Reporting: Chapter 4, Elements of Financial Statements (December 2021); Chapter 5, Recognition and Derecognition (August 2023); Chapter 6, Measurement (July 2024); Chapter 7, Presentation (December 2022); Chapter 8, Notes to Financial Statements (August 2018). Nonauthoritative.
FASB. Accounting Standards Codification, Topic 105, Generally Accepted Accounting Principles (including 105-10-05-1). Topics 606 and 842 are cited as examples.
FASB. GAAP Financial Reporting Taxonomy, 2026 release (December 2025).
International Accounting Standards Board (IASB). Conceptual Framework for Financial Reporting (March 2018).
U.S. Securities and Exchange Commission. Regulation S-T, Rule 405, Interactive Data Files (17 CFR 232.405).
U.S. Securities and Exchange Commission. Staff Accounting Bulletin No. 99, Materiality (1999).

Auditing and attestation standards

Public Company Accounting Oversight Board (PCAOB). AS 1000, General Responsibilities of the Auditor in Conducting an Audit (PCAOB Release No. 2024-004; effective for fiscal years beginning on or after December 15, 2024; replaces AS 1001, 1005, 1010 and 1015).
PCAOB. AS 1105, Audit Evidence, paragraphs .08 and .11 (as amended by PCAOB Release No. 2024-007, effective for fiscal years beginning on or after December 15, 2025).
PCAOB. AS 2105, Consideration of Materiality in Planning and Performing an Audit.
PCAOB. AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements.
PCAOB. AS 2805, Management Representations.
International Auditing and Assurance Standards Board (IAASB). ISA 200, Overall Objectives of the Independent Auditor and the Conduct of an Audit in Accordance with International Standards on Auditing.
IAASB. ISA 315 (Revised 2019), Identifying and Assessing the Risks of Material Misstatement, paragraph A190.
IAASB. ISA 320, Materiality in Planning and Performing an Audit.
IAASB. ISA 450, Evaluation of Misstatements Identified during the Audit.
IAASB. ISA 500, Audit Evidence. Citations are to the extant standard; a proposed ISA 500 (Revised) was exposed for comment in August 2026, with comments due December 15, 2026.
IAASB. ISA 580, Written Representations.
American Institute of CPAs (AICPA). AU-C 315, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement (as revised by SAS No. 145).
AICPA. AT-C 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting (SOC 1).

Internal control

Committee of Sponsoring Organizations of the Treadway Commission (COSO). Internal Control—Integrated Framework (2013).