Infor gives you real load paths for purchase orders. M3 has Purchase Order Batch Entry, which stages records in the MX interface tables before transferring them into MPHEAD and MPLINE. LN has the Purchase Order Intake Workbench in front of tdpur400 and tdpur401. Both want structured rows, and neither reads a PDF. PurchaseOrders reads the purchase order document, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the file feeding your Infor load 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...
The Infor estate is wide. A US manufacturer might be on M3, a distributor on LN, a mid-market shop on CloudSuite Industrial. The purchasing screens differ, the table names differ, and the load programs differ. What does not differ is the step before all of them: somebody has to turn a supplier document into structured data, and in most Infor shops that somebody is a person with two windows open.
Purchase Order Batch Entry stages data in interface tables such as MXHEAD for headers and MXLINE for lines, with MXPOAD for addresses, MXOEXP for charges, and MXTEXT for text blocks. You work the batch in Purchase Order Batch. Open (PPS370) and Purchase Order Batch. Open Lines (PPS371). Every one of those rows has to come from somewhere, and a PDF is not a row.
The Purchase Order Intake Workbench (tdpur4601m200) filters orders into Purchase Orders Intake (tdpur4100m100) so a buyer can review them before they become live orders. Orders reach intake from Enterprise Planning, requisition and RFQ conversions, sales direct delivery, service order planning, manual entry, or an external system. That last route is the one a supplier PDF has to travel, and it needs clean fields first.
M3 batch records move through statuses as they are entered, validated, and processed before they create anything in MPHEAD and MPLINE. A malformed date, an item number that does not match the item master, or a unit of measure Infor does not recognize stops the record at validation. Most of those failures start as transcription mistakes.
In M3 the header lands in MPHEAD and the lines in MPLINE. In LN it is tdpur400 and tdpur401. Keying an order by hand means keeping the header and every line consistent across two structures, and a mismatch usually surfaces after the load, not during it.
Infor customers are often multi-plant or multi-company, which means the same supplier PO may need different facility, warehouse, or division values depending on where it lands. That decision is fine for a person to make once. It is expensive when the person also has to retype forty line items underneath it.
A migration onto CloudSuite, a quarter of accumulated customer POs, or a newly acquired plant all land as a stack of documents. The Infor side of the load runs in minutes. The data-entry side runs for weeks.
PurchaseOrders is the capture step in front of your Infor load. It is not an Infor connector and it does not run inside M3, LN, or CloudSuite. You give it a purchase order document. It gives back clean, field-level data that you map to the columns your batch entry, intake, or ION integration already expects, then you load it with the Infor 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 item number, description, quantity, unit of measure, unit price, and extended amount, captured across page breaks.
Output is one row per line item with consistent headers. Map your columns once to the M3 batch interface tables or the LN order and line structures, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already talks to Infor, whether that is an ION flow, a middleware job, or a script that writes your staging rows. Clean fields in, no document parsing on your side.
Upload a stack of orders at once rather than one at a time. That is what turns a CloudSuite migration load 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 costs a great deal less than finding it after a batch record has already failed validation.
M3 keeps live purchase orders in two tables: MPHEAD for the order header and MPLINE for the order lines. Both are what PPS200, Purchase Order. Open, and PPS201, Purchase Order. Open Lines, write to when a buyer keys an order on screen. For anything arriving from outside, M3 offers Purchase Order Batch Entry. Batch data sits first in a set of interface tables, including MXHEAD for batch headers, MXLINE for batch lines, MXPOAD for addresses, MXOEXP for charges, MXCCST for accounting entries, and MXTEXT for text blocks. You maintain those records in PPS370 and PPS371, and once the batch transfers, the result is a normal purchase order in MPHEAD and MPLINE that behaves exactly as if it had been created in PPS200. The question this page answers is where the batch rows come from. If the answer today is a person reading a PDF, this tool replaces that step.
LN stores purchase orders in tdpur400 and the lines in tdpur401, maintained through Purchase Orders (tdpur4100m000), Purchase Order (tdpur4100m900), and Purchase Order Lines (tdpur4101m000). In front of those sits the intake layer. The Purchase Order Intake Workbench (tdpur4601m200) applies filter settings, Purchase Orders Intake (tdpur4100m100) shows the filtered orders, and Purchase Order Intake Lines (tdpur4101m500) shows their detail, so a buyer can look at an order before it moves on. Orders can arrive in intake from Enterprise Planning transfer orders, sales direct delivery or cross-docking, service order resource planning, purchase requisition conversions, RFQ conversions, manual entry, or creation by an external system. From there an order progresses through statuses such as Created, Approved, Modified, Sent, In Process, Blocked, Canceled, and Closed. A supplier PDF takes the external-system route, which means the external system needs structured data to send.
M3 exposes its functionality through MI programs, and the purchasing one most teams meet is PPS200MI, the Purchase Order Information and Text Interface, which covers the order header, the order lines, order line transactions, order addresses, and order texts. The transactions available to you and their exact field layouts are documented inside your own system in the API repository programs MRS001, MRS002, and MRS003, which is the right place to check before building anything, because the transaction set depends on your version. Whichever route your integration takes, ION flow or direct call, it needs field-level values rather than an email attachment. That is what our JSON output provides.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not an Infor connector, it does not install in M3, LN, or CloudSuite, it does not run batch transfers, it does not write to MPHEAD, MPLINE, MXHEAD, MXLINE, tdpur400, tdpur401, or any other Infor table, and it does not create, approve, receive, or match purchase orders. Those all stay in Infor. We remove the typing that happens before the load, and nothing else.
Infor manufacturers whose customers still send POs as PDFs use it so those orders reach M3 or LN the same day they arrive. Distributors running multi-site estates use it to keep a consistent capture step across plants. Teams migrating onto CloudSuite use it to build the initial load file. Integration teams wiring an orders mailbox into ION use the purchase order API so the flow receives JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, row-level accuracy on long orders is covered in purchase order line item extraction, and a backlog clears through bulk purchase order upload. The general pattern is in how to import purchase orders to an ERP, and teams comparing systems can look at purchase order to SAP, Oracle purchase order import, and purchase order to Epicor. Plant-floor teams often start with purchase order extraction for manufacturing.
All three end at the same place, a live order in MPHEAD and MPLINE or in tdpur400 and tdpur401. They differ in what happens before the load.
| What matters | Manual keying into PPS200 or LN | 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 the screen | Needs cleanup | Row per line, ready to map |
| Records stuck at validation | 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 your Infor load columns. It is not an Infor connector, does not run batch transfers, does not write to MPHEAD, MPLINE, MXHEAD, MXLINE, tdpur400, tdpur401, or any other Infor table, and does not create, approve, receive, or match purchase orders. Infor, M3, LN, and CloudSuite are trademarks of Infor; this page is not affiliated with or endorsed by Infor. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside M3, LN, or CloudSuite.
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 a batch record fails validation.
Download Excel or CSV, map the columns to your M3 batch entry layout or your LN order and line structures, and run the load you use today, or pull JSON via the API and let your ION flow write the rows.
Through Purchase Order Batch Entry. You stage the order in the batch interface tables, principally MXHEAD for the header and MXLINE for the lines, maintain and validate the records in Purchase Order Batch. Open (PPS370) and Purchase Order Batch. Open Lines (PPS371), then transfer the batch. The transfer creates a normal purchase order in MPHEAD and MPLINE that you can work with exactly as if it had been keyed in PPS200.
They are the live purchase order tables. MPHEAD holds the purchase order header, which carries the information valid for the whole order such as terms and addresses. MPLINE holds the order lines, one per item being purchased. Both are updated by Purchase Order. Open (PPS200) and by a completed batch transfer.
tdpur400 is the purchase order table in LN and tdpur401 is the purchase order lines table. You reach them through sessions such as Purchase Orders (tdpur4100m000), Purchase Order (tdpur4100m900), and Purchase Order Lines (tdpur4101m000). Line types include order line, detail, back order, and total, where a total line aggregates detail delivery lines.
It is a filtered review layer that sits in front of live purchase orders. The workbench (tdpur4601m200) applies your filter settings, Purchase Orders Intake (tdpur4100m100) lists the orders that match, and Purchase Order Intake Lines (tdpur4101m500) shows their detail. Double-clicking a line opens the full Purchase Order session so the order can be worked normally.
Several places. Enterprise Planning transfer orders, sales direct delivery or cross-docking, service order resource planning, purchase requisition conversions, RFQ conversions, manual entry, and creation by an external system. A supplier PDF that has been extracted into structured data travels the external-system route.
Yes, and many Infor estates do it through ION rather than a file. M3 exposes MI programs, and the purchasing one you will meet is PPS200MI, the Purchase Order Information and Text Interface, covering the order header, order lines, order line transactions, addresses, and texts. Check the exact transaction set for your version in the API repository programs MRS001, MRS002, and MRS003 before you build.
The capture step is the same regardless of which Infor product you run, because it happens before Infor sees the data. We read the purchase order document and return the header fields and line items as Excel, CSV, or JSON. You map those columns to whatever your CloudSuite load or integration expects. What differs between M3, LN, and CloudSuite is the destination, not the extraction.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in M3, LN, or CloudSuite, it does not run batch transfers, it does not write to any Infor table, and it does not create, approve, receive, or match orders. You keep using Infor exactly as you do now; we 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 in Infor estates because manufacturing and distribution customers still send a meaningful share of orders as scans, which template-based OCR tools tend to miss or mangle.
Line items are captured as a table rather than as loose text, including across page breaks, which is where most document tools lose rows. Every field is shown on screen before export so you can check quantities, unit prices, and units of measure against the document. Reviewing forty lines takes far less time than typing them.
PO data shaped for SAP.
The same capture step for Oracle Fusion and EBS.
PO data for the JDE Z-file load.
PO data for Infor M3, LN and CloudSuite.
PO data shaped for Epicor Kinetic.
The general ERP load path.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Capture built around plant workflows.
