A mesma nota pode atravessar ERP, localização, motor fiscal conectado e SAP DRC. Só olhar o último sistema da fila não responde onde o resultado tributário nasceu. A documentação SAP distribui funções: há páginas de determinação e cálculo no ERP e páginas de processos documentais no DRC. E a Resolução CGIBS nº 6/2026, art. 132, I, avisa que a autorização “não implica validação das informações”. A arquitetura fiscal precisa, portanto, seguir a regra da entrada ao cálculo, do cálculo ao documento e do retorno à contabilização — com um responsável e uma evidência em cada fronteira.
DRC, ERP e motor conectado podem participar do mesmo fluxo, mas só o desenho e a demonstração do ambiente concreto dizem quem decide, calcula, transmite e comprova cada etapa.
Onde nasce o resultado que aparece na nota
- Fato: o que ocorreu, entre quais partes, em qual processo e com quais condições?
- Regra: qual premissa aprovada representa esse fato e qual é sua versão?
- Cálculo: qual componente recebeu entradas e produziu o resultado?
- Documento: como o resultado foi mapeado para a saída fiscal?
- Transmissão e retorno: qual serviço enviou, recebeu e atualizou o status?
- Contabilização e reporte: o que foi registrado e como se compara ao esperado?
Fonte visual: mapa editorial TaxUp, com base nas fontes oficiais SAP S04 e S09–S12 registradas no corpus em 14/09/2026.
O documento é uma fotografia tardia do processo. Antes dele, alguém descreveu o fato, classificou a operação, aprovou uma premissa, alimentou uma regra e executou um cálculo. Depois dele, o retorno precisa chegar ao fluxo e o resultado precisa reconciliar com a contabilização. Uma caixa de arquitetura isolada não mostra essas passagens.
A SAP documenta no TAXBRA uma entrega de compras com “automatic calculation and mapping” de CBS e IBS em versões delimitadas. Em outra frente, o catálogo DRC documenta processos eletrônicos brasileiros. Esses documentos mostram que “cálculo” e “processo documental” não são sinônimos, mas não resolvem a arquitetura de uma empresa que o pesquisador não examinou.
Antes de escolher componente, recomendo desenhar o resultado fiscal sem marcas: entrada, decisão, saída, falha e evidência. Depois se associa cada função ao produto, à versão e ao contrato concretos. O roteiro executivo de SAP e Reforma Tributária ajuda a colocar essa definição dentro do programa maior sem misturar prazo jurídico, lifecycle e cronograma interno.
O que a documentação SAP coloca em cada camada
| Camada | Exemplo documentado | O que se pode afirmar | O que permanece a confirmar |
|---|---|---|---|
| ERP e localização | TAXBRA, tax groups/types, tax situations, condition records e objetos por release. | Há capacidades de determinação, cálculo e mapeamento nos escopos publicados. | Baseline, procedure usada, customizações, regras e operações cobertas pela empresa. |
| SAP DRC | Processos de documentos e relatórios eletrônicos listados por país e sistema de origem. | Há processos brasileiros documentados, inclusive integração inbound NF-e com SAP ERP. | Paridade entre versões, documentos, cenários e toda função contratada no landscape. |
| Sistema conectado | Função definida no desenho e no contrato concretos. | Somente o que o fornecedor demonstrar com entrada, regra, versão, saída e log. | Capacidade, cobertura e comportamento na falha; não há produto externo pesquisado nesta página. |
| Governança humana | Aprovação da premissa, confirmação dos fatos, tratamento de exceção e aceite. | Decisões precisam de responsável funcional identificável. | Quem decide no processo real e como a evidência será conservada. |
A página S04 de tarefas suportadas registra “Inbound Electronic Nota Fiscal (NF-e) | SAP ERP”. O trecho comprova um processo documentado na matriz do DRC Cloud Edition. Não comprova todos os documentos, todas as releases, paridade com S/4HANA ou que o DRC assuma toda a determinação tributária.
É nessa fronteira que a discussão sobre GRC NFe, DRC e a transição da camada documental se aprofunda. A página de migração decide cobertura, coexistência e ponto de troca. Este artigo responde outra pergunta: depois da transição, onde ficam permanentemente regra, cálculo, documento, retorno e reconciliação?
A coluna “a confirmar” é obrigatória. Uma página de produto revela capacidades publicadas; não revela os add-ons, customizações, motores, contratos e interfaces do leitor. Declarar uma fronteira sem examinar esses elementos transformaria uma arquitetura ilustrativa em falso diagnóstico.
Cálculo automático depende de qual regra
Vendas:
- Categoria do item e informações configuradas alimentam a relação.
- A situação tributária é determinada a partir da estrutura documentada em J_1BSDICA.
- Condições, reduções e texto legal participam da saída conforme configuração e versão.
Compras:
- Tax code, dados da operação e informação recebida entram no processo.
- J_1BTAXCODEV contém coluna documentada para situação tributária CBS e IBS.
- O resultado precisa reconciliar com a nota de entrada e a contabilização.
Fonte visual: síntese TaxUp das páginas oficiais SAP S09, S10, S11 e S12 registradas no corpus em 14/09/2026.
No SAP ERP, a página TAXBRA descreve “automatic calculation and mapping … CBS and IBS” para compras em EHPs e support packages especificados. O trecho demonstra uma entrega publicada; não significa que todo cliente use a procedure, que toda operação esteja coberta ou que uma baseline fora da lista seja elegível.
No S/4HANA, a localização documenta “tax types to represent CBS, IBS and IS taxes”. Representar um tipo no sistema é uma capacidade técnica. Decidir quando ele se aplica à operação é uma análise diferente.
A página de vendas informa que o sistema “automatically determines the tax situation … from … J_1BSDICA”. Em compras, o Help registra “J_1BTAXCODEV agora inclui a coluna Situação tributária CBS e IBS”. As relações são diferentes; por isso compras e vendas devem ser demonstradas separadamente, sem transformar nomes de tabela em tutorial de enquadramento.
Quando a divergência nasce antes do cálculo, o guia de dados mestres SAP na Reforma Tributária ajuda a separar cadastro, dado transacional, customizing e extensão e a seguir cada informação até o seu efeito.
Como um motor conectado entra no desenho
| Pergunta | Demonstração esperada | Responsável a nomear | Comportamento na falha |
|---|---|---|---|
| Que dado recebe? | Payload, origem, obrigatoriedade, vigência, validação e identificador da operação. | Dono do processo e responsável pela interface. | Rejeitar, enfileirar ou sinalizar sem substituir silenciosamente a entrada. |
| Que decisão executa? | Regra, versão, prioridade, exceção e premissa tributária aprovada. | Tax e owner funcional do motor. | Registrar regra não localizada ou conflito, sem inventar tratamento padrão. |
| Que resultado devolve? | Campos, cálculo, mensagens, versão e vínculo com a entrada original. | Fornecedor do motor e integração. | Preservar retorno, erro, repetição e efeito no processo seguinte. |
| Como se prova? | Log, cenário, resultado esperado, resultado observado e reconciliação ponta a ponta. | Tax, testes, Financeiro e equipe técnica. | Escalar divergência sem declarar conformidade pela simples resposta “sucesso”. |
“Motor fiscal” descreve uma função ampla demais para fechar arquitetura. Um produto pode determinar regra, calcular, enriquecer dados, devolver campos ou combinar parte dessas funções. A página não pesquisou produto externo algum; logo, cada capacidade permanece “a confirmar” até demonstração no desenho e na versão contratados.
O risco de duplicação aparece quando duas camadas acreditam governar a mesma decisão. Uma aplica versão nova, a outra conserva a anterior; uma recalcula, a outra apenas mapeia; uma devolve mensagem, a outra transforma o retorno. A matriz obriga o projeto a registrar precedência, versão e comportamento na falha antes do teste integrado.
Também separa responsabilidade técnica de responsabilidade pelo fato e pela premissa. O fornecedor demonstra o que seu componente executa. O integrador mostra a passagem entre sistemas. Tax aprova o resultado esperado. O contribuinte conserva a decisão e o aceite. O contrato concreto pode distribuir atividades; a tabela não declara responsabilidade civil de ninguém.
Um documento autorizado pode esconder uma divergência de origem
Trilha esperada: fato confirmado → classificação aprovada → regra versionada → resultado esperado → documento e contabilização reconciliados.
Trilha observada: fato confirmado → classificação diferente → regra aplicada → resultado observado → documento autorizado → diferença ainda aberta.
Pergunta de saída: a divergência nasceu no fato, no dado, na versão da regra, no cálculo ou no mapeamento?
Fonte visual: exemplo hipotético TaxUp à luz do art. 132, I, da Resolução CGIBS 6/2026.
O art. 132, I, da Resolução CGIBS nº 6/2026 diz que a autorização “não implica validação das informações”. A formulação não nega controles técnicos e não permite afirmar que qualquer erro será autorizado. Ela impede usar o protocolo, isoladamente, como certificado material do que foi informado.
No exemplo, as duas trilhas chegam à emissão por hipótese. A investigação não começa culpando uma ferramenta. Primeiro conserva as entradas e versões; depois compara premissa aprovada, regra executada, resultado, campos, retorno e contabilização. Só então a equipe localiza a primeira diferença verificável.
Esse método também evita a frase absoluta “o SAP não decide imposto”. A documentação mostra automações reais em escopos concretos. O ponto é outro: automação não elimina a necessidade de configurar, versionar, demonstrar e aprovar a relação que ela executa.
O que precisa atravessar as fronteiras dos sistemas
- Identificador
- Vínculo estável entre operação, mensagens, documento, retorno e lançamento.
- Versão da premissa
- Decisão tributária aprovada e data a partir da qual vale.
- Entrada
- Dados efetivamente recebidos, fonte e transformações realizadas.
- Regra executada
- Objeto, versão, prioridade e exceção que produziram o resultado.
- Resultado
- Cálculo e campos devolvidos ao próximo componente.
- Documento e retorno
- Conteúdo transmitido, protocolo, mensagem e estado atualizado.
- Contabilização
- Lançamento e reporte reconciliados com o resultado esperado.
Fonte visual: modelo editorial TaxUp de rastreabilidade entre sistemas.
O passaporte não precisa ser um arquivo único. Pode estar distribuído entre logs, IDs, transportes, memórias de decisão e evidências de teste. O requisito é conseguir recompor a cadeia sem depender da lembrança de quem participou do projeto.
O ponto mais frágil costuma ser a transformação invisível: arredondamento, default, enriquecimento, substituição ou perda de versão. Por isso, a evidência deve registrar a entrada e a saída de cada componente, não apenas o início e o fim do processo.
Esse desenho é recomendação de governança da TaxUp, apoiada nas relações documentadas pelas fontes. Não é campo obrigatório imposto pela Resolução nem especificação universal da SAP. A forma de implementar depende da arquitetura, dos contratos e das capacidades do ambiente real.
Perguntas antes de fechar a arquitetura fiscal
| Pergunta | Demonstração | Evidência | Decisão disponível |
|---|---|---|---|
| Quem determina e calcula? | Cenário controlado com entradas, regra versionada e resultado esperado. | Log, configuração, retorno e reconciliação. | Aprovar função, precedência e exceções. |
| Quem gera e transmite? | Processo suportado, mapeamento, autenticação, envio e atualização de status. | Documento, protocolo, fila e erro reproduzível. | Aprovar fronteira documental e tratamento da falha. |
| Quem atualiza a regra? | Fluxo de mudança, versão, transporte e comunicação entre componentes. | Registro de decisão, release e impacto avaliado. | Aprovar governança e fonte de verdade. |
| Quem reconcilia e aceita? | Comparação de premissa, cálculo, documento, retorno e contabilização. | Diferenças classificadas e aceite pelo responsável. | Liberar, corrigir ou aceitar condição residual explícita. |
Uma arquitetura pode ter poucas caixas e muitas responsabilidades escondidas. O quadro final força as decisões para a superfície: qual componente executa, qual equipe demonstra, qual área aprova e que evidência será recuperável depois do go-live.
DRC é a mesma coisa que motor fiscal?
Não por definição. A documentação pública do DRC descreve processos de documentos e relatórios eletrônicos. Um motor conectado pode executar funções de determinação ou cálculo conforme produto e contrato. O desenho concreto deve comprovar entradas, regras, saídas e comportamento na falha.
O ERP pode calcular CBS/IBS?
Há entregas SAP documentadas para escopos específicos, como o cálculo e mapeamento no TAXBRA para níveis publicados do SAP ERP. Isso não qualifica toda baseline, procedure, operação ou customização; aplicabilidade e resultado precisam ser confirmados no ambiente real.
Quando considerar um motor conectado?
Quando requisitos, alcance, velocidade de mudança, regras ou arquitetura justificarem avaliar uma função fora do ERP. A decisão só é comparável se o motor demonstrar o que recebe, decide, devolve, registra e faz quando não consegue processar.
Duas ferramentas podem aplicar versões diferentes de uma regra?
Sim, se a governança permitir fontes, datas ou transportes divergentes. A prevenção é registrar uma premissa aprovada, sua vigência, a versão executada em cada componente e a precedência quando duas camadas puderem transformar o mesmo resultado.
Quem deve comprovar o resultado em cada interface?
O responsável técnico demonstra a entrada, a transformação e a saída sob seu controle. Tax confirma o resultado esperado; o negócio confirma os fatos; Financeiro participa da contabilização; e o responsável pelo aceite decide sobre a divergência e o risco residual.
O status da SEFAZ substitui a comparação com o resultado esperado?
Não. O status integra a evidência do fluxo documental, mas o art. 132, I, impede tratá-lo isoladamente como validação material das informações. A comparação ainda precisa alcançar premissa, cálculo, campos transmitidos, retorno e contabilização.
Discutir um caso concreto da sua empresa
30 minutos com consultor sênior. Mapeamos o cenário tributário específico, identificamos as oportunidades aplicáveis e indicamos o caminho técnico — independentemente de você seguir conosco.
Agendar diagnóstico gratuito 30 minutos com consultor sênior. Sem compromisso.