Skip to main content

Why LLMs Cannot Write Ledgers Directly

At first glance, letting an LLM write accounting entries seems reasonable.

LLMs can:

  • Understand transaction descriptions
  • Infer debit and credit relationships
  • Generate balanced journal entries
  • Explain why an entry was created

In early prototypes, this often appears to work.

The problem is not whether an LLM can generate a ledger entry. The problem is what happens after that entry exists.

A real failure case from BookiAI​

During BookiAI development, we encountered a recurring class of issues documented in an internal report: AI-generated suggestion issues.

The model was asked to assist with journal entries based on transaction context.

The output looked correct:

  • Debits equaled credits
  • Accounts appeared reasonable
  • Explanations sounded confident

Yet the result was still wrong.

Not syntactically wrong.
Semantically and systemically wrong.

Ledger entries are not isolated actions​

A ledger entry is not a single write.

It is a trigger.

Once written, it affects:

  • Account balances
  • Financial statements
  • Tax calculations
  • Downstream reports
  • Future AI reasoning (feedback loops)

In one observed case:

  • The AI inferred an account based on incomplete context
  • The entry was balanced
  • But it violated internal account classification rules

Nothing broke immediately.

The error propagated quietly.

The illusion of correctness​

LLMs are extremely good at producing plausible correctness.

In the reported issues, the model:

  • Used correct accounting language
  • Followed common patterns
  • Explained its reasoning convincingly

However, the explanation was post-hoc, not authoritative.

The system had no way to know:

  • Which assumptions were made
  • Which rules were applied implicitly
  • What uncertainty existed

Once written, the ledger contained no trace of this ambiguity.

Corrections are not edits​

In accounting systems, mistakes are not fixed by editing records.

They are fixed by:

  • Reversals
  • Adjustments
  • Audit trails

When an LLM writes directly:

  • The system inherits the mistake
  • Reversal logic must be invented after the fact
  • Responsibility becomes unclear

Was the error:

  • A model hallucination?
  • A prompt issue?
  • A missing rule?
  • User intent misinterpretation?

Direct execution collapses all these distinctions.

Context is always incomplete​

Another issue revealed in the report was partial context.

The model often lacked:

  • Full chart-of-accounts constraints
  • Organization-specific accounting policies
  • Temporal state (what has already been booked)
  • Pending or provisional entries

Despite this, it still produced a confident answer.

LLMs do not say β€œI don’t know” unless explicitly designed to.

Writing a ledger entry requires certainty. Inference alone is insufficient.

The deeper problem: authority without accountability​

The core issue is not accuracy.

It is authority.

Writing to a ledger is an act of authority:

  • It asserts that something is true
  • It changes system state irreversibly
  • It creates obligations downstream

LLMs cannot be held accountable. Users should not silently inherit that accountability.

A system that allows LLMs to write ledgers has already abdicated responsibility.

What must change​

From these failures, a clear requirement emerged:

LLMs must not write ledgers directly.

Instead, they must:

  • Propose entries
  • Declare assumptions
  • Expose uncertainty
  • Submit results for governance

This leads directly to the architectural separation introduced in the next chapter.

What comes next​

If LLMs cannot write ledgers, what can they do safely?

πŸ‘‰ Generate / Review / Controller: separating roles and authority

Written by ChatGPT, reviewed by the BookiAI team.