How to automate invoice data entry, end to end

Invoice data entry automates well because invoices are semi-structured: the fields you want are in different places on every vendor's template, but they are the same fields every time. The major cloud parsers charge about a penny a page to pull them out, and the work that actually decides whether the project succeeds is the exception queue you build behind them.

Prices and limits here were checked against each vendor's own documentation in September 2026. This article does not claim any accuracy figure of its own — where a number appears, it comes from the vendor's page and is linked.

The pipeline has five stages, not one

People say "OCR the invoice" as if that were the whole job. In practice a working setup has five stages, and only the second is OCR:

1. Intake. Invoices arrive as PDF email attachments, scans, or supplier portal downloads. Something has to collect them into one place and record where each one came from.
2. Extraction. A document AI model returns field values and confidence scores.
3. Validation. Your own rules: does the math add up, does the PO exist, is this a duplicate invoice number from the same vendor.
4. Exception handling. A human looks at whatever failed validation or scored low, and fixes it.
5. Posting. The approved record goes into the accounting system, with the original file attached.

Stages three and four are where the savings are won or lost. Extraction is a commodity now. Deciding what to do with a field the model isn't sure about is not.

What the parsers extract

The vendor docs are specific about this, which makes them worth reading before you scope anything. Amazon's AnalyzeExpense documentation lists a normalized taxonomy that includes INVOICE_RECEIPT_ID, INVOICE_RECEIPT_DATE, DUE_DATE, PO_NUMBER, PAYMENT_TERMS, VENDOR_NAME, TOTAL, SUBTOTAL, TAX, AMOUNT_DUE, AMOUNT_PAID, DISCOUNT and SHIPPING_HANDLING_CHARGE, along with vendor and receiver addresses broken into street, city, state, country and ZIP. Line items come back as rows, with ITEM, QUANTITY, UNIT_PRICE, PRICE and PRODUCT_CODE.

Crucially, the same docs show confidence returned at three levels: on the field type, on the label as printed, and on the extracted value. That third number is the one your routing rules should read.

Microsoft's prebuilt invoice model documentation covers similar ground — invoice ID, customer and vendor details, bill-to and ship-to addresses, due date, amount due, line items — and states the model currently supports invoices in 27 languages.

What they read badly

Vendors publish limits rather than failure rates, so read the limits. Microsoft's invoice page documents a maximum file size of 500 MB on the paid tier and 4 MB on the free tier, up to 2,000 pages per PDF or TIFF (free tier processes only the first two pages), image dimensions between 50x50 and 10,000x10,000 pixels, and a minimum text height of 12 pixels on a 1024x768 image — roughly 8-point text scanned at 150 DPI.

That last one is the practical constraint most people hit. A faxed invoice, a phone photo taken at an angle, a third-generation photocopy: these fall under the documented minimum, and no amount of tuning fixes an image the model cannot resolve. Fix the intake instead. Ask suppliers for PDFs. Set the office scanner to 300 DPI.

Two more honest gaps. Handwritten amounts and handwritten annotations in the margin are not covered by any accuracy commitment in the invoice-specific docs we checked. And multi-page invoices with line items that continue across a page break are a known source of quiet errors, because the row that belongs to page two can be reported without its header context.

What it costs per document

These are list prices from the vendors' pricing pages, checked September 2026, for US regions.

Sources: Textract pricing, Document AI pricing and A2I pricing. Microsoft's Document Intelligence pricing page renders its figures only after you select a region and currency, and we could not read a US number from it, so none is quoted here. Its documented free tier is 500 pages a month.

Now the arithmetic. Say you process 2,000 invoices a month averaging two pages each: 4,000 pages. At $0.01 a page that is $40 in extraction. Suppose you route 15% of documents to a human — that percentage is an assumption you will replace with your own measured rate, not a benchmark — so 300 documents at $0.03 is another $9. Call it under $60 a month in vendor fees.

Where a human still has to check

Microsoft's accuracy and confidence documentation explains that a confidence score "indicates probability by measuring the degree of statistical certainty that the extracted result is detected correctly," and that a 0.95 score means the prediction is likely correct 19 times out of 20. For custom models it advises targeting 80% or higher, and "for more sensitive cases, like financial or medical records, we recommend a score of close to 100%." It also says plainly that confidence can be used to decide whether to accept a prediction automatically or flag it for human review.

Nineteen out of twenty is not good enough for a payment amount. Set the thresholds by field, not globally:

• Always reviewed, regardless of score: total amount due, bank account or remittance details, and any invoice above whatever dollar figure your controller names.
• Reviewed below a high threshold: vendor name, invoice number, PO number, tax amount.
• Reviewed below a lower threshold: line item descriptions, product codes, dates other than the due date.

Then add rules that do not depend on confidence at all. Line items plus tax must equal the total. The invoice number must not already exist for that vendor. The PO must exist and have enough remaining balance. A vendor's bank details changing between invoices should stop the document cold and page a person — that is the single most common invoice fraud pattern, and no model confidence score will catch it because the model read the new account number perfectly.

A followable first month

Week one: collect 200 real invoices from your last quarter, including the ugly ones. Run them through one parser's free tier or trial and export the results with confidence scores to a spreadsheet. Do not tune anything yet.

Week two: hand-key the same 200 invoices, or use the values already in your accounting system, and compare field by field. You now have your own accuracy number for your own supplier mix, which is worth more than any vendor claim.

Week three: set thresholds from that comparison, build the validation rules above, and build the review screen — the original image on the left, the extracted fields on the right, editable, with low-confidence fields highlighted. Every reviewer correction gets logged.

Week four: run in parallel. The automation posts nothing; it produces a proposed record that a person approves. Only after a few weeks of the approve rate holding steady should you let anything post unattended, and even then, keep the dollar ceiling and the bank-detail rule as hard stops.