From GRC NF-e to DRC: what migrates and when to use DRC or GUEPARDO Tax

What SAP said and what it did not say

When and why to migrate

Migrating is the client's decision. What SAP wrote gives four triggers to make it with a date, and all of them have a source: the post of 13/04/2023, the author's comments, the announcement of 04/02/2020 and the what's new list of the outbound service.

Questions that set the timing

• Is your GRC NF-e already in customer-specific maintenance, or still in mainstream maintenance under your contract? The support terms are in your contract with SAP: confirm with SAP.
• Is there an S/4HANA conversion project or a rollout in the same period? Migrating the document together with the ERP avoids designing twice.
• Does the tax reform already require a new field on your invoice? The tax lead checks the act in force, and the technical team checks what the contracted DRC version documents.
• Is there a window in the tax calendar that the cutover must avoid, such as month-end close? The client decides.
• Who manages the SAP BTP global account and the licenses today? Without that access, the project cannot generate the credentials.

The GRC NF-e life cycle, with date and source

The timeline below gathers only what SAP wrote, in date order. Two of the dates come from comments by the post's author, an SAP employee, and not from a formal announcement.

The right names: GRC NF-e, DRC and cloud edition

The acronym DRC appears in more than one product, and the project conversation only moves when everyone talks about the same one. SAP's help also says that the inbound service changed its name on 11/08/2022, from SAP Document Compliance to SAP Document and Reporting Compliance, without changing how it works.

The first item of the inventory is to note which of these products the client uses and which it plans to use. A SAP Community post of 11/02/2026 describes DRC as the former GRC NF-e (source: SAP Community, 11/02/2026). The technical help pages, however, treat GRC NF-e, the outbound and inbound options and cloud edition as separate products, with migration between them.

What outbound DRC covers

The features below come from SAP's Feature Scope Description for outbound DRC, version 1.0 of 17/03/2025 (Feature Scope), and from the service's help page (SAP help).

Points the project confirms with SAP

• NFC-e: the project confirms with SAP whether it is covered, without assuming.
• NFS-e for municipalities beyond Rio de Janeiro and São Paulo depends on the service extension or on Partner Enablement.
• CBS and IBS are not cited in the Feature Scope, version 1.0 of 17/03/2025.
• Receiving XML, which is foreseen in the outbound scope through Inbound Simple, does not include automation, according to SAP.

Absence from the list does not prove absence from the product. What matters for the project is to turn each line into a test case (parity section) and each limit into a written question to SAP.

Inbound DRC and what changes in receiving

The inbound option handles what suppliers and carriers issued against the client's CNPJ (company tax ID). According to SAP, it queries NF-e and CT-e status at SEFAZ, sends recipient events through the eDocument Cockpit (confirmation, closing and denial of the operation) and downloads NF-e and CT-e from SEFAZ (SAP help).

What changes in receiving, in the order it appears in the project

Recipient events, deadlines and the tax reading of inbound are in automatic inbound NF-e, CT-e and events.

What must be in order before you start

SAP documents the technical path in Initial Setup pages, and the implementation tips from the post's author list the points that delay projects: account, license and certificates. The list below joins both, with the source on each item.

• Service license purchased. SAP says the license must be bought before the integration credentials can be generated (tips).
• A person with access to the SAP BTP global account. If whoever managed it left the company, SAP advises opening a ticket on component BC-NEO-CIS to get new access.
• Contract check: depending on how it was set up, a second global account may exist. If that was not intended, SAP's sales team fixes it.
• Subaccount, Cloud Foundry, space, entitlement for the service, instance and service key, in the order of the Initial Setup in the help (migration to cloud edition).
• Prerequisite SAP Notes for inbound DRC, all listed in SAP Note 2776753, according to SAP.
• New root certificates for TLS communication (DigiCert TLS RSA4096 Root G5 and DigiCert Global Root G3), valid since 13/01/2026, without removing the old one before the end of the transition (inbound what's new).
• The client's digital certificates to sign and to communicate with the authorities. In DRC cloud edition, one subaccount for test and another for production.
• Adobe Forms to generate the PDFs of the documents. SAP requires it for inbound and recommends it for outbound (post of 31/10/2022).

Who runs each item is a project arrangement between Basis, integrator and tax team. Installation and technical configuration on BTP normally stay with the integrator, and the tax layer is where DFSpro works.

What each GRC customizing became in DRC

In the help of both services, SAP publishes a table with the DRC configuration steps and, next to it, the equivalent in the GRC NF-e SPRO, for comparison. It is not a migration tool: it is the guide for the team to check what each customizing became. Below, the lines that weigh most, in a free translation (outbound and inbound).

Outbound

Inbound

The lines marked "not relevant" are the ones that mislead most, because they disappear from the SPRO without warning and take with them a decision that someone used to make on that screen. Each one must be assessed by the tax team and recorded as accepted.

ECC, S/4HANA and Cloud: what changes in each environment

The environment decides the first question of the project. SAP describes the path from GRC NF-e to the outbound and inbound options, and from those options to cloud edition, in two steps. On each card, the source comes at the end.

The ERP conversion has its own page, at ECC to S/4HANA migration, and the rollout design by company and plant is in tax rollout. When the goal is to keep the core clean, the tax Clean Core page shows where the tax document enters that decision.

Which document goes where, and what goes into the test

Document by document, the table crosses what SAP lists with what the project must prove. The sources are the Feature Scope and the what's new list of the outbound service (SAP Help, What's new).

Events of NF-e, CT-e and MDF-e have their own rules and deadlines, which have their own pages. In the migration project, the practical rule is one: each event that GRC handles today becomes a test case, and what DRC does not list becomes a written question, before the cutover.

Six phases, with evidence in each one

This is DFSpro's method (guidance, not a statement about the product), built from what SAP documents for the migration. The contract, the environment and the integrator may call for variations. What does not vary is the rule: each phase ends with evidence that someone on the client side can open.

Inventory: what goes through GRC today

The inventory comes first because, according to SAP, there is no official migration tool and the partner must examine the current implementation to estimate the effort (comment of 29/09/2023). Without it, the project finds out at cutover what was left out.

• Document types issued and received: NF-e, NFC-e, CT-e, MDF-e, NFS-e and NF3-e.
• Issuing scenarios by company and establishment: sale, return, transfer, service and freight.
• Events in use: cancellation, correction letter, voiding, contingency and recipient events.
• Automated inbound scenarios. SAP keeps KBA 2374911, with the list of GRC scenarios, which serves as a guide.
• FLEX processes and custom BAdIs of GRC, with the owner of each one.
• Digital certificates: which ones, whose, validity and where they are kept.
• Interfaces around GRC: PI, vendor XML email, logistics, TM, WM and LES.
• Monthly volume by document type and by CNPJ.
• XML repository: where the files are, for how long and who queries them.
• Owners: tax, IT, Basis and whoever manages the SAP BTP global account.
• Reports and queries that operations use in GRC.
• Contingency and reprocessing routines the team already has.

The SAP Tax Diagnostic helps list what depends on GRC and what needs action: see the tax diagnosticpage. Source of the inbound scenario list: KBA 2374911, updated on 19/02/2025.

Parity tests: the same invoice, two systems

A parity test is running the same case in both systems and comparing the result: the XML, the returned status, the posting and the bookkeeping. It is a DFSpro project concept, not an SAP product concept, and the matrix below is guidance for building yours.

Approval criterion: zero difference in the tax fields of the XML, or a difference explained and approved by the client's tax lead, because the decision is theirs. The test environment (SEFAZ test) is defined in the business place configuration, as SAP describes in the equivalence table. Bookkeeping is covered in SPED Fiscal in SAP.

Cutover: the day communication changes owner

At cutover, the communication with SEFAZ changes owner. On inbound, SAP warns that a query out of sequence, or two applications querying the same CNPJ, can cause a rejection for misuse (implementation tips). That is why the NSU is the central point of the sequence, which is DFSpro guidance.

Hypercare: what to watch after the cutover

Hypercare is the period right after cutover, when the team follows the new environment closely. The places below come from SAP's sources (implementation tips and outbound what's new). The frequency and the length of the follow-up are a project decision.

Exit criterion, as DFSpro guidance: no open item, rejections with no system cause, NSU up to date and acceptance by the tax lead. After the exit, stabilization becomes routine, the topic of the page on AMS Fiscal and post-go-live stabilization.

Risks that appear and decisions that belong to the client

Each risk below comes with the sign that reveals it and with who decides.

Decisions that belong to the client

• Migrate to DRC or take another path for the document, and when.
• The target environment: outbound and inbound DRC, or cloud edition.
• Who takes each layer and which system is the source of the tax amount.
• Whether each difference found in parity is accepted or corrected.
• The cutover criterion and the rollback criterion.
• The tax thesis behind any setup.

DRC and GUEPARDO Tax solve different layers

The question that separates the layers is simple: was the invoice rejected for format or communication, or accepted with the wrong tax amount? In the first case, the investigation starts at the document. In the second, at the calculation and the tax assessment.

They are not mutually exclusive: they coexist in the same environment, and the decision is by environment and belongs to the client.

The reform and the cutover date

The tax reform changes the invoice, so it enters the cutover date. What SAP wrote is short.

Before fixing the cutover date

• Confirm with SAP, in writing, what the contracted DRC version documents for the new field groups of the NF-e.
• Check the Technical Note in force and the mandatory date at the SEFAZ of each issuer's state. The tax lead decides.
• Run the parity with the new documents too, not only with today's.
• Record which system is the source of the CBS and IBS amount on the invoice.

The tax reading of the reform is in tax reform with CBS and IBS, and the new inbound events are in automatic inbound NF-e and CT-e.

Who does what: DFSpro and the client

In the project, DFSpro handles the tax layer and sells the service, without taking the integrator's place. The exact split is closed case by case in the scope.

Official sources with link

The SAP facts come from these sources. SAP and NTT DATA documents and pages may change: check the current version before you decide.

Start with what depends on GRC today

The first step is the inventory of the documents and scenarios that go through GRC NF-e, together with the tax layer that feeds them.