Extracting purchase orders and invoices into the ERP: where projects fail.

Reading the page is only half the task

In a demo, automating purchase orders or supplier invoices looks finished. Someone drags a PDF into a browser window, and three seconds later a language model outputs a clean table of line items, quantities and prices. Everyone in the room nods.

Then the team tries to post that output into SAP, NetSuite, Dynamics or Odoo, and the ERP rejects four out of five orders. The model read the PDF accurately—it wrote "Valve assembly DN40, 2 pallets" because that is what the customer printed on the page. Your ERP, however, needs internal customer ID CUST-0194, ship-to location WH-HAMBURG-03, internal SKU VLV-040-SS, and a quantity of 96 individual units at the agreed contract price.

The five gaps between PDF and ERP

When a document workflow meets a production inbox, the failures almost never come from misreading characters. They come from five translation steps that human operators perform in their heads without realising it:

The five entity-resolution checks required before a transcribed purchase order or supplier invoice can post to an ERP.

Even small per-line ambiguity compounds across a multi-line order. By simple binomial arithmetic (pⁿ), if an order has ten line items and each line has a 0.90 probability of matching a catalogue SKU and unit of measure on raw text alone, only 0.90¹⁰ ≈ 35% of complete orders can post without an exception.

Separate extraction from resolution

The architectural mistake that sinks most projects is asking the language model to do everything in one prompt—read the PDF, guess the internal SKU, convert the units and output an ERP payload. Language models are good at reading messy layouts; they are bad at holding your entire ERP master database in their heads.

A dependable workflow splits the work into four distinct stages:

1. Extract what is on the page, verbatim. Ask the model only to transcribe what the document says into a strict schema: sender tax ID, buyer part code, printed description, printed quantity, printed unit and line total, along with the page coordinates of each field.
2. Resolve against master data in code. Match the sender against your ERP customer table using VAT number, IBAN or email domain. Look up the buyer’s part code in a customer-to-SKU cross-reference table, and apply the SKU’s pack-size conversion factor from your item master.
3. Run deterministic arithmetic and contract checks. Verify in plain code that quantity × unit_price = line_total, that the sum of lines plus tax equals the document total, and that each unit price matches the customer’s active price list within your agreed tolerance.
4. Route to a side-by-side approval queue. Orders that pass every check arrive in the operator’s queue ready to approve in one click. Orders with an unknown SKU, a price variance or a delivery date inside lead time arrive with the exact field highlighted next to the original PDF passage.

SELECT
  l.doc_id,
  l.line_no,
  c.erp_customer_id,
  x.erp_sku_id,
  l.printed_qty * u.to_base_factor                             AS erp_base_qty,
  ROUND(l.printed_unit_price / u.to_base_factor, 4)            AS realised_base_price,
  p.contract_base_price,
  ABS(l.printed_qty * l.printed_unit_price - l.printed_total)  AS line_math_diff,
  CASE
    WHEN c.erp_customer_id IS NULL THEN 'UNRESOLVED_CUSTOMER'
    WHEN x.erp_sku_id IS NULL      THEN 'UNKNOWN_BUYER_PART'
    WHEN u.to_base_factor IS NULL  THEN 'UNMAPPED_UOM'
    WHEN ABS(l.printed_qty * l.printed_unit_price - l.printed_total) >= 0.02
                                   THEN 'LINE_ARITHMETIC_ERROR'
    WHEN ABS((l.printed_unit_price / u.to_base_factor) - p.contract_base_price) > 0.005
                                   THEN 'CONTRACT_PRICE_VARIANCE'
    ELSE 'READY_FOR_ERP'
  END AS resolution_status
FROM stg_extracted_po_lines l
LEFT JOIN erp_customers c
  ON l.extracted_vat_id = c.vat_id
LEFT JOIN erp_customer_sku_xref x
  ON c.erp_customer_id = x.erp_customer_id
 AND l.printed_buyer_part_no = x.buyer_part_no
LEFT JOIN erp_uom_conversions u
  ON x.erp_sku_id = u.erp_sku_id
 AND UPPER(l.printed_uom) = u.printed_uom_code
LEFT JOIN erp_contract_prices p
  ON c.erp_customer_id = p.erp_customer_id
 AND x.erp_sku_id = p.erp_sku_id
 AND l.order_date BETWEEN p.valid_from AND p.valid_to;

Turn corrections into reference data

The most valuable moment in a supervised workflow is when an operator fixes an exception. When a customer sends part number CUST-9981 for the first time and a person maps it to internal SKU VLV-040-SS, the system writes that mapping into erp_customer_sku_xref upon approval.

The next time that customer orders the same item, the SQL join resolves it deterministically on the first pass—without fine-tuning a model or touching a prompt. Exception rates fall over time because the master-data bridge gets richer with every approved order.

What realistic performance looks like

In a well-designed B2B order or invoice workflow, operators do not disappear; their job changes. Repeat orders whose customer VAT ID, ship-to location, cross-referenced part numbers, pack sizes and contract prices all pass the deterministic checks arrive ready to post in one click, while the operations team spends its time solely on genuine commercial exceptions—a first-time buyer part code, an unapproved price difference or a requested delivery date inside lead time.