Power Automate can move a purchase order around, but it cannot read one out of the box. AI Builder ships prebuilt models for invoices and receipts, not for purchase orders, so most flows end at a PDF sitting in SharePoint with nobody able to get the line items out of it. PurchaseOrders reads the PDF, the scan, or the photo and returns the header fields and the full line grid as Excel, CSV, or JSON your flow can pick up. Upload a real purchase order below and see what comes back.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Power Automate is genuinely good at moving work between systems. Reading a supplier document is the one step it was never designed for, and every available route has a catch that only shows up after you have built the flow.
This is the wall most people hit. Microsoft publishes prebuilt document models for invoices and receipts. There is no prebuilt purchase order model. The prebuilt invoice model does return a field called PurchaseOrder, but that is only the PO reference number printed on an invoice, not an extraction of a purchase order document. Reading an actual supplier PO in AI Builder means training a custom model first.
Microsoft says you need five documents to get started with a custom document processing model, and you train and publish it before a flow can call it. That is fine for one supplier with one stable layout. With forty suppliers sending forty different order formats, you are maintaining a model library rather than running a flow.
Power Automate Desktop has actions to extract text and tables from a PDF, and they work on digital PDFs where the text layer already exists. Point them at a scan or a phone photo of a mailed order and there is no text to extract. Half of the purchase orders in a typical receiving inbox fall into that half.
Pulling a table out of a PDF assumes the table looks the same every time. Purchase order line grids do not. They wrap across page breaks, repeat headers, carry subtotal rows, and put the unit of measure in a different column depending on who sent it. A rule that works on one supplier quietly returns shifted columns on the next.
AI Builder is a premium capability that consumes credits per page, and the HTTP action you would use to call an outside service is a premium connector too. Whichever route you pick, PDF extraction in Power Automate is not something the seeded license covers, so it is worth knowing the cost shape before you build.
Document processing calls are capped at 360 per environment per 60 seconds across the prebuilt models. A steady trickle of orders never notices. A migration or a month-end catch-up of several thousand documents does, and the flow starts failing in a way that looks like a bug rather than a limit.
PurchaseOrders is the reading step your flow is missing. It is not a certified connector and nothing installs in your tenant. You post a document to it and get back clean field-level data, then Power Automate does what it is good at with the result.
Digital PDFs from a supplier portal, scans of mailed orders, and photos taken at a receiving desk all go through the same extraction. There is no separate OCR step to wire in and no per-supplier template to train first.
PO number, vendor, order date, ship-to, requested by, terms, and the line table: item code, description, quantity, unit of measure, unit price, and extended amount, captured across page breaks.
Point an HTTP action at the API and the flow receives structured JSON it can parse with Parse JSON and write straight into a SharePoint list, a Dataverse table, or an Excel file.
Export the batch to Excel or CSV, drop it in SharePoint or OneDrive, and let a simple flow pick it up. Plenty of teams never need the API at all.
Upload a stack of orders at once rather than metering them through a per-environment call limit during a cutover or a backlog.
Captured fields are shown on screen so you can fix an odd quantity or price before anything is exported. Correcting a value here takes seconds. Correcting it after a flow has written it into six places does not.
The honest answer to the question everyone searches is: it depends entirely on which PDF and which route. Power Automate has three different ways to get data out of a PDF, and they fail in three different places. AI Builder document processing understands layout and reads scans, but there is no prebuilt purchase order model, so you have to train a custom one. Power Automate Desktop has direct actions to extract text and tables from a PDF, and they are quick, but they only work where a text layer already exists, which rules out scans and photos. An outside extraction API called from an HTTP action handles both cases and needs no training, but the HTTP connector is premium. Nothing in the seeded Power Automate license reads a purchase order PDF properly, and it saves a lot of time to know that before you start building.
Microsoft's prebuilt document models cover invoices and receipts. There is no prebuilt purchase order model. What trips people up is that the prebuilt invoice model returns a field named PurchaseOrder, described in Microsoft's own documentation as a purchase order reference number. That is the PO number quoted on an invoice, one string, and it tells you nothing about the purchase order itself. If you feed a supplier purchase order into the invoice model hoping the naming implies support, you get a partial and unreliable read, because the model was trained on a different document. It is a naming collision, not a feature.
The supported route inside AI Builder is a custom document processing model. Microsoft's guidance is that you need five documents to get started, and the workflow is train, then publish, then call from a flow. For a single high-volume supplier whose layout never changes, that is a sensible investment and it works well. The problem is the shape of purchase order traffic in most US businesses: a long tail of suppliers, each sending a slightly different form, several of them changing their template once a year without telling anyone. Every new layout is another collection to train, another publish, and another thing to notice when it starts drifting. Teams that go down this path usually cover their top few suppliers and keep typing the rest.
Microsoft publishes hard limits on the document processing models, and they are easy to design past by accident. Files must be JPEG, PNG, or PDF. File size must not exceed 20 MB. Image dimensions must sit between 50 x 50 and 10,000 x 10,000 pixels, and PDF pages must be at most 17 x 17 inches, which is Legal or A3 and smaller. For PDF documents, only the first 2,000 pages are processed. The one that bites in production is the throughput cap: calls across the document processing models are limited to 360 per environment per 60 seconds. A steady inbox never approaches it. A migration batch or a quarter-end catch-up does, and the failure looks like an intermittent flow error rather than a documented limit.
The pattern that avoids the training problem entirely is to keep Power Automate doing what it is good at, which is orchestration, and hand the reading to a service built for it. A typical flow looks like this: a trigger fires when a file lands in a SharePoint document library or an attachment arrives in a shared mailbox, an HTTP action posts the file to the extraction API, a Parse JSON action gives you typed access to the response, and an Apply to each loop writes one row per line item into a SharePoint list, a Dataverse table, or an Excel table. No model to train, no per-supplier collection, and the same flow handles a scanned order and a digital one identically. The HTTP action is a premium connector, so check your licensing, but you were going to be on a premium plan for AI Builder anyway.
This is the most common destination people search for, and the detail that matters is grain. A purchase order is not one record. It is a header and a set of lines, so a single SharePoint list holding one item per order throws away the line detail that made the exercise worth doing. Two lists work far better: an orders list keyed on the PO number, and a lines list with a lookup back to it, one item per line. Whichever route you use for the reading, build the extraction output at line grain with the PO number repeated on every row, and the Apply to each that populates the lines list becomes trivial. Getting this wrong early is the reason a lot of these flows get rebuilt three months in.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into structured output. It is not a certified Power Platform connector, there is no AppSource app to install, and it does not appear in the Power Automate connector list. You call it from a standard HTTP action, or you export Excel or CSV and let a file trigger pick it up. It does not create, approve, route, or match purchase orders, and it does not write to your ERP. Power Automate keeps the orchestration. We remove the part where a person reads a PDF and types it into a form.
Operations teams already running Microsoft 365 use it when a flow stalls at a PDF nobody can parse. Developers building Power Platform solutions use the purchase order API so their HTTP action gets JSON instead of a base64 blob they have to solve. Finance teams who would rather not build a flow at all export to the purchase order PDF to Excel converter and work in the spreadsheet. Dynamics 365 shops loading the result into an ERP go on to purchase order to Business Central or purchase order to D365 Finance and Operations. Long material orders where every row has to survive are covered in purchase order line item extraction, and a migration backlog clears through bulk purchase order upload.
Each route works somewhere and fails somewhere. This is the comparison worth making before you build, not after.
| Route | Reads which documents | Handles scans | Setup per supplier | Where it falls down |
|---|---|---|---|---|
| AI Builder prebuilt models | Invoices and receipts only | Yes, reads scans | None | No purchase order model exists |
| AI Builder custom model | Any layout you train | Yes, reads scans | Five documents per layout, then publish | New supplier layout means new training |
| Power Automate Desktop PDF actions | Digital PDFs with a text layer | No | None | Returns nothing useful from a scan or photo |
| Extract tables from PDF action | Simple, repeating tables | No | None | Line grids that wrap or nest shift columns |
| PurchaseOrders via HTTP action | Purchase orders in any layout | Yes, reads scans and photos | None | Not a certified connector, you call the API |
AI Builder model availability, file limits and throughput caps reflect Microsoft's published documentation for AI Builder document processing and can change between releases, so confirm the current limits for your tenant. PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response. It is not a certified Power Platform connector, does not install in your tenant, and does not create, approve, route, or match purchase orders.
No AI Builder model to train, nothing to install in your tenant.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the purchasing mailbox.
Tip: Mixed suppliers and mixed file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line grid in seconds, one row per line item.
Tip: No model to train first, and no five sample documents per supplier.
Take JSON through the API from an HTTP action, or export Excel or CSV to SharePoint and let a file-created trigger do the rest.
Yes, but not with the standard actions alone. You need AI Builder document processing, which reads scans and understands layout, or the Power Automate Desktop PDF actions, which only work when the PDF already has a text layer, or an outside extraction API called from an HTTP action. All three are premium capabilities in some form.
No. Microsoft publishes prebuilt document models for invoices and receipts, and there is no prebuilt purchase order model. The prebuilt invoice model returns a field called PurchaseOrder, but that is the PO reference number quoted on an invoice, not an extraction of a purchase order document.
Get the data into a structured object first, then write it. Either train a custom AI Builder model, or post the file to an extraction API from an HTTP action and use Parse JSON on the response. Then loop the line items with Apply to each into an Excel table, keeping one row per line item rather than one row per order.
Trigger the flow when the file is created in the library, extract the fields, then create items in the list. Use two lists rather than one: an orders list keyed on the PO number and a lines list with a lookup back to it. A single list forces you to drop the line detail, which is usually the data you wanted.
Power Automate Desktop has an action to extract tables from a PDF, and it works on clean digital PDFs with simple repeating tables. Purchase order line grids often defeat it, because they wrap across pages, repeat headers, and carry subtotal rows. AI Builder or a purpose-built extraction service handles those cases more reliably.
In practice yes. AI Builder is a premium capability that consumes credits per page, and the HTTP action used to call an outside service is a premium connector. The seeded Power Automate license that comes with Microsoft 365 does not cover reading a purchase order PDF by either route.
Microsoft's guidance is that you need five documents to get started, and you train and then publish the model before a flow can call it. Note that this is per layout, so a supplier base sending many different purchase order formats turns into a set of models to build and maintain.
No, and we would rather say so than imply otherwise. There is no certified connector and no AppSource app. You call the REST API from a standard HTTP action, or you export Excel or CSV and let a file-created trigger pick it up. The orchestration stays entirely in your flow.
Get the same data as JSON over REST.
Load the result into Dynamics 365 Business Central.
The D365 Finance and Operations load path.
See the output shape in one upload.
Capture every detail line.
Clear a backlog in batches.
The general ERP load pattern.