Paper has not left accounts payable. Plenty of finance departments receive a meaningful share of their bills in an envelope, keep filing cabinets they are contractually obliged to keep, and have a backlog nobody has time to digitise. This page is about that physical reality: getting paper into the system, keeping the scanning process from becoming its own bottleneck, and deciding what to do with the originals afterwards.
Reads digital PDFs, scans and phone photos. Exports to Excel, CSV and JSON.
Compare the extracted fields and line items against your own document.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
Automated invoice scanning succeeds or fails at the point of digitization, and that point is usually staffed by whoever opens the post. The process needs to be dull enough to survive being done by different people on different days.
The decisions worth making once, in writing, are the separation method, the scanner settings and the destination. Separation is the awkward one: a stack of thirty invoices scanned in one pass produces one file unless something tells the system where each document ends. Barcode separator sheets, blank-page detection, or simply scanning in small batches all work; choosing none of them is what produces a 60-page PDF containing eighteen bills.
Once digitized, the file should go to exactly one destination, a watched folder or a monitored address, and never to someone's desktop. The most common failure in a scanning workflow is not misrecognition, it is a scanned invoice sitting in a personal folder that nobody else can see.
A backlog is a different project from steady-state scanning, and treating it as the same thing is why backlogs stay backlogs. It is bounded, it has no deadline pressure per document, and it can be processed in large batches during quiet periods.
The pragmatic approach is to work backwards from the most recent, because recent invoices are the ones people ask about. Set a cut-off date beyond which documents are scanned for archive only, without full field extraction, since nobody is going to post a bill from four years ago. They only need to find it.
It is also worth deciding explicitly what "done" means before starting. Full extraction with validation on everything is expensive and rarely necessary. Extraction on the last two years and image-plus-index on the rest is a defensible position that finishes.
A scanned invoice carries the same purchase order reference as a native PDF, but it carries it less reliably. A smudged digit or a low-contrast footer turns "PO-40381" into "PO-4O38l", which then matches nothing at all.
Two things make matching robust against this. The first is fuzzy reference matching that tolerates the specific confusions optical recognition makes, zero against O, one against l, five against S, rather than demanding an exact string. The second is matching on the invoice content when the reference fails: supplier, date range and total against open purchase orders will usually identify the right one even when the quoted reference is unreadable.
Anything that still cannot be matched should be visible as an exception with the scan attached, not silently posted as a non-PO invoice. Bills that quietly bypass matching are how purchase-order controls stop meaning anything.
Retention rules vary by jurisdiction and by tax authority, and they are the reason many teams keep boxes they never open. Whatever period applies to you, the practical question is whether the digital copy satisfies it or whether the original must survive.
That is a question for your accountant or auditor rather than for a software vendor, and the honest answer in most cases is that it depends on the jurisdiction and on how the digital copy was produced and stored. What software can do is make the digital side defensible: keep the original scan unaltered, link it to the extracted data, and record every subsequent edit against the document with a timestamp and a user.
A useful test is whether you could hand an auditor a single invoice and show, without assembling anything by hand, the image that arrived, the values read from it, every change made afterwards, who approved it and what was posted.
It is the use of optical character recognition inside the payables function: converting scanned or photographed supplier invoices into structured data so they can be validated, matched, approved and posted without manual typing. The technology is the same as general invoice OCR; the surrounding workflow is what makes it payables-specific.
Scan at around 300 dpi in greyscale with deskew and despeckle enabled, and use a consistent method to separate one document from the next: barcode separator sheets, blank-page detection or small batches. Send the output to one monitored destination rather than to individual desktops.
Yes. Multi-invoice files are split by detecting where one document ends and the next begins, using layout cues such as a new supplier header or a fresh invoice number. Anything ambiguous is surfaced for a person to confirm rather than split silently.
That depends on your jurisdiction and your auditor, and it is a question for them rather than for a software vendor. What the system provides is a defensible digital record: the unaltered original scan, the data extracted from it, and a timestamped history of every change afterwards.
Generally yes, because a native PDF already contains a text layer while a scan must be recognized from pixels. The gap is narrowed considerably by good scanning practice, and the remaining uncertainty shows up as lower per-field confidence, which routes those specific fields to review.
Invoice OCR software that reads scanned, photographed and native PDF bills. How invoice OCR differs from generic text recognition, why templates break, and what per-field confidence means.
Accounts payable automation that reads every supplier invoice, matches it to your purchase orders, routes it for approval and posts it to your ledger. See how AP automation works end to end.
Bulk invoice processing for high volumes: uploading hundreds of documents at once, queue behavior, parallelism, partial failure handling, splitting multi-invoice PDFs and surviving month-end spikes.
Invoice processing software for teams handling steady invoice volume: automatic capture, validation rules, exception queues and clean export to your accounting system.
A complete guide to invoice data extraction: which fields are captured, how header data differs from line items, what structured output looks like, and how extracted values are validated.
Upload a few of your least tidy supplier invoices and compare the extracted fields against the documents. That tells you more than any feature list.
