T007A table — Tax Keys Table T007A
T007A is the tax code master table. One row represents a single tax code defined for a country, together with its tax type (output, input, and so on) and control indicators used when the code is applied on a document. It does not store the tax percentage rate itself; that lives in the condition records tied to the tax calculation procedure, maintained through the same FTXP transaction.
This page covers what T007A stores, the fields a consultant actually queries, how it joins into the posting and tax tables, and the recurring mistake of treating it as the source of tax percentages when it only holds the code definition. It also covers where the table sits in S/4HANA and who owns changes to it.
Published 15 Sept 2026· 963 words
What it stores
Each row in T007A is one tax code defined for one country: the two-character code (MWSKZ) that appears on every FI and MM document line carrying tax, scoped to a country (ALAND) and classified by tax type (MWART) as output tax, input tax, or one of the other categories SAP supports. The row also carries control indicators that govern how the code behaves when it is used in posting and reporting. T007A is maintained through the FTXP configuration transaction, usually as the first step before assigning condition records for the actual rate. A tax code can exist in T007A and still produce a zero-rate posting, or fail entirely, if the rate condition record for that code and procedure was never created. The table answers 'does this tax code exist, for which country, and as what type' - nothing about the percentage.
Key fields
- MANDT - client
- ALAND - country key the tax code is defined for; a code with the same MWSKZ can exist independently in another country
- MWSKZ - the two-character tax code used across FI, MM, and SD documents
- MWART - tax type indicating whether the code is output tax, input tax, or another supported category
- PRUEF - check indicator controlling additional validation on the code (confirm on the FTXP screen before relying on it in a query, spelling on some releases varies)
How it joins the data model
- bseg-mwskz = t007a-mwskz to resolve the tax type and country behind the code posted on a line item
- bset-mwskz = t007a-mwskz to join the document's tax breakdown lines back to the code definition
- acdoca-mwskz = t007a-mwskz for the same lookup against the universal journal in S/4HANA
- t001-land1 = t007a-aland to confirm the tax code's country actually matches the posting company code's country
How to read it safely
T007A is small and client-dependent; always restrict on MANDT and, whenever possible, on ALAND before browsing, since the same MWSKZ value is reused across countries with completely different meanings. MWSKZ alone is not selective enough to identify a unique row - country plus code together are the real key. Do not attempt to read a rate or percentage out of this table; there is nothing here to read for that purpose, and any join that expects one will return blanks that look like an error but are not.
How to prove it in the data
Symptom: a posting fails with an unknown or invalid tax code error, or a report shows a tax code the business claims does not exist. Select T007A on MANDT and MWSKZ; if no row comes back for the country in question, the code genuinely does not exist there, even if it exists under the same value in another country. If the row exists but MWART does not match the direction the document expects (input versus output), the code was used on the wrong side of the transaction.
ECC vs S/4HANA
T007A survives unchanged in S/4HANA as a configuration table maintained through the same FTXP transaction. It is not replaced by a CDS compatibility view because it is master/config data rather than a transactional table. Tax codes stored here continue to be referenced from the universal journal (ACDOCA) via MWSKZ exactly as they were referenced from BSEG and BSET in the classic ledger tables.
Common pitfalls
- Assuming the existence of a row in T007A means the tax code is fully usable. It only confirms the code and its type exist; the rate condition record for the assigned tax procedure can still be missing, giving a zero-percent posting that looks like a configuration bug elsewhere.
- Querying MWSKZ without restricting on ALAND. The same two-character code is commonly reused across countries with unrelated tax types, so a match found in the wrong country leads to a wrong conclusion about why a document failed.
- Confusing tax type (MWART) with the account key or transaction key used for automatic account determination. T007A tells you the code is output or input tax; it says nothing about which GL account the tax amount lands in.
- Treating a code that exists in T007A but was later blocked or restricted as still fully active without checking the relevant control indicator on the FTXP screen directly, since not every restriction is obvious from a raw table dump.
- Trying to explain a jurisdiction-code-based tax discrepancy (US-style tax) purely from T007A. Jurisdiction determination depends on additional configuration outside this table, and T007A alone will not explain a jurisdiction mismatch.
Whose problem this is
New tax codes and their type/country combination are a finance configuration decision, typically owned by the FI tax or GL configuration lead in coordination with the local tax or statutory reporting team. A technical FI consultant maintains the FTXP entries; the business decides which rates and codes are legally required for a given country.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t007aERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.