O SAP já tem DRC nativo. O cálculo do imposto continua sendo problema seu.

Antes de aprovar um projeto de S/4HANA, um Diretor Fiscal ou um CIO enterprise costuma fazer a mesma pergunta: se o SAP já entrega DRC e ACR nativamente, a operação ainda precisa de uma solução fiscal terceira, como o Guepardo Tax? A resposta não é "sim" nem "não": é uma questão de escopo. O SAP Document and Reporting Compliance (DRC) entrega, de forma nativa, o framework de geração e transmissão de documentos fiscais e relatórios estatutários. O que ele não substitui é a camada de determinação e cálculo de imposto específica de cada operação, que segue sendo função de um motor fiscal integrado ao SAP, no ecossistema desta consultoria, o Guepardo Tax, detido pela NTT DATA.

O que é DRC e o que é ACR, segundo a documentação e os canais oficiais da SAP

SAP Document and Reporting Compliance (DRC) é a solução da SAP para trocar documentos eletrônicos entre sistemas de negócio e partes externas de comunicação e para submeter relatórios estatutários, cumprindo a exigência legal de cada país. Fonte oficial, texto literal confirmado no SAP Help Portal, lido em 2026-08-29: "Meet compliance requirements by exchanging documents and reports between business systems and external communication parties. The cloud edition enables you to exchange electronic documents between business systems and external communication parties and submit reports" (help.sap.com/docs/cloud-edition/sap-document-and-reporting-compliance-cloud-edition). A mesma fonte, e a página "End-to-End Processing with SAP Document and Reporting Compliance" (S/4HANA Cloud, lida em 2026-08-29), confirmam que o produto cobre tanto o eDocument (documento eletrônico transacional, como a nota fiscal) quanto o Statutory Reporting (relatório periódico agregado), com o SAP Integration Suite tratando a comunicação com o sistema externo (portal do governo, autoridade fiscal).

A caracterização de uma arquitetura de "dois frameworks", com o SAP Application Interface Framework (AIF) mapeando o dado transacional para o formato exigido, aparece em material de consultoria terceira, não nas páginas oficiais da SAP (verificado em 29/08/2026). Antes de tratar o AIF como capacidade nativa garantida, a referência é a nota de release da versão em uso, que varia entre releases do S/4HANA.

Advanced Compliance Reporting (ACR) era o nome do produto anterior da SAP para relatório estatutário centralizado, focado em gerar um número relativamente menor de documentos legais consolidados. Confirmado em texto literal, lido em 2026-08-29, em dois posts oficiais da SAP (SAP Blogs/SAP Community): já em agosto de 2021 a SAP publicava conteúdo sob o título "SAP Document Reporting and Compliance (Formerly 'ACR') in Central Finance", e em março de 2022 um post oficial da SAP já usava a nomenclatura padrão "Document and reporting compliance - statutory reporting (formerly Advanced compliance reporting - ACR)". Na prática, isso significa que "ACR" hoje é, em grande parte, terminologia legada: quem pergunta "o SAP tem ACR?" está, no S/4HANA atual, perguntando pela capacidade de Relatório Estatutário dentro do DRC.

A documentação pública da SAP não registra a data exata em que a absorção do ACR pelo DRC ocorreu formalmente (verificado em 29/08/2026). Isso tem efeito prático: contrato, proposta técnica e escopo de projeto que citem "ACR" como produto vigente ficam sem lastro documental, e a referência defensável passa a ser a SAP Note da versão em uso.

O que isso cobre no Brasil, segundo o que está documentado

Para o Brasil, a parte de eDocument/faturamento eletrônico do DRC cobre nativamente a emissão e transmissão da Nota Fiscal Eletrônica (NF-e). A opção outbound do DRC para Brasil aparece documentada no Help Portal como parte do escopo padrão do produto. A parte de Relatório Estatutário, confirmado em texto literal do SAP Help Portal (página "ECD Report", S/4HANA On-Premise, lida em 2026-08-29), cobre os relatórios EFD ICMS/IPI, ECD, ECF, EFD-Contribuições e EFD-Reinf como parte do escopo padrão do DRC para o Brasil.

O DRC resolve a camada de transporte e formato do relatório fiscal. A camada de cálculo e determinação de imposto por operação (benefício fiscal estadual, exceção setorial, regra de determinação por combinação de produto/operação/UF) é papel de um motor fiscal integrado ao SAP, o Guepardo Tax, no caso desta consultoria.

A SAP não publica nota oficial sobre o grau de completude dessa cobertura para o cenário fiscal específico de cada operação, e fontes de consultoria terceira divergem entre si (verificado em 29/08/2026). A consequência para quem decide arquitetura é direta: a completude não pode ser assumida por reputação do produto, precisa ser testada obrigação por obrigação no cenário real. A separação de papéis descrita acima é leitura da DFSpro, formada em operações que acompanhamos, não fato documentado pela SAP.

Por que essa distinção é fácil de perder de vista

A causa raiz de a pergunta "eu preciso mesmo de uma solução terceira?" continuar aparecendo em avaliações de arquitetura não é falta de informação pública, a SAP documenta o escopo do DRC. A causa raiz é que DRC/ACR e um motor de determinação fiscal como o Guepardo Tax resolvem camadas diferentes do mesmo problema, e o material de marketing de plataforma tende a apresentar as duas camadas como se fossem a mesma coisa: "o SAP já faz compliance fiscal". Faz, para a camada de transporte e formato do relatório. A camada de cálculo, de regra de negócio por operação e de regra fiscal específica de cada estado ou setor, é uma decisão de arquitetura à parte, e é aqui que o cliente decide a tese fiscal que a operação vai adotar, decisão que segue sendo do cliente, nunca da consultoria ou do software.

O que costuma acontecer quando essa fronteira não é diagnosticada antes da migração

Quando uma empresa assume, sem diagnóstico prévio, que "o S/4HANA com DRC resolve compliance fiscal", o padrão comum não é uma falha técnica visível na migração: é uma lacuna que só aparece no primeiro fechamento real ou na primeira fiscalização, quando um relatório gerado pelo standard não reflete a regra fiscal completa daquela operação, porque a parametrização daquele cenário específico nunca foi feita. A abordagem padrão do mercado, nesses casos, é tratar isso como um problema de "configuração pendente" a ser resolvido depois do go-live, o resultado é retrabalho sob pressão, no pior momento possível para corrigir. A raiz continua sem solução porque o problema nunca foi um bug do DRC: foi a ausência de um diagnóstico que separasse, antes da migração, o que o standard cobre do que precisa de parametrização e integração com o motor fiscal.

Framework de autodiagnóstico: 5 perguntas antes de decidir a arquitetura

1. Qual parte do meu compliance fiscal depende de transporte/formato de relatório, e qual depende de cálculo/determinação de imposto? DRC resolve a primeira. A segunda depende do motor fiscal integrado ao ambiente.
2. Para cada obrigação SPED da minha operação, a cobertura nativa documentada é completa ou parcial para o meu cenário? Isso exige checar a documentação de escopo (Feature Scope Description) da versão específica em uso, não uma afirmação genérica de que "o SAP já faz SPED".
3. Minhas regras fiscais têm exceção estadual, setorial ou de benefício fiscal que o núcleo padrão da SAP não contempla? Se sim, essa regra precisa viver em algum lugar governado: motor fiscal integrado, camada de extensão, ou customização revisada por triagem.
4. Existe hoje um inventário de qual regra fiscal está no DRC/ACR nativo, qual está no motor fiscal (Guepardo Tax) e qual ainda está em controle paralelo (planilha, e-mail)? Sem esse inventário, a decisão de arquitetura é feita às cegas.
5. O plano de teste de migração valida só execução técnica (processou sem erro) ou também o resultado fiscal (o valor calculado está correto para a legislação vigente)?

Como isso se resolve, sem ser uma decisão pré-tomada

O caminho estruturado começa por um Diagnóstico Fiscal Estruturado que mapeia, cenário por cenário, o que a operação real precisa e onde cada necessidade é atendida: transporte e formato de relatório (DRC/ACR), cálculo e determinação (motor fiscal), ou parametrização/extensão específica. A partir desse mapa, a decisão sobre manter, ampliar ou reconfigurar a arquitetura fiscal é do cliente. A consultoria técnica desenha, configura e prova o comportamento de cada camada, mas não decide a tese fiscal nem substitui o julgamento do Diretor Fiscal ou do CFO sobre risco aceitável. Depois de um projeto de estabilização, a manutenção contínua dessa arquitetura, incluindo o acompanhamento de mudanças de legislação que afetam parametrização, é o escopo do AMS Fiscal Consultivo.

Perguntas frequentes

O DRC substitui o Guepardo Tax?

Não. Documentação oficial descreve o DRC como framework de geração/transmissão de documentos e relatórios fiscais. Determinação e cálculo de imposto por operação é função de um motor fiscal integrado ao SAP, papel que o Guepardo Tax, detido pela NTT DATA, cumpre no ecossistema desta consultoria. São camadas complementares, não concorrentes.

"ACR" ainda existe como produto separado no S/4HANA atual?

Confirmado em texto literal de posts oficiais da SAP (SAP Blogs/SAP Community, lidos em 2026-08-29): a SAP já tratava "ACR" como nome anterior do DRC em posts de 2021 e 2022. Hoje, "ACR" é majoritariamente terminologia legada para a capacidade de Relatório Estatutário do DRC. Não conferido: a data exata da renomeação/absorção formal, e se existe algum cenário de release específico em que o nome ainda aparece separadamente; vale checar a SAP Note da versão em uso.

Se a SAP já cobre SPED nativamente, por que ainda existe retrabalho fiscal em empresas SAP?

Porque a cobertura nativa dos relatórios principais, mesmo confirmada, não elimina a necessidade de parametrização para o cenário fiscal específico da operação (exceção estadual, benefício fiscal, regra setorial). Essa é uma observação da DFSpro a partir dos diagnósticos realizados, não uma afirmação documentada pela SAP sobre o grau de completude do produto.

Isso significa que a DFSpro recomenda substituir DRC/ACR por outra coisa?

Não. Nenhuma das duas camadas substitui a outra: o DRC responde por transporte e formato, o motor fiscal responde por determinação e cálculo. A decisão sobre qual arquitetura fiscal adotar é sempre do cliente; o papel desta consultoria é desenhar, configurar e provar o comportamento real de cada camada dentro do ambiente do cliente. O mapeamento cenário por cenário, o que o standard cobre, o que depende do motor fiscal, o que precisa de parametrização, é exatamente o que o Diagnóstico Fiscal Estruturado entrega antes de qualquer decisão de arquitetura.