Invoice processing automation with Power Automate: extraction and review

Start with a review queue

Build the first version around one result: a reviewer can open an invoice, compare the extracted fields with the original and record a decision. An extraction action returning successfully does not mean the invoice is correct.

This guide uses Power Automate, AI Builder and a SharePoint review list. The companies, documents and outputs below are made up. They are planning examples, not results from a running customer system.

Keep payment, supplier bank changes and accounting decisions outside this flow. A status of Reviewed means someone checked the captured data. It does not mean approved for payment. This is a document-processing guide, not tax or legal advice.

Start with one invoice per upload and a small set of known suppliers. Keep quotations, statements, credit notes and unreadable files in a separate review category. Do not decide that every attachment is an invoice because its email mentions a payment.

Define the record before building the flow

Give each intake its own ID. Also keep the supplier's invoice number as text. These identify different things: an intake is a received document; an invoice number belongs to the supplier.

Preserve the first extraction and store corrections separately. Otherwise a reviewer cannot tell whether a wrong value came from the document, the extraction or a later edit. Keep the original document in a location the assigned reviewer can open.

Use states such as Extracting, Needs review, Ready for sign-off, Reviewed and Rejected. Extraction failed is also a useful state. These are fields you create, not built-in AI Builder workflow states.

Build the first version in Power Automate

Check your environment, access and available capacity first. AI Builder actions need the appropriate Power Automate licensing and consume capacity when run. Confirm that with the person who manages the environment before scheduling a batch. Microsoft explains the current licensing requirements.

1. Create an instant cloud flow with Manually trigger a flow and add a File input.
2. Save the input in a private SharePoint document library with a unique intake ID in its name. Create a review-list item before extraction so a failed attempt still has a record.
3. Add AI Builder's Extract information from invoices. Map the uploaded file content to Invoice file. Use the action's dynamic outputs to fill your review fields.
4. Keep currency as a separate review field. The documented action output list does not provide a Currency output. Do not invent a mapping named Currency or infer it from the tenant's default.
5. Update the existing list item with the extracted values and checks. Leave missing values empty, with a reason. Route every pilot record to the reviewer.

The file-input and extraction steps follow Microsoft’s invoice action instructions. The storage steps use SharePoint's Create file, Create item and Update item actions; map the saved item's ID into later updates. See the SharePoint connector reference.

Use a second, manually started sign-off flow after corrections. Re-read the record, confirm required fields and compare its saved document version. Then use Start and wait for an approval, assigned to your configured reviewer. Include the source link and the values being reviewed. Record the decision and comments. Microsoft documents the approval action.

A rejection returns the item to Needs review. A timeout leaves it pending. Neither outcome should set Reviewed. If the source or reviewed values change while approval is outstanding, request a new review against the new version.

Example 1: a clear invoice with matching totals

Input: Northfield Services, confirmed supplier S-17, sends invoice 000742 for purchase order PO-917. It shows two net line amounts, 450.00 and 150.00, tax of 48.00 and a total of 648.00 USD.

Setup: Keep invoice and purchase-order IDs in text fields. Store amount fields as numbers, but preserve their printed text too. The reviewer confirms the printed USD currency. For this example, line amounts exclude tax and there are no discounts, shipping charges or previous balances.

{
  "intake_id": "D-01",
  "supplier_id": "S-17",
  "invoice_id": "000742",
  "purchase_order": "PO-917",
  "subtotal": "600.00",
  "tax": "48.00",
  "invoice_total": "648.00",
  "amount_due": "648.00",
  "currency_reviewed": "USD",
  "arithmetic_difference": "0.00",
  "state": "Needs review"
}

Expected output: one record linked to one source document. The leading zeros survive. The reviewer sees 450.00 + 150.00 + 48.00 = 648.00 and can move the corrected record to sign-off. This is your review-record format, not the action's raw response schema.

Failure and recovery: if the list shows 742, change the invoice field and mapping to text, then restore 000742 from the source. A successful arithmetic check must not skip the document review.

Example 2: the extracted total does not add up

Input: invoice 000743 shows net lines of 300.00 and 120.00, tax of 33.60 and a printed invoice total of 463.60. The example explicitly has no other charges or discounts.

Setup: Compare amounts using decimal arithmetic or integer minor units for the confirmed currency. Here, the currency uses two decimal places. Do not apply that assumption to every currency. Keep the printed total unchanged.

Net lines:       300.00 + 120.00 = 420.00
Expected total:  420.00 + 33.60  = 453.60
Printed total:                     463.60
Difference:      463.60 - 453.60 =  10.00
Route: Needs review
Reason: total_mismatch

Expected output: a 10.00 difference and an explicit review reason. The reviewer checks whether extraction missed a fee, read a digit incorrectly or treated a tax-inclusive line as a net line.

Failure and recovery: do not replace 463.60 with 453.60 automatically. If the source confirms a separate 10.00 fee, capture that field and repeat the check under the documented calculation. If it remains unexplained, keep the item unresolved.

Also compare the right fields. InvoiceTotal represents the current invoice charges; AmountDue can include a previous unpaid balance. A 648.00 invoice with a printed previous balance of 100.00 may show 748.00 due. That difference needs explanation, not an automatic error correction. See Microsoft’s field definitions.

Example 3: the currency or date is missing

Input: a PDF shows a total of $1,250.00. No currency code is printed in the extracted fields, and the invoice date is unreadable. The supplier operates in more than one country.

Setup: Require a confirmed currency and invoice date before sign-off. Use separate missing-field flags. A dollar sign alone is insufficient to choose USD rather than CAD or another dollar currency.

{
  "invoice_total_text": "$1,250.00",
  "currency_reviewed": null,
  "invoice_date": null,
  "review_reasons": ["currency_missing", "invoice_date_unreadable"],
  "state": "Needs review"
}

Expected output: the reviewer gets both reasons and the original document link. The flow keeps the received date in its own field; it does not substitute that date for the invoice date.

Failure and recovery: a required field filled with today's date can look complete while being wrong. Clear the invented value, check the document and use your normal supplier-confirmation process if necessary. Record who confirmed the missing facts.

For a pilot, manual currency confirmation is often simpler than another extraction step. If you later add custom extraction, test its currency output against the document and retain the same missing-value route. A model returning a value does not make ambiguity disappear.

Example 4: the purchase order is mistaken for the invoice

Input: a cramped invoice header contains Invoice 000744 and Purchase order PO-918. Extraction places PO-918 in the invoice field and gives that field a confidence score of 0.48.

Setup: Display Invoice ID and Purchase order separately beside the source link. Add a review reason for an unexpected identifier pattern, and show available confidence values to the reviewer. Do not replace the invoice number with whichever identifier looks more complete.

Before review:
  invoice_id = "PO-918"
  purchase_order = "PO-918"
  invoice_id_confidence = 0.48
  reason = "check_invoice_identifier"

After checking the printed header:
  invoice_id = "000744"
  purchase_order = "PO-918"
  correction_reason = "Purchase order copied into invoice field"

Expected output: the original extracted value remains in history, while the corrected invoice number drives later duplicate checks. The reviewer signs off on the correction, not on the confidence score.

Failure and recovery: a high score can still accompany the wrong business field. Check identifiers even when their score looks reassuring. If you add a low-confidence threshold, choose it from your own labeled sample and inspect errors above it too. AI Builder provides field confidence, but no universal threshold proves an invoice is safe. See the documented invoice outputs.

Example 5: the same invoice arrives again

Input: invoice 000742 from S-17 arrives again as scan-final.pdf. Its total is 648.00 USD, matching D-01. A different supplier, S-19, also sends an invoice numbered 000742.

Setup: Give each arrival a source ID, then look for existing records using the confirmed supplier and invoice number. Compare currency, totals and source documents before classifying a duplicate. Filename and email subject are not invoice identities.

D-01: S-17 | 000742 | USD | 648.00
D-05: S-17 | 000742 | USD | 648.00 -> possible duplicate of D-01
D-06: S-19 | 000742 | USD | 648.00 -> different supplier
D-07: S-17 | 000742 | USD | 658.00 -> conflicting revision

Expected output: D-05 links to D-01 for comparison. D-06 is reviewed independently. D-07 goes to a reviewer who decides whether it is a corrected invoice, an extraction error or something else. None of the source documents is silently discarded.

Failure and recovery: a search followed by Create item is not a complete concurrency safeguard. Two runs can both find nothing. During the pilot, process this comparison through one review queue. Before unattended intake, add a storage-enforced unique intake key or another tested method that prevents competing writes.

Keep arrival identity separate from invoice matching. A replay of the same source should reuse its processing record. A genuinely new file with the same invoice number should create a review event, not overwrite the earlier decision.

Example 6: one PDF contains two invoices

Input: a three-page PDF contains invoice A on page 1 and invoice B across pages 2 and 3.

Setup: Have the reviewer identify the page ranges. Process page 1 separately from pages 2–3. AI Builder's Pages parameter expects one invoice within the selected range; a mixed range can return partial data. Microsoft explains page-range processing.

Source: D-08, saved file version 1
Review record A: pages "1", invoice A
Review record B: pages "2-3", invoice B
Expected: two review records, each linked to its page range
Do not treat pages "1-3" as one invoice.

Expected output: each record has its own invoice number, totals and review decision. The reviewer confirms that the last page of invoice B was included before checking its total.

Failure and recovery: if extraction times out, record the failed action and run ID against the same source. Retry after checking the cause. Do not create another reviewed invoice every time the file is retried.

Unreadable scans need a better source, not endless retries. Check the supported file types and size before running extraction: the model accepts PDF, JPEG and PNG within its documented limits. Review the current file requirements.

Test the queue before connecting an inbox

Run the six cases through a private pilot. Check the saved values, original file, reviewer access and final state. Also reject one approval, leave one unanswered and change a document after requesting approval. The earlier decision must not apply to changed content.

Put extraction and mapping inside a Scope. Configure a failure path with Run after for failed or timed-out work. That path should update the intake record to Extraction failed and identify the step to inspect. If the review store itself is unavailable, keep the failed run visible for the owner to recover. Microsoft documents scopes and Run after settings.

Track how many documents arrive, how many need corrections, which fields cause them and how long items wait for review. Count approved extraction separately from failed, rejected and waiting work. These numbers tell you whether adding more suppliers will help or simply grow the queue.

Only then connect automatic intake. Decide who monitors it, who handles missing fields and how to stop it. If you want help setting up that first queue, an automation review can start with your document types, existing tools and the person who owns the review.

Sources

• Use invoice processing in Power Automate
• Invoice processing model: fields and requirements
• SharePoint connector reference
• Create and test an approval workflow
• Power Automate error handling
• AI Builder licensing and capacity