Procore keeps purchase orders in the project-level Commitments tool, with the line items on a Schedule of Values. Both the SOV CSV import and the purchase_order_contracts REST API want structured rows. Neither reads a PDF. PurchaseOrders reads the purchase order PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so whatever feeds Procore is typed by a machine instead of a person. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Procore is clear about what a purchase order is. In its own words, a PO is a documented financial commitment that details the types, quantities, and agreed-upon prices for products or services. Creating one is quick. Creating three hundred from documents that arrived as PDFs is a different job, and it is the job Procore deliberately leaves to you.
This surprises people. Procore has downloadable import templates for direct costs, budgets, the directory, locations, punch list items, and submittals. Commitments have exactly one entry on that list, and it covers SOV line items only. The Procore Imports desktop application handles cost codes, contacts, locations, punch items, and submittals, and does not handle commitments at all.
The Schedule of Values CSV import adds or replaces line items inside a commitment that already exists. So a hundred purchase orders means a hundred commitments created by hand first, each one then filled from its own file. The import saves the line entry, not the order entry.
Creating purchase orders at volume means POST to purchase_order_contracts, or the sync endpoint for batches. Either way your integration has to supply vendor, number, dates, terms, and every line with its cost code and amount. If the source is an emailed PDF, something upstream has to produce those values.
By default the commitment has to be in Draft status to import SOV line items. The Enable Always Editable Schedule of Values setting relaxes that, but even then you cannot replace line items that have already been invoiced. Discovering this halfway through a migration is a bad afternoon.
Procore is explicit that you must not add or move data columns, because the order matches its database. Rows missing a cost code name, cost code number, line item type, or an amount are skipped. A blank amount cell is rejected outright, so you enter 0.00 instead. Typing errors produce a shorter file, not an error message you can act on.
The CSV does not accept budget codes. You supply the cost code, the cost type, and optionally the sub job segment, and Procore assembles the budget code from those. Anyone building a file from a supplier PO has to map to that structure rather than to what the document says.
PurchaseOrders is the capture step in front of Procore. It is not a Procore integration and it does not run inside Procore. You give it a purchase order document. It gives back clean, field-level data that you map to the SOV CSV template Procore generates for you, or hand to the integration that calls the commitments API.
A digital PDF from a supplier system, a scan of a mailed order, or a phone photo taken in a job trailer. All go through the same extraction, with no per-supplier template to build first.
PO number, vendor, bill-to and ship-to, order and delivery dates, payment terms, ship via, and the line grid: description, quantity, unit of measure, unit price, and extended amount, captured across page breaks.
Output is one row per line item with consistent headers, which is what the Schedule of Values import expects once you have added your cost code, cost type, and line item type columns. Map once, and every later batch drops into the same mapping.
Pull the same extraction as JSON and feed whatever calls purchase_order_contracts and its line_items collection. Clean fields in, no document parsing on your side, and no PDF handling in your integration code.
Upload a stack of orders at once rather than one at a time. That is what turns a migration onto Procore from a staffing problem into a same-day job.
Captured fields are shown on screen so you can correct an odd value before you export. Catching it here is cheaper than finding out a row was silently skipped during the SOV import.
All three end at the same place, a commitment with a populated Schedule of Values. They differ in what happens before it.
| What matters | Manual keying into Commitments | Template OCR tools | PurchaseOrders AI |
|---|---|---|---|
| Setup per supplier layout | None, but slow forever | Build a template each | None, any layout |
| Mixed PDF, scan, job-site photo | Handled by a person | Often breaks | Handled automatically |
| Line-item capture for the SOV | Error-prone by hand | Varies by template | Full line-item tables |
| Time per purchase order | 5 to 10 minutes | 1 to 3 minutes | Under 10 seconds |
| Output shape | Typed straight into the screen | Needs cleanup | Row per line, ready to map |
| Rows silently skipped on import | Typos drive most of them | Some | Fewer, data is reviewed first |
| Cost per PO at volume | High manual labor | Per-page plus setup | Under $2 |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you map to Procore's Schedule of Values columns or hand to your own integration. It is not a Procore integration, does not install in Procore, does not call the Procore API on your behalf, and does not create, approve, receive, or match commitments. Procore is a trademark of Procore Technologies, Inc.; this page is not affiliated with or endorsed by Procore. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside Procore.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the orders mailbox.
Tip: Mixed suppliers and file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line-item table in seconds.
Tip: Check the captured values on screen before you export, not after the SOV import silently skips a row.
Download Excel or CSV, add your cost code, cost type, and line item type columns, and paste into the SOV template Procore generates for the commitment, or pull JSON via the API and let your own integration post to purchase_order_contracts.
Yes. Purchase orders are one of the two commitment types in the project-level Commitments tool, alongside subcontracts. Procore defines a purchase order as a documented financial commitment detailing the types, quantities, and agreed-upon prices for products or services. You create one from the Contracts tab and give it a Schedule of Values for the line items.
Go to the project's Commitments tool, open the Contracts tab, click Create, and choose Purchase Order. Fill in contract number, contract company, and title, then the general information such as status, payment terms, ship to, and ship via. Add the line items on the Schedule of Values. The status has to reach Approved or Complete before you can raise change orders or invoices against it.
Only partly, and this is the detail that catches migrations out. Procore supports importing Schedule of Values line items into a commitment from CSV, but there is no native CSV or Excel import that creates the purchase order records themselves in bulk. Commitments are not in the Procore Imports desktop application either. Bulk creation goes through the REST API.
Purchase orders are purchase_order_contracts. List and create at /rest/v1.0/purchase_order_contracts, read, update, and delete at /rest/v1.0/purchase_order_contracts/{id}, and line items at /rest/v1.0/purchase_order_contracts/{id}/line_items. The PATCH sync variants handle batches. GET /rest/v1.0/commitments is read-only and returns purchase orders and subcontracts together, so it cannot be used to create either.
Procore documents that the sync endpoints accept attributes for a maximum of 1000 resources per call. Sync always returns HTTP 200 and reports per-record outcomes in an entities array and an errors array, so you have to read the response body rather than trust the status code. Rate limits apply on an hourly and a ten-second window, reported through the X-Rate-Limit headers.
Both are commitments, and in the API a subcontract is a work order contract. A purchase order carries assignee, bill to and ship to addresses, ship via, payment terms, and delivery date, and moves through Draft, Processing, Submitted, Partially Received, Received, Approved, and Closed. A subcontract carries contract dates, inclusions, and exclusions, and runs Draft, Out For Bid, Out For Signature, Approved, Complete, Terminated, and Void. Buy materials on a PO, buy labor and scope on a subcontract.
Rows are skipped when the cost code name, cost code number, line item type, or the amount is missing. A blank amount cell is rejected, so enter 0.00 rather than leaving it empty. Procore also requires that you do not add or move columns in its template, because the column order matches its database. And budget codes cannot be imported at all: supply cost code, cost type, and optional sub job instead.
By default, yes. With the Enable Always Editable Schedule of Values setting turned off, which is the default, the commitment must be in Draft to import line items. Turning that setting on allows the import at any status, but you still cannot replace line items that have already been invoiced.
Procore's ERP Integrations cover Viewpoint Spectrum, Vista, QuickBooks Desktop and Online, Sage 300 CRE, Sage 100 Contractor, Sage Intacct, Yardi Voyager, NetSuite, Acumatica, MRI Platform X, CMiC, Workday, and Xero. Procore states that each connector has its own feature set, so confirm commitment export on yours specifically. Foundation and Dynamics 365 Business Central are not on Procore's own supported list.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in Procore, does not call purchase_order_contracts, does not write to Procore, and does not create, approve, receive, or match commitments. You keep using Procore's own SOV import or your own API integration; we just remove the typing in front of it.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters on construction projects because material orders and supplier confirmations often reach the office as a photo taken in a job trailer, which template-based OCR tools tend to miss or mangle.
The construction use case end to end.
PO data for Sage Intacct.
PO data shaped for Acumatica.
The general ERP load path.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Clear a migration backlog in batches.
See the output shape in Excel.
