You Already Own SAP Condition Contract Management. Why Is the Accrual Still a Guess?
If you run S/4HANA, you already own Condition Contract Management. It came with the migration; it replaced the deprecated SD rebate agreements (VBO1/VBO2 are gone, and they are not coming back); and your integrator was right to turn it on. This article is not going to tell you CCM is bad. It is going to explain why, with CCM configured correctly and running well, your quarterly rebate accrual can still be a number the controller has to defend with a spreadsheet.
Start with what CCM genuinely does well
Settlement management in S/4HANA is a real advance: condition contracts unify purchasing- and sales-side programs under one object, settlement documents post cleanly through the ledger with document flow intact, delta accruals let you post the movement since the last run instead of reversing and re-posting, and the business partner model ends the old sold-to/payer contortions. For flat-rate programs with clean scope — X% on qualifying revenue for a defined partner set — CCM calculates, accrues, and settles with the reliability you'd expect from the ERP's own machinery. If that describes your programs, you should stay native; running a second system for programs CCM handles is cost without benefit.
Where the accrual becomes a guess
The accrual becomes a guess at the point where the program stops looking like a condition record. Three specific ceilings, all structural.
1. The finishing-rate estimate has no home. A tiered program with retroactive attainment accrues correctly only at the rate the customer is expected to finish at — that is what variable consideration under ASC 606 requires. A condition record stores the rate that applies now, per the contract's tier table. It has no native concept of "we believe this customer finishes in tier 3, here is why, here is who decided that, here is when we revised it." So the estimate lives outside — in a planning spreadsheet that feeds manual accrual adjustments — and the moment it does, the ERP number and the controller's number are two numbers. Every close reconciles them by hand.
2. Eligibility outgrows condition technique. Growth incentives measured against a prior-year baseline, program scope defined by customer hierarchy as it stood at a point in time, exclusions that depend on claim history rather than order attributes — these are questions condition tables were never built to answer. The standard workaround is pre-processing in custom code or spreadsheets that compute the qualifying base and hand CCM a simplified version of reality. The calculation still happens; it just happens where the audit trail isn't.
3. Retrospective recalculation is a batch event, not a query. When a baseline is corrected or a hierarchy is backdated, the question auditors actually ask is: what did we know when we booked Q2, and what should Q2 have been on today's data? Document flow can show what posted; it cannot replay the calculation as-of two dates and show the difference decomposed by cause. Reconstructing that answer from change documents and settlement history is possible — it is also days of specialist work, per question.
The pattern across all three
CCM is the system of record for what posted. The accrual problem needs a system of record for what was calculated, estimated, and decided — including the estimates that never post anywhere. Those are different jobs. Configuring CCM harder does not close the gap, because the gap is not configuration; it is that estimates, baselines, and eligibility decisions are not condition records and never will be.
What good looks like
Principles, whatever tooling you choose: the finishing-rate estimate recorded as a decision with an owner and a revision history; the qualifying base computed in one governed place, with the definition versioned; corrections applied by supersession so the number you certified at close still exists after the data moves; and the ERP kept as the posting authority — shell settlement documents in, ledger postings out, no second general ledger. If you run SAP, that means a calculation layer that reads SAP data and writes SAP-consumable settlement documents, leaving CCM's settlement machinery doing what it is genuinely good at.
The test
Ask whoever owns the accrual to reproduce last quarter's number, today, with its evidence, decomposed into estimate vs. actuals vs. base changes. If the answer is a query, your accrual was never a guess. If the answer is a project, you have found the boundary — not of your team's competence, but of what condition records were designed to know. (The same boundary, seen from the close: why doesn't my rebate accrual match my settlements?)