SAP Purchase Order: The Complete Guide

The purchase order is the point at which an internal intention becomes an external commitment, and in SAP it is also the anchor that goods receipt, invoice verification and reporting all attach themselves to. Understanding how it is built, how it is approved and how it behaves once it is live explains most of what people find confusing about purchasing in SAP. This guide walks through the document at a conceptual level, from its structure to the problems it most often creates.

What a purchase order actually is in SAP

Outside any particular system, a purchase order is a buyer's offer to a supplier setting out what is wanted, how much of it, when it is needed and at what price. Once the supplier accepts, it becomes a contract. That definition holds in SAP, but the document does considerably more work than a piece of paper would.

Inside SAP the order is a live object with obligations attached to it. It creates a commitment against a budget where commitment accounting is used, tells materials planning that a supply is expected on a given date, and defines what a warehouse may receive and what accounts payable may pay. It also accumulates a history, so months later you can see what was ordered, what arrived, what was invoiced and what changed.

A note before going further. SAP releases and implementations differ, and every landscape is configured to its own design. The concepts and terminology below are the ones commonly documented, but exact behaviour and available options depend on your release and configuration, so confirm specifics against the SAP documentation for the version you actually run.

The anatomy of the purchase order document

The single most useful mental model is that the order is built in layers, and each layer answers a different question. Once you know which layer holds which information, most confusion about where to look or why a field cannot be changed resolves itself.

The header applies to everything below it, which is why supplier and payment terms cannot vary by line. Items are independent, so one order can mix stock and expense purchases across plants. Schedule lines only matter when a quantity arrives in stages, but where they are used they become the reference point for planning and receipt rather than the item total.

Account assignment sits slightly apart because it is where purchasing hands over to finance. Rather than listing every possible category, it helps to think in terms of what is consuming the purchase.

Document types and what they control

Every purchase order carries a document type, and that type is not a label. It governs number ranges, which item categories and account assignments are permitted, which fields are mandatory or hidden, whether the document can be created without a requisition, and often which release strategy applies. Two orders that look identical on screen can behave completely differently because their types allow different things.

Implementations typically distinguish a normal order for ordinary goods, a service order for work confirmed through entry sheets rather than counted at a loading bay, subcontracting and consignment variants where material ownership is unusual, and framework arrangements where a value limit is agreed once and drawn against over a period. Outline agreements sit alongside these as the sources that ordinary orders are released from.

Creating an order from a requisition or an RFQ

Purchase orders can be created directly, but in a controlled environment most of them originate elsewhere. The two common routes are conversion from a purchase requisition and conversion from a quotation obtained through a request for quotation.

The requisition route starts with an internal request describing a need. Once a source of supply is determined, whether from a source list, an existing agreement or a purchasing info record, the requisition can be converted into an order. Conversion carries forward the material, quantity, delivery date, plant and account assignment, so the buyer confirms and completes rather than retypes, and the link between the two documents survives so a requester can see what happened to their request.

The quotation route applies where no agreed source or price exists. A request for quotation goes out to several suppliers, their responses are recorded as quotations and compared, one is selected, and the order is created from it with the quoted conditions attached. This is slower and it should be, because it is how competitive pricing enters the system in the first place. Our general purchase order guide covers the same decisions without the SAP specifics if you want the process view.

Automatic creation is also possible where an agreement already fixes the terms and the only variable is timing. Materials planning can propose orders against a scheduling agreement, and requisitions flagged as automatically convertible can become orders without a buyer touching them, which is efficient precisely because the commercial decision was already made upstream.

Release strategies: how approval works

Approval in SAP purchasing is handled through release strategies rather than through a simple manager hierarchy. When a document is created it is evaluated against a set of characteristics such as total value, purchasing group, plant, material group or document type. If it matches a defined strategy, the document is held until the release codes attached to that strategy have been applied, in sequence where a sequence is defined. Until then it cannot be issued to the supplier.

Two properties of this design catch people out. The strategy is chosen by the data on the document, so changing a value or a purchasing group after creation can move the document to a different strategy or reset releases already granted. And release is a property of the document, not a message in someone's inbox: workflow can notify approvers, but the block itself lives on the order.

A common design question is whether to release at requisition level, order level or both. Releasing the requisition approves the intention to spend before a buyer invests effort in sourcing. Releasing the order approves the actual commitment including the negotiated price. Many organisations do both, with a lighter touch on the second, and the trade-off between control and cycle time is discussed further in our SAP P2P guide.

Goods receipt and invoice verification against the order

Once the order is with the supplier, it becomes the reference document for everything that follows. Goods receipt records what physically arrived against the ordered quantity, posts the stock or consumption, and creates the accounting entry recognising the liability. For services, an entry sheet records what was performed and is accepted before it counts as received.

Invoice verification then compares the supplier's invoice against the order and the receipt. Where all three agree within tolerance, the invoice posts and becomes payable. Where they do not, it is blocked. This three-way match is the core financial control of purchasing, and it is only as good as the discipline behind it: an order with a stale price, or a receipt nobody posted, will produce a block that has nothing to do with the supplier.

Order history and change documents

Every receipt, service entry, invoice and credit posted against an order accumulates in its history, and that history is the fastest place to answer the question people ask most often: where is my order. It shows what has been delivered, what remains open, what has been invoiced and what value has been settled, all in one place and all tied to the specific line item.

Alongside the history, SAP records amendments as change documents. When a quantity, price, delivery date or account assignment is altered, the old and new values are retained with the user and timestamp. That explains why a document no longer looks the way someone remembers, and it means an order cannot be quietly rewritten to match an invoice that arrived, which is a pattern auditors look for.

Getting the order to the supplier

A released order still has to reach the supplier, and that is handled by output determination. Depending on configuration, the same document can be printed, emailed as a document attachment, transmitted through electronic data interchange, or sent through an integration to a supplier portal. The medium, the recipient and the timing are all driven by condition records rather than decided by the buyer at the moment of sending.

Output is also repeatable. When an order is changed, a change message can be generated so the supplier receives the amendment rather than a fresh order they might fulfil twice. It is worth confirming how your system handles change output before assuming it is safe.

Common problems and how to think about them

The same handful of issues account for most of the frustration around purchase orders in SAP, and each has a characteristic cause.

• Blocked invoices. The invoice disagrees with the order or the receipt beyond tolerance. Before chasing the supplier, check which of the three documents is actually wrong, because in a large share of cases it is the order carrying an outdated price.
• Price variances. Usually the info record or agreement was not updated after a renegotiation, so orders were raised at the old condition. Fixing the invoice clears one symptom; fixing the source data prevents the next fifty.
• Missing goods receipt. The goods arrived but nobody posted the receipt, often because the delivery went to a site that treats receipting as optional. This is a process discipline problem that looks like a system problem.
• Orders stuck in release. An approver has left, a strategy references a structure that no longer exists, or a change reset the releases. Reviewing release strategies annually catches most of these before they cause delay.
• Open orders that never close. Small residual quantities and cancelled requirements leave lines permanently open, distorting commitment reporting. A periodic review with delivery completed indicators applied is unglamorous and very effective.

None of these are exotic faults in the software. Systems built by SAP SE handle purchase orders reliably; what varies is the quality of the data feeding them and the habits of the people working around them. That is broadly true of any full enterprise resource planning platform, where the process is only ever as sound as the master data underneath it.

If purchase orders are causing pain, resist the instinct to reconfigure first. Measure instead: what proportion of invoices match first time, how many orders sit unreleased for days, how many are raised after the invoice has already arrived. Those three numbers point at the real problem faster than any workshop, and they nearly always send you upstream, because an order is only ever as good as the requisition, the source and the price behind it.

ProcureWave is designed for the layer above the back office, giving requesters a clear place to ask, buyers a single view of sources and agreements, and finance a matched invoice at the end, whatever runs underneath. If you would like to see how that sits alongside an existing SAP landscape, have a look at what the platform covers or get in touch and we will talk it through with you.

Frequently asked questions

What is a purchase order in SAP?

It is the formal document that commits your organisation to buy specified goods or services from a supplier on agreed terms. In SAP it is more than a form: it carries organisational data, one or more line items with quantities and delivery dates, an account assignment that tells finance where the value belongs, and a history that records every receipt, invoice and change made against it.

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

A requisition is an internal request that something should be bought. It has no legal standing outside the business and is not sent anywhere. A purchase order is the external commitment issued to a supplier. Requisitions are commonly converted into orders once a source and a price are known, which carries the request details forward and keeps the link between the two documents. The wider flow is covered in our P2P cycle in SAP guide.

What are schedule lines on an SAP purchase order?

Schedule lines break a single item quantity into separate delivery dates. One line item for twelve hundred units can be scheduled as one hundred per month, so the supplier sees a phased requirement and planning sees the correct expected date for each tranche. Goods receipts are matched back against those schedules rather than against the item total.

Why is my invoice blocked against a purchase order?

Usually because one of the three matched documents disagrees with the others beyond the tolerance your system allows. Common causes are a price on the invoice that differs from the order, a quantity invoiced that exceeds what was received, a goods receipt that has not been posted yet, or a tax code mismatch. The block is a control working as intended; the fix is to find which of the three documents is wrong.

Can a purchase order be changed after it is sent?

In most configurations yes, subject to authorisation and to whether receipts or invoices already exist against it. SAP records amendments as change documents, so the original values and the person who altered them remain visible, and depending on the setup a changed order may need to be released again and reissued to the supplier.