SAP SD explained: sales in SAP

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026

SAP SD (Sales and Distribution), called Sales on S/4HANA, is the area that runs order to cash: quotations and sales orders, the price on each line, the deliveries that ship against them, and the billing documents whose revenue and receivables post into Finance.

How is the sales area structured?

As three keys combined — sales organisation, distribution channel, division — which almost every determination in the area reads, and which is agreed in the first workshop because unpicking it later means re-creating master data. Under it sit the document types: standard order (OR in the standard delivery), rush order, cash sale, returns (RE), credit and debit memo requests, contracts and scheduling agreements.

How does copy control work, and what decides each line?

Copy control is the rule set that says which document may be created from which, and what is copied across; below the header, it works alongside two other determinations that do the quiet work.

The item category

Found from the document type and the item category group on the material, it decides whether the line is priced, whether it is relevant for delivery and for billing, and whether it is a free good or a text.

The schedule line category

It decides the movement type the goods issue will use and whether the requirement is passed on to planning at all, which is how an order can exist and still be invisible to the planners.

Copy control

It decides what a document may become next, field by field: order to delivery, delivery to invoice, invoice to credit memo. When a business says it cannot bill something, the cause is usually a copying requirement here rather than anything in the order.

How does the condition technique price an order?

By trying a list of lookups in a fixed order and stopping at the first hit. A condition table defines the key a price can be stored against (customer and material, price list and material, material alone); an access sequence puts several tables in priority order; a condition type uses one access sequence and adds behaviour — percentage or fixed amount, scales, whether it may be changed by hand; and the pricing procedure lists the condition types in sequence with subtotals, requirements and calculation rules.

The pricing procedure is determined from the sales area plus the document pricing procedure on the order type and the customer pricing procedure on the business partner, which is the mechanism behind "why does this customer price differently" — and why a business partner created with the wrong value is a master data governance problem before it is a pricing one. When a price looks wrong, the pricing analysis on the line shows every access the system attempted, with the key it used and why it missed, and reading that screen fluently is the single most useful skill in the area. Subtotals carried out of the procedure are also what profitability reporting reads, so a pricing procedure is a margin design as well as a price one.

How does the availability check confirm a delivery date?

It confirms a line for the requested date only if the stock and receipts its checking rule counts will cover it, and that scope is configurable to an uncomfortable degree: which stock types count, whether goods in transit and planned receipts count, whether the replenishment lead time is included. Two customers arguing about a confirmed date are usually arguing about a checking rule nobody has read in years.

Advanced ATP sits beside the basic check on S/4HANA as a separately licensed option, and adds the parts businesses always wanted: product allocation to ration scarce stock by customer or region, backorder processing that re-decides confirmations by priority instead of by whoever ordered first, and alternative-based confirmation offering another plant. It also moved the conversation from configuration to policy, because somebody senior now has to state, in writing, which customers lose their stock when supply is short.

How does credit management block an order?

It compares the customer's exposure with a credit limit for a credit segment, using a risk class, and blocks the document when the check fails — a different question from availability: not whether the goods exist, but whether this customer should get them. The check can be placed at order creation, at delivery creation or at goods issue — three different moments, three different people inconvenienced.

The design work is mostly about the release path. A blocked order sits in a list somebody must work, and if that list has no owner the warehouse finds out at picking. On S/4HANA the check sits in credit management on the finance side rather than in the sales configuration, so the rule and the release authority belong to finance while the visible consequence belongs to sales, which is exactly the kind of split that needs to be agreed in a workshop rather than discovered in hypercare.

What happens at delivery and goods issue?

The order becomes an outbound delivery that is picked, packed and then goods-issued, the posting that reduces stock and books cost of sales. Shipping point determination reads the shipping condition from the customer, the loading group from the material and the delivering plant; route determination adds the transit time that moves the dates. Picking hands over to warehouse execution, packing builds handling units, and goods issue does both postings in a single step.

Deliveries are also where a sales consultant learns humility about grouping. Whether two orders combine into one delivery depends on matching ship-to, shipping point, route and dates, and every business believes its own combination rules are obvious until they are written down.

Why does a billing document split?

Because the system splits whenever a header field differs between the items being combined — payer, payment terms, billing date, sometimes a field a data transfer routine copied for no good reason. Billing runs from a due list rather than one document at a time, so explaining a split is a weekly conversation in hypercare.

Revenue account determination then resolves the account from the chart of accounts, the sales organisation and the account assignment groups on the customer and the material, so a new material group with no assignment blocks the release to accounting. Billing plans handle periodic and milestone invoicing; invoice lists collect invoices for one payer. Output determination decides what leaves the system: in ECC through the same condition technique as pricing, in S/4HANA output management through BRFplus decision rules maintained in OPD, with the older technique still available. The result is a printed invoice, a PDF by email, or an electronic invoice message an integration consultant maps for the customer's own system.

How are returns and rebates handled?

By running the chain backwards: a returns order can be created with reference to the invoice, receives the goods into a returns stock, and produces a credit memo whose value has to match what the customer was actually charged, which is a pricing problem more than a logistics one. Advanced returns management adds inspection and follow-up decisions for businesses where returns are a real volume rather than an exception; an item repaired rather than credited becomes repair work handled in SAP Service.

Retrospective agreements moved as well: the classic rebate agreement gave way to condition contract settlement, which uses the same condition technique but settles from a contract rather than from an agreement hanging off the billing document. Anybody whose experience predates that change should say so plainly rather than let an interviewer discover it.

Who moves into SD, and how are they tested?

Order desks, customer service and sales operations people convert most naturally, followed by key users (the key-user route) and developers who have written pricing routines and order user exits. The interview test is nearly always one shape: take an invoice and walk it back to the order, naming the delivery, the goods issue, the accounting document and the condition records on the way. The SD interview guide runs those scenarios; with order capture drifting into CX front ends, saying which system owns pricing is part of the answer.