Purchase order parsing API

Purchase orders drive procurement, but they arrive as PDFs and email attachments that a buyer's system can't read without manual keying. The AIDataParser purchase order parsing API converts a PO into structured JSON: PO number, order date, buyer and supplier details, billing and shipping addresses, requested delivery date, and a line-item array with SKUs, quantities, and prices. Define the schema and every PO — regardless of the ERP that produced it — comes back in the same shape.

This is what lets a supplier auto-ingest incoming orders and a buyer reconcile POs against invoices without a data-entry team. Each line item is a discrete object, so three-way matching (PO vs. goods receipt vs. invoice) becomes a straightforward comparison instead of a fuzzy text search. Ship-to and bill-to addresses are separated into their own fields for routing and tax logic.

Drop it into an order-management workflow or an autonomous procurement agent: POST the PO, receive structured data for one credit, and use review_needed to hold anything ambiguous for human sign-off. Because it's schema-first rather than template-based, onboarding a new trading partner doesn't require building a new parser.

Get 50 free credits

Fields you can extract from a purchase order

po_numberstring

Purchase order identifier.

order_datestring

Date the PO was issued.

buyerstring

Ordering company.

supplierstring

Vendor fulfilling the PO.

ship_tostring

Delivery address.

delivery_datestring

Requested delivery date.

line_itemsarray

SKU, quantity, unit price.

Example request

POST the purchase order by URL, upload, or base64, with a JSON Schema describing the output you want.

curl -X POST https://aidataparser.com/v1/parse/document \
  -H "Authorization: Bearer adp_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/purchase-order.pdf",
    "schema": {
      "type": "object",
      "properties": {
        "po_number": {
          "type": "string"
        },
        "order_date": {
          "type": "string"
        },
        "buyer": {
          "type": "string"
        },
        "supplier": {
          "type": "string"
        },
        "ship_to": {
          "type": "string"
        },
        "line_items": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "sku": {
                "type": "string"
              },
              "quantity": {
                "type": "number"
              },
              "unit_price": {
                "type": "number"
              }
            }
          }
        }
      }
    }
  }'

Example response

The data field is guaranteed to match your schema.

{
  "object": "parse.document",
  "data": {
    "po_number": "PO-55810",
    "order_date": "2026-07-01",
    "buyer": "Contoso Retail",
    "supplier": "Fabrikam Goods",
    "ship_to": "220 Dock St, Newark, NJ 07102",
    "line_items": [
      {
        "sku": "WIDGET-BLK",
        "quantity": 500,
        "unit_price": 2.4
      },
      {
        "sku": "WIDGET-RED",
        "quantity": 250,
        "unit_price": 2.4
      }
    ]
  },
  "confidence": "high",
  "review_needed": false,
  "credits_charged": 1,
  "credits_remaining": 49
}

FAQ

Can it separate ship-to from bill-to addresses?

Yes. Model each address as its own field in your schema and the API returns them independently, which is essential for routing and tax determination.

Does it support three-way matching?

It provides the structured PO side of the match — line items as discrete objects with SKU, quantity, and price — so you can compare against goods receipts and invoices programmatically.

How does it handle POs from different ERP systems?

Extraction is model-driven, not template-based, so POs from any ERP layout map onto the same JSON schema without per-partner parser work.