IBS e CBS na nota fiscal: o campo virou confissão de dívida, não rascunho

O art. 112, § 2º, do Regulamento do IBS (Resolução CGIBS nº 6/2026) estabelece que as informações prestadas pelo contribuinte em matéria de IBS no documento fiscal "possuem caráter declaratório e constituem confissão do valor devido". Isso não é jargão de regulamento. É a definição legal de que o campo preenchido na nota não é um rascunho técnico. É uma declaração formal de dívida, com o mesmo peso de uma confissão.

A nota emitida não pergunta. Ela afirma.

O que o regulamento diz, com todas as letras

O texto do § 2º do art. 112 é direto: "As informações prestadas pelo sujeito passivo nos termos deste artigo possuem caráter declaratório e constituem confissão do valor devido de IBS consignado no documento fiscal". O próprio regulamento cita, entre parênteses, a base legal: art. 60, § 1º, da Lei Complementar 214/2025. Não é interpretação de mercado. É texto normativo explícito, com remissão à lei que a Reforma instituiu.

O § 3º do mesmo artigo complementa a lógica: para fins de apuração do IBS, o CGIBS e as administrações tributárias usam essas informações como referência de controle. O sistema não confia cegamente no contribuinte por boa vontade.

Ele confia porque a lei trata o valor informado como declaração vinculante, não como estimativa sujeita a revisão amigável depois. Essa escolha de desenho normativo tem uma consequência prática direta: o fisco não precisa provar que o contribuinte errou para cobrar diferença. Basta comparar o que foi declarado contra o que deveria ter sido, porque o próprio documento emitido já tem força de confissão.

Quanto à obrigatoriedade de IBS e CBS constarem na NF-e e na NFC-e desde 3 de agosto de 2026, a referência consultada aponta para o Ato Conjunto RFB/CGIBS nº 4/2026, publicado no Diário Oficial da União em 31 de julho de 2026. O texto específico desse ato não foi reconferido linha a linha nesta rodada de verificação, de forma que a data exata e o alcance preciso da obrigatoriedade merecem checagem direta na fonte oficial antes de qualquer comunicação formal sobre prazo a um cliente.

Validação de schema não é validação de cálculo

Toda nota fiscal eletrônica passa por uma validação de schema no momento da transmissão: o XML precisa ter a estrutura certa, os campos obrigatórios preenchidos, os tipos de dado corretos. Uma nota que passa nessa validação recebe autorização de uso. O schema aceitou o documento.

O que o schema não verifica é se o valor de IBS e CBS informado naquele campo está matematicamente correto para aquela operação específica, considerando alíquota, base de cálculo, regime aplicável e eventuais incentivos. Uma nota pode ser tecnicamente válida, autorizada pela SEFAZ, e ainda assim carregar um valor de IBS errado, porque a validação de schema e a validação de cálculo são duas camadas completamente diferentes. A primeira garante que o documento está bem formado. A segunda, que ninguém verifica automaticamente no momento da emissão, garante que o número ali dentro é o número certo.

Essa distinção importa exatamente porque o § 2º do art. 112 trata o valor como confissão. Uma nota aceita pelo schema, mas com erro de cálculo, não é um erro técnico sem consequência. É uma declaração formal de um valor que pode estar errado, emitida com a mesma força jurídica de uma declaração correta.

Essa diferença entre as duas camadas de validação costuma ser mal compreendida justamente porque, no dia a dia da operação, autorização de uso soa como sinônimo de documento correto. Para qualquer outro tipo de erro de formatação, essa equivalência até funciona na prática: se o XML foi rejeitado, há algo errado; se foi aceito, está formalmente certo. Para o valor de IBS e CBS, essa lógica se rompe, porque a aceitação técnica não carrega nenhuma garantia sobre a correção do número declarado.

Essa lacuna entre as duas camadas de validação não é falha de projeto do sistema nacional de documentos fiscais. É consequência direta de como o cálculo tributário funciona: o schema conhece a estrutura esperada do XML, mas não tem acesso às regras de negócio específicas de cada contribuinte, como o enquadramento tributário do item, eventuais benefícios fiscais aplicáveis ou particularidades do regime de apuração da empresa. Essas informações moram no ERP, não no validador nacional, e é exatamente por isso que a responsabilidade pela correção do número cai inteiramente sobre quem configura o sistema de origem.

Vale reforçar que nenhuma camada de validação nacional, hoje ou no futuro próximo, foi desenhada para substituir essa checagem interna. Mesmo que notas técnicas futuras incluam regras adicionais de consistência no schema, essas regras tendem a continuar genéricas, aplicáveis a qualquer contribuinte do país, e nunca vão capturar a particularidade de uma parametrização fiscal específica de uma rede de lojas com histórico próprio de aberturas e ajustes. Depender de um alerta nacional futuro para descobrir um erro de cálculo próprio é assumir um risco que a própria arquitetura do sistema já deixa claro que não vai ser coberto.

O que muda quando o campo vira confissão

Em regimes tributários onde a declaração do contribuinte tem caráter apenas informativo, um erro identificado depois costuma ser corrigido por retificação, sem necessariamente caracterizar reconhecimento formal de dívida diferente da que foi paga. Quando a própria norma classifica o valor como confissão, a lógica muda: o documento emitido já vale como reconhecimento daquele valor específico, para todos os efeitos.

Isso significa que corrigir um erro de IBS ou CBS identificado meses depois da emissão não é apenas um ajuste técnico de sistema.

É alterar uma declaração que já tinha valor de confissão, o que normalmente exige processo mais formal do que um simples reprocessamento de nota.

Corrigir depois não apaga o que já foi declarado antes.

Para uma rede de lojas que emite documento fiscal todos os dias, em múltiplos endereços, isso multiplica o risco por volume: cada nota emitida com campo de IBS ou CBS incorreto, em qualquer loja, é uma confissão individual daquele valor, não um erro agregado que se resolve numa única correção ao final do mês.

Mil notas erradas não são um erro. São mil confissões.

Essa multiplicação recai, na prática, sobre quem precisa assinar a correção depois: o gerente fiscal que decide se retifica uma nota isolada ou um lote de mil precisa também decidir, em cada caso, que forma de correção formal o volume exige, porque o processo de retificar uma confissão acumulada tende a ser mais pesado do que reemitir um documento comum. Quanto maior o lote de notas com o mesmo erro, maior a complexidade de decidir, caso a caso, qual via de correção é exigida para desfazer uma declaração que já valia como reconhecimento de dívida.

Onde o cálculo nasce no SAP

Em ambiente SAP, o valor de IBS e CBS que acaba impresso e transmitido na NF-e ou na NFC-e normalmente é determinado por uma cadeia de parametrização que envolve o código de tributação do item, as condições fiscais associadas àquela operação e as regras específicas do estabelecimento emissor. Cada elo dessa cadeia é um ponto onde um parâmetro desatualizado ou mal configurado pode gerar um valor tecnicamente aceito pelo schema, mas incorreto na substância.

O padrão que aparece com consistência em operações com múltiplos pontos de emissão é a parametrização fiscal não ser idêntica entre todos os estabelecimentos, especialmente quando lojas foram abertas em momentos diferentes ou em praças fiscais distintas. Uma regra configurada corretamente para o primeiro estabelecimento pode não ter sido replicada da mesma forma para os demais, criando uma divergência silenciosa entre lojas que, individualmente, emitem notas tecnicamente válidas, mas com critérios de cálculo que não são idênticos entre si.

Rastrear essa origem exige mais do que olhar o valor final na nota. Exige reconstruir, para cada estabelecimento, qual condição fiscal foi aplicada, de onde ela veio no cadastro, e se essa configuração está alinhada com a regra vigente desde que IBS e CBS passaram a ser obrigatórios no documento.

Um estabelecimento recém-aberto herda, por padrão, a parametrização do estabelecimento de referência usado para criá-lo no sistema, e qualquer ajuste fiscal feito depois no estabelecimento original raramente é propagado automaticamente para os que vieram depois. Isso cria um efeito de defasagem silenciosa: a regra mais recente e correta existe em algum lugar do cadastro, mas não necessariamente em todos os pontos de emissão que deveriam usá-la.

Esse efeito de herança desatualizada é especialmente relevante quando a correção posterior foi motivada por uma mudança regulatória pontual, aplicada manualmente num único estabelecimento sob pressão de prazo, sem que o processo de atualização tenha sido documentado de forma replicável para os demais pontos de venda. A regra correta existe, mas existe isolada, presa à loja onde foi corrigida primeiro. Quanto mais pontos de emissão a operação tiver, maior o número de combinações possíveis entre regra antiga e regra nova convivendo ao mesmo tempo, sem que exista, em muitos casos, um relatório único que mostre essa divergência consolidada entre lojas.

O teste de amostra por loja

O caminho estruturado para verificar essa exposição começa com uma amostra de notas emitidas por cada ponto de venda desde que a obrigatoriedade de IBS e CBS entrou em vigor, não uma amostra única da operação como um todo. Cada loja, nesse teste, precisa ser tratada como uma unidade separada de verificação.

Para cada nota da amostra, o teste reconstrói o cálculo esperado de IBS e CBS a partir das regras vigentes e compara com o valor efetivamente emitido. A divergência entre o valor calculado de forma independente e o valor que saiu na nota é o indicador direto de onde a parametrização do estabelecimento pode estar desalinhada.

Esse teste, feito loja por loja, revela se a divergência é um evento isolado, localizado num único estabelecimento, ou um padrão sistêmico que se repete na parametrização de vários pontos de emissão, o que sugere uma causa raiz comum, mais fácil de corrigir de uma vez do que loja por loja.

Além de comparar valores, o teste precisa registrar a evidência de origem de cada cálculo: qual condição fiscal foi acionada, de que tabela de configuração ela veio, e em que data essa configuração foi criada ou alterada pela última vez. Essa trilha de evidência é o que transforma uma simples lista de divergências numéricas em material defensável diante de qualquer questionamento posterior, seja interno, de auditoria ou de fiscalização.

Esse é o trabalho que a DFSpro estrutura: amostra de notas por loja, confrontada contra a regra de cálculo de IBS e CBS parametrizada no SAP, com lista priorizada de divergências encontradas. A DFSpro mede e prova o comportamento do sistema. A decisão sobre qual tese de cálculo tributário aplicar continua sendo do cliente.

A pergunta que o gerente fiscal precisa responder

Se a Receita cruzar as notas emitidas desde que IBS e CBS se tornaram obrigatórios no documento fiscal, qual loja tem campo de IBS ou CBS que o time fiscal não consegue explicar com uma regra de cálculo documentada? Essa pergunta não tem resposta de memória. Exige a amostra, loja por loja, comparando o que saiu na nota contra o que a regra vigente determinava.

O risco de não fazer esse teste não é teórico. É o acúmulo silencioso de confissões de valor, em cada nota emitida, que ninguém verificou enquanto a obrigatoriedade estava recente. O Diagnóstico Fiscal SAP é o ponto de partida para medir essa exposição antes que uma auditoria externa faça essa comparação primeiro.