Tag: XML fiscal

A manutenção de um emissor de CT-e não se limita a gerar XML, assinar o documento e transmitir um lote. Ela depende da leitura cuidadosa de regras fiscais, do comportamento do autorizador e da distinção entre processos que foram descontinuados e validações que continuam relevantes para o acervo histórico ou para determinados modelos de documento. A Nota Técnica (NT) 2023.001 v.1.03 é um marco útil para essa revisão.

O documento oficial reúne alterações nas regras de validação do CT-e, do CT-e OS e da GTV-e. Para desenvolvedores Delphi, o tema alcança rotinas de montagem de dados, tratamento de retornos, cadastros e testes de homologação. Para a contabilidade, envolve a conferência do fluxo documental, a numeração e a interpretação adequada de rejeições. Neste artigo, vamos identificar o alcance da nota, detalhar as mudanças confirmadas e, sobretudo, mostrar como transformar esse conteúdo em decisões técnicas prudentes.

Conferência de 23 de outubro de 2026: o aviso oficial da SVRS informa implantação das NTs 2026.004 no ambiente de homologação da SVRS. Isso complementa o cronograma geral até 26 de outubro e não comprova disponibilidade em todos os autorizadores. A previsão principal de produção continua em 16 de novembro; os marcos específicos do CT-e Simplificado permanecem separados.

A Nota Técnica 2026.004 RTC altera aspectos relevantes da emissão de documentos fiscais eletrônicos ligados ao transporte e ao transporte de passageiros. Para quem desenvolve em Delphi, mantém componentes de XML, integra web services autorizadores ou responde pela sustentação de um ERP, a mudança não se resume à inclusão de campos: ela alcança a formação dos valores documentais, a conferência de totais, cenários de contingência e, no CT-e Simplificado, a própria distribuição das informações tributárias entre cabeçalho e itens.

Para a área contábil e fiscal, o ponto central é interpretar corretamente a transição. A documentação técnica trata IBS e CBS como tributos calculados “por fora”, mas estabelece uma regra específica para impedir duplicidade na totalização de 2026. A composição indicada para 2027 não pode ser aplicada retrospectivamente como se já representasse a validação transitória de 2026.

Este guia apresenta o que está confirmado nas notas técnicas oficiais de CT-e e BP-e, diferencia cronogramas e propõe um roteiro de implementação. Também delimita o que ainda não deve ser tratado como requisito técnico confirmado para NFCom, NF3-e, NFAg e NFGas.

Atualização de 19 de outubro de 2026: o cronograma principal de CT-e e BP-e foi revisado conforme o comunicado do ENCAT de 15 de outubro. A homologação foi postergada para até 26 de outubro; a produção continua prevista para 16 de novembro. Os cronogramas específicos descritos para CT-e Simplificado e para a regra de 2027 permanecem separados.

A evolução da NF-e e da NFC-e para acomodar informações relacionadas à CBS e ao IBS exige atenção coordenada de quem desenvolve software e de quem responde pela operação fiscal. Não se trata apenas de incluir campos em telas ou atualizar uma biblioteca de emissão: a preparação pode envolver serialização de XML, regras de negócio, cadastros, tabelas de domínio, testes de autorização e, no caso da NF-e, a geração do DANFE.

O ponto de partida é o Ato Técnico Conjunto nº 8/2026, disponibilizado em 1º de outubro de 2026. Ele aprovou cinco notas técnicas e o Informe Técnico 2025.002 v1.70 para NF-e, modelo 55, e NFC-e, modelo 65. Poucos dias depois, um aviso oficial alterou parte do calendário. Por isso, uma implantação segura começa por distinguir três coisas que frequentemente são confundidas: publicação da documentação, entrada em homologação e ativação em produção.

Neste guia, apresentamos o alcance confirmado do pacote, os cronogramas e os cuidados para ERPs e componentes Delphi. O panorama não substitui a leitura integral das regras de validação e estruturas XML nem os testes de cada emissor.

A Nota Técnica CT-e 2026.004 v.1.00 altera pontos relevantes do leiaute e das validações de documentos de transporte eletrônico. Para quem desenvolve emissores em Delphi, mantém ERP ou TMS, integra serviços fiscais e revisa a escrituração de transportadoras, a leitura não pode ficar limitada aos novos nomes de campos: é preciso entender onde os valores nascem, como são totalizados, em quais cenários o XML muda e em que datas cada bloco técnico deve ser tratado.

A versão 1.00 está listada no Portal do CT-e como publicada em 1º de outubro de 2026, enquanto a capa da nota a identifica como versão de setembro de 2026. O documento reúne adequações relacionadas à Reforma Tributária do Consumo e alcança, de forma expressa em seu corpo, CT-e, CT-eOS e CT-e Simplificado. Neste artigo, vamos separar as mudanças confirmadas, os cronogramas, as consequências de implementação e os limites do que a documentação examinada permite concluir. A fonte central é a Nota Técnica CT-e 2026.004 v.1.00.

A atualização da Nota Fiscal de Serviço eletrônica (NFS-e) para contemplar IBS e CBS não é apenas uma mudança de nomenclatura tributária. Ela alcança o contrato técnico entre emissor e ambiente nacional: tipos de dados, grupos de informação, regras de negócio, cenários de ajuste e validações. Para quem mantém um ERP em Delphi, isso significa revisar componentes de geração de XML, modelos de domínio, persistência e rotinas de integração. Para a contabilidade, significa acompanhar se o dado transmitido expressa corretamente a operação que está sendo documentada.

O marco analisado aqui é o Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 7, de 28 de setembro de 2026, disponibilizado pelo CGIBS em 1º de outubro de 2026. Ele aprova documentos técnicos para a NFS-e e a NFS-e Via aplicáveis à CBS e ao IBS. Este artigo percorre o que foi formalmente aprovado, as alterações técnicas confirmadas, o cronograma divulgado, a divergência documental identificada e uma forma prática de conduzir a adequação sem confundir leiaute com obrigação tributária material.

O sistema foi atualizado, os campos da reforma tributária apareceram na tela e uma nota foi autorizada. Isso demonstra que a emissão funcionou naquele cenário, mas ainda deixa uma pergunta importante: a parametrização representa corretamente as operações da empresa? O Portal Nacional da NF-e esclarece o alcance da autorização de uso: ela envolve verificações formais e de regras de conteúdo, sem transferir ao Fisco a responsabilidade pelo mérito da operação declarada. Por isso, contador e desenvolvedor precisam comparar decisões fiscais, dados do cadastro e informações efetivamente geradas.

A revisão proposta acompanha o caminho da decisão fiscal até a emissão: começa pelo preenchimento do cadastro, verifica a coerência dos códigos e o contexto da operação, confere o XML e a vigência das regras e, por fim, reúne as evidências dos testes. Ao longo desse percurso, é preciso distinguir uma rejeição técnica de um enquadramento fiscal inadequado, pois cada problema exige uma investigação diferente.

O blog já explicou por que uma nota autorizada pode estar tributariamente errada. Aqui, vamos transformar o entendimento em seis cenários de revisão do sistema de gestão empresarial, o ERP. O foco é a Nota Fiscal Eletrônica (NF-e), com fontes conferidas em 13 de outubro de 2026. Os testes propostos são procedimentos didáticos; não representam execução em um emissor real nem homologação de integração.

A NFS-e Via criou um padrão nacional específico para o registro de prestações de serviços de exploração de via. Para quem desenvolve sistemas em Delphi, integra ERPs ou conduz a escrituração e a conferência fiscal de concessionárias, a novidade não se resume a mais um arquivo XML: ela conecta cadastros operacionais, identificação de passagens, valores cobrados, tributação e eventos documentais em um mesmo fluxo.

A base técnica inicial desse modelo está na Nota Técnica SE/CGNFS-e nº 006, versão 1.00, de 22 de janeiro de 2026. Ela apresenta o primeiro leiaute da NFS-e Via, disciplinando emissão em XML, transmissão ao Ambiente Nacional e validação síncrona. Mas há um ponto essencial para qualquer projeto: essa nota não deve ser lida isoladamente como fotografia definitiva do leiaute atual. A documentação oficial posterior registra ajustes pela NT 010 e lista uma versão mais recente do anexo de leiautes.

Este artigo percorre o contexto normativo, a estrutura funcional do documento, os reflexos técnicos e contábeis, as atualizações confirmadas e um roteiro concreto de adequação. A proposta é distinguir o que os documentos efetivamente estabelecem daquilo que é uma decisão de implementação ou uma inferência operacional prudente.

Uma nota fiscal autorizada não é necessariamente uma nota tributariamente correta. Essa diferença, que já existia antes da reforma tributária, ganha importância com o Código de Classificação Tributária do IBS e da CBS, o cClassTrib. O autorizador consegue verificar se o código existe, se combina com o CST informado e se pode ser usado naquele modelo de documento. Ele não consegue, sozinho, conhecer todos os fatos da operação e decidir se o tratamento jurídico escolhido pelo contribuinte é o adequado.

O tema foi levantado no episódio “cClassTrib: o código que decide o imposto do item na nota”, do Radar Tributário. A ideia central é pertinente: deixar de receber uma rejeição não encerra a análise tributária. Mas algumas expressões usadas no vídeo, como “o código que decide o imposto”, precisam de contexto para não sugerir que um campo isolado substitui a interpretação da operação.

Neste artigo, explico o que o cClassTrib representa, o que as rejeições 1023, 1024 e 1025 realmente verificam, por que o NCM não produz um “de/para” universal e como contabilidade e desenvolvimento podem revisar a parametrização sem transformar uma tabela oficial em piloto automático.