What Does a Purchase Order Look Like? PO Example

Jul 9, 2026

Convert a purchase order to Excel, CSV, or JSON

PDF, JPG, PNG, BMP, HEIC, TIFF

Submit your purchase orders

A purchase order looks like a one-page business form, usually a PDF, that reads top to bottom in four blocks. The top holds a title ("Purchase Order"), a unique PO number, and the order date. Below it sit the buyer's and supplier's names and addresses, plus separate ship-to and bill-to lines. The middle is a table of line items with quantity, description, unit of measure, unit price, and line total. The bottom shows the subtotal, tax, shipping, grand total in USD, payment terms like Net 30, and sometimes a signature line.

Last updated July 2026.

If you have a supplier PO open right now and want to see exactly what fields it holds, upload it in the tool above. It reads the document and returns every field as a labeled column in Excel, CSV, or JSON in about ten seconds, which is a quicker way to see a PO's contents than squinting at the layout.

What does a purchase order look like?

A purchase order looks like a formal, single-page form with a header at the top, two address blocks under it, a grid of line items in the middle, and a totals-and-terms block at the bottom. It's usually a PDF or a printout on company letterhead. The layout is deliberately plain because the document has to be read quickly by a warehouse clerk, an accounts payable specialist, and sometimes a piece of software.

Think of it as a receipt written before the purchase happens. An invoice tells you what you owe after goods ship; a PO states what the buyer agreed to buy, at what price, and on what terms, before anything moves. Because it's the buyer's authorization to spend money, every zone on the page exists to remove ambiguity about who ordered what, where it goes, and how it gets paid.

The anatomy of a purchase order, top to bottom

Almost every PO you'll see in US business, whether it comes out of SAP, NetSuite, QuickBooks, or a Word template a small supplier built by hand, follows the same vertical order. Here is what each zone contains and why it's there.

Zone What appears there Why it matters
Header block Title "Purchase Order," PO number, order date, buyer logo Identifies the document and gives it a unique reference every later document quotes back.
Buyer block Ordering company name, address, contact, buyer email or phone Tells the supplier who to bill and who authorized the spend.
Supplier block Vendor name, address, vendor number Confirms which vendor record the order is tied to in the buyer's system.
Ship-to vs bill-to One address for delivery, a separate one for the invoice Goods and paperwork often go to different places; mixing them delays receiving.
Line-item table Item number, description, quantity, unit of measure, unit price, line total The actual order. This grid is what receiving and accounts payable check against.
Totals and terms Subtotal, tax, freight, grand total (USD), payment terms, delivery date Sets the agreed price and when payment is due, usually Net 30 or Net 60.
Signature and notes Authorized signature, special instructions, terms and conditions Shows internal approval and captures anything the standard fields can't.

If you want a field-by-field walkthrough rather than the zone view, our guide to every PO field explained lists all fifteen to twenty-five fields and flags the ones that break automated matching. For a reading order that follows how accounts payable actually checks a PO, see how to read a purchase order.

What information is on a purchase order?

A purchase order carries the identifying details (PO number, order date, both companies' names and addresses), the shipping details (ship-to, bill-to, delivery date), the goods themselves as line items (description, quantity, unit price, line total), and the money details (subtotal, tax, freight, grand total, payment terms). Some fields are effectively mandatory; others are optional.

The distinction matters because a PO with a missing PO number or a blank unit price can't be matched to a later invoice without manual chasing. Here's how the fields typically split.

Field Required or optional Notes
PO number Required The unique key every downstream document references.
Order date Required Anchors payment terms and audit trails.
Buyer and supplier Required Names and addresses of both parties.
Line items Required Quantity, description, unit price, line total per row.
Grand total Required Stated in USD, drives three-way matching later.
Payment terms Usually present Net 30, Net 60, or 2/10 Net 30 discount terms.
Ship-to / bill-to Usually present Split when delivery and billing addresses differ.
Requisition or department code Optional Common in larger buyers with internal cost centers.
Signature Optional Many electronic POs skip it; system approval replaces the wet signature.

What is the difference between a purchase order and an invoice?

A purchase order is issued by the buyer before goods ship and states what they agreed to buy; an invoice is issued by the supplier after goods ship and states what the buyer now owes. They look similar because both list line items and totals, but the direction and the timing are opposite. The PO comes first and the invoice references its PO number.

In practice, accounts payable lines up the two documents (plus the receiving record) to confirm the invoice matches the order before paying. If you handle both sides, our breakdown of purchase order vs invoice covers exactly which fields should agree and which commonly drift.

Is there a standard purchase order format?

No single legal standard dictates a PO's layout, so formats vary by the software that produced them, but the content is remarkably consistent: header, parties, line items, totals, terms. A PO from a Fortune 500 ERP and one a two-person supplier types into a template will differ in styling yet carry the same fields in roughly the same order. That consistency is why the document is easy to read and easy to parse.

The one structured exception is EDI, where large trading partners exchange the same information as a coded 850 transaction instead of a PDF. Whether it arrives as a polished PDF, a scanned image, or an emailed template, the underlying structure holds. That's what makes it practical to run any PO through a purchase order PDF to Excel converter and get clean columns back regardless of who designed the form.

What does a PO number look like?

A PO number looks like a short alphanumeric string, often a prefix plus a sequential number, such as PO-10432, 4500098231, or 2026-000145. It's usually printed near the top right of the header and is the single most important field on the page because every invoice, packing slip, and payment references it. Length and style depend entirely on the buyer's system.

There's no universal format, but the patterns cluster into a few recognizable shapes.

Pattern Example Where you'll see it
Prefix + sequence PO-10432 Small to mid-size businesses, QuickBooks.
Long numeric 4500098231 SAP and other large ERPs.
Year + sequence 2026-000145 Buyers that reset numbering each year.
Department + sequence MKT-2026-0088 Organizations tracking spend by team.

For the full logic behind prefixes, sequencing, and why duplicates cause payment errors, see our guide to purchase order number format.

Does a purchase order need a signature?

A purchase order does not legally require a handwritten signature to be valid in most US business contexts; approval inside the buyer's purchasing system usually serves the same purpose. Many POs still include a signature line out of habit or for higher-value orders, but electronic POs routinely go out with none. What makes a PO binding is that the buyer issued it and the supplier accepted it.

When a signature line is present, it typically sits at the bottom near the terms, alongside a printed name and a date. If your supplier's terms and conditions call for a countersignature, that's a contract requirement, not a rule about what a PO must contain.

Can a purchase order be an email?

Yes, a purchase order can be an email, an emailed PDF attachment, an EDI message, or even a form on a supplier portal; it does not have to be a printed page. What defines a PO is the information it carries, not the format it arrives in. An email that states the PO number, items, quantities, prices, and delivery terms functions as a purchase order.

That flexibility is also why PO data lands in so many shapes. A buyer might send a crisp PDF one week and a scanned, slightly crooked image the next. Pulling consistent data out of all those variants by hand is slow, which is where automated line-item extraction earns its keep: it reads the grid whether the file is native text or a photo.

From looking at a PO to using its data

Knowing what a PO looks like is step one. The harder part is getting its contents into a system you can work with, because a PDF is easy for a person to read and hard for a spreadsheet to consume. If you receive dozens of supplier POs a week, retyping the header and every line into your ERP is where errors and delays creep in. The same problem shows up on the sales side when you need to turn a stack of supplier invoices into a spreadsheet for reconciliation.

PurchaseOrders reads the document you upload and returns the PO number, supplier, dates, and every line item as structured Excel, CSV, or JSON, or through an API. To be clear about what it does and doesn't do: it extracts the data on the page. It does not create purchase orders, route them for approval, or run three-way matching. It hands you clean fields so your own system can do those steps. If you're mapping where extraction fits, our overview of the purchase order process shows the full lifecycle, and purchase order automation software covers where accurate data capture removes the most manual work.

The short version: a purchase order looks like a plain one-page form built for fast reading, and once you know its six zones you can find any field in seconds. To skip the reading entirely, upload the PO above and get the same fields back as columns.