Ten ways AI is entering accounting software, and which of them SQL-Ledger should build

9.1What is actually being done

Strip the branding and the AI in accounting software is five mechanisms. Learned categorisation: a model trained on the tenant’s own history proposes the account for a bank line or an invoice line, with a confidence. Document extraction: OCR and a model turn a receipt or bill into fields and a draft transaction. Agents inside the product: rules and models that draft a reminder, an accrual, an invoice or a project and wait for a human to approve. Conversation: a question in English answered from the books, or an instruction in English turned into an action. And, newest, the ledger as a tool: an MCP server that lets Claude or ChatGPT read and write the books on the user’s behalf. Anomaly detection and forecasting sit across the first and fourth. The AI-native newcomers — Digits, Puzzle, Rillet — are the same five, built from the start rather than bolted on.

9.2The ten

Marked for us as build (in the next round of work), later (after the intake it depends on exists), or watch (not ours to build, or not yet proven). The fourth column says what it rests on in this book.

9.3Where we start from

There is no model code in the application. What exists is outside it: the contact summaries in the Ledger123 mail archive were written by a language model offline and applied to the database by script, and the support-ticket replies are drafted the same way. Both are the pattern this chapter recommends — the model produces a draft, a person approves, the ledger records — and neither touches a customer’s books. The three US charts, the departments, projects and tax codes on every line, and the audit trail are the labelled data any categoriser would train on; that is a better starting position than it sounds, because the vendors’ models are trained on exactly that.

9.4The five enhancements

1A categoriser that learns from the tenant

Three layers, each cheaper and more certain than the next, tried in order. First, memory: the same payee string and a similar amount were posted to an account before — propose it at high confidence; this alone resolves most lines in a mature ledger, and is a query. Second, rules: the user’s own patterns from chapter 1. Third, a model for the remainder: the payee text, amount, day of week and account history go to a small classifier trained on that tenant’s acc_trans (a few thousand rows is enough; retrained nightly on the host, no data leaves it), or, for a new tenant with no history, a language model prompted with the chart of accounts and asked for one account and a confidence. Anything under the threshold is shown unproposed. Every acceptance and correction is written to a catlog table, which is the training set and the audit of what the machine suggested. The screen is the matching grid of chapter 1: nothing posts without a tick.

Touches: SL/BK.pm, a nightly training job, one schema upgrade. Effort: medium.

2Extraction for the receipt inbox

The inbox of chapter 1 item 4 gets its engine. Pipeline: the file to text and layout by OCR — PaddleOCR on the host for layout and tables, Tesseract as the fallback — then a model with a fixed JSON schema (vendor, date, currency, total, tax, lines with description, quantity, amount) and a confidence per field, then vendor matching against the vendor table and account proposal by enhancement 1. Fields under the threshold are highlighted, as NetSuite does, and the transaction is a draft until a person posts it. For tenants who want better than local accuracy, a per-page cloud engine behind the same interface: Mistral OCR at about $2 a thousand pages, or Textract’s expense analysis at $10, chosen in the panel and charged through. Like Odoo, a vendor whose last three drafts were posted unedited may be flagged auto-post, per tenant, off by default.

Touches: bin/mozilla/inbox.pl, SL/RD.pm, an extraction service, panel settings. Effort: medium.

3An MCP server over the API

The one item where the market has moved fastest, and the one that turns every assistant a customer already pays for into a front end for their ledger. A Model Context Protocol server on the application server, speaking to the JSON API of chapter 6 with a token scoped by the roles of chapter 4. Forty tools, not seven hundred: the reports (balances, ageing, statements, a customer’s history, stock on hand), the lookups (customers, vendors, parts, open documents), and the drafts (quotation, invoice, vendor invoice, journal, payment). Read tools are on by default; write tools create a transaction in awaiting approval through the rules of chapter 4 item 3 and never post, so the assistant can draft and the accountant presses the button. Every call is an audit row with the token, the tool and the arguments. Text that came from outside — an invoice description, a vendor name, a note — is returned to the model as data with an explicit marker, because the documented MCP incidents of 2025 were all instructions smuggled in through content. Ships with a connector entry for Claude and ChatGPT and a page in the manual.

Touches: the appserver, SL/API.pm, SL/VR.pm approvals, the manual. Effort: medium once the API exists; small after.

4Anomaly review

A nightly job and a screen. The job runs a fixed set of tests over the month’s postings — duplicate vendor invoice numbers and near-duplicate amounts, an amount more than three deviations from the account’s history, a recurring charge whose expected date passed, a vendor whose bank details changed before a payment, round-thousand postings to expense accounts, postings dated outside working hours, an account pair never used together before, a customer credit followed by a payment to the same address — and writes findings with a severity to a table. The screen lists them; dismissing one teaches the test its threshold for that account, which is all Sage’s “learns from dismissals” means. A language model is used for one thing: turning a finding into a sentence the owner understands. This is MindBridge for a small firm and it is mostly SQL.

Touches: a job, SL/RP.pm, dashboard badge, one schema upgrade. Effort: small-medium.

5Ask the ledger, grounded

Not text-to-SQL. The question goes to a model with the catalogue of named reports from chapter 2 item 5 and their parameters; the model chooses a report and fills the parameters (period, customer, department); the report runs through the same code as the screen; the answer is the first line of the result with the full report beneath it and a link to the screen with the same filters. If no report fits, the assistant says so rather than inventing a query. The same catalogue is what enhancement 3 exposes as tools, so the two are one piece of work with two front doors.

Touches: bin/mozilla/rp.pl, the report library, a small model call. Effort: small once the library exists.

9.5What we will watch, and what we will not build

Agents that act without asking. Intuit’s Payments agent sends reminders; Odoo auto-posts after three clean drafts; the AI-native ledgers book 95% of lines untouched. Every one of them has a correction workflow because every one of them is wrong sometimes. We will draft, and let the tenant choose auto-post per vendor once the record shows it is safe, and never for money leaving the account.

Our own models. Digits trained on 170 million transactions. We will train per-tenant classifiers, which are small, private and better for that tenant, and rent language models by the call for the rest.

Forecasting sold as AI. The planner of chapter 1 is arithmetic and will say so.

Tax and audit assistants. Practitioners’ tools; we produce what they consume. If a Pakistani practice serving US clients wants TaxGPT-style research, it buys it.

A chatbot without a ledger behind it. The value in every product above is the data underneath, approved by a person. A model answering from nothing is the thing to avoid.

9.6The rules we will hold to

9.7Glossary of acronyms

9.8Sources