KONA table — KONA Agreement Header Table for Rebates and Deals

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.

KONA is present and populated the same way on S/4HANA as it was on ECC, and classic rebate processing, sales deals, and promotions built on it continue to function. SAP's newer settlement management capability, built on condition contracts, is a separate object model and does not use KONA. Existing implementations that migrated classic rebate agreements from ECC generally keep using this table unchanged, new implementations are steered toward the newer settlement approach, but that is a design decision made at project level, not something forced by the table itself.

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.