How OCR and document capture removed manual invoice entry from accounts payable, what it genuinely automates, and what it does not.
Accounts payable is the finance process that has changed most in the past decade, and the change is not what most people assume. The interesting development is not that invoices arrive electronically. It is that a machine can now read a document reliably enough that a person no longer has to type what it says.
That single capability removes the largest single block of manual effort in a finance function, and it changes what accounts payable staff spend their time on rather than only how quickly they do it.
This article covers what the technology actually does, where it works and where it does not, and what has to be true for it to deliver.
At its simplest, optical character recognition converts an image of text into machine readable text. That capability is old and it is not the interesting part.
The interesting part is what sits on top. Recognising that a document is an invoice, identifying which number is the invoice number, which is the total, which is the tax and which is the date, and matching the supplier name to a record in your system.
Early implementations did this with templates. Each supplier's invoice layout was mapped once, and the system extracted fields from known positions. That worked and it required setup per supplier and broke whenever a supplier changed their layout.
Modern approaches are model based rather than template based. The system has learned what invoices generally look like and can extract fields from a layout it has never seen. That difference is what made the technology practical for businesses with long supplier tails rather than only for those with a handful of high volume suppliers.
The traditional accounts payable process has a specific shape, and the technology attacks one part of it.
An invoice arrives, usually by email. Somebody opens it, reads it, and types the supplier, the date, the invoice number, the amounts and the tax into the finance system. Then they code it, then they route it for approval, then it gets paid.
Data entry is the block being removed. Where the document is read automatically, the invoice record is created with the fields populated, and the person's job becomes checking rather than typing.
That is a substantial change in a business processing any volume. It is also a change in the nature of the work, from transcription to exception handling, which most accounts payable staff regard as an improvement.
What it does not remove is coding, approval, matching and payment. Those are separate problems with separate solutions, and businesses that expect capture technology to solve them are usually disappointed.
The honest position on accuracy is that it is high and not perfect, and the process has to account for that.
Clean digital documents from a supplier with a conventional layout extract very reliably. Scanned paper, photographs taken on a phone, unusual layouts, handwritten annotations and multi page invoices with the total on the last page are all harder.
The important design principle is that the system should tell you when it is uncertain rather than guessing silently. An extraction with low confidence flagged for human review is useful. One presented with the same confidence as a correct extraction is dangerous, because it moves errors past the point where anybody looks.
The practical implication is that the review step remains, and it changes character. Instead of typing every invoice, somebody reviews every invoice quickly and corrects the few that need it.
Businesses that measure this generally find the review takes a fraction of the entry time, and that the error rate falls rather than rises, because reading and confirming is more reliable than reading and retyping.
The capability that makes these systems improve over time is that corrections feed back.
Where somebody corrects an extracted field, the system records that this supplier's invoices have the relevant value in a different place, or that this supplier name maps to that vendor record.
The result is that accuracy improves for the suppliers you actually use, which is more useful than general accuracy. A business with two hundred regular suppliers finds that after a few months, those two hundred extract almost perfectly, and the exceptions are new suppliers and one off documents.
That has an implication for evaluation. A pilot run over two weeks understates what the system will eventually do, because it has not yet learned your supplier base. Judging on early accuracy is judging the wrong thing.
Capture gets the invoice into the system. Matching establishes whether it should be paid, and that is where the more valuable automation sits.
Three way matching compares the invoice against the purchase order and the goods receipt. Where all three agree within tolerance, the invoice can proceed without human intervention. Where they do not, somebody investigates.
This is where accounts payable effort concentrates in businesses that buy physical goods, and it is where the largest savings are available.
The prerequisite is that purchase orders are raised and goods receipts are recorded. Where the business orders informally and receives without recording, there is nothing to match against, and the technology cannot help.
That is worth stating plainly, because businesses frequently buy capture technology hoping to fix an accounts payable problem whose actual cause is that procurement is informal. Fixing the ordering process is the prerequisite rather than the follow up.
Coding is the other manual step and it automates partially rather than fully.
Where an invoice matches a purchase order, the coding comes from the order, which is the cleanest case and requires no decision at all.
Where there is no order, rules can handle a substantial proportion. A supplier who only ever provides one category of service can default to that account. Recurring invoices can inherit the coding from the previous instance.
What does not automate well is genuinely variable coding, meaning an invoice that could reasonably belong to several projects, departments or categories depending on circumstances the document does not state.
The practical approach is to automate the predictable majority through rules and defaults, and to route the remainder to somebody who knows. That is a considerably better use of judgement than applying it to every line.
Once an invoice is in the system with coding attached, routing it for approval is straightforward automation and is where a good deal of elapsed time currently goes.
Rules based on amount, category, department or supplier send the invoice to the right approver without anybody deciding. Reminders chase without anybody chasing. And the status is visible, so the question of where an invoice is has an answer.
The design principle worth holding is minimalism. Every additional approval step adds delay, and delay produces the situation where suppliers chase, relationships strain and early settlement discounts are missed.
Matched invoices within tolerance arguably need no approval at all, since the approval happened when the purchase order was raised. Businesses that require a second approval on matched invoices are approving the same decision twice.
It is worth being specific about the benefits, because the case is frequently made on data entry time alone and that understates it.
Processing time falls, which is the visible benefit and the easiest to measure.
Elapsed time falls further, because invoices reach approvers immediately rather than after a batch is processed, which means less supplier chasing and fewer late payments.
Error rates fall, because reading and confirming beats reading and retyping, and because duplicate detection catches what humans miss.
Visibility improves, because accrued liabilities are known rather than estimated. Invoices received and not yet approved are in the system, which means the period end accrual is calculable.
And the accounts payable role changes, from transcription to supplier relationships, exception resolution and process improvement, which affects retention in a role that is otherwise difficult to fill.
A specific benefit worth calling out because duplicate payments are more common than businesses assume.
The circumstances are ordinary. A supplier sends a statement and an invoice and both get processed. An invoice is emailed to two people and both submit it. A credit note is applied and the original is paid anyway.
Manual detection depends on somebody recognising a familiar amount, which works occasionally.
Systematic detection on supplier, amount, date and invoice number catches these reliably, and it catches them before payment rather than during a subsequent audit.
For businesses that have never checked, a review of historical payments for duplicates is worth running once. Most find something, and some find enough to fund the technology.
Being honest about the limits prevents the disappointment that follows overselling.
It does not fix informal procurement. Where purchase orders are not raised, there is nothing to match against and the invoice still requires a human decision about whether it should be paid at all.
It does not resolve disputes. An invoice that does not match because the delivery was short is a supplier conversation, and no technology shortens it.
It does not handle genuinely unusual documents well. Complex construction claims, invoices with extensive supporting schedules, and documents in unusual formats will need human handling.
And it does not reduce headcount proportionally in a small team. A business processing two hundred invoices a month saves real time and does not save a person, because the person does other things as well.
The architectural question is the same one that applies across finance applications.
A standalone capture product processes documents and passes the result to your finance system, which means an integration to maintain and a second place where invoices exist during processing.
A capability within the ERP itself creates the payable record directly, with the approval workflow, the matching and the payment all in the same system.
The second removes an integration, removes a reconciliation, and means the invoice image is attached to the transaction rather than stored elsewhere, which matters for audit and for answering supplier queries quickly.
For businesses on NetSuite, capability exists within the platform and through applications built natively on it, and checking what the standard configuration already supports before buying anything is the usual discipline.
A few practical points separate implementations that deliver from those that disappoint.
Clean the vendor master first. Extraction matches supplier names to vendor records, and a master file full of duplicates and inconsistent naming produces matching failures that look like technology failures.
Establish a single intake channel, meaning one email address that all invoices arrive at, rather than invoices reaching individuals. Where invoices arrive in six inboxes, capture only sees some of them.
Fix procurement before expecting matching to work, since the prerequisite for three way matching is that orders and receipts exist.
Start with your highest volume suppliers, where the learning effect is strongest and the return is quickest, then broaden.
And keep the review step until the accuracy is proven for your supplier base rather than removing it on the strength of a demonstration.
The measures worth tracking are specific and easy to collect.
Time per invoice from receipt to posted, which captures the processing improvement.
Elapsed time from receipt to approved, which captures the workflow improvement and is usually the larger number.
The proportion of invoices requiring manual correction, which should fall as the system learns.
The proportion matching automatically without intervention, which indicates how well procurement discipline is working.
And the number of duplicate payments prevented, which is the benefit nobody predicts and everybody appreciates.
Document capture technology is now reliable enough that manual invoice entry is a choice rather than a necessity for most businesses processing meaningful volume.
The larger opportunity sits behind it in matching and approval workflow, and those depend on procurement discipline rather than on the technology.
The useful first step is measuring what accounts payable currently costs in time, and establishing what proportion of invoices could match automatically if orders and receipts were consistently recorded. That second number usually determines how much the technology can actually deliver.
Our piece on expense management procedures covers the adjacent process, and managed services covers the ongoing capability to configure and maintain automation properly.
If you would like a view on what your accounts payable process could realistically automate, get in touch.
