SAP SD / O2C Settlement Management Interview Questions

Interviewers use settlement management to test depth rather than coverage: the follow-up question is almost always "why does the system behave that way?", and that is where prepared answers usually run out.

Settlement Management covers the SD processes used to accrue, calculate and pay out volume-based agreements such as rebates, bonuses and condition contracts, spanning classic SD rebate processing in ECC and the redesigned Settlement Management (Condition Contract Management) framework in S/4HANA, including configuration, document flow, FI/CO integration, and production troubleshooting.

This page carries 8 reviewed SAP SD / O2C settlement management interview questions, each with a complete written answer and no sign-in required. The set breaks down into 1 foundational, 4 mid-level and 3 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.

If you can handle every question here without hesitating, settlement management is unlikely to be what costs you an SAP SD / O2C interview — and the same reasoning pattern transfers to the neighbouring topics linked at the bottom of this page.

8 Settlement Management questions with answers

easySettlement Management

1. What is a condition contract in SAP SD, and how does it differ from a standard sales pricing agreement?

A condition contract (transaction types under settlement management, e.g., in S/4HANA using apps for condition contract management) is a long-term agreement that accumulates business volume data over time and triggers settlement postings, typically rebates or extended agreements, rather than applying pricing directly at order/billing time like standard condition records. It supports periodic settlement runs, verification levels, and can create credit/debit memo requests based on accrued volumes.
mediumSettlement Management

2. A customer has a condition contract for volume-based rebates that must be settled periodically, but the shipping configuration team reports that partial deliveries against sales orders are causing settlement values to be understated. How would you investigate and correct this?

I would first check whether the condition contract's settlement basis pulls from billing document quantities/values rather than order quantities, since partial deliveries generate multiple billing documents over time and settlement should aggregate all relevant billings within the settlement period. I'd verify the condition contract's data source (billing document item category relevance) and settlement calendar, then confirm no billing documents were excluded due to incorrect item category or condition contract assignment at order/delivery level, and rerun settlement after correction.
mediumSettlement Management

3. During settlement of a condition contract, the resulting credit memo posts to an incorrect G/L account. What configuration areas would you check to resolve account determination for the settlement document?

I would verify VKOA account determination for the settlement's billing/credit memo type, confirming the account key from the pricing procedure's condition type maps correctly to G/L accounts by condition type, chart of accounts, sales org, account assignment group of customer/material. I'd also check the settlement document's document pricing procedure and pricing type used, and confirm the correct access sequence in the account determination table isn't picking a fallback entry.
mediumSettlement Management

4. How does a condition contract (e.g., rebate or settlement agreement) interact with VKOA account determination when settlement postings are generated in FI-AR, and what configuration ensures correct GL account derivation?

Condition contracts (transaction management, e.g. via WCONTRACT or condition contract settlement) generate settlement documents that trigger accrual and payment postings using account determination similar to standard SD, typically routed through account keys tied to the settlement condition type. VKOA must have entries for the relevant application (V/WCS), condition type, chart of accounts, sales org, account assignment group of customer/payer, and account key to ensure postings hit correct rebate accrual and clearing accounts rather than standard revenue accounts.
mediumSettlement Management

5. A customer's orders are fulfilled from two shipping points feeding into a single condition contract's business volume, but finance notices the settlement run is double-counting volume for deliveries split across both shipping points. As the architect, how would you diagnose and correct the business volume selection design?

I'd first review the business volume selection criteria in the condition contract to check whether it's filtering at the correct granularity, such as by sales order or billing document rather than by delivery, since a single order split across two shipping points could generate multiple deliveries and billing documents that each independently qualify. I'd check for overlapping or duplicate condition records across shipping-point-specific determination that both match the same billing line, and review whether shipping point was inadvertently included as a key field in the business volume selection, causing the same underlying sales volume to be counted once per shipping point instead of once per qualifying transaction.
hardSettlement Management

6. Describe the end-to-end settlement management process for a customer rebate agreement from accrual creation during billing through final settlement, and identify where billing configuration decisions impact the accuracy of the settlement.

During billing, rebate-relevant condition records accrue amounts per invoice based on the pricing procedure's rebate condition type, posting provisional accruals to FI via VKOA. Over the agreement validity, accruals accumulate against sales volume/value. At settlement, a credit memo request (or condition contract settlement in S/4HANA) is generated, comparing accrued vs. earned rebate, and a settlement document posts final payables/receivables. Billing configuration decisions—condition type scale basis, accrual rate accuracy, billing document pricing type, and copy control—directly affect whether accrual amounts reconcile with actual settlement liability.
hardSettlement Management

7. A condition contract settlement (rebate agreement equivalent) run produces settlement documents with amounts that don't match the accrued values posted during billing. As the architect, how would you approach root-cause analysis?

I would first compare the accrual condition type postings during billing (via the provision/accrual account key) against the settlement basis in the condition contract to check if the settlement period, business volume selection criteria, or condition records changed retroactively after accruals posted. I'd review the condition contract settlement calendar and business volume determination (from billing documents or a separate BW/CDS-based volume source) for scope mismatches, then check for manual adjustments or partial settlements that weren't reflected in FI reconciliation of the accrual account.
hardSettlement Management

8. During a settlement management run for volume rebate condition contracts, finance reports that accrual reversal amounts posted to FI do not match the settlement document amounts in SD. As the architect, how would you diagnose the root cause?

I would trace the settlement document's accrual postings against the original accrual condition records to check if the accrual rate or basis changed between accrual posting periods and final settlement, since rate changes or retroactive price changes cause mismatches. I'd also check whether partial settlements occurred with different accrual reversal percentages, and verify the account determination (VKOA) for accrual vs settlement condition types is correctly split, since using the same account key for both can mask discrepancies. Reconciliation between ACDOCA and the settlement document is essential.

Related lesson

Introduction to Settlement Management: Purpose, Business Case and Core Concepts

Related topics

Next practice step