Purchase order data extraction

Which purchase orders are worth extracting

Start with who wrote the PO. If your own ERP issued it, you already hold the data, and reading it back from a PDF adds nothing. Extraction earns its keep on purchase orders that come from outside.

• Sales order entry. Your customers each send POs on their own forms, and a coordinator keys them into your order system. The lines, ship-to and requested dates are the job.
• Accounts payable. Suppliers' invoices need checking against POs held only as PDFs or scans, often after an acquisition or from a legacy system.
• Contract and spend reviews. Old POs need reading in bulk for prices, terms and contract references.

The first case suits docRefinery best: a stable customer base means a stable set of layouts, each learned once and remembered. The use cases page covers the AP side.

Purchase order fields docRefinery extracts

There are 47 definitions, counting the line table and its 10 columns. Requisitioner and Approver Name record who raised a PO and who signed it off. Line-level GL Account matters where a PO is coded before it leaves the buyer.

Example purchase order JSON

A trimmed excerpt with invented values. This one is revision 2 with a line-level date that differs from the header. Extract a document shows the whole response.

{
  "document_type": "purchase_order",
  "result": {
    "fields": [
      { "alias": "Purchase Order ID", "text": "PO-000123", "field_confidence": 0.99,
        "location": { "page": 1, "bbox": [0.70, 0.07, 0.88, 0.09] } },
      { "alias": "Revision Number", "text": "2", "field_confidence": 0.91,
        "location": { "page": 1, "bbox": [0.70, 0.10, 0.74, 0.12] } },
      { "alias": "Requested Delivery Date", "text": "2026-12-01", "field_confidence": 0.95,
        "location": { "page": 1, "bbox": [0.70, 0.13, 0.84, 0.15] } },
      { "alias": "Contract Reference", "text": null, "location": null },
      { "alias": "Line Item", "table": [[
        { "alias": "Product Code", "text": "EX-1001", "field_confidence": 0.97,
          "location": { "page": 1, "bbox": [0.08, 0.46, 0.20, 0.48] } },
        { "alias": "Quantity", "text": "40", "field_confidence": 0.98,
          "location": { "page": 1, "bbox": [0.56, 0.46, 0.60, 0.48] } },
        { "alias": "Line Requested Delivery Date", "text": "2026-12-15", "field_confidence": 0.93,
          "location": { "page": 1, "bbox": [0.78, 0.46, 0.92, 0.48] } }
      ]] }
    ],
    "extraction_approval": "auto",
    "low_confidence_fields": []
  }
}

What order desks get from docRefinery

What makes purchase orders hard to read

• Revisions. A change order can restate the whole PO or list only what moved, and it can look almost identical to the original.
• Dates at two levels. Header dates and per-line delivery dates disagree on purpose when a shipment is split.
• Three addresses. Buyer, bill-to and ship-to can all differ, with a warehouse in one place and shared services in another.
• Whose part number? Lines may carry the buyer's code, the supplier's, or both.
• Units. "10 CS" is ten cases, not ten items, and pack sizes hide in the description.
• Boilerplate. Pages of terms and conditions follow the order, and free-text notes about delivery slots end up between lines.

How low-confidence PO values are handled

A wrong quantity on a PO ships the wrong goods, so most teams set Quantity, Unit Price and Ship To Address strictly and let Buyer Phone go loose. A value under its threshold puts the run in the review queue instead of the order system; the coordinator sees the highlighted line, fixes the cell, adds or removes a row if needed, and approves. Clean runs are marked auto and carry on. A missing Contract Reference is simply null, unless you've made the field required, when it is flagged as missing. Scoring tells you the page was read well, not that the PO itself is right.