Questions we get most, answered in depth

DFSpro does not work with SAP licensing price information. What can be said, based on market material, is that SAP uses a consumption model based on pre-purchased credits (called AI Units), consumed as Joule and Joule Agents are used, with a pricing structure that the market itself describes as not very transparent. For any investment decision, the right path is to ask SAP directly, or the licensing partner responsible for the company's contract.

Because a number only goes into a case when the client that produced the result confirms it and authorizes its release. We prefer to describe the problem and the solution applied with precision rather than publish a loose percentage without that confirmation.

The investment varies by project category and by the real complexity of the tax environment, it is not a single figure. There are three distinct categories: the SAP Tax Diagnostic (the first step, with the lowest relative investment), Stabilization or technical Migration projects (SAP ECC to S/4HANA), and recurring Continuous Governance contracts. There is no closed price table because each tax operation has a different scope and risk, and a generic range might not match reality. The most direct path to a real range is the Diagnostic itself: at the end, a prioritized risk map and, based on it, a concrete scope proposal. Request a Tax Diagnostic

It is modular. Each stage matches a real moment in the operation, not a mandatory item in a package. A company can enter straight at Stage 4 (Focused Project) if it already has an equivalent diagnostic, or stay only in Continuous Governance if the operation is already stable.

No. The pricing model varies with the line of work hired (Diagnostic, Stabilization Project, AMS, Migration), and the ranges are discussed directly during the commercial process, always after the diagnostic, because the real scope depends on what it reveals.

The pricing model varies with the line of work hired (Diagnostic, Stabilization, Migration, AMS Fiscal), and depends on the real complexity of each environment. The ranges are discussed directly in the commercial process, always after the diagnostic, because the real scope depends on what it reveals. A fixed number would be inaccurate for most cases.

Yes. The SAP Tax Diagnostic is the entry offer in the portfolio, with the lowest relative investment. Stabilization, Migration and Continuous Governance are hired separately, with their own scope and investment, defined after the Diagnostic shows what needs to be done.

This is defined contract by contract, depending on the line of work hired. There is no single rule because the billing format follows the type of project (Diagnostic with a closed scope, recurring Continuous Governance). The right way to confirm it is to bring the question to the team before signing.

No. Adding DFSpro does not require any change to the contract already in force with the infrastructure partner.

Each continuous governance cycle delivers a periodic tax health report and a record of the changes applied, with a justification, and the delivery is documented and verifiable, not a charge with no visible return.

It is a consulting service, with scope, deliverables and timeline defined in the proposal (see "Nature of the contract relationship" above). DFSpro delivers a defined piece of work, it does not make a professional available on a work schedule under the client's direct supervision.

Specific guarantees are handled case by case, within the commercial proposal of each project. DFSpro does not publish a generic guarantee clause because it varies by the scope hired; the right way to get this information is to bring the question directly to the team before signing.

Every Radar email carries a direct unsubscribe link, with no extra step.

No. The Diagnostic is a closed step in itself, with no commitment to future hiring. The decision to go ahead (or not) with Stabilization, Migration or Continuous Governance is always the client's.

Specific guarantees are handled case by case within the commercial proposal of each project, because they vary by the scope hired. There is no generic guarantee clause. The right way to get this information is to bring the question to the team before signing.

It depends on the line of work. The SAP Tax Diagnostic is a closed step, with no automatic renewal. Continuous Governance, on the other hand, is a recurring contract, and its exit terms are defined in the commercial proposal itself. There is no single loyalty rule published for the whole portfolio.

AMS Fiscal Advisory runs on an 8x5 basis by default (business hours, Monday to Friday). Coverage outside those hours (night, weekend, 24/7) exists as a scope add-on, sized when the operation requires it. The specific response time within these regimes is defined in the proposal of each contract.

The contract defines a milestone and a delivery for each stage (not just a single final date), and each delay is handled as a deviation to be resolved within the relationship, with an explicit, communicated replan, not as an automatic penalty clause. Where the delay is caused by a dependency on the client itself (access, data, a pending decision), this is recorded as such before it counts as a DFSpro delay.

Yes, AMS Fiscal Advisory classifies each ticket by severity (from a blocker that stops the tax close down to the lowest-urgency adjustment), and the agreed response time varies by that classification, it is never a single SLA equal for every type of ticket.

No. No data is sent until you click "See my result".

Not from this contact form. Your data is handled according to DFSpro's Legal Information (LGPD). The Radar newsletter is a separate, optional subscription, which you control.

No. Access is limited to the tax layer (setup, taxation rules, GUEPARDO Tax). DFSpro does not ask for general administrative access, nor for permission to change infrastructure, Basis or modules outside the tax scope.

Access to each item is released after registration. To receive any of them, just request access through the contact form; the material is sent right after.

The scope of access to the SAP environment during a Diagnostic or project is limited to the tax layer, never to general system administration, the same principle applied to coexistence with the current SAP integrator. A non-disclosure agreement (NDA) and formal data handling are part of the hiring process, and can be formalized before any work that involves sensitive data. DFSpro does not currently hold a formal information security certification issued by a third party. Confidential handling of data is formalized in the contract. GUEPARDO Tax, as an NTT DATA product, holds its own certifications (SAP S/4HANA Cloud Private Edition, SAP DRC, SAP TDF, ISO 27001, ISO 27017, SOC 2 Type II), which belong to NTT DATA.

No. The scope of access is limited to the tax layer (setup, taxation rules, GUEPARDO Tax), the same principle applied to coexistence with the current SAP integrator. General administrative access, Basis or modules outside the tax scope are not part of the work.

Data handling is formalized in the contract and a Non-Disclosure Agreement (NDA) before any work that involves sensitive data. There is no generic policy on post-project retention because it is defined contract by contract; confirm directly with the team before signing.

DFSpro does not currently hold a formal information security certification issued by a third party; confidential handling is formalized in the contract. GUEPARDO Tax, as an NTT DATA product, holds its own certifications (SAP S/4HANA Cloud Private Edition, SAP DRC, SAP TDF, ISO 27001, ISO 27017, SOC 2 Type II), which belong to NTT DATA, not to DFSpro.

Yes, access to client tax data is always formalized by a confidentiality agreement (NDA) before the work starts, and the scope of access granted is proportional to what the project stage requires, never broad access by default.

Yes, every credential and permission granted during the contract is revoked at the end of it, and this revocation is checked as part of the closing, not left for later.

"No incident at go-live" measures that the system went live, not that it has already survived the first real tax close. Most of the risk in this window shows up right after, when a specific scenario is run for the first time in production. The follow-up exists to cover that gap, not to fix a troubled go-live.

No. The Diagnostic delivers a prioritized risk map (Critical, High, Medium, Monitor) that is the basis for deciding the next step, whether it is a Focused Project, a Migration, entry into Continuous Governance, or none of the three. The decision is always the client's, with or without DFSpro in the sequence.

Yes. The report (prioritized risk map) is the contracted deliverable of the Diagnostic itself, independent of any later decision on whether to continue with DFSpro.

A deliberately limited number of simultaneous clients, which allows direct advisory service, with no helpdesk and no queue. When a tax problem comes up, the answer comes from someone who already knows that specific client's operation.

DFSpro does not serve early-stage startups, businesses with simple tax calculation, companies that do not use SAP as the core ERP, or those looking to hire by the technical hour with no commitment to a defined result.

DFSpro uses "deliberately limited number" without publishing an exact number. It is worth confirming directly with the team if that figure is decisive for your assessment.

DFSpro does not discuss price or compare cost with another type of supplier. A real cost comparison depends on the specific scope of each operation.

The tax governance methodology scales by process, not by squad size, and what sustains volume is the quality of the setup and of the continuous follow-up, not the number of people assigned.

The DFSpro model is deliberate: a limited number of simultaneous clients, which allows direct advisory service, with no helpdesk and no queue. This is a choice of depth, not a limit on capacity. The real fit criterion is not the size of DFSpro, it is the tax complexity of the client's operation inside SAP.

The DFSpro methodology does not depend on one specific person: it is a defined, documented sequence (Diagnostic, Stabilization, Continuous Governance), not knowledge concentrated in a single consultant. Setup adjustments and decisions are recorded, and autonomy is transferred to the client throughout the work, so that continuity does not depend on permanent contact with one specific person, on either the client side or the DFSpro side.

Ask how many simultaneous clients the team really serves, whether the person who presents the proposal is the one who does the work, and whether there is high consultant turnover during the same contract. A real consultancy has a number of clients limited by design, not by lack of demand, and keeps the same team from the start to the end of a project.

DFSpro works with a limited number of clients by design, so the capacity for a new project depends on the workload in progress at the time of the proposal. This is handled case by case in the commercial conversation, never promised generically before understanding the real scope of the project.

The structured Tax Diagnostic always happens before any closed commercial proposal. There is no negotiation of price or scope before it. If the buying process requires a specific or unusual contract format, raising it directly with the team before any formal approval is the fastest way.

No. The scope of access is limited to the tax layer.

If the cause is infrastructure, it is the integrator's; if it is tax setup, it is DFSpro's.

Yes, always, as part of the standard entry protocol.

No. The scope is a distinct technical slice, defined before the work starts.

No. Adding DFSpro does not require any change to the contract already in force.

It adds a specialized layer, it does not duplicate scope that is already covered.

By asking for a report that clearly separates measured risk (with evidence and a verification method) from estimated or hypothetical risk, with an owner and a mitigation deadline for each item, and not just a list of observations with no priority. The DFSpro SAP Tax Diagnostic delivers risks in exactly this format, prioritized.

Dependence on a single key person, response time if a consultant leaves the team, and whether there is documentation of what was done (so it does not rely only on tacit knowledge). DFSpro documents findings and technical decisions in writing precisely to reduce this single-person dependence.

Yes. The Presentation Library brings together 16 institutional and method materials, organized in three groups (institutional, specialties and method, and pitches by buyer role: CFO, CIO or SAP Manager, Tax Director), each one released through individual registration, with no commercial conversation required first.

No. Subscribing to DFSpro Radar does not trigger automatic commercial contact, and access to the Presentation Library does not require a commercial conversation either. The decision to talk to DFSpro remains yours, when it makes sense.

Yes. The first conversation is about understanding the problem, not closing a deal, and the SAP Tax Diagnostic is usually the input the company itself later uses to justify the budget to the board, with a concrete risk map instead of a generic estimate.

SAP version (ECC or S/4HANA), whether a tax calculation tool is installed (GUEPARDO Tax or another), how many CNPJs (company tax IDs) or plants the environment covers, and an objective description of the symptom that prompted the contact (a specific mismatch, an assessment notice, a late close). Having this ready is not a prerequisite, but it speeds up the first conversation.

It means keeping the setup correct over time: new tax rules, new CNPJs and branches, changes in legislation. Having the tool installed does not guarantee that it keeps reflecting the real operation month after month.

It is one of the most common patterns. Many operations use a fraction of what the tool offers because the setup stopped in time or was never tuned with rigor after the implementation.

Validation requires cross-checking setup, source data in SAP, applied tax rules, ancillary obligations, tax calculations and close evidence. The diagnostic identifies where the tool is working as a system and where it still depends on a parallel control.

Because an implemented tool is not the same as operational tax governance. Without process, setup review, traceability and recurring validation, inconsistencies can stay off the radar.

Not necessarily. The criterion for the CIO or SAP Manager includes companies with GUEPARDO Tax under evaluation, not only in operation. What matters is the real SAP environment (ECC or S/4HANA) and a context of change that justifies the diagnostic.

No. GUEPARDO Tax is a tax layer that runs integrated with SAP (ECC or S/4HANA). It depends on SAP as the core ERP; it is not a substitute for the ERP.

No. DFSpro's work is about setup and governance of the client's environment, without replacing official NTT DATA support.

Not automatically. GUEPARDO Tax calculates exactly what is set up: if the tax code and the determination condition for IBS and CBS have not yet been created and tested in the environment, the arrival of the effective date does not make the system calculate them on its own. The section "GUEPARDO Tax facing IBS and CBS", further up, details what changes in the setup. The full legal calendar and the regulatory detail of the Tax Reform are on the Tax Reform (CBS and IBS) page.

Yes. DFSpro sells GUEPARDO Tax licenses as an Authorized Channel of NTT DATA, implements the product when that is the client's starting point, and provides setup, governance and tax stabilization services on the product once it is implemented, described in GUEPARDO Tax Governance.

Yes. DFSpro operates as an Authorized Channel of NTT DATA in the GUEPARDO Tax ecosystem.

It means DFSpro is authorized by NTT DATA to work on the GUEPARDO Tax product within the standard recognized by NTT DATA itself.

No. GUEPARDO Tax is developed and maintained by NTT DATA. DFSpro works on implementation, setup, governance and stabilization on the product, as an Authorized Channel.

GUEPARDO Tax is an SAP-native tax automation module (from NTT DATA), charged per root CNPJ, with annual licensing, that centralizes tax rules inside the SAP environment itself. It is DFSpro's strongest technical differentiator in the ecosystem: deep specialization in how GUEPARDO Tax integrates with SAP (Clean Core, DRC, TDF, CDS Views), making sure the setup stays correct as legislation changes and new CNPJs enter the operation. Companies in the evaluation phase (still deciding whether to adopt GUEPARDO Tax) are also part of the profile served, not only those that already have the system implemented. GUEPARDO Tax: what it is. GUEPARDO Governance

This integration must be confirmed with SAP and with NTT DATA before it goes into any plan. GUEPARDO Tax works as a specialized tax engine layer on top of SAP, with its own data structure and logic, and how much of that layer is visible to a Joule query is a point to validate case by case, never assumed to be solved by default.

Because part of the logic that determines that result may be configured inside GUEPARDO Tax, and not necessarily replicated in full in the semantic layer that Joule queries natively inside SAP. If that happens, Joule's answer reflects only what is visible from the SAP side, which may look like a complete explanation without being one.

No. GUEPARDO Tax is a technical add-on for the SAP environment (ECC, S/4HANA or SAP TDF), installed on that specific infrastructure; a company running another ERP is not the audience for this product.

DFSpro does not publish a generic percentage of time savings without a specific measurement in the client's environment, for the same reason it does not publish a case number without authorization (see the question about cases with no specific financial figure). The time gain is discussed, with a measurement method, within the SAP Tax Diagnostic itself.

It runs as an add-on inside the client's own SAP environment (ECC, S/4HANA or SAP TDF), without requiring a separate server or replacing the ERP core.

No. DFSpro works in the slice of tax governance and GUEPARDO Tax, technically distinct from general SAP infrastructure and operation.

No. It is a working protocol that applies to any integrator the client already has, not a named commercial agreement with a specific integrator.

Yes, as part of the standard entry protocol. DFSpro introduces itself to the current integrator, describing the same boundary of responsibility, with transparency of scope. We do not go behind the back of whoever is already in the environment.

DFSpro does not control, and does not promise to control, the current partner's reaction. What it does guarantee is clarity of scope from the first contact and the decision not to take part in commercial conversations that involve the partner's contract with the client. A clear technical boundary is usually what reduces friction.

It is not a problem, it is the most common starting point. The fit criterion does not ask for exclusivity, it asks for recognition that there is a gap between what the current partner delivers and what the operation needs. The How we work with your team page details this boundary of responsibility.

Yes, and it is one of the best-fit contexts. DFSpro works as a tax specialist layer alongside the integrator, covering what usually falls outside its scope. The detail of the split of responsibility is in the ECC to S/4HANA Migration page.

No. The S/4HANA integrator remains responsible for the technical migration: architecture, infrastructure, Clean Core and module integration. DFSpro works alongside that integrator, with a defined and distinct scope: tax risk assessment, integration with GUEPARDO Tax and post-go-live stabilization.

No. They prepare the conversation, they do not replace it. The SAP Tax Diagnostic is the step that depends on each company's real operation, something no institutional material can cover in advance.

Because maintaining a stable environment depends on continuity of specialized knowledge, exactly what team turnover and frequent regulatory change make hard to sustain with the internal team alone, without a dedicated follow-up layer.

No. It is a specialist follow-up layer on the setup, not the day-to-day operation. Running the daily routine stays with the client's internal team.

No. It is a complementary discipline, specific to the Stabilization period. For the full detail of the relationship with the current SAP partner, see How we work with your team.

Yes. The methodology documents how the work is carried out and how decisions are recorded, in a format suited to Legal and Compliance due diligence before approving a contract.

No. DFSpro does not replace the SAP integrator responsible for the infrastructure and the broad functional modules of the environment. It works as a specialist tax governance layer inside SAP and GUEPARDO Tax, a technical slice that is often not the focus of a generalist integrator. The boundary is explicit: infrastructure, Basis and broad functional modules stay with the current integrator; tax governance, setup and continuous monitoring of tax changes stay with DFSpro. The scope of access is limited to the tax layer, with no general administrative access. How we work with your team and SAP partner

Transferring autonomy to the client is one of DFSpro's operating features. Setup adjustments and decisions are documented, and internal key users receive effective training, so that stability does not depend on a single person or on permanent contact with DFSpro.

Two objective questions that DFSpro's differentiating mechanism already answers: does the same team that interprets the tax rule also know where it is set up in SAP (or does it depend on hand-offs between separate teams)? And is there a documented method, not just a verbal promise, that defines how the diagnostic, stabilization and continuous governance happen?

That is exactly what the SAP Tax Diagnostic assesses first: where the current setup breaks under the real volume of your operation, before proposing any adjustment.

No. DFSpro deals with the intersection between the sector obligation and the tax setup in SAP; the formal regulatory reading remains the responsibility of your Compliance or legal team. The value is in translating that obligation, already validated by them, into the system's tax governance.

No. DFSpro works on the environment you already have, without requiring a change of product supplier or any change to the existing contract.

No. DFSpro works as a specialist second line on the tax layer, alongside the integrator that looks after the infrastructure and the general operation. See "How we work with your team".

No. The SAP Tax Diagnostic is the entry assessment for any SAP and GUEPARDO Tax operation, migrating or not. The focus is the tax risk of the version migration event.

Yes, and this is a common part of post-go-live stabilization work: the SAP Tax Diagnostic maps what a previous supplier left incomplete or badly set up before deciding the correction plan, instead of assuming the environment was correct.

Contribution on Goods and Services: a federal tax created by the Brazilian Tax Reform (Constitutional Amendment 132/2023, regulated by Complementary Law 214/2025) to replace PIS and Cofins over the transition period. Calculating it correctly inside SAP depends on specific tax setup, not on an automatic system version update.

A state and city tax created by the Brazilian Tax Reform (Constitutional Amendment 132/2023, regulated by Complementary Law 214/2025) to replace ICMS (Brazil's state value-added tax) and ISS (the city services tax) over the transition period. In a SAP operation, calculating it depends on tax configuration and correct integration between SAP and the tax calculation software, it is not automatic.

A mechanism provided for in the Brazilian Tax Reform in which the IBS and CBS amount of a transaction is separated and collected directly at the moment of payment, instead of being calculated and paid later by the company. Putting it into operation inside SAP requires adapting the existing financial and tax flows; the technical regulation by CGIBS and the Federal Revenue Service has begun to be published (Joint Act RFB/CGIBS No. 2, of 27/05/2026, cgibs.gov.br/atos-conjuntos), with actual collection expected from 2027, to be confirmed at each review.

CBS is federal and replaces PIS and Cofins; IBS is state and city and replaces ICMS and ISS. In SAP, each one needs its own set of determination, calculation and reporting rules, coexisting with the current taxes during the transition. It is not a new rate on the existing structure: it is a second tax determination structure running in parallel with the current one.

Split payment (collecting the tax at the moment of financial settlement of the transaction) is planned for certain operations; the technical regulation has begun to be published (Joint Act RFB/CGIBS No. 2, of 27/05/2026, cgibs.gov.br/atos-conjuntos), but actual collection remains tied to the CBS and IBS schedule, from 2027. Where it applies, it changes the timing and form of collection, which can affect the integration between tax and finance inside SAP. The Readiness Assessment identifies whether, and where, this touches your specific operation.

Not necessarily. Adapting to CBS and IBS is a tax setup change that can be done in both ECC and S/4HANA. If a migration to S/4HANA is already on your horizon, it makes sense to coordinate the two fronts; if not, the adaptation is handled in the current environment. See ECC to S/4HANA Migration for the case where the two coincide.

The broad tax strategy of the Reform (high-level regulatory decisions) can come from any heavyweight advisory firm. DFSpro's work is different and complementary: making sure SAP and GUEPARDO Tax carry out that strategy correctly, in a sustainable way, day to day. DFSpro does not compete at the level of regulatory definition, it works at the level of technical execution inside the system. Legal calendar (LC 214/2025): 2026 is a test phase (test rates of 0.1% for IBS and 0.9% for CBS, with CBS and IBS shown on the tax document). The Split Payment mechanism (arts. 31 to 34 of LC 214/2025) has been formally in force since 01/01/2026 (art. 544, item VI), but there is no actual collection in 2026: it is a purely informational calculation year, with no tax effect (Joint Act RFB/CGIBS No. 1, of 22/12/2025), while the Federal Revenue Service and the IBS Steering Committee publish the technical regulation of the mechanism (already under way, Joint Act RFB/CGIBS No. 2, of 27/05/2026, cgibs.gov.br/atos-conjuntos). Actual collection through Split Payment starts from 2027, with IBS still at 0.05% state and 0.05% city in 2027 and 2028. In 2027 CBS starts to use the reference rate set by the Senate. Between 2029 and 2032 ICMS and ISS are reduced gradually, with IBS charged at the reference rate that the Senate sets each year, and the transition ends in 2033. Tax Reform (CBS and IBS)

It can. Many regional benefits are tied to ICMS, which is gradually replaced by IBS between 2029 and 2033. Reviewing how each benefit behaves through this transition, and what needs to be reconfigured in SAP, is part of the adaptation, and is one of the reasons not to leave the Reform analysis to the last minute.

Besides the general change in taxation of goods and services, you need to assess how the CBS and IBS transition interacts with the sector ancillary obligation that already exists. The effect is not only tax-related: it can change how the same event is read in the two layers, and this joint assessment is part of the adaptation.

Yes, over the course of the transition. ICMS (and the tax substitution that today governs operations between plants) is gradually replaced by IBS between 2029 and 2033. While the two regimes coexist, multi-plant operations are among the most error-prone, which is why the CBS and IBS adaptation comes early in planning for this sector.

Yes. The dual VAT model (federal CBS and state and city IBS) replaces the calculation based today on ICMS, ISS, PIS and Cofins with a unified credit and debit logic per transaction, which requires reconfiguring the SAP tax engine, not just adjusting a rate.

Yes, during the transition period (rule in force until 2033) the company runs two tax systems in parallel, which temporarily increases setup complexity before it simplifies in the final regime.

The ICMS credit accumulated up to the start of the transition follows its own rules of use defined in the reform regulation, distinct from the new credit generated under CBS and IBS; treating the two as equivalent in SAP is a common setup mistake to avoid.

No. The result reflects only your own answers, with no stated comparison with another company or with market statistics.

The institutional and method materials are general (they apply to any complex SAP tax operation). Anyone who wants the translation into the technical context of their own sector will find it on the sector pages, not in this library.

Direct references are possible when the client authorizes, case by case, usually at a later stage of a commercial conversation. We do not expose clients to outside contact without their prior consent.

Our work is concentrated in four priority sectors (Agribusiness, Manufacturing, Distribution and Retail, Energy and Regulated industries). Each has its own page with the technical translation of that vertical's tax problem, which is the most concrete way to assess fit before a named case exists.

A case is only published with the client's own confirmation of the result described, even when the company name does not appear. Anonymization protects the client's identity, not the truth of the case, which is why the text describes the problem and the real change of state, not a generic marketing number.

What repeats across sectors is not the surface problem, it is the pattern behind it: dependence on a side spreadsheet, tax knowledge concentrated in one person, or setup that did not keep up with a rule change. The sector pages exist precisely to translate this pattern into the specific technical context of your segment.

Not necessarily. The published cases are a sample limited by what was authorized for release, not DFSpro's fit criterion. The real fit criterion is described in Is this for you?, and it is worth checking there before ruling yourself out because of what did not appear in a case.

The structure (mapping, analysis, prioritization by risk) is the same; what changes is the specific technical slice of each vertical, applied on top of the same diagnostic discipline.

DFSpro only publishes a client's name and result with explicit, confirmed authorization. Several active clients are in the authorization process; others are handled confidentially by the client's own decision. Meanwhile, the proof available is the methodology and the technical depth, verifiable today. See Cases.

No. It only means we do not yet have a dedicated page for your sector. The real fit criterion is size and tax complexity inside the SAP environment. See Is this for you?.

The most direct sign is a recurring tax complexity point specific to your vertical inside SAP (tax substitution between plants, high invoice volume, dual regulatory and tax compliance, multi-CNPJ spread). If your operation lives with one of these patterns, the sector reading helps; if not, the size and complexity criterion in Is this for you? is the most objective path.

No. DFSpro's contracting model is defined by the specialty and the real scope of the work (diagnostic, project, AMS), not by sector. The sector guides how the problem is read and the language, not the commercial structure.

It is common, and it is not a problem. The same company often crosses more than one vertical (for example, a food-industry company with a distribution arm). In practice, the diagnostic starts from the real operation and the existing setup, not from a single sector label; the sector reading is there so the specific complexity of each front is not missed.

They are two entry points to the same work. The sector page starts from "my vertical reality looks like this"; the problem page starts from "the pain I am feeling now is this". Both lead to the same diagnostic; use the one that best describes your moment.

The starting point is always a diagnostic of the real environment, not a prior sector framing. If your vertical has a tax peculiarity not described in the sectors served, it is exactly this kind of detail that the diagnostic exists to map. See Is this for you? for the fit criterion and the next step.

DFSpro works at the intersection between the SAP tax landscape and the ancillary obligation imposed by your sector's regulatory agency. The reading of the specific regulatory obligation is validated together with the client's Compliance team. DFSpro's work does not replace a formal regulatory opinion.

We are a specialized consultancy, with a limited number of simultaneous clients. This is a structural choice: we work with a direct senior team, with no junior support layer, and that is what sustains direct partner attention in each contract.

Sector authority comes from the concrete technical translation of each vertical's tax complexity. Named cases, when authorized by the client, appear in the Portfolio.

The cases published on the site only carry a specific number when the client that produced the result confirms it and authorizes its release (the same rule applied to any case metric). Where that authorization does not exist, the problem and the solution are described without the number.

Yes, DFSpro's fit criterion is the complexity and risk of the SAP tax environment, not the sector by itself. The cases published today concentrate on manufacturing and distribution and retail, but the same method applies to a services company with complex SAP tax needs.

SAP Joule is SAP's generative artificial intelligence copilot, built natively into the ecosystem's cloud applications (S/4HANA, Ariba, SuccessFactors, among others). Unlike a generic productivity assistant that works outside the system, Joule works from inside the ERP itself, with access to the same data layer and permissions that the signed-in user already has. It answers questions in natural language, helps navigate between screens, summarizes documents and information, and generates analyses from data already in the system. In more recent versions, it also carries out actions through specialized agents, called Joule Agents.

Joule processes a question or command in natural language, interprets the intent behind it, and looks for the answer inside SAP's business semantic structure (organized, among other components, by the SAP Knowledge Graph). Depending on the type of request, it may only point to where to find a piece of information, summarize existing content, generate a data visualization, or, when configured as an agent, carry out a sequence of steps inside a business process. What Joule can answer well depends directly on how well organized, documented and up to date the configuration of that specific SAP is, which is especially relevant in Brazilian tax.

Not automatically or with a guarantee. Joule understands the structure of SAP itself well, but the quality of an answer about a specific Brazilian tax rule depends entirely on how that rule is configured, documented and kept up to date inside that SAP. If the rule exists only as informal knowledge (in a side spreadsheet or in one person's experience), Joule has no way to access it, and will answer with the general rule, which may be wrong for that specific case.

Yes. DFSpro sells and implements SAP Joule, as part of the SAP portfolio it sells and deploys. The work does not stop there: DFSpro also works on applied tax governance, assessing and preparing the base of data, rules and tax exceptions so that the AI layer (Joule or another) runs on a reliable foundation, with traceability and accountability preserved. This second point is stronger precisely because it comes from someone who also sells and implements the solution: it shows judgment, not unavailability.

The most natural entry point is the SAP Tax Diagnostic, with an additional scope to map specifically the condition of the tax base to support automation safely (master data, rules, exceptions, traceability). From there, continuous follow-up within AMS Fiscal is the natural space to evolve the use of AI in the tax routine over time, always with the same governance discipline applied to any other front of the operation.

No. Tax decisions always belong to the client. DFSpro's role is to design, configure and prove the behavior of the system, including the behavior of any AI layer applied to it, so that the decision, whether made by a person or supported by a Joule suggestion, has the context, traceability and defensibility needed to be sustained before an audit or an inspection.

Because the spreadsheet exists to cover a tax exception that the main system does not handle natively, and an AI copilot that only queries SAP has no access to that knowledge unless it is formally brought into the system's configuration or documentation. AI does not remove the side Excel on its own, it just starts to live alongside it without knowing it exists.

Three moves, according to market sources: the expansion of the Joule Agents catalog, including procurement areas; Joule Studio as a way to build agents and agentic flows; and the confirmation of general-availability integration with Microsoft 365 Copilot, including an interoperability layer between agents from different platforms.

It is a recurring contract, with no defined end date, unlike the Stabilization project (fixed term of 90 days). Audit cadence, included scope and adjustment terms are defined in the contract, sized by the size and complexity of the environment.

The senior response prioritizes technical analysis by a SAP tax specialist, with guidance on impact, probable cause, urgency and the next operational step.

No. The Diagnostic is hired as a stand-alone delivery, with its own scope and timeline. The decision to move to a Stabilization project is made later, based on what the report shows, not before.

By severity and real impact, not by order of discovery. The result is a prioritized map (critical, high, medium or just monitor), so that effort goes first to what creates the most exposure.

Always with the SAP Tax Diagnostic. No project is sized before the diagnostic maps the real state of the environment and prioritizes the risks.

No. DFSpro works with a defined sequence (Diagnostic, Stabilization, Continuous Governance) that is the real structure organizing any project, not a sales funnel slogan and not knowledge concentrated in a single person.

In most cases, no, because IT change management is designed to protect system stability and performance, not to validate tax impact. It is exactly this formal tax checkpoint, inside the existing IT flow, that is usually missing.

The reading covers the chain, not an isolated step. What changes tax treatment in agribusiness is precisely the transition between steps (production, industrialization, distribution) and between CNPJs; assessing only one unit misses exactly where the criteria tend to diverge.

By real risk, not by alphabetical order of state. Prioritization combines the volume of invoices affected by each rule with the probability and impact of error, to fix first what creates the greatest tax exposure per unit of effort.

This documentation lives in our Methodology, with specific detail for Legal and Compliance.

Each finding is cross-checked against real evidence from the environment itself (setup, SPED, tax calculation), not only against interviews or the internal team's perception; where the evidence does not allow something to be confirmed with certainty, this is recorded as such in the report, never presented as fact.

It delivers both: the prioritized risk map and, from it, a concrete scope proposal for the next step (stabilization, migration or continuous governance), not just a list of problems with no path to a solution.

Usually because one of them uses stale data, a different filter or period, or a setup rule that changed between the two reports being generated without being documented; identifying which of these causes is the real one is part of the diagnostic work itself.

It is the most common scenario for those who hire AMS Fiscal Advisory: instead of growing the internal team, continuous governance is run by a specialized external team, with the internal team keeping the final decision on what to do with each finding.

Accumulation of outdated master data, a state legislation change not reflected in the original setup, and a customization made to solve a one-off problem that became a permanent rule without review. These are risks that a diagnostic done only at go-live would not capture, because they did not exist yet.

10 objective questions about the SAP tax operation, designed to be answered in a few minutes.

Usually within 1 business day. The answer comes from a senior specialist who reads your message, not an automatic confirmation of receipt.

Before or at the start of technical planning, in the pre-migration risk assessment phase, when it is still possible to map the tax rules and setup active in the current ECC environment before any architecture decision is made.

5 to 8 weeks, run by a senior team. The exact time depends on the complexity of the environment (number of CNPJs, SAP version, scope of obligations) and is confirmed at the start.

There is no universal calendar term, the most reliable indicator is not counting months, it is having completed, with no emergency adjustment, at least one full tax cycle (monthly and, where applicable, annual) in production. It is this milestone, not a fixed date, that signals the move to Continuous Tax Governance.

Because Stabilization is deliberately fixed-term: it covers the window of the first real tax cycle after the project. Open-ended support is something else (Continuous Governance), with its own cadence and contract.

It depends on the current state of your tax setup. With CBS taking full effect in 2027, planning and the project window need to exist before that, and the Readiness Assessment is the step that tells you whether your current budget cycle or the next one is the right moment.

The start is agreed case by case, from direct contact. There is no SDR queue or long commercial process before the Diagnostic: the first conversation is already with a senior specialist, and from there the kickoff is set according to the availability of both sides.

DFSpro began working in the GUEPARDO Tax ecosystem in 2018.

It varies with the severity of what the initial diagnostic finds; there is no single number valid for every environment. The first close cycle after the contract starts usually already shows whether the priority adjustments were enough or need a second round.

The Clean Core philosophy limits direct customization in the system core, moving logic that used to be built into ECC to extension layers. Tax rules set up for years in ECC need to be reassessed one by one to confirm where they remain valid and where they need a new extension.

Both. The Diagnostic assesses the real tax setup, whether it is ECC or S/4HANA, and even helps size the tax risk before a possible migration.

S/4HANA tends to have a more direct support path from the vendor for the new tax requirements. ECC that has not been migrated usually calls for a specific assessment of what is supported natively and what would need an adaptation project before the transition. In both cases, the tax setup of your master data still needs to be validated.

No. These credentials belong to NTT DATA, not to DFSpro. They are mentioned as context about the product. See the attribution note in the section "NTT DATA Credentials".

No. DFSpro works in both SAP ECC and S/4HANA. Migration is only one of the possible Focused Projects, triggered when it makes sense, not a prerequisite. In fact, the Diagnostic helps size the tax risk before a possible migration.

It is one of the best moments. A migration or consolidation forces the tax setup to be revalidated anyway; using that window to handle ICMS-ST and DIFAL between plants avoids carrying a mismatch that already existed into the new environment. See ECC to S/4HANA Migration.

No. Assess Readiness is a questionnaire of 10 objective questions about the SAP tax operation, with no registration to start.

Registration is per material, not a single one for the whole library. Each of the 16 has its own access button.

The risk is recorded and classified in the same way as any other prioritized item (Critical, High, Medium, Monitor), with a recommendation on how to handle it, even if the recommended answer is not a new project with DFSpro.

It is worth understanding, before hiring, whether this scenario is covered by the follow-up or turns into a separate project. The answer changes the real financial risk of the 90 days.

The criterion is not company size, it is the complexity of the SAP tax environment: multiple CNPJs, a history of assessments, or manual calculation outside the system justify a diagnostic regardless of revenue. A small company with a simple environment may not need one, but that is only confirmed by assessing the case.

Outdated material or customer master data, tax setup that did not keep up with a state legislation change, and a mismatch between what SAP calculates and what is transmitted in SPED (Brazil's digital tax reporting system). The exact frequency of these three types varies by client and is not a single generic number.

Service is remote and national by default, which allows serving companies that run SAP in any region of Brazil. Specific needs for on-site presence can be agreed case by case during a project.

The same team that interprets the tax rule is the one that knows exactly where, inside GUEPARDO Tax and SAP (ECC or S/4HANA), that rule must be set up, with Clean Core, DRC and TDF treated as everyday working vocabulary. This stops a tax problem from turning into a cycle of hand-offs between departments.

It is the calculation schema configured in SAP that defines the sequence and logic for calculating each tax (tax base, rate, condition) within a sales or purchase document. It is the technical structure behind every tax price condition, and a badly made adjustment in it is a common source of calculation errors. See DFSpro Glossary.

It is the organized representation, usually in a spreadsheet or configuration table, of how each tax applies by combination of material, customer, operation and state. It serves as a reference to check whether the SAP setup is really aligned with the rule in force, and it is usually one of the first documents a SAP Tax Diagnostic tries to rebuild when the client does not have it formalized. See DFSpro Glossary.

The MM module (Materials Management) is responsible for the purchasing, receiving and inventory management process in SAP. Tax determination for an inbound invoice starts from the purchase order and receipt information recorded in this module, so a master data or flow error in MM spreads straight into the tax result of the purchase. See DFSpro Glossary.

A SAP technical note (SAP Note) is an official correction or guidance published by SAP for a specific system problem, including Brazilian tax legislation updates. Applying, or failing to apply, a tax technical note on time is one of the most common causes of mismatch between what SAP calculates and what the legislation in force requires. See DFSpro Glossary.

It is the configuration, inside the SAP tax engine, of the rules that determine which tax applies to each transaction (CFOP, NCM, customer regime, applicable tax benefit). It is one of the points most sensitive to error in a SAP tax environment, because an outdated or badly configured rule creates a systematic mismatch, not an isolated error. See DFSpro Glossary.

It is the invoice issued to correct or supplement the amount, tax or information of an original invoice that was already transmitted, without cancelling it. It is used when the error is only found after issuing and there is no longer a window for a simple cancellation. See DFSpro Glossary.

It is the document issued to charge the recipient an additional amount (tax, freight, price difference) related to a transaction already documented by an invoice. Unlike the supplementary invoice, which corrects the original tax document itself, the debit note represents a financial charge. See DFSpro Glossary.

They are two regimes for calculating corporate income tax (IRPJ and CSLL): under Real Profit, the tax applies to the accounting profit actually calculated, with tax adjustments; under Presumed Profit, to a profit margin presumed by law according to the activity. The choice of regime directly affects how certain postings and calculations are set up in SAP, and switching regimes without reviewing that setup is a common source of error. The decision on the regime always belongs to the client; DFSpro works on the corresponding technical configuration in SAP. See DFSpro Glossary.

It is the differentiated tax treatment granted by a state to a specific company or sector (reduced rate, its own payment deadline, exemption from an ancillary obligation), formalized by an agreement or special regime with the state tax authority. It requires its own setup in SAP, outside the state's general rule, and it is often forgotten when SAP is reconfigured in another project. See DFSpro Glossary.