SAP S/4HANA tax consulting: tax that crosses the platform change without losing proof

Tax consulting on S/4HANA, in one sentence

Five changes in S/4HANA and the tax question for each one

Tax in each path: conversion, new implementation and selective transition

For the cloud decision, the page on RISE and GROW with SAP covers the subject in full.

What tax must deliver in each phase of SAP Activate

Four cares for the environment so the tax test is valid

Business Partner: what happens to the tax data of the partner

Universal Journal and reconciliation: where tax checks

Whoever needs to go deeper into the checking method will find the step by step in tax and accounting reconciliation.

Six tax balances that the cutoff must carry

For the related topics, see Block H and inventory and CIAP and fixed assets.

Obligations of the period in which two systems lived together

Monthly and annual obligations are covered in SPED and reporting obligations.

Sending and receiving: six questions that the migration plan forgets

For the design of each document, see electronic tax documents; for those who still use the old issuing component, migration from GRC NF-e to DRC.

Six steps to build the set of cases that proves the calculation stayed the same

1. Choose the universe. List the operations, partners, materials and branches that represent the business, including the most costly exceptions.
2. Select real documents. For each combination, choose a real document from ECC and note taxes, bases and accounts. Remove personal data.
3. Fix the expected result. The person responsible for tax approves, in writing, the expected value of each case. Approving after seeing the new result voids the proof.
4. Run it in S/4HANA. Reproduce each case in the new environment, with the migrated data, and keep the result next to the expected one.
5. Classify each difference. Migrated data, rule, custom code or improvement of the standard. The decision to accept or correct belongs to the person responsible for tax.
6. Keep it and repeat. The set becomes the regression test for each release. When something changes, the same set answers whether the calculation is still the same.

A tax rule written by hand: keep, replace or retire

The detail on clean core and on what each level allows is in Clean Core for tax, and the one on development is in ABAP and tax customization.

Which tax layer will run on S/4HANA: decide before the Realize phase

Integrations that tax depends on and that change address in the migration

The technical part of each interface is on the page on tax integration with SAP BTP and API.

Go-live and the tax reform: three scenarios of date

The details of what changes are in CBS and IBS in SAP. SAP points to calculation and mapping of CBS and IBS for the invoice in the TAXBRA help, and the coverage of your release is confirmed in the system.

The first three closes: what to follow

1. First close. Compare the ledger with the book, invoice by invoice in the accounts of highest value, and check the opening balances.
2. Second close. A leaner reconciliation routine, focused on the differences that repeated and on the exceptions of each branch.
3. Third close. A close without special support, with a report of what was corrected, what stayed open and what becomes routine.

When the routine needs permanent support, see AMS Fiscal.

Six tax deliverables of a migration

Four company profiles, four tax priorities in the migration

Integrator and tax consultancy: a boundary that is written

Four sentences we hear at the start of projects and what to answer

What to watch in each tax when migrating the calculation

Eight things your team must have ready for the work to pay off

• A person responsible for tax with time set aside to approve expected results.
• A person responsible for IT with access to the environments and to the transport history.
• A list of the taxes, documents and obligations in scope.
• Real documents for the set of cases, already stripped of identity or ready to be.
• A list of the known tax rules of your own, even if incomplete.
• A decision on the transition path, or the date when it will be made.
• A calendar of closes and obligations for the period of the project.
• The name of who decides when two options are possible.

How the tax consultancy works beside the integrator

Eight tax migration errors that can be avoided

• Treating tax as one more module, with no named owner and no room in the schedule.
• Defining the set of cases after seeing the result of the new system.
• Converting the partner master data without checking the tax numbers.
• Finding out late that the chosen tax layer does not cover an exception of the business.
• Taking all the custom code to the new platform, without deciding case by case.
• Setting the cutoff in the middle of a calculation period with no reconciliation plan.
• Leaving tax regression with no owner after go-live.
• Confusing data cleanup, which belongs to the client, with configuration, which is ours.

Twelve months to go-live: what tax does in each window

1. Twelve to nine months before. Name the person responsible for tax, take inventory of rules and custom code and define the transition path with its effect on books and balances.
2. Nine to six months before. Decide the tax layer, build the set of reference cases and agree the test environments.
3. Six to three months before. Configure, run parity, classify differences and validate the conversion of the partner master data.
4. Three to one month before. Rehearse the tax cutover, check opening balances, define the consolidation of the month of the switch and train those who operate.
5. In the week of the switch. Freeze rule changes, carry out the cutoff plan and keep the proof team on call.
6. After the switch. Follow the first three closes and turn the set of cases into permanent regression.

Six tax decisions that are yours and that the project must record

What we do in the project and what stays with the company

Ten signs that tax is undersized in your project

• The person responsible for tax does not take part in design meetings.
• The schedule has no line for tax testing.
• Nobody defined the set of reference cases.
• The tax layer has not been chosen yet and the Realize phase has already started.
• The conversion of the partner master data is treated as an IT task, with no tax validation.
• There is no plan for the month when two systems coexist.
• There are custom rules and nobody knows how many.
• The integrated test uses invented data.
• The approval test with the authority is set for the week of go-live.
• Support after the switch has no owner and no deadline.

Twenty tax questions to bring to the technical meeting

The tax plan B for the switch: what to decide before, and not in the middle of the night

Every cutover rehearsal has an approval criterion, and every criterion needs an alternative path when it is not met. At the switch, the tax question is not whether something can go wrong, but who decides, until what hour and with what effect on documents and books. The table below gathers the decisions worth taking and writing down in advance.

Plan B does not foresee failure. It cuts the time the team spends arguing, at the worst possible hour, a decision that could have been made calmly two weeks before.

How to run an obligation in both systems and compare the result

Document parity proves that the calculation stayed the same. Obligation parity proves that what goes to the tax authority stayed the same. They are different proofs, and the second is often left for the last month, when there is no time left to correct.

1. Choose the reference period. A period already closed and delivered in the old system, with all documents and adjustments known. The official result becomes the standard for comparison.
2. Generate the obligation in the new system. With the migrated data and the same period, using the same layout version as the file delivered. It is not valid to compare files of different layouts.
3. Compare by block, not by file. Totals by record and by type of tax show where the difference starts. Line by line comparison comes only after the block is found.
4. Classify each difference. Migrated data, generation rule, own report or configuration error. The classification points to who corrects.
5. Repeat until the unexplained is zero. A difference that is explained and approved can stay. A difference with no explanation reopens the round. The person responsible for tax signs the final table.

Tax access profiles in the new system: what to review in the conversion

The platform change is the moment when access profiles are recreated, copied or simplified. For tax, the risk is double: too much access, which lets someone change a rule with no record, and too little access, which stalls the close on the worst day of the month.

The inventory of profiles of the old system is the base. The migration is the chance to remove what nobody uses, as long as each removal has an owner and a date.

Keeping the history: how the old system keeps answering the auditor

After the cutoff, the new system carries balances and perhaps a slice of movement. The rest of the tax history still exists in the old system, and someone must answer what happens to it. The retention period of each document and book is a legal matter, and this point was not checked on this page: the company defines it with its legal team and its person responsible for tax.

• Record which documents, books and obligation files stay only in the old system and for how long.
• Define who maintains the old system or the query archive, and with what access, until the end of the period set by the company.
• Test, before the cutoff, the query of an old document by number and by key, as the auditor would do.
• Keep the documentation of the tax configuration of the old system, because it explains the history left behind.
• Agree with accounting how comparative reports between periods will be made when half of the history is in each system.

Each release update is a small migration: five cares

SAP updates S/4HANA in cycles, and each update can change standard behavior. The rhythm and the guidance of each release were not checked on this page, and the plan of each company should start from the documentation of the version in use. What does not change is the need to prove that tax stayed the same.

1. Read the list of changes. Someone from tax reads the update notes that touch taxes, before the test environment receives it.
2. Update quality first. The update goes into the test environment with recent data, and never straight into production.
3. Run the set of cases. The same set as in the migration, with the original expected result. A difference needs an explanation.
4. Check the custom code. Own code that depends on a changed standard object is reviewed before the date of the update.
5. Record and release. The parity table of the update is signed by the person responsible for tax and kept with the date.

Six notices to third parties that the switch requires and that the project often forgets

The switch changes how the company presents itself to those who issue and receive documents with it. Part of the notices belongs to tax, part to sales or purchasing, and all of them need a date.

• Vendors that send the invoice file by a fixed channel: confirm whether the receiving address changes.
• Customers that query the invoice on a portal: warn of any change of format or of sending channel.
• External accountant and support office: agree the exact point at which they start to receive data from the new system.
• Banks and administrators: confirm whether collection and return files keep the layout and the naming convention.
• Carriers: check whether the invoice data that feeds the transport document stays in the same format.
• Authorities: check certificates, credentials and access registrations before the first issue in production.

Laws and pages read for this page

Dynamic pages from SAP were read by title and excerpt. For any decision, the text of the release and of the simplification note of your environment is what counts.

Frequently asked questions about SAP S/4HANA tax consulting

Reach go-live with the tax proof ready

Tell us the SAP version, the transition path and the date you want. The conversation starts from your scenario, with no price and no commitment on dates, and the tax decisions stay with your company.