AI Invoice Routing for a Multi-Entity Group

A shared finance mailbox was the intake point for supplier invoices across roughly 20 legal entities, at around 400 invoices a month. Each email had to be opened, the invoice read, the Bill-To entity identified and the email forwarded to that entity's Business Central ingestion address.

That work is repetitive, easy to get wrong and invisible until something lands in the wrong ledger. The brief was to automate the routing without automating the mistakes: an invoice sent to the wrong entity is worse than one that waits for a person.

The agreed target was 95% or more of invoices routed automatically, with zero mis-routes, and routing rules the finance team could change without a developer.

Extraction reads, rules route. Azure Document Intelligence's prebuilt invoice model reads the customer name (the Bill-To) and returns a confidence score for that field. The decision about where the invoice goes is made by the flow, against the finance team's own routing table, never by the model.

Auto-route only when every gate passes. An invoice is forwarded automatically only when the Bill-To was identified, the analysis did not fail, the confidence is at or above the threshold (0.80 by default) and there is exactly one matching row in the routing table. Anything else goes to the exception queue with a plain-English reason.

Four exception cases, designed first. Bill-To not identified, confidence below the threshold, more than one possible match, and an attachment that could not be read. The lookup deliberately fetches up to five matches so ambiguity is detected rather than hidden behind the first result.

Any common invoice format. PDFs and images (including scans) go straight to Document Intelligence. Word, Excel, RTF and similar files are converted to PDF through OneDrive for Business first, because the invoice model does not read Office formats. That conversion path is controlled by a solution environment variable, so an environment can switch it off without editing the flow; unsupported files then go to the exception queue.

Nothing crashes the run. The whole analysis block sits inside a try/catch scope. A corrupt, password-protected or unconvertible file is flagged as unreadable and routed to a person.

Maintainable by the business. Onboarding a new entity is one row in a SharePoint list. The threshold and exception address are configuration. The original email and attachment are forwarded untouched, so Business Central receives exactly what the supplier sent.

Delivered as a proper solution. The flow ships as a Power Platform solution package with a solution design document, SharePoint list schemas, a ten-scenario UAT plan, a production deployment runbook with rollback steps, a knowledge-transfer agenda and a requirements traceability matrix.

Connection references belong in one place only. The first solution packages failed to import with Invalid component type provided 10112. The root cause was declaring connection references as root components in solution.xml. Removing them entirely produced a different failure at publish. Diffing my package against a real export from the target environment showed the fix: declare them only in customizations.xml. Building on a genuine export rather than hand-authoring the package structure is now how I start every solution build.

The exception queue is the product. Anyone can pull a name off an invoice. Trust comes from what happens when the read is uncertain, so the exception rules were designed before the happy path.

Use the confidence score. Extraction services return a confidence for every field and it is the number that decides whether a person needs to look. Ignoring it makes wrong routing look like success.

Secrets do not belong in flow variables. For portability during the build the service key sat in a flow variable. The design document flags it for production: move it to a Key Vault backed environment variable so it is never readable in an exported solution.