Power Automate AI Builder for Invoice OCR: What Actually Works in Production

Why OCR is the step that makes or breaks an AP automation project

Most invoice automation projects fail at one step — not the approvals, not the ERP posting, but the OCR. If the document reader is 70% accurate on your supplier mix, your AP clerk spends more time correcting extractions than they used to spend capturing invoices, and the project quietly dies. If it is 95%+ accurate, the flow runs unattended and pays for itself in a quarter. This article is about how to get to 95%+ on real South African supplier invoices using Power Automate AI Builder.

If you want the end-to-end AP flow — capture, validate, approve, post, file — see our full Power Automate invoice processing guide. This post zooms in on the OCR mechanics.

Prebuilt vs custom: which AI Builder model to use

AI Builder ships two options for reading invoices, and choosing the wrong one is the most common mistake we see:

1. Prebuilt "Invoice processing" model

A pre-trained model that already knows what an invoice looks like. Zero training, zero examples — you point the action at a PDF and get structured JSON back with supplier name, invoice number, date, VAT, totals and line items. On a typical South African supplier mix (services invoices from consultants, utility bills, standard supplier invoices with a clean layout), we see 85–92% field-level accuracy out of the box. On line-item extraction specifically, accuracy drops to 70–85% because line-item layouts vary far more than headers.

2. Custom "Document processing" model

You train it on 5 or more example documents of a specific layout — say, invoices from one supplier — and it learns exactly where each field sits on that layout. On any invoice layout it has been trained on, we see 95–99% accuracy, including line items. The trade-off is that you need a small training set per layout and a light re-training pass when a supplier redesigns their invoice.

The right architecture is almost always both. Run the prebuilt model first as the default path. For your top 20 suppliers by volume — usually 60–80% of all invoices in a South African SMB — train a custom model per supplier and route to it based on the sender domain or extracted supplier name. Everything else falls through to prebuilt. That gets you 95%+ overall accuracy without training a model per supplier in your master file.

Real accuracy numbers from South African deployments

From production flows we have live in SA:

• Prebuilt only — 87% header accuracy, 78% line-item accuracy, ~18% of invoices touch exceptions.
• Hybrid (custom for top 20 suppliers, prebuilt for the rest) — 96% header accuracy, 93% line-item accuracy, 5–7% exceptions.
• Custom for every supplier — 98%+ across the board, but the training and maintenance cost is only worth it above ~3,000 invoices/month.

The categories that reliably need a custom model: utility invoices with dense tabular consumption data (Eskom, City Power, municipal accounts), freight invoices with per-line surcharges, and any supplier whose invoice is generated by an older ERP with a non-standard layout.

How to train a custom document processing model

1. Collect 5–20 invoices from the same supplier. More examples help edge cases (multi-page invoices, credit notes) but you can start production-ready with 5.
2. Create a Document processing model in AI Builder (make.powerplatform.com → AI Builder → Explore → Document processing).
3. Define the fields and tables you want extracted — supplier name, invoice number, date, VAT number, line description, unit price, quantity, line total, invoice total. Fields are single values; tables are line-item grids.
4. Tag the sample documents — draw a box around each field/column on each sample. This takes 3–5 minutes per document.
5. Train and quick-test. Training runs in 3–10 minutes. Test on an invoice the model hasn't seen — accuracy should be 95%+ on the trained layout.
6. Publish and use in Power Automate. Add the "Extract information from documents" action, point at the published model, and consume the structured output.

What AI Builder actually costs in South Africa

AI Builder is licensed in service credits, sold in packs of 1 million credits per month (list price around USD 500/month — verify current SA pricing with your Microsoft partner). Document extraction consumes credits per page processed:

• Prebuilt invoice processing — approximately 10 credits per page.
• Custom document processing — approximately 20 credits per page.

Worked example: an AP team processing 1,500 invoices/month averaging 2 pages each, running the hybrid model (60% custom, 40% prebuilt) uses roughly (1,500 × 2 × 0.6 × 20) + (1,500 × 2 × 0.4 × 10) = 36,000 + 12,000 = 48,000 credits/month. That is under 5% of a single 1M-credit pack — well inside one licence.

The credits are usually the smallest line item in the project. The larger cost is the Power Automate Premium licences for the users who trigger the flow and the engineering time to build validation, routing and ERP posting properly.

The exceptions design that keeps the flow running unattended

Even at 96% accuracy, you will get exceptions — 40 to 60 a month at 1,500 invoices/month. What separates a working flow from an abandoned one is how the exception queue is designed:

• Confidence thresholds. AI Builder returns a confidence score per field. Set a rule: if any critical field (total, VAT, invoice number) is below 0.85, route to the exceptions queue automatically — do not let a low-confidence value hit the ERP.
• Cross-field validation. Recompute totals from line items and compare to the extracted total. If they disagree by more than 1 cent, exception.
• Duplicate detection. Before the flow does anything else, query the ERP for supplier + invoice number. Duplicates are the single most common exception in month 1 of any deployment.
• A real UI for the AP clerk. Do not send exceptions as emails. Build a small Power App that shows the invoice PDF side-by-side with the extracted fields, lets the clerk correct the wrong ones in place, and posts to the ERP with one click. That app turns 15-minute exception handling into 60-second exception handling.
• Feedback loop into the model. Every correction the clerk makes is a labelled training example. Once you have 50–100 corrections for a supplier, re-train the custom model on those. Accuracy climbs quarter over quarter.

Things that will bite you if you skip them

• Password-protected PDFs. Some SA suppliers still send encrypted PDFs. AI Builder cannot read them. Handle this at the capture step — a shared mailbox rule that flags encrypted attachments and asks the supplier for an unlocked copy.
• Scanned invoices at 150 DPI or lower. OCR accuracy craters below 200 DPI. If a supplier is scanning invoices on an old copier, your accuracy will be 60% no matter which model you use. Fix the source or accept the exceptions.
• Multi-invoice PDFs. Some suppliers send a monthly statement with 10 invoices in one PDF. You need a preprocessing step to split by page markers before the extraction action runs.
• Currency and VAT edge cases. Zero-rated exports, imports with SARS deferment, foreign-currency invoices with no VAT — all need explicit validation branches or they will hit the ERP with the wrong tax code.

Frequently asked questions

Is AI Builder good enough for production invoice processing in South Africa?

Yes — with the hybrid model architecture (custom for top suppliers, prebuilt for the tail), we consistently reach 95%+ accuracy on real SA supplier mixes. It is not "AI magic that works on any document" — it is a solid OCR engine that needs a small amount of layout-specific training for volume suppliers.

How is this different from ABBYY, Rossum, Kofax, or Docsumo?

The specialist AP OCR vendors have slightly better out-of-the-box accuracy on the long tail of suppliers, but for a business already on Microsoft 365 the total cost of ownership is dramatically lower with AI Builder — you avoid a second licence, a second integration layer, and a second vendor relationship. For under ~5,000 invoices/month, AI Builder is almost always the right answer.

Can it read handwritten invoices or receipts?

AI Builder has a separate receipt processing model that handles handwritten totals reasonably well. Invoices with handwritten fields are hit-and-miss — treat them as exceptions.

Does it work offline / on-premise?

No — AI Builder runs in the Microsoft cloud. The document is transmitted to the AI Builder service, extracted, and the result returned. Data residency is Microsoft's regional data centre for your tenant. For POPIA compliance this is generally fine; if you have a specific regulator requirement for on-prem OCR, ABBYY FlexiCapture on-prem is the usual fallback.

Where to start

If you are evaluating AI Builder for invoice OCR, the fastest useful step is a 2-week proof-of-value on your five highest-volume suppliers — enough to prove the accuracy numbers on your actual documents before committing to a full build. See our Power Automate consulting service for how we scope that, or book a call.