SAP SD: what it does and where implementations break

SAP SD (Sales and Distribution) runs order-to-cash in SAP: quotation, sales order, delivery, billing and the handoff to finance. On S/4HANA it changes in ways that matter for project scope. Customers become business partners, credit management moves to SAP Credit Management, rebates move to condition contracts, and billing posts straight into the Universal Journal. This guide is for sales operations leads, finance controllers and project managers who need to know what SD does and where it breaks. The short answer on the second point: customer master data, pricing conditions, the availability check and account determination. Test those four with real data before go-live.

In one rollout after a full SAP implementation, the order-to-cash steps were built exactly as designed. They looked fine on the process map. Nobody had checked how stock updates were coming from production.

Sales told customers five days. Manufacturing knew it was closer to ten.

That gap cost more than late deliveries. It cost trust, and trust is harder to rebuild than a configuration setting.

SD sits at the front of the logistics chain. It turns a customer's interest into an invoice through a chain of documents:

1. Inquiry: the customer asks for price or availability
2. Quotation: a formal price and delivery offer with a validity period
3. Sales order: the customer commits, the availability check runs and a delivery date is confirmed
4. Delivery: the warehouse picks and packs; goods issue reduces stock
5. Billing: the invoice is created along with its accounting document
6. Payment: finance clears the incoming payment against the open item

Each document references the one before it. That document flow is what makes order-to-cash traceable. If the chain is clean, you can trace every invoice back to the original request. If documents are created out of sequence or bypassed, reporting breaks and disputes follow.

1. 01InquiryPrice or availability asked
2. 02QuotationFormal offer with a validity date
3. 03Sales orderAvailability check confirms the date
4. 04DeliveryPick, pack, goods issue
5. 05BillingInvoice and accounting document
6. 06PaymentFinance clears the open item

Every invoice traceable back to the original request

Done well, that chain removes manual handoffs. One manufacturing client cut its order-to-cash cycle by 40% after SD went live, mostly by eliminating handoffs between sales, warehouse and finance.

Sales orders and the availability check

Sales order processing is where most SD configuration effort lands: order types, item categories, schedule lines and the availability check.

Available-to-promise (ATP) is the most business-critical piece. It checks whether the requested date can be met from stock, planned receipts and existing commitments. Configured properly, sales tells customers what the system can actually commit to. Configured badly, sales tells customers what it hopes to deliver.

In the rollout from the opening, nobody had checked how stock updates were coming from production. Sales was quoting dates the plant could not meet.

Pricing and conditions

Pricing is the most underestimated setup in SD. It looks simple until the first invoice dispute.

SD's condition technique handles base prices, customer discounts, volume breaks, surcharges, freight and tax. Each element is a condition type with an access sequence, and the condition record holds the value.

The most common pricing problem I see: old pricing conditions from go-live that were never updated. The business renegotiates a discount, nobody updates the condition record in SD, the invoice is wrong and the dispute lands in accounts receivable.

Pricing governance is a process decision, not a configuration decision. Someone has to own condition record maintenance.

Shipping

Delivery processing covers picking, packing and goods issue. Goods issue is the critical event: it posts the stock reduction, puts the delivery on the billing due list and records the actual delivery date. Shipping point and route determination control how deliveries are created. Companies with complex distribution networks extend this with SAP Transportation Management (TM).

Billing, account determination and tax

Billing turns the delivery into an invoice and creates the accounting document. Account determination maps each billing item to revenue, tax and other G/L accounts, based on the sales organisation, the customer and material account assignment groups and the condition type. When it is wrong, the invoice posts to the wrong account and finance finds out at month-end.

Tax determination is just as brittle. It depends on the customer's tax classification, the material's tax classification and the delivering country or jurisdiction. A mismatch can produce a zero-tax invoice on a taxable sale, or tax on an exempt one.

Credit management

Credit checks block or flag orders that would take a customer past their credit limit. It only works if limits are maintained. Static limits set at go-live stop meaning anything as payment behaviour and volumes change.

When a limit falls below a customer's normal order size, every order is blocked automatically. Sales teams then learn to release the blocks rather than ask for a limit review.

That is not credit management. That is a workaround.

These are the SD structure elements and what each one links to.

Structure element	Purpose in SAP SD	Key linkage
Sales organisation	Top-level selling unit, responsible for sales terms and liability	Assigned to a company code in FI
Distribution channel	How products reach the customer (wholesale, retail, direct)	Controls pricing, master data and partner determination
Division	Product group within the sales organisation	Material grouping for reporting and output
Sales area	Sales organisation, distribution channel and division together	Required for every sales document and customer record
Sales office	Geographic sales unit	Regional reporting and partner determination
Sales group	Team within a sales office	Responsible person on orders
Shipping point	Location goods ship from	Links SD to warehouse management and transport
Plant	Producing or supplying unit	Source of stock, linked to shipping point

The sales area is the operative unit. Customer sales data is maintained per sales area, and every sales document is created in one. Many migrations stumble here: legacy customer records that do not map cleanly to sales areas need real preparation before loading.

If you are moving from ECC, these are the SD changes to plan into scope. SAP files the area under "Sales" in its S/4HANA documentation, though most teams still call it SD.

ECCS/4HANA

CustomersECCCustomer master recordS/4HANABusiness partner with a customer role

Credit managementECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), not optional

RebatesECCSD rebate processing, rebuilt from an indexS/4HANACondition contracts in Settlement Management

Availability checkECCBasic product availability checkS/4HANAAdvanced ATP: allocation, backorders, alternative plants

BillingECCFI and CO reconciled separatelyS/4HANAOne line item in the Universal Journal (ACDOCA)

Revenue recognitionECCCustom deferral logic on many programmesS/4HANASAP Revenue Accounting and Reporting, licensed separately

1. Customers are business partners. Customer master data is maintained through the business partner with a customer role. In a conversion, customer-vendor integration must be set up before the conversion runs.
2. Credit management moves to SAP Credit Management. The ECC credit management (FI-AR-CR) is not available in S/4HANA. SAP Credit Management (FIN-FSCM-CR) is its replacement, so a conversion has to migrate credit data and settings. It is not optional.
3. Rebates move to condition contracts. Classic SD rebate processing is replaced by Settlement Management (condition contract management). Rebate conditions apply immediately instead of being rebuilt from an index.
4. Advanced ATP. S/4HANA's advanced ATP adds product allocation, backorder processing, alternative-based confirmation across plants, release for delivery and supply assignment. In S/4HANA Cloud these functions are part of the standard licence. On-premise they need a dedicated licence once activated.
5. Billing posts into the Universal Journal. FI, CO and margin analysis share one line item in ACDOCA, which removes the FI-CO reconciliation work of ECC. The trade-off: an account determination error is an immediate posting to the wrong account, visible at line-item level.
6. Revenue recognition. For multi-element contracts, subscriptions or long-term services under IFRS 15, SAP Revenue Accounting and Reporting replaces the custom deferral logic many ECC programmes built. It is separately licensed and needs designing before go-live, not discovering at year-end.

Clean core changes how SD customisation is handled. On public cloud, custom code in the core is not possible. On private cloud and on-premise it is possible but makes every upgrade harder. Most old pricing Z-routines can be replaced with standard condition types, formulas and BAdIs. What genuinely remains belongs in a side-by-side extension on SAP BTP. My clean core guide covers the decision.

SD with MM

The availability check reads stock from MM, and goods issue posts the stock movement. If inventory data is wrong, ATP results are unreliable. If goods issue fails because the stock is not really at the shipping point, the delivery cannot complete and billing stalls. Keep both aligned through master data and through discipline: no manual stock adjustments that bypass standard postings.

SD with PP

In make-to-order scenarios, a sales order can drive production directly, so the confirmed date becomes a commitment backed by a production order. The strategy group in the material master controls how sales orders and forecasts interact. Set it wrong and they add up instead of netting off, the planning run overstates demand, and overproduction follows. My SAP PP guide covers the planning side.

SD with FI

The billing document is the interface. Each invoice creates an accounting document that posts revenue, tax and the customer open item into the Universal Journal. Payment terms on the customer master drive the due date. When sales negotiates terms without telling finance, the system enforces terms finance never agreed.

If the SD design treats all revenue as recognised at billing and the contracts say otherwise, the retrofit is expensive. Agree revenue recognition with finance before the design is signed off. For the finance side of the integration, see my SAP FICO guide.

Four failure points cause most of the post-go-live pain.

Customer master not ready. Every field matters downstream. Missing tax classification means wrong tax. Missing payment terms means FI cannot calculate due dates. Missing shipping conditions break delivery scheduling. Volumes are larger and source data worse than the plan assumes, and cleanup needs business decisions. Start early and treat it as a business workstream, not a technical load. My piece on why SAP data migration fails covers the method.

Pricing conditions not maintained. Go-live conditions that nobody reviews become invoice disputes within the first year.

Availability check disconnected from reality. ATP reading stale data produces promises the business cannot keep. Validate it against real production and stock scenarios, not the clean test data used in unit testing.

Account determination gaps found after go-live. Test with the actual chart of accounts, tax codes and material groups. Tax codes that do not match can block orders or spark invoice disputes before anyone realises what is wrong.

The table is the checklist I would walk through before UAT sign-off.

Risk	Impact	Mitigation
Incomplete customer master	Invoice errors, delivery failures, FI posting gaps	Start the data workstream early; define mandatory fields per sales area before migration
Stale pricing conditions	Invoice disputes, incorrect revenue	Name a condition record owner and review cycle at go-live
ATP disconnected from PP or MM	Unreliable delivery promises	Test ATP with live planning scenarios before UAT sign-off
Account determination gaps	Revenue posted to the wrong accounts	Test with the real chart of accounts and full tax code set
Credit block releases as routine	Uncontrolled exposure, receivables disputes	Enforce limit reviews; track manual releases in the first 90 days
Output not tested	Invoices and delivery notes not sent automatically	Test every output type with real print and email routing before go-live
Payment terms misaligned	Wrong due dates, cash forecasting errors	Agree terms between sales and finance before customer data is loaded

If the sales team routinely releases credit blocks instead of asking for a review, fix it in the first ninety days, before the habit sets.

What is SAP SD and what does it do?

SAP SD (Sales and Distribution) manages order-to-cash: inquiries, quotations, sales orders, deliveries, billing and the handoff to financial accounting. Its document flow links each step to the one before, so every invoice can be traced back to the original order. It integrates with MM for stock and goods issue, PP for make-to-order and availability, and FI for revenue, tax and receivables.

What is the organisational structure in SAP SD?

The operative unit is the sales area: a sales organisation, distribution channel and division together. Every sales document is created in a sales area and customer sales data is maintained per sales area. Sales offices and sales groups sit below for reporting and responsibility. On the logistics side, shipping points and plants determine where goods ship from. Get the structure right before customer data is loaded, because changing it later means reloading data.

How does pricing work in SAP SD?

Pricing uses the condition technique. Each price element is a condition type, an access sequence decides which condition record applies, and a pricing procedure combines the condition types in order. Most pricing disputes trace back to condition records that were not updated when commercial terms changed, not to configuration errors.

What is advanced ATP in SAP S/4HANA?

Advanced available-to-promise (aATP) is S/4HANA's availability check. Beyond the basic product availability check, it adds product allocation, backorder processing, alternative-based confirmation across plants, release for delivery and supply assignment. These functions are included in S/4HANA Cloud and need a dedicated licence on-premise once activated. Use them where supply is constrained or allocation rules matter. For stable supply chains, a well-configured basic check is often enough.

How does SAP SD integrate with financial accounting?

Through the billing document. Releasing a billing document to accounting creates a journal entry for revenue, tax and the customer open item. Account determination decides the G/L accounts from the sales organisation, account assignment groups and condition type. Tax depends on customer and material tax classifications. Payment terms on the customer master set the due date. For IFRS 15 cases, SAP Revenue Accounting and Reporting defers and recognises revenue over time.

What changes in SAP SD when moving from ECC to S/4HANA?

Customers become business partners. Credit management moves from FI-AR-CR to SAP Credit Management, which is mandatory. Rebate processing is replaced by condition contracts in Settlement Management. Advanced ATP becomes available, and billing posts into the Universal Journal. Plan all of these into scope early, because each one needs configuration, data migration and testing.

What are the most common SAP SD implementation mistakes?

Five come up again and again. Underestimating customer master data. Leaving pricing conditions without an owner after go-live. Testing ATP only with clean data. Testing account determination with simplified data. Not testing output end to end. The last one is easy to miss. When invoices do not go out automatically, someone starts printing them by hand, and the workaround becomes permanent.