SAP Notes for the Brazilian Tax Reform: how to track, decide and prove they were applied

Six steps between the publication of a note and the proof

The note is the start of the work, not the end. The cycle applies to any note with a tax effect, from the reform or not.

Tracking a note is a decision with an owner and proof

SAP delivers the fix. The company decides whether it goes in, when it goes in and how to prove the calculation is still right. The reform itself, tax by tax, has its own page at Tax Reform: IBS and CBS in SAP, and the notes process starts where that page ends.

The notes and the reform guides that organize the work

For the Brazil reform, SAP maintains reference notes that say what was delivered and in what order to implement it. The process starts from them.

Source: SAP Community, SAP publication on the impact of the Brazil tax reform on SAP users.

Six channels and one routine so no note arrives unannounced

To monitor is to have defined channels and a fixed time to read them. Without that, the note arrives through technical application and the tax team finds out later.

A named owner reads the six channels at a fixed time and opens a line in the single list of notes. All the rest of the process starts from that list.

Twelve fixed dates to read the notes of the month

SAP publishes the new security notes on the second Tuesday of each month. The 2026 dates are below.

Customers find the notes in SAP for Me, in the security notes area, by choosing the full list. The Support Package level of the system decides whether the month's fix reaches it.

Source: SAP Support Portal, SAP Security Notes and News. Maintenance policy in note 3053725.

The note backlog: what is already in and nobody has assessed

Before the process applies to new notes, you need to know what was already applied in the system. That backlog is the first result of the work.

A note implemented incompletely deserves special attention: the system keeps working and may calculate differently from what is expected without any warning. That is why the survey separates complete implementation from partial.

The result is the first record for each relevant note and a list of open items, each with an owner and a date. The tax readiness checklist helps measure the rest of the system.

Four categories to say whether the note touches tax

Triage separates the note that needs the tax team from the one that does not. The criterion is the effect of the note, not the component it changes.

The blind spot between IT and tax, which this filter closes, is described in the blog article on SAP Notes with tax impact.

Eight questions the owner asks of each note

The first four questions decide whether tax gets involved. The last four decide the order and the window.

• Does the note talk about tax, base, rate, classification or tax status?
• Does it change a field, table or setting in the tax master data for a product, partner or operation?
• Does it change the content of the tax document XML or a validation rule?
• Does it touch the integration with the tax assessment, with SPED or with bookkeeping?
• Does it require manual activity after implementation, such as setup or a table adjustment?
• Does it depend on another note, a Support Package or a component version that the system does not have yet?
• Is there a customer-owned object at the same point, such as an exit, a BAdI or a Z program?
• Is there a legal date that requires the new behavior?

Any yes to questions 1 to 4 sends the note to the tax team. Questions 5 to 8 do not change the category: they define the order, the window and the test effort.

Apply, postpone or do not apply: the decision with written criteria

Every note with a tax effect ends in one of four decisions. Not applying also counts, as long as it has an owner and a reason.

The date of the note comes from the tax authority, the window comes from the operations calendar

Two dates decide when the note goes in: the one the law imposes and the one operations can tolerate. The first is fixed, the second is planned.

The window is a shared calendar. Tax marks the sensitive periods, IT marks the technical windows, and the free overlap becomes the application schedule.

With the schedule ready, the question on decision day stops being when it fits and becomes which window suits this note.

Note by note, in the right order

The reform notes depend on one another. The order is not the implementer's choice: it comes from the dependencies.

The XML is updated often, so the order is reimported at each round of application.

Source: SAP Community, SAP publication on the Brazil tax reform.

What the SAP tool does and what remains human work

The tool reduces execution errors, but decides nothing. Separating what it does from what stays with the team avoids the illusion that an applied note is an assessed note.

The Note Assistant, transaction SNOTE, is SAP's standard tool for this task. Its work list separates the notes assigned to the user, the inconsistent ones and the new ones not yet processed.

Digitally signed notes can only be downloaded and uploaded with SNOTE enabled for that, and the steps are gathered in note 2836302. The enhanced version of the tool requires SAP_BASIS 7.40 SP02 or note 3051466.

Source: SAP Support Portal, Note Assistant, and Note Assistant documentation on SAP Help.

Four systems, one sequence

The note goes through the systems in the order of the customer's other changes and only moves on with the approval of the previous system.

The DFSpro process implements the note in development and moves the same request through the transport route. Implementing straight in production breaks the sequence and removes the proof that the test looked at the same code that will run.

Quality only works as proof with data that keeps what determines the tax, such as NCM, state, tax regime and partner profile. The method is in tax tests and validation.

Six rules so the note does not reach production out of order

Transport is where the dependency order is most easily lost. These rules protect the sequence.

Before, during and after the import in production

Import day is short and leaves little margin. That is why every step is written down beforehand and has an owner.

The note is only considered complete after tax follows the first real invoices and confirms that the result matches the expected one.

Where the note meets what the customer has already changed

When the tax system has custom code around the calculation, the standard note can collide with it, and the collision does not show up in a screen test.

Before applying, IT lists the custom objects and the extension points in the stretch the note touches, and tax says which business rule each one carries. A collision found becomes a decision item, not a silent adjustment.

The less custom code in the calculation, the smaller the collision, and that is the argument for tax Clean Core. The design and review of the code that stays are in ABAP and tax customization.

Take a snapshot of tax behavior before the note

Without a snapshot of the before, the after proves nothing. The baseline is built in quality, before the note goes in.

• One reference document per operation, with the tax of each tax type.
• The calculation result for the critical cases, with base, rate and tax status.
• The XML generated in the most used electronic document types.
• The tax assessment report for a closed period, for comparison.
• Date, and the version of the note and of the component at which the snapshot was taken.
• The author of the snapshot and the tax person who accepts the values as correct.

The snapshot does not need to be large. It covers the cases the note may touch, chosen in triage, and reuses the scenario matrix the company already uses in tax testing.

When the note brings a new field, such as the IBS and CBS ones, the snapshot records that the field was empty before. The expected effect includes the field coming to exist.

What to run after the note, by category

The note regression is smaller than a project test. It runs only what the triage category may have changed and compares it with the snapshot.

Scenario matrix, data sets and test levels have their own page: tax tests and validation. For the note, only the slice the category asks for applies.

The regression runs in quality, with the note already implemented in the correct order, and ends with the tax signature.

Write the expected effect before the test

A reform note changes the result on purpose. So the test does not look for any difference: it looks for the right difference.

The expected effect is written by tax before the implementation, with the rule that supports it. The CST and cClassTrib table is the starting point of the expected result for classification.

Comparing the after with the expected result and with the snapshot gives three outcomes: it matches, justified difference, or unexplained difference. The first two pass. The third goes back to IT and to tax.

Six records that prove the note went in

Applied is what the system shows, not what the team remembers. Proof of application is technical and comes from the system itself.

The set is attached to the note record. Whoever audits can rebuild, from it alone, what changed, where, when and on whose order.

What proves the calculation is still what the company decided

A correct application does not guarantee a correct effect. Proof of effect compares the result with what tax wrote beforehand.

Each rejected case opens an item with an owner and a deadline, and the note only moves on to production with all critical cases approved. Going ahead with a known difference is the customer's decision and is written down, with the reason.

In production, the first tax assessment after the note gets reinforced checking: tax compares the result with the previous period and records the explained differences.

Who decides, who executes and who signs

Each step of the process has a role that decides, one that executes and one that signs. When the same role does all three, the proof loses value.

The owner of the list of notes is a named person, with a deputy. The decision meeting is short and periodic, and tax and IT sit at the same table.

The note record: eight fields that stay in the customer's system

The record is a single entry per note, kept where the customer already controls changes. A loose file does not serve as proof.

Where the customer already uses a change management system, the record becomes a form in it, with the same fields. The audit question of who assessed the note and why is answered by opening the record.

The retention period is defined by the customer's legal and tax teams.

The rollback plan comes before the import

Not every note rolls back easily. That is why the way back is defined beforehand, and so is the criterion for going back.

Rollback needs an owner with the power to trigger it. It also has a clock: tax documents already authorized follow their own cancellation and correction rules, and the plan takes that into account.

Eight failures that turn a note into a tax problem

Eight patterns repeat when the process fails, and each has an answer in the process.

Six signs that the process is working

A process only improves when someone measures it. These six signs fit on one monthly tracking page.

The indicators feed the monthly management conversation. Targets and limits are set by the customer, and no value should be copied from another system.

When the tax calculation runs in GUEPARDO Tax

The GUEPARDO Tax license belongs to NTT DATA, and DFSpro sells it as an Authorized Channel, in addition to implementing and governing the product.

Whoever uses GUEPARDO Tax in part of the operations and the standard SAP calculation in others keeps a single list, with the origin of each item.

The four fronts of the work with the notes

DFSpro structures the process and runs it alongside the customer's team. For those who do not yet know what is already in the system, the way in is the SAP Tax Diagnostic.

Who decides each note and what DFSpro delivers to the customer

The decision on each note belongs to the customer. DFSpro delivers the process design, the configuration of what the system allows and the proof of how it behaves after the note.

Reference documentation and publications

Start with the list of notes that tax has not read yet

The first step is to survey what was already applied, in what order and without tax assessment.

For a deeper look: Tax Reform: IBS and CBS in SAP and tax tests and validation.