Classic SD Rebates Retired For Condition Contracts

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom reports and extracts built against the classic rebate agreement condition tables return nothing or break once agreements are converted to condition contracts, because the data now lives in a different structure.
• Custom ABAP or interfaces reading the rebate index table used to identify rebate-relevant billing documents stop finding matching records after cutover.
• Scheduled batch jobs for rebate settlement need to be replaced with condition contract settlement jobs; if the job chain is not updated, month-end accrual settlement silently stops running and nobody notices until accruals pile up.
• Rebate administrators and revenue managers who know the classic agreement screens face a different application entirely, with different navigation and terminology, and need retraining rather than a quick orientation.
• Finance teams reviewing accrual accounts have to revalidate account determination, because condition contracts can pick different G/L accounts or key combinations than the classic accrual key did.
• Authorization roles scoped to the old rebate transactions do not cover the new condition contract applications and have to be rebuilt.
• Open rebate agreements that straddle the cutover date are the hardest case: partially settled agreements with multi-year validity periods need an explicit decision, not a default technical conversion.
• Any external rebate calculation or business intelligence extract keyed to the old tables needs redesign against the condition contract model.

Migration actions

• Inventory every active and open rebate agreement, including validity period and current accrual balance. This is a pre-conversion gate, not optional cleanup, because agreements open across the cutover date force a decision before the technical conversion runs.
• Decide the cutover strategy per agreement population: settle and close everything before go-live where feasible, or migrate open agreements into condition contracts with mapped accrual balances where closure is not practical.
• Run the relevant readiness check for rebate processing before starting the technical conversion; treat a failed check as a blocker, not a warning to review later.
• Redesign condition contract master data: contract types, settlement calendars, and condition types mapped from the classic rebate condition types being retired.
• Rebuild custom reports and interfaces away from the classic agreement and index tables onto the condition contract data model.
• Rebuild the batch schedule for settlement runs under the new process before the first post-conversion month-end.
• Retrain rebate administrators, revenue management, and the finance staff who review accrual postings.
• Test the full cycle end to end, including creation, accrual through billing, partial settlement, final settlement, and reversal, using production-scale agreement volumes rather than a handful of test agreements.
• Reconcile accrual account balances before and after conversion before signing off.

Whose problem this is

Common pitfalls

• Treating this as a pure technical lift-and-shift and only raising the question of what to do with multi-year open agreements after the conversion has already run, when the answer needed to come first.
• Testing conversion and settlement cycles with a small handful of agreements while production carries thousands with years of accrual history, so real conversion runtime and data volume are discovered too late.
• Custom pricing routines keyed to the classic rebate relevance indicator on the customer or billing document stop firing once that indicator is no longer maintained the same way, and pricing quietly drops rebate-relevant flags.
• Accrual account balances fail to reconcile after conversion because the new condition contract determination logic resolves to a different account or key combination than the classic accrual key did.
• Compatibility mode gets treated as a permanent solution instead of a bridge, and the problem resurfaces unexpectedly when that compatibility scope is eventually withdrawn.
• Settlement documents generated under the new process default into an unexpected document type, which confuses downstream credit memo release and billing block handling that teams assumed would carry over unchanged.