Headers
PO metadata becomes a stable object
PO number, supplier, dates, and ship-to fields can be returned in a contract your ERP or receiving workflow understands.
Purchase order to JSON API
Procurement JSON API
Turn purchase orders into JSON your procurement and ERP systems can trust.
Purchase orders are usually more useful as structured objects than as OCR text. LeapOCR helps teams extract supplier metadata, ship-to details, and line items into JSON that can move directly into procurement workflows.
Why teams use this
Extract headers, supplier blocks, ship-to details, and item arrays into JSON.
Support digital and scanned purchase orders in one workflow.
Keep a readable markdown layer available for buyer review and exception handling.
PO JSON request
This page targets the exact workflow where OCR must become a procurement-ready JSON object.
PO to JSON request
{ "url": "https://example.com/purchase-order.pdf", "file_name": "purchase-order.pdf", "format": "structured", "schema": { "type": "object", "properties": { "po_number": { "type": "string" }, "supplier_name": { "type": "string" }, "items": { "type": "array" } } }}
Why it works
Why teams use a PO-to-JSON page
The hard part is not reading the PO. It is producing a JSON object that fits a procurement workflow without repair work later.
Rows
Line items stay arrays
SKUs, quantities, and unit prices can be preserved as structured rows instead of flattened text.
Downstream fit
Built for receiving and ERP workflows
The output is easier to validate and route than a generic OCR response that still needs translation.
What you control
What purchase-order JSON usually contains
The useful record is the one your procurement stack can read directly.
po
Header
PO number and order date
These fields identify the procurement record and usually anchor the rest of the workflow.
supplier
Party block
Supplier and ship-to details
Capture vendor and destination metadata as separate fields instead of burying them in page text.
items
Array
Structured line items
Quantities, descriptions, SKUs, and prices can travel as item arrays for procurement and ERP writeback.
review
Readable mode
Keep markdown for manual checks
Markdown stays useful when buyers need to confirm the source layout during exceptions.
Examples
Two common PO-to-JSON workflows
Most teams either need a procurement-ready object or a readable PO alongside structured output.
ERP handoff
Return a purchase order object for downstream systems
Useful when the purchase order must move directly into an ERP, receiving, or internal procurement workflow.
PO JSON
json
{ "po_number": "PO-10441", "supplier_name": "Blue Harbor Supply", "items": [ { "sku": "AX-44", "quantity": 12, "unit_price": 48.0 } ]}
Buyer review
Keep a readable purchase order version for checks
Useful when a buyer still needs to compare the source document against the extracted record before approval.
Markdown excerpt
md
# Purchase order PO-10441- Supplier: Blue Harbor Supply## Items- AX-44 · Qty 12 · 48.00
FAQ
Questions teams ask before wiring this up
Straight answers for teams evaluating how this workflow fits into production.
Is this different from the purchase order OCR API page?
Yes. This page targets the exact 'purchase order to JSON' workflow and frames the value around a procurement-ready JSON object rather than OCR in the abstract.
Can the JSON include line items?
Yes. Purchase order line items can be returned as structured arrays with quantities, SKUs, descriptions, and pricing.
Can I still keep a readable version of the PO?
Yes. Markdown can remain available for buyer review while JSON powers the downstream procurement workflow.
Ready to test
Test whether your purchase orders become useful JSON records
Run a real purchase order and check whether the result fits your procurement stack without another parsing or cleanup pass.