Oracle Fusion Cloud imports purchase orders through the FBDI spreadsheet template and the Import Orders scheduled process, and Oracle E-Business Suite does it through the Purchasing Documents Open Interface. Both want structured rows. Neither reads a PDF. PurchaseOrders reads the PO PDF, scan, or photo and hands back the header fields and the full line-item table as Excel, CSV, or JSON, so the file you load into the interface 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...
Oracle gives you good bulk-load machinery. FBDI, the Import Orders process, the REST endpoints, and PDOI in E-Business Suite all move purchase orders in at volume and validate them properly. The catch is what they take as input: a CSV with the columns in a fixed order. Getting to that CSV is the part nobody automated, because the orders arrive as documents.
The POPurchaseOrderImportTemplate.xlsm workbook generates a ZIP of CSV files from its interface tabs. Somebody has to fill those tabs first. When the source is an emailed PDF from a customer or a scan of a mailed order, that somebody is a person reading one window and typing into another.
A single purchase order does not land in one row. The header goes to PO_HEADERS_INTERFACE, the items to PO_LINES_INTERFACE, the ship-to and delivery detail to PO_LINE_LOCATIONS_INTERFACE, and the accounting split to PO_DISTRIBUTIONS_INTERFACE. Keying one order by hand means keeping four sheets consistent.
Reordering columns or deleting unused ones in the FBDI sheets breaks the load. So does a date in the wrong format or a quantity with a stray character. You find out after the Load Interface File for Import job runs, not while you are typing, and then you go back and fix rows.
In E-Business Suite, PDOI writes rejected records to PO_INTERFACE_ERRORS. In Fusion, you read the process output. Either way the feedback loop between a mistyped line and the error message is long enough that a bad batch can sit for a day before anyone reconciles it.
A migration from a legacy system, a quarter of emailed customer POs, or a newly acquired entity all produce hundreds of orders at once. The Oracle side of that load takes minutes. The data-entry side takes weeks of somebody's time.
Posting to the Fusion purchase order REST resources needs a JSON body with real field values. If your integration layer is fed by a mailbox full of PDFs, the API does not help until something has turned those documents into fields.
PurchaseOrders is the capture step in front of FBDI, PDOI, or the REST API. It is not an Oracle connector and it does not run inside Oracle. You give it a purchase order document. It gives you back clean, field-level data that you map to the interface columns Oracle already expects, then you load it with the tooling you use today.
A digital PDF from a customer ERP, 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, buyer and supplier, bill-to and ship-to, order date, requested delivery date, payment terms, currency, and the line grid: item number, supplier part number, description, quantity, unit of measure, unit price, and line total, captured across page breaks.
Output is one row per line item with consistent headers, which is the shape the interface sheets want. Map your columns once to PO_HEADERS_INTERFACE and PO_LINES_INTERFACE, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already talks to Oracle, whether that is OIC, a custom integration, or a script that posts to the Fusion purchase order endpoints. Clean fields in, no document parsing on your side.
Upload a stack of orders at once rather than one at a time. This is what makes an initial load from a legacy system or a quarter of accumulated emailed POs 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. Catching it here is a great deal cheaper than catching it in PO_INTERFACE_ERRORS after a load.
The route depends on which Oracle you run. In Oracle Fusion Cloud Procurement you fill the FBDI workbook, generate the ZIP of CSVs from its instructions tab, run Load Interface File for Import to populate the interface tables, then run the Import Orders scheduled process with your Procurement BU, Default Buyer, Approval Action, and Default Requisitioning BU. In Oracle E-Business Suite R12 you populate the PDOI interface tables and run the Import Standard Purchase Orders concurrent program, which moves validated records into PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL. In both cases the question is the same: where does the CSV come from? If the answer today is a person reading a PDF, this tool replaces that step.
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 run FBDI or any scheduled process for you, it does not write to Oracle interface tables, and it does not create, approve, or match purchase orders. Those all stay in Oracle. We remove the typing that happens before the load, and nothing else.
Oracle shops running an initial load from a legacy purchasing system use it to build the migration file. Suppliers whose customers send POs as PDFs use it so those orders reach Oracle the same day they arrive. Integration teams wiring a mailbox to OIC use the purchase order API so the middleware gets JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, and row-level accuracy on long orders is covered in purchase order line item extraction. A backlog clears through bulk purchase order upload, the general load path is in how to import purchase orders to an ERP, and teams on other systems can compare purchase order to NetSuite, purchase order to SAP, and Ariba purchase order to Excel.
All three end at the same place, an order sitting in Oracle Purchasing. They differ in what happens before the load.
| What matters | Manual keying into FBDI | Template OCR tools | PurchaseOrders AI |
|---|---|---|---|
| Setup per supplier layout | None, but slow forever | Build a template each | None, any layout |
| Mixed PDF, scan, photo | Handled by a person | Often breaks | Handled automatically |
| Line-item capture | 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 tabs | Needs cleanup | Row per line, ready to map |
| Rejected records to chase | 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 Oracle's interface columns. It is not an Oracle connector, does not run FBDI, PDOI, or any scheduled process, does not write to Oracle interface tables, and does not create, approve, or match purchase orders. Oracle, Oracle Fusion Cloud, NetSuite, and E-Business Suite are trademarks of Oracle Corporation; this page is not affiliated with or endorsed by Oracle. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
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 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 load fails.
Download Excel or CSV, map the columns to the FBDI interface tabs or your PDOI staging table, and run the import, or pull JSON via the API and post it from your own integration.
You load the data with file-based data import, then run the import. Fill the purchase order FBDI workbook, generate the ZIP of CSV files from its instructions tab, run the Load Interface File for Import scheduled process to populate the interface tables, then run Import Orders. PurchaseOrders supplies the field-level data for that CSV by reading your PDF purchase orders.
It is the POPurchaseOrderImportTemplate.xlsm workbook from Oracle's File-Based Data Import documentation for Procurement. It carries one tab per interface table, including PO_HEADERS_INTERFACE, PO_LINES_INTERFACE, PO_LINE_LOCATIONS_INTERFACE, and PO_DISTRIBUTIONS_INTERFACE, plus an instructions tab that generates the ZIP of CSV files you upload.
Import Orders takes purchase order records already loaded into the interface tables and creates the orders in Oracle Fusion Cloud Procurement. It is used for initial loads from a legacy application, ongoing imports from an external system, and adding lines to existing orders. It requires a Procurement BU, a Default Buyer, an Approval Action, and a Default Requisitioning BU.
Through the Purchasing Documents Open Interface, usually shortened to PDOI. You populate the header, line, shipment, and distribution interface tables, then run the Import Standard Purchase Orders concurrent program. Validated records move into PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL, and rejected ones are written to PO_INTERFACE_ERRORS.
Yes. Oracle Fusion Cloud Procurement exposes purchase order REST resources under the fscmRestApi path, and many teams post orders that way rather than batching through FBDI. The API still needs a JSON body of real field values, so if your orders arrive as PDFs you need extraction first. Our API returns that JSON.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in Oracle, does not run FBDI or any scheduled process, does not write to interface tables, and does not create, approve, or match orders. You keep using Oracle's own import tooling; we just remove the typing in front of it.
The common causes are structural rather than logical. Reordering or deleting columns in the FBDI sheets breaks the load, as do dates in the wrong format, quantities with stray characters, and values that do not match setup data such as the supplier site or item. Reviewing extracted fields before export catches most of the typing-driven failures.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters for Oracle loads because a good share of supplier and customer orders arrive as scans, which template-based OCR tools tend to miss or mangle.
No. Oracle's purchase order FBDI supports creating new orders and adding lines to existing ones, but it does not support updating purchase orders. Changes to an order already in the system go through the change-order path instead, so plan your load as create-plus-add-lines rather than as a two-way sync.
Yes. Oracle does not support creating or updating purchasing documents with more than 10,000 distributions, because exceeding that count causes performance problems and failed loads. For a large migration, split the work into batches that stay under the limit rather than pushing one very large file.
NetSuite is an Oracle product but a separate system with its own import model, so it has its own page. This page covers Oracle Fusion Cloud Procurement and Oracle E-Business Suite, where the load paths are FBDI with Import Orders, and PDOI with Import Standard Purchase Orders. The extraction step is identical; only the target columns differ.
PO data shaped for SAP imports.
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.
