SAP Concepts: SAP SD Explained: The Revenue Side

MM was about buying. SD is about selling.

In Episode 2 we walked through Materials Management — the master data, the procure-to-pay flow, the movement-type vocabulary, the valuation methods. Almost every concept in MM has a mirror on the revenue side, and that mirror is SD — Sales and Distribution, the SAP module that handles everything between a customer placing an order and that customer paying for what they got.

If MM and SD were perfectly symmetric, we’d be done in a paragraph. But they’re not. SD has one piece of machinery that MM doesn’t — the pricing procedure, also called the condition technique — and that piece of machinery is, by a wide margin, the most configurable, most-talked-about, most career-defining feature of any SAP installation. Pricing is what makes SD different.

This is episode three of Season 2 of SAP Concepts, and we’re going to walk into SD properly. What it stores, how the order-to-cash flow works, why pricing is a module unto itself, and what the rest of SD looks like at intro depth.

What SD is for

Start with the brief.

SD’s job is to convert customer demand into delivered goods, billed invoices, and received cash. Four stages, in order:

• Capture demand. A customer says they want something — through a quotation, a contract, a sales order, an electronic data interchange (EDI) message, or a marketplace integration. SD records the demand on a sales document.
• Promise delivery. Based on availability, lead times, and credit checks, SD commits to deliver — and the commitment is visible to the customer, the warehouse, the planner, and finance.
• Ship the goods. When materials are picked, packed, and dispatched, SD posts the delivery that triggers the inventory and accounting impact. Goods leave; the customer’s account starts to owe.
• Bill the customer. SD generates the invoice, which posts to FI, sets the receivables clock running, and waits for the customer to pay.

Every other piece of SD — the customer master, the sales document types, the pricing procedure, the credit management framework, the output determination — exists to make those four stages happen reliably across thousands of orders a day.

Hold the four stages in mind as we walk through the module. Each concept fits into one of them.

The Customer Master, now Business Partner

In ECC, the customer master was its own master record — table KNA1, transactions XD01/XD02/XD03, separate from the vendor master.

In S/4HANA, customer is a role on a Business Partner — same unification we covered in Season 1 episode 8. A company that’s both a customer and a supplier has one BP record with two roles attached. The mechanics underneath have been unified with the procurement side.

For day-to-day SD purposes, users still talk about “customers” and “customer codes.” Sales orders still reference a customer number. The system still works the way it did. But the master data is now reached through the Maintain Business Partner Fiori app, with a customer role that exposes the sales-relevant fields — payment terms, default delivery plant, ship-to addresses, sales-area assignments, credit limit.

A customer in SD lives at the intersection of three organisational dimensions:

• Sales Organisation — the legal entity that owns the sales activity.
• Distribution Channel — how the goods get to the customer (direct, retail, wholesale, online).
• Division — which product line or business unit is selling.

The combination of all three is called a sales area, and a customer is “extended to” each sales area it transacts in. Different terms can apply per sales area — same customer, different prices in different channels.

That structure feels overengineered the first time you meet it; it pays off once you have a multi-channel, multi-region business. Don’t fight it.

Sales Document Types

SD’s transactional records are sales documents, and like FI, every sales document is an immutable header-plus-line-items record.

Where SD differs is the document type. SAP ships a small alphabet of standard sales document types, and every shop adds its own variants. The handful you’ll meet in any SAP installation:

• OR — Standard Order. The bread and butter of SD. Customer orders something, you sell it, you ship it, you bill it.
• RE — Returns. The customer is sending something back. Inventory comes back in; you owe them a credit.
• CR — Credit Memo Request. “We owe the customer money” — usually because of a billing error or a goodwill adjustment.
• DR — Debit Memo Request. “The customer owes us more money” — usually because of an under-invoiced earlier transaction.
• G2 — Credit Memo. The follow-on document that posts the credit to FI.
• L2 — Debit Memo. The follow-on document that posts the debit to FI.
• QT — Quotation. “Here’s what it would cost.” No commitment yet — the prospect can convert it into an order later.
• CQ — Contract. A long-term agreement under which orders are created against agreed terms.
• SO — Scheduling Agreement. A long-term agreement with delivery schedules built in — common in automotive and contract manufacturing.

Every shop adds custom document types — ZOR for “standard order, our flavour,” ZSO for “consignment fill-up,” ZSD for “stock transfer to a customer location.” The configuration controls everything about how a document of that type behaves: which item categories are allowed, how delivery is determined, how billing is triggered, which pricing procedure applies, what’s printed on the output.

For the introductory map, just remember: when somebody says “OR” they mean a normal sales order, “RE” means a return, and “CR/DR” means an adjustment is being raised.

Order-to-Cash, revisited

Quickly recapping S1 Ep5 — order-to-cash is the SD-led business process:

Sales Order (SO) — created from a quotation, an EDI message, or directly. Carries the customer, materials, quantities, requested delivery date, and pricing. ATP (available-to-promise) checks confirm what can be delivered when.

Delivery (LF) — when the goods are ready to ship, a delivery is created and the warehouse picks, packs, and dispatches. Posting goods issue triggers the inventory and FI postings — inventory ↓, cost-of-goods-sold ↑.

Billing Document (F2) — when the goods have shipped (or sometimes before, depending on billing terms), an invoice is created. FI gets a posting — accounts receivable ↑, sales revenue ↑.

Customer Payment — eventually the customer pays. AR is cleared, cash is debited. This last step typically happens through FI’s automatic-payment programme on the inbound side — out of SD’s hands once the invoice is issued.

Every order-to-cash flow generates two or three FI postings — one for the goods issue, one for the invoice, one for the payment receipt. The bulk of revenue-side postings to FI come from SD.

For our purposes today, the part that matters most is what happens between order and invoice — because that’s where pricing does its work, and pricing is what makes SD distinctive.

The Pricing Procedure — the heart of SD

If you only learn one thing about SD, learn the pricing procedure.

Pricing in SAP is not a single field on a sales-order line. It’s a procedure — an ordered sequence of condition types, each of which contributes a value (a base price, a discount, a surcharge, a freight charge, a tax) to the line’s total. Each condition type has its own logic for how it’s calculated, who can override it, and which other conditions it depends on.

The mechanism is called the condition technique, and it shows up not just in SD pricing but anywhere SAP needs flexible, configurable, condition-based determination — output determination, account determination, free-goods determination. Once you understand it for pricing, you understand it everywhere.

The high-level shape:

• A condition type is one element of a price. Examples: PR00 for base price, K007 for customer-specific discount, MWST for tax, KF00 for freight.
• An access sequence is the lookup logic for finding the value of a condition type. “First try customer-and-material specific. Failing that, customer specific. Failing that, material specific. Failing that, region specific.” Each access reads a condition record from a configured table.
• A pricing procedure is the ordered list of condition types that apply to a sales-order line. The procedure is determined by the combination of sales area, customer pricing procedure, and document pricing procedure.
• A condition record is the actual data — “for customer 100123 buying material RM-100023, the price is €12.40 per square metre” — that the access sequence retrieves.

When a sales-order line is created, SAP runs the determined pricing procedure top to bottom. For each condition type, it runs the access sequence to find a record. It applies the value with whatever calculation logic the condition type defines (fixed amount, percentage of base, scale-based, gross-vs-net). The cumulative result is the line’s net value.

That sounds bureaucratic. In practice, it’s incredibly powerful — a typical SAP shop has dozens of condition types, often with custom logic for industry-specific rebates, complex discount stacking, channel-specific surcharges, or contract-based pricing. The pricing procedure is what lets the same software run a B2B contract manufacturer, a B2C retailer, and a wholesale distributor using different rules without forking the code.

We’re naming the pieces and pointing to where they live. Going one level deeper — actually configuring a pricing procedure or building condition records — is a multi-week subject of its own. Every shop has a senior SD configurator whose job is essentially “owns the pricing procedure,” and audit trails go back years on every condition record change.

Credit Management and Output Determination

Two more pieces sit alongside pricing in SD’s “things that happen automatically when an order is created” basket.

Credit Management. Before SAP commits to a sales order, it checks whether the customer is good for the money — open receivables plus the new order’s value against the customer’s credit limit. If the check fails, the order is blocked until somebody (a credit manager, a finance approver) releases it. In S/4HANA, credit management has moved into FSCM Credit Management (a more sophisticated framework than the classic SD credit checks). Same idea, more flexibility.

Output Determination. When a sales order is created, an order confirmation is sent to the customer. When a delivery is posted, a packing slip is printed at the warehouse. When an invoice is created, a PDF is emailed (or EDI’d, or printed). All of that is governed by output determination — another condition-technique-driven configuration that decides which output goes out, when, in what format, to whom, via what channel. Driver behind every “we need to send an EDI 856 to this customer when the goods ship” requirement.

Both are real. Both are configurable. Both are out of scope for an intro episode — we’re naming them so you know they exist and where they sit in the SD machinery.

The Star Screen — Manage Sales Orders

In S/4HANA, the canonical Fiori app for working with SD documents is Manage Sales Orders.

It’s a tile on the launchpad. Click it, you get a filterable list of orders by sales area, customer, document type, status, requested delivery date, value range. Click an order, you get the document — header up top (sold-to, ship-to, payment terms, requested date), then line items, then conditions (the pricing breakdown), then schedule lines (the delivery commitments), then partner functions (sold-to, ship-to, bill-to, payer), then output history.

The drill-down pattern from FI applies again. From any order, you can drill into the customer’s open-items list. From a line item, you can drill into the material master, the pricing procedure that was applied, the inventory availability, the related delivery, the related invoice, the FI posting that resulted. Same data underneath; vastly different feel from ECC’s VA01 / VA02 / VA03 / VL01N / VF01 chain.

The Fiori launchpad for a sales-area-aligned user pulls together: Manage Sales Orders, Manage Customer Returns, Create Outbound Delivery, Create Billing Document, Customer Balances, Sales Performance, plus a half-dozen analytical apps that read straight from ACDOCA. The analytics piece matters — because the universal journal is right there, the same screens that operate transactions can show profitability instantly.

For this episode, Manage Sales Orders with the pricing-conditions tab visible is the screen we’ll spend most time on. It shows everything we just talked about in one place.

What we’re deliberately not covering

SD has many more pieces:

• Variant Configuration. Configurable products — “this car, with these options, at this price.” Whole sub-module of its own.
• Pricing Procedures in detail. Configuring the procedure, building condition records, implementing custom condition types. We named the technique but didn’t go inside.
• Available-to-Promise (ATP) and advanced ATP. The promise-to-deliver logic, including S/4’s new aATP with backorder processing and arbitration.
• Free Goods Determination. “Buy two, get one free” — same condition technique, different application.
• Rebates and settlement management. Post-sale customer rebates and the settlement processes that pay them out.
• EDI integration. Inbound 850 (purchase order), 855 (PO acknowledgement), 856 (advance shipment notice), 810 (invoice). Real, important, configurable, beyond an intro.
• CRM integration. Many shops integrate SD with a CRM (SAP C4C, Salesforce, Dynamics) on the front end. Lead-to-order is a parallel flow that ends in SD.

If you work with SD day-to-day, you’ll meet all of these. SAP Help Portal documents each properly.

Why SD mirrors MM (and where it doesn’t)

Step back to the symmetry.

MM has materials and vendors; SD has materials (same masters!) and customers. MM has the procure-to-pay flow ending in an invoice from a supplier; SD has the order-to-cash flow ending in an invoice to a customer. MM has movement type 101 for goods receipt; SD has movement type 601 for goods issue (which we met in Episode 2). Both modules feed FI; both report through the universal journal in ACDOCA.

The mirror breaks at pricing. On the procurement side, the price of an incoming material is mostly fixed by the purchase order — the supplier quoted you a number, you negotiated, that’s the number. On the sales side, the price out the door is determined dynamically per customer per material per sales channel per quantity tier per promotional calendar — that complexity is what the pricing procedure solves. There’s no procurement-side equivalent because there’s no need for one.

Knowing how SD captures, prices, delivers, and bills sets up everything we’ll talk about in the rest of S2. PP next episode will produce the goods that SD ultimately ships. CO in the season finale will analyse profitability of the orders SD created — sliced by customer, by region, by product, by sales channel.

What’s next

That’s SD. Next episode we move from selling to making: PP — From Recipe to Reality. Bills of material, routings, work centres, the MRP run, planned and production orders — and the movement types from Episode 2 finally cashed in.