SAP SD explained: sales in SAP

SAP Sales — classically SD, Sales and Distribution — is the SAP area that runs order-to-cash: quotations and sales orders, the deliveries that ship against them, and the billing documents whose revenue and receivables post into Finance. Working in it means configuring that document chain — order types, item categories, pricing procedures, delivery and billing types — and the customer and material master data every step of it reads.

What the area covers

Sales (SD-SLS) — inquiries, quotations, standard, rush and cash orders, returns, contracts and scheduling agreements, and the item categories and copy control deciding what a document may become next.
Pricing (SD-BF-PR) — the condition technique: condition tables, access sequences, condition types and pricing procedures carrying prices, discounts, surcharges, freight and tax.
Basic functions (SD-BF) — availability check, credit check, output determination, partner and text determination, and the incompletion rules that stop a bad order early.
Shipping (SD-SHP) — outbound deliveries, shipping point and route determination, picking, packing and goods issue.
Billing (SD-BIL) — invoices, credit and debit memos, billing plans, invoice lists and revenue account determination.
Agreements and settlement — rebates and other customer agreements settled after the fact, alongside the condition records and customer-material info records pricing reads.

What does an SAP Sales consultant actually do?

The artefacts are concrete: a process design out of fit-to-standard workshops, configuration in the IMG (sales area structure, document and item categories, copy control, pricing procedure determination, output), functional specs for what standard cannot do — an order import, a custom pricing routine, an order confirmation form — test scripts, and a cutover plan for the open order and delivery backlog.

Most meetings are border meetings. Customer service describes how orders really arrive, the commercial team defends its discount structure, finance asks which account revenue posts to and who may release a credit block, the warehouse wants the delivery to be pickable, and integration walks through the EDI messages carrying orders, dispatch advices and invoices.

A week changes shape by phase: workshops and sandbox demos in explore; configuration, specs and unit tests in realise; defect triage in test, usually "why did this order price like that" — answered in the pricing analysis — or a delivery that will not pick. Then cutover, with open orders migrated and condition records loaded. In hypercare and AMS the billing run is the recurring pressure point.

How do people get into SAP Sales?

The common route is domain: order desk, customer service, sales operations and pricing or export administrators who know why an order is structured the way it is, now configuring the system they used. Next is the key-user route — owning the sales process during a project, then staying with it. Adjacent areas convert: MM consultants read SD as the mirror image of purchasing, logistics people arrive through the delivery, finance people through the invoice. Developers who wrote sales-order exits and pricing routines become strong techno-functional profiles here.

What gets someone hired is evidence rather than vocabulary: explaining the condition technique in your own words, describing a pricing procedure you built, reading a document flow backwards from an invoice to the order that caused it, saying how you cleared a credit block or what you did with the backlog at cutover. Interviews probe exactly there.

What it pairs with

Finance (FI): Billing posts receivables and revenue, so account determination and credit limits are shared territory — SD+FI is a well-worn combination.
Supply Chain & Logistics: The delivery is the hand-over point to picking, packing and warehouse execution.
Customer Experience (CX): Storefronts and CRM capture the order; the core still owns pricing, availability and the invoice (CX explained).
Procurement (MM): Third-party orders and intercompany stock transfers are one process written from both ends.
Service: What was sold gets repaired, and its contracts billed (Service explained).

Where it is going

Order capture keeps drifting outward: commerce and CRM front ends take the customer interaction while the ERP keeps the order, delivery and billing record — so defining which system owns pricing and availability, and how the order returns, is now part of the design work. Inside the core, functions have been re-based: availability onto advanced ATP, the credit check onto credit management in Finance, classic rebates onto condition contract settlement. Clean-core discipline pushes custom pricing logic and order exits beside the core on BTP, which is why the chain you are asked to explain now crosses more than one system.