What happens to SAP SD rebate processing in S/4HANA?

What SD rebate processing was, and why SAP replaced it

In ECC, a customer rebate lived in a rebate agreement (VBO1, VBO2, VBO3) with an agreement type such as customer, material, group, or hierarchy rebate. Rebate condition types BO01 to BO06 sat in the pricing procedure, accruals posted with every billing document, and settlement produced a rebate credit memo request (document types B1 for final and B3 for partial settlement) that was then billed. Retroactive agreements depended on the rebate index table VBOX, which had to be rebuilt through VBOF or report SDBONT06 whenever an agreement was created for a period that already had billing documents.

That design tied rebates to SD pricing and to SD billing types, which made it hard to extend to supplier rebates, to non-billing business volume, or to programs settled on anything other than a credit memo. Settlement Management, which SAP built first for trading and retail scenarios, generalizes the pattern: a condition contract defines the partner, the eligibility criteria, the conditions, and the settlement calendar; a settlement run selects the qualifying business volume and generates settlement documents that post to FI directly. S/4HANA made this the only path for new rebates and retired the old one as a simplification item.

What actually happens to open agreements at conversion

The Simplification Item Check flags the SD rebate item when the source system carries rebate agreements. The conversion itself does not migrate them into condition contracts; there is no transformation. Existing agreements remain readable and can be settled up to their validity end date, at which point a final settlement closes them. What you lose immediately is the ability to create new agreements or extend old ones, so any annual program that would normally be renewed in VBO1 has to be re-created as a condition contract before the renewal date, and the business volume rules have to be re-expressed in the condition contract's selection criteria rather than in rebate-relevant flags on the customer master and sales organization.

Two consequences catch projects out. First, if the conversion lands mid-year, sales will be running two mechanisms in parallel for the rest of the year: old agreements settling through credit memo requests, new contracts settling through settlement documents, with different FI postings and different reports. That is manageable if it is planned and confusing if it is discovered. Second, the extended rebate processing enhancement, which some ECC estates used for variable-key rebates, has no equivalent; those programs need to be re-modelled from the business rule rather than mapped from the configuration.

Why this is a process decision, not a data task

Every configuration object in classic rebate processing encoded a business decision that the migration now reopens. The condition contract model asks the same questions in a different vocabulary, and the honest answer is often different from what ECC was doing.

• Accrual policy. ECC accrued through the pricing procedure on every invoice. Settlement Management accrues through its own delta-accrual settlement runs, which means finance chooses the cadence explicitly. Some controllers prefer that; others discover their month-end has assumed invoice-level accruals for years.
• Business volume definition. A condition contract selects business volume by criteria such as customer, customer hierarchy, material, or material group, evaluated at settlement time from posted documents. Rules that were implemented in ECC as rebate-relevance flags, pricing requirements, or a user exit have to be restated as selection criteria or they silently stop applying.
• Settlement cadence and output. Partial, delta, and final settlements are scheduled on the contract's calendar and produce settlement documents rather than sales documents. Anyone whose reporting, approval workflow, or customer statements keyed on document types B1 and B3 has a change to absorb.
• Unification with purchasing. Supplier rebates and other vendor conditions run through the same condition contract types. A migration is the natural moment to put customer and supplier programs on one framework with one settlement calendar, but it is a decision, not a default.
• Custom code. Pricing user exits that manipulated BO01 to BO06, custom reports over KONA, KONP, and VBOX, and interfaces that exported rebate accruals all point at objects that either change meaning or stop being populated. Each one is a retire, re-implement, or replace decision.

Reading the impact from the live system before you plan it

The information a project needs is all in the ECC system: which agreement types are in use, how many are open and how far their validity runs, which billing types are rebate-relevant, which condition types appear in which pricing procedures, and which custom objects reference the rebate tables and condition types. Collected by hand it is a two-week workshop exercise. Read through governed, read-only tool calls against the live system it is an afternoon, and it comes with evidence attached to every finding rather than a slide that says rebates are in scope.

Our agents do exactly that read: agreement inventory and validity horizon from the live tables, the pricing procedures that carry rebate condition types, and a where-used pass over the custom objects that touch them, with the business rule inside each object read from source. On a reference estate, a live ECC system we use to validate the method rather than any customer's result, 44% of custom objects were retirement candidates, and logic that exists only to feed a function S/4HANA replaces is exactly the kind that lands in that bucket. A customer's numbers come from their own system. Where the outcome is target configuration, such as condition contract types, settlement calendars, or profiles, the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never touching production on its own. A functional-testing agent that would run a converted program end to end against the volume the old agreement carried is in build and design preview, not shipped.

A working sequence

Start with the inventory: every open rebate agreement, its type, its validity end, and its settlement history, plus the pricing procedures and billing types that reference rebate condition types. Put a sales owner and a finance owner on the list together, because the accrual question is theirs to settle before anyone configures anything. Design the condition contract types and settlement calendar against the real programs, not the delivered examples. Decide the cutover rule for the overlap period explicitly: which agreements run out under the old mechanism, which are closed early with a final settlement and re-created as contracts, and how the two sets are reported side by side. Then map each custom object to retire, re-implement, or replace, and let the where-used evidence rather than the developer's memory decide.

SAP's own direction points at the same discipline. The agent-led transformation capabilities SAP announced at Sapphire 2026, with a stated reduction of more than 35% in migration effort (SAP News), target precisely this class of simplification item, where the technical change is small and the process change is the real work. Whether that runs inside RISE with SAP or as comparable agentic tooling on an S/4HANA estate a customer operates on AWS is an ownership choice. The rebate decision itself does not change: the old mechanism runs out, and the business chooses what the new one does.