AI bookkeeping automates entry processing in a fixed sequence. It captures a source document or bank line, extracts the fields a ledger needs, assigns a contact and account code, matches the item to existing records, and then either posts the entry or sends it to a person for review. The automation is only as good as the checks between those steps, so the useful question for a buyer is less "can it post entries?" and more "how does it decide when not to?"
What "entry processing" actually covers
An entry in your books starts as evidence: a supplier invoice, a till receipt, a sales invoice, or a line on a bank statement. A bookkeeper turns that evidence into a ledger entry with a date, a counterparty, a net amount, a tax amount and rate, and an account code. They also link it to the bank movement that settled it. Done by hand, each of those steps means a person reads the document, types values and makes a judgement about coding.
AI replaces most of the reading and typing. It replaces judgement only partly, and only where the system has good evidence for the decision. A sound design keeps those two things apart.
The pipeline, step by step
1. Capture
Documents arrive by email inbox, mobile upload, supplier portal or scanner. Bank transactions arrive through a bank feed. The system's first job is to record where each item came from and keep the original image or file. That matters for audit and, as covered below, for tax compliance.
2. Extraction
An extraction model reads the document and returns structured data. Microsoft's Document Intelligence invoice model is a typical example. It accepts phone-captured images, scanned documents and digital PDFs, and returns JSON containing fields such as invoice ID, customer, bill-to, due date, total and line items. Its output also carries confidence values for extracted tables and cells, which gives a pipeline a basis for deciding which values to trust. Microsoft's documentation also lists practical limits. Results are best with one clear photo or high-quality scan per document, and text smaller than 12 pixels high in a 1024 x 768 image (roughly 8-point text at 150 dpi) is below the stated minimum.
Large language models are also used for extraction, particularly for messy or unusual layouts. They are flexible, but they can return a plausible-looking value even when the document is ambiguous. That is the main reason extraction should never be the last check.
3. Classification and coding
Once the fields are known, the system decides what the entry is (an expense, a sale, a transfer, a refund) and picks a contact and a nominal or chart-of-accounts code. Xero's bank reconciliation shows the layered approach most systems use:
- Bank rules: rules the user sets up to code regular transactions, such as parking charges.
- Matching: finding an existing invoice or bill in the ledger that the bank line settles.
- Memorisation: remembering, for example, which account you transferred money to and suggesting it again for similar transactions.
- Prediction: machine learning that suggests a contact and account code. It learns from reconciliation patterns across Xero's millions of subscribers and covers transactions the other methods cannot place.
The order matters. Deterministic rules and exact matches come first because they are predictable. Statistical prediction is the fallback. When Xero introduced its predictive feature, it said that at first the feature would help only a very small percentage of transactions. That is a useful reminder that prediction covers the long tail, not the bulk.
4. Matching and reconciliation
The entry is then tied to its bank movement. Matching checks the amount, a date window and the counterparty. It gets hard with partial payments, combined payments covering several invoices, and foreign currency differences, and those cases produce many of the exceptions.
5. Validation
Before anything posts, a well-built system runs checks that do not depend on AI at all:
- Net plus tax equals gross, and line items sum to the total.
- The tax rate is valid for the jurisdiction and the type of supply.
- The invoice number has not been seen before from that supplier (duplicate detection).
- The date falls in an open period.
- The supplier exists and the bank details match what is on file.
Arithmetic and reference checks are cheap to run and catch many extraction errors. A bank-details check can also flag a changed account before a payment goes to it.
6. Posting or exception
Items that pass every check post automatically. QuickBooks Online, for example, lets you create rules that automatically accept bank feed transactions without a review step. Everything else lands in a review queue with the reason it was held. Your team's time now goes into that queue, so its design decides how much time you actually save. It should give clear reasons for each hold, show the source image beside the extracted values, and allow one-click correction.
Why a single model is a weak point
The most expensive failure in automated bookkeeping is not a missed entry. It is a confident wrong entry that posts cleanly and is found only at month end, at VAT return time, or by an auditor. Typical cases are a transposed amount, the wrong VAT rate, or a supplier coded to the wrong expense account. Rules cannot catch these because nothing looks broken.
We dealt with this risk directly. Before we built Pixelet's AI bookkeeping pipeline, its entries were processed by hand, one at a time. Handing the job to one AI model would have been faster. But a single model can be wrong, and nobody notices until the books are off. So we built a pipeline in which several AI models process each entry independently, and an entry is accepted only when the models agree. The principle behind the build was that in bookkeeping a confident wrong answer is worse than no answer, so no single model gets the final say. You can read more in the Pixelet case study.
Cross-checking is not the only control. Confidence thresholds, deterministic validation and sampling of auto-posted entries all help. But independent agreement is one of the few checks that can catch an error that is internally consistent.
Compliance: what the rules expect of automated entries
United Kingdom
HMRC's VAT Notice 700/22 on Making Tax Digital sets out several points that affect automated bookkeeping:
- Manually entering data when it is first captured, such as keying an invoice into software, is allowed.
- After capture, data moving within or between software programs must travel by digital link. Cut and paste does not count. Acceptable links include CSV import and export, XML, API transfer and automated data transfer.
- For each supply, records must include the time of supply, the value of the supply and the VAT rate charged.
- If a scanned image is kept and holds all the detail needed for VAT purposes, the original invoice need not be kept, unless another purpose requires it.
In practice, an AI pipeline that extracts invoice data and pushes it into your accounting software through an API fits these rules. A process where someone copies AI output from one screen into another does not. Keep the source image linked to each entry.
United States and the European Union
Record-keeping, document-imaging and e-invoicing rules differ between the US and individual EU member states. Before you decide whether the system will keep or discard original documents, and for how long, confirm the local requirements with your accountant.
What to watch for when buying or building
- Ask what happens when the system is unsure. A vendor should be able to explain exactly what triggers an exception. "The AI is very accurate" is not an answer.
- Measure on your own documents. Accuracy on a vendor's sample set says little about your suppliers' invoice layouts, handwritten receipts or multi-currency statements. Run a pilot on a few months of past entries where you already know the correct answers.
- Separate field accuracy from coding accuracy. Reading the total correctly and choosing the right expense account are different problems. Track their error rates separately.
- Check the audit trail. Every posted entry should show its source document, the extracted values, which rule or model decided the coding, and who approved it if a person did.
- Watch the learning loop. Systems that learn from your corrections can also learn your mistakes. Someone should review new auto-post rules before they go live.
- Keep sampling auto-posted entries. Each period, review a sample of entries that posted without a person checking them. Silent errors show up only if someone looks for them.
- Know where your data goes. Financial documents contain personal data and bank details. Ask which models and providers process them, in which region, and whether your data trains anyone else's models.
Off-the-shelf features or a custom pipeline?
If your volume is moderate and your documents are standard, the bank rules, receipt capture and suggested matching in your accounting platform may be enough. Start there and set up rules for your recurring transactions. A custom pipeline is worth the cost when one or more of these apply:
- You process high volumes or unusual document types that built-in tools read poorly.
- You need stronger verification, such as independent cross-checking, before anything posts.
- Entries must flow by digital link into several systems, such as an ERP, a practice management tool and a reporting database.
- You want to control the exception logic and own the code, rather than accept a vendor's defaults.
Khive builds AI document processing systems in code and hands them over, so the client owns the pipeline, its rules and its review logic.
Next step
If your entries are still keyed by hand, or a single AI tool is posting entries nobody checks, we can help you design a pipeline that knows when to stop and ask. Send us a brief with your document types, monthly volumes and accounting software, and we will tell you how we would approach it.