There is no Workday web service that mass-creates purchase orders. Workday builds a purchase order itself when an approved requisition is sourced, so a Workday EIB purchase order import is in practice a Submit Requisition inbound EIB carrying one spreadsheet row per line. The rows still have to come from somewhere, and the supplier order usually arrives as a PDF. PurchaseOrders reads that document and returns the order number, supplier, dates, item codes, quantities and unit prices as clean Excel or CSV you can paste into the EIB template. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Teams arrive looking for an inbound EIB called something like Import Purchase Order, do not find one, and assume they lack a security role. The operation genuinely does not exist, because of how Workday models the document.
A purchase order in Workday is the output of sourcing an approved requisition. You can configure requisition sourcing rules so purchase orders are created automatically, or run the Source Requisitions task by hand. Either way the PO is generated inside Workday, which is why there is no bulk create operation to point an EIB at.
The realistic bulk route is a Submit Requisition inbound EIB. That is the template universities and large finance teams actually use, typically once a requisition runs past roughly 20 lines and typing it becomes untenable. It loads requisitions, and Workday turns them into purchase orders downstream.
The EIB workbook carries hidden metadata that maps each column to a field on the web service request. Reformat it, save it as .xls, or paste a block of cells in carelessly and the load fails in ways the error message does not explain. The rule everywhere is the same: populate the template, never restyle it.
None of the above is the slow part. The slow part is that the order came in as a PDF attachment or a scan, and somebody has to turn its header and its line table into spreadsheet rows before any EIB has anything to carry.
PurchaseOrders is a document data capture layer. It reads a purchase order or supplier order confirmation and returns structured fields you can drop into an EIB spreadsheet template. It does not connect to Workday, does not hold a tenant credential, and does not launch integrations. The load stays yours to run under your own security.
The order number, supplier, order date, requested delivery date, currency and any memo or reference text come back as named fields, which covers the header columns before you get to the line block.
Each line returns with item or part number, description, quantity, unit of measure, unit price and extended amount. An EIB spreadsheet wants one row per line, and a 60-line order becomes 60 rows in one pass instead of an afternoon of retyping.
The supplier prints their own part number, not your Workday item identifier. Keeping both values side by side is what lets you map to the catalog item before the load, and mismatched item references are the most common reason an otherwise clean requisition EIB errors.
Excel matches the EIB workbook you are filling in. JSON and the API suit teams pushing requisitions through Workday web services on a schedule rather than through a spreadsheet.
Two situations bring people to a Workday EIB for procurement data. The first is a one-time event: a migration, a backlog of open supplier orders, or a department that has been running on spreadsheets and needs its commitments represented in Workday properly. A Submit Requisition EIB handles that in a single launch. The second is ongoing intake, where supplier order confirmations and customer purchase orders land in a shared mailbox every morning and someone opens each one and types it in. That is a different shape of problem, and a spreadsheet upload is a slow answer to it. A scheduled feed through a purchase order API fits it far better, because the extraction runs as documents arrive rather than in a weekly batch.
The load mechanics differ more between systems than the demos suggest, and it is worth knowing what you are comparing. NetSuite uses the CSV Import Assistant with an External ID repeated on every row, Oracle Fusion uses FBDI templates loaded through a scheduled process, Business Central uses configuration packages, Acumatica uses import scenarios, and SAP Business One uses the Data Transfer Workbench. Workday is the odd one out, because it is the only system in that list where the purchase order is generated by a business process rather than loaded. What every one of them shares is that none of them reads a PDF, and all of them want columns.
If the columns are all you need, the purchase order PDF to Excel converter returns them directly with no Workday step involved, and line item extraction covers orders with long item tables where the line block is the whole job. Teams clearing a month-end backlog in one pass usually start with bulk purchase order processing, and the general shape of the problem across every ERP is set out in how to import purchase orders to an ERP.
Only one of these is a bulk route, and it does not load purchase orders directly. Pick the row that matches what you are actually trying to do.
| Route | What it loads | When it fits |
|---|---|---|
| Submit Requisition inbound EIB | Requisitions, one spreadsheet row per line | Bulk loads and long orders. Workday sources the requisition into a PO afterwards |
| Requisition sourcing rules | Nothing. It converts what is already there | Configure once so approved requisitions become purchase orders automatically |
| Source Requisitions task | Nothing. Manual conversion | When a buyer wants to consolidate or split requisitions before the PO is issued |
| XML auto purchase orders | Purchase orders, as XML | Machine to machine feeds. The Purchase Order XML Issue business process issues them automatically |
| Manual entry | One requisition at a time | Low volume, or anything with unusual approvals attached |
The extraction removes the typing. The EIB launch stays inside Workday, under your roles and your audit trail.
Drag in the PDF, scan or photo exactly as it arrived. There is no template to configure first and no supplier layout to teach the system in advance.
Tip: Multi-page orders and several suppliers in one batch are fine.
Confirm the order number, supplier, dates and every line before you export. Correcting a quantity here takes seconds. Finding it after a partial EIB load means unpicking requisitions that are already in an approval chain.
Tip: Watch units of measure. A case versus each mismatch creates a valid requisition for the wrong quantity.
Download Excel, then paste values into the generated Submit Requisition template without touching its formatting. Launch the EIB with Validate Only first, read the results, then run it for real.
Tip: Test the first launch on two or three requisitions before committing the whole batch.
Not directly. Workday does not publish a web service that bulk-creates purchase orders, because a purchase order is produced when an approved requisition is sourced. The practical bulk route is a Submit Requisition inbound EIB, after which requisition sourcing rules or the Source Requisitions task turn those requisitions into purchase orders.
The Enterprise Interface Builder is Workday's no-code integration tool for moving data in and out of a tenant without writing code. An inbound EIB reads a spreadsheet or file and calls a Workday web service operation to load the records. An outbound EIB extracts Workday data and delivers it to an external endpoint.
Run the Create EIB task, give the integration a durable name, and set it as inbound. On the Get Data tab, choose the web service operation you want to call, such as Submit Requisition. Save it, then use the Template Model related action on the integration system and choose Generate Spreadsheet Template to produce the workbook you fill in.
It is the spreadsheet workbook Workday generates for one specific web service operation. Its columns and hidden metadata map each cell to a field on the request, which is why the structure must not be altered. Populate the cells, do not restyle the sheet, and do not save it down to the older .xls format.
The constraint is file size rather than a published row count. A spreadsheet attached at launch time is limited to 30 MB. A spreadsheet delivered from a file server such as SFTP can be up to 300 MB. Very large loads are usually split into several launches anyway, so failures are easier to isolate and rerun.
Direction. An inbound EIB brings data into Workday by calling a web service operation with rows from a spreadsheet or file. An outbound EIB takes data out, usually from a custom report, transforms it and delivers it to an external system over SFTP, email or a web service.
No, and expecting it to is a common and expensive misunderstanding. A requisition submitted through an EIB enters the same business process as one typed by hand, so it routes for approval exactly the same way. The EIB removes the keying, not the controls.
Through sourcing. You can configure requisition sourcing rules so approved requisitions create purchase orders automatically, or use the Source Requisitions task to do it manually and consolidate lines across requisitions. The Purchase Order Event business process then controls approvals and document routing, and the Purchase Order Issue Event initiates issuing.
The Buyer, Implementer and Supplier Contract Specialist roles carry the security to create and issue purchase orders. Launching an inbound EIB is a separate permission again, and a Submit Requisition EIB only works for the cost centers or worktags the launching user already has access to.
Because that is the designed behavior. When you source additional requisition lines onto a purchase order that is already approved, the Purchase Order Event business process restarts. Nothing is broken. Plan consolidations before the approval rather than after, or expect the order to go around again.
No. PurchaseOrders reads purchase order documents and returns the data as Excel, CSV, JSON or API output. It does not hold Workday credentials, does not launch integrations and does not write to your tenant. You paste the values into the EIB template and run the load yourself, which keeps your roles, permissions and audit trail intact.
The NetSuite CSV Import Assistant route.
Oracle Fusion FBDI templates for PO loads.
The Business Central configuration package route.
Acumatica import scenarios for PO data.
IIF files and the QuickBooks Online gap.
Turn a PO into an Excel sheet directly.
Capture the full line table.
The general ERP load pattern.
Same fields as JSON for a scheduled feed.