ERP Core ConceptsGlossary

What Is Purchase Order (PO)?

Also known as: PO, purchase order in ERP

Definition

A purchase order (PO) is a document a buyer issues to a supplier committing to buy specified items or services at agreed quantities, prices and delivery dates. In ERP it drives receiving, invoice matching, open commitments and supply in MRP.

Purchase Order (PO) Explained

A purchase order is the buyer's formal commitment to a supplier. It carries a header (supplier, currency, payment terms, incoterms, ship-to) and one or more lines (item, quantity, unit of measure, unit price, promise date). Once the supplier accepts it, the PO is the contract reference for everything that follows: receipt, inspection, invoice and payment.

In ERP the PO is also a planning object. An open PO line is scheduled supply: MRP counts it against demand, and a late promise date triggers reschedule or expedite messages. It is also a financial object, because the open value is a commitment that finance uses for accruals and budget checks before an invoice exists.

Every major system has its own shape. SAP creates POs in ME21N and posts receipts against them in MIGO. NetSuite has a Purchase Order transaction that turns into an Item Receipt and then a Vendor Bill. Infor SyteLine uses the Purchase Orders form with PO lines and PO receiving, and Infor LN uses purchase orders in the Procurement module with the order lines carrying planned and actual receipt dates. Odoo converts a request for quotation into a purchase order with one click.

A PO is usually created from a requisition, from a planned order that MRP converted, or directly by a buyer. Approval limits, supplier restrictions and price-list lookups are applied at this step, which is why PO controls are one of the first things auditors test.

Why It Matters

It is the contractual anchor for price and delivery terms, so disputes with suppliers are settled against the PO, not an email.
Open PO lines are scheduled supply in MRP, so wrong promise dates produce wrong shortage and expedite signals.
Receipts and invoices match against it, which makes the PO the control point for three-way match and payment.
Open PO value is a financial commitment, which feeds accruals and budget control before invoices arrive.

In Practice

A buyer orders 500 machined brackets at 14.20 each with a promise date of the 20th. The supplier confirms 300 on the 20th and 200 on the 27th. The buyer splits the line into two releases with their own dates. MRP now sees 300 arriving on the 20th and 200 on the 27th, and the shortage message for the work order due on the 24th correctly shows 200 short, instead of the whole 500 appearing on time.

Frequently Asked Questions

What is the difference between a purchase order and a purchase requisition?

A requisition is an internal request to buy something and usually needs approval. A purchase order is the external commitment sent to the supplier. Requisitions are converted into purchase orders.

Can a purchase order be changed after it is sent?

Yes, but most ERPs track it as a revision or change order, keep the history, and may re-trigger approval if the value rises. Changing price or quantity after receipts exist is usually restricted.

Is a purchase order a legal contract?

Generally it becomes a binding contract once the supplier accepts it, but enforceability depends on the terms and jurisdiction. Treat the PO and its referenced terms as the governing record and get legal advice for specifics.

Related Terms

Purchase Requisition

A purchase requisition is an internal request to procure goods or services, routed for approval against budget and authority limits before a buyer sources it and converts it into a purchase order sent to a supplier.

Three-Way Match

A three-way match is the accounts payable control that compares the purchase order, the goods receipt, and the supplier invoice on quantity and price before releasing payment, ensuring a company pays only for what it ordered and actually received.

MRP (Material Requirements Planning)

MRP (Material Requirements Planning) is the ERP calculation that explodes demand through bills of materials, nets it against on-hand and on-order inventory, and offsets by lead time to produce timed purchase and work order suggestions.

Lead Time

Lead time is the elapsed time between initiating an order and having the material available for use. In ERP it is the offset MRP applies when back-scheduling a planned order from its due date to its release date.

Landed Cost

Landed cost is the total cost of bringing purchased goods into inventory, combining the supplier price with freight, insurance, customs duty, tariffs, brokerage, and handling, so inventory is valued at what the material truly cost to acquire.

Working with Purchase Order (PO) in a live environment? Our engineers do this every day - and our AI agents automate most of it.

Talk to an Expert Browse the Full Glossary

Back to Glossary

Try it here, free

SyteLine Open Purchase Order Query Generator

Open full tool

Builds a read-only SQL query for open and late PO lines in SyteLine 9/10, with a second query for vendor on-time delivery from PO receipts.

Fill in

Site (site_ref)

The site_ref value of the site you are reporting on.

Vendor filter (LIKE pattern)

Use % for all vendors. Vendor numbers can be stored right-justified with leading spaces, so prefer a leading % (for example %V1001).

Buyer filter (LIKE pattern)

Warehouse filter (LIKE pattern)

Minimum days late

0 returns lines due today or earlier. Use -9999 to return every open line, including future due dates.

PO line statuses to include

Quoted, comma separated stat values. O = Ordered. Add 'P' to include planned lines.

Order by

On-time lookback (days)

Generated code

Free, optional. Reopen it on any device.

Download:

1. Open and late PO lines

-- Open and late purchase order lines, SyteLine 9/10 (run on a read-only login)
DECLARE @Site nvarchar(20) = N'MAIN';
DECLARE @DaysLate int = 0;

SELECT
    p.po_num,
    pi.po_line,
    pi.po_release,
    p.vend_num,
    va.name AS vendor_name,
    p.buyer,
    pi.whse,
    pi.item,
    pi.qty_ordered,
    pi.qty_received,
    pi.qty_ordered - pi.qty_received AS qty_open,
    pi.item_cost,
    (pi.qty_ordered - pi.qty_received) * pi.item_cost AS open_value,
    pi.due_date,
    DATEDIFF(day, pi.due_date, GETDATE()) AS days_late
FROM po_mst p
JOIN poitem_mst pi
    ON pi.site_ref = p.site_ref
   AND pi.po_num = p.po_num
JOIN vendaddr_mst va
    ON va.site_ref = p.site_ref
   AND va.vend_num = p.vend_num
WHERE p.site_ref = @Site
  AND pi.stat IN ('O')
  AND pi.qty_ordered > pi.qty_received
  AND p.vend_num LIKE N'%'
  AND ISNULL(p.buyer, N'') LIKE N'%'
  AND pi.whse LIKE N'%'
  AND DATEDIFF(day, pi.due_date, GETDATE()) >= @DaysLate
ORDER BY pi.due_date, p.vend_num;

2. Vendor on-time percentage from PO receipts

-- Receipt transactions (ref_type P, trans_type R) compared with the PO line due date
DECLARE @Site nvarchar(20) = N'MAIN';
DECLARE @Lookback int = 90;

SELECT
    p.vend_num,
    va.name AS vendor_name,
    COUNT(*) AS receipts,
    SUM(CASE WHEN CAST(m.trans_date AS date) <= CAST(pi.due_date AS date) THEN 1 ELSE 0 END) AS on_time_receipts,
    CAST(100.0 * SUM(CASE WHEN CAST(m.trans_date AS date) <= CAST(pi.due_date AS date) THEN 1 ELSE 0 END) / COUNT(*) AS decimal(5,1)) AS on_time_pct
FROM matltran_mst m
JOIN poitem_mst pi
    ON pi.site_ref = m.site_ref
   AND pi.po_num = m.ref_num
   AND pi.po_line = m.ref_line_suf
   AND pi.po_release = m.ref_release
JOIN po_mst p
    ON p.site_ref = pi.site_ref
   AND p.po_num = pi.po_num
JOIN vendaddr_mst va
    ON va.site_ref = p.site_ref
   AND va.vend_num = p.vend_num
WHERE m.site_ref = @Site
  AND m.ref_type = 'P'
  AND m.trans_type = 'R'
  AND m.qty > 0
  AND m.trans_date >= DATEADD(day, -@Lookback, GETDATE())
  AND p.vend_num LIKE N'%'
GROUP BY p.vend_num, va.name
ORDER BY on_time_pct, receipts DESC;

Verify on your SyteLine 9/10 database before relying on it: the stat values in use on poitem_mst (check against the PO line status list in your forms), and whether item_cost is in vendor currency for foreign vendors before summing open_value across vendors. Blanket POs carry due dates at release level, so read them by po_release. In a multi-site database every join must include site_ref. Run it on a reporting copy or a read-only login.