Retirar IBS, CBS e Imposto Seletivo do campo vProd da NF-e não significa retirar esses tributos da operação. Para quem confere documentos fiscais, a diferença é decisiva: valor dos produtos, bases de cálculo e total da nota precisam ser tratados como grandezas distintas. Uma integração que mistura essas informações pode duplicar valores ou apontar divergências inexistentes.
A atualização atribuída à versão 1.01 da NT 2026.008 mantém esses três tributos fora do vProd e os direciona à composição dos totais aplicáveis. A descrição da alteração e dos campos informa publicação em 30 de outubro de 2026 e entrada em produção de uma etapa em 16 de novembro.
Há uma pendência relevante para implantar: essas informações foram obtidas da notícia, sem conferência independente do documento oficial. A versão vigente, os identificadores das regras e seu calendário precisam ser confirmados no Portal Nacional da NF-e antes de liberar alterações em produção. O roteiro abaixo organiza essa conferência, sem substituir a especificação técnica.
vProd não é base de cálculo nem total da nota
A primeira revisão deve ocorrer no significado dos campos. O valor bruto dos produtos não pode ser usado automaticamente como base de todos os tributos. Tampouco deve ser confundido com o total a pagar. Descontos, frete, despesas e tratamentos tributários exigem análise própria, conforme a operação e as regras aplicáveis.
A notícia descreve os seguintes campos, cuja definição completa deve ser confrontada com o leiaute oficial:
- vProd: valor bruto do produto ou serviço, sem acrescentar IBS, CBS e IS.
- vProdLiq e vUnComLiq: valores líquido do produto e líquido unitário.
- vProdLiqTot: total dos valores líquidos dos produtos ou serviços.
- vItem: valor total do item, com os componentes aplicáveis.
- vNFTot: total do documento, descrito como a soma dos totais dos itens.
Essa relação não constitui uma fórmula universal de totalização. É necessário verificar caminhos completos no XML, ocorrência por item ou total, condições de preenchimento e componentes de cada cálculo. O nome de uma tag, isoladamente, não basta para definir o lançamento contábil ou o crédito tributário.
Considere um teste hipotético: o sistema registra R$ 1.000 em produtos e R$ 100 em tributos segregados. Se a interface acrescentar esses R$ 100 ao valor dos produtos e outra rotina os adicionar novamente ao total, haverá duplicidade. Os números apenas ilustram o erro de integração; não representam alíquota nem fórmula legal de uma operação real.
Alterar o XML não equivale a mudar a incidência
Uma nota técnica orienta a representação e a validação de informações no documento eletrônico. A incidência, a base de cálculo, a alíquota e o direito a crédito dependem da legislação aplicável. Por isso, retirar um tributo de determinado campo não demonstra, por si só, redução de carga, isenção ou mudança no custo da compra.
Na prática, devem existir duas aprovações: a fiscal, sobre o tratamento da operação, e a técnica, sobre sua implementação. Essa separação também orienta a revisão do ERP para a CBS sem antecipar regras. Uma atualização de software não substitui a fundamentação tributária.
Os números do IMTT — Índice de Maturidade Tecnológica em Tax, da Confeb, de 2026, ajudam a dimensionar o desafio: entre as empresas respondentes, 100% utilizam ERP, mas 31% ainda fazem envio manual na integração interna entre ERP e plataformas de Tax. O estudo ouviu 190 profissionais. Para a conciliação, isso reforça a necessidade de testar também os arquivos e ajustes manuais que conectam os sistemas.
O cronograma precisa ser controlado por regra
O calendário descrito na notícia situa a produção dos novos campos e das regras previstas para aquela etapa em 16 de novembro de 2026, em substituição a 3 de novembro. Também apresenta homologação em 1º de fevereiro de 2027 e produção em 1º de março de 2027 para uma regra ligada ao ICMS previsto em pagamentos antecipados.
Essas datas não devem ser estendidas a todo o pacote. A mesma descrição informa implementação futura, sem data definida, para a obrigatoriedade geral de vProdLiq e determinadas regras de composição de vItem. Disponibilizar um campo, ativar uma validação e exigir seu preenchimento são eventos diferentes.
Antes da implantação, monte uma matriz com versão da NT, pacote de schemas, regra, operação alcançada, ambiente e data. Para pagamentos antecipados, confirme também o alcance do campo vICMSPrevisto. O cuidado é semelhante ao necessário para validar novos campos de IBS/CBS no CT-e: não transportar exigências entre documentos distintos por analogia.
Roteiro de testes entre XML, ERP e escrituração
1. Fixe a referência técnica. Arquive a versão oficial consultada, sua data e os schemas utilizados. Relacione cada alteração ao requisito do fornecedor de software. Se houver diferença entre a notícia, a documentação do fornecedor e a especificação oficial, trate-a como pendência antes da aprovação.
2. Prepare operações representativas. Selecione vendas e compras com múltiplos itens, descontos, frete, devoluções e diferentes tratamentos tributários. Inclua pagamentos antecipados quando fizerem parte da operação da empresa. Para cada cenário, registre previamente os valores esperados, suas fórmulas e o fundamento fiscal.
3. Confira cada passagem do dado. Compare pedido, cálculo do ERP, XML gerado, retorno do autorizador, importação no sistema destinatário e registro fiscal. Identifique onde cada valor nasce e se sofre transformação. Como no teste do ERP além do XML de saída da NFS-e, a validação precisa alcançar as interfaces posteriores à emissão.
4. Teste precisão e exceções. A notícia menciona tolerância de um centavo na relação entre valor líquido unitário, quantidade comercializada e valor líquido do produto. Confirme a regra oficial antes de adotá-la. Execute casos no limite e fora dele, com quantidades fracionadas, sem generalizar essa tolerância para outras validações.
A evidência deve explicar o resultado, não só guardar o XML
5. Reconcilie a escrituração. Verifique se produtos, descontos, despesas e tributos chegam aos registros corretos. A autorização da NF-e não prova, sozinha, que o ERP importou os valores adequadamente ou que o crédito foi reconhecido com fundamento válido. Compare também os totais usados no recebimento e no contas a pagar.
6. Monte o dossiê de homologação. Para cada cenário, preserve XML, protocolo ou retorno de rejeição, memória de cálculo, versão do sistema, parâmetros, resultado esperado e resultado obtido. Registre responsáveis, divergências, correções e aprovação. Capturas de tela ajudam, mas não substituem arquivos e cálculos reproduzíveis.
Na entrada em produção, monitore rejeições, diferenças de totalização e ajustes manuais. Se a nota do fornecedor divergir do pedido, investigue a composição antes de bloquear o recebimento ou alterar o valor a pagar. O objetivo é rastrear cada parcela da operação, sem transformar mudança de leiaute em decisão tributária automática.
Este conteúdo foi produzido com apoio de inteligência artificial e revisado pela equipe editorial da Live University.
Especialista virtual de Compliance & Obrigações e de Contencioso & Jurisprudência. Cobre os dois lados da mesma tese: antes, como governança, matriz de risco, auditoria interna e calendário de obrigação acessória; depois, como auto de infração, defesa, CARF, STJ e STF. Precisa: decisão sempre citada pelo órgão, número do processo ou tema e data do julgamento.
