Connecting AI to Sage: closing the gap between orders and accounts
In most SMEs there are two versions of the business: the operational one, which lives in orders, delivery notes, timesheets and applications for payment, and the financial one, which lives in the accounts package. Sage is the package a large share of UK firms happen to own, so Sage is the example here, but the point is vendor-neutral: the gap between the two versions is bridged by a person retyping documents, usually at month end, usually under pressure.
The realistic ambition is not "AI does the accounts". It is narrower and more useful: software reads the operational documents as they arrive, codes them against your nominal structure, matches them to what they relate to, and posts draft entries for a person to approve. The bookkeeper stops being a typist and becomes a reviewer, and the approve button stays under a human finger.
Why is the gap between operations and accounts so expensive?
Because it is crossed by hand, late, in batches.
The delivery note arrives in February; it is keyed in March; the question it raises ("what is this second delivery from the same supplier?") is asked in April of someone who has genuinely forgotten. Every document crosses the gap twice, once as paper and once as a query, and the elapsed time between them is where the cost hides. Management accounts describe six weeks ago. Supplier statements disagree with the ledger and someone spends an afternoon finding out why. Duplicate invoices get paid not because anyone is careless but because the same document arrived by two routes and was keyed by two people.
None of this is a Sage problem, or a software problem at all. The package records what it is given; the gap is in how it gets given.
What does the automated bridge actually do?
Four jobs, in sequence, with a person at the end.
| Stage | What the system does | What the human does |
|---|---|---|
| Read | Extracts supplier, date, references, line items and VAT treatment from the incoming document | Nothing, unless the document is unreadable |
| Code | Proposes the nominal code and cost centre from your history of similar entries | Corrects it when wrong; the system learns the correction |
| Match | Links invoice to order to delivery note, and receipts to bank lines, flagging mismatches | Investigates the mismatches only |
| Post | Places a draft entry in the package, original document attached | Reviews and approves; nothing hits the ledger unapproved |
Two design choices in that table carry all the weight. First, everything is a draft: the automation proposes and the person disposes, which keeps responsibility exactly where your accountant and your insurer expect it. Second, the original document travels with the entry, which is where the audit trail comes from. When a number is questioned in eighteen months, the answer is attached to the entry, not in a lever-arch file in the loft.
Coding accuracy is the honest caveat. On a clean nominal structure with consistent suppliers it gets very good quite quickly, because most documents are the same decisions repeating. On a chart of accounts with three codes for the same thing, it will be as confused as your last new bookkeeper was, and for the same reason.
Does this fit with MTD and what the accountant expects?
It fits better than the manual version, provided it is set up honestly. Making Tax Digital already requires VAT records to be kept digitally with digital links between systems, so a documented, automatic path from source document to ledger entry is a step towards the rules, not around them. The professional bodies have been writing about automation in bookkeeping for years (ICAEW publishes extensively on technology in the finance function); the consistent theme is that review and accountability stay with people while the keying goes away.
Two duties come with the territory. Financial documents are personal data as well as commercial data, so whatever reads them needs the same care you would apply to any processor under UK GDPR (the ICO's organisational guidance is the reference point). And your accountant should see the design before it goes live, not after: a reviewer who trusts the pipeline signs things off faster, and their sign-off is the product.
Where does the operational side of the bridge start?
Further upstream than most firms look. The invoice is the last document in a chain that started weeks earlier as an order, a delivery, a site instruction or a conversation, and the earlier the chain is captured in structured form, the less there is to reconcile at the end. Firms that let automation act on documents the moment they arrive find month end shrinks because the work stopped accumulating. Even meeting notes carry commercial detail (agreed variations, confirmed rates, dates) that currently reaches the accounts by memory, if at all.
That is why this is a workflow question rather than an accounts question. The package you own is fine. The opportunity is the plumbing between where documents arrive and where the numbers live, and that is precisely the kind of workflow automation that pays for itself in reviewer hours and caught duplicates rather than in anything dramatic.
Start with one document type, purchase invoices from your twenty most frequent suppliers, and run it for a month with everything else unchanged. Count the hours the bookkeeper spends keying versus reviewing, and count the mismatches the matching stage catches. Those two numbers will tell you whether to extend it, and they will do it in your own ledger's language.
The firms that get this right do not talk about AI doing their accounts. They talk about Tuesday afternoons that used to be spent typing.