Ask most small business owners where their books live and they will name an accounting system. QuickBooks. Xero. Sage. That answer is correct and it is also incomplete, because it describes where the numbers end up rather than how they got there.
The gap between "a purchase happened" and "a correct, evidenced entry exists in the ledger" is not a small administrative detail. It is where books actually go wrong, and it has a name.
Pre-accounting software is the layer that collects and structures source documents before they reach an accounting system. It captures receipts, bills and statements from wherever they arrive — email, a phone camera, a supplier portal — reads the vendor, date, amount and tax off them, attaches the original document as evidence, and hands a clean, categorized set of records to QuickBooks, Xero or an accountant. Your accounting system is a system of record. Pre-accounting is the collection system that feeds it. Both are necessary, and confusing the two is why so many sets of books are technically complete and practically untrustworthy.
What pre-accounting software actually is
The category has existed for years without most people having a name for it. Dext (formerly Receipt Bank), Hubdoc and AutoEntry are the established players; accountants have used them at scale for the better part of a decade. What they have in common is that none of them is an accounting system. They sit in front of one.
The division of labour is clean once you see it:
| Pre-accounting (collection) | Accounting (system of record) |
|---|---|
| Captures documents from email, camera, portals | Holds the ledger and chart of accounts |
| Reads vendor, date, amount, tax off the document | Applies double-entry and maintains balances |
| Keeps the original attached as evidence | Produces statements and reports |
| Structures and categorizes for handoff | Is what your accountant and tax authority rely on |
Read the left column and notice that none of it is accounting. It is document logistics. That is precisely why it gets neglected — it does not feel like finance work, so it ends up as nobody's job, done badly, in a hurry, in April.
Why the books break without it
The failure is not usually dramatic. Nobody sets out to keep bad records. What happens is more ordinary: the bank feed populates the accounting system automatically, the transactions all look plausible, and the books appear complete. Meanwhile the documents that would substantiate any of it are in four places and three formats.
This is the difference between a transaction and a record. A bank feed tells you that money left the account. A receipt tells you what it bought. One of those substantiates a deduction and the other does not. A line reading a big-box retailer's name tells an accountant nothing about whether it was materials for a job or a personal purchase on the wrong card.
Accountants encounter the mature form of this problem constantly, and it has its own name too — the shoebox. We wrote about the accountant's side of it in the shoebox problem. The important insight there is that the shoebox is not a client discipline failure so much as a missing layer. If nothing is capturing documents at the moment they arrive, they accumulate somewhere unstructured by default. Blaming the client for that is like blaming water for flowing downhill.
The layer's contract: four things it owes you
If you are evaluating anything in this category — including ours — these are the obligations worth holding it to. They are more useful than a feature list because they are the things that determine whether the records survive contact with reality.
| The duty | Why it matters |
|---|---|
| Capture everything, from where it actually arrives | Receipts do not arrive in one place. Some are emailed, some are paper handed over a counter, some sit in a supplier portal. A capture layer that only handles one channel leaves a gap, and the gap is always in the channel you did not automate. |
| Attach the evidence, not just the number | A row saying $412.80 is a claim. The same row with the original document attached is a substantiated claim. The difference only matters on the day someone asks — which is exactly the day you cannot go back and get it. |
| The client owns the data | Records should outlive the tool. If the source documents are only reachable through a vendor's interface, the client's books are hostage to a subscription. Portable format, storage the client controls. |
| Hand off clean | The output is an input to something else — an accountant, QuickBooks, Xero. The measure of the layer is how little work is left at the boundary, not how impressive its own dashboard looks. |
The third one is the one people underweight and later regret. It is easy to evaluate a tool on how well it reads a receipt and never ask what happens to five years of documents when you stop paying for it.
What AI changes about this layer
Document extraction has been machine-assisted for years, so "AI reads your receipt" is not the interesting part. Two things are genuinely new.
Capture is becoming conversational. The friction in this layer was never the reading — it was getting the document into the system at all. When the capture surface is an assistant you already have open, dropping a receipt into a conversation is a materially lower-effort path than opening a dedicated app, finding the upload button and waiting. Lower friction at the moment of capture matters more than accuracy improvements downstream, because the documents that never get captured are the ones that cost you.
Capture is becoming agent-driven. Protocols like MCP let an assistant call tools directly rather than just describe what you should do. The practical consequence is that "add this receipt", "what did I spend on this client", and "build the report" can happen in the same conversation as the rest of your work. We publish our own connectors for this — see MCP connectors — and the direction of travel is broader than any one vendor.
What has not changed is the contract above. An agent that captures documents into a place you do not control, or records a number without keeping the evidence, has automated the easy half and skipped the half that matters. Convenience at capture is only worth having if the record it produces is durable.
Choosing tools for the layer
The incumbents are strong products, and for a practice processing high document volume across many clients they are often the right answer. They are also priced and shaped for practices. If you are a small business or a sole operator, you are frequently buying a workflow designed for a bookkeeper managing dozens of clients, and paying accordingly.
We have written the honest comparisons: Dext alternatives and Hubdoc alternatives. Both include the cases where the incumbent is the better fit, because a comparison that concludes "buy ours" every time is not a comparison.
The questions worth asking of anything in this category:
- Does it capture from the channels my documents actually arrive in, or only the one it was built for?
- Is the original document retained and retrievable, or only the extracted numbers?
- Where do the records physically live, and what do I keep if I leave?
- What does the handoff to my accounting system or my accountant actually look like?
- Is it priced for a practice or for a business my size?
For what it is worth, ExpenseBot's answers: you connect your Gmail and it scans it for receipts, labelling what it reads and never sending or deleting anything; you can photograph paper receipts or forward them in; everything lands in a categorized Google Sheet in your own Google Drive, which you keep if you leave; and it exports to QuickBooks Online, Xero or Sage in one click. Accountants use it free.
Honest limits
A category-defining post that only describes what the layer can do is marketing. So, plainly: this layer does not do accounting, and tools in it should not pretend to.
ExpenseBot specifically is not a general ledger, does not do double-entry, does not run budgets or forecasts, is not an invoicing suite, and does not file anything for you. It captures spend and organizes records. Everything downstream of that — the classification judgments, the adjusting entries, the return — is work for an accounting system and a professional.
Nor does capture eliminate judgment. Software can read a receipt and propose a category; whether a particular cost is deductible in your situation is not a question a capture tool is competent to settle. The right mental model is that the layer removes the archaeology — the reconstruction of a year from memory and bank lines — so that the judgment happens against complete information instead of fragments.
That is the whole argument for taking this layer seriously. Not that it replaces your accounting system, but that it decides how much of what reaches your accounting system is true.
Estimates — confirm with your tax professional.