How the Ledger Module Actually Works: SQLite, Regex, and Avoiding LLM Maths

We built Kep's Ledger module with accountants in mind, but it's useful for anyone who needs to work with financial figures in documents without pasting them into a cloud chatbot. Here's the technical reality under the hood — no fluff, just the facts.

The Core Problem: LLMs Shouldn't Do the Adding Up

Language models are good at reading and explaining. They are not reliable calculators: ask one to total a column of figures from a document and it may well give you a confident, plausible and wrong number. For accounting work that's not a quirk, it's a liability.

So Ledger never asks the model to do the arithmetic. It runs two paths side by side:

1. Semantic RAG (retrieval-augmented generation) for questions about meaning — "explain this VAT treatment".
2. Deterministic SQL sums for the numbers themselves.

When a document is added to the Ledger module:

1. Extract the text (PDFs via pypdf, the same ingest path as every other module).
2. Parse amounts with a deliberately conservative regex — £1,234.56, GBP 1,234.56, 1,234.56 GBP — together with the line they appear on.
3. Store each amount as integer pence in its own SQLite table.

When you ask a question in a Ledger conversation, Kep sums those stored amounts in SQL — across the Ledger documents you're allowed to see — and hands the model a block like this alongside the retrieved text:

Computed totals (from 14 structured record(s), computed exactly — not by you):
- Sum: £7,407.36 GBP
- ...

The module's system prompt tells the model to treat that block as authoritative over any figure it reads out of the documents, while still explaining the numbers in plain language. The model reads and explains; SQL does the maths.

No Cloud, No Shared Anything

The security model is the same as the rest of Kep:

• Physical isolation: each firm has its own machine running its own local model — no shared server, no shared GPU time, nothing wired between one client and another.
• Strict ownership: even within a firm, one person can't see another's documents unless they're explicitly shared. The Ledger totals go through exactly the same visibility rule as chat and search (visible_document_ids()), so a sum can never include a colleague's private figures.

Ledger uses the same SQLite + sqlite-vec setup as everything else because:

1. It works fully offline.
2. Backup is copying one file — no database server to run.
3. There's nothing extra to install, secure or keep patched.

One Codebase, Modules Switched On by Licence

Every Kep install has the same code. Industry modules (Ledger, Clause and others) ship inert and are switched on by a licence grant from our licensing service — not by installing a different build. The registry lives in modules/base.py.

The one exception is Forge, our internal development module: it only registers itself when node_type == "internal_dev", so a client install never sees it at all.

The Takeaway

For regulated work, AI isn't about flashy demos — it's about numbers you can check and a system you can explain to an auditor. That's why the Ledger module:

• relies on regex and integer arithmetic for figures,
• never lets the model invent or recalculate a total,
• keeps its data in a single local SQLite file on the firm's own machine.

It's not revolutionary. It just works without asking anyone to put blind faith in a black box — and for accountants, that's the whole point.

---

Footnotes for the especially pedantic

1. Yes, the regex won't catch every format. Anything it can't match confidently is left out of the totals rather than guessed — the figure is still there in the document for the model to quote and for you to check.
2. Amounts are stored as integer pence to avoid floating-point drift, and only formatted as pounds for display.
3. Today the totals cover all Ledger documents you can see. Filtering them by date or category ("expenses last quarter") is not built yet.

Kep is built by FixFlex Ltd, London. Try the online demo — a fictional firm, no sign-up — at kep.fixflex.co.uk.