A NF-e passa no leiaute desde agosto, e isso não prova que o cálculo de CBS e IBS está certo

Desde 3 de agosto de 2026, toda NF-e de bens materiais carrega os grupos de CBS e IBS, e o XML passar pela validação do leiaute não prova que o valor calculado dentro dele está certo. O documento pode sair autorizado, limpo, sem rejeição nenhuma do ambiente nacional, e ainda assim carregar um valor de tributo que não é o que a apuração da empresa vai, de fato, considerar depois.

Leiaute valida formato.

Formato não é cálculo.

O que ficou obrigatório em 3 de agosto

O Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, fixou no inciso I do cronograma: "Nota Fiscal Eletrônica (NF-e), modelo 55: 3 de agosto de 2026". A Receita Federal, em comunicado de 31 de julho de 2026, descreveu o mesmo documento como aplicável ao "Fornecimento de bens materiais e outros fornecimentos específicos", com a mesma data de início.

Dois atos oficiais, com um dia de diferença entre eles, fixando a mesma obrigatoriedade para o mesmo documento. Não há margem de dúvida sobre quando a exigência começou.

O que esses dois atos determinam é a obrigatoriedade do formato: a partir daquela data, a NF-e de bens materiais precisa carregar os grupos de informação de CBS e IBS no XML, estruturados conforme o leiaute nacional definido para a transição. O documento que não tiver esses grupos preenchidos corretamente, na estrutura esperada, é rejeitado pelo ambiente de autorização.

Essa é uma barreira de qualidade real, mas é uma barreira de estrutura, não de conteúdo tributário. O ambiente nacional confere se o campo existe, se está no lugar certo, se o tipo de dado é o esperado. Não confere se o valor lançado naquele campo corresponde à regra tributária correta para aquela operação específica.

Essa barreira estrutural também não é nova em sua natureza, apenas em seu conteúdo. O ambiente nacional de autorização de NF-e sempre operou dessa forma, desde a implantação original do documento eletrônico: verifica assinatura, verifica schema, verifica se os campos obrigatórios chegaram preenchidos, e autoriza. A inclusão dos grupos de CBS e IBS apenas estendeu essa mesma lógica de verificação para dois tributos novos, sem alterar a natureza do que está, de fato, sendo checado.

Vale registrar também que essa obrigatoriedade de 3 de agosto não veio isolada. Ela faz parte do mesmo cronograma de documentos fiscais eletrônicos que, em datas sequenciais, trouxe também o CT-e e outros documentos para o mesmo regime de CBS e IBS. A NF-e foi o primeiro grande documento de alto volume a entrar nessa obrigatoriedade, o que explica por que o impacto operacional dela tende a ser sentido primeiro e com mais intensidade do que o de documentos que entraram depois.

O que o leiaute valida e o que não valida

O leiaute da NF-e, desde sempre, cumpriu essa função de verificação estrutural. Confere assinatura digital, confere schema XML, confere se os campos obrigatórios estão presentes, confere consistência básica entre alguns campos relacionados. Isso já acontecia antes da Reforma Tributária, com ICMS e PIS/Cofins, e continua acontecendo agora, com os novos grupos de CBS e IBS incorporados à mesma lógica de validação.

O que o leiaute nunca validou, nem antes nem agora, é se o percentual aplicado, a base de cálculo considerada e o enquadramento tributário escolhido para aquela operação específica estão corretos diante da legislação vigente. Essa validação de conteúdo tributário é uma camada completamente diferente, interna ao sistema que emite o documento, não ao ambiente que o recebe e autoriza.

Essa distinção sempre existiu, mas ganhou peso diferente com CBS e IBS, porque a complexidade de determinação do tributo nesse novo regime é maior do que era com o regime anterior em transição. Mais variáveis de enquadramento, mais cenários de operação, mais hipóteses de redução ou diferimento. Quanto mais complexa a determinação, maior a chance de um erro de cálculo passar despercebido justamente porque o documento onde ele está embutido é, tecnicamente, válido.

Essa é a armadilha específica desse momento: a obrigatoriedade de agosto deu visibilidade e urgência ao formato, e essa urgência pode, sem querer, deslocar a atenção do time fiscal para "o documento está saindo" em vez de "o valor dentro do documento está certo".

Essa armadilha tem um componente adicional, menos óbvio: o próprio sucesso técnico da implantação do leiaute pode gerar falsa sensação de segurança. Quando o volume de notas emitidas sem rejeição cresce, é tentador interpretar essa ausência de erro técnico como sinônimo de ausência de erro tributário, quando na verdade são duas coisas completamente diferentes, medidas por processos de verificação que não se comunicam entre si.

Onde o SAP decide o valor

No SAP, a determinação do valor de tributo que vai para a NF-e acontece antes da geração do documento fiscal propriamente dito, numa camada de configuração fiscal que combina classificação do material ou serviço, código de operação, características do estabelecimento emissor e do destinatário, e as regras vigentes de CBS e IBS aplicáveis a cada combinação dessas variáveis.

Essa camada de determinação é onde o cálculo efetivamente acontece. O documento fiscal, gerado depois, apenas reflete o resultado dessa determinação no formato exigido pelo leiaute. Se a determinação estiver parametrizada de forma incorreta para um cenário específico, o documento sai estruturalmente perfeito, carregando um valor tributariamente incorreto.

Em operações com múltiplos estabelecimentos emitindo em vários estados, essa camada de determinação tende a ter volume relevante de combinações possíveis entre tipo de operação, estado de origem, estado de destino e classificação de material. Cada combinação é, potencialmente, uma regra de cálculo distinta, e nem toda combinação recebe o mesmo nível de atenção na hora de validar se a parametrização está correta diante da nova legislação.

Um padrão provável nesse tipo de ambiente multiestadual é que a validação de parametrização, quando feita, tende a se concentrar nos cenários de maior volume, deixando combinações de menor frequência com menor grau de verificação. Isso não é um erro deliberado. É uma consequência natural de como prioridades são definidas sob prazo apertado, e é exatamente onde um cálculo incorreto pode sobreviver sem ser notado por mais tempo, justamente porque aparece com menos frequência.

Esse risco se agrava quando a empresa opera com estabelecimentos de porte e complexidade fiscal diferentes, porque a equipe que valida parametrização costuma concentrar esforço nos estabelecimentos de maior faturamento, deixando unidades menores, muitas vezes com regras de exceção próprias, sob um escrutínio proporcionalmente mais fraco do que o risco real justificaria.

Essa concentração de atenção nos estabelecimentos maiores tem uma lógica de recurso limitado por trás: revisar cada combinação de parametrização em cada estabelecimento consome tempo de um time fiscal que já está sob pressão de prazo. Mas o tamanho do estabelecimento não determina o tamanho do erro potencial numa combinação específica. Uma unidade pequena com uma exceção de enquadramento mal configurada pode gerar, proporcionalmente ao seu próprio volume, o mesmo nível de exposição que um erro maior numa unidade grande.

Prova mínima de coerência nota x apuração

O primeiro elemento de uma prova mínima de coerência é a reconciliação periódica entre o valor de CBS e IBS que sai nas notas fiscais emitidas e o valor que a apuração da empresa, de fato, está considerando para fins de recolhimento. Esses dois números deveriam ser o mesmo número, mas vêm de processos diferentes dentro do sistema, e nada garante automaticamente que permaneçam coerentes ao longo do tempo, especialmente depois de qualquer ajuste de parametrização.

O segundo elemento é testar a determinação do tributo numa amostra representativa de cenários, não apenas nos mais frequentes. Isso significa simular operações específicas para combinações menos comuns de estado, tipo de operação e classificação de material, e verificar se o resultado calculado corresponde à regra vigente para cada uma.

O terceiro elemento é documentar, de forma rastreável, quem validou cada parametrização de CBS e IBS e quando. Isso responde diretamente à pergunta executiva central: quem na empresa assina que o valor que sai na NF-e é o valor que a apuração vai usar? Sem essa assinatura documentada, a resposta, em qualquer auditoria futura, tende a ser "o sistema calculou", o que não é uma resposta de governança, é uma ausência de responsável.

O quarto elemento é revisar essa coerência sempre que houver mudança normativa relevante no regime de CBS e IBS, não apenas na implantação inicial. Uma parametrização validada corretamente em agosto de 2026 pode deixar de refletir a norma vigente meses depois, se uma atualização regulatória mudar algum critério de enquadramento e a parametrização do SAP não acompanhar a mudança no mesmo ritmo.

O quinto elemento é estender essa verificação para os estabelecimentos de menor volume, justamente os que tendem a receber menos atenção na rotina normal. Um teste amostral que cubra proporcionalmente todos os estabelecimentos, e não apenas os de maior faturamento, fecha a lacuna de risco que a priorização natural por volume costuma deixar aberta.

Onde termina a responsabilidade do fiscal e começa a da TI

Vale separar com clareza quem decide a regra tributária de quem mantém o sistema que a executa.

A decisão sobre qual regra de CBS e IBS se aplica a cada tipo de operação, cada estado, cada classificação de material, pertence ao time fiscal e jurídico tributário da empresa. Essa decisão não muda com nenhum ajuste de leiaute nem com nenhuma atualização de versão do SAP.

O papel da área de TI e de quem mantém a parametrização fiscal do sistema é traduzir, com precisão, a regra que o time fiscal definiu, para a camada de determinação que efetivamente calcula o valor antes de gerar o documento. Um erro nessa tradução não é um erro de interpretação tributária. É um erro de configuração que produz resultado tributariamente incorreto, mesmo quando a regra que o time fiscal definiu estava certa.

Separar essas duas responsabilidades evita que uma falha de parametrização seja tratada como se fosse uma dúvida de interpretação da lei, quando na verdade é uma falha de execução de uma decisão que já havia sido tomada corretamente.

O documento passar na validação prova que o formato está certo. Não prova que o número dentro dele está certo.

A versão, a customização e o nível real de parametrização do SAP em qualquer operação específica são informações que só um levantamento interno revela. A decisão sobre qual regra tributária aplicar a cada cenário é sempre do time fiscal e jurídico tributário da empresa.

O que não depende de levantamento nenhum é se existe, hoje, uma prova documentada de que o valor de CBS e IBS na NF-e corresponde ao valor que a apuração realmente usa. Isso é verificação de processo, possível de fazer agora.

Na DFSpro, o primeiro passo é sempre um diagnóstico real: mapear a saída de NF-e e o cálculo de CBS e IBS por estabelecimento, testar a determinação em cenários de menor frequência, e entregar a lista de riscos priorizada. Se a sua empresa ainda não sabe quem assina que o valor da nota é o valor da apuração, talvez seja a próxima pergunta a responder.