SAP Tax Code Specialist: who reads, audits and proves tax determination in your system

SAP Tax Code, in one sentence

Tax code in the narrow and in the broad sense

Seven links between master data and the tax assessment

1. Master data. The tax classification of the material, the partner category and the attributes of the establishment provide the inputs. An error here repeats in every document.
2. Operation type. The business process, such as purchase for resale, shipment, return or service, sets the context of the rule.
3. Code determination. The system chooses the tax code from a combination of data, by a determination rule or by information typed into the document.
4. Pricing procedure. The code triggers the procedure that lists the taxes and the order of calculation. In Brazil, the SAP help treats TAXBRA as the pricing procedure.
5. Conditions and rates. Condition records deliver percentages, bases and exceptions by state, tax regime and validity.
6. Accounts and posting. The same code decides which account the tax is posted to and whether it creates a credit or a debit.
7. Document and tax assessment. The result reaches the invoice, the tax book and the tax assessment, and this is the point where the divergence is usually noticed.

Six places where a tax code decides without warning

A well-governed tax code answers ten questions

The inventory a specialist builds first

• A full list of active tax codes, with description, procedure and creation date.
• Usage count by code, by period and by establishment.
• Duplicate or near-identical codes that produce the same result under different names.
• Codes with no use for more than one annual assessment cycle.
• Determination rules that select each code, and the master data that feeds them.
• Codes typed by hand into documents, which escape the determination rule.
• Tax accounts linked to each code and opening balances that depend on them.
• Custom developments that change or ignore the chosen code.
• Differences between development, quality and production environments.
• Existing documentation and the name of whoever maintains it.

Eight symptoms and where the tax code fits in the explanation

Six steps to find the cause of a wrong tax

1. Record the case. Document, item, expected value, value obtained, date and who approved the expected value. Without this the conversation turns into opinion.
2. Reproduce. Repeat the case in the test environment with the same data. A case that does not reproduce stays without a cause.
3. Follow the chain. From the document to the master data, noting the code chosen at each link and the rule that chose it.
4. Isolate the layer. Source data, determination rule, procedure, condition, account or custom development. One layer at a time.
5. Fix at the cause. Change the guilty layer, with approval from the tax lead for any change that alters the result.
6. Prove and keep. Run the scenario again, keep the test with the case and record what changed.

The scenario matrix that turns the code into evidence

From birth to deactivation: the life cycle of a tax code

1. Request. The requester records the operation, the reason and the tax lead who approves. A request without an owner does not become a code.
2. Design. The specialist checks whether a code already exists for the operation before creating another. The default is to reuse.
3. Test. The scenario matrix runs with the new code and with its neighbors, to see whether the new one shifts any result.
4. Approval. The tax lead signs the result. The signature covers the scenario, not the configuration.
5. Transport. The change reaches production with a record of the date and of what was changed, and with a rollback plan.
6. Periodic review. At each assessment cycle, the inventory shows usage, and an unused code is deactivated with a record.

Six ways a tax code ends up out of control

What cannot be missing from the root cause report on a wrong tax

The first two weeks of a Tax Code engagement

1. Days 1 and 2: access and scope. Read access to the test environment, the problem document and the list of decision makers. What is in and what is out gets defined.
2. Days 3 to 5: inventory. Survey of the codes, their use and the determination rules. A first map comes out with the doubtful points marked.
3. Week 2, first half: reproduction. The problem case is reproduced and followed through the chain. The hypothesis of the cause is written down before any change.
4. Week 2, second half: proposal and matrix. A fix proposal with the scenario matrix, the expected result submitted to the tax lead and the transport plan.

The two weeks describe a work sequence, not a commitment on timing. The real duration depends on the size of the environment and on the availability of those who approve.

What the auditor asks about a tax code and how to answer with a document

Six indicators to know whether tax code governance is working

Eight items before transporting a tax code

• The tax lead signed the expected result of each affected scenario.
• The matrix ran with and without the change, and the difference is the expected one.
• The neighboring codes were tested, not just the changed one.
• The rollback plan is written and was rehearsed in a test environment.
• The validity date was checked against the official source.
• The assessment period in progress was considered, so rules are not mixed within the same month.
• Whoever operates was told about the change and what to watch on the first document.
• The change record points to the request, the test and the approval.

Tax Code does not live alone

Three reasons the tax error comes back

What changes for the tax code with CBS and IBS

For the full picture of the reform in SAP, see the page on CBS and IBS in SAP and the one on CST for the reform.

Tax code in S/4HANA: what changes and what stays

Read SAP S/4HANA tax consulting.

What each area of your team brings to a Tax Code engagement

Tax code in rollout: what happens when a new branch comes in

Whoever opens branches often finds the full method in tax rollout.

Ten questions to know whether your environment needs a specialist

• Can you say how many tax codes are active today?
• Does each code have an owner and a description that says what it does?
• Is there one place where the determination rules are explained?
• Do you know how many documents last year had the code typed by hand?
• Are there saved and up-to-date test scenarios for the main operations?
• Does the last change to a tax code have a recorded test and approval?
• Does the tax close result match the ledger without manual adjustment?
• Can anyone explain why rate X applies to operation Y?
• Do you know the effect a system update would have on the current codes?
• Is there a plan for what the tax reform changes in the codes?

Ten technical questions for the interview

Five deliverables of a Tax Code

Where our work ends and the client's decision

When you do not need a Tax Code specialist

Who may change a tax code: four roles that do not mix

A tax code changes the tax of every document that uses it from then on. That is why a change needs more than one person, and the cheapest internal control rule is to separate who requests, who configures, who approves and who transports. In a small environment one person holds two roles, but never three.

The warning sign is a person who requests, configures and transports on the same day, with no record at all. When this is frequent, the inventory usually shows codes with personal names, open validity dates and differences between environments that nobody can explain.

Naming convention: eight rules so the code says what it does

The description of a tax code is the first document the auditor and the next consultant read. A name like "TESTE2" or "JOSE NOVO" forces them to open the configuration to understand what it does. A simple convention, written down and applied from the first code, avoids most of that work.

• Start with the operation, not the tax: purchase for resale, domestic sale, return, service received.
• State the geographic scope in the same place in every name, so the list sorts by state or by interstate.
• Record whether the code serves inbound, outbound or both, without leaving the reader to guess.
• Never use a person's name, a project name or the creation date as part of the description.
• Mark a code with limited validity with the year in the name, so the periodic review finds it.
• Reserve a range or a prefix for test codes, with the rule that they do not exist in production.
• Write the convention on one page that the team consults, not only in the head of whoever created it.
• Review the old names when the convention changes, instead of living with two standards indefinitely.

The convention does not fix a wrong configuration. It only makes the error visible earlier, because a code whose name says "domestic sale" and that appears on an interstate invoice catches the eye of whoever reads the document.

How to calculate the expected value outside SAP without repeating SAP's error

A test only proves something if the expected result comes from somewhere other than the system under test. When the expected value is copied from the document itself, the test confirms what was already wrong. The method below keeps independence and fits in a spreadsheet.

1. Start from the written decision. The tax lead records the treatment of each operation in the scenario, with the source used. The calculation starts from this decision, not from the screen.
2. Build the calculation in your own spreadsheet. Base, rate, reduction and amount of each tax in separate columns, with the formula visible. Whoever reviews must be able to redo the math in minutes.
3. Freeze the input data. Material, partner, branch and date stay fixed on the scenario row. Changing one of them creates another scenario and does not alter the old one.
4. Compare field by field. The SAP result goes next to it, tax by tax. A difference of cents is also a difference: it may be rounding, and rounding has its own rule.
5. Record the accepted difference. When the system and the spreadsheet diverge for a known reason, the explanation and the approval are noted. An unexplained divergence fails the scenario.

Six moments of the close when the tax code should be checked

The tax code does not need to be reviewed every day. But there are fixed points in the calendar where a short check keeps the error from turning into rework on the tax assessment.

Three sources of documents that escape the determination rule

The determination rule only protects documents that go through it. Whoever builds the inventory needs to know which document creation paths exist in the environment, because each one may bring the code in a different way.

In all three cases the symptom is the same: the code on the document differs from what the determination rule would have chosen. The comparison between the two, by period, is the most direct indicator that an uncontrolled path exists.

A short routine to know the rule changed before the invoice goes out wrong

No specialist decides the effect of a change in the rules, but the system has to be ready for the client's decision. The routine below fits in one hour a month and leaves a record that the reading was done.

• Define who reads the official publications for each tax and how often, and note the name in the inventory.
• Record the reading date and the address of the source, so the next person knows how far the reading went.
• Separate what is already in force from what depends on regulation not yet published, without treating the second as certain.
• Open a change request for each change that affects a code, with the tax lead as approver.
• Mark in the inventory the codes that depend on the changed rule, and test them before the effective date.

What was read for this page

The SAP help pages load their content dynamically. The title and an excerpt of each were seen, and the text for each release of your environment is what counts when deciding any configuration.

Frequently asked questions about SAP Tax Code

Bring a document with a strange tax and leave with the cause

Tell us the symptom, the environment and the last document affected. The conversation starts from the case, with no price and no commitment on timing, and the tax treatment stays with your company.