The purchase order FBDI template is POPurchaseOrderImportTemplate.xlsm, the Oracle-supplied workbook with four interface tabs that feeds the Import Orders scheduled process in Oracle Fusion Cloud Procurement. It wants clean rows. It cannot read a purchase order PDF. PurchaseOrders reads the PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the data you paste into the template was 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...
Filling the workbook, zipping it, and running the two scheduled processes is a well-documented afternoon of work. Getting the source data into a spreadsheet in the first place is what actually consumes the project, because most purchase orders arrive as documents rather than as extracts.
Every FBDI tab maps to an interface table column for column. If your source is a supplier PDF, a scanned order from a legacy filing cabinet, or an emailed attachment, somebody reads one window and types into another before the workbook is worth anything.
A single purchase order is not one row. The header goes to PO_HEADERS_INTERFACE, the line to PO_LINES_INTERFACE, the schedule to PO_LINE_LOCATIONS_INTERFACE, and the accounting split to PO_DISTRIBUTIONS_INTERFACE. Typing a fifty-line order by hand means typing it four times over.
Interface Header Key ties lines to their header, Interface Line Key ties schedules to their line, and Interface Line Location Key ties distributions to their schedule. Get one of those wrong by hand and the rows load but the order comes out wrong, or the child rows are orphaned.
For several Fusion objects you can skip FBDI and use ADF Desktop Integration. Purchase orders are not one of them, so FBDI is the supported spreadsheet route and the data has to be genuinely ready before you start.
Validation failures land in PO_INTERFACE_ERRORS and in the process log after the batch has run. Records in that table are not purged automatically, so a sloppy source file turns into a cleanup queue rather than a clean import.
A go-live from E-Business Suite, an acquired division on a different system, or a quarter of open orders that never made it across all land together. The FBDI side of that load runs in minutes. The keying in front of it runs for weeks.
PurchaseOrders is the capture step in front of the template. It is not an Oracle connector and it does not run inside Fusion. You give it a purchase order document. It gives you back clean, field-level data you paste into the FBDI tabs or map with a script, then you load it with the processes Oracle already gives you.
A digital PDF from a supplier system, a scan of a mailed order, or a phone photo of a paper PO. All go through the same extraction, with no per-supplier template to build first and nothing to configure per layout.
PO number, supplier, buyer, ship-to and bill-to, order date, need-by date, payment terms, currency, and the line grid: item, description, quantity, unit of measure, unit price, and line amount, captured across page breaks.
Output is a flat table with consistent headers, which is the shape you want before you split it across the header, line, schedule, and distribution tabs. Map your columns once and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and build the four CSVs programmatically, or feed whatever already talks to Fusion, whether that is OIC, a Python job, or a script that assembles and uploads the ZIP.
Upload a stack of orders at once rather than one at a time. That is what turns an EBS cutover or a quarter of emailed POs into a same-day job instead of a staffing problem.
Captured fields are shown on screen so you can correct an odd value before you export. Fixing a quantity here costs seconds; fixing it after the order is approved and received costs a great deal more.
The workbook Oracle publishes for this object is POPurchaseOrderImportTemplate.xlsm, and it carries four interface tabs that match four interface tables one to one: PO_HEADERS_INTERFACE, PO_LINES_INTERFACE, PO_LINE_LOCATIONS_INTERFACE, and PO_DISTRIBUTIONS_INTERFACE. A fifth tab, Instructions and CSV Generation, is the one that builds the ZIP file you upload. The Action column on the header decides whether the row creates a document (Original) or changes an existing one (Update), and the same batch can carry standard purchase orders alongside the other purchasing documents the interface supports.
Nothing in the template uses the real purchase order number to join the tabs. It uses your own temporary keys. Interface Header Key must be unique per document and is repeated on every line that belongs to it. Interface Line Key does the same job between a line and its schedules, and Interface Line Location Key between a schedule and its distributions. A unique Batch ID ties the whole load together and is the value you hand to the Import Orders job so it picks up your rows and nobody else's. Get the chain right and the load is boring. Get it wrong and the rows import into shapes nobody intended.
Loading is always two steps. First Load Interface File for Import takes the ZIP you uploaded through Navigator, Tools, File Import and Export into the prc/purchaseOrder/import account, and writes it into the interface tables. Then Import Orders validates those staged rows and creates the documents. Import Orders asks for a Procurement BU, a Default Buyer, a Default Requisitioning BU, and an Approval Action of Do Not Approve, Submit for Approval, or Bypass Approval, and optionally an Import Source and Batch ID to narrow which staged rows it takes. Oracle documents a ceiling of 10,000 distributions per document and runs one instance of the job at a time, which matters when you are planning a large cutover.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not an Oracle connector, it does not install in Fusion, it does not generate the FBDI ZIP or run either scheduled process for you, it does not write to the interface tables, and it does not create, approve, receive, or match purchase orders. Those all stay in Oracle. We remove the typing that happens before the template is filled, and nothing else.
Teams migrating from E-Business Suite use it to build the source table behind the four tabs. Buyers whose suppliers send order confirmations and orders as PDFs use it so those documents reach Fusion the same week they arrive. Developers assembling the CSVs in code use the purchase order API so their job receives JSON rather than an attachment. The wider Oracle load path, including the E-Business Suite open interface, is covered on Oracle purchase order import, and the tables the data eventually lands in are documented in PO_HEADERS_ALL and the Oracle purchase order tables. The purchase order PDF to Excel converter is the quickest way to see the output shape, long orders are covered in purchase order line item extraction, and a backlog clears through bulk purchase order upload. The general pattern across systems is in how to import purchase orders to an ERP.
Each tab in POPurchaseOrderImportTemplate.xlsm maps to one interface table. This is the grain your source data has to reach before the template is any use.
| Template tab | Interface table | One row per | Key it carries |
|---|---|---|---|
| Header Interface | PO_HEADERS_INTERFACE | Purchase order | Interface Header Key |
| Line Interface | PO_LINES_INTERFACE | Order line | Interface Line Key, plus its header key |
| Line Locations Interface | PO_LINE_LOCATIONS_INTERFACE | Schedule or shipment | Interface Line Location Key, plus its line key |
| Distributions Interface | PO_DISTRIBUTIONS_INTERFACE | Accounting split | Interface Distribution Key, plus its line location key |
| Instructions and CSV Generation | Not a table | Whole batch | Builds the ZIP you upload |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you shape for these tabs. It is not an Oracle connector, does not install in Oracle Fusion, does not generate the FBDI ZIP or run Load Interface File for Import or Import Orders for you, does not write to the interface tables, and does not create, approve, receive, or match purchase orders. Oracle, Oracle Fusion, and E-Business Suite are trademarks of Oracle Corporation; this page is not affiliated with or endorsed by Oracle. Interface table and process names reflect Oracle Fusion Cloud Procurement documentation and can change between releases, so check the FBDI page for your own release.
No templates to build, no changes inside Oracle.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the purchasing mailbox or a migration folder.
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, one row per line.
Tip: Check the captured values on screen before you export, not after Import Orders writes them to PO_INTERFACE_ERRORS.
Download Excel or CSV, split it across the header, line, line location, and distribution tabs with your own keys, generate the ZIP from the Instructions tab, upload it, then run Load Interface File for Import followed by Import Orders.
It is POPurchaseOrderImportTemplate.xlsm, an Oracle-supplied macro-enabled workbook for file-based data import. It holds four interface tabs, one each for PO_HEADERS_INTERFACE, PO_LINES_INTERFACE, PO_LINE_LOCATIONS_INTERFACE, and PO_DISTRIBUTIONS_INTERFACE, plus an Instructions and CSV Generation tab that turns your data into the ZIP file Oracle loads.
From the File-Based Data Import guide for Oracle Fusion Cloud Procurement in Oracle Help Center, on the Purchase Orders Import page for your release. Always take the workbook that matches your release, because columns are added and changed between updates and an older template can fail validation against a newer environment.
Fill the four tabs, generate the ZIP from the Instructions and CSV Generation tab, upload it through Navigator, Tools, File Import and Export to the prc/purchaseOrder/import account, then run Load Interface File for Import to stage the rows and Import Orders to create the documents. Import Orders needs a Procurement BU, a Default Buyer, a Default Requisitioning BU, and an Approval Action.
No. FBDI reads structured rows in CSV files, not documents. A PDF or scanned purchase order has to become rows first. That conversion is what PurchaseOrders does: it reads the document and returns the header fields and line items as a spreadsheet you shape for the template tabs.
It is your own temporary identifier that joins the tabs before Oracle assigns real numbers. It must be unique for each purchase order in the batch, and every line belonging to that order repeats it. Interface Line Key and Interface Line Location Key do the same job further down, tying schedules to lines and distributions to schedules.
Check PO_INTERFACE_ERRORS and the Import Orders log first, because they name the row and the reason. The usual causes are a broken key chain between tabs, a Batch ID that does not match the one entered in the job, a supplier or item that does not exist in the target environment, a missing required column, or a template downloaded from a different release.
Oracle documents a ceiling of 10,000 distributions per document and notes that Import Orders runs a single instance at a time. For a large cutover that means planning the load into sequential batches rather than one enormous file, and keeping an eye on how many distributions your longest orders generate.
No. ADFdi covers a number of Fusion objects but purchase orders are not among them, so FBDI is the supported spreadsheet route for bulk creation and update. Order by order integrations usually use the Purchase Orders REST resource instead.
The Action column on the header row is what controls this: Original creates a new document, and Update is used for changes to an existing one. What a change load is actually allowed to alter has moved between releases, and it is stricter than a create about the document being in a state that accepts a revision. Check the FBDI page for your own release and test the change flow in a lower environment before you rely on it.
The wider Oracle Fusion and EBS load path.
The general ERP load path across systems.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Clear a cutover backlog in batches.
See the output shape in one upload.
CSV output for the template tabs.
