Por que o layout da nota fiscal mudou com a chegada do IVA Dual?
O layout mudou porque o modelo antigo foi desenhado para tributos diferentes entre si, como ICMS, ISS, PIS e Cofins. O IVA Dual exige outra lógica: tributação por item, cálculo por fora, crédito financeiro e identificação do destino da operação.
A NF-e deixa de ser apenas o registro da venda. Ela passa a ser a primeira peça de apuração do IBS e da CBS. Parece exagero chamar o XML de centro nervoso do faturamento? Não é. O Fisco vai ler o arquivo como dado estruturado, não como intenção do contribuinte.
Para a empresa, isso muda o ERP. Para o contador, muda a revisão de cadastro. Para o advogado, muda a prova documental em discussões sobre crédito, cobrança indevida, glosa ou responsabilidade por erro de emissão.
Como a CBS e o IBS são apresentados no arquivo digital?
No XML, IBS e CBS devem aparecer em grupos próprios, separados dos tributos atuais, com dados suficientes para cálculo e validação. A referência técnica mais citada é o grupo gIBSCBS, que concentra campos como CST, cClassTrib, vBC, alíquotas e valores calculados para IBS e CBS.
A estrutura também prevê detalhamento do IBS em parcelas ligadas à UF e ao município, por meio de subgrupos como gIBS, gIBSUF e gIBSMun, quando o documento fiscal aplicável exigir essa decomposição.
Em português de rotina fiscal: cada item da nota precisa dizer o que está sendo vendido, como aquilo é tributado, sobre qual base, com qual alíquota e qual valor de imposto resulta desse cálculo. O XML vira uma confissão técnica da operação. Tomara que seja verdadeira.
Leia também: “Modelo de nota fiscal com IBS e CBS: o que muda na emissão dos novos tributos”.
Qual a importância da base de cálculo “por fora” no XML?
A base “por fora” importa porque IBS e CBS não seguem a lógica de imposto embutido em si mesmo. O valor do tributo deve ser destacado de forma transparente, sem compor sua própria base de cálculo.
Na emissão, isso exige separar preço do item, descontos, frete, seguro, outras despesas e valores tributários. Se o sistema apenas reaproveitar a lógica antiga do ICMS por dentro, a base pode ficar inflada ou inconsistente.
O risco prático é duplo: a empresa pode faturar com preço errado e o cliente pode receber um XML que não sustenta crédito. Em B2B, esse segundo ponto pesa. Ninguém gosta de fornecedor que entrega mercadoria e dor de cabeça fiscal na mesma remessa.
Confira depois: Nota fiscal interestadual: diferencial de alíquota e o que muda na emissão.
Quais são as novas tags obrigatórias para o cálculo dos tributos?
As novas tags obrigatórias, em sentido funcional, são as que permitem calcular IBS e CBS com rastreabilidade. O conjunto básico envolve:
- gIBSCBS, grupo de informações do IBS e da CBS;
- CST, código de situação tributária;
- cClassTrib, código de classificação tributária;
- vBC, base de cálculo;
- campos de alíquota do IBS e da CBS, como pAliqIBS e pAliqCBS;
- campos de valor do IBS e da CBS, como vIBS e vCBS ou equivalentes conforme schema vigente;
- campos de redução de base ou alíquota, quando houver tratamento diferenciado;
- campos de diferimento, crédito presumido ou monofasia, quando a operação exigir.
Atenção: o nome exato da tag deve ser conferido no schema XSD vigente do documento fiscal usado. A Reforma não autoriza “campo criativo”. XML não é redação livre.
Onde inserir a alíquota específica de cada estado e município?
A alíquota do IBS deve ser informada nos campos próprios do grupo de tributação do item, com decomposição entre a parcela estadual e municipal quando o layout exigir.
A referência técnica aponta subgrupos como gIBSUF e gIBSMun, justamente para separar a parcela da UF e do município no IBS.
Na prática, o ERP precisa buscar o destino da operação, identificar o município, aplicar a regra vigente e gravar os percentuais e valores nos campos corretos.
Não basta saber que o cliente está em outro estado. É preciso saber onde ocorre o consumo, porque o IBS segue a lógica de tributação no destino.
O trade-off aparece aqui: quanto mais automatizado o motor fiscal, menor o risco operacional. Mas maior também a dependência de cadastros íntegros. Automatizar cadastro ruim só entrega erro em escala industrial.
Entenda mais com detalhes: “Como a CBS deve aparecer no XML?”.
Como informar o local da operação para garantir a tributação no destino?
O local da operação deve ser informado pelos dados do destinatário, endereço, município, UF e natureza da operação, além dos campos próprios que o documento fiscal exige para identificar o destino ou o local de incidência. A lógica do IBS depende dessa informação para direcionar a arrecadação ao ente de destino.
Para mercadorias, o ponto crítico costuma estar no cadastro do destinatário e no endereço de entrega. Para serviços, o cuidado se desloca para o local da prestação ou do consumo, conforme a regra aplicável.
Quando essa lógica não se aplica? Em operações com tratamento específico, exportações, imunidades, regimes próprios ou documentos fiscais com regra própria de localização, a empresa não deve “forçar” a regra geral. O XML deve seguir o código de classificação tributária e o documento fiscal correspondente.
Saiba mais: “Como destacar o IBS no XML?”.
Como o XML deve registrar o mecanismo de Split Payment?
O XML deve registrar informações que permitam vincular a operação fiscal à transação de pagamento e identificar os valores de IBS e CBS incidentes. A LC nº 214/2025 prevê que, no Split Payment, prestadores de pagamento segregam e recolham IBS e CBS no momento da liquidação financeira, com base nas informações da operação.
Isso significa que o documento fiscal precisa conversar com o financeiro. Nota emitida de um lado e pagamento conciliado “no olho” do outro não combinam com o novo modelo.
Quais dados de pagamento são necessários para a retenção automática?
A legislação exige dados que permitam vincular a operação à transação de pagamento e identificar os valores de IBS e CBS incidentes. O art. 32 da LC nº 214/2025 prevê que o originador da transação transmita informações ao prestador de pagamento para fazer essa vinculação e identificação.
Na prática, o sistema deve guardar e transmitir referências como:
- identificação do documento fiscal;
- valor total da operação;
- valores destacados de IBS e CBS;
- meio de pagamento;
- identificação da transação financeira;
- parcelas, quando houver pagamento parcelado;
- dados necessários à conciliação entre nota, recebimento e retenção.
O ponto não é apenas preencher o XML. É permitir que o banco, a adquirente, a carteira digital ou outro agente financeiro saiba quanto deve seguir para o fornecedor e quanto deve ser segregado.
Saiba mais em: “Split Payment: o que é, impactos e quando começa a valer?”.
De que forma o XML comunica o valor líquido ao sistema bancário?
O XML não “fala sozinho” com o banco. Ele alimenta a cadeia de dados que permite ao sistema de pagamento consultar as informações fiscais e calcular a segregação. A LC nº 214/2025 prevê que, antes de disponibilizar recursos ao fornecedor, o prestador de pagamento consulte o sistema do Comitê Gestor do IBS e da RFB sobre os valores a serem segregados.
Então, o valor líquido nasce da combinação entre:
- valor total pago;
- valores de IBS e CBS destacados;
- débitos já extintos por outras modalidades;
- regras do procedimento padrão ou simplificado;
- eventual parcelamento.
Se houver divergência entre nota, cobrança e liquidação, o caixa vira campo de batalha. O contador verá diferença na conciliação. O advogado verá discussão sobre retenção indevida. A empresa verá dinheiro faltando.
Confira depois: Como evitar multas de IBS e CBS na Reforma Tributária?
Como o código NCM e o CFOP influenciam o preenchimento dos campos?
O NCM influencia o enquadramento do produto, a identificação de tratamentos diferenciados, possíveis reduções, alíquota zero, monofasia ou incidência de Imposto Seletivo.
O CFOP continua relevante para descrever a natureza da circulação no modelo atual e durante a transição, mas perde centralidade como chave única de leitura do IBS e da CBS.
O novo XML exige coerência entre NCM, CST, cClassTrib, natureza da operação, destinatário e tratamento tributário. Se um desses elementos contradiz o outro, o documento pode passar a carregar uma inconsistência estrutural.
Por que a classificação correta evita a rejeição da nota em 2026?
A classificação correta evita rejeição porque o sistema tende a validar a compatibilidade entre o item vendido, sua classificação fiscal, o código de situação tributária e o tratamento aplicado.
A NT 2025.002 RTC incluiu regras de validação para o grupo de IBS/CBS/IS, ainda que a aplicação de algumas regras venha sendo faseada.
Exemplo prático: uma distribuidora cadastra determinado produto com NCM antigo e aplica alíquota reduzida por hábito. O ERP preenche o cClassTrib como se o item estivesse em tratamento diferenciado.
Se o NCM não sustenta esse tratamento, o XML fica incoerente. Mesmo que a nota não seja rejeitada de imediato em alguma fase da transição, o crédito do cliente pode ficar exposto.
O erro antigo era chato. O erro novo é auditável, rastreável e compartilhado com quem compra.
Saiba mais: CFOP na Reforma Tributária: o que muda para as empresas?
Como o Imposto Seletivo é destacado nos campos de tributação monofásica?
O Imposto Seletivo deve ser destacado em campos próprios quando a operação envolver bem ou serviço sujeito a esse tributo. A NT 2025.002 RTC prevê informações de IBS, CBS e IS no grupo UB e totalização específica no grupo W03 da NF-e/NFC-e.
A lógica do IS é diferente da lógica de crédito amplo do IBS e da CBS. Ele tem caráter seletivo e incide sobre hipóteses específicas, previstas na LC nº 214/2025 e em atos complementares.
Quando houver tributação monofásica ou concentrada de IBS/CBS, o XML deve usar os subgrupos próprios, como os relacionados à monofasia, quando aplicáveis. A fonte técnica documenta o gIBSCBSMono como subgrupo para regime monofásico do IBS e da CBS.
Entenda com mais detalhes: Imposto Seletivo na nota fiscal: quem precisa destacar e como funciona.
Quais os riscos jurídicos de omitir informações no arquivo XML?
O risco jurídico de omitir informações no XML está em transformar uma operação real em um documento fiscal incompleto. Isso pode comprometer crédito, apuração, recolhimento, prova da operação e conformidade perante a fiscalização eletrônica.
Não se trata apenas de multa por campo vazio. O problema maior é a consequência econômica: crédito glosado para o cliente, retenção incorreta no Split Payment, divergência contábil e discussão contratual entre comprador e fornecedor.
Como a falta de dados invalida o crédito tributário do seu cliente?
A falta de dados pode invalidar o crédito porque o novo modelo depende da nota fiscal para comprovar base, alíquota, valor do imposto e enquadramento da operação. O grupo gIBSCBS deve conter CST, cClassTrib, base, alíquotas e valores, exatamente para permitir essa rastreabilidade.
Se o XML não informar corretamente a CBS ou o IBS, o adquirente não consegue demonstrar, com segurança, o crédito que pretende aproveitar. A discussão deixa de ser “paguei ao fornecedor” e passa a ser “o documento fiscal permite crédito?”.
Para contadores com carteira PME, este será um ponto comercial sensível. Cliente B2B pode trocar de fornecedor se a nota recebida não gerar crédito confiável. A fidelidade empresarial costuma ser bonita no discurso, mas desaparece diante de crédito tributário inseguro.
Saiba mais: Automação fiscal na Reforma Tributária: reduza erros e riscos.
Quais sanções o Comitê Gestor aplica por erros de preenchimento?
A LC nº 214/2025 cria o Comitê Gestor do IBS e estrutura a administração do novo tributo, mas sanções concretas por preenchimento dependerão das regras de fiscalização, regulamentação e atos aplicáveis ao período.
O que já dá para afirmar com segurança é o risco operacional: o erro pode gerar rejeição do documento quando a validação estiver ativa, exigência de correção, inconsistência na apuração, bloqueio ou glosa de crédito e exposição a fiscalização eletrônica.
Aqui cabe uma cautela jurídica: não convém prometer uma penalidade específica sem ato vigente que a detalhe para aquele caso. O correto é mapear o risco, registrar o fundamento técnico e corrigir a origem do erro no cadastro e no emissor.
Veja também: Como evitar glosa de crédito no novo sistema tributário?
Dados íntegros: a base para um faturamento sem erros na Reforma
A Reforma Tributária não começa no botão “emitir nota”. Começa no cadastro de produtos, clientes, serviços, regras fiscais, meios de pagamento e integrações do ERP.
Um XML com IBS e CBS precisa responder a perguntas simples:
- O item está classificado corretamente?
- O CST e o cClassTrib combinam com a operação?
- A base de cálculo foi apurada por fora?
- A alíquota aplicada corresponde ao destino e ao tratamento tributário?
- Há redução, diferimento, crédito presumido ou monofasia?
- O pagamento pode ser vinculado à nota?
- O cliente conseguirá aproveitar crédito com segurança?
O contador deve revisar a matriz fiscal. O advogado deve observar contrato, responsabilidade por emissão incorreta e prova documental. A empresa deve testar o faturamento antes de depender dele na produção.
Dúvidas frequentes sobre os novos campos da nota fiscal
1. O DANFE continuará exibindo todos os novos campos do XML?
Não necessariamente. O DANFE continua sendo representação gráfica da NF-e, útil para acompanhamento da mercadoria e conferência visual, mas o documento fiscal com validade técnica e jurídica é o XML. O XML contém os campos estruturados usados para apuração, crédito e fiscalização.
Na prática, o DANFE pode exibir informações resumidas. Quem valida crédito, base, alíquota e enquadramento deve conferir o XML.
2. Como informar o benefício de alíquota reduzida para serviços no XML?
O benefício deve ser informado por meio do código de classificação tributária adequado, campos de redução de alíquota ou base, e demais campos previstos no schema vigente do documento fiscal. Referências técnicas listam campos como pRedBC e pRedAliq dentro da estrutura de IBS/CBS.
O cuidado é não aplicar redução por analogia. Serviço de saúde, educação, transporte ou outro setor com tratamento diferenciado precisa ser enquadrado conforme regra específica e código correto.
3. Onde destacar o valor do Cashback para o consumidor final?
O cashback depende de regras próprias de identificação do consumidor e devolução tributária. A LC nº 214/2025 trata de cidadania fiscal, cashback e devolução em sua estrutura geral, mas o destaque técnico deve seguir os campos e orientações do documento fiscal e atos complementares vigentes.
Na prática, não se deve criar tag própria nem usar campo livre para “inventar” cashback. O emissor deve aguardar e aplicar o layout oficial correspondente, incluindo CPF, identificação do consumidor ou campos específicos quando exigidos.
4. Existe um campo específico para o crédito presumido do agronegócio?
Há campos relacionados a crédito presumido no grupo de IBS/CBS, como códigos e indicadores próprios, conforme referências técnicas do XML.
Para o agronegócio, o ponto principal será cruzar a hipótese legal, o tipo de produtor, a operação, o item e o código correto. Crédito presumido informado sem base normativa é convite para glosa. E convite, nesse caso, ninguém quer aceitar.
5. Como o XML trata a devolução de mercadorias no modelo Split Payment?
A devolução deve ser documentada com a operação fiscal correspondente, vinculando a nota original e ajustando os valores de IBS e CBS conforme o evento ou documento aplicável. No Split Payment, a dificuldade aumenta porque parte do tributo pode já ter sido segregada na liquidação financeira.
Por isso, o ERP precisa integrar fiscal e financeiro. Cancelar ou devolver mercadoria sem reconciliar nota, pagamento e tributo retido pode gerar saldo preso, crédito incorreto ou ajuste posterior desnecessário. A devolução deixa de ser só logística. Vira também evento de apuração.
