SAP SD Interview Questions

100 Scenario-Based Questions & Answers — Beginner to Advanced (For Freshers)

Covers: Org Structure & Master Data | Pricing & Condition Technique | Availability Check & Delivery | Billing
& Credit Management | Advanced Integration & S/4HANA

Designed for freshers preparing for SAP SD interviews — every question is framed the way it is actually asked in
real interviews, with practical, scenario-driven answers.
Table of Contents
Section 1: SAP SD Basics & Organizational Structure (Beginner) - Q1 to Q20
Section 2: Pricing & Condition Technique (Beginner-Intermediate) - Q21 to Q35
Section 3: Availability Check, Delivery & Shipping (Intermediate) - Q36 to Q55
Section 4: Billing, Credit Management & Special Processes (Advanced) - Q56 to Q80
Section 5: Advanced Integration, S/4HANA & Troubleshooting - Q81 to Q100

Tip: Read this document section by section in order. Beginner questions build the foundation
(organizational structure, master data) that the later scenario questions on pricing, delivery, billing, and
credit management all depend on.
 Section 1: SAP SD Basics & Organizational Structure
(Beginner) - Q1 to Q20

Q1. What is SAP SD and where does it fit in the SAP ecosystem?
Answer: SAP SD (Sales and Distribution) is the module that manages the order-to-cash process: inquiry,
quotation, sales order, delivery, billing, and payment. It is tightly integrated with MM (for stock and
procurement), FI/CO (for revenue and cost postings), and PP (for production-linked sales). Scenario: when
a customer places an order, SD checks stock via MM, creates a delivery, posts goods issue, and finally
hands off the invoice to FI for accounting.

Q2. Scenario: Your company has one sales office selling in two countries with different
currencies and legal requirements. How would you set up the organizational structure?
Answer: You would create one Sales Organization if reporting can be combined, or two if legal/financial
reporting must be separate. Under each Sales Organization, you'd assign Distribution Channels (e.g.,
Wholesale, Retail) and Divisions (product lines). Each Sales Area is the combination of Sales Org +
Distribution Channel + Division, and it's the level at which sales orders are actually created.

Q3. What is a Sales Organization?

Answer: The highest level in the SD organizational structure, responsible for distributing goods/services,
negotiating sales conditions, and it's a legal entity that can be held liable for product liability. One Company
Code can have multiple Sales Organizations, but one Sales Organization belongs to only one Company
Code.

Q4. What is a Distribution Channel and give an example of when you'd use multiple
channels.
Answer: It represents the way products reach the customer, e.g., Direct Sales, Retail, Wholesale, or
Online. A company selling both through retail stores and an e-commerce site would maintain two
distribution channels so that pricing, availability, and reporting can differ between them even though the
same material and sales org are used.

Q5. What is a Division in SD and when is it useful?

Answer: A Division groups materials or services into product lines (e.g., Electronics, Furniture). It's useful
when different divisions need different pricing procedures, different sales teams, or separate credit limits
per product line.

Q6. Explain the concept of a Sales Area.

Answer: A Sales Area is the combination of Sales Organization + Distribution Channel + Division. Every
sales document is created within one Sales Area, and customer/material master data relevant to sales (like
pricing, delivery terms) is maintained at this level.

Q7. What is a Plant in the context of SD, and how is it linked to a Sales Organization?
Answer: A Plant is a location where stock is held or production happens; it belongs to MM/PP but is linked
to Sales Organizations through the assignment of Plant to Sales Org/Distribution Channel. Scenario: if an
order is placed and the assigned plant has no stock, the system can still process it if another plant is set up
for that combination, or it will trigger a cross-plant/cross-company scenario.
Q8. What is a Shipping Point and how does the system determine it?
Answer: A Shipping Point is the physical location (e.g., a loading dock or warehouse) from which goods
are shipped. It's determined automatically based on the Shipping Condition (from customer master),
Loading Group (from material master), and the Plant on the order — configured in the shipping point
determination table.

Q9. Scenario: Two customers order the same material from the same plant, but the system
proposes different shipping points. Why could that happen?
Answer: Because shipping point determination also depends on the Shipping Condition maintained in
each customer's master data (e.g., one customer wants 'immediate delivery' and another 'standard'), and
the Loading Group of the material combined with these conditions and the Plant can map to different
shipping points in the determination table.

Q10. What is Sales Document Type and name a few standard ones.
Answer: It controls the business scenario and behavior of a document (e.g., what fields are required, item
categories allowed, pricing procedure used). Standard types include OR (Standard Order), IN (Inquiry), QT
(Quotation), CS (Cash Sale), RE (Returns), and FD (Free of charge delivery order).

Q11. What is the difference between an Inquiry, a Quotation, and a Sales Order?
Answer: An Inquiry (IN) is a customer's request for information/pricing with no commitment. A Quotation
(QT) is a formal, legally binding offer with validity dates and pricing that the customer can accept. A Sales
Order (OR) is a confirmed request to deliver goods/services, which triggers delivery and billing processes.

Q12. What is Item Category in a sales document and how is it determined?

Answer: Item Category controls how each line item behaves — whether it's relevant for pricing, delivery,
billing, whether it needs a schedule line, etc. It's determined from a combination of Sales Document Type +
Item Category Group (from material master) + Usage + Higher-Level Item Category, configured in table
T184 (VOV4).

Q13. Scenario: A customer orders a free sample item along with regular paid items in the
same sales order. How does the system handle pricing differently for the free item?
Answer: The free item is assigned a different Item Category (e.g., TANN) which is marked as 'not relevant
for pricing' or uses a pricing procedure that zeroes out the value, while the regular item uses the standard
item category (TAN) that is fully pricing-relevant. This lets one order carry both priced and free items
correctly.

Q14. What is a Schedule Line and what does Schedule Line Category control?
Answer: A Schedule Line contains the delivery quantity and date, and Schedule Line Category controls
whether the item is relevant for delivery, whether it triggers an availability check, and whether it creates a
purchase requisition (e.g., for third-party or make-to-order items).

Q15. What is the difference between the Header, Item, and Schedule Line levels in a sales
document?
Answer: Header level data applies to the whole document (e.g., sold-to party, payment terms). Item level
data is specific to each material line (e.g., quantity, plant, pricing). Schedule Line level breaks the item
quantity into delivery dates/quantities, especially useful when a large order quantity is split into partial
deliveries.
Q16. What master data is essential before creating a sales order?
Answer: Customer Master (general, sales area, and company code views), Material Master (sales, MRP,
and accounting views), Customer-Material Info Record (optional, for customer-specific material data),
Condition Records for pricing, and Output Determination records for printing/emailing documents.

Q17. What are the key views in the Customer Master relevant to SD?
Answer: General Data (address, contact), Company Code Data (reconciliation account, payment terms —
used by FI), and Sales Area Data (pricing, delivery plant, shipping conditions, order probability, partner
functions) — this last view is created per Sales Area.

Q18. Scenario: A new customer wants to order in a Sales Area where their master record
hasn't been extended yet. What happens and how do you fix it?
Answer: The sales order creation will fail or the customer won't be found in that Sales Area, because
customer master Sales Area data is Sales-Area specific. You fix it by extending the customer master to that
new Sales Area (XD01/VD01 or the Business Partner transaction in S/4HANA) so pricing, delivery, and
partner data are maintained for it.

Q19. What are Partner Functions in SD? Name the four mandatory ones.
Answer: Partner Functions define the roles different partners play in a transaction. The four mandatory
ones are Sold-to Party (who places the order), Ship-to Party (who receives goods), Bill-to Party (who
receives the invoice), and Payer (who pays).

Q20. Scenario: A parent company places orders for all its regional branches, but wants
invoices consolidated at head office while goods go to each branch. How do you configure
partner functions for this?
Answer: You'd set up the Sold-to Party and Payer as the head office, and create separate Ship-to Party
master records for each branch. The sales order would use the head office as Sold-to/Bill-to/Payer, while
each order line or delivery uses the specific branch's Ship-to Party address for goods receipt.
 Section 2: Pricing & Condition Technique
(Beginner-Intermediate) - Q21 to Q35

Q21. Explain the Condition Technique in SAP SD pricing.

Answer: The Condition Technique is the framework SAP uses to determine prices, discounts, taxes, and
surcharges automatically. It uses Condition Tables (key combinations), Access Sequences (search
strategy/order), Condition Types (individual price elements like PR00 for base price, K004 for discount),
and the Pricing Procedure (which determines which condition types apply and in what sequence).

Q22. Scenario: You need to give a special discount only to a specific customer for a specific
material, but a general discount should apply to everyone else. How would you configure
this?
Answer: You'd create two condition records under the same Condition Type (e.g., a discount type K005):
one with the key combination Customer + Material for the special discount, and another with just Material
for the general discount. The Access Sequence checks the more specific combination (Customer+Material)
first; if found, it uses that, otherwise it falls back to the general one.

Q23. What is a Pricing Procedure and how is it determined for a sales order?
Answer: A Pricing Procedure is an ordered list of condition types (base price, discounts, freight, tax) with
calculation rules (from/to steps, subtotal, requirement routines). It's determined by the combination of Sales
Area + Customer Pricing Procedure (from customer master) + Document Pricing Procedure (from sales
document type).

Q24. What are Access Sequences?

Answer: An Access Sequence is a search strategy attached to a condition type that tells the system which
condition tables to check, and in what order, to find a valid condition record — e.g., first check
Customer/Material, then Price List/Material, then just Material.

Q25. Scenario: A discount condition record you created is not being picked up in the sales
order. What are the possible causes and how would you troubleshoot?
Answer: Common causes: (1) validity dates of the condition record don't cover the order date, (2) the
condition record's key combination doesn't match the order's data, (3) the condition type isn't included in
the pricing procedure for that sales area/document type, (4) the condition type is excluded via a
requirement routine or exclusion group, (5) pricing hasn't been redetermined after a data change. Use
Analysis in the pricing screen (the 'Analysis' button in item conditions) to see which condition records were
checked and why they failed.

Q26. What is the difference between Condition Type and Condition Record?
Answer: A Condition Type (e.g., PR00, K004) is the configuration definition of what a price element is and
how it behaves (e.g., percentage vs fixed amount). A Condition Record is the actual data entry (e.g.,
material X costs $50, or customer Y gets 5% discount) created via VK11.

Q27. What is Condition Exclusion and when would you use it?
Answer: Condition Exclusion prevents multiple discounts from applying together — e.g., if a customer
qualifies for both a volume discount and a promotional discount, exclusion logic (group or best-price
 comparison) ensures only the more favorable one is applied, avoiding double-discounting.

Q28. Scenario: The sales team wants the system to automatically apply the better of two
discounts (whichever gives the customer more benefit) rather than applying both. How is
this achieved?
Answer: Using Condition Exclusion Groups with exclusion procedure 'Best price' (comparison type B) —
you group the relevant condition types into an exclusion group and set the requirement so the system
compares the resulting net price under each and keeps only the cheapest for the customer.

Q29. What is a Condition Table and how does it relate to key combinations?
Answer: A Condition Table defines the key fields (e.g., Sales Org + Customer + Material) used to store
and retrieve condition records. When you create a condition record via VK11, you choose a 'key
combination' which corresponds to one of these tables.

Q30. What is the role of the 'Requirement' field/routine in a pricing procedure?

Answer: A Requirement is an ABAP routine assigned to a condition type or step that acts as a filter — the
condition is only considered if the requirement's logic returns true, e.g., 'only apply freight condition if the
item is relevant for delivery' or 'only apply this tax if the customer is domestic'.

Q31. What is a Rebate Agreement and how is it different from a normal discount?
Answer: A Rebate Agreement is a retroactive discount/settlement agreed with a customer based on
cumulative sales volume/value over a period, settled periodically (monthly/quarterly) via credit memo,
unlike a normal discount which reduces the price at the time of order. (Classic rebate processing uses
condition types like BO01-BO06 with settlement via VBO2.)

Q32. Scenario: A customer's contract states 'Pay in 30 days, 2% cash discount if paid in 10
days.' How is this represented in SAP?
Answer: Through Payment Terms configured in the customer master (or overridden at order level) using
terms of payment (OBB8) with staggered cash discount percentages and due date calculation rules — e.g.,
ZB01: 2% discount within 10 days, net due in 30 days. This links to FI for actual discount calculation at
payment/clearing time.

Q33. How does the system determine which Tax Condition applies to a sales order line?
Answer: Tax determination uses the condition technique with tax condition types (e.g., MWST) whose
access sequence usually checks Country + Customer Tax Classification + Material Tax Classification, both
maintained in customer and material master 'Sales' views, allowing different tax treatment for tax-exempt
customers or materials.

Q34. Scenario: Same material, same customer, but pricing differs between two sales orders
created a month apart. What's the most likely explanation?
Answer: The most likely reason is that condition records have validity periods, and a new condition record
(updated price, new discount, or a price change) became effective between the two order creation dates. It
could also be that the pricing date used (e.g., requested delivery date vs. order date) differs, causing a
different condition record to be picked.

Q35. What is 'New Pricing' (Update Pricing) in a sales order and when would you use it?
Answer: It's a function to re-determine pricing (via the 'Update' button, with options like 'Carry out new
pricing' or 'Copy manual pricing elements and redetermine the others') used when master data (prices,
discounts) has changed after order creation, or when correcting a change in quantity/material that should
re-trigger pricing.
 Section 3: Availability Check, Delivery & Shipping
(Intermediate) - Q36 to Q55

Q36. What is Availability Check (ATP) in SAP SD?

Answer: ATP (Available-to-Promise) checks whether the ordered quantity can be delivered by the
requested date, considering stock, planned receipts (POs, production orders), and existing
reservations/other sales orders, so the system can propose a confirmed delivery date and quantity.

Q37. Scenario: A customer orders 100 units, but only 60 are in stock with 50 more arriving
via a purchase order in 3 days. How does the system typically handle confirmation?
Answer: Depending on the configuration (checking rule/scope of check), the system can perform
Backorder Processing and either confirm 60 immediately with the remaining 40 confirmed for the date the
PO stock arrives (partial delivery/split schedule lines), or, if partial delivery is not allowed for that
customer/order, confirm the full 100 only on the later date.

Q38. What is the difference between Rules-Based ATP (in APO/aATP) and Standard SD
Availability Check?
Answer: Standard SD ATP checks stock at one plant against a simple checking rule (stock, receipts,
requirements). Rules-based ATP (in SAP APO or S/4HANA's Advanced ATP) can check across multiple
plants/locations, substitute materials, and apply business rules for allocation and prioritization — offering
much more sophisticated sourcing decisions.

Q39. What is a Checking Group and Checking Rule in Availability Check configuration?
Answer: The Checking Group (in material master) defines whether/how ATP runs for a material (e.g.,
include or exclude certain stock types), and the Checking Rule (linked to the transaction, like sales order vs
delivery) defines which stock/receipt elements to include. Together they form the 'Scope of Check' used
during ATP.

Q40. Scenario: A material is showing as unavailable in ATP even though physical stock
exists in the warehouse. What could be wrong?
Answer: Possible causes: the stock is in a status not included in the scope of check (e.g., blocked stock,
quality inspection stock), the checking group/rule combination excludes that stock category, there's an
unreleased delivery already reserving it, or the ATP check is being done against the wrong plant/storage
location.

Q41. What is a Delivery Document and what triggers its creation?

Answer: A Delivery (document type LF for standard) is created to physically ship goods; it's triggered from
a confirmed sales order schedule line once the delivery-relevant date is reached, via transaction VL01N
(individually) or VL10 (collective, based on due list).

Q42. What is the difference between Picking, Packing, and Post Goods Issue (PGI) in the
delivery process?
Answer: Picking is retrieving the goods from their storage location (can be via Warehouse
Management/WM). Packing is grouping the picked items into shipping units (e.g., boxes, pallets). Post
Goods Issue (PGI) is the final step that reduces inventory, updates stock in MM, and creates the
 accounting document for cost of goods sold — after which the delivery is considered fully processed and
billing can proceed.

Q43. Scenario: Goods Issue is posted, but the billing document still can't be created. What
might be missing?
Answer: Common causes: the billing due list (VF04) hasn't picked up the delivery because of billing block
at header/item, the item category or delivery item isn't relevant for billing (billing relevance flag), copy
control between delivery and billing type isn't configured, or the delivery is only partially picked/PGI'd (e.g.,
some items still open).

Q44. What is Route Determination and what factors influence it?

Answer: Route Determination automatically proposes a shipping route based on Departure Zone (from
shipping point), Destination/Transportation Zone (from ship-to party), Shipping Condition (customer),
Transportation Group (material), and weight group — configured to help estimate transit time and plan
loading/goods issue dates.

Q45. Scenario: A customer in a remote area always complains about receiving goods late
even though PGI happens on time. What SD configuration area should you investigate?
Answer: Investigate Route Determination and the associated transit/transportation lead times; if the route
assigned underestimates transit duration, or the wrong (faster) route is defaulting for that destination zone,
delivery dates will look on-time in the system but not reflect reality. Also check the Rounding profile and
loading/transportation planning time in the shipping point's scheduling settings.

Q46. What is Delivery Split and name common reasons a single sales order creates multiple
deliveries.
Answer: A Delivery Split happens when SAP cannot combine all order items into one delivery document.
Common reasons: different shipping points, different delivery dates/schedule lines, different routes,
different partner functions (ship-to), incompatible delivery item categories, or a header-level split control
field (like different sales order but same customer) not matching between items.

Q47. What is the significance of the 'Complete Delivery' indicator on a sales order?
Answer: When set, it means the entire order must be delivered in one delivery — partial deliveries per item
aren't allowed until all items are available; this is typically set at customer master or order header level for
customers who don't want split shipments.

Q48. Scenario: A high-priority customer wants partial deliveries allowed per item, but no
more than 3 partial deliveries per item. How would you configure this?
Answer: On the customer master (or item level in the order), you'd set 'Partial Delivery per Item' to allow
partial deliveries and specify the 'Maximum Number of Partial Deliveries' field (e.g., 3), so the system stops
creating further partial deliveries beyond that limit for the item.

Q49. What is Backorder Processing?

Answer: Backorder Processing (transaction V_RA or via rescheduling) is used to re-run ATP for orders
where confirmed quantities may need adjusting because new stock came in, priorities changed, or urgent
orders need to 'steal' confirmed quantities from lower-priority ones.
Q50. Scenario: A VIP customer places a rush order, but stock is already reserved for older,
lower-priority orders. How can you fulfill the rush order without manually canceling other
orders?
Answer: Use Backorder Processing/Rescheduling (V_V2 or V_RA) which re-sorts confirmations based on
priority rules (e.g., requested delivery date, customer priority) allowing the system to re-allocate available
stock from lower-priority open orders to the higher-priority rush order automatically, subject to the
configured rescheduling rules.

Q51. What is the difference between Delivery-Relevant Billing and Order-Relevant Billing?
Answer: Delivery-Relevant Billing means the invoice is created based on the delivery document (typical for
physical goods, e.g., delivery quantity, after PGI). Order-Relevant Billing means the invoice is created
directly from the sales order without a goods movement (typical for services or when the item category is
billing-relevant directly from order, e.g., third-party or services with no physical delivery).

Q52. What is Proof of Delivery (POD) and how does it affect billing?
Answer: POD is a confirmation from the customer/carrier that goods were received (often quantity/date
confirmed), and if POD-relevant, billing is only released after this confirmation is recorded — used for
scenarios needing tighter reconciliation of delivered vs billed quantity.

Q53. Scenario: A customer disputes an invoice, claiming they received less quantity than
delivered. What SD feature helps prevent or resolve this?
Answer: Proof of Delivery (POD) functionality — by requiring POD confirmation with the actual received
quantity before the invoice is created (or by capturing POD-confirmed quantity separately), differences
between delivered and confirmed-received quantity can be flagged and resolved before billing, and the
invoice can be split/created only for the confirmed quantity.

Q54. What is a Transportation/Shipment document and when is it used?

Answer: A Shipment document (VT01N) groups one or more deliveries going to similar destinations/routes
into one physical transport (truck, container) for shipment planning, cost settlement (freight costs), and
tracking, especially useful when consolidating multiple orders into a single truckload.

Q55. Scenario: Multiple small orders headed to the same region need to be shipped together
to save freight cost. What SD process addresses this?
Answer: Shipment Document / Transportation Planning — group deliveries with the same route/destination
into a single Shipment document, allowing collective goods issue and combined freight cost settlement,
which is more efficient than shipping each delivery separately.
 Section 4: Billing, Credit Management & Special Processes
(Advanced) - Q56 to Q80

Q56. What is Copy Control in SAP SD and why is it critical?

Answer: Copy Control (VTAA, VTLA, VTFA, VTFL) defines the rules for copying data from one sales
document to another (e.g., order to delivery, delivery to billing, quotation to order) at header and item level,
including which fields copy, quantity/pricing update rules, and requirement routines that determine if
copying is even allowed. It's critical because incorrect copy control causes wrong pricing, blocked
document flow, or data mismatches downstream.

Q57. Scenario: When creating a billing document from a delivery, the system throws an error
saying the item category is not relevant for billing. How do you fix this?
Answer: Check the Item Category configuration (VOV7) — the 'Billing Relevance' field must be set
correctly (e.g., 'A' relevant for order-related billing, blank/other for delivery-related). If the item is meant to
be billed from the delivery, ensure it's flagged accordingly, and also verify the copy control between the
delivery type and billing type (VTFL) includes that item category with a valid copying requirement.

Q58. What is Credit Management in SAP SD and what are the main checks?
Answer: Credit Management ensures a customer doesn't exceed an approved credit exposure. Main
checks include: static credit limit check (open orders + open deliveries + open billing + open items vs credit
limit), dynamic check (considers a horizon/time period), and can be at order entry, delivery creation, or PGI.
In S/4HANA, this is largely handled via the integrated FSCM Credit Management (UKM) with credit
segments and scoring.

Q59. Scenario: A long-time trusted customer's order gets blocked for credit even though
they always pay on time. How would you investigate and resolve it?
Answer: Investigate: check the customer's current credit exposure (FD33/UKM_BP) vs their assigned
credit limit — the limit may not have been increased despite good payment history, or a large open sales
order/delivery is temporarily inflating exposure. Resolution: after review, either release the blocked
document (VKM3/VKM4) for that instance or request a formal credit limit increase if their business has
genuinely grown, and consider using a risk category assessment to justify the change.

Q60. What is a Credit Block and how is it released?

Answer: A Credit Block automatically holds a sales order/delivery from further processing (delivery
creation, PGI, or billing) when a credit check fails. It's released via VKM1/VKM3/VKM4 (credit manager
work list) after review, either manually approving the block or adjusting the credit limit/risk category.

Q61. What is the difference between Simple Credit Check and Automatic Credit Control?
Answer: Simple Credit Check is a basic check (credit limit vs open value) at the sales document type level
with just a warning/error/block option. Automatic Credit Control is more granular — configured by Credit
Control Area + Risk Category + Credit Group, allowing checks at multiple points (order, delivery, PGI) with
different rules like static/dynamic checks, and integrates with credit management work lists for release.

Q62. What is Third-Party Order Processing and how does it work end-to-end?
 Answer: In Third-Party Processing, the selling company never holds stock; instead, upon sales order
creation, a Purchase Requisition is automatically generated (via item category TAS), converted to a
Purchase Order sent to the vendor, who ships directly to the customer. The vendor's invoice (from MM)
triggers the ability to bill the customer in SD, often linked via the 'billing relevance' set to allow
invoice-receipt-based billing.

Q63. Scenario: In a third-party sales scenario, the customer should only be billed after the
vendor's invoice is verified. How is this ensured in SD configuration?
Answer: By setting the Item Category's Billing Relevance to 'F' (Order-relevant billing – billing plan based
on invoice receipt/order value, or more precisely, billing based on quantity actually invoiced by the vendor),
so the sales order billing document can only be created up to the quantity that has been invoice-verified in
MM (via the statistical PO/invoice receipt), preventing billing to the customer before vendor invoice
verification.

Q64. What is Intercompany Sales Processing?

Answer: Intercompany Sales happens when one company code's sales org sells to an external customer,
but the goods are delivered from a plant belonging to a different company code. This triggers two billing
documents: a customer invoice from the selling company (standard SD billing) and an Intercompany Billing
document (IV) from the delivering plant's company code to the selling company code, using intercompany
pricing conditions (like PI01/PI02) to determine the internal transfer price.

Q65. Scenario: A German sales org sells goods that are physically delivered from a plant in
France (different company code). What documents/pricing are involved?
Answer: The customer sees one standard invoice from the German sales org at customer sales price.
Separately, an Intercompany Billing Document is created between the French delivering plant's company
code and the German sales org's company code, using an intercompany price condition (PI01)
representing the internal transfer price — this creates the necessary FI postings between the two company
codes.

Q66. What is a Billing Plan and when is it used?

Answer: A Billing Plan schedules billing over time instead of a single invoice — used for Periodic Billing
(e.g., monthly rent/subscription, same amount each period) or Milestone Billing (e.g., project billing tied to
completion percentages/milestones like 30% on order, 40% on delivery, 30% on completion).

Q67. Scenario: A construction company sells a large equipment project billed 20% on order
confirmation, 50% on delivery, and 30% after installation. What SD feature supports this?
Answer: Milestone Billing Plan — configured at the item level (usually with item category relevant for
milestone billing plans, linked to a project/network in PS if applicable), where each billing date/milestone
has a percentage or fixed value, and billing is only released for each milestone as its condition (e.g., PS
milestone confirmation) is met.

Q68. What is Consignment Processing in SD and what are its four sub-processes?
Answer: Consignment allows goods to be placed at the customer's location while ownership stays with the
selling company until consumed. The four sub-processes are: Consignment Fill-up (CF – send stock to
customer, no billing), Consignment Issue (CI – customer consumes stock, billing occurs), Consignment
Pick-up (CP – return unused stock, no billing), and Consignment Returns (CR – customer returns
already-issued/faulty goods, credit memo relevant).
Q69. Scenario: A customer has 100 units of consignment stock at their site; they use 30 and
want to return 10 as defective. How would each transaction be processed?
Answer: The 30 units consumed are recorded via Consignment Issue (CI) — this creates a delivery +
billing document since ownership transfers upon consumption. The 10 defective units are processed via
Consignment Returns (CR), creating a returns delivery and a credit memo since the customer was already
billed for consumed stock (assuming those 10 were part of the consumed 30) or, if part of the un-consumed
70, they'd instead go through Consignment Pick-up (CP) with no billing since they were never billed.

Q70. What is the Returns process (RE) in SD and what special configurations are involved?
Answer: Returns (order type RE) captures customer returns of previously sold goods, using item category
REN, typically with a returns delivery (document type LR) to physically receive goods back into inventory
(often into blocked/quality stock), followed by a credit memo to refund the customer. Reason codes are
usually mandatory to track why goods were returned (damaged, wrong item, etc.).

Q71. Scenario: A customer wants a refund for damaged goods, but you also want to track
why this happened for quality reporting. What SD feature addresses this?
Answer: Reason Codes on the Returns order/item — mandatory reason code fields (e.g., 'damaged in
transit', 'wrong item shipped') are captured during Returns processing, enabling reporting/analysis on return
reasons which can feed into quality management or vendor claims.

Q72. What is a Credit Memo Request vs a Debit Memo Request?

Answer: A Credit Memo Request (CR) is a sales document created (often with reference to an invoice)
when a customer is owed money back (e.g., pricing error, overbilling, returns) and results in a credit memo
billing document reducing what they owe. A Debit Memo Request (DR) is the opposite — used when the
customer was underbilled and needs to pay more, resulting in a debit memo increasing what they owe.
Both often route through a billing block for approval before the actual memo is released.

Q73. Scenario: A pricing error caused a customer to be overcharged by $500 on a delivered

order. How would you correct this in SD?
Answer: Create a Credit Memo Request (document type CR) with reference to the original billing
document, adjust the amount/pricing condition to reflect the $500 correction, route it through the billing
block for approval (since financial credit memos usually require review), then release the block and create
the Credit Memo billing document to refund the customer.

Q74. What is Free Goods Determination in SD?

Answer: Free Goods Determination automatically adds free items to an order based on rules — either
'inclusive' (e.g., buy 10, pay for only 8, 2 free of the same material) or 'exclusive' (e.g., buy 10 of material A,
get 1 unit of material B free), configured via condition technique (condition type NA00/NR00) with condition
records maintained via VBN1.

Q75. Scenario: A promotion says 'Buy 12 units, pay for only 10' for a specific material. How is
this configured?
Answer: This is an Inclusive Free Goods scenario — a free goods condition record is created (VBN1) with
the 'from quantity' as 12 and 'free quantity' as 2 (12 ordered, 2 free means customer pays for 10), using
condition type NA00, so the sales order automatically splits the line into a priced sub-item (10 billed) and a
free sub-item (2 free, item category TANN).
Q76. What is the difference between a Standard Invoice (F2), a Cancellation Invoice (S1), and
a Pro-forma Invoice?
Answer: A Standard Invoice (F2) is the regular commercial invoice that posts to FI and is legally billable. A
Cancellation Invoice (S1) reverses a previously posted billing document (e.g., created in error) and posts
an offsetting accounting entry, keeping the original invoice for audit trail via document flow. A Pro-forma
Invoice is a non-binding, non-accounting document often used for customs/export declarations or advance
customer reference, and it never posts to FI.

Q77. What is Text Determination in SD and why does it matter operationally?

Answer: Text Determination automatically proposes/copies standard texts (e.g., delivery instructions,
packing notes, internal remarks) at header/item level into sales documents from sources like customer
master or material master, using a Text Determination Procedure — ensuring consistent, required
information flows through order-to-delivery-to-invoice without manual retyping, and can auto-populate fields
like special packing instructions on the delivery/pick list.

Q78. Scenario: Warehouse staff keep missing special handling instructions (e.g., 'fragile,
handle with care') that used to be manually written on paper delivery notes. How can SD help
automate this?
Answer: By setting up Text Determination at the material master or customer master level with a standard
text (e.g., 'Handling Instructions') that's automatically copied into the sales order and subsequently the
delivery document/packing list output, ensuring the instruction prints automatically every time that material
or customer is used, removing dependence on manual entry.

Q79. What is Output Determination and what are the common output types in SD?
Answer: Output Determination automatically decides which outputs (print, email, EDI, fax) to trigger for a
document (e.g., order confirmation, delivery note, invoice, packing list) using the condition technique,
similar to pricing — with condition records (via NACE or VV11) defining, for a given customer/document
combination, which output type and medium apply.

Q80. Scenario: A customer wants their invoices emailed automatically instead of printed,
while another customer still wants a paper delivery note. How would SD handle both?
Answer: Through Output Determination condition records: for the first customer's billing output type (e.g.,
RD00), maintain a condition record with transmission medium 'Email' and their email address; for the
second customer's delivery output, maintain a condition record with medium 'Print'. Each customer's
determination is independent because condition records key on customer/document type, allowing mixed
output channels.
 Section 5: Advanced Integration, S/4HANA & Troubleshooting
- Q81 to Q100

Q81. How does SD integrate with MM during the order-to-cash cycle?

Answer: SD checks material availability (ATP) against MM stock, uses MM for plant/storage location
determination, triggers goods movements (PGI) that update MM inventory and valuation, and for
third-party/individual purchase order scenarios, SD creates purchase requisitions that flow into MM
procurement.

Q82. How does SD integrate with FI/CO?

Answer: Billing documents post to FI (creating customer receivables and revenue postings via account
determination — VKOA), Cost of Goods Sold posts at PGI, credit management historically synced with
FI-AR (now via FSCM), and revenue account determination uses condition technique (account keys like
ERL, ERS mapped to G/L accounts) to decide which G/L accounts are hit.

Q83. Scenario: A billing document is created but no accounting document (FI posting) is
generated. What should you check first?
Answer: Check Account Determination configuration (VKOA) — the combination of Chart of Accounts +
Sales Org + Account Assignment Group (Customer) + Account Assignment Group (Material) + Account
Key must map to a valid G/L account; if this combination is missing or misconfigured, no FI document is
created and the billing document shows an account determination error that must be corrected and then
reprocessed (VFX3).

Q84. What is Revenue Account Determination and what are Account Assignment Groups?
Answer: It's the condition-technique-based process that decides which G/L accounts revenue, discounts,
and taxes post to when a billing document is released to accounting. Account Assignment Groups (one for
Customer, one for Material) are simplification 'buckets' — e.g., grouping customers as domestic/export, or
materials as finished goods/services — used as part of the key to look up the correct G/L account in VKOA.

Q85. What is the difference between SAP SD in ECC and Sales in S/4HANA at a high level?
Answer: Core SD processes (order-to-cash) remain conceptually the same, but S/4HANA introduces the
Business Partner model (replacing separate Customer/Vendor master with a unified BP), Advanced
Available-to-Promise (aATP) with more powerful backorder processing, embedded/integrated FSCM Credit
Management (UKM) replacing classic FD32/FD33, simplified data models (e.g., no more separate
VBUK/VBUP redundant tables in some areas, use of CDS views), and Fiori-based apps for many
transactions alongside the classic GUI.

Q86. What is the Business Partner (BP) concept in S/4HANA and how does it affect SD?
Answer: In S/4HANA, Customer and Vendor master data is unified under the Business Partner model —
every customer must have a corresponding Business Partner record (with Customer role added), and
transactions like XD01/VD01 are technically redirected to BP transaction (or deprecated). SD processes
still reference 'customer' logically, but the underlying master data maintenance now happens through the
BP transaction with customer-specific roles/views.
Q87. What is aATP (Advanced Available-to-Promise) and how does it differ from classic
ATP?
Answer: aATP in S/4HANA offers Product Allocation (allocate scarce supply across customers/channels
by quota), Backorder Processing with more flexible sorting, and Alternative-Based Confirmation
(substituting plant/product/date to still fulfill demand) — offering much finer control and better performance
(leveraging HANA) compared to classic SD ATP's simpler stock/receipts check.

Q88. Scenario: During peak season, a company wants to ensure its top 10 strategic
customers always get priority allocation of a scarce product over smaller customers. What
S/4HANA feature would you recommend?
Answer: Product Allocation (part of aATP) — set up allocation objects/procedures based on characteristics
like customer, and define allocation sequences/quotas so that strategic customers are guaranteed a
reserved allocation of the scarce product ahead of general demand, rather than relying purely on
first-come-first-served ATP.

Q89. What is the significance of VBAK, VBAP, VBEP, and VBUK/VBUP tables?
Answer: VBAK stores sales document header data, VBAP stores item data, VBEP stores schedule line
data, and VBUK/VBUP store overall processing status (header/item) such as delivery status, billing status,
and rejection status — critical for understanding document flow and building custom reports.

Q90. Scenario: You need to build a report showing all sales orders that are 'fully delivered
but not yet billed.' Which tables/fields would you use?
Answer: Join VBAK/VBAP (order header/item) with VBUP (item status) filtering on Delivery Status ('C' =
fully delivered) and Billing Status (not 'C', i.e., open/partially billed), optionally cross-referencing VBFA
(document flow table) to trace linked delivery and billing documents for confirmation.

Q91. What is VBFA and why is it one of the most important tables for an SD consultant?
Answer: VBFA (Sales Document Flow) records the relationships between predecessor and successor
documents (e.g., quotation → order → delivery → billing document), including quantities copied at each
stage. It's essential for tracing the complete document flow, building reconciliation reports, and diagnosing
where a process broke down (e.g., order created but no delivery, or delivery created but billing missing).

Q92. What is an incompletion log/procedure and why is it useful?

Answer: The Incompletion Procedure flags mandatory fields that are missing at header, item, schedule
line, or partner level (e.g., missing purchase order number, missing pricing) and can block further
processing (like delivery or billing) until resolved — helping ensure data quality without hard-coding
validations everywhere.

Q93. Scenario: An order was saved successfully, but the delivery can't be created. The order
doesn't show any error message. What should you check?
Answer: Check the Incompletion Log (VA02 > Edit > Incompletion Log, or the system may show it
automatically) — the order might have been saved as 'incomplete' (SAP allows saving incomplete orders in
many configs) with a missing mandatory field like schedule line date, shipping point determination failure,
or a credit block, any of which would silently prevent delivery creation until the missing data is completed or
the block released.

Q94. What are User Exits/BAdIs commonly used in SD, and give a scenario for one.
 Answer: Common ones include USEREXIT_SAVE_DOCUMENT_PREPARE (custom validations before
saving an order), USEREXIT_PRICING_PREPARE_TKOMP/TKOMK (custom pricing communication
structure fields), and BAdI's like BADI_SD_SALES_ORDER or RV_INVOICE_CREATE for custom logic in
invoice creation. Scenario: if management wants to block sales orders above a certain value from a specific
new customer segment without a formal credit check, a custom validation in
USEREXIT_SAVE_DOCUMENT_PREPARE could enforce this business rule.

Q95. What is the role of a Sales BOM (Bill of Material) in SD and how is it processed at
pricing/delivery?
Answer: A Sales BOM lets you sell a 'kit' (header material) that explodes into component materials in the
sales order (e.g., a computer bundle exploding into CPU, monitor, keyboard). Pricing can be at the header
level (components zero-priced) or item level (each component priced individually, header just
informational), controlled by the item category group/structure scope settings; delivery and billing typically
happen at the component level since those are the physically relevant items.

Q96. Scenario: A company sells a 'Starter Kit' bundle at a fixed bundle price, but needs each
component tracked separately in inventory for delivery. How would you configure this in SD?
Answer: Configure the kit as a Sales BOM with the header material's item category set for BOM explosion
(e.g., using item category group ERLA for pricing at header level), so pricing is fixed at the header (bundle
price) while the component items (with item categories like TAE, not relevant for pricing but relevant for
delivery) still get individually tracked for stock, picking, and delivery.

Q97. How would you handle a scenario where a customer requires goods to be delivered to
multiple different addresses within a single sales order?
Answer: Use multiple Ship-to Party partner functions at the item level (or the 'alternative ship-to' address
feature) — each line item (or item split) can have a different ship-to party assigned, and the system will
typically split the delivery per ship-to address, since a single delivery document generally can't have
multiple ship-to parties.

Q98. What common KPIs/reports would an SD consultant typically discuss with a business
user, and why?
Answer: Order-to-Cash cycle time (order creation to payment), Open Order Report (VA05), Delivery due
list backlog (VL10), Billing due list backlog (VF04), Incomplete orders report, and Credit-blocked orders
report — these help operations and finance quickly spot bottlenecks (e.g., orders stuck due to credit blocks
or missing data) before they affect customer satisfaction or revenue recognition timing.

Q99. What preparation tips would you give a fresher walking into their first SAP SD
interview?
Answer: Be very solid on the order-to-cash flow end-to-end and be ready to draw it out; know the four
mandatory partner functions and the condition technique cold (access sequence, condition type, condition
record, pricing procedure) since these underpin most scenario questions; practice explaining at least one
scenario per module (order, delivery, billing, pricing, credit) in your own words rather than memorized
definitions, since interviewers for SD roles often probe with 'what would you check if X went wrong' rather
than pure theory.

Q100. As a fresher, how would you explain the complete Order-to-Cash cycle in an interview
if asked to summarize it end-to-end?
Answer: Presales (Inquiry/Quotation) → Sales Order creation (with pricing, availability check, credit check)
→ Delivery creation (picking, packing, Post Goods Issue which reduces inventory and posts COGS) →
Billing (invoice creation, which posts revenue and receivables to FI) → Payment receipt and clearing in FI.
Throughout, master data (customer, material, pricing conditions) and organizational structure (sales area,
plant, shipping point) drive how each step behaves, and document flow (VBFA) ties every stage together
for tracking and reporting.