VA41 — Create Sales Contract
VA41 creates a sales contract in SD - a quantity contract, value contract, master contract, or service contract - that records a negotiated agreement with target quantities or values over a validity period. The contract itself triggers no delivery or billing; it only becomes active in logistics when a separate sales order is created against it and draws down the agreed quantity or value.
This page covers the VA41 create-contract transaction in SD order-to-cash: what it writes, how release orders consume it, and the recurring failure pattern where contracts exist correctly but never get drawn against, or release orders cannot find the contract they should be referencing. It also covers where responsibility for these gaps sits between functional configuration and master data.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,317 words
Purpose
VA41 creates a sales contract document - typically a quantity contract, value contract, master contract, or service contract, depending on the contract type assigned. The header carries a validity period and, for quantity or value contracts, a target quantity or target value that the contract is meant to be consumed against over time. The structural fact that causes most confusion: a contract is a framework, not a transaction that moves goods or generates revenue. Nothing in VA41 itself creates a delivery or a billing document. Consumption only happens when someone creates a standard sales order (a release order) that references the contract number, and that release order carries its own delivery and billing flow. A contract with a target value sitting untouched in the system is normal, not broken, until release orders start pointing at it.
When it is used
VA41 is used when the business has negotiated a framework agreement with a customer - an annual quantity commitment, a value-based rebate arrangement, a maintenance/service agreement, or an umbrella master contract that groups several sub-contracts under shared terms. It sits upstream of the standard order-to-cash flow: sales rep or contract administrator creates the contract once, then operational users create release orders (VA01) throughout the validity period that reference it. Reach for VA41 instead of VA01 when the requirement is tracking cumulative consumption against a ceiling, not processing an individual delivery. Reach for a scheduling agreement instead when the relationship is delivery-schedule driven with JIT or forecast releases rather than a value/quantity ceiling. Fiori equivalents exist for contract management but the underlying document type and logic are the same.
How to use it in practice
- Start VA41 and enter the contract type (quantity contract, value contract, master contract, or service contract) along with sales organization, distribution channel, and division.
- Enter the sold-to party; system pulls partner and pricing defaults from the customer master.
- On the header validity screen, set the contract start and end dates - this drives whether release orders can reference it later.
- For quantity or value contracts, enter the target quantity or target value at header or item level as required.
- Add line items with material and target quantity for quantity contracts; value contracts may carry a generic item instead of specific materials.
- Check the contract data tab (cancellation procedure, cancellation quantity/value) if the business requires early termination rules.
- Save. The contract number is generated and is now available for release orders to reference.
Key data objects
- VBAK - contract header: document type, sales area, validity dates reference, overall status.
- VBAP - contract item: material, target quantity, item category, plant.
- VBKD - business data at header and item level: validity dates, terms of payment, incoterms for the contract.
- VEDA - contract-specific data: target value, consumed value/quantity, cancellation procedure and quantity, validity start/end used for release-order eligibility checks.
- VBFA - document flow: links the contract number as the preceding document to every release order created against it, which is the primary evidence of consumption.
How to prove it in the data
Pull the contract from VBAK filtering on document category for outline agreements and the specific contract type; note the VBELN. Look up VEDA on that VBELN to see target quantity/value versus what has been consumed and the validity window. Then query VBFA with VBELV equal to the contract number and a preceding-document category for contracts, to list every release order created against it; sum the item quantities in VBAP for those release order numbers and compare to the target in VEDA to confirm whether consumption is tracking as expected.
ECC vs S/4HANA
VA41 remains fully functional on S/4HANA and continues to write to the same underlying tables. Fiori apps for managing sales contracts exist for certain contract scenarios and give a worklist-style view, but they sit on top of the same document type and copy control logic described here rather than replacing it. Consultants troubleshooting a contract issue on S/4HANA still end up in the same VBAK/VBAP/VEDA/VBFA chain regardless of whether the contract was created via VA41 or a Fiori app.
Common pitfalls and how to diagnose them
- Contract exists but nothing consumes it: business complains a value contract shows no revenue movement. Check VBFA for the contract number - if no subsequent documents exist, no release order has ever referenced it. This is a process gap, not a system error; confirm whether operational users know the contract number and are supposed to be using it.
- Release order cannot find the contract: the customer creating a sales order gets no proposal or an error when trying to reference the contract. Check the contract validity dates in VEDA first - an expired contract will not be offered. Then check copy control between the release order type and the contract type; a missing or misconfigured copy control entry blocks the reference even with valid dates. Also confirm the sold-to on the order matches the sold-to on the contract, or that the contract's customer hierarchy permits a different ordering party.
- Consumed value or quantity not updating: VEDA's running total looks stale after release orders are created. Check whether those release orders were fully saved and not stuck in an incomplete status, and whether a cancelled or rejected release order properly reversed its consumption - reversal logic depends on correct item category and copy control settings, not automatic.
- Wrong contract type chosen at creation: master contracts carry no target quantity fields by design, since they exist to hold shared header conditions for several sub-contracts. If a user expects a target-quantity field on a master contract and it is missing, this is expected behavior for that type, not a bug - the fix is choosing the correct contract type, not customizing the screen.
- Pricing not inherited by the release order: price agreed at contract level does not appear on the release order. Check the pricing type in the copy control between contract and order type; a pricing type that repeats pricing from scratch will ignore the contract's condition records instead of copying them forward.
- Cancellation blocked: contract cannot be closed or a quantity cannot be reduced because the cancellation procedure in VEDA enforces a minimum notice period or quantity threshold. This is a configured business rule, not a technical block, and needs a business decision before any config change.
Whose problem this is
This is functional SD territory - contract type configuration, copy control between contract and order types, and cancellation procedure setup are all SD customizing. Pricing inheritance issues cross into pricing/condition technique ownership. A good handover includes the contract number, contract type, validity dates, the release order number (if one is involved), and whether the issue is 'contract not found by order' versus 'consumption not updating' - these point to different config areas and save the next person a repeat investigation.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/va41ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.