SAP Procurement

• Purchase Requisition: an internal request to buy.
• Purchase Order: the formal order to a vendor.
• Goods Receipt: receiving the goods (updates stock and GR/IR).
• Invoice Verification: matching the invoice to PO and receipt.
• Payment: paying the vendor (FI-AP).

Procurement covers stock materials (into inventory), consumables (directly to a cost center/order), services, and subcontracting/special procurement. The process and account determination differ by type, so understanding which applies is important.

Every document in the cycle has its own transaction and its own table pair, and they line up neatly once you see them together.

A purchase requisition is ME51N to create and ME53N to display, stored in EBAN. A purchase order is ME21N, ME22N and ME23N, stored in EKKO for the header and EKPO for the items. Release, which is SAP's word for approval, is ME29N for a single document and ME28 for a list. Goods receipt is MIGO and invoice receipt is MIRO.

The table that answers most questions is EKBE, the purchase order history. It holds every goods receipt and invoice posted against each line, which is how you see at a glance whether a line is fully received, partially invoiced or untouched. MMBE shows stock, and ME2M and ME2L list open orders by material or vendor.

Configuration sits under Materials Management in SPRO, and the two organisational units that drive it are the purchasing organisation and the purchasing group.

Half an hour on a practice system, and it is the exercise most MM interviews are really asking about.

1. Raise a requisition with ME51N for a stock material, one line, a quantity and a delivery date. No commitment exists yet: a requisition is an internal request.
2. Convert it with ME21N, referencing the requisition rather than typing the line again. Note that the price came from somewhere, usually an info record or a contract.
3. If a release strategy applies, release it with ME29N. Until then the order cannot be received against. See release strategies for how that is configured.
4. Receive with MIGO, movement type 101, against the order. Stock rises, and an accounting document appears because inventory has value.
5. Post the invoice with MIRO. The three-way match compares order, receipt and invoice, and blocks for payment when they disagree.
6. Open ME23N and read the purchase order history tab. The whole story is on one screen.

Procurement integrates with inventory (stock updates), FI (liabilities and inventory value), and CO (consumables to cost objects). Controls like release strategies (approval workflows) and the three-way match (PO, receipt, invoice) ensure spend is authorised and correct.

The field that decides where the cost lands is the account assignment category on the purchase order line. Blank means the material goes into stock and is valued there. K sends it to a cost centre, so it is an expense the moment it is received. F sends it to an internal order, and P to a project. Choosing the wrong one is the most common cause of a posting arriving somewhere finance did not expect, and it is corrected in procurement rather than in FI. See SAP MM inventory for what happens to stock afterwards.

• Stock or consumable. This is the account assignment decision above, and it should follow how the business actually uses the item rather than how it is easiest to order.
• Where the release strategy sits. On requisitions, on orders, or both. Approving the requisition catches spend before it is committed, which is usually the right place.
• Contracts and scheduling agreements or standalone orders. Repeated buying from one vendor belongs on an agreement, so the price and terms are agreed once.
• Goods receipt based invoice verification. Switching it on forces the invoice to match a specific receipt rather than the order as a whole, which is stricter and catches more.

Beyond buying stock and buying consumables, three patterns come up constantly and each behaves differently enough to be worth knowing by name.

Subcontracting. You send components to a vendor, who returns a finished item. The purchase order carries the components as a bill of material, the stock sits at the vendor while it is being worked on, and it is still yours. The value stays on your balance sheet throughout, which is the point people miss.

Consignment. The vendor's stock sits in your warehouse and stays the vendor's until you consume it. There is no goods receipt posting to a payable, because nothing has been bought yet. Settlement happens periodically against what was actually used, which is why consignment stock has its own stock type and its own settlement run.

Third party. The vendor ships directly to your customer and the goods never touch your warehouse. A sales order creates a requisition, the requisition becomes a purchase order, and the vendor delivers. Billing your customer and being invoiced by the vendor are linked through the order rather than through a delivery.

Each of these is a normal purchase order with a different item category, and that field is the thing to look at first when a procurement flow behaves in a way the standard cycle does not explain. See SAP MM for how they sit alongside the standard flow.

People are often surprised that a purchase order arrives with a price already in it. That comes from the purchasing info record, which holds the agreed price and terms for one material from one vendor.

The order of preference is worth knowing. A contract or scheduling agreement wins, because it is a negotiated commitment. Failing that, the info record supplies the price. Failing that, the last purchase order for the same combination may be proposed. Failing all of it, somebody types a number, and that is where uncontrolled spend begins.

The practical consequence: when a buyer complains that prices keep drifting, the answer is nearly always that no info record or contract exists, so every order is a fresh negotiation carried out by whoever raised it. Creating the record fixes the drift at source and makes invoice matching meaningful, because there is now an agreed price to match against.

• Skipping the three-way match control.
• Wrong procurement type, incorrect postings.
• No release strategy on high-value POs.

• Blaming the invoice for a price difference. If no info record exists, the order price was typed by hand, and the invoice is right.
• Tolerances set so wide that the three-way match never blocks anything.
• Deleting a purchase order line that has history. Read EKBE first.

Vendors are Business Partners, maintained with BP. Material documents moved to MATDOC, so reports that read the older header and item tables need rewriting. The classic transactions still work, and alongside them Fiori apps cover the same ground for requisitioners and approvers who never open SAP GUI. See SAP master data for the Business Partner change in full.

Running the cycle is the easy half, and configuring the release strategy and account determination that made it behave is the part you do in the course.

One more habit worth forming early: whenever a procurement question arrives, open ME23N and read the purchase order history before forming a theory. The document tells you what actually happened, and it is right more often than the person reporting the problem.