ME31K — Create Outline Purchase Agreement (Contract)
ME31K creates a purchasing contract, the outline agreement type that carries a value or quantity target and pricing terms but no delivery dates. It is not a purchase order and creates no commitment or goods movement by itself. Buyers reference it later from a purchase requisition or purchase order through source determination, and consumption is tracked against the contract's release documentation.
ME31K is the transaction for creating a purchasing contract, one of the two outline agreement types in MM alongside scheduling agreements. The page covers the structural distinction between a contract and a PO, the release order versus centrally agreed contract split, and the most common reasons a contract silently fails to be found or fails to release correctly.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,150 words
Purpose
ME31K creates an outline purchase agreement of category 'contract', either a quantity contract or a value contract. A contract fixes commercial terms - price, conditions, validity period, target quantity or target value - with a vendor for a material or material group, without committing to specific delivery dates or quantities. The structural fact that causes most confusion: a contract is not a stock transaction and touches no inventory or accounting document at creation. It only becomes operationally relevant when a release order (a PO with document type referencing the contract) or a scheduling line draws against it. Two contract subtypes exist - 'centrally agreed contract' (no release documentation required, any plant can order) and standard release-order contract (release documentation tracks consumption against the target). Getting these confused is the single biggest source of 'why isn't my contract updating' tickets.
When it is used
Contracts sit upstream of the operational purchase order, typically negotiated by strategic procurement or category management as an annual or multi-year agreement, then consumed by operational buyers who never touch ME31K themselves - they just create POs that reference it. A consultant reaches for ME31K when setting up a new negotiated agreement, when migrating legacy long-term agreements into SAP, or when troubleshooting why a PO is not picking up contract pricing. In S/4HANA the equivalent Fiori app exists for contract creation in the redesigned UI, but the underlying document category and logic are unchanged, so ME31K remains the fastest tool for diagnostic work even in shops that have moved buyers to Fiori.
How to use it in practice
- Start ME31K and enter the vendor, contract type (value contract MK or quantity contract WK, or client-specific variant), and purchasing organization / group / plant.
- On the header, set validity start and end dates - a contract with no valid validity window will not be found by source determination.
- Enter target quantity or target value depending on contract type; leave blank only if genuinely open-ended and confirm that is intended.
- Add item lines: material or material group, target quantity/value, net price and any scale pricing.
- Check the 'Contract release documentation' indicator on the item - this decides whether consumption tracking (release order history) is active.
- Maintain conditions (discounts, freight, taxes) at header or item level as required by the negotiated terms.
- Save. Note the resulting contract number for use in ME57/ME58 source assignment or as an info record reference.
Key data objects
- EKKO - contract header: document category (contract), vendor, purchasing organization, validity dates, currency.
- EKPO - contract item: material, plant, target quantity, target value, price, release documentation indicator.
- EKKN - account assignment lines if the contract item carries account assignment (rare for pure contracts, more common on value contracts tied to cost objects).
- KONV/KONP - condition records generated for the contract's pricing when conditions are maintained at item level.
- EKAB - release order documentation records, populated only when release documentation is active and a referencing PO is created against the contract.
How to prove it in the data
In SE16 on EKKO, filter on document category equal to the contract category and vendor to confirm the contract exists and check validity dates against today's date. Cross-check EKPO for the item's target quantity, target value, and release documentation indicator. If a PO is failing to consume the contract, pull EKAB filtered on the contract number and item to see what has actually been released so far, and compare the cumulative released quantity or value there against the target in EKPO - a target already exhausted explains a hard block on further release orders.
ECC vs S/4HANA
The document category, header and item structure, and release documentation logic are unchanged in S/4HANA. The transaction ME31K itself still works. A Fiori app for managing purchase contracts exists for buyers who work exclusively in the Fiori UI, but it operates on the same underlying tables and does not add new contract concepts. No structural rewrite occurred for this object.
Common pitfalls and how to diagnose them
- Validity window mismatch: source determination finds nothing because the contract's validity end date has passed or the requisition/PO date falls outside the window. Check EKKO validity dates first before assuming a master data or condition problem.
- Release documentation confusion: a buyer expects the contract's cumulative quantity to update automatically but the item was created without the release documentation indicator, so EKAB never gets written and the contract looks static. This is a design decision made at ME31K creation time and cannot always be toggled retroactively without side effects.
- Target exhausted, no hard stop expected: value or quantity contracts can be configured to warn or to block once the target is reached. A PO rejection at ME58 or ME21N referencing 'target quantity exceeded' traces back to the target field on EKPO, not to a PO-side error.
- Plant scoping: centrally agreed contracts are visible to all plants, but standard contracts may be restricted by the plant entered on the item, so a plant not listed cannot draw against it even though the contract exists and is valid.
- Pricing not inherited: conditions maintained only at header level are sometimes expected to cascade to items automatically; if item-level conditions are missing, PO pricing falls back to info record or manual entry instead of the negotiated contract price.
- Wrong contract type for the need: a value contract used where a quantity contract was intended (or vice versa) produces target-tracking behavior that does not match what the business expects, and this is a creation-time error that surfaces only weeks later during consumption.
Whose problem this is
Functional MM/procurement territory, usually owned by strategic sourcing or category management rather than operational buyers. A handover to ABAP/Basis is only needed if the issue is a custom pricing routine, a custom release strategy workflow, or a performance problem on large-volume EKAB lookups - otherwise this stays with the functional purchasing team.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/me31kERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.