AI Builder in Power Automate: Automating Invoice and PO Matching for FMCG Finance

An FMCG finance team processing supplier invoices runs a three-way match: does the invoice agree with the purchase order it references and the goods actually received? When all three line up, the invoice should simply be approved for payment. The reality is that this clean case still consumes clerical time, and the mismatches — a price that moved, a partial delivery, a quantity that does not tie — consume far more, because each one is chased by hand.

The volume makes it painful. Thousands of invoices a month, a large share of them clean matches that a person checks anyway, and a stubborn tail of exceptions that eat the team’s attention. The clean cases are pure overhead; the exceptions are where judgement is genuinely needed.

So the automation opportunity is precise: remove the clean matches from human hands entirely, and route only the real discrepancies to a person, with the discrepancy already identified. AI Builder and Power Automate are built to do exactly that on a Microsoft estate.

Supplier invoices arrive as PDFs, emails and scans in inconsistent layouts. AI Builder’s document processing reads them and extracts the structured fields a match needs — supplier, invoice number, PO reference, line items, quantities, unit prices and totals — turning an unstructured document into data a flow can act on. For common invoice shapes this works out of the box; for a supplier’s unusual layout, the model can be trained on examples to extract reliably.

This extraction is the part everyone notices, because reading a messy invoice automatically feels like the clever bit. It is necessary, but it is not where the value is. Extracting the invoice into fields only gets you to the starting line of the actual task, which is the match.

The honest caveat is that extraction is never perfect on every document, so the flow must treat low-confidence extractions as exceptions to review rather than facts to act on. An invoice the model could not read cleanly is routed to a person, not guessed at — which keeps a bad read from becoming a bad payment.

With the invoice in structured fields, a Power Automate flow performs the three-way match against the PO and goods-receipt data pulled from the ERP. It checks that the invoice references a valid PO, that quantities invoiced match quantities received, and that prices match the PO within tolerance. Where everything agrees within the rules, the invoice is approved automatically and passed for payment — no human touch at all.

The match rules are the heart of it and have to be explicit. Real FMCG purchasing is not tidy: there are agreed price tolerances, partial and split deliveries, volume rebates, and legitimate variances that should pass. Encoding those rules — what counts as a match, what tolerance is acceptable, how partial deliveries reconcile — is the design work that decides whether the automation clears the clean cases correctly or flags half of them wrongly.

Get the rules right and the flow absorbs the volume: the large share of invoices that genuinely match clear automatically, and the team never sees them. That is the saving — not the reading, but the clean cases disappearing from the queue.

When the match fails, the flow does not stop at "exception" — it routes the invoice to a finance reviewer with the discrepancy already identified: this invoice price is 6% above the PO, this quantity exceeds what was received, this PO number was not found. The reviewer opens a case that already tells them what is wrong, rather than starting a reconciliation from scratch.

That framing is most of the human-side saving. The exceptions still need judgement — approve the variance, query the supplier, hold for a credit — but the investigation is pre-done. The person spends their time deciding, not discovering, and the volume of clean cases that used to dilute their attention is gone.

Routing should also reflect the organisation: different thresholds to different approvers, high-value variances escalated, a clear audit trail of who approved what. The flow carries the exception to the right person with the right context, and records the decision — so the exception process is as governed as the auto-approval path.

Automating invoice and PO matching with AI Builder and Power Automate works when you keep the division of labour honest: AI Builder reads the document, the flow performs the three-way match against ERP PO and receipt data under explicit rules, clean matches auto-approve and vanish from the queue, and only genuine mismatches reach a person — with the discrepancy already identified and the decision recorded. The machine takes the volume; the finance team keeps the judgement.

The measure of success is not "the invoice was read" but "what share of invoices now clear without a human, and do the exceptions arrive pre-diagnosed?" If most clean matches auto-approve and reviewers open cases that already state what is wrong, the automation has done its job. If low-confidence reads are being auto-paid, the rules or the confidence handling need work before it scales. We build these on the Microsoft Power Platform, matching against the governed ERP data a Fabric foundation already provides.