AI automation in the back office: examples, risks and running it well
Phil McParlane, founder of Sellframe
Published 31 October 2026
AI automation means putting an AI model inside a business process, usually to read something messy, such as an emailed order, a PDF invoice or a CV, and turn it into data the rest of the process can use. This guide is for the operations or finance lead who has to make one work.
We design, build and run AI automation for businesses, and run one inside a product of our own.
What AI automation is, and what it isn't
Most business automation is rules: when an order ships, raise the invoice; when an invoice is over a set amount, send it for approval. Rules are cheap, predictable and easy to test, but break when the input has no fixed shape, such as a supplier's PDF, a customer's email or a handwritten form.
AI automation adds a step that reads, sorts or drafts, then hands its output back to ordinary code. The process calls the model for the one job rules can't do, and checks what comes back.
Anthropic, which makes the Claude models, draws the same line in its guide to building effective agents. Workflows follow "predefined code paths"; agents "dynamically direct their own processes and tool usage". It recommends the simplest solution that works, which "might mean not building agentic systems at all", and warns that agents bring "higher costs, and the potential for compounding errors". Most back-office jobs are workflows.
Robotic process automation (RPA), software that drives other programs' screens the way a person would, is a third thing; our guide to what RPA is and when to use it covers it.
AI automation examples from the back office
In each of these, the AI does the reading, rules do the checking, and a person deals with what the rules can't settle.
| Job | What the AI does | What the rules check | What a person does |
|---|---|---|---|
| Supplier invoices as PDFs | Reads the supplier, number, date, lines, VAT and total | Lines add up, the purchase order exists, quantities match goods received, no duplicate | Approves matches, resolves differences |
| Orders sent by email | Turns free text or a PDF into draft order lines | Product codes exist, prices match the price list, no credit hold | Checks the draft and releases it |
| A shared inbox | Sorts each email by type, pulls out the reference, drafts a reply | Routes each type to the right team | Edits and sends the reply |
| CVs and application forms | Pulls skills, experience and dates into fields | Required fields present, dates make sense | Decides who to interview |
| Contracts and leases | Finds notice periods, break clauses and renewal dates | Dates valid and in order | Confirms each date before it goes in the diary |
At first a person checks everything, which still saves the typing. As your tests show which fields the AI gets right, you can move to checking exceptions and samples.
An example from our own product
We built and run 4dayweek.io, a job board for four-day weeks and other reduced hours. Its jobs sit on more than 1,300 company job boards, and every ad has to be read for pay, place, work arrangement and role. Three AI requests read each ad at once: one for the role, level and skills, one for the location text alone, and one for the salary.
Two choices carry over to any back-office job. First, give each AI step only what it needs: the location reader never sees the company name, so it can't guess the head office. Second, decide in advance that a blank beats a wrong answer, and enforce it in code. The salary reader takes base pay only and keeps the stated period, a guard drops implausible figures, and we never estimate a missing salary, because a salary we show is published to Google as the employer's stated pay.
Where AI automation fails
Confident wrong answers. NIST's generative AI risk profile calls this confabulation: "confidently stated but erroneous or false content". On an invoice, that is a total that doesn't match the lines, or a purchase order number that isn't on the page. Check every field you can. If a supplier's bank details differ from those on file, a person sees it every time.
Instructions hidden in the input. OWASP's list of risks for language model applications puts prompt injection first, including the indirect kind, where a model "accepts input from external sources, such as websites or files". An inbound email or CV can carry text aimed at the model. OWASP advises giving the model the least access it needs and human approval for privileged actions. An AI step that reads email should never be able to pay, send or delete anything by itself.
The rare case. Credit notes, two-page invoices, foreign currency, a handwritten correction. Tests built only from typical documents miss them.
Change underneath you. Providers retire models. Anthropic's model deprecations page promises at least 60 days' notice for publicly released models, and lists Claude Sonnet 4.5 as deprecated on 30 September 2026 and due to retire on 30 November 2026. Every move to a new model means checking your results again. Providers also have outages.
Decisions about people. The UK GDPR, as amended by the Data (Use and Access) Act 2025, has specific rules for significant decisions about a person taken with "no meaningful human involvement" (Article 22A). Article 22C requires safeguards, including ways to obtain human intervention and to contest the decision. The simplest design: let AI prepare these decisions and a person genuinely make them.
What it takes to run one well
- Inputs. Write down what goes in and which fields come out, in a fixed format. Send the least the job needs, and leave out personal data the step doesn't use.
- Checks on each result. Totals, lookups against your own records, plausible ranges, required fields. Anything that fails goes to a person with the reason shown.
- Checks on the system. Keep a set of real examples with right answers agreed by the people who do the work, and rerun it before any change to a prompt, model or provider. On 4dayweek.io, golden tests run against the real models before any such change goes live, checking that boilerplate isn't read as a perk as well as that real facts are found.
- Fallbacks. Decide what happens when the model is down or returns something unreadable. On 4dayweek.io a failed read would drop a job, so a request that fails on one AI provider is retried on the other, and an alert fires if a quarter or more of requests fall back. The last fallback is a person doing the job as before, so keep that route working.
- Logging. Record what the model was given, what it returned, which model and prompt ran, which checks passed and who approved, so you can answer an auditor and see what to improve.
Cost control
Model providers charge per token, a short piece of text. As of October 2026, Anthropic's pricing page lists, in US dollars, Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens, and Claude Haiku 5.5 at $0.10 and $0.50 for prompts up to 100,000 tokens. Work that can wait goes through its Batch API at a 50 percent discount.
Its PDF guide says a page typically uses 1,500 to 3,000 tokens of text, and each page is also sent as an image, which its vision guide puts at up to 4,784 tokens on Claude 4.7 and later models. Allow 10,000 input tokens and 500 output tokens for a one-page invoice with instructions, and 5,000 invoices a month comes to about $125 on Sonnet 5.5, or about $6 on Haiku 5.5, before any batch discount. Measure your own documents, but the model bill is usually smaller than the time people spend checking.
Costs run away in three ways: a large model where a smaller one passes your tests, far more text than the job needs (a whole email thread for one order), and loops, where retries or an agent call the model again and again. Cap daily spend in your own code, alert on it, and let the tests decide which model each step uses.
When plain automation or a product is the better answer
The input is already structured. If data arrives as a spreadsheet export, through an API or as an electronic order, use rules. AI adds cost and a chance of error to a job a lookup does perfectly. Plenty of good business process automation has no AI in it at all.
Invoices are moving that way. The UK government's e-invoicing consultation response says "the UK will introduce mandatory e-invoicing for all VAT invoices from 2029", and defines e-invoicing as "the digital exchange of invoice data directly between buyers' and suppliers' financial systems"; a PDF doesn't count. A system built to read supplier PDFs should expect structured data instead.
The job is common. Xero's Smart Document capture, for example, reads receipts, invoices, bills and rental statements, lets you double-check the details before it creates a record, and Xero says it's available on all its small business plans (as of October 2026). Build only when your documents, systems or checks are unusual enough that a product won't fit.
The job is rare, varied or a judgement call. A pricing dispute, a credit decision or a complaint belongs with a person, though AI can draft the summary they read.
The process is a muddle. Automating a process nobody has written down builds its problems into the software, so map the process before you automate it. For where AI helps a smaller business beyond automation, see our guide to AI for business.
How to start
- Pick one job with high volume, messy input, a clear right answer and a cost of error you can name.
- Collect 50 real examples, awkward ones included, with right answers from the people who do the job.
- Run a model over them before building anything, and count errors field by field.
- Decide what the rules check and what a person checks, then build the smallest version, with logging and a fallback.
- Count corrections every week, and widen the job only when the numbers support it.
If you'd like us to run that first test on your own documents, start a project and tell us which job you have in mind.