Purchase Order Fields: Every Field on a PO Explained
Jul 9, 2026
Jul 9, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
A purchase order has four groups of fields: header fields that identify the order (PO number, order date, buyer and supplier details), shipping fields (ship-to, bill-to, delivery date, freight terms), line-item fields (SKU, description, quantity, unit of measure, unit price, line total), and terms fields (subtotal, tax, shipping, grand total, payment terms). No law dictates the list. What matters is that every field a later document has to match against is present and legible.
Last updated July 2026.
If you are looking at a supplier PO right now and wondering which of these fields your system actually needs, upload it above. Every field described on this page comes back as a labeled column in Excel, CSV, or JSON in about ten seconds, which is a faster way to see what a document contains than reading it twice.
A purchase order contains roughly fifteen to twenty-five fields depending on the buyer's system. They divide cleanly into four blocks. The header identifies the order and the two parties. The shipping block says where goods go and when. The line-item table says what is being bought. The terms block says what it costs and when it is paid. Every downstream document, from the goods receipt to the invoice, matches back against one of those blocks.
Here is the full list as it appears on a typical US business purchase order, with what each field is for.
| Field | What it holds | Why it matters |
|---|---|---|
| PO number | Unique buyer-assigned reference, for example PO-2026-00417 | The key every later document quotes back; without it, matching is manual |
| PO date | Date the order was issued | Starts the clock on delivery windows and aging reports |
| Buyer / legal entity | Company name, address, and ordering contact | Tells the supplier who is contractually committed |
| Supplier / vendor | Legal name, remit-to address, vendor ID | Ties the order to the right vendor master record |
| Requester or department | Person, cost center, or project | Determines which budget the spend hits |
| Revision number | Version of the order, if amended | Prevents a superseded PO being received or paid against |
| Contract or blanket PO reference | Parent agreement number, when the order is a release | Links a call-off back to the agreement it draws down |
| Field | What it holds | Why it matters |
|---|---|---|
| Ship-to address | Physical delivery location | Where the goods actually go; often a warehouse or job site |
| Bill-to address | Where the invoice is sent | Frequently a different address from ship-to, and confusing the two delays payment |
| Requested delivery date | Date the buyer wants the goods | The commitment expediting reports are built on |
| Promised date | Date the supplier confirms on the acknowledgment | The realistic date, which often differs from the requested one |
| Shipping method and freight terms | Carrier, service level, FOB point | Determines who pays freight and who owns the goods in transit |
| Receiving instructions | Dock hours, packaging, contact on site | Prevents refused deliveries |
| Field | What it holds | Why it matters |
|---|---|---|
| Line number | Sequential position on the order | How partial receipts and line-level matching are referenced |
| Item code or SKU | Supplier part number, catalog number, or service code | The only unambiguous identifier of what was ordered |
| Description | Free text describing the item | Useful to a human, unreliable as a match key |
| Quantity | How many units are ordered | Matched against quantity received and quantity invoiced |
| Unit of measure | Each, case, box, pound, hour | The single most common source of match failures |
| Unit price | Agreed price per unit | Compared against the invoice price on every match |
| Line total | Quantity times unit price | Rolls up into the order subtotal |
| GL account or cost code | Where the cost is booked | Job costing and category spend reporting depend on it |
| Field | What it holds | Why it matters |
|---|---|---|
| Subtotal | Sum of line totals before tax and freight | The figure the line items must add up to |
| Tax | Sales or use tax where applicable | Often the difference when an invoice fails to match |
| Shipping and handling | Freight charged to the buyer | Unauthorized freight is a classic invoice exception |
| Grand total | Full committed value of the order | What hits the encumbrance or commitment ledger |
| Payment terms | Net 30, 2/10 Net 30, due on receipt | Sets the payment date and any early-pay discount |
| Currency | USD or other | Rarely stated on domestic orders and badly missed on cross-border ones |
| Authorized signature | Name or signature of the approver | Evidence the commitment was authorized |
| Terms and conditions | Standard purchasing terms, usually on the reverse or by reference | What makes the PO a binding offer once accepted |
A purchase order carries everything needed to answer four questions without asking anyone: who is buying, who is selling, what exactly is being bought, and on what commercial terms. Anything that does not serve one of those four questions is decoration. That is why a PO from a fifty-person distributor and a PO from a Fortune 500 look different in style but carry the same fields.
It looks like a one-page or two-page form: a header block with the buyer's logo, PO number, and date at the top; two address boxes side by side for vendor and ship-to; a wide table across the middle with one row per item; and a totals block bottom right with payment terms below it. Suppliers who send POs as PDFs keep this layout because receiving clerks and AP staff have learned to read it at a glance.
The visual sameness is deceptive. The column order in that middle table varies constantly. One supplier puts unit of measure after quantity, another puts it inside the description text, a third omits it. This is exactly why generic PDF to spreadsheet conversion produces a grid that looks right and is subtly wrong, while field-aware extraction maps each value to the field it belongs to regardless of where it sat on the page. If you want a guided walk through a real document, read how to read a purchase order.
There is no legally required set. In practice, five fields are non-negotiable because the order cannot be received, matched, or paid without them: PO number, supplier, ship-to address, line items with quantity and unit of measure, and payment terms. Most procurement systems enforce those as mandatory before an order can be approved and issued, and add cost center or GL account when budgets are tracked.
A useful test: for every field on your PO template, ask which later document has to match against it. If nothing ever matches against it, the field is there for a person to read, not for a system to check, and it can be optional. Quantity, unit of measure, and unit price all fail that test loudly, because the three-way match compares them against both the goods receipt and the invoice.
The PO number is a unique alphanumeric reference the buyer assigns when the order is created, and it is the single most important field on the document. It appears on the supplier's acknowledgment, the packing slip, the invoice, and the remittance. An invoice that arrives without it cannot be matched automatically and goes into a queue while someone emails the vendor. Format conventions are covered in purchase order number format.
A line item is one row of the order table, representing one product or service being bought. Its fields are the line number, item code, description, quantity, unit of measure, unit price, and line total. A fifty-line order has fifty of these rows, and each one is matched independently against what was received and what was invoiced. Header totals alone cannot support that, which is why purchase order line item extraction is the hard part of digitizing a PO.
Ship-to is where the physical goods are delivered. Bill-to is where the invoice is sent for payment. They are often different: goods go to a warehouse, distribution center, or job site, while the invoice goes to a central accounts payable address or an AP inbox. Sending an invoice to the ship-to address is one of the most common reasons a supplier's bill goes missing for a month.
The concepts are standard; the field names are not. QuickBooks calls the supplier a vendor and the line an item. NetSuite exposes a purchase order record with item sublists. SAP uses a document header and item table with number ranges by document type. Dynamics 365 Business Central uses number series and lines. When you export PO data to load into any of them, the field mapping, not the extraction, is usually the work, which is what importing purchase orders to your ERP walks through.
Three, consistently, and they are worth checking on every supplier template you accept.
Knowing the fields is step one. Step two is having them exist as data rather than as ink on a PDF. A field is only useful once it can be filtered, summed, or matched, and typing twenty-odd fields per order into an ERP is where the transposed digits come from.
Field-aware extraction handles this differently from a generic converter. It reads the document, identifies each field by what it means rather than by where it sits, and returns consistent columns whether the supplier put unit price in column four or column six. That output feeds the match, populates an AI purchase order tracking system, and imports cleanly through the purchase order PDF to Excel converter. If you are designing a PO template rather than reading one, start with how to create a purchase order and make every field above either mandatory or deliberately absent. Teams evaluating tools for the capture step should read AI purchase order software.