BSET table — BSET Tax Data Table in Accounting Documents

Each row in BSET represents one tax calculation result for one accounting document: a specific combination of company code, document number, fiscal year, tax code and condition type, together with the base amount the tax was calculated on and the resulting tax amount, in both local and document currency. A single invoice with two different tax codes produces two rows in BSET, not one. The table is populated automatically during posting whenever a document contains at least one line with a tax code, whether the tax is calculated by the system or entered manually. It exists independently of BSEG because a document's tax lines are a derived, aggregated view of the tax-relevant items, not a one-to-one copy of the posting lines themselves.

BSET is client-dependent and keyed at document level, so it can grow to the same order of size as BSEG in a mature system. Never select from it without at least BUKRS and a GJAHR restriction; adding a BELNR range or a posting date filter joined through BKPF is what keeps the query usable. Do not attempt to filter directly on HWSTE or HWBAS with a range unless the currency and sign convention have been confirmed first, since amounts carry SHKZG-driven sign logic that differs from how the same amount appears in BSEG. When comparing tax amounts across documents, always compare within the same currency field consistently, either local or document currency, never mixing HWSTE and FWSTE in the same calculation.

To confirm a suspected wrong tax amount on an invoice, select BSET restricted to BUKRS, BELNR and GJAHR of the document in question, and inspect KSCHL, MWSKZ, HWBAS and HWSTE for every row returned. If more than one row appears with different tax codes, the document contains mixed tax treatment across its line items, which explains why a single expected tax percentage does not reconcile against the total. Cross-check HWBAS against the sum of the tax-relevant BSEG lines carrying the same MWSKZ to confirm the base was calculated correctly before assuming the tax code configuration is wrong.

BSET continues to exist as a table in S/4HANA and is still populated on posting for compatibility with tax reporting programs and interfaces that read it directly. The line-item detail that used to require joining BSET to BSEG is now also available directly in ACDOCA, which carries tax code and tax amount fields at the universal journal line level, so newer custom reports and CDS-based tax analysis tend to read ACDOCA instead. Existing tax reports built against BSET generally continue to work unchanged.

Discrepancies in BSET amounts are first a tax configuration question, owned by the FI consultant responsible for tax code and condition setup, before they become a program or interface issue. If the base amount itself looks wrong, the question shifts to whoever owns pricing or invoice creation upstream, since BSET only reflects what was handed to the tax calculation, not why that amount was calculated that way.

BKPF and BSEG are the header and line item tables every BSET row ultimately belongs to, written by the same posting transactions such as invoice entry or payment posting. T007A holds the tax code master configuration referenced by MWSKZ, and T030 supplies the automatic account determination that decides which general ledger account the tax amount lands on, which in turn shows up on SKB1 and SKA1 for that account.