SD Pricing Conditions and Their Mapping to RAR

The SD pricing procedure is where the numbers of a customer contract are born: list prices, discounts, surcharges, freight, and cost. SAP Revenue Accounting and Reporting (RAR) reads those conditions to build the transaction price under ASC 606, to allocate it based on standalone selling prices (SSP), and to defer cost. Pricing procedures, however, were designed for invoicing, not for revenue accounting. Mapping them cleanly is one of the most underestimated parts of an SD-to-RAR design.

What RAR Does with SD Conditions

When an order item is transferred, its conditions travel with it. RAR treats them as follows:

• Pricing conditions are aggregated to determine the transaction price of the contract.

• Costing conditions are excluded. Each condition entry carries a pricing/costing attribute.

• Statistical conditions are excluded. Each entry carries a statistical attribute.

Excluded conditions are not added to the transaction price and are not allocated. That sounds simple, but it means that every condition in the procedure needs a conscious decision: is it part of the price the customer pays, information only, or cost?

The Main Price Condition

Each performance obligation needs exactly one pricing condition marked as main. RAR issues an error message when this is not the case. In practice, problems arise when:

• a pricing procedure uses alternative price conditions depending on the customer or channel;

• a manual price overrides the standard condition;

• an item has no price at all, for example a free-of-charge component in a bundle.

Define which condition is the main price for each pricing procedure and item category, and test every variant.

Standalone Selling Price: From SD or from BRFplus

ASC 606 requires the transaction price to be allocated to performance obligations on a relative SSP basis. RAR can take the SSP from an SD condition type that is assigned in Customizing, or from a BRFplus decision table.

Two points are worth knowing:

• Setting a price condition type such as PR00 as the SSP condition type can result in a transaction price of zero in RAR. Keep the main price and the SSP in separate condition types, and test the result.

• Inactive conditions, for example after an item is rejected, can cause errors for a missing main price condition or a missing SSP. Include these scenarios in your test cases.

The design question behind this is not technical: where does your SSP evidence live? If SSP is maintained as condition records in SD, sales owns the data, and pricing changes affect allocation. If SSP lives in BRFplus, finance owns it. For SOX purposes, the owner of SSP data should be the function that is accountable for the SSP policy.

Discounts and Allocation

Under ASC 606, a discount is allocated proportionally to all performance obligations based on relative SSP, unless specific criteria are met that allow allocating it to only some of them. RAR applies this through its allocation logic, not through the SD condition that carried the discount. Consequences for design:

• Header discounts and item discounts in SD both end up in the transaction price. Where they appear in the procedure matters less than whether they are pricing-relevant.

• If your policy allocates a discount to specific obligations, that exception needs to be configured in RAR and supported by evidence. It does not follow automatically from SD.

• Variable consideration, such as volume rebates, needs its own decision. Some rebate conditions are pricing-relevant in SD; whether and how they belong in the transaction price is an accounting judgment first.

Contractual Price Versus Allocated Price

RAR distinguishes the contractual price, which is the effective price of the obligation before allocation, from the allocated price, which drives recognized revenue. When a later invoice carries a different price than the order, the contractual price changes for the affected quantity, and RAR reallocates the transaction price. Price changes on the sales order after renegotiation also trigger reallocation automatically. Your pricing procedure should therefore deliver the same pricing-relevant conditions on order and invoice, or differences will cause reallocations nobody expected.

Cost Conditions

For cost recognition, RAR uses one main cost condition, typically VPRS. VPRS reads the cost from the material's valuation segment. RAR ignores additional cost conditions, except capitalized cost. Cost conditions are also not passed for BOM headers. Check that the cost you want to defer is the one that arrives.

A Practical Mapping Exercise

For each pricing procedure in scope, document:

• every condition type and whether it is pricing, statistical, or costing;

• the main price condition per item category;

• the SSP source and owner;

• discounts and their allocation policy;

• the main cost condition.

This table becomes your design document, your test basis, and your audit evidence.

Agentic Finance, Human-Governed

Comparing pricing procedures against RAR mapping rules is repetitive but error-prone. In our Agentic Finance approach, agents check new or changed condition types against the agreed mapping and flag gaps, while revenue accountants decide.

Related Articles

• From Sales Order to Revenue Contract: How SD Feeds SAP RAR

• Discounts in the Quote: How They Drive Revenue Allocation

• Standalone Selling Price (SSP): Methods and Common Mistakes

The Bottom Line

SD pricing feeds SAP RAR with the transaction price, the SSP, and the cost. Classify every condition, define one main price and one main cost condition, decide who owns SSP, and keep order and invoice pricing consistent. Then allocation under ASC 606 (and IFRS 15) reflects your policy instead of your pricing history.

Mapping SD pricing to SAP RAR? Talk to our experts.