Configuring Tax Codes, Condition Records, and Account Determination End to End
Walk through the practical configuration steps to build a working tax code, assign G/L accounts through automatic account determination, and trace how tax amounts post during document entry.
Explanation
Once the foundational concepts of tax procedures and codes are understood, the next step is configuring a tax code that actually calculates and posts correctly in a live document. This lesson focuses on the practical build sequence and the posting flow that results from it, which is essential knowledge for any FI consultant expected to support tax-related incidents or new country rollouts. The configuration sequence typically starts by confirming the tax procedure assigned to the country, since this determines which condition types are available (for example, a base amount condition, an output tax condition, and possibly a non-deductible input tax condition for countries with partial VAT recovery rules). The consultant then creates the tax code itself, specifying a percentage rate against the relevant condition type and marking the code as either input (V series conventionally) or output (A series conventionally) tax, though naming conventions vary by organization. A critical and often underestimated step is account determination. Tax amounts calculated by a tax code must post automatically to the correct general ledger accounts without requiring the user to manually select a G/L account during document entry. This is achieved through automatic posting configuration where each tax code (or a tax account key derived from the condition type) is linked to specific G/L accounts, potentially varying by chart of accounts or even by tax rate tier for granular reporting. Getting this account assignment wrong does not stop the document from posting — it simply routes the tax amount to the wrong account, which is far more dangerous because it can go unnoticed until a reconciliation or statutory filing reveals the discrepancy. Non-deductible tax handling deserves particular attention at this level. In some countries, a portion of input tax is not recoverable (for example, tax on entertainment expenses in certain jurisdictions) and must be capitalized into the expense or asset cost rather than posted to a recoverable tax account. This requires a distinct condition type and account key, and the consultant must ensure the non-deductible portion flows into the correct cost object rather than being lost or misclassified. Once configuration is complete, the runtime flow during document entry follows this path: a user posts a vendor invoice in MM or directly in FI, selects a tax code, the system reads the tax procedure to identify applicable condition types, calculates the tax amount based on the net base amount and the code's rate, and creates a separate tax line item posted to the account determined by the account key. This tax line item is visible in the document display and can be verified against expected calculations during testing. Troubleshooting at this level usually involves tracing why a tax amount posted to an unexpected account, why a tax code produced a zero-tax result, or why a rate change did not take effect on new documents. Common root causes include validity date issues on tax code rates, incorrect condition type sequencing in custom tax procedures, or account determination configured against the wrong chart of accounts variant used by the company code in question.
Real project scenario
During a VAT rate change project for a retail company, the finance team needed to introduce a new tax code with an updated rate effective from a future date rather than modifying the existing code's rate directly, which would have retroactively changed calculations on already-posted historical documents if misapplied. The consultant created a new tax code with the new rate, coordinated the effective date with the business, and updated automatic determination rules in SD so that new sales orders after the cutover date picked up the new code, while leaving the old code untouched for the historical reporting period.
Common mistakes
• Changing the rate on an existing tax code instead of creating a new code for future-dated rate changes • Misconfiguring account determination so tax posts to the wrong G/L account without any error message • Forgetting to configure non-deductible tax handling, causing recoverable input tax to be inflated • Not testing tax code changes against the actual chart of accounts and company codes that will use them • Overlooking that condition type sequence in the tax procedure affects calculation results for compound taxes
Best practices
• Create new tax codes for rate changes rather than editing existing codes with historical postings • Document account determination mappings per tax code and review them during every country or company code rollout • Build test cases that verify both the tax amount and the target G/L account for each new or changed tax code • Coordinate tax code changes with MM and SD teams responsible for automatic tax determination in transactions • Maintain validity periods on tax codes explicitly rather than relying on default open-ended validity
Interview angle
Expect scenario-based questions such as how to handle a VAT rate change without disturbing historical postings, or how to trace a tax posting that landed in the wrong G/L account. Strong candidates describe the difference between changing an existing tax code versus creating a new one, and can explain how account determination keys separate tax G/L postings from the base transaction posting.