Tax Code Not Permitted for Company Code

An AP clerk or shared service processor tries to post a vendor invoice or a journal entry and the system stops the save with a message that the tax code is not permitted, or not defined, for this company code. The user swears the same tax code works in every other invoice they enter that morning. It usually surfaces right after a new company code goes live, after an existing company code is copied for a new legal entity, or when someone keys a cross-border intercompany document and reuses a tax code from the wrong entity out of habit. The finance team frames it as the invoice being stuck, with the payment run deadline approaching, and asks for the tax code to simply be added or allowed for their company code, assuming it is a one-line master data fix.

Pull the company code master to confirm its country key, then pull the tax code list from FTXP for that country and check whether the code in question appears, along with its validity dates and deletion status. Cross-check by extracting documents with that tax code from the line item table filtered on company code and posting date to see whether it ever posted successfully there, or only in other company codes, which confirms whether this is a country mismatch or a validity gap.

If the root cause is a country mismatch, the fix is to build the tax code correctly under the company code's actual country in FTXP, which is a configuration change requiring transport through the landscape, not a same-system quick fix. If a deletion indicator is blocking a code that should still be active, removing the flag is a config change in FTXP, but check first whether the flag was set deliberately for a superseded rate before reversing it. If the rate record is missing or expired for the posting date, add a new validity line with the correct percentage in FTXP, which is configuration but can usually move faster since it does not touch the account determination. If the tax procedure was reassigned at country level, the tax codes under the old procedure need to be rebuilt under the new one and the related account determination in the tax accounts configuration needs to be checked as well, which is a heavier change involving finance sign-off. If the cause is an incomplete transport, retransport the tax code together with its rate data rather than patching the rate manually in each downstream system, to keep the landscape consistent.

The reflex fix is to tell the user to key a different tax code that happens to post, or to hunt for a similarly-named code from another company code and force it through. Both get the invoice posted but apply the wrong tax treatment or rate, which shows up later as a discrepancy on the VAT or sales tax return and requires a correction posting to fix. Removing a deletion flag without checking why it was set is equally risky, since it can bring back a superseded rate after a statutory change and misstate tax on every document posted with it until someone notices.

Tax code configuration sits with the FI/tax configuration owner, working with local tax or finance control on rate correctness before any code is rebuilt or unflagged. AP or AR consultants confirm the reproduction and gather the company code, tax code, posting date and exact message, then hand off with the country comparison already done so config does not have to start the investigation from zero.