An Israeli non-profit that runs several residential centers was keying every supplier invoice into its ERP by hand. I led the build of a platform that reads scanned invoices with Azure AI Document Intelligence, runs 14 automatic checks on every one, and sends people only the invoices that actually need a human decision.
Suppliers send tax invoices, consolidated invoices, delivery notes and credit notes, often as phone scans or emailed PDFs and sometimes handwritten. Before anything could be entered into the ERP, someone had to read each one, check that it was addressed to the organization, work out which center it belonged to, check the arithmetic, look for a stamp and signature, and make sure it had not already been entered. The work was slow and repetitive, and mistakes were easy to miss.
The diagram is wider than the screen: swipe sideways to see all of it →
The ERP is reached only through one provider (an anti-corruption layer). In Phase 1 it exposes read-only lookups, and every provider without configuration fails closed, so nothing ever pretends an integration answered. The queue sits behind an interface: SQL-backed for now, Azure Service Bus later through DI, with no change to business code.
The OCR model is good but not trustworthy on its own. Anything the system repairs, such as table rows it rebuilds or reference lines it drops, is accepted only when the result sums exactly to the printed total. Trade-off: more invoices go to a person early on, but nothing unverified gets in.
A center, SKU or budget code resolves only when exactly one candidate matches. Zero matches means Not found and several means Ambiguous, and both send the invoice to review. Reviewer edits are never overwritten. Trade-off: lower automation until the real mapping data is loaded.
The Azure environment wasn't decided yet, so the queue runs on SQL Server with an atomic claim, retries, backoff and dead-letters, behind IProcessingQueue. Handlers are idempotent. Trade-off: it polls every 5 seconds, which is fine at this volume.
The customer postponed Entra ID. Instead of leaving the API anonymous, it issues short-lived JWTs from a simulated sign-in, using the same claims, guards and audit identity. Trade-off: switching to Entra ID replaces only the token issuer.
Tests with real customer documents came early and often. Each problem below came from a real invoice.
A read-then-update claim lets two consumers pick up the same queued document.
Claimed messages with a single SQL statement that updates one row and returns it, so there is no gap for a race. Messages stuck in processing after 10 minutes are recovered, and after 3 attempts they go to a dead-letter list that operators can requeue.
On a handwritten invoice the service read 28,500 as 2,800 and 5,130 as 130, with field confidence 0.98 and document confidence 1.0.
Reported confidence is now the minimum across all critical header and line fields. The arithmetic cross-checks (lines → subtotal → VAT → total, with zero tolerance) became the main safety net, and they caught this invoice.
On dense printed tables the model merged rows or shifted quantities and prices between lines.
When the model's lines don't add up, the system rebuilds them from the recognised table grid. The rebuild is kept only if it sums exactly. Reviewers can also add, remove and split lines, and the original reading is kept unchanged.
A tax ID in small print was read correctly, but at 0.54 confidence, below the 95% threshold. Without a fix, most scanned documents would have failed on this one field.
Israeli company and personal IDs carry a check digit. An ID that passes the checksum is treated as verified and left out of the confidence minimum. The customer approved this as a recorded exception to the threshold policy.
The development tier analyses 2 pages per call. In one file the delivery note on pages 1–2 had the lines, and the tax invoice came after them.
Later pages are analysed too, and only the missing identification fields are taken from them. Amounts stay with the primary result, and if the extra page was read with lower confidence, that lower confidence is the one reported.
The model took the number printed next to the delivery-note title as the invoice number.
That number now goes into dedicated delivery-note fields, and the invoice number is left empty. The required-field rule then asks the reviewer for the real one. Credit notes are handled the same way.
A single upload sometimes held more than one invoice.
The file is split into separate documents in the same process, but only when each part has its own invoice number and payable total. Weaker candidates stay attached to the main invoice.
Some scans were printed email threads where a center manager had replied “approved”.
A conservative, deterministic detector looks for email-thread markers plus an approval word on a line of its own (“not approved” never matches). It shows up as a hint for the reviewer and never approves anything automatically.
A walkthrough with a synthetic invoice: supplier, center and amounts are invented. Choose a stage to see what the system does and which safeguard applies.
| Area | Before | After |
|---|---|---|
| Data entry | Every field typed by hand | Extracted automatically. People review only flagged invoices (≈6 → ≈1 min each, estimate) |
| Checks | By eye, and it varied by person | 14 rules on every invoice, with 12 named exception reasons |
| Confidence | One document score (1.0 on a misread invoice) | Lowest score across every critical field, plus exact arithmetic checks |
| Approvals | One document at a time | Multi-select bulk approval, with the approver's identity and time recorded |
| Multi-invoice files | Separated by hand | Split automatically into separate documents, each validated on its own |
| Failures | Silent | 3 retries with backoff, a dead-letter list with requeue, and a daily report |
| Database setup | Manual migration steps | One-command install, plus backup and restore scripts |
Phase 1 covers intake, extraction, matching, validation, review and approval, tested on real customer documents. The ERP read lookups (M7) are waiting on the ERP vendor's API details. Posting to the ERP and mailbox intake are planned for the next phases.
Free scoping call · 30 minutes · No commitment
Write a few lines: the process or system, what hurts today (time, errors, cost or an AI pilot that stalled) and who uses it. After a short call you get a written plan and a fixed quote within ≈3 days.
Opens a pre-filled email · reply within one business day
The model reads. The code counts.
All projects