KONA table — Agreements Header (Classic Rebate / Sales Deal / Purchasing Agreement)

One row in KONA represents one agreement header, created through the rebate agreement transactions, or through the sales deal and promotion transactions that share the same condition-technique framework. The row carries the agreement type, which controls how the agreement behaves and settles, the validity period, the sales area the agreement is valid for, the currency, and the customer treated as the rebate recipient or the agreement's owning partner. KONA does not store the rebate percentages, scale rates, or accrual amounts. Those are held in ordinary condition records, created and maintained under the agreement, and linked back to it through the agreement number embedded in the condition table used for that agreement type. Reading KONA alone tells whether an agreement exists and is valid, not whether it is producing any financial effect.

MANDT is mandatory on every direct select. KONA is small relative to sales document tables, one row per agreement rather than per line, so it is rarely the volume problem. The selectivity to use is BOART together with VKORG, VTWEG, SPART and KUNNR, then DATAB and DATBI to confirm the agreement is actually valid on the date in question. Never assume an agreement is currently active just because it exists in KONA, an expired DATBI or a not-yet-started DATAB is the single most common reason an expected rebate condition does not appear. The real volume and performance risk sits in the condition record tables generated under the agreement, not in KONA itself.

Symptom: rebate accrual stopped appearing on new sales orders for a customer, even though the business believes the agreement is still running. Select from KONA where KUNNR equals the customer, VKORG/VTWEG/SPART match the order's sales area, and check DATBI against the order date and DATAB against it as well. If DATBI is in the past, the agreement has expired regardless of what the business assumes. If no row is returned at all for that sales area, the agreement was never valid there, or BOART points to a type not relevant for that order's pricing procedure.

SAP's S/4HANA simplification guidance states that classic SD Rebate Processing is generally not available as the target model and is replaced by Settlement Management. Existing rebate agreements can be completed in supported conversion scenarios, while new agreements use condition contracts. KONA can still appear for classic or purchasing agreement scenarios, but should not be presented as unchanged strategic rebate persistence.

The SD functional consultant responsible for pricing and rebate configuration owns questions about agreement type behaviour, validity handling, and why a specific agreement is not producing accrual. Master data ownership for the customer's sales area extension sits with the customer master data team, and a mismatch there is frequently the true root cause behind a rebate that looks correctly configured but never fires.

KONP and KONH hold the actual condition rates and header data for the records created under a KONA agreement. KNA1 and KNVV hold the customer master data the recipient must be correctly extended into. VBRK carries the settlement billing documents generated once an agreement is settled. The rebate agreement itself is created, changed, and displayed through the dedicated rebate agreement transactions, while sales deals and promotions built on the same table use their own separate transaction codes.