Invoice capture and transaction coding
How invoice capture turns documents into coded data
Capture is the least glamorous part of accounting automation and the one that decides whether the rest works. If a document enters with the wrong amount or the wrong vendor, every step after it inherits the error. This page compares how document capture and auto-coding behave in daily use, and where a person still has to step in.
What document capture reads
A capture engine pulls structured fields out of an unstructured document: vendor name, invoice or receipt number, date, total, tax, and often the individual line items. Modern tools accept PDFs, phone photos and forwarded emails, and they get steadier as they see more documents from the same vendor.
The extraction is probabilistic. Usually right, occasionally wrong. So the practical question is not whether the engine is accurate — it is whether the platform shows you what it read and lets you fix it in one move.
Ask to see the field list before you sign anything. A tool that reads totals but ignores tax codes or purchase-order numbers will still leave you typing, just in a different screen.
Fields a typical engine returns
- Vendor
- Matched against names you have used before, so repeats land under the record you already created.
- Document number
- The invoice or receipt number, used to catch duplicates before they reach the ledger.
- Date
- Placed into the right period, which matters most at month end and around a cut-off.
- Total and tax
- Split apart, so a taxable line and a shipping line do not end up in the same account.
- Line items
- Not every platform reads these. If you code by line, check this before anything else.
Receipt capture for expense management
Receipts are harder than invoices in one way and easier in another. Harder, because a phone photo is often crumpled, angled or faded. Easier, because the amounts are small and the coding is usually predictable. Expense tools lean on that second fact: they match the receipt to a card transaction on their own.
Confident match
The receipt lines up with the card charge and the employee does nothing at all. No email, no monthly envelope of paper.
Uncertain match
The tool asks one question — which category — and the answer trains the next round of suggestions for that vendor.
No receipt yet
The charge posts first and the tool holds the line open. When the photo arrives later it attaches to the same transaction instead of starting a new one.
That single interaction replaces the monthly receipt chase. It is also the cheapest automation most small businesses can switch on, because it needs no new chart of accounts and no new vendor relationship.
Auto-coding runs on two layers: the rules you write, and the patterns the system learns from how you coded before.
Most teams run both, and the split between them matters more than the marketing suggests. Rules are predictable and need maintenance. Learned behaviour adapts, but it can drift when your vendor mix changes.
Auto-coding rules and how they learn
The first layer is rules you write yourself. This vendor always goes to this account; anything with the word freight goes to shipping. Rules are boring and reliable, and they are the layer you can explain to an auditor in one sentence.
The second layer is learned behaviour. The system notices how you categorised similar transactions and proposes the same choice next time. QuickBooks Online describes this as learning how users categorise income and expenses, then matching similar transactions automatically. It is helpful, and it is the layer that quietly drifts when a vendor starts selling something new.
A workable split: rules for the largest ten or twenty vendors that carry most of your invoice volume, learned suggestions for everything else, and a short monthly look at the accounts that absorb the most uncategorised lines.
Rules layer
Predictable, easy to audit, needs a periodic tidy when vendors or account codes change.
Learned layer
Adapts to new vendors on its own, and needs a light review so a wrong suggestion does not become the habit.
Wrong-book risk
Multi-entity capture and the wrong-book problem
When a company runs several entities, every document has to land in the right set of books. That is harder than it sounds, because the same vendor may invoice three entities with similar amounts on the same day. A capture tool without entity-level routing pushes that decision back to a person, every single time.
Docyt comes up in multi-entity bookkeeping conversations because it pairs document capture with workflow automation and oversight across multiple books. Whatever tool you shortlist, test this before anything else: send the same vendor to three entities and see whether the tool asks you which book, or guesses. A guess that is right most of the time still costs you a correction and a review every month.
Where capture accuracy breaks down
Capture struggles with new vendors, unusual layouts, and documents that combine several invoices into one. It also struggles with anything handwritten or photographed badly. None of that is a reason to skip capture. It is a reason to design a review step into the flow before the data reaches the ledger.
The review step
- Low-confidence extractions are flagged for a person instead of being accepted silently.
- The document sits beside the extracted fields, so a correction is a glance and a keystroke.
- The correction feeds back immediately, so the same vendor does not raise the same flag twice.
If a platform cannot tell you how confident it is, you have no way to prioritise your review.
Review burden is the real cost
The pitch for capture is time saved on entry. The number that actually lands on your team's week is time spent on review. A tool that extracts well but buries corrections in a long queue costs about as much as typing the invoice yourself.
Look for three things in the review screen: the document and the extracted fields side by side, a sort that puts the least confident extractions first, and a correction that updates the vendor's future suggestions on the spot. Docyt, BILL and Stampli each approach this differently, and the difference shows up in daily use rather than in a demo.
Matching documents to transactions
Capture produces data. Matching connects that data to a bank line or a bill already sitting in the ledger. This is where receipt capture and reconciliation meet.
The clean version of this is automatic and silent. The messy version is a folder of unmatched receipts that someone reconciles by hand at month end — which is the exact problem capture was supposed to solve.
Sequence
What the tool does
Receipt first
The tool holds the receipt and waits for the card charge, then matches without asking.
Charge first
The line stays open, and the receipt attaches retroactively when the photo or PDF arrives.
Split amount
A receipt that covers several items gets split across categories, either at capture or at review.
No document
The tool should still surface the missing document at close, so the gap is visible rather than forgotten.
What to test before you buy
Three tests, using your own documents rather than a prepared sample. Vendors answer the first two readily and the third less so. If you run multiple entities or multiple currencies, the third question is the one that decides the purchase.
-
1
Feed it a bad scan
Throw in a crooked, faded or low-resolution invoice and read what came back. Does it show the document and the fields together, and does it flag the fields it is unsure about?
-
2
Submit an unknown vendor
Use a supplier the tool has never seen and check whether the coding proposal is sensible. A blank suggestion is fine; a confidently wrong account is not.
-
3
Ask about the wrong entity
Ask what happens when a document is coded to the wrong set of books. The answer tells you whether entity routing is a real feature or a promise.
Capture inside your accounting platform
QuickBooks Online and Zoho Books both include capture and coding as part of the platform, which avoids a second integration and a second bill. The trade-off is depth: a dedicated tool will usually handle more document types and more complex routing.
For a single-entity business with straightforward expenses, native capture is often enough. For a business with multiple entities, inventory, or high invoice volume, the specialist tools justify their cost. Start native and move when you hit a limit you can actually name.
Before you move, check one thing: whether your accounting platform already captures the document types you spend the most time on. Most teams discover the limit at a specific document, not at a whole category.
Native capture usually handles the documents you already see every week. The specialist tools earn their place on the ones you only see sometimes.
Common questions about capture
Short answers to the three questions that come up most when a team is comparing document capture and auto-coding.
How accurate is automated invoice capture?
It depends on document quality and vendor consistency. Most tools handle clean, recurring invoices well and flag unusual documents for review.
Can capture handle receipts as well as invoices?
Yes, and receipt capture is often the first automation a small business sets up, because it removes the monthly receipt chase.
What happens when capture reads an amount wrong?
A good platform flags low-confidence extractions for review and lets you correct them before the data reaches the ledger. Ask how confidence is surfaced.
Start with the documents you already fight with
The right capture setup depends on what your team actually processes. If most of your volume is clean recurring invoices, native capture inside your accounting platform may be enough. If you run multiple entities or currencies, or you spend the first week of every month chasing receipts, that is the signal to compare the specialist tools properly.
Finoradeks · 8920 Corporate Drive, Building B, Austin, TX 78758, USA · +1-512-558-7445 · [email protected] · Mon–Fri, 9:00 AM – 6:00 PM