Rafael Pousas20 de maio de 2026 · 14 min de leitura
Os campos obrigatórios no XML com IBS e CBS são aqueles que permitem identificar a incidência, a base de cálculo, a alíquota, o valor do tributo, o tratamento tributário e o destino da operação.
Em termos práticos, o emissor precisa suportar grupos e tags como gIBSCBS, CST, cClassTrib, vBC, campos de alíquota e valor para IBS e CBS, além de subgrupos para IBS estadual e municipal quando aplicável.
A mudança parece um detalhe de layout, mas não é. O XML passa a carregar a lógica do IVA Dual, formado por IBS e CBS, e será usado para a apuração, crédito, fiscalização eletrônica e, em parte das operações, integração com o pagamento.
Se o dado nasce errado no XML, o erro não fica escondido no rodapé. Ele viaja para o crédito do cliente, para a escrituração e para o caixa.
Na prática, contadores e advogados precisarão olhar menos para “qual campo preencher” de forma isolada e mais para qual raciocínio tributário o XML está declarando.
A Nota Técnica 2025.002 RTC incluiu, na NF-e e NFC-e, grupos próprios para IBS, CBS e Imposto Seletivo, com informações por item e totalização na nota.
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.
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”.
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.
As novas tags obrigatórias, em sentido funcional, são as que permitem calcular IBS e CBS com rastreabilidade. O conjunto básico envolve:
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.
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?”.
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?”.
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.
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:
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?”.
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:
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?
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.
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?
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.
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.
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.
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?
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 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.
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.
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.
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.
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.
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.
Especialista em Consultoria Tributária
Rafael Pousas é Contador e Especialista em Consultoria Tributária, formado em Ciências Contábeis pela Universidade Federal de Minas Gerais (UFMG). Atua na área tributária com foco em oferecer soluções seguras e eficientes para empresas, garantindo conformidade legal e apoio estratégico na gestão fiscal. Com 5 anos de experiência, Rafael desenvolve trabalhos voltados à auditoria e consultoria tributária, especialmente para médias empresas. Sua atuação é marcada pelo detalhismo, atenção às normas e constante atualização frente às mudanças do cenário fiscal, sempre buscando reduzir riscos e otimizar processos. Na GestãoClick, ClickNotas e CertClick, Rafael produz conteúdos sobre legislação tributária, obrigações fiscais e Reforma Tributária. Seu objetivo é auxiliar contadores de micro e pequenas empresas a se manterem atualizados e compreenderem as normas fiscais de forma prática, apoiando decisões mais seguras e assertivas.
Emita suas notas fiscais sem complicação
NF-e, NFS-e e NFC-e em um só lugar, com suporte de verdade.
Notas FiscaisEvite notas fiscais rejeitadas e retenções indevidas. Veja como o cadastro de produtos define o sucesso da emissão sob as novas regras do IVA Dual.
Patrícia14 min de leitura
Reforma TributáriaPrepare sua contabilidade para o novo SPED. Descubra como adaptar sua escrituração para o IBS e CBS e garanta conformidade na transição do IVA Dual.
Rafael Pousas10 min de leitura
Reforma TributáriaAprenda a projetar os custos da Reforma Tributária. Saiba como simular impacto tributário do IBS e CBS no seu caixa e prepare sua micro empresa para a transição de 2026.
Rafael Pousas15 min de leitura