What is SAP SD?

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 24, 2026 · 11 min read

1) What SD Covers#

SAP Sales and Distribution (SD) is the module of SAP ERP and SAP S/4HANA that manages every step from receiving a customer’s order to collecting payment. It is organized around the order-to-cash (O2C) cycle: pre-sales activities → sales order → outbound delivery → goods issue → billing → cash receipt.

The module is formally divided into the sub-modules SD-MD (Master Data), SD-SLS (Sales), SD-SHP (Shipping), SD-BIL (Billing), SD-TBA (Transportation), SD-CAS (Sales Support), and SD-FTT (Foreign Trade). In practice, requirements definition projects focus most heavily on five functional domains.

Sales Order Management#

The sales order is the central document of SD. Every order has a three-level structure:

• Header — sold-to party, overall pricing, order date, requested delivery date, payment terms, incoterms
• Items — each material or service with its quantity, plant, and item category
• Schedule Lines — the delivery date and confirmed quantity for each item, plus the link to MRP/ATP

Order types define document behavior. Standard delivery-based orders use type OR. Returns use RE. Credit memo requests use KR and debit memo requests use DR. Rush orders (RO) and cash sales (CS) have streamlined delivery flows. Quotations (QT) and inquiries (IN) are pre-sales documents that feed into order creation via copy control.

Item categories control what happens at the item level. TAN is the standard deliverable item; TANN is a free-of-charge item that triggers delivery but no billing. TAB routes a third-party order to an external vendor via a purchase requisition. TAK is a make-to-order item that ties the production order to the sales order via a special stock indicator. Item categories are determined automatically from the sales document type + item category group on the material master, with manual override allowed.

Schedule line categories (e.g., CP for standard purchasing, CN for no planning) determine whether a transfer of requirements flows to MRP and which inventory movement type is used at goods issue.

Availability to Promise (ATP) is checked at the schedule line level. The system reads unrestricted stock plus scheduled receipts against demand, using a checking rule that defines the scope of the check (stock only, purchase orders included, production orders included, etc.). In S/4HANA, advanced ATP (aATP) extends this with product substitution, multilevel ATP, and capable-to-promise capabilities.

Pricing#

SD pricing is governed by the condition technique — a four-layer rules engine:

1. Condition Table — defines the key fields for storing a condition record (e.g., Sales Organization + Customer + Material stores a customer-specific price).
2. Access Sequence — defines the search path across condition tables in priority order. The system reads the first table that returns a valid record and (by default) stops.
3. Condition Type — defines the nature of a pricing element: PR00 (base price), K007 (customer discount in %), RA01 (header discount), MWST (tax), VPRS (internal cost). Each condition type specifies whether manual entry is allowed, whether it is mandatory, and how it calculates (percentage, fixed amount, quantity-based).
4. Pricing Procedure — the master list of condition types with step numbers, From/To references for sub-totaling, requirement routines (the condition is skipped if the routine returns false), and account keys that map to general ledger accounts.

Pricing procedure determination happens in transaction OVKK: the combination of Sales Area + Customer Pricing Procedure (from customer master) + Document Pricing Procedure (from order type) returns the correct pricing procedure.

VPRS (cost condition) draws the moving average price or standard cost from the material master. It is not visible to the customer but flows to CO-PA as the cost component of profitability.

For rebate processing, condition types of the HB class accrue a provision to an accrual account at each billing; the rebate settlement run later creates a credit memo against that accrual.

Shipping and Delivery#

The outbound delivery document (transaction VL01N) is created from a sales order or a delivery due list (VL10). It copies the ship-to party, delivery address, materials, quantities, and the requested delivery date from the sales order.

Key steps in the delivery process:

1. Picking — warehouse management (LE-WM or SAP EWM) selects goods from storage bins and moves them to a staging area. Picking confirmation updates the actual picked quantity on the delivery.
2. Packing — materials are assigned to handling units (HUs) with the appropriate packaging material. Packing is optional for domestic shipments but often required for international freight.
3. Post Goods Issue (PGI) — movement type 601 records the physical departure of goods. PGI reduces unrestricted stock in MM, creates an accounting document (debit COGS, credit inventory), and triggers a billing due entry. The delivery status flips to “goods issued,” preventing further changes.

Shipping point determination is automatic: Loading Group (from material master) + Shipping Condition (from customer master or order header) + Plant → Shipping Point. A single delivery can only have one shipping point, so mixed items sometimes cause a delivery split.

Route determination uses the departure zone (from shipping point), the transportation zone (from ship-to address), the shipping condition, and the transportation group (from material master) to derive a route. Routes carry transit time, which feeds backward scheduling of pick/pack activities.

Backorder processing (transaction V_V2) identifies schedule lines with unconfirmed quantities and reassigns newly available stock according to priority rules.

Billing#

The billing document (transaction VF01 or the billing due list VF04) is created from a goods-issued delivery or, for services, directly from a sales order. Common billing types:

• F2 — standard invoice created from delivery
• RE — credit memo from a returns sales order (RE order type)
• RK — invoice correction request
• BV — cash sales invoice (created automatically at order save)
• LR — delivery-related credit memo for returns

For project or subscription scenarios, billing plans separate invoicing from delivery. Milestone billing creates partial invoices when project milestones are completed; periodic billing generates fixed-amount invoices on a calendar schedule (monthly, quarterly).

Account determination (transaction VKOA) maps the combination of chart of accounts + sales organization + account assignment group (customer) + account assignment group (material) + account key to a GL account. Common account keys: ERL (revenue), ERF (freight revenue), ERS (cost/COGS offset), ERS (rebate accrual).

Billing releases an FI accounting document automatically: accounts receivable is debited against the reconciliation account, and revenue accounts are credited. This is the primary SD-FI integration point.

Intercompany billing involves two documents: a standard invoice to the external customer from the selling company code, and an intercompany invoice (type IV) from the delivering company code to the selling company code at transfer price.

Revenue recognition in S/4HANA can follow ASC 606/IFRS 15 rules. Event-based revenue recognition (VBREVENI) uses revenue recognition keys on condition types and posts deferred revenue at billing, recognizing it when the performance obligation is satisfied.

Credit Management#

Credit management in SD checks whether a customer’s total exposure (open orders + open deliveries + open invoices + open FI items) exceeds their credit limit before allowing a business transaction to proceed.

Classic SD Credit Management (SD-BF-CM):

• Credit Control Area — the organizational unit that manages credit; each company code is assigned to exactly one credit control area.
• Static credit check — total exposure ≤ credit limit (no time horizon).
• Dynamic credit check — exposure within a configurable future horizon counts against the limit. Orders with delivery dates beyond the horizon do not consume credit.
• Risk category — customers are assigned to risk groups (e.g., 001=high risk, 003=low risk) that control which check type and reaction (warning, error, workflow) applies.
• Check points: order save, delivery creation, goods issue.

SAP Credit Management / FIN-FSCM-CR (recommended for new S/4HANA implementations): Classic SD credit management is restricted in S/4HANA — new configurations should use FIN-FSCM-CR. It provides a unified credit exposure drawing from SD, FI, and treasury. Credit segments allow partitioning exposure by business unit. A rule-based decision engine evaluates credit worthiness, and Fiori apps (e.g., “Credit Limit Utilization”) give the credit analyst a real-time view.

2) Organizational Structure#

SAP SD’s organizational units form a hierarchy that must be designed before master data can be created. Every sales-relevant transaction occurs in the context of a Sales Area, which is the combination of three units:

Sales Organization#

The Sales Organization (German: Verkaufsorganisation, table T001W) is the top-level unit for sales. It represents the legal or regional entity responsible for selling and distributing products. Sales Organization is assigned to exactly one Company Code, creating the SD-FI link at the organization level.

Design considerations:

• One Sales Organization per legal entity is the typical baseline. Separate legal entities almost always require separate Sales Orgs because financial reporting, credit control, and pricing are Sales Org-specific.
• Multiple Sales Orgs within a single company code are possible (e.g., different regional selling units sharing the same legal entity), but they increase master data maintenance because customer master sales area data must be maintained per Sales Org.
• SAP provides a “reference Sales Organization” concept to share certain condition records.

Distribution Channel#

The Distribution Channel (Vertriebsweg) represents the means by which goods and services reach the customer. Common examples: 10 = Direct Sales, 20 = Wholesale, 30 = Internet/eCommerce, 40 = Retail.

Distribution Channel is assigned to a Sales Organization. Each channel can have distinct:

• Pricing (condition records keyed on Sales Org + Distribution Channel)
• Customer master data (payment terms, incoterms, shipping conditions per Sales Area)
• Account determination

The Common Distribution Channel (SPRO: Define Common Distribution Channels) allows one channel to share condition records and/or customer master data with another, reducing maintenance.

Division#

The Division (Sparte) groups products or services by business line (e.g., 01 = Machinery, 02 = Spare Parts, 03 = Services). Materials must have a Division in their basic data. When a material is placed on a sales order, the Sales Area (including Division) must match the Division on the material unless cross-division sales are activated.

Division is relevant for:

• Customer material info records
• Pricing (price lists can be Division-specific)
• Sales statistics and reporting segmentation

The Common Division (SPRO: Define Common Divisions) allows customer master data to be shared across divisions.

Sales Area and Downstream Units#

The Sales Area = Sales Organization + Distribution Channel + Division. All of the following are keyed on Sales Area:

• Customer master sales area data (payment terms, incoterms, shipping conditions, customer pricing procedure, output conditions)
• Condition records (prices, discounts, surcharges)
• Customer material information records

Below the Sales Area, two optional organizational units help with reporting and workload assignment:

• Sales Office — a geographic or functional grouping of salespeople (e.g., Tokyo Office, Osaka Office)
• Sales Group — a team within a Sales Office (e.g., Key Accounts team)

Neither Sales Office nor Sales Group affects pricing or document determination — they are primarily reporting dimensions and can be assigned to sales documents manually or via defaults.

Plant is the logistics unit responsible for inventory and production. Each plant is assigned to a Sales Organization. When a sales order item is created, a plant is proposed based on customer master and/or material master defaults; it can be overridden. The plant drives availability check, MRP, and shipping point determination.

3) Roles#

Summary#

SAP SD is the module that connects a company’s selling activities to its logistics and financial back-end. Its five core sub-modules — Sales Order Management, Pricing, Shipping and Delivery, Billing, and Credit Management — together implement the order-to-cash cycle. Organizational structure design (Sales Organization, Distribution Channel, Division) is foundational; decisions made here determine the shape of master data, pricing maintenance, and reporting for years after go-live.

In S/4HANA, the most significant structural change is the replacement of the Customer Master (XD01) with the Business Partner (BP transaction). Credit management moves from classic SD-BF-CM to FIN-FSCM-CR for new implementations. Fiori apps replace the SAP GUI as the primary interface for sales processing, credit analysis, and delivery management.

For a requirements definition project, the critical early decisions are: how many Sales Organizations and Distribution Channels are needed, which pricing procedure strategy to adopt, which credit check approach (classic vs. FSCM-CR) to implement, and where the integration boundaries with MM (ATP), FI (account determination), CO (CO-PA characteristics), and PP (MTO scenario) lie.

What to Read Next#

L1) Big Picture

L2-A) Master Data