Rebate Accrual Posting to Wrong GL Account

Finance reports that the rebate accrual balance on a customer or material group does not match what sales expects, or that a G/L account they do not recognize is picking up rebate postings. Sometimes it surfaces as an accrual that never shows up at all, so the rebate agreement's accrued value stays at zero even though billing documents are being created against it. Controlling asks why the cost of sales or revenue deduction account is absorbing what should be a balance sheet accrual. The sales rebate team sees the agreement in the rebate transaction showing accrued amounts, but the FI document attached to the billing document shows the offsetting entry landing somewhere unexpected, often a default or suspense account, or occasionally the standard sales revenue account with no accrual line at all.

Pull the billing documents for the affected rebate agreement and run account determination analysis on each to list the condition type, account key, and G/L account actually posted, then compare against the account key expected on the pricing procedure and the G/L account expected from VKOA for that combination. A pattern where the accrual condition type consistently resolves to a revenue or suspense account rather than the accrual liability account confirms the determination gap rather than a one-off posting error.

If the account key is missing or wrong on the pricing procedure control line, that is a config change to the pricing procedure requiring a transport through the landscape, and it affects every future billing document using that procedure, so it needs regression testing against other condition types on the same procedure. If the account determination table entry for the account key is missing, that is normally treated as customizing data maintained directly in VKOA; whether it needs a transport depends on how the landscape classifies account determination tables, but it should never be corrected only in production without also correcting the source system. If the condition type is not accrual-relevant, changing that flag is a cross-client config change with wide impact and needs careful review before transport, since it changes posting behavior for every agreement using that condition type, not just the one in question. Master data corrections to account assignment groups are direct data fixes, no transport required, but should be checked for whether other open documents were also mis-posted before the correction. Existing wrongly posted accruals are not fixed retroactively by any of these changes; they require a manual reclassification or a rebate agreement update run to redistribute the accrual to the correct account going forward.

The reflex fix is a manual FI reclassification journal entry moving the balance from the wrong account to the correct accrual account at period end. It clears the balance sheet for that period but does nothing to the account determination logic, so the next billing run against the same rebate agreement posts to the wrong account again. Over several periods this produces a running reconciliation exercise that finance has to repeat manually, and it obscures the actual configuration defect from whoever eventually has to explain the recurring variance.

SD pricing and rebate configuration owns the account key assignment and condition type configuration; the FI general ledger team owns the account determination table entries and the G/L account master. The handover note should state the condition type, the account key involved, the exact account determination combination that was missing or wrong, the corrected G/L account, and the list of billing documents affected for any manual reclassification.