Purchase order processing
Tavnit reads incoming purchase orders and returns PO number, buyer, ship-to details, requested dates and every line item as typed fields. Because invoices are extracted into the same shape, matching an invoice to its PO becomes a query rather than a manual comparison.
Why this is painful
Purchase orders arrive as PDF attachments from customers who each use their own ERP output, and somebody re-keys them into your order system. The re-keying is the bottleneck, and it is also where quantity and SKU errors enter — the two errors that turn into a shipping problem.
The second half of the problem is matching. When the invoice eventually arrives, someone compares two documents by eye to confirm that what was ordered is what was billed.
What to extract
| Field | Why it needs care |
|---|---|
| PO number | The key everything else joins on. Text, not numeric — prefixes and leading zeros are significant. |
| Buyer and ship-to address | Frequently different, and the difference matters for fulfilment. |
| Line items with SKU and quantity | A repeating table. Customer part numbers often differ from yours, which is a lookup problem. |
| Unit price and extended amount | Both, so the arithmetic can be verified rather than assumed. |
| Requested delivery date | Sometimes per line rather than per order. |
| Payment and incoterms | Short fields with outsized downstream consequences. |
What makes purchase orders hard
Customer part numbers are not your part numbers
A PO lists what the buyer calls the item. Your system knows a different SKU. A lookup Cleaner matches customer part numbers against your reference data during processing, so the order arrives already translated rather than needing manual mapping.
Matching is the point, and it only works if shapes agree
Three-way matching falls apart when the PO and the invoice are extracted into different field names. Using the same field naming across both flows is what makes matching a query on the PO number rather than a document comparison.
Quantity errors are the expensive ones
A wrong price is an invoicing correction. A wrong quantity is a shipment. A formula Cleaner checking that unit price times quantity equals the extended amount catches a large share of misreads before anything is picked.
How the pipeline handles it
- Collections — Customers send POs, invoices and delivery notes to the same address. Collections classifies each and routes it to the right flow.
- Cleaners — Maps customer part numbers to your SKUs by lookup, and verifies line arithmetic.
- Buckets — Holds POs and invoices in the same shape, so matching is a query on the PO number.
- API Integration — Pushes confirmed orders into your ERP without a manual step.
Common questions
- Can it match invoices to purchase orders?
- Extract both into the same field structure and matching becomes a query on the PO number in your Bucket. Tavnit produces the structured data that makes matching possible; the comparison then runs against your own data rather than against two PDFs.
- What if the customer uses their own part numbers?
- A lookup Cleaner matches customer part numbers against your reference data during processing, so orders arrive already translated to your SKUs.
- Do line items come through separately?
- Yes. Line items are table fields, so each row returns SKU, quantity, unit price and extended amount as separate typed values.
Other document types
Try it on one document
Build a flow, send a real purchase order through it, and see what comes back. Free credits to start.
Start free