ERPClimb logoERPClimb

SAP SD / O2C Pricing Interview Questions

Pricing comes up in SAP SD / O2C interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

SAP SD Pricing covers the condition technique used to determine prices, surcharges, discounts, freight, rebates and taxes on sales documents. This topic explains condition tables, access sequences, condition types, pricing procedures, procedure determination, condition records, and how pricing results flow into sales orders, billing and finance, across ECC and S/4HANA.

This page carries 36 reviewed SAP SD / O2C pricing interview questions, each with a complete written answer and no sign-in required. The set breaks down into 5 foundational, 15 mid-level and 16 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for pricing.

36 Pricing questions with answers

easyPricing

1. What is the purpose of the 'Expected Price' field on a sales order item, and how does it differ from the actual pricing determined by the pricing procedure?

The expected price field lets the sales rep or customer service agent enter a price the customer anticipated, typically from a quote or prior agreement, without it affecting the actual pricing procedure output. The system still calculates the real price via condition records; the expected price is stored for comparison/reporting, often triggering an incompletion or manual review if there's a significant variance versus the system-determined net price.
easyPricing

2. What is the condition technique in SAP SD pricing, and what are its core building blocks?

The condition technique is the framework SAP uses to determine prices, discounts, surcharges, taxes, and freight dynamically during sales order and billing processing. It links condition types (what is calculated), access sequences (search strategy), condition tables (key combinations), and condition records (actual values) within a pricing procedure. The system searches accesses in sequence until it finds a valid record, enabling flexible, maintainable pricing without hardcoding logic.
easyPricing

3. In SD pricing, what are scales within a condition record, and what is the functional difference between a base scale and a graduated (interval) scale?

A scale lets a condition amount or percentage vary by quantity or value thresholds within a single condition record. A base scale applies one rate to the entire quantity once the highest applicable threshold is reached, while a graduated (interval) scale applies different rates to each portion of quantity falling within its own bracket, then sums the results. Scale type is set per condition type/record via the scale basis and calculation type fields.
easyPricing

4. In SD pricing, how are tax conditions (like MWST) and freight conditions (like KF00) typically classified differently in the pricing procedure, and why does this distinction matter for account determination?

Tax conditions are usually statistical-in-effect for pricing but are calculated based on tax classification and departure/destination country, then posted via the tax procedure to tax accounts through condition type-to-GL mapping in FTXP/OB40. Freight conditions are revenue-relevant or cost elements posted via VKOA using account keys like ERL or ERF. The distinction matters because taxes flow through the tax code determination logic while freight uses standard SD account determination, and mixing them up causes incorrect GL postings.
easyPricing

5. What is the purpose of condition exclusion groups in SD pricing, and how do they differ from simply using requirement routines on individual condition types?

Condition exclusion groups let you bundle several condition types (e.g., competing discounts) and apply an exclusion procedure (best price, exclusive, or group comparison) so only the most favorable or a defined subset applies. Unlike a requirement routine on one condition type, exclusion groups compare multiple conditions dynamically at pricing time within the pricing procedure, avoiding stacking of overlapping discounts without hardcoding logic per condition.
mediumPricing

6. A customer reports that a manually entered discount condition record disappeared from a recurring sales order template after mass condition record updates. How would you troubleshoot this using condition record maintenance?

I would check validity periods on the condition record via VK13 - mass updates often use a validity end date that may have expired or overlapped incorrectly with the manual entry, causing it to be superseded. I'd also check if the mass update created a new record with higher priority in the access sequence or overlapping validity that pushed out the manual record, and review change documents (condition record change log) to confirm what was altered and when, then correct validity dates or recreate the manual condition record if genuinely deleted.
mediumPricing

7. When configuring VKOA account determination for a billing document that includes both a tax condition (MWST) and a freight condition (KF00), how do you ensure each posts to its correct G/L account via distinct account keys?

Tax conditions are typically excluded from revenue account determination and instead flow through the tax procedure to tax accounts via OB40, since MWST is marked as a tax category condition, not an accounting-relevant revenue condition. Freight (KF00) is assigned an account key like ERF in the pricing procedure, and VKOA maintains a separate account determination table keyed by application V, condition type/account key, chart of accounts, account assignment group, and account key to route it to a freight revenue or clearing account distinct from ERL (main revenue).
mediumPricing

8. Freight condition records for a promotional shipping surcharge are maintained at the shipping point level, but the shipping point determination logic assigns different shipping points to deliveries from the same sales order depending on plant and loading group. As a result, freight amounts posted to FI-AR are inconsistent across split deliveries for the same customer order. How do condition record master data attributes interact with shipping point determination to cause this, and how would you resolve it?

Shipping point determination evaluates plant, shipping condition, and loading group per delivery-relevant line, so a single order can generate deliveries from multiple shipping points even under one sales area. If the freight condition table key includes shipping point, each split delivery accesses different condition records, producing inconsistent freight amounts that post separately to FI-AR. I'd redesign the condition table key to use route or a higher-level field (like sales org/customer) instead of shipping point, or maintain harmonized records across all valid shipping points to ensure consistent freight regardless of delivery split.
mediumPricing

9. A customer complains that freight charges and tax are calculated inconsistently across delivery plants for the same material and destination. What areas would you investigate in shipping and pricing configuration to diagnose this?

I would first check whether the pricing procedure determination varies by sales area/document pricing procedure combination across plants, then verify condition records for freight (e.g., KF00) are maintained at the correct access sequence level (plant, route, shipping point) since missing plant-specific records cause fallback to different condition records. For tax, I'd check tax classification on the customer/material master and jurisdiction code determination (departure vs. destination country) via the tax procedure, since plant location changes the departure country used in tax determination even for identical destinations.
mediumPricing

10. A shipping condition (e.g., route or shipping point) is influencing freight pricing in the sales order, but freight charges posted to FI-AR appear inconsistent across deliveries from different shipping points. How do shipping configuration and the pricing procedure integrate, and where would you investigate?

Shipping point and route determination (based on delivering plant, loading group, transportation zone) feed into the sales order/delivery header, which pricing conditions like freight (KF00) reference via field catalog access. Investigate route/shipping point determination tables (TVRO, shipping point determination), confirm the freight condition's access sequence includes route or shipping point as key fields, and verify pricing redetermination at billing (copy control pricing type) isn't recalculating freight inconsistently. Also check if different plants have different account determination for freight revenue accounts in VKOA.
mediumPricing

11. When configuring scale-based pricing conditions that feed into VKOA account determination, what design considerations ensure the correct revenue account is hit as quantities cross scale thresholds?

Scales themselves (interval or graduated-to) affect only the condition rate calculation, not account determination directly—VKOA keys off account key (from pricing procedure), sales org, chart of accounts, customer/material account assignment groups. The design consideration is ensuring the condition type carrying the scale is assigned the correct account key (e.g., ERL vs ERS) so scale-driven amounts post to the right GL account, and that scale basis (value/quantity) doesn't cause rounding splits across periods.
mediumPricing

12. When configuring condition exclusion groups in pricing, how can this configuration inadvertently affect revenue account determination (VKOA) results downstream?

Exclusion groups (via condition exclusion procedure, transaction V/32) determine which conditions survive in the pricing procedure for a line item. If a discount or surcharge condition that carries an account key (e.g., ERL, ERS) gets excluded, the corresponding revenue or discount postings never occur, even though the condition type is technically configured with an account assignment in VKOA. Testing must confirm that exclusion logic doesn't silently drop conditions needed for correct GL posting splits, especially in rebate or bundled pricing scenarios.
mediumPricing

13. Freight charges determined via an access sequence keyed on shipping point and route are posting to the wrong G/L account during billing. How does the access sequence design connect to this downstream FI-AR posting issue?

The access sequence for the freight condition type determines which condition record is found, but the actual G/L account posted comes from a separate VKOA account determination step using the account key assigned to that condition type in the pricing procedure. If freight values differ by route or shipping point but the account key doesn't distinguish accordingly, all freight revenue posts to one account regardless of the access sequence's granularity, meaning the fix lies in account determination, not the access sequence itself.
mediumPricing

14. A client wants a special freight surcharge condition to never combine with a promotional discount condition on the same order line. How would you configure this, and what shipping-related impact should you check?

I'd configure condition exclusion using either exclusion groups (grouping the two condition types and defining a procedure like 'best price' or 'exclusive') or a requirement routine on the freight surcharge to suppress it when the promotional discount is active. On the shipping side, I'd verify that freight determination in delivery-relevant pricing (if freight is calculated at delivery/shipment cost level) isn't recalculating the surcharge independently, since shipment cost documents can have separate pricing procedures that bypass sales order exclusions.
mediumPricing

15. A customer's invoice posts revenue to the wrong GL account even though the pricing conditions and access sequence are correct. What area would you investigate first and why?

I would investigate account determination (VKOA) first, since it maps condition types to GL accounts using account keys, not the access sequence itself. Correct pricing values with wrong GL posting typically point to a mismatched condition table in VKOA (e.g., wrong account assignment group, material group, or account key ERL/ERS), or the account key assignment in the pricing procedure being misconfigured. Access sequences only determine price values, not the accounting destination.
mediumPricing

16. A sales rep enters a customer's expected price on an MTO sales order item that differs from the system-calculated price, and the item category in use is configured with pricing type that normally allows manual price overrides. What is the interaction between the expected price field and item category determination, and how would you ensure the discrepancy is flagged for review rather than silently accepted?

The expected price field is a comparison value stored on the item, independent of the pricing procedure output; it does not alter pricing unless a manual condition is entered. Item category determination itself is unaffected by expected price, but the incompletion procedure should include the expected price comparison field or a custom check to flag variances above a tolerance. Configure incompletion group at item level for MTO-relevant categories so orders with a meaningful expected-vs-actual price gap route to a review status before confirmation.
mediumPricing

17. In a pricing procedure, how do the 'From' and 'To' step columns work with subtotal and requirement fields to control condition calculation?

'From' and 'To' columns define ranges of steps used as a base for calculating a condition, such as summing net price and freight before computing tax. Subtotal fields route intermediate results into fields like KOMP-KZWI1 for later use (e.g., statistics or copying to billing). Requirement routines (VOFM) control whether a condition step is executed at all based on business logic, preventing unnecessary or invalid calculations, like skipping tax for tax-exempt customers.
mediumPricing

18. A shipping condition record for freight (KF00) is not being determined correctly for a specific plant-route combination, causing incorrect freight charges to post to revenue accounts. How would you use condition tables to diagnose this?

I would check the access sequence for KF00 to identify which condition tables are checked and in what order (e.g., shipping point/route, route/weight group). Using VK13 or condition analysis in the sales order, I'd trace which table returned no match, then verify the specific condition record exists for the plant-route combination with correct validity dates and scale. If the table structure lacks the required fields (like route or shipping point), I may need a custom condition table added to the access sequence, ensuring correct sequence positioning to avoid conflicts with existing entries.
mediumPricing

19. How is the customer expected price used in sales order line items, and how does it interact with the incompletion procedure when it deviates from the system-calculated price?

Customer expected price is a manually entered field on the order item representing what the customer believes they will be charged (common in configurable/MTO scenarios or when a legacy quote price is referenced). SAP compares it against the pricing-determined net price; if the deviation exceeds a tolerance, the item can be flagged incomplete via the incompletion procedure, forcing the order processor to review and either confirm the deviation or correct pricing before the order can proceed to delivery/billing.
mediumPricing

20. A global company shares a single condition table for revenue account determination (VKOA access sequence) across multiple sales organizations, but one division now needs a different GL account for the same material/customer combination due to a new reporting requirement. How would you diagnose and redesign the condition table setup without disrupting other divisions?

First confirm which VKOA access sequence and condition table currently drive account determination (commonly account assignment group of customer/material plus sales org/chart of accounts). Since the shared table lacks a field to differentiate the division, I'd check whether a distribution channel, division, or account assignment group field can be added or already exists but is unpopulated in master data. I'd create a more specific access (e.g., including division) ranked before the generic access, populate condition records only for the division needing the new account, and regression test that other divisions still hit the original generic access unchanged.
hardPricing

21. During a post-merger integration, two legacy access sequences for the same condition type PR00 need to be consolidated without disrupting thousands of existing condition records. What approach would you take to redesign the access sequence safely?

I would map the field combinations (condition tables) used in both legacy access sequences, identify overlapping and unique tables, then design a consolidated access sequence preserving all necessary tables in correct priority order (most specific to most general) to avoid changing which record wins for existing scenarios. Existing condition records remain valid since they're stored independently of the access sequence; only the sequence of table checks changes. I'd test extensively with condition analysis across representative order scenarios before cutover, and avoid deleting legacy tables prematurely to prevent record orphaning.
hardPricing

22. A customer-specific discount condition record exists in VK13 but is not being picked up in the sales order pricing screen despite matching all key fields. Outline your systematic troubleshooting approach using the condition technique.

Check pricing analysis (Item > Conditions > Analysis) in the order to see why the condition was excluded, e.g., requirement routine failing, exclusion group conflict, or validity date mismatch. Verify the condition type is included in the pricing procedure assigned to the document's pricing procedure determination (sales area + customer pricing procedure + document pricing procedure). Confirm the access sequence table sequence and exclusive indicator, check if a higher-priority table already found a record via 'exclusive' access, and verify field catalog values match order data exactly, including case sensitivity and organizational data.
hardPricing

23. In a complex billing scenario using graduated (interval) scales on a pricing condition, how does the scale basis (quantity vs. value) affect the final calculated amount, and what implementation pitfalls should be anticipated?

Graduated scales calculate each portion of the quantity/value at its respective scale rate (unlike 'to' scales that apply one rate to the whole amount), so total price is the sum across intervals. Scale basis (B for value, C for quantity, D for gross weight, etc., configured in V/06) determines what triggers the scale lookup. Pitfalls include mismatched scale basis versus the condition's calculation basis causing wrong tier selection, currency conversion issues in value-based scales, and scale master data maintenance errors in VK11/VK12 that silently default to the lowest tier.
hardPricing

24. You need to design condition tables for a complex pricing scenario where discounts vary by customer group, material group, and sales organization simultaneously, but performance and maintainability are both concerns. What design approach would you take?

Design a condition table with a field sequence ordered from most selective to least selective (e.g., sales org, customer group, material group) to optimize database access performance, avoiding overly generic tables that cause large KONV/condition record volumes. Use existing standard tables where field combinations already exist rather than creating redundant custom tables, and combine access sequence steps so specific combinations are checked before falling back to more generic ones, balancing maintenance effort against granularity, while considering condition record volume impact on system performance.
hardPricing

25. A global customer needs volume-based pricing where the discount percentage increases as cumulative order quantity across multiple orders in a month grows. How would you design this using scales, and what limitation must you flag to the business?

I'd configure a graduated or interval scale on the discount condition record, but standard scales operate per single document/line item, not across multiple orders. To achieve cumulative monthly quantity-based pricing, I'd recommend combining scales with a rebate or settlement management (or condition contract management in S/4HANA) approach that accumulates quantities over a period and settles retroactively, since real-time cross-order scale accumulation isn't natively supported by simple condition scales.
hardPricing

26. A retailer sells the same material through both wholesale and e-commerce channels, and finance requires revenue to post to different G/L accounts by channel while using a single material master. How would you design revenue account determination to achieve this without duplicating materials?

Configure VKOA condition tables including a field that differentiates channel, such as sales organization/distribution channel or a custom account assignment group derived from the sales document's distribution channel rather than only material's account assignment group. Maintain separate condition records per account key (ERL) and distribution channel combination so the same material posts to different revenue accounts based on which channel processed the sale, avoiding the need for material duplication.
hardPricing

27. Free-of-charge deliveries are posting to revenue accounts unexpectedly instead of being fully cost-absorbed. As the architect, how do you diagnose and correct the sales document type and pricing configuration?

Check the sales document type (e.g., FD) and ensure item category is set with billing relevance blank or set to not relevant for billing, and pricing procedure determination assigns a procedure with 100% discount condition (R100) that zeroes the net value—not just a discount reducing it partially. Also verify item category assignment isn't defaulting to a standard TAN-based category. Statistical value should still populate via condition type VPRS/cost, but net value must be zero to prevent revenue recognition and avoid COGS/revenue mismatch in Universal Journal.
hardPricing

28. A pricing procedure includes a discount condition type with an access sequence containing three access steps, each flagged as 'Exclusive'. Business users report that for a key account, the system picks a less specific condition record from a later access step instead of a highly specific customer/material record that exists in an earlier step, resulting in an incorrect discount amount flowing into the billing document and posting to FI-AR. As the architect, how would you diagnose this?

I'd check the access sequence step sequence and 'Exclusive' indicator settings first — an exclusive flag on an earlier step stops the search entirely once any record is found at that step, even a less specific/generic one, skipping more specific later steps. I'd use pricing analysis (condition technique log) in the order to see which access step actually returned a hit, verify the field combination and validity of the specific record, and confirm access step sequencing matches the intended specificity hierarchy (most specific first). Correcting sequencing order or removing the exclusive flag resolves it.
hardPricing

29. After a global rollout, one region reports that billing documents fail pricing with 'no condition record found' while another region works fine using the same pricing procedure. How would you diagnose whether the condition table structure is the root cause?

I would first compare the access sequence and condition tables assigned for the affected condition type across both regions to check if the failing region requires a field (e.g., plant, sales org, or a custom Z-field) not populated on those orders. Using condition analysis in the sales order or VK13 to check existing records for the exact key combination confirms whether the table's key fields don't match master data setup in that region, requiring either a broader condition table or master data correction.
hardPricing

30. A global rollout is experiencing inconsistent pricing results across countries using a single shared pricing procedure, with some countries seeing incorrect tax conditions applying alongside manual discounts. As the architect, how would you redesign the pricing procedure structure to resolve this?

I would evaluate whether a single shared pricing procedure is appropriate versus country-specific procedures determined via sales area (sales org/distribution channel/division) combined with document pricing procedure and customer pricing procedure keys. Root cause is likely condition exclusion groups or requirement routines not properly scoping country-specific tax conditions (e.g., MWST vs country-specific tax conditions) and step/counter sequencing causing manual discounts to interact incorrectly with subtotals feeding tax base. I'd introduce condition exclusion groups, alternative calculation type routines, and separate procedures per country/tax jurisdiction while keeping a common base structure for maintainability.
hardPricing

31. A mass condition record upload for a promotional price changed values across multiple sales organizations, but two regions unexpectedly retained old prices in new orders. What condition record attributes would you check to explain this?

I would check the validity periods, scale basis, and release status of the uploaded records for those two regions, since a mass upload can create overlapping validity periods where an existing more specific record (lower access sequence step or narrower key combination) still wins over the new one. I would also verify whether those regions use a different sales organization or distribution channel key combination not covered by the uploaded condition table, causing the system to fall back to the previous record.
hardPricing

32. A multinational client uses customer hierarchies for pricing and rebate aggregation, but after an MDG-driven mass restructuring of customer nodes, condition records at higher hierarchy levels stopped applying to certain subsidiaries. How would you diagnose and fix this?

First check whether the hierarchy assignment (customer node and validity dates) for the affected subsidiaries was correctly re-linked after the MDG restructuring, since a broken or gapped node assignment stops pricing inheritance. Verify the hierarchy type and partner function used for pricing (commonly hierarchy node as a pricing-relevant partner) is still valid, and confirm condition records were maintained against the correct new node, not the retired one. Also check date validity overlaps and whether the hierarchy change was replicated timely to the pricing-relevant customer master fields.
hardPricing

33. During month-end, users report that a specific discount condition record is being ignored for certain orders even though it's active and within its validity dates. As the architect, how do you systematically diagnose this?

I'd start with pricing analysis (condition analysis in the order/billing document) to see which access was attempted and why it failed—common causes include exclusion indicators on higher-priority conditions, scale basis mismatches, or requirement routines suppressing the step. I'd also check if condition exclusion groups or the pricing procedure's exclusive indicator caused a competing condition to win. Finally, I'd verify the condition record's specific key combination matches order data exactly, including sales area, currency, and unit of measure, since silent mismatches are a frequent root cause.
hardPricing

34. In a make-to-order scenario, how does customer expected price functionality reconcile a customer's anticipated price with the system-calculated pricing during ATP and requirements transfer, and what are the risks if this is misconfigured?

Customer expected price (condition type EDI1/EDI2 or manual entry in the order) allows the price the customer expects, often from an EDI order or prior quotation, to be compared against system-determined pricing; discrepancies beyond tolerance trigger a block (e.g., billing block or incompletion) for manual review rather than silently overriding pricing. If misconfigured, tolerance limits set too wide can let material price deviations pass unnoticed, while too narrow tolerances create excessive manual intervention, delaying requirements transfer to MRP and downstream production for MTO items.
hardPricing

35. In a billing configuration where freight is calculated using a shipment cost document and taxes must be recalculated at invoice time, what sequencing and condition-type design issues typically arise, and how are they resolved?

Freight from shipment costing often transfers into billing via a freight condition type (e.g., KF00) copied from the shipment cost document, but tax calculation must occur after freight is included in the pricing procedure so tax base reflects freight-inclusive value where legally required. Sequencing issues arise if freight is added after tax subtotal is fixed; resolution involves placing freight condition before the tax subtotal line and ensuring the tax condition (e.g., MWST) references the correct subtotal via 'from-to' steps.
hardPricing

36. Following a merger, two legacy entities each used their own pricing procedures with different condition exclusion group configurations for the same discount conditions. After template consolidation onto one shared pricing procedure, one legal entity now sees a different 'best price' selection outcome than before, causing inconsistent net values and downstream revenue recognition treatment across entities using the same customer and material. As the architect, how would you approach resolving this?

I'd first document each legacy exclusion group's logic (best condition among a group vs. exclusion between groups) and compare against the consolidated procedure's exclusion group assignments, since exclusion groups directly change which condition 'wins' when multiple valid records exist. I'd run parallel pricing simulations for representative order combinations from both legacy entities against the new procedure to identify divergence, then decide whether to harmonize business rules (single exclusion policy) or use procedure determination by sales area to preserve entity-specific logic where legally/commercially required, documenting the impact on revenue recognition.

Related lesson

Pricing Routines, Requirements, and Alternative Calculation Types

Related topics

Advanced SD Scenarios, Integration and Production SupportS/4HANA SD Transformation, Migration, Public Cloud and ArchitectureEnterprise StructureBillingCustomer and Business PartnerOutput ManagementSchedule Line CategoriesItem CategoriesCopy ControlCredit ManagementAvailability CheckSales Documents

Next practice step

Practice with Interview AITake a mock test