PurchaseOrders turns a supplier PO into SAP-ready data. Upload a PDF, scan, or photo and the AI pulls the PO number, vendor, material numbers, quantities, unit prices, and delivery dates into a clean CSV, Excel, or JSON file. SAP loads that data through the Migration Cockpit, a BAPI, or an IDoc, none of which will read a PDF on their own. Try it on a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
SAP has more ways to load a purchase order than almost any system: the S/4HANA Migration Cockpit, BAPI_PO_CREATE1, the PORDCR1 IDoc, LSMW on older releases, and the Data Transfer Workbench in SAP Business One. Every one of them expects structured, column-mapped data. None of them can read the PDF a supplier emailed you.
The Migration Cockpit wants a CSV or XLSX staging template. A BAPI wants populated POHEADER and POITEM tables. An IDoc wants segments. The gap is always the same: someone has to turn the supplier document into fields before SAP will touch it.
The migration object for open purchase orders is designed to move a legacy backlog into S/4HANA once, at go-live. It is a poor fit for the POs that keep arriving every week, so day-to-day orders fall back to ME21N and manual typing.
SAP will not post a line to a vendor or material number it does not recognize. So the extracted vendor name and part numbers need to come out clean and consistent, or the load fails on records you then have to hunt down by hand.
The Migration Cockpit expects the header row of your CSV to carry the same field names as its template, with a value present for every mandatory field. One renamed column or one blank required cell and the upload stops.
PurchaseOrders reads the supplier purchase order and hands you clean, structured fields. What you do with them stays inside SAP: map them into a Migration Cockpit template, feed a BAPI, or drive an IDoc. The extraction is the part that was manual.
Download a flat file with one row per line item and consistent column names, then map it onto the staging template for the open purchase order migration object. The header row lines up instead of being retyped.
Take the same extraction as JSON and populate POHEADER, POITEM, and POSCHEDULE for BAPI_PO_CREATE1, or map it into a PORDCR1 IDoc. Developers get fields, not a PDF to parse.
Material number, description, quantity, unit of measure, unit price, and line total for every row, captured across page breaks so the line values still reconcile to the order total.
A new vendor layout works on the first upload because the AI reads fields by meaning rather than by fixed position. PDFs, scans, and phone photos all go through the same path.
Sending purchase orders out of SAP is a separate mechanism from loading them in, driven by ME9F, NACE and the NAST output determination tables. If you are on SAP Business One rather than S/4HANA or ECC, the mechanics are completely different, and the SAP Business One purchase order import page covers the Data Transfer Workbench route and the OPOR and POR1 tables. Running more than one system? The same extraction feeds a purchase order to NetSuite import, a Business Central import, a Sage import, a QuickBooks converter, and a Xero import. If you only need the file, the PO PDF to CSV converter and PDF to Excel converter produce it directly, and developers can pull structured records straight from the purchase order API. For the general approach see how to import purchase orders to your ERP, for line-level accuracy see purchase order line item extraction, and clear a backlog with bulk purchase order processing.
What each SAP load path actually does, and where the supplier PDF still has to be read by something.
| Extract first, then load | Migration Cockpit alone | Manual entry in ME21N | |
|---|---|---|---|
| Reads the supplier PDF | Yes, AI reads any layout | No, it takes CSV or XLSX only | A person reads it |
| Builds the staging file | Exported for you, one row per line | You build it by hand | Not applicable |
| Good for daily incoming POs | Yes | No, it is built for cutover | Yes, but slowly |
| Good for a legacy backlog at go-live | Yes, batch the whole backlog | Yes, that is its purpose | Not realistically |
| Needs vendor and material to exist in SAP | Yes | Yes | Yes |
| Line-item table | Captured across page breaks | Whatever you typed into it | Keyed row by row |
| Posts the document inside SAP | No, SAP does that | Yes | Yes |
| Setup | None, no templates | Migration project and mapping | None, but fully manual |
PurchaseOrders is a document extraction tool, not an SAP add-on and not an SAP partner product. It does not post documents, create master data, or run inside your SAP landscape. It reads supplier purchase orders and returns structured fields, which you then load through the S/4HANA Migration Cockpit, BAPI_PO_CREATE1, a PORDCR1 IDoc, or the Data Transfer Workbench in SAP Business One. SAP transaction names and template field names differ by release, so confirm the current steps in your own system before a production load.
No templates to build and no line items to retype. Upload a real supplier PO and get structured data back.
Drag in a PDF, a scan, or a photo from any vendor. Multi-page orders and several suppliers in one batch are fine.
Tip: Start with your messiest supplier layout. That is the one that tells you whether extraction holds up.
The AI reads the PO number, vendor, ship-to, order and delivery dates, payment terms, and each line with its material number, description, quantity, unit of measure, unit price, and line total.
Map the CSV or XLSX onto a Migration Cockpit staging template, or take the JSON and drive BAPI_PO_CREATE1 or a PORDCR1 IDoc. You review and post inside SAP, where the controls belong.
T16FS holds the release strategies, keyed on release group and release strategy, and the order itself carries those keys on EKKO as FRGGR and FRGSX along with the release indicator FRGKE and the release status FRGZU. Release codes are defined in T16FC and groups in T16FG. The full table map and the joins are in <a href='/blog/sap-purchase-order-release-strategy-tables' class='text-blue-600 hover:underline'>the SAP PO release strategy tables reference</a>. The processing state field EKKO-PROCSTAT and the item closure indicators ELIKZ and EREKZ are mapped in <a href=\"/blog/sap-purchase-order-status-table\" class=\"text-blue-600 hover:underline\">the SAP purchase order status tables reference</a>.
The header lands in EKKO, one row per document, and the line items in EKPO, one row per line keyed on EBELN plus EBELP. Schedule lines go to EKET, account assignments to EKKN, and receipts and invoices to EKBE. Field lists and the joins between them are in <a href="/blog/sap-purchase-order-tables-ekko-ekpo" class="text-blue-600 hover:underline">EKKO and EKPO, the SAP purchase order tables</a>.
Export the purchase order data to a structured file, then load it with an SAP tool. In S/4HANA that is usually the Migration Cockpit, which takes a CSV or XLSX staging template for the open purchase order migration object. For ongoing orders, teams drive BAPI_PO_CREATE1 or a PORDCR1 IDoc instead.
No. Every SAP load path expects structured data: the Migration Cockpit reads CSV or XLSX templates, a BAPI reads populated tables, and an IDoc reads segments. A supplier PDF has to be converted into those fields first, either by typing it into ME21N or by extracting it with AI.
BAPI_PO_CREATE1 is the SAP function module that creates a purchase order programmatically, using the same logic as the ME21N transaction. You populate POHEADER, POITEM, and POSCHEDULE, call the BAPI, then call BAPI_TRANSACTION_COMMIT to save. The PORDCR1 IDoc feeds the same function module. The <a href='/blog/bapi-po-create1' class='text-blue-600 hover:underline'>full BAPI_PO_CREATE1 reference</a> covers the whole parameter list, the X structure rule, and EXTENSIONIN.
Yes. The S/4HANA Migration Cockpit loads many purchase orders from one staging file, which is why it is used at go-live to bring open POs across from a legacy system. You upload the template, resolve the mapping tasks, simulate the migration, then run it.
Yes. SAP will not post a purchase order line against a vendor or material number that does not exist in the master data. That is why clean extraction matters: the vendor name and material numbers have to come out consistently so you can map them to the right master records.
SAP Business One imports transactional data through the Data Transfer Workbench, which reads structured files, or through the DI API for a coded integration. As with S/4HANA, the business partner and item records have to exist first, and the file columns have to match what the import expects.
No. PurchaseOrders is a purchase order extraction tool that runs outside your SAP landscape. It reads supplier POs and outputs CSV, Excel, JSON, or API data. You load that data into SAP yourself through the Migration Cockpit, a BAPI, or an IDoc, so the posting and the controls stay in SAP.
The B1 route: DTW, OPOR and POR1.
PO data for SAP Ariba and the Business Network.
Read PO PDFs inside a Power Automate flow.
Import PO data into Dynamics 365.
Map PO data into any ERP.
Export PO data to an SAP-ready CSV.
Pull structured PO records over an API.
