Top 120 SAP SD Interview
Questions & Answers (2026)

SAP SD (Sales & Distribution) is SAP's core logistics module that manages the entire order-to-cash (O2C) cycle — from pre-sales inquiry through sales order, delivery, shipping, billing, and receivables. It covers master data (customer, material, pricing), sales document processing, availability check, delivery and transportation, billing, credit management, and returns. SD is tightly integrated with MM (availability, goods issue), FI/CO (billing postings, revenue), and PP (make-to-order). It is one of the most widely implemented SAP modules because every product-selling business runs its revenue process through it.

The SD org structure defines how a company's sales operations map into SAP. Key units: Sales Organization (highest SD unit, responsible for selling and legal liability, linked to one company code), Distribution Channel (how goods reach customers — e.g. wholesale, retail, online), and Division (product-line grouping). Together these three form the Sales Area, the central concept controlling sales document processing. Additional units include Plant (delivering location, shared with MM), Shipping Point (physical location that processes deliveries), and Sales Office/Group for reporting. Config is done under SPRO → Enterprise Structure.

A Sales Area is the unique combination of Sales Organization + Distribution Channel + Division. It is the most important org concept in SD because every sales document is created within exactly one sales area, and it controls master data, pricing, and document processing. Master data (customer, material) and condition records are maintained per sales area, so the same customer can have different terms in different sales areas. A customer must be extended to a sales area before you can create an order for them there.

Sales Organization is the top SD unit — legally responsible for sales, negotiating terms, and product liability; it links to one company code for FI postings. Distribution Channel describes the route through which goods/services reach the customer (e.g. direct, wholesale, e-commerce) and allows different pricing and master data per channel. Division groups related products or product lines (e.g. pharmaceuticals vs cosmetics), enabling product-wise sales analysis and separate terms. Combined, they form the sales area.

A Shipping Point is the top-level organizational unit for shipping that processes and monitors deliveries — physically a loading dock, mail room, or rail depot. Every outbound delivery is processed from exactly one shipping point. It is determined automatically from three factors: Shipping Conditions (customer master / sales doc type), Loading Group (material master), and the delivering Plant. Config: OVL2. It controls delivery scheduling, picking, and goods issue.

In SD, a Plant is the location from which goods are delivered and services rendered — the “delivering plant.” It is mandatory in the sales order because availability check, delivery scheduling, and shipping point determination all depend on it. The plant is a shared org unit: in MM it represents a manufacturing site or storage location for inventory and procurement, while in SD it represents the source of supply for a sale. The delivering plant is determined from the customer-material info record, then the customer master, then the material master.

Although the Company Code is an FI org unit, it is critical to SD because every Sales Organization is assigned to exactly one company code. When a billing document is released to accounting, the resulting FI document posts to that company code's ledgers — recording receivables and revenue. This assignment links the O2C revenue flow to statutory financial reporting. One company code can have multiple sales organizations, but a sales org cannot span company codes.

SD models the customer through partner functions that separate business roles: Sold-to Party (SP) — who places the order; Ship-to Party (SH) — who receives the goods; Bill-to Party (BP) — who receives the invoice; and Payer (PY) — who settles it. One physical customer often plays all four roles, but they can differ (e.g. head office pays, branches receive goods). Partner functions are assigned in the customer master and determined into the document via the partner determination procedure (VOPA).

Order-to-cash is the end-to-end SD process: (1) pre-sales — inquiry (VA11) and quotation (VA21); (2) sales order (VA01) capturing products, quantities, pricing, and availability; (3) outbound delivery (VL01N) with picking, packing, and post goods issue (reducing inventory and posting to FI via MM); (4) billing (VF01) creating the invoice and posting revenue/receivables to FI; and (5) payment clearing the receivable in FI-AR. SD owns steps 1–4; FI closes the loop.

A Storage Location is an MM sub-unit of a plant where stock physically sits; in SD it is determined during delivery processing and drives picking and goods issue. A Loading Point is an optional sub-division of a shipping point (e.g. a specific dock door or ramp) used purely for finer organization and scheduling of loading activities. Loading points are informational and do not carry their own configuration control the way shipping points do.

SD relies on four master data pillars: Customer Master (general, company code/FI, and sales area views), Material Master (with SD-specific Sales Org 1 & 2 and Sales:General/Plant views), Customer-Material Info Record (customer-specific material data such as their part number and delivery tolerances), and Condition (pricing) records. Clean, correctly maintained master data is the foundation of accurate order processing, pricing, and delivery.

The customer master has three data levels: General Data (address, communication, control — shared across all areas, at client level), Company Code Data (FI/accounting: reconciliation account, payment terms, dunning — maintained by finance), and Sales Area Data (sales, shipping, billing, partner functions — maintained by SD per sales area). T-codes: XD01 (central, all views), VD01 (SD sales-area views), FD01 (company-code/FI). In S/4HANA, the Business Partner (BP) is the single point of entry.

The Customer-Material Info Record (CMIR) stores data specific to one customer–material combination, maintained via VD51. It holds the customer's own material number and description, customer-specific delivery tolerances (over/under-delivery), a default delivering plant, and delivery priority. During order entry, SD checks the CMIR first for plant and shipping data, so it takes precedence over the customer and material master. It's essential when customers refer to products by their own part numbers.

The Account Group is assigned when the customer is created and controls: the field status (mandatory/optional/display/suppressed fields), the number range (internal or external), the partner functions allowed, and whether it's a one-time customer. Common groups include Sold-to, Ship-to, Bill-to, Payer, and one-time (CPD) accounts. It enforces data-entry consistency across the organization.

The SD-relevant views are Sales: Sales Org Data 1 (base/sales unit, delivering plant, tax classification, minimum order qty), Sales: Sales Org Data 2 (material statistics group, account assignment group, item category group), Sales: General/Plant Data (availability check group, loading group, transportation group, weights), and Sales Text. The Item Category Group and Account Assignment Group here are especially important because they feed determination logic.

The Item Category Group classifies a material for sales processing (e.g. NORM = standard, DIEN = service, LEER = empties, BANS = third-party). It is maintained in the material master Sales Org 2 view and is the key input to item category determination: SD combines Sales Document Type + Item Category Group (+ usage + higher-level item) to derive the item category (VOV4), which controls whether the line is relevant for delivery, billing, and pricing.

Condition records store the actual pricing values — prices, discounts, surcharges, freight, and taxes — for specific key combinations (e.g. customer/material, price-list/material). They are the data behind the condition technique. Maintained via VK11 (create), VK12 (change), VK13 (display), each record is tied to a condition type and a condition table and can carry validity dates and scales. At pricing time, the access sequence reads these records to find the valid price.

To avoid maintaining the same master data and condition records separately for every distribution channel or division, SAP lets you define a common (reference) distribution channel and common division. Master data and conditions are maintained once under the reference channel/division, and other channels/divisions point to it. This dramatically reduces maintenance effort for companies with many channels sharing the same customer/material/pricing data.

In classic ECC, customers (XD01) and vendors (XK01) were separate records. In S/4HANA, the Business Partner (BP) is the single, mandatory entry point — one BP can hold multiple roles (FI Customer, SD Customer, FI Vendor) with a Customer/Vendor Integration (CVI) layer keeping the classic tables (KNA1/LFA1) in sync underneath. This eliminates duplicate data, lets one entity be both customer and vendor, and is a key part of the S/4HANA simplification.

A Sales Bill of Materials lets you sell a product as a set of components (e.g. a computer with monitor, keyboard, cables). Depending on the item category group and config, it is processed either as main-item pricing (ERLA — price/stock at the header, components for information) or component pricing (LUMF — price and delivery at sub-item level). The BOM explodes automatically in the order, and the header item category determines the processing type.

SD sales documents fall into three groups: Pre-sales — Inquiry (VA11) and Quotation (VA21); Orders — Standard Order (VA01, type OR), Rush Order, Cash Sale; and Outline agreements — Contracts (VA41) and Scheduling Agreements (VA31). Post-order documents (deliveries, billing) are separate categories. Each sales document has a header, item, and schedule-line level.

A sales order has three levels. Header data applies to the whole document — sold-to, order date, pricing procedure, payment terms, incoterms. Item data is per material line — quantity, plant, item category, net value. Schedule line data sits under each item and holds delivery-relevant information — confirmed quantity and delivery date from the availability check, and the movement type for goods issue. One item can have multiple schedule lines if quantities confirm for different dates.

The Sales Document Type (VOV8) is the central control for how a sales document behaves. It defines: number range, screen layout, delivery- and billing-relevance, default delivery and billing types, item category and schedule line usage, pricing behaviour, incompletion procedure, partner determination, and immediate-delivery flags. Changing the document type (OR, RE for returns, CS for cash sale) fundamentally changes processing.

The item category controls how a line is processed — its relevance for pricing, delivery, and billing. It is determined (VOV4) from Sales Document Type + Item Category Group + Item Usage + Higher-Level Item Category. For example, OR + NORM → TAN (standard item). This four-part key lets the same material behave differently across document types (e.g. free-of-charge, text item, third-party).

The schedule line category controls delivery- and requirements-relevant behaviour — whether it triggers an availability check, transfers requirements to MRP, is delivery-relevant, and which movement type it uses. It is determined from Item Category + MRP Type. Examples: CP (make-to-stock, delivery relevant), CN (no inventory/no delivery), CB (individual purchase order). Configured in VOV6, determination in VOV5.

Copy control defines how data flows when one document is created with reference to another — quotation→order, order→delivery, delivery→billing. It controls, at header/item/schedule-line level, which routines copy data, whether pricing is redetermined or copied, and quantity/value rules. T-codes: VTAA (sales→sales), VTLA (sales→delivery), VTFL (delivery→billing), VTFA (sales→billing). Misconfigured copy control is a very common cause of documents that won't create or price correctly.

An incompletion procedure defines which fields must be filled for a document to be complete and proceed to the next step. If a required field (e.g. PO number, delivery plant) is missing, the document is flagged incomplete and — depending on the status group — may be blocked from delivery or billing. Configured via OVA2 and assigned to sales document types and item categories, it enforces data quality early in the process.

Both are pre-sales documents. An Inquiry (VA11) records a customer's request for information — availability, price, delivery — with no commitment. A Quotation (VA21) is a legally binding offer to sell specified quantities at a stated price within a validity period. A quotation can be created with reference to an inquiry, and a sales order with reference to the quotation, carrying data forward via copy control.

A Contract (VA41) is an agreement that the customer will buy a target quantity (quantity contract) or value (value contract) over a period, with no fixed delivery dates; release orders draw against it. A Scheduling Agreement (VA31) contains fixed delivery schedule lines with specific dates and quantities, so deliveries are created directly against the schedule without separate release orders — common in automotive/JIT supply.

Both are special order types with immediate processing. In a Rush Order (type SO), the delivery is created automatically when the order is saved; billing follows normally. In a Cash Sale (type BV/CS), delivery is created immediately and the customer pays on the spot — an invoice prints as a receipt and billing posts against a cash account rather than receivables. Standard orders (OR) process delivery and billing as separate, later steps.

The condition technique is SAP's generic framework for determining values from data — used for pricing, output, account determination, and more. In pricing it links five elements: Condition Types (what is calculated — price, discount, freight), Access Sequences (the search strategy), Condition Tables (key combinations), Pricing Procedure (the ordered set of condition types), and Condition Records (the actual values). Understanding this framework is essential because it recurs across many SD determinations.

A pricing procedure (V/08) is the ordered list of condition types that calculates the net price — controlling sequence, subtotals, formulas, requirements, and which conditions are mandatory, statistical, or manual. It is determined (OVKK) from three keys: Sales Area + Customer Pricing Procedure (customer master) + Document Pricing Procedure (doc type). The standard procedure is RVAA01. It's the backbone of all SD pricing.

A Condition Type (V/06) represents a pricing element — e.g. PR00 (price), K007 (customer discount), KF00 (freight). An Access Sequence (V/07) is the ordered search strategy assigned to a condition type — it lists condition tables from most specific to most general, stopping at the first hit. A Condition Table (V/03) defines the key fields of a condition record (e.g. customer/material). Together they let SAP find the right price for each situation.

PR00 is the standard base-price condition type — it establishes the gross price and is typically the first, mandatory condition in the pricing procedure. Other types build on it: discount/surcharge types (K004 material discount, K007 customer discount) adjust it, tax conditions (MWST/UTXJ) add tax, and freight (KF00) adds delivery cost. Condition types are classified by calculation type (fixed amount, percentage, quantity-based) and class (price, discount/surcharge, tax).

Condition records (VK11) hold prices/discounts for specific key combinations. When pricing runs, the condition type's access sequence tries each assigned table in order — say customer/material (specific), then price-list/material, then material (general) — and stops at the first table where a valid record exists for the document's data and date. This “most-specific-first” logic lets you set customer overrides while falling back to general prices.

A statistical condition is calculated but does not affect the net value the customer pays — it's flagged “statistical” in V/08. It's used for information and analysis: cost (VPRS) for profit-margin calculation, expected/competitor prices, or values passed to CO-PA. For example, VPRS carries the material cost so the system can compute profit margin without adding cost to the customer price.

Tax is determined through the condition technique using tax condition types (e.g. MWST, or UTXJ/jurisdiction-based in North America). The key inputs are the tax classification of the customer (customer master, billing) and the tax classification of the material (material master), combined with departure and destination country/region. For US/Canada, jurisdiction codes and often an external engine (Vertex, Sabrix) are integrated. The tax condition record returns the correct rate.

Condition exclusion prevents a customer from receiving multiple competing discounts simultaneously — the system picks the best (or a specific) condition instead of adding them all. It uses exclusion groups: you assign condition types to groups and define the comparison rule (e.g. “best condition within group A,” or “if group A exists, ignore group B”). Assigned to the pricing procedure, it's commonly used to give the customer the most favourable of several discounts.

Pricing procedures use small ABAP routines. Requirements decide whether a condition type is accessed at all (e.g. only apply freight if weight > X). Condition base value / value formulas alter how a condition's basis or result is calculated. Scale base formulas change scale logic. These routines are created and assigned in VOFM — the standard way to implement pricing requirements config alone can't meet.

Start with the pricing analysis: Item → Conditions → Analysis, which shows per condition type exactly which access was tried and why a record was or wasn't found. Check: is the correct pricing procedure determined (OVKK keys)? Does a valid condition record exist for the date and key (VK13)? Is an access sequence or requirement blocking the access? Are customer/material pricing fields correct? The analysis screen resolves the vast majority of pricing issues quickly.

The Availability Check (Available-to-Promise) verifies, at order entry, whether the requested quantity can be confirmed for the requested date by comparing demand against supply elements (stock, planned/production/purchase orders). It returns a confirmed quantity and date via schedule lines. It's controlled by the checking group (material master) + checking rule, and the scope of check (OVZ9) defines which stocks and receipt/issue elements are included. Transaction CO09 shows the availability overview.

Transfer of Requirements passes the demand created by a sales order or delivery to MRP/planning so procurement or production can react. When a schedule line relevant for requirements is created, the demand is recorded and visible to MRP. TOR is controlled by the requirements class (from the requirements type, derived from the material's strategy group/MRP), the schedule line category, and a global activation. With ATP, it connects selling to supply planning.

The checking group (availability-check field in the material master Sales:General/Plant view) defines whether and how availability is checked and whether requirements are transferred. The checking rule comes from the transaction (SD order vs delivery) and, combined with the checking group, points to the scope of check (OVZ9) — which stocks (safety, in-transit), receipts (POs, production orders), and issues are included in the calculation.

An outbound delivery is the document that initiates and monitors shipping — picking, packing, loading, and goods issue. It's created (VL01N) with reference to a sales order (or scheduling agreement) once the delivery due date is reached and stock is available. Collective processing uses the delivery due list (VL10/VL04). The delivery copies items via copy control (VTLA), determines the picking location, and is the basis for post goods issue and later billing.

Picking selects and stages goods from a storage location (in WM/EWM via transfer orders, e.g. LT03); the picked quantity is confirmed on the delivery. Packing (optional) assigns materials to handling units. Post Goods Issue (PGI) (VL02N) is the final step — it reduces inventory, creates a material document, posts cost of goods sold to FI (via MM account determination), updates requirements, and sets the delivery status so billing can proceed.

PGI is the point where ownership of the goods effectively transfers. It: (1) reduces warehouse stock and creates a material document (movement type 601); (2) posts an accounting document debiting Cost of Goods Sold and crediting Inventory (via MM/FI account determination); (3) reduces the transfer of requirements; (4) updates the delivery status and the order's document flow; and (5) makes the delivery relevant for billing. PGI is reversible with VL09 before billing.

The delivering plant is determined in this priority: Customer-Material Info Record → Customer Master (ship-to) → Material Master. The route (defining transit time and transportation scheduling) is determined (0VRF) from Departure Country/Zone (shipping point) + Destination Country/Zone (ship-to) + Shipping Condition (customer) + Transportation Group (material). The route drives delivery scheduling and transportation planning.

Delivery scheduling calculates the dates needed to meet the requested delivery date, accounting for transit, loading, pick/pack, and transportation lead time. Backward scheduling works back from the requested delivery date to find the material availability date; if that date is in the past or stock isn't available, the system switches to forward scheduling — starting from today/availability and calculating the earliest possible delivery date. These dates populate the schedule lines.

A delivery block prevents an order or delivery from being processed for shipping. It can be set on the sales document header (e.g. from a credit check or manually), at the schedule line, or on the customer master (blocking all orders). Delivery block reasons are configured and can be assigned to specific document types. Credit management, for instance, automatically applies a delivery block when a customer exceeds their limit.

Individual delivery creates one delivery per sales order (VL01N). Collective processing (VL10/VL04 delivery due list) groups multiple orders — or items across orders — into fewer deliveries to optimize shipping, provided they share key criteria: same ship-to, shipping point, route, delivery date, and incoterms. Combining deliveries reduces freight and handling; the rules are controlled by these matching fields and copy control.

A billing document is the SD invoice that charges the customer and posts revenue/receivables to FI. It's created (VF01, or collectively via the billing due list VF04) with reference to a delivery (delivery-related) or a sales order (order-related, e.g. services). Copy control (VTFL delivery→billing, VTFA order→billing) governs the data flow. On release, it generates an FI document debiting the customer (AR) and crediting revenue.

Common billing types: F2 (standard invoice), F1 (order-related invoice), G2 (credit memo), L2 (debit memo), RE (returns credit), IV (intercompany invoice), S1 (cancellation), and BV (cash-sale invoice/receipt). The billing type (VOFA) controls the number range, the FI document type posted, account determination, output, and whether it's a debit or credit to the customer.

Delivery-related billing creates the invoice from the outbound delivery — used for physical goods, so you bill only what shipped (billing after PGI). Order-related billing creates the invoice directly from the sales order — used when there's no delivery, such as services, or for credit/debit memos and milestone billing. The billing relevance is set on the item category, which determines which route a line follows.

Revenue Account Determination decides which G/L revenue accounts the billing document posts to. It uses the condition technique with condition type KOFI (and KOFK for CO). The account is found (VKOA) from a key typically including Chart of Accounts + Sales Organization + Account Assignment Group of the Customer + Account Assignment Group of the Material + Account Key. This is a core SD-FI integration point and a frequent config topic.

An Account Key (e.g. ERL for revenue, ERS for sales deductions/discounts, ERF for freight, MWS for tax) is assigned to condition types in the pricing procedure (V/08). During billing, each condition's account key routes its value to the correct G/L account via VKOA. This lets revenue, discounts, freight, and taxes post to separate accounts automatically, keeping the financial postings granular and analyzable.

An invoice split occurs when items that could combine into one invoice are billed on separate documents. It happens when header-level fields differ between items — e.g. different payer, billing date, terms of payment, or foreign-trade data — because those must be unique per billing document. In VF04/VF01, SAP shows a split analysis. If an unwanted split occurs, check copy control's data routine (e.g. 003) and the differing fields.

A billing plan schedules billing over time rather than in one invoice. Periodic billing invoices the full amount at regular intervals (e.g. monthly rent/subscription). Milestone billing splits the total across project milestones (common in make-to-order with PS integration) — each milestone releases a percentage or amount when reached. The billing plan type and date rules are configured and assigned to the item category/document type.

A credit memo reduces what a customer owes (e.g. overcharge, goodwill); a debit memo increases it (e.g. undercharge). They typically start as a credit/debit memo request (VA01, type G2/L2), which may require approval (billing block released via V.23), then are billed (VF01) into a credit memo (G2) or debit memo (L2). They're order-related billing since there's no delivery.

When a billing document is released to accounting, SD posts an FI document: it debits the customer's receivables (AR) reconciliation account (from the payer's master) and credits revenue accounts (from VKOA), with separate lines for discounts, freight, and taxes via their account keys. The receivable is later cleared by incoming payment in FI-AR. This automatic, real-time posting is a defining strength of SAP's integrated O2C.

A billing block prevents an order or delivery from being invoiced until released. It can be set on the sales document header (e.g. for credit/debit memo requests pending approval), at item level, or defaulted by the sales document type (VOV8). For example, credit memo requests are often configured with an automatic billing block so a manager must review and release them (V.23) before the credit is issued.

Credit Management controls a customer's outstanding credit exposure to reduce non-payment risk. It compares the customer's credit limit against receivables plus open orders/deliveries not yet billed. When an order would exceed the limit, the system can warn, block the order, or block delivery. In classic SD it's FI-SD credit management (credit control area, FD32); in S/4HANA it's replaced by FSCM Credit Management.

A Credit Control Area is the organizational unit that defines and monitors a customer's credit limit. It groups company codes for credit purposes — you can have one central credit control area for the whole group or one per company code. Each sales organization is assigned to a credit control area, and a customer's credit master data and exposure are managed at this level. Configured in FI enterprise structure (OB45).

A simple credit check compares order value plus open items against the limit at save. Automatic credit control (OVA8) is more granular and splits into static and dynamic. Static sums open orders, deliveries, billing, and receivables against the limit. Dynamic adds a time horizon — only counting open order values within a defined period — plus checks like maximum document value, oldest open item, and payment behaviour.

Automatic credit control is set up in OVA8 by the key Credit Control Area + Risk Category + Credit Group. The risk category (assigned to the customer in credit master data) classifies customers by risk; the credit group ties the check to a document activity (order, delivery, PGI). In OVA8 you activate the specific checks (static, dynamic with horizon, max value, oldest open item) and set the reaction (warning, error, or block).

A return starts with a Returns Order (VA01, type RE) referencing the original order or invoice. It creates a returns delivery (VL01N, movement type 651) to receive the goods back into stock (often blocked/returns stock), followed by a credit memo (billing type RE) to refund the customer. Item category REN and copy control drive the flow. Inspection and follow-up (scrap, restock) can be added via returns management.

A rebate is a discount paid retroactively based on sales volume over a period. A rebate agreement (VBO1) defines the customer, validity, condition types (e.g. BO01–BO03), and accrual rates. As invoices post, the system accrues the expected rebate (statistically) into an accrual account. At period end, the rebate is settled via a credit memo. Note: in S/4HANA classic rebates are largely replaced by Settlement Management / condition contracts.

Free goods let a customer receive extra quantity at no charge (e.g. buy 10 get 1 free). Configured via the condition technique for free goods (condition type NA00, records in VBN1), there are two types: inclusive (the free quantity is part of the ordered quantity — pay for 9, get 10) and exclusive (the free quantity is additional — order 10, get 1 extra as a separate free line, item category TANN). Determination happens automatically at order entry.

A return (RE) is used when the customer sends goods back and expects a refund — it brings stock back and issues a credit. A credit memo (G2) refunds money without goods movement — e.g. a price correction. A subsequent delivery free of charge (KN) ships replacement goods at no cost — e.g. for damaged/short shipments — with no charge and no return. Choosing the right document reflects the true business scenario.

When automatic credit control reacts at the delivery/PGI credit group, a customer over their limit gets the document blocked. Blocked documents appear in the credit representative's worklist (VKM1/VKM3/VKM4), where an authorized user reviews the exposure and either releases the document (removing the block so delivery can proceed) or rejects it. This gives finance control before goods ship.

Settlement Management is the S/4HANA framework that replaces classic SD rebate processing. Instead of rebate agreements, it uses condition contracts to model volume-based rebates, commissions, and royalties. Business volume is collected from billing data, accruals are managed, and settlement documents (credit/debit) are generated at defined intervals. It's more flexible and unified than legacy rebates and is the recommended approach for new S/4HANA implementations.

SD and MM meet at several points: availability check reads MM stock and receipt elements; Post Goods Issue in the delivery creates an MM material document and reduces inventory; third-party sales generate a purchase requisition/PO in MM; and stock transport orders (STO) move stock between plants using both modules. Master data overlaps too — the plant and material master are shared. This integration keeps inventory and sales in sync in real time.

The main SD-FI touchpoints are billing (posts receivables and revenue via VKOA) and PGI (posts COGS/inventory via MM-FI). Credit management links SD orders to FI-AR exposure. For CO, revenue and cost conditions can flow to CO-PA (Profitability Analysis) for margin reporting by customer/product, and make-to-order scenarios settle costs to the sales order as a cost object. This is why an SD consultant must understand account determination.

Output determination controls documents/communications sent to customers or internally — order confirmations, delivery notes, invoices — via print, email, or EDI/IDoc. It uses the condition technique: output types (e.g. BA00 order confirmation, LD00 delivery note, RD00 invoice) with access sequences and condition records, grouped in an output procedure assigned to the document type. Configured centrally in NACE. In S/4HANA, output management can also use BRF+ and Adobe forms.

Text determination controls how texts (notes, instructions, terms) flow onto documents and from master data. Text types (e.g. sales note, shipping instructions) are grouped into a text determination procedure assigned by object (customer master, sales header/item, delivery). Access sequences let texts copy from the customer master or a preceding document into the order and onward to delivery/invoice, ensuring consistent instructions across the O2C flow.

Material Determination automatically substitutes one material for another during order entry — e.g. replacing an old material number with a new one, swapping to a promotional product, or mapping a customer's material to yours. It uses the condition technique (condition type, records in VB11). A common use is product phase-in/phase-out, swapping discontinued items for successors without the order-entry clerk needing to know the internal number.

Listing and Exclusion control which materials a specific customer may or may not buy. A listing restricts a customer to only the materials on their list — anything not listed is rejected in the order. An exclusion blocks specific materials for that customer. Both use the condition technique (records via VB01). They enforce contractual assortments, regulatory restrictions, or customer-specific catalogues at order entry.

In third-party sales, the vendor ships goods directly to the customer instead of from your stock. A sales order with a third-party item category (TAS) automatically creates a purchase requisition; MM converts it to a PO to the vendor, who ships to the customer. Billing to the customer is typically triggered by the vendor's incoming invoice (statistical goods receipt / invoice-based). It's a key SD-MM integration scenario and a frequent interview topic.

Intercompany sales occur when the selling sales organization belongs to one company code but the delivering plant belongs to another. The customer is billed normally by the selling company (F2), and separately the delivering company code bills the selling company code with an intercompany invoice (IV) using intercompany condition types (PI01/PI02). It settles the internal transfer between the two legal entities and requires plant-to-sales-org assignment configuration.

An STO moves stock between plants (often across company codes). In an STO with delivery (SD-involved), the supplying plant creates an outbound delivery (SD shipping — picking, PGI) against the purchase order, and for cross-company scenarios an intercompany billing document is created. It combines MM (purchasing) and SD (delivery/billing), giving full document flow and valuation control for internal stock movements.

Consignment is stock stored at the customer's site but owned by you until they consume it. It has four steps, each a special order type/movement: Fill-up (KB) — move stock to the customer (no invoice); Issue (KE) — customer withdraws stock, now billed and ownership transfers; Return (KR) — customer returns consignment stock; Pick-up (KA) — you retrieve unsold stock. Only the issue step bills the customer.

User exits are predefined points in standard SAP programs where you insert custom ABAP without modifying the core. In SD order processing, the main include is MV45AFZZ, with exits like USEREXIT_SAVE_DOCUMENT_PREPARE (validations before save), USEREXIT_PRICING_PREPARE_TKOMK (add fields to pricing), and USEREXIT_MOVE_FIELD_TO_VBAP. For billing, the equivalent include is RV60AFZZ. They're the classic way to meet requirements config can't.

A User Exit is an older, include-based hook (e.g. MV45AFZZ) requiring an access key and edited in ABAP. A BAdI (Business Add-In) is object-oriented, using interfaces/implementations — cleaner, with multiple implementations possible (e.g. BADI_SD_SALES). An Enhancement Spot is the container for BAdIs and enhancement points in the modern Enhancement Framework. The trend moves user exits → BAdIs → enhancement framework for upgrade-safe custom logic.

VOFM is where SD's small, assignable ABAP routines are created — used across pricing, copy control, and output. Types include requirements (should this run?), data transfer routines (copy-control field logic), condition base value / value formulas (pricing calculations), and output/text requirements. Once created in VOFM, a routine gets a number and is assigned in the relevant config, letting consultants add logic without core modification.

The main sales-order BAPIs are BAPI_SALESORDER_CREATEFROMDAT2 (create), BAPI_SALESORDER_CHANGE (change), and BAPI_SALESORDER_GETSTATUS/GETLIST. They're used for integrations, data loads, and interfaces — enforcing the same checks as the online transaction and requiring BAPI_TRANSACTION_COMMIT to save. For deliveries there's BAPI_OUTB_DELIVERY_CREATE_SLS, and for billing BAPI_BILLINGDOC_CREATEMULTIPLE. BAPIs are preferred over direct table updates or BDC for reliability.

IDocs (Intermediate Documents) are SAP's standard containers for exchanging data with external systems/EDI. Common SD message/basic types: ORDERS (ORDERS05) — inbound customer POs creating sales orders; ORDRSP — outbound order confirmations; DESADV (DELVRY03) — outbound advance shipping notifications; and INVOIC (INVOIC02) — outbound invoices. They enable automated, high-volume EDI order-to-cash with trading partners. Status is monitored in WE02.

Options depend on volume and object. LSMW offers a structured, largely code-free path using recordings, BAPIs, or IDocs — historically common for master data and orders. BDC (call transaction or session) replays screen input for custom/complex loads. In S/4HANA, the Migration Cockpit (LTMC/LTMOM) with predefined templates is the recommended tool. For master data, standard programs/BAPIs (e.g. customer via BP) are preferred.

Document flow (the “Display Document Flow” button) links order → delivery → goods issue → invoice, stored in table VBFA. Core SD tables: VBAK/VBAP (order header/item), VBEP (schedule lines), LIKP/LIPS (delivery header/item), VBRK/VBRP (billing header/item), KNA1/KNVV (customer general/sales), KONV (conditions, PRCD_ELEMENTS in S/4). Knowing these is essential for reporting and debugging.

RICEF categorizes technical objects: Reports (custom ALV/analytics, e.g. open orders), Interfaces (data exchange via IDoc/BAPI/PI-PO), Conversions (legacy loads via LSMW/LTMC), Enhancements (user exits/BAdIs/VOFM), and Forms (SmartForms/Adobe for invoices, delivery notes). As a functional consultant you write the functional spec for each; ABAP develops from it. Managing the RICEF list is central to project delivery.

For pricing, use the condition analysis screen first, then if needed set a breakpoint in the pricing routine (VOFM) or program SAPLV61A. For output, check determination analysis (Extras → Output → Processing log) to see why an output wasn't found or failed, and review the processing status/message log. A functional consultant should read the analysis logs and pinpoint whether the issue is config, master data, or a routine.

An access key (SSCR) is required to modify SAP standard objects (like user-exit includes) — it registers the object/developer with SAP. A Transport Request (managed in SE09/SE10) captures configuration and development changes so they can move through the landscape — Development → Quality → Production — in a controlled sequence. SD customizing requests and ABAP workbench requests both travel this way; understanding transports is essential on any project.

I'd work top-down from the blueprint: define/confirm the enterprise structure (sales org, channel, division, plant, shipping point) and assignments; set up master data (customer, material, CMIR, conditions); configure the sales document type (VOV8) with its item and schedule line categories and determination; build the pricing procedure and account determination (VKOA); set up delivery and billing types with copy control; then availability check, output, and credit. Finally, unit-test the full O2C cycle and document it.

This is output determination. I'd configure an output type (e.g. BA00) for order confirmation with transmission medium external send (email), set up condition records so it triggers for the relevant sales org/customer, ensure the customer master has the email and partner/communication set, and assign the output procedure to the sales document type in NACE. A SmartForm/Adobe form and, if needed, a small program handle the layout and dispatch.

In MTO, production is triggered by the specific sales order rather than stock. I'd use a material with an MTO strategy group (e.g. 20) so the schedule line category creates an individual requirement transferred to planning; the sales order becomes a cost object. A production order is created against the order, costs collect on it, and at delivery/billing the costs settle and results flow to CO-PA. It requires close SD-PP-CO integration and correct requirements-type determination.

I'd model the two routes as separate distribution channels (online vs retail) within the sales area. Pricing then differs because condition records are maintained per sales area / distribution channel, and I can use distinct condition tables (e.g. distribution-channel/material) or a customer pricing procedure to drive different procedures. This keeps one material and customer master while cleanly separating price lists, and channel reporting comes for free.

I'd trace tax determination step by step: check the tax classification on the customer master (billing) and material master, confirm the departure country/region (plant/shipping point) and destination (ship-to), then run the pricing analysis on the tax condition to see which access and record were used. For US/Canada I'd verify jurisdiction codes and, if an external engine (Vertex) is used, check the RFC and returned rate. The fix is usually master data or a missing condition record.

This is free goods. I'd configure the free-goods condition technique (condition type NA00) and create records in VBN1 for the qualifying material and quantity. For “buy 10 get 1 additional free,” I'd use exclusive free goods so the free item is an extra line (item category TANN, unpriced). For “pay for 9 of 10,” I'd use inclusive. I'd bound validity to the promotion dates and test that determination fires only in the target sales area.

I'd reduce manual effort through determination and defaults: ensure the customer-material info record and customer master defaults (plant, shipping condition, incoterms, payment terms) auto-populate; verify item/schedule line and pricing determination are correct so nothing is keyed by hand; use material determination for substitutions; and consider order templates or variant configuration if applicable. I'd also review the incompletion log to remove non-essential mandatory fields.

That's intercompany sales. I'd assign the delivering plant (company code B) to the selling sales organization (company code A), configure intercompany billing (type IV) and intercompany condition types (PI01), and set the internal customer representing the selling company. The end customer is billed normally by A (F2), while B raises an intercompany invoice to A. I'd test both billing documents and confirm correct FI postings in each company code.

I'd use collective/periodic billing. First, align the header fields that force splits (payment terms, payer, billing date) so deliveries can combine. Then use the billing due list (VF04) with billing-date logic (billing date set to month-end via the factory calendar / date rules) so all deliveries in the period bill together on one invoice. A billing plan or invoice list (LR) can further consolidate multiple invoices into a single statement for the payer.

I'd determine whether it's config or data: confirm the checking group on the affected materials and the scope of check (OVZ9) — often a receipt element (POs or safety stock) is wrongly included/excluded. Verify stock actually exists in the delivering plant/storage location, that requirements aren't double-counting, and that the checking rule is correct for the transaction. CO09 gives the ATP breakdown. Most go-live ATP issues trace to scope-of-check settings or missing opening stock.

Frequent tickets: pricing errors (missing/expired condition records), orders stuck incomplete, credit blocks holding deliveries, ATP not confirming, invoice splits, output not printing/emailing, billing-to-accounting posting errors (VKOA/account determination), and IDoc failures for EDI orders. Effective support means reading the relevant analysis log (pricing, output, credit worklist, IDoc status WE02) to distinguish config, master-data, and technical root causes quickly.

I'd first quantify impact (how many documents, revenue at risk) and check the billing document's accounting status via Release to Accounting (VF02). Common causes: missing account in VKOA, a closed FI posting period, an account requiring a cost object (CO assignment), or a number-range gap. I'd find the root cause, coordinate with FI if needed, apply the fix in the right environment, release the stuck documents, and document a preventive action.

Unit testing — a consultant tests individual config (e.g. a pricing condition). String/scenario testing — a connected sequence within SD. Integration testing — end-to-end O2C across SD-MM-FI with real cross-module postings. User Acceptance Testing (UAT) — business users validate against requirements. Regression testing — confirming changes don't break existing processes, increasingly automated. Each has entry/exit criteria and defect tracking.

A test script is a step-by-step document proving a process works. A good SD test case contains: a unique ID, the scenario/requirement reference, preconditions (master and org data), the exact steps (transactions and inputs), the expected result at each step (document numbers, statuses, postings), the actual result, pass/fail, and evidence (screenshots). For O2C it walks order → availability → delivery → PGI → billing → accounting, verifying the FI document and values.

Through structured discovery: study the existing (AS-IS) process, run workshops with sales, logistics, and finance stakeholders, and document the TO-BE process. I capture organizational structure, master-data ownership, order types and channels, pricing rules, delivery/shipping needs, billing and credit policies, and integration/reporting needs. Outputs are a business blueprint and a fit-gap analysis separating standard functionality from gaps needing configuration or RICEF development.

A fit-gap analysis compares the client's requirements against standard SAP capabilities. Each requirement is classified as a fit (met by standard config) or a gap (needs enhancement, custom development, a workaround, or a process change). For gaps, you assess options and effort — often preferring configuration or standard alternatives over custom code to keep the system upgrade-friendly. It drives design decisions and the RICEF development list.

A functional specification (FS) is the document a functional consultant writes to hand a development requirement to ABAP — for any RICEF object. It describes the business need, the exact logic, input/output, selection criteria, data sources (tables/fields), error handling, and test cases, without dictating the code. It's the contract between functional design and technical build and the basis for testing the delivered object.

Cutover is the controlled transition from legacy to SAP at go-live. SD cutover activities include: loading master data (customers, materials, CMIR, condition records) in sequence, migrating open sales orders, open deliveries, and open billing, loading opening stock (so ATP works), and validating pricing and document flow. It follows a detailed, time-boxed cutover plan with dependencies, owners, and checkpoints — usually rehearsed in a mock run first.

Hypercare is the intensive support period immediately after go-live (typically a few weeks) when the project team stays engaged to stabilize the system. SD support means monitoring the O2C flow closely — orders, deliveries, billing, IDocs, credit — rapidly resolving incidents, sitting with users, and tracking issues by severity. The goal is to quickly fix teething problems, reassure the business, and transition smoothly to steady-state support.

By severity and business impact against SLAs: P1 (business-stopping, e.g. can't invoice) gets immediate attention; lower priorities are scheduled. I triage to confirm severity, reproduce the issue, determine root cause (config/data/technical), apply and test the fix in the correct environment, transport it properly, and communicate with the user. I also look for recurring patterns signalling a deeper root cause, an enhancement, or a training need — rather than just closing tickets repeatedly.

Major changes: the Business Partner replaces separate customer/vendor masters; classic SD rebates are replaced by Settlement Management (condition contracts); credit management moves to FSCM Credit Management; foreign trade moves to SAP GTS; the data model is simplified (conditions in PRCD_ELEMENTS, document-flow optimizations); advanced ATP (aATP) replaces classic ATP; output management can use BRF+/Adobe; Fiori provides role-based UIs; and revenue recognition uses SAP RAR for IFRS 15.

Advanced Available-to-Promise is the S/4HANA evolution of availability checking, built for high volume and complex confirmation. Beyond classic ATP it adds: Product Availability Check at scale, Backorder Processing (BOP) with configurable prioritization to reschedule confirmations by business rules, Release for Delivery, and Alternative-Based Confirmation (substituting plants/materials). It runs on HANA for real-time performance and gives businesses far more control over how scarce supply is allocated to demand.

Revenue recognition governs when revenue is booked versus billed, which can differ (e.g. subscriptions, bundled goods+services). Classic SD had SD Revenue Recognition (time- and event-based). Under IFRS 15/ASC 606, S/4HANA uses SAP Revenue Accounting and Reporting (RAR), which manages performance obligations, allocates the transaction price, and recognizes revenue as obligations are satisfied — decoupling revenue from billing and ensuring compliant, auditable postings. It's a key finance-integration topic for modern implementations.

S/4HANA uses SAP Credit Management (FIN-FSCM-CR) instead of classic FI-SD credit. It centralizes credit data (a credit master via the business partner), supports a scoring/rules engine to derive risk classes and limits, can integrate external credit agencies, and calculates credit exposure across systems. SD checks call this credit engine during order/delivery. It's more flexible and analytics-driven than the legacy credit control area approach, though the core concept — check exposure vs limit and block if exceeded — remains.

Variant Configuration (LO-VC, or Advanced Variant Configuration in S/4HANA) lets a customer configure a complex product from characteristics and options at order entry (e.g. a machine with chosen engine, colour, features), rather than maintaining a material for every combination. In SD, a configurable material (KMAT) with a super-BOM and object dependencies is selected in the order; pricing can depend on characteristics (variant conditions VA00). It's central to engineer-to-order and complex manufacturing sales.

Both group pricing agreements for a period. A Promotion is a higher-level marketing plan (e.g. a seasonal campaign) that can encompass several sales deals. A Sales Deal sits under a promotion and links to specific condition records (special prices/discounts) with validity. Together they let you manage and report promotional pricing centrally — activate/deactivate and analyze effectiveness — while the actual price adjustments are delivered through normal condition records tied to the deal.

Export processing captures foreign-trade data — commodity/tariff codes, country of origin, export licenses, incoterms, and legal control — on the material, customer, and documents, and generates export documentation. Classic SD-FT handled this within SD; in S/4HANA it's largely delivered through SAP GTS (Global Trade Services), which does compliance checks (sanctioned-party screening, embargo, licensing), customs management, and trade documentation as a connected system. It's essential for cross-border O2C.

For batch-managed materials (pharma, food, chemicals) SD must determine and deliver the correct batch. Batch determination (condition technique) can automatically select batches in the order or delivery based on rules (shelf life, FIFO, characteristics). Batches carry attributes (production/expiry date) and enable traceability. SD ensures the right batch, with valid shelf life, is picked and passed to the delivery and billing, and printed on documents — critical for regulated industries.

Within copy control, the copying requirement is a routine that decides whether copying is allowed at all (e.g. “don't copy a fully billed item,” “don't create a delivery for a blocked order”). The data transfer routine controls exactly which fields carry from source to target and how (e.g. redetermine vs copy pricing). Together they enforce process integrity — correct routines prevent bad documents and are a common root cause when a delivery or invoice won't create.

SD is evolving toward real-time, intelligent, cloud-based order-to-cash: advanced ATP for smarter fulfilment, Settlement Management and RAR for compliant financials, Fiori for role-based UX, embedded analytics on HANA, and tighter integration with SAP's cloud portfolio. With ECC mainstream maintenance winding down, companies are migrating to S/4HANA, so S/4HANA SD skills — the new data model, business partner, aATP, output management, and settlement — are in high demand. For consultants, that transition is where the opportunity is.