Invoice capture and coding
Invoice capture and coding that holds up
A demo with three clean PDFs tells you almost nothing. Test extraction and coding on the invoices your vendors actually send — scanned faxes, mixed line items, and all.
Where to start
Capture looks like the easy part of automation
Until you run it on your own documents. The real question is what happens with a scanned fax from a vendor who has been sending the same illegible invoice since 2014, or a single document that bills both a product and a service. This page covers how capture and coding work, how to test them properly, and where accuracy breaks down. It is written for finance teams who are past the should-we-automate stage and into will-this-actually-work.
What this page answers
- Which documents extract cleanly, and which ones do not
- How the three coding methods differ in practice
- Why your chart of accounts sets the accuracy ceiling
- How to test extraction without a sales demo
What capture technology can and cannot read
Capture engines pair optical character recognition with a layout model that learns where vendor names, invoice numbers, and totals tend to appear. Printed, consistently formatted invoices extract reliably. Handwriting, low-resolution scans, unusual fonts, and multi-page invoices with line items split across pages cause problems.
Tables are a known weak point. An invoice with a dozen line items in a dense grid often extracts the total correctly but garbles individual lines. That matters when you need line-level coding for inventory or project accounting. Test your actual documents before assuming a stated accuracy figure applies to your vendor mix.
Read the AP automation guide
Dense tables and split line items are where capture quietly drifts from the invoice totals your team already trusts.
Extracts reliably
Printed invoices with consistent vendor formatting, clean totals, and a stable page layout.
Needs review
Handwritten fields, fax-grade scans, unusual fonts, and line items split across multiple pages.
The three coding approaches
Most platforms combine all three methods below. The mix is what determines how well the system fits your vendor base — and each one fails in its own way.
Rule-based coding
If the vendor is Acme and the amount is under a threshold, code it to a specific account. This is predictable and easy to audit, but it breaks when a vendor's spending changes.
Memory-based coding
The system learns from how you coded similar invoices before and proposes the same account. This handles variety better and improves over time, but it needs a correction history to learn from.
Keyword or line-item coding
The system reads the invoice description and maps it to an account. This works well for detailed invoices and poorly for vague ones — a one-line description of consulting gives it almost nothing to work with.
Why your chart of accounts decides coding accuracy
Automated coding can only choose among the accounts you give it. If your chart has overlapping categories, the system has no reliable way to pick between them, and it will propose something plausible that a human then corrects. Consolidating accounts before implementation is unglamorous work with a direct payoff: fewer corrections, better learning, and a higher touchless rate.
A reasonable rule is that if two accounts are distinguished only by a distinction your team argues about, they should probably be one account, with the detail captured in a description field instead. Do this before you configure coding rules — not after the first round of exceptions.
Before you configure coding rules
Fewer accounts, better learning.
- Merge accounts your team argues about into one, and move the nuance into a description field.
- Do the consolidation before coding rules are written, not after the first exception wave.
- Expect the payoff in correction volume, not in a launch-day number.
Testing extraction on your real invoices
Pull a representative sample and ask the vendor to process that set and show you the extracted fields. Look specifically at line items, tax handling, and whether the invoice number and date come through cleanly, because those are what duplicate detection and matching depend on. Vendors who only demo their cleanest examples are telling you something about their confidence. A serious evaluation takes an afternoon and saves months of cleanup.
Highest-volume vendor
The invoice you see most
Start here. If your biggest vendor's format is already consistent, this is the easy pass — and it shows you the ceiling.
Messiest scan
The worst page you have
Pull the lowest-quality fax or photo in your recent history. This is where accuracy claims get tested honestly.
Foreign currency
A currency you actually pay in
If you pay vendors outside the US, include one. Capture has to identify the currency and the exchange rate basis.
Credit memo and statement
Documents that are not invoices
A credit memo reduces what you owe. A statement is a summary, not a bill. Both need their own handling path.
Handling duplicates and credit memos
Duplicate detection compares a new invoice against recent records, usually on vendor, invoice number, and amount. It catches the common case where a vendor emails the same invoice twice. It is less reliable when a vendor reissues an invoice with a new number after a correction, or when invoice numbers repeat across vendors.
Credit memos need separate handling. They reduce what you owe, and if your workflow treats them as invoices with negative amounts, approval thresholds and matching rules can behave unexpectedly. Configure credit memo handling explicitly rather than assuming it inherits the invoice path.
Watch for
Reissued invoices with fresh numbers, and invoice numbers that repeat across different vendors. Both slip past a simple three-field duplicate check.
Foreign currency and tax fields
If you pay vendors outside the US, capture needs to identify the invoice currency and the exchange rate basis, and coding needs to route to the right account for currency gains and losses.
Tax fields add another layer. US sales tax rules vary by state, and many invoices include tax lines that need to land in a tax account rather than being folded into the expense. Getting this wrong is subtle: the invoice totals match, so nothing looks broken, but the tax account drifts over time and someone has to reconcile it at year end.
Why it hides
The totals still tie out. The drift only shows up when someone reconciles the tax account at the end of the year.
Matching against purchase orders
Once captured and coded, an invoice moves into matching. If you issue purchase orders, three-way matching compares invoice, purchase order, and receipt. Tolerance settings determine how much variance is acceptable before an invoice becomes an exception.
Tight tolerances catch overbilling but generate more exceptions. Loose tolerances keep things moving but let small overcharges through. There is no universally correct setting. Look at your vendor history and decide what a reasonable price variance is for your business, then set the tolerance slightly inside it so exceptions are genuinely worth reviewing.
The exception queue
Exceptions are where capture projects succeed or fail.
A well-designed queue shows the invoice image, the extracted data, the reason for the exception, and who owns the resolution, all in one place. Resolutions should feed back into the system so the same problem does not repeat. If your queue is a shared inbox with a subject line, you do not have exception handling — you have a backlog. When you evaluate tools, spend more time on the exception interface than on the happy path. That is where your team will actually work.
The image
The original document, next to the extracted values, so a reviewer can see the mismatch immediately.
The reason
A plain cause — price variance, missing receipt, unfamiliar vendor — not a generic flagged-for-review tag.
The owner
One named resolver per exception, so nothing sits unassigned in a queue nobody actually reads.
The feedback
Resolutions should teach the system, so the same vendor and the same mistake stop repeating next month.
Accuracy over time
Capture accuracy usually improves after go-live, because the system learns from corrections and your vendor list stabilizes. The first month is the worst. Plan for more manual review early and less later, and do not judge the tool on week one.
What you should watch is whether corrections actually reduce repeat mistakes. If the same vendor's invoices keep landing in the wrong account after three months, the learning is not working, and that is a configuration problem worth escalating. Track corrections by vendor to see where the friction concentrates.
When to keep a human in the loop
Not every invoice should be automated. High-value payments, new vendors, and anything touching a regulated account benefit from human review regardless of how confident the extraction is.
A useful pattern is to auto-approve routine invoices and route the rest for review, then revisit the thresholds quarterly. Some teams also keep manual coding for a specific class of spend, like professional services, because the account depends on context the invoice does not carry. That is a reasonable choice. The goal is fewer errors, not an arbitrary touchless percentage.
Month one
The worst stretch. More manual review, more corrections, and a vendor list that has not settled yet.
Month three
The checkpoint. If the same vendor still lands in the wrong account, treat it as a configuration problem and escalate.
Ongoing
Review thresholds quarterly and track corrections by vendor to see where the friction actually concentrates.
Questions that come up before a pilot
If a question you need answered is not here, the full FAQ page covers the wider automation picture, or you can send us your invoice mix directly.
How long should a capture pilot run before I judge it? Open
Long enough to see the first month of corrections feed back. Week one tells you whether extraction runs at all; it does not tell you whether the learning works. A useful checkpoint is whether the same vendor's repeat mistakes are falling by the end of the third month.
What sample should I send a vendor for testing? Open
Your highest-volume vendor, your messiest scan, a foreign-currency invoice if you have one, a credit memo, and a statement. That set covers the common cases and the awkward ones in a single pass, and it shows whether the tool handles documents that are not invoices at all.
Should I clean up my chart of accounts first, or configure coding rules first? Open
Chart first. Automated coding can only choose among the accounts you give it, so overlapping categories produce plausible guesses your team corrects by hand. Consolidating before configuration is less visible work with a clearer payoff.
How much line-item detail should I expect from a dense invoice? Open
Totals usually come through correctly even when individual lines do not. If you need line-level coding for inventory or project accounting, test a real dense table rather than assuming the header-level result carries down to every row.
Test capture on the documents you actually receive
Send us your invoice mix and we will walk through what extraction and coding will look like on it — the clean vendors, the messy ones, and the documents that need their own handling path. No demo set, no clean examples only.
Where to go next
- Compare capture and coding tools
- See how capture connects to your accounting system
- Read the full FAQ
ClerDataFlo USA · 770 Innovation Way, San Jose, CA 95134 · Mon–Fri, 9:00 AM – 6:00 PM