A freight brokerage, 3PL, or carrier runs on inbound paperwork: customer transport orders, supplier POs for parts and equipment, and carrier confirmations, most of it arriving as PDFs, emailed attachments, and scans rather than clean EDI. PurchaseOrders reads each one with AI and returns the shipper or vendor, the PO or reference number, dates, and every line with its description, quantity, and price. Upload a PO below and get spreadsheet rows in about ten seconds.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Your largest partners send EDI 850s and 204s, but the long tail of shippers, vendors, and owner-operators still emails PDF purchase orders, transport orders, and scans. Someone in operations or billing keys each one into the TMS or ERP before a load can be built, a carrier assigned, or an invoice raised. At freight volume, that typing is a bottleneck that delays tenders and introduces reference-number errors that turn into disputes.
A PO number, a shipper reference, a PRO number, or a BOL number ties the whole shipment together. Transpose one digit keying it into the TMS and the load, the billing, and the customer status update all point at the wrong record. Volume makes a careful manual copy slow and error prone.
A transport order or supplier PO carries lines for the freight, fuel, detention, liftgate, and other accessorials, each with a charge. Rush the entry and a line gets dropped or mistyped, so the load is under-billed or the vendor invoice will not match later.
Big shippers get onboarded to EDI, but the many smaller ones and one-off vendors do not justify the setup. So a steady stream of PDF and emailed POs keeps landing in a shared inbox, and every one is retyped into operations by hand.
A PO or rate confirmation arrives as a fax or a phone photo with no text layer. It gets retyped line by line before dispatch can move, and that lag is felt by a shipper waiting on a pickup confirmation.
PurchaseOrders reads each document by meaning, so a new shipper or vendor layout works on the first upload. It captures the header references and the full line detail your TMS, billing, and ERP depend on, without a template per partner.
PO number, shipper reference, PRO, and BOL number are pulled with the header so the shipment can be matched to the right record in your TMS instead of hunted for by hand.
Each line, the freight charge, fuel, detention, and other accessorials, is captured with its quantity and amount, so the load is billed and the vendor invoice reconciled against the right figures.
OCR plus AI reads a faxed or photographed PO with no text layer, rebuilds the line table, and returns structured rows, so the non-EDI long tail stops blocking dispatch.
Excel, CSV, JSON, or the API, so the data feeds order entry, a billing sheet, or your TMS and ERP without retyping.
Operations clearing a shift of inbound POs at once use bulk purchase order upload, and accuracy on the charge lines comes from purchase order line item extraction. Getting the numbers into a sheet is covered by the PDF to Excel and PDF to CSV routes, and pulling data programmatically at volume is what the purchase order API is for. Turning inbound customer transport orders into loads is close to sales order entry automation, and adjacent operations sit in wholesale distribution and manufacturing extraction.
What each way of getting PO and transport-order data into operations actually does at volume.
| PurchaseOrders (capture layer) | Manual TMS entry | EDI onboarding | |
|---|---|---|---|
| Reads any shipper or vendor PO | Yes, AI reads any layout | A person reads it | Only fully onboarded partners |
| Captures references and charge lines | Yes, per document | If there is time and focus | Yes, mapped in the EDI setup |
| Handles the non-EDI long tail | Yes, on first upload | Keyed by hand | Not worth onboarding small partners |
| Works on a fax or photographed PO | Yes, OCR plus AI | Retyped by hand | No, EDI only |
| Time to add a new partner | None, works immediately | None, already manual | Weeks of mapping and testing |
| Rates, tenders, or dispatches the load | No, your TMS does | The operator does, manually | No, EDI is a data channel |
| Pricing | Free to try, then per document | Staff hours that scale | Per-partner setup and VAN fees |
PurchaseOrders is a document extraction tool, not a TMS or an EDI network. It does not rate loads, tender freight, dispatch carriers, or replace EDI with your largest partners. Systems such as McLeod, MercuryGate, Turvo, or your EDI provider do that. This tool captures clean line-item data from the PDF, fax, and scanned POs and transport orders those systems do not receive electronically.
Take one emailed transport order or supplier PO and get its lines into the TMS.
Drag in the PDF, the emailed attachment, the fax, or a phone photo from any shipper, vendor, or carrier. Batch a shift of inbound POs if you process in waves.
Tip: Try a transport order with multiple accessorial lines to see each charge captured.
Shipper or vendor, dates, PO and reference numbers, and each line with description, quantity, and amount come back as rows you check on screen.
Export to Excel or CSV, or send the data through the API into your TMS or ERP. Your system builds the load, assigns the carrier, and raises the invoice.
They upload the shipper or vendor PO to an AI extraction tool that reads the header, the PO and reference numbers, and every line with its description, quantity, and amount, then export to the TMS or a spreadsheet. This replaces keying each PDF, fax, and emailed transport order into operations by hand, which is the bottleneck that delays load building and billing at freight volume.
No. EDI stays the right channel for your largest, highest-volume partners. This tool handles the long tail EDI does not cover, the smaller shippers, one-off vendors, and owner-operators who email PDF purchase orders or send faxes and scans. It captures those into clean line data so the non-EDI orders move as fast as the EDI ones.
Yes. It pulls the PO number, shipper reference, PRO number, and BOL number from the header so the shipment can be matched to the right record in your TMS. The tool captures the numbers as written; tying them to a load or an invoice is done by your TMS or ERP, which is where the shipment record lives.
Yes. Each line, the linehaul or freight charge, fuel, detention, liftgate, and other accessorials, is captured with its amount so the load is billed and the vendor invoice reconciled against accurate figures. Dropping or mistyping an accessorial by hand is a common cause of under-billing and later disputes, which line-level capture avoids.
No. It extracts data from the document; it does not rate loads, tender freight, dispatch carriers, or track shipments. Those belong in your TMS such as McLeod, MercuryGate, or Turvo. PurchaseOrders feeds that system, or your spreadsheet, clean line-item data so operations and billing start from accurate numbers instead of retyped ones.
Yes. You can run up to 100 POs through a single bulk upload, and pull data programmatically through the API for steady high volume. That lets an operations or billing team clear a shift of inbound PDF and faxed POs in one pass instead of typing each one before a load can move.
Capture every reference and charge line.
Process hundreds of POs at once.
Pull PO data programmatically.
Capture high-volume distribution POs.
Export PO lines to CSV for import.
Turn inbound orders into loads.
