Specialty · Testing and validation

Tax testing and validation in SAP: scenarios, evidence and what the technical test does not see

Tax testing is the proof that SAP calculates the right tax, issues the right document and closes the month at the right amount for each scenario of the operation. It starts from a scenario matrix, uses data that keeps what determines the tax, compares each result with an expected value written beforehand and keeps the evidence.

The technical test shows that the system runs without error. The tax test shows that the result matches what the company decided is correct.

Talk about the tax test plan See the scenario matrix

Versão em português

Contents

Go straight to the part of the tax test that fits your role

One reading for each of the five roles, with a shortcut to the right part.

01Project manager

Test levels, entry and exit criteria and the rule of not passing with an open tax defect, to settle scope and schedule.

Go to section

02Tax key user

How to build the scenario matrix, write the expected value of each case and what the tax authority's authorization test does not prove.

Go to section

03QA and IT

Test data, environments, automation worth doing and the regression pack for invoice, update and layout change.

Go to section

04Accounting and controlling

Assessment and file testing, a close test with one month of activity, and the reconciliation that the per-document test does not do.

Go to section

05Internal audit

Evidence sheet, traceability from the case to the expected value and the retention horizon to consider.

Go to section

Direct links

Direct links:scenario matrix tax authority environments exit criteria regression common mistakes questions

The short answer

Three proofs, and each answers one question

The direct answer

There are three different proofs: the technical test shows that the system runs, the tax test shows that the result is right for the scenario, and the close test shows that the whole month reconciles. Passing the first does not excuse the other two.

Technical test

Question: does the system run without error? It confirms screens, interfaces, jobs and transports. Typical evidence: a run with no error message. It does not prove that the calculated tax is the one due.

Tax test

Question: are the amount and the document right in this scenario? It compares tax, classification and fields with an expected value written by the tax team. Typical evidence: case, expected, obtained and approval.

Close test

Question: does the period close and reconcile? It brings together documents, assessment, files, payment slip and accounting for one month of activity. Typical evidence: a reconciliation table with no difference left without an owner.

The distinction between the first two is already covered in the SAP Tax Diagnostic and in tax setup.

Why tax testing is different

The right value comes from outside the system

Every test compares an obtained result with an expected result. In the technical test, the expected result is in the specification. In the tax test, it is in the law, in the state act and in the company's reading of them.

The expected value written beforehand, by whoever decides

Every tax test case starts from a statement by the tax team: in this operation, between these states, with this product and this partner profile, the tax is this and the document comes out like this. The statement has an author and a date. If the expected value is copied from what SAP calculated, the test becomes a photograph, and a photograph agrees with any error.

The thesis belongs to the client

The tax interpretation that produces the expected value is the company's decision, with its advisors. The job of the test is to prove that the system reproduces that decision in each scenario. If the tax team and the accountant disagree, the case stays suspended until a decision is recorded, because passing with the doubt open only pushes it to the close.

The rule changes without the code changing

Rate, benefit, tax base and layout change by act of the tax authority, without any program having been altered. A case that passed in March can fail in October with the same code. So each case carries the date of the rule it checks, and regression has its own calendar, in addition to the technical triggers.

Good practice

Treat the expected value as a document with an owner, a source and an effective date. When the owner changes their mind, the case changes with it, and the history shows the previous version.

The levels

Six test levels, each with its own question

The terms change from project to project. What does not change is the question each level answers and what it leaves unproven.

Level	The question it answers	Who runs it	Evidence	What it does not prove
Unit	Do a rule, a calculation or an extension, in isolation, respond as expected for known inputs?	Technical team, with the cases written by the tax team	Case result and version of the object tested	That the whole works together
Integrated	Does the whole process, from order to authorized document, to posting and to bookkeeping, close at the expected value?	Tax and IT, in the quality environment	Document, postings and file of the case	That the month closes with real volume
Regression	Does what was approved stay approved after a change?	IT, with the tax team signing	Comparison with the previous result, case by case	That the new case is right
User acceptance (UAT)	Does the key user recognize the result as what the operation needs?	Tax key user and business areas	Acceptance record with the cases run	Compliance with the law when the user does not master the rule
Parallel	Does the SAP result match that of an independent reference in the same period?	Tax and controlling	Table of differences by document and by assessment	Cases that the reference does not cover either
Close	Does the whole period close, reconcile and generate files and payment slips without manual adjustment?	Controlling, tax and IT	Assessment, reconciliations, files and payment slips of the test period	Future periods, such as year-end or a change of regime

The order is the order of dependency: the integrated test only counts if the unit tests of the critical points passed, and the close only counts if the integrated test covered the month's operations. Regression is not a phase, it is a repetition that goes along with all of them. The parallel test is the most expensive and the most revealing: it compares SAP with an independent reference, such as the result of the previous environment or an assessment done outside, and the difference points to where to investigate.

Good practice

Not every project needs all six levels. A small setup change calls for unit, integrated and regression. A version migration and a rollout to a new unit also call for parallel and close. The choice should be in the plan, with the reason.

Scenario matrix

Five dimensions form the matrix

The matrix is the list of combinations that change the tax or the document. It exists so that scenarios are not chosen from memory.

Operation

Sale, return, transfer, shipment for repair, bonus goods, service, import, input purchase. Each one follows a different rule for tax, CFOP and bookkeeping.

Origin and destination

State of origin and destination, and the municipality when there is a service. The same sale changes in rate, differential and tax substitution depending on the route.

Profile of the parties

Taxpayer or not, regime of the issuer and the recipient, final consumer, partner with withholding or benefit. The partner master decides part of the calculation.

Product or service

NCM, origin of the goods, tax treatment (substitution, exemption, zero rate, single-phase) and service code. It is the dimension that grows most in industry and distribution.

Document and event

NF-e, NFC-e, CT-e, NFS-e and the events that change the case: cancellation, correction letter, supplement, return and voiding.

There is a sixth, silent dimension: time. Every case checks a rule that applies from one date and stops applying on another. Noting the effective date on the case avoids approving today what the state act has already changed.

How to reduce without losing what matters

Survey what the operation does

Extract the documents of the last twelve months by operation, state and product. A scenario that never happened only goes in if it will happen in the project.

Group by equivalence

Cases that go through the same rule and change only the amount become one scenario with two values, the minimum and the maximum, not two scenarios.

Mark the critical ones

Amount, frequency and exposure define criticality: regimes with a benefit, substitution, export and return tend to rank higher. The criterion belongs to the tax team.

Write the expected value

Tax by tax type, classification, mandatory fields of the document and postings, with the source cited next to each value.

Give an owner and a date

Each expected value has someone who signs it, the act that supports it and until when it applies. Without an owner, the case does not count toward the exit criterion.

Good practice

Combining first and reducing afterwards is the safe order. Reducing before combining hides the dimensions the project forgot, and they show up at the first close.

Calculator

The size of the matrix and the effort of execution

Multiplying the dimensions gives the theoretical universe. Reduction by equivalence and the choice of critical cases give what is actually run. Change the fields to see how much each dimension weighs.

Matrix size

How many scenarios does the project really have?

Example with the starting values: 6 operations, 5 state combinations, 4 partner profiles, 8 product treatments and 3 types of document or event make 2,880 possible scenarios. With an 85% reduction by equivalence, 432 scenarios remain to run. At 12 minutes per scenario, that is 86.4 hours of execution. Enable JavaScript to change the values.

Illustrative example, with hypothetical values. The reduction percentage and the time per scenario are project judgment, not a rule.

Test data

Anonymized real data and what must not be masked

Test data must keep what determines the tax and protect what identifies people. The same column can be in both groups depending on the master record.

Real, anonymized or synthetic

Real data brings the cases the operation actually has, including those nobody would remember to write. Synthetic data gives control: the case exists because someone designed it. Real data finds what was missing from the matrix, and synthetic data covers what the operation has not yet done, such as a new state. The five patterns of the alphanumeric CNPJ are on the dedicated page.

What the data protection law says

The LGPD treats as personal data any information related to an identified or identifiable natural person. Anonymized data is not personal data, unless the process is reversed (art. 12). Processing is limited to the minimum necessary (art. 6, III), with security measures (art. 46). The CNPJ of a legal entity does not refer to a natural person, but partners and contacts appear in the same master records.

Keep, because it determines the tax

CNPJ and state registration: they go into validation, regime and partner-specific rules.
NCM, CFOP, origin of the goods, CST or CSOSN: changing the code changes the scenario.
State and municipality of origin, destination and service: they define rate, differential, substitution and place of taxation.
Amounts, quantities and discounts: they can be scaled while keeping the proportions, because the base and the rounding depend on the composition.
Issue, entry and exit dates: they define the effective date of the rule and the assessment period.

Mask, because it identifies people

CPF of an individual: replace with a valid fictitious number.
Company name, trade name and street address: they do not change the calculation. Keep the state and the municipality.
E-mail, phone and contact name: they do not enter the tax calculation.
Bank account and payment data: mask them, keeping the layout that the interface test requires.

Official source

The LGPD defines anonymized data (art. 5, III), excludes it from the concept of personal data (art. 12), sets the principle of necessity (art. 6, III) and requires security measures (art. 46).

Law 13,709/2018 (LGPD), Planalto

Good practice

Mask what identifies people and keep what determines the tax. The decision to use real data in a test environment belongs to the client's data governance, with the data protection officer. Before blaming the calculation, check the tax master data

Environments and tax authority testing

Two environments called testing, and what each one proves

The company's test system and the tax authority's test environment answer different questions. The test plan must say which of the two each result used.

Environment	What it is	What it proves	What it does not prove
Company quality or test system	SAP test system, where you configure, develop and test before production	That configuration, code and test data produce the expected result	That the tax authority accepts the document, or the behavior with the real master data and volume
Tax authority test environment (NF-e)	Authorization environment kept by the tax administrations for layout and rule testing. In the layout, the field tpAmb tells production (1) from test (2)	That the XML meets the layout and the validation rules in force in that environment	That the tax amount is right, or that production will have the same rule on the same day: rollout in the test environment can vary by state
Restricted production (national-standard NFS-e)	The national issuer's test environment, with interactive API documentation	That integration and layout work before pointing to production	The municipality's treatment, which depends on its own parameters
Split payment public platform	Integration test phase between payment service providers and the platform, from 15/10/2026, in a controlled environment	The providers' integration with the platform	The behavior of the company's ERP, which is not a participant in this phase

Vocabulary trap

The word "homologation" names two environments: the company's test system and the tax authority's test environment. A report that says only "homologated" does not say which of the two was used.

The calendar changes, and the plan needs an effective date

NF-e

The NF-e Portal notice of 05/10/2026 postpones technical notes NF-e 2025.002 v.1.52, 2026.007 v.1.10 and 2026.008 v.1.00 to 26/10/2026 in the test environment and 16/11/2026 in production. That is a three-week gap, and it is the real testing time. See who signs off the regression of the new layout.

Split payment

The announcement of 30/09/2026 covers integration tests of the payment providers with the platform, with no final transaction. The Timing Manual leaves testing out of its deadlines. The company tests the ERP side, with simulated data: Split payment in SAP.

NFS-e

The official documentation confirms a test environment and advises validating the integration there before pointing to production. Each municipality's treatment follows its own parameters: National-standard NFS-e in SAP.

Official source

NF-e Portal (notices and technical notes in force), NT 2025.002 RTC v1.40 (defines the field tpAmb and the separate schedule for test and production), Federal Revenue Service announcement of 30/09/2026, split payment Timing Manual (section 1.2) and NFS-e Questions and Answers (topic 19.5).

Electronic documents

Authorization of use: what it confirms and what it leaves open

Seeing the authorized document gives the feeling that the test passed. The rule is explicit about what this authorization means.

Authorization of use confirms

The issuer's tax compliance.
The issuer's accreditation to issue the NF-e.
The authorship of the file signature.
The integrity of the digital file.
Compliance with the file layout.
The numbering of the document.

Only the tax test confirms

Whether the rate and the tax base are the ones due for the scenario.
Whether the product classification and the tax treatment are right.
Whether the benefit was applied when it should have been and not when it should not.
Whether the accounting posting and the bookkeeping reflect the document.
Whether the later event (cancellation, return) reverses what it should reverse.

SINIEF Adjustment 07/05 says, in clause four, § 3, I, that granting authorization of use results from applying formal rules specified in the manual and does not validate the tax information in the NF-e. Clause six lists what the administration checks before authorizing. § 1 of the same clause four goes further: even if formally regular, an NF-e issued or used with an error that makes it possible, even for a third party, not to pay the tax or to gain another undue advantage is not valid.

Official source

SINIEF Adjustment 07/05, clause four, §§ 1 and 3, I, and clause six. Consolidated text at Confaz.

SINIEF Adjustment 07/05, Confaz

The consequence for the plan is practical: an authorized invoice is an entry criterion for the document test, not an exit criterion. The exit requires comparison with the expected value. The same reasoning applies to events and to the other electronic documents. Issuance, events and rejections are covered in electronic tax documents in SAP and in CT-e and MDF-e in SAP.

Assessment and obligations

The file validator does not replace the assessment check

The file test and the assessment test are two tests. The first answers whether the file is well formed. The second answers whether the number is right.

File test

It checks that the file meets the required layout and consistency. For the SPED tax file, SINIEF Adjustment 02/09 (clause ten) requires the file to be submitted to the layout consistency validation of the PVA-EFD. A file the validator accepts is a well-formed file. It does not say whether the assessment the file carries is right.

Assessment test

It checks that the period result is the one due: debits, credits, adjustments, balance and payment slip. The reference is an independent assessment, done with the same rules by another route, and the comparison looks for differences by document, not only in the total.

The test order follows data dependency

Document

Each operation in the matrix generates the right document, with the expected value.

Posting

The document's tax and accounting postings match what it declares.

Assessment

The period closes at the expected balance, with adjustments and late items handled.

File

The period file passes the validator and tells the same story as the assessment.

Payment slip and accounting

The generated payment slip and the general ledger agree with the assessment and with the file.

Each link depends on the one before. Testing the file without having tested the document is looking, at the end of the chain, for a cause that began at the start. The close test goes through all five links in one month of activity, and the rule is to check whether any manual adjustment was needed to close: if so, the adjustment is a defect or a rule that is not yet in the system. The tests for each obligation are in SPED tax file, tax assessment and post-go-live tax close.

Official source

SINIEF Adjustment 02/09, clause ten, on layout consistency validation and signing by the PVA-EFD.

SINIEF Adjustment 02/09, Confaz

Tax reform

What to test in 2026, side by side

The reform enters the matrix as one more dimension, that of the new groups and rules.

Document with the new groups

Filling in the IBS and CBS fields, tax classification, layout rejections and referenced return. Detail on the NF-e Portal and in electronic tax documents.

Settlement and withholding

Withholding forecast, link to the document, clearing by arrangement and reconciliation, with the ten-test plan in Split payment in SAP.

Master data

Partners with an alphanumeric CNPJ in the master record, the document, the bookkeeping and the interface, with the data set of the five patterns in Alphanumeric CNPJ in SAP.

Period assessment

Assessment and files with the new taxes alongside the current ones, in the context of tax reform in SAP.

Services

NFS-e issuance and integration in the national standard and treatment by municipality, in National-standard NFS-e.

Under LC 214/2025, the 2026 IBS rate is 0.1% and the CBS rate is 0.9% (arts. 343 and 346). So a 2026 error costs little, and finding it only in 2027 costs more. That is the argument for testing now, with the matrix cases and the new fields. Also read IBS and CBS test phase in 2026 and tax test scenarios in S/4HANA.

Official source

Complementary Law 214/2025, arts. 343 (IBS) and 346 (CBS), 2026 rates. The dates and layout validation rules are on the NF-e Portal and in NT 2025.002.

Good practice

Give the reform test the same treatment as the others: case, expected value, source, effective date and owner. Since the dates change, record in each case the version of the technical note and the effective date of the source.

Entry and exit criteria

When testing can start, when it can end

An entry criterion prevents testing a system that is not ready yet. An exit criterion prevents leaving with the doubt open. Both must be written before the first case.

Entry criteria

Scope and matrix frozen, with a version.
System at the right version and with the plan's notes, recorded.
Data loaded and master records checked.
Expected value signed for the critical cases.
Access, certificates and tax authority environment available.

Exit criteria

All critical cases run.
No open tax defect without a recorded decision.
Regression of approved cases with no drop.
Acceptance by the key user and by controlling.
Evidence filed and complete.

The rule of not passing with an open tax defect

An open tax defect is any difference in amount, document or file without a recorded decision from whoever answers for the rule. The decision can be to correct, to accept the difference in writing or to change the expected value. What does not exist is a fourth option, passing without deciding. A project that postpones this decision until after go-live passes the bill to the first close, when the cost of correction is higher.

Severity	What it is	Example	Decision
Blocking	Wrong tax, document or file in a frequent or high-value operation	Wrong rate on an interstate sale of a fast-moving product	Does not leave the phase until fixed and the case and regression are repeated
High	Difference in amount or field with an effect on assessment, bookkeeping or obligation	A mismatched CST that changes the assessment block	Fix before exit, or a recorded client decision
Medium	Right result with a repeatable, documented manual step	Manual adjustment at close with a script and an owner	Pending item with a deadline and an owner, outside the exit only if accepted in writing
Low	Difference with no tax effect	Message text or report format	Normal project backlog

Good practice

The severity levels and criteria are method proposals. Each project should adjust them to its own risk and record the version that applied in the exit decision. In its Activate method, SAP describes the realization phase with tests and the deployment phase with the final test before cutover; the decision to pass belongs to the project.

Calculator

Coverage: cases tested over critical cases

Coverage is what was tested divided by what matters. The matrix chooses what matters, and the tax team checks the result.

Test coverage

Does coverage of the critical cases already allow exit?

Example with the starting values: of 120 critical cases, 108 were run (90%), 96 were approved (80%) and 6 have a recorded client decision, which gives 85% ready. That leaves 6 open failures and 12 cases to run, and the suggested exit criterion is not met. Enable JavaScript to change the values.

Illustrative example: arithmetic with hypothetical values. The exit criterion is a method suggestion, not a legal rule.

Evidence for audit

The sheet that lets you repeat the case and reach the same result

Evidence is what lets another person, months later, understand what was tested, against which expected value and with what result. An eight-field sheet covers most cases.

Sheet field	What to record	Why it matters
Identifier and objective	Case code and the question it answers	Lets you cite the case and find the result in seconds
Scenario in the matrix	Operation, route, profile, product, document and effective date	Shows what the case covers and what it leaves out
System version	Environment, package, notes applied and run date	The same case can give another result after a change
Data used	Source document, partner and material, anonymized	Makes the case repeatable
Expected value and source	Values, the act or rule that supports them and who signed them	Separates the rule from the result
Obtained value	System result, with the document, the posting or the file attached	Proves the behavior of the system
Result and decision	Passed, passed with manual adjustment or failed, and the recorded decision	Prevents implicit approval
Owner and date	Who ran it and who approved it, with the date	Gives traceability to whoever audits

How long to keep it

The law sets how long tax documents and books must be kept. The National Tax Code requires keeping the mandatory commercial and tax books and the supporting records of postings until the statute of limitations runs out on the tax credits arising from the operations they refer to (art. 195, sole paragraph), and sets at five years the period for the tax authority to establish the credit (art. 173). The NF-e issuer must keep the digital file for the period set by tax legislation (SINIEF Adjustment 07/05, clause ten).

Official source

National Tax Code, arts. 173 and 195, sole paragraph. SINIEF Adjustment 07/05, clause ten. Test evidence is neither a book nor a supporting record of a posting, and the law does not address it directly.

Good practice

Align the retention of the evidence with the horizon of the documents the test validates, and record the rule in the company's retention policy. Evidence containing personal data follows the LGPD security measures (art. 46). What a specific auditor asks for should be asked of that auditor at the start of the project.

Automation

Automate the repetition, never the decision

Automation weighs in favor when the case repeats and the rule changes little. It weighs against when the case is rare or when the expected value is still in dispute.

What is worth automating

Regression of approved cases, repeated at each note, package or layout change.
Calculation with known inputs and expected output, such as isolated tax rules.
Comparison of files and XML between one version and another, which flags differences without needing to be read.
Static code checks, before the transport is released.

What is not worth automating

The expected value: it comes from the client's decision, and a robot only repeats what someone decided.
User acceptance, which depends on judgment.
A rare, high-risk scenario that changes every time and costs more to automate than to run.
Any case whose rule is still under discussion.

SAP's ABAP programming documentation describes the ABAP Test Cockpit as the framework that lets you run checks such as the extended program check, static performance tests and module tests with ABAP Unit. The rule in that documentation is to run ATC on all objects involved and have no open messages before releasing for transport. This covers the code. It does not cover whether the tax rule the code implements is right. The link between ATC and unit cases written by the tax team is in ABAP development and tax customization in SAP.

Official source

SAP, ABAP Keyword Documentation, version 7.51, guideline on the ABAP Test Cockpit.

ABAP Test Cockpit, SAP Help Portal

Good practice

Automate the repetition, never the decision. The cost of maintaining an automated case grows every time the rule changes, so start with the cases that change least and repeat most.

Regression

Rerun what matters after a note, upgrade and layout change

Every change that arrives after go-live can alter an already approved result. Regression is the organized answer to that.

Trigger	What to rerun	Who signs
SAP Note or support package	Cases tied to the objects the note changes, plus the critical calculation and document cases, and the dependencies the note declares	IT runs, tax team signs
Version update or upgrade	The full regression set and a test close	Project manager, tax team and controlling
Layout change (technical note)	Issuance in the tax authority test environment, rejections, events and the bookkeeping file	Tax team and IT
Change in state rule or rate	Cases for the affected state and operation, with the new effective date	Tax team
Change in setup or in in-house tax code	Cases for the changed rule and those that use it	Tax team and whoever made the change

The minimum regression pack is the subset of critical cases that covers each risk object. Each case carries a trigger tag: what changed it, what would make it fail. After a note, you do not rerun the whole plan, only the cases with the tag of the changed object. The record cites the note number and the system where it was applied. The process of following and deciding on each note is in SAP Notes for the Tax Reform.

A layout change has a peculiarity: the tax authority's test date comes before the production date, and that gap is the real testing time. In the NF-e Portal notice, the gap is from 26/10 to 16/11/2026, three weeks. The regression plan should start on the test-environment date, not the production date.

Good practice

Keep the list of triggers and the cases per trigger in one place. Regression stops depending on the memory of whoever was on the project and becomes an ongoing support routine, like the one described in AMS Fiscal and post-go-live stabilization.

GUEPARDO Tax

When the tax engine is GUEPARDO Tax, the proof has three layers

GUEPARDO Tax is a third-party product that the company configures and sometimes extends with its own code. A test that passed in one layer does not hold for the others.

The product

It belongs to NTT DATA, and the company receives it as a ready-made engine. What the company can prove is its result on its own documents, not the inside of the product.

The setup

It is the company's tax decision turned into a rule. A rule is only proven when a real document exercises it, with the expected value written beforehand. A rule without a document is an unproven rule. The governance of these rules is in GUEPARDO Tax: governance.

The in-house code

An extension alongside the product has no proof inherited from anyone. Each one needs its own cases, and the date the product changes release is also the date to retest the extension. See updating the GUEPARDO Tax release.

So when the result differs, the first question is which layer it came from. DFSpro implements GUEPARDO Tax as an Authorized Channel and handles its governance; the tax decision for each rule belongs to the company.

How DFSpro works

Design, configuration and proof of the behavior of the system

In tax testing, DFSpro's work is the tax part of the project. The technical test and the project's overall plan stay with whoever answers for them.

What DFSpro does

Builds with the company's tax team the scenario matrix and the expected value of each critical case.
Adjusts the tax setup and the tax ABAP code when the test shows a difference.
Runs the cases, compares the result and delivers the evidence for each one.
Organizes the close test and the reconciliation of the period.
Designs the regression for notes, updates and layout changes.

What stays with the client and the integrator

The tax thesis behind each expected value, which is the company's decision.
Approval of the result and the exit from the phase.
The project's overall test plan, the technical test and the environment, which stay with the integrator.
The data governance that authorizes the test data.

DFSpro's scope is the tax layer of the SAP project, alongside the integrator and not in its place. The starting point is usually the SAP Tax Diagnostic or the tax setup. In migrations and new units, the migration to S/4HANA and the tax rollout.

Limit of our role

DFSpro designs, configures and proves how the system behaves, together with the integrator. The test shows whether the system reproduces the company's decision; the client decides the taxation and the thesis. A doubt about the thesis goes to the client's legal counsel and accountant, and the case waits for the answer.

Common mistakes

Ten mistakes that make the test pass and the close fail

The mistakes follow a pattern: the test measures what is easy to measure. Each one has a cause and an alternative.

Mistake	Why it happens	How to avoid it
Testing only the happy path	One scenario per operation seems enough	Combine the matrix dimensions and reduce by equivalence, with the critical ones guaranteed
Taking the expected value from SAP itself	It is faster than consulting the rule	Expected value written by the tax team, with source and date, before the run
Data with no effective date	The data is all from today	Cases with dates before and after each rule change
Masking what determines the tax	Anonymization is done by column, with no tax criterion	List of preserved fields, defined by the tax team and the data protection officer
Treating authorization as approval	The authorized document appears and the test ends	Authorization is an entry criterion. The exit is the comparison with the expected value
Passing with a manual adjustment that has no owner	The deadline tightens and the adjustment looks small	Passed with an adjustment becomes a pending item with an owner, a deadline and a written decision
Forgetting the establishment with its own rule	The head office is tested and the branches inherit	Cases per establishment where the state or benefit rule differs
Regression only of what the note says changes	The description of the note seems complete	Trigger tag per case, plus the critical calculation cases and the declared dependencies
Evidence in e-mail and local spreadsheets	Each person keeps their own	A single sheet, with system and expected-value version, in a project repository
Ending before the first close	The schedule ends with go-live	Close test with one month of activity before exit, and follow-up of the first real one

Official sources

Rules and reference documents

Confaz

Portal notices and questions

Federal Revenue Service and CGIBS

Legislation

SAP

Frequently asked questions

Frequently asked questions about tax testing in SAP

Execution4 questions, 01 to 04

01What does DFSpro do in tax testing in SAP?+

On the tax side of the SAP project, DFSpro takes on these tasks: it builds with the company's tax team the scenario matrix and the expected value of each case, adjusts the setup and the tax ABAP code when the test shows a difference, runs the cases and delivers the evidence for each result. The tax decision behind the expected value remains the company's.

02Does DFSpro's testing replace the integrator's?+

No. The integrator is responsible for the project's overall test plan, the technical testing of the interfaces and the environment. Tax testing is an extra layer, which looks at the amount, the document and the close. The two meet in the entry and exit criteria, and the tax result goes into the same acceptance table of the project.

03What minimum scenarios does a project need?+

There is no minimum list valid for everyone. The minimum is what covers each operation the company actually does, in each combination that changes the tax: state of origin and destination, partner profile, product treatment and type of document or event. Building the matrix and reducing the set by equivalence, without losing what matters, is what sizes the effort.

04How is the result documented?+

Each case becomes a sheet with an identifier, scenario, version of the system and of the notes applied, data used, expected value and its source, obtained value, result and decision, owner and date. The test is that another person can repeat the case, months later, and reach the same result.

Engagement and scope4 questions, 05 to 08

05How does the client take part?+

The company's tax team writes or validates the expected value of the critical cases, the key user runs the acceptance and controlling follows the reconciliation of the test period. Without this participation, the test only proves that the system does what was configured, not that the configuration is the right rule for the company.

06How is the scope settled?+

Through contact, starting from what the company has: the size of the operation, the states, the documents, the project under way and whether there is an environment and test data. The conversation produces the scope, with the workstreams and the order, and the commercial terms are handled there, with the company.

07Does it work for reform, S/4HANA and ongoing support projects?+

Yes. The method is the same and the trigger changes. In the reform, the trigger is the layout and rule change. In the migration to S/4HANA, it is the change of architecture and the first close in the new environment. In ongoing support, such as AMS Fiscal, it is the change that arrives by note, update or legislation, and what is rerun is the regression set.

08Who approves the test result?+

Whoever answers for the rule approves the result: the company's tax team approves amount and document, controlling approves the reconciliation and the project manager approves the exit from the phase. DFSpro presents the proof of the system's behavior and makes a recommendation. Approval and the tax thesis belong to the client.

Risks and objections4 questions, 09 to 12

09Why does an environment pass every test and fail at the close?+

Because the test was done per document and the close is done per period. Isolated documents pass, but the month's total depends on posting order, late documents, reversals, master records changed in the middle of the period and rules that only show up with volume. That is why the plan includes the close test, with one month of activity.

10Can I use real data in the test environment?+

The LGPD treats as personal data what refers to an identified or identifiable natural person, and anonymized data stops being personal as long as the process cannot be reversed (arts. 5 and 12). Processing must be limited to the minimum necessary and the environment must be protected (arts. 6, III, and 46). In practice, you keep what determines the tax and mask what identifies people. The decision belongs to the client's data governance.

11Is SEFAZ authorization enough?+

No. SINIEF Adjustment 07/05 says that granting authorization of use results from formal rules and does not validate the NF-e's tax information (clause four, § 3, I). It confirms the issuer's compliance, accreditation, signature, integrity, layout and numbering. It does not confirm whether the rate, the base and the classification were right.

12What should be tested after an SAP Note?+

Rerun the cases tied to the objects the note changes, plus the critical calculation and document cases, and check the dependencies the note declares. If the note changes a layout or a field, include issuance in the tax authority test environment and the bookkeeping file. The record should cite the note number and the system where it was applied.

Reform and next steps4 questions, 13 to 16

13What should be tested in 2026 for the tax reform?+

What your environment issues and receives with the new groups and rules. The NF-e Portal notice of 05/10/2026 set 26/10/2026 in the test environment and 16/11/2026 in production for the new technical notes. Test filling in, rejections, events, referenced return and the bookkeeping files. Under LC 214/2025, the 2026 rates are 0.1% (IBS) and 0.9% (CBS), in arts. 343 and 346.

14How to start: with the scenario matrix or with the close test?+

With the matrix, because it defines what the close must contain. The first calculation, however, is the most recent close: take the last closed month, the documents and the adjustments that made it up, and use it as the starting data. That way the matrix comes from the real operation and the close test already has a reference value.

15What evidence does the auditor expect?+

The method guidance is to keep traceability: what was tested, against which expected value, with which data, in which version, with which result and approved by whom. What a specific auditor asks for should be asked of that auditor at the start of the project.

16How does the test method connect to the testing of each topic?+

The method is the base, and each topic has its own test. The SAP Tax Diagnostic and tax setup deal with the calculation. Split payment brings the ten-test plan of the mechanism. The alphanumeric CNPJ brings the test data set with the five patterns. The tax rollout brings the first invoice per unit, and tax ABAP brings ATC and the unit cases.

GUEPARDO Tax2 questions, 17 and 18

17When the result differs, how do you know whether the cause is the product, the setup or the in-house code?+

Start with the document's source data, then the process that generated it, and only then the configuration. Rerun the same case with the in-house extension switched off, when possible, and compare. The evidence comes before any call to product support, and the company decides how to handle the difference.

18How do you know whether a rule set up in GUEPARDO Tax was really proven?+

By the existence of a real document that exercises it, with the expected value written beforehand by the tax team and the result compared. A rule without such a document was only configured, not proven. List the rules, mark the ones that have a case and decide with the tax team what to do with the rest.

Next steps

Start with the month your team already knows

The first step is to take the last close and find out which scenarios it contained and which were left out of the test plan. Through contact, the conversation covers your environment, your data and the exit criteria, with no price and no commitment on timing.

Talk about the tax test plan Assess readiness in 2 minutes

To go deeper first: SAP Tax Diagnostic, Split payment in SAP and unstable tax close.

Comece por aqui

Projetos e sustentação

Reforma tributária

GUEPARDO

Por problema

Por setor

Processos fiscais

Automação e integração

Consultar e verificar

Todas as especialidades

Participar

Consultar

Acompanhar

Tax testing and validation in SAP: scenarios, evidence and what the technical test does not see

Go straight to the part of the tax test that fits your role

01Project manager

02Tax key user

03QA and IT

04Accounting and controlling

05Internal audit

Three proofs, and each answers one question

Technical test

Tax test

Close test

The right value comes from outside the system

The expected value written beforehand, by whoever decides

The thesis belongs to the client

The rule changes without the code changing

Six test levels, each with its own question

Five dimensions form the matrix

Operation

Origin and destination

Profile of the parties

Product or service

Document and event

How to reduce without losing what matters

Survey what the operation does

Group by equivalence

Mark the critical ones

Write the expected value

Give an owner and a date

The size of the matrix and the effort of execution

How many scenarios does the project really have?

Anonymized real data and what must not be masked

Real, anonymized or synthetic

What the data protection law says

Keep, because it determines the tax

Mask, because it identifies people

Two environments called testing, and what each one proves

The calendar changes, and the plan needs an effective date

NF-e

Split payment

NFS-e

Authorization of use: what it confirms and what it leaves open

Authorization of use confirms

Only the tax test confirms

The file validator does not replace the assessment check

File test

Assessment test

The test order follows data dependency

Document

Posting

Assessment

File

Payment slip and accounting

What to test in 2026, side by side

Document with the new groups

Settlement and withholding

Master data

Period assessment

Services

When testing can start, when it can end

Entry criteria

Exit criteria

The rule of not passing with an open tax defect

Coverage: cases tested over critical cases

Does coverage of the critical cases already allow exit?

The sheet that lets you repeat the case and reach the same result

How long to keep it

Automate the repetition, never the decision