A Declaração de Regimes Específicos, ou DeRE, passa por uma atualização técnica relevante para quem desenvolve, mantém ou opera sistemas fiscais. A Receita Federal e o Comitê Gestor do IBS (CGIBS) comunicaram a aprovação da versão 1.3.0 da documentação técnica pelo Ato Técnico Conjunto RFB/CGIBS nº 6, de 28 de setembro de 2026. Não se trata apenas de um novo manual: o pacote reúne regras de negócio, tabelas, leiautes XML e esquemas de validação que afetam a preparação, a transmissão e o processamento das informações.
Para escritórios contábeis, áreas fiscais e fornecedores de ERP — inclusive equipes que trabalham com Delphi — o ponto central é transformar a documentação em processos verificáveis. Isso envolve revisar cadastros, plano de contas, geração de XML, tratamento de retornos e rotinas de fechamento. Neste artigo, vamos separar o que foi confirmado oficialmente, o que isso sugere para a arquitetura do sistema e quais cuidados precisam orientar a implantação.
O que foi aprovado na DeRE 1.3.0
O Ato Técnico Conjunto RFB/CGIBS nº 6/2026 consta no índice oficial de atos técnicos conjuntos da Receita Federal e aprovou a documentação técnica da DeRE. Em comunicado oficial, o Sped informa que a medida formalizou a versão 1.3.0 do pacote técnico, voltado à adaptação de sistemas corporativos de contribuintes enquadrados nos regimes específicos de serviços financeiros, planos de assistência à saúde e concursos de prognósticos.
A DeRE é apresentada pelo portal do Sped como um documento fiscal destinado a viabilizar a apuração de IBS e CBS em contextos que não seguem exclusivamente a sistemática padrão de débito e crédito. A página destaca situações nas quais a base de cálculo depende de margens e de controles específicos de deduções. Portanto, o valor da declaração não está somente em registrar dados: ela integra uma cadeia de informações que requer coerência entre contabilidade, regras fiscais e eventos eletrônicos.
O pacote aprovado na versão 1.3.0 é composto por cinco conjuntos documentais:
- Manual de Orientação do Usuário da DeRE (MOD);
- Leiautes da DeRE — Eventos;
- Anexo I — Tabelas;
- Anexo II — Regras de Validação;
- Arquivos XSD (XML Schema Definition).
Essa composição merece atenção porque cada artefato responde a uma camada diferente da implementação. O MOD descreve conceitos, fluxos e orientações de preenchimento. Os leiautes especificam a estrutura dos eventos e dos campos XML. As tabelas fornecem domínios e códigos aceitos. As regras de validação detalham críticas de negócio, consistência e mensagens do sistema. Já os XSD ajudam a validar estrutura e sintaxe antes do envio.
Em termos de engenharia, um XML que passa no XSD não deve ser tratado automaticamente como um evento aceito. A validação estrutural é uma etapa; regras de negócio, dependências entre eventos e consistência com informações previamente processadas são outras. Essa distinção é especialmente importante ao projetar uma camada de validação local no ERP.
Mudanças destacadas oficialmente
O comunicado do Sped sobre a versão 1.3.0 aponta alterações específicas que devem entrar no planejamento de análise funcional e técnica. Não é um comparativo completo, campo a campo, com a versão anterior; são os destaques divulgados oficialmente. Ainda assim, eles indicam áreas de maior risco de incompatibilidade quando dados, regras e leiautes não forem revisados em conjunto.
Novo evento D-2252
A versão 1.3.0 institui o evento transacional D-2252, descrito como relativo a seguros de ramos elementares e de pessoas sem cobertura por sobrevivência, para identificação de adquirentes contribuintes. A consequência direta para o fornecedor de software é confirmar se o portfólio de clientes abrange operações alcançadas por esse evento e, em caso positivo, modelar os dados necessários desde a origem.
Criar uma tela ou um gerador de XML sem identificar a fonte confiável dos dados costuma levar a preenchimentos manuais e difíceis de auditar. Uma implementação consistente tende a começar pelo levantamento de entidades, documentos, participantes e regras de elegibilidade que alimentam o evento. Essa é uma inferência de arquitetura, não uma exigência adicional publicada: a documentação oficial confirma o novo evento, mas cada empresa precisará determinar a aplicabilidade concreta no seu segmento.
Deduções e o evento D-1121
O D-1121 recebe atenção porque sua finalidade informada é controlar, em conta-corrente, deduções por documento fiscal. Segundo o comunicado oficial, esse controle busca assegurar a não cumulatividade e evitar duplo benefício fiscal. Para a contabilidade, isso reforça que dedução não deve ser tratada apenas como um total mensal desconectado de sua origem documental.
Para o ERP, o ponto prático é preservar rastreabilidade. A aplicação precisa conseguir relacionar o dado usado na apuração ao documento correspondente e impedir que uma mesma referência seja usada de modo incompatível com as regras implementadas. Isso não significa presumir um algoritmo ou uma chave de controle específica que não conste do pacote técnico; significa desenhar a persistência de dados e as validações internas de forma que suportem a conferência exigida pelo evento.
Fechamento, reabertura e bases negativas
A versão 1.3.0 também traz regras relacionadas ao fechamento D-1199, à reabertura D-1198 e às bases de cálculo negativas. O Sped descreve o D-1199 como mecanismo de travamento das competências no ambiente autorizador e menciona travas de consistência entre eventos auxiliares e balancete. Para retificações, há rito de reabertura. Quanto às bases negativas acumuladas, o comunicado menciona parametrização de compensação pelos métodos automático PEPS ou manual.
Esses pontos deslocam a discussão de uma simples exportação de arquivo para um ciclo de estados. Em software, convém não representar o período apenas como “aberto” ou “fechado”. O desenho precisa distinguir, ao menos conceitualmente, a competência em preparação, os eventos enviados, o resultado do processamento, o fechamento aceito, a necessidade de reabertura e a nova versão decorrente de retificação.
A inferência é importante: se o sistema permitir alterações em dados que deram origem a um fechamento sem registrar a necessidade de reabertura, a conciliação entre base interna e declaração transmitida se torna frágil. A documentação confirmada não permite afirmar como cada ERP deve organizar suas tabelas internas, mas sustenta a necessidade de um controle operacional claro sobre esses marcos.
Tabelas, eventos transacionais e retorno
O Anexo I da versão 1.3.0 atualiza a Tabela 11, de códigos de tributação (codTrib), e a Tabela 12, de códigos de base de cálculo (codBC), além de variáveis auxiliares e coeficientes de rateio e reversão. Essas referências não devem ficar dispersas em condições codificadas diretamente no fonte Delphi. Uma tabela parametrizável, com versionamento e vigência controlada, reduz o risco de manter códigos antigos após a atualização documental.
Também foram destacados ajustes no D-2241, relativo a arranjos de pagamento e credenciados, para discriminação de deduções legais de tributos, e aperfeiçoamentos no D-9209, evento de retorno de eventos transacionais. O D-9209 merece tratamento como parte essencial da integração. Não basta registrar que a transmissão foi iniciada: é preciso persistir recibos, identificadores de lote, situação de processamento, mensagens recebidas e vínculo com os eventos de origem.
O MOD 1.3.0, disponibilizado pelo Sped, descreve transmissão em lotes, APIs ou Web Service, processamento assíncrono, assinatura digital e recibos. Para um sistema Delphi, isso sugere separar nitidamente quatro responsabilidades: montagem do XML, assinatura e comunicação, consulta de processamento e interpretação do retorno. Essa separação favorece testes unitários e reduz o acoplamento entre a regra fiscal e a infraestrutura de transporte.
Cronograma: o que a versão 1.3.0 não altera por si só
Uma leitura cuidadosa evita confundir a aprovação do pacote 1.3.0 com a criação integral da obrigação ou com uma nova data geral de início. O comunicado oficial de agosto sobre o cronograma da DeRE esclarece que os eventos de tabela D-1001, Informações do Contribuinte, e D-1011, Plano Geral de Contas Comentado, passaram a ser recepcionados a partir de 1º de outubro de 2026.
A mesma orientação estabelece que os eventos de tabela devem estar transmitidos e processados com sucesso antes dos eventos periódicos mensais da competência outubro de 2026. Para essa primeira escrituração mensal, o prazo informado foi 15 de novembro de 2026. Entre os eventos periódicos citados estão D-1101, D-1106 quando houver obrigatoriedade, D-1121, D-2101 quando aplicável ao setor financeiro, e D-1199.
A Receita Federal também informou a disponibilização de D-1001 e D-1011 em ambiente de produção beta. As fontes acessadas, porém, não confirmam endpoints, credenciais, abrangência de todos os eventos da versão 1.3.0 ou a situação de recepção de cada um deles. Assim, não é seguro extrapolar que todo o pacote esteja aberto no mesmo ambiente ou sob as mesmas condições. A consulta à documentação vigente e aos canais oficiais deve integrar a rotina de implantação.
Aplicação prática
A adequação ganha qualidade quando contabilidade, fiscal e desenvolvimento trabalham sobre o mesmo roteiro. A seguir, um caminho objetivo, baseado nos componentes e nas orientações oficiais disponíveis.
1. Delimite a aplicabilidade antes de desenvolver
Liste os clientes, produtos e operações que possam estar nos segmentos mencionados no comunicado: serviços financeiros, planos de assistência à saúde e concursos de prognósticos. Em seguida, valide a incidência da DeRE e dos eventos por regime e subsegmento no MOD e na regulamentação aplicável.
Essa triagem é indispensável porque as fontes confirmam o foco setorial, mas não fornecem, por si só, um mapa exaustivo de obrigatoriedade, dispensas e eventos exigidos para cada operação. Desenvolver tudo indiscriminadamente pode ampliar custo e complexidade; ignorar um evento aplicável pode comprometer o processo. A decisão deve ser documentada com participação do responsável tributário do cliente.
2. Atualize artefatos técnicos como um conjunto
Baixe o pacote oficial 1.3.0 e mantenha-o identificado no repositório do projeto. Atualize simultaneamente XSD, mapeamentos de eventos, tabelas de domínio e mensagens de validação. Evite substituir somente o schema XML e considerar a tarefa concluída, pois mudanças em codTrib, codBC e regras de negócio podem demandar ajustes de cadastro e cálculo.
Em aplicações Delphi, é recomendável centralizar as versões dos leiautes em uma camada própria. O gerador de XML deve receber uma estrutura de dados validada, em vez de decidir códigos tributários por regras espalhadas em formulários, datasets ou relatórios. O objetivo é facilitar a auditoria da regra e permitir correções com menor risco de efeitos colaterais.
3. Trate D-1001 e D-1011 como pré-requisitos operacionais
A sequência divulgada pelo Sped é clara: transmitir os eventos de tabela, aguardar o processamento bem-sucedido, corrigir inconsistências e somente então transmitir os eventos periódicos mensais. O órgão ainda recomenda não enviar no mesmo lote eventos com dependência lógica quando a validação de um depender de informação ainda não processada do outro.
Na prática, implemente uma fila de transmissão orientada por dependências. Antes de liberar D-1101, D-1121 ou D-1199, o sistema deve consultar e registrar o sucesso do D-1001 e do D-1011 relevantes. Caso o PGCC seja atualizado, a regra de negócio do ERP deve evitar que o balancete seja processado contra uma versão anterior sem que a equipe perceba. O comunicado oficial alerta precisamente para esse risco.
4. Modele o ciclo mensal e os retornos
Monte casos de teste para competência normal, fechamento, reabertura e retificação. Para cada caso, guarde o XML enviado, o identificador de transmissão, o recibo, o status final e as críticas retornadas. Inclua cenários de dependência entre eventos, deduções por documento, base de cálculo negativa e uso dos eventos transacionais aplicáveis ao cliente.
O processamento assíncrono exige disciplina. A tela que envia o lote não deve traduzir a conclusão da chamada como aceitação definitiva da escrituração. A aplicação precisa agendar ou permitir a consulta de resultados, converter retornos em informações compreensíveis para o usuário e impedir o fechamento interno enquanto existirem pendências relevantes.
5. Faça reconciliação contábil-fiscal antes do D-1199
Como a documentação menciona consistência entre eventos auxiliares e balancete, estabeleça uma conferência formal antes do fechamento. Compare saldos e dados que alimentam o D-1101 com deduções reportadas, códigos tributários e bases de cálculo usados na competência. Quando houver base negativa, identifique o critério de compensação adotado e mantenha evidência interna do cálculo.
O sistema não deve transformar essa recomendação em uma suposta regra fiscal não documentada. O papel do ERP é oferecer trilha de auditoria, alertas e relatórios de divergência; a decisão tributária sobre os dados deve permanecer validada pela área competente. Essa divisão reduz o risco de automatizar interpretações sem respaldo.
Limitações das evidências disponíveis
Há limites relevantes para a leitura desta atualização. Embora o Ato Técnico Conjunto nº 6/2026 esteja identificado no índice oficial da Receita Federal e tenha sido corroborado por comunicados oficiais, o texto individual do ato apresentou indisponibilidade durante a pesquisa. Por isso, este artigo não afirma detalhes não reproduzidos nas fontes acessadas, como veículo específico e horário de eventual publicação no Diário Oficial da União.
Também não foi realizado um comparativo independente, tag a tag, entre as versões 1.2.0 e 1.3.0 dos PDFs e XSD. Os pontos apresentados como mudanças são aqueles destacados oficialmente pela Receita e pelo Sped. Um fornecedor que precise estimar esforço por campo, classe Delphi ou regra de cálculo deve executar seu próprio diff estruturado entre as versões, além de testar os arquivos contra os ambientes efetivamente disponibilizados.
Por fim, as fontes não permitem concluir que todos os eventos da versão 1.3.0 estejam disponíveis nas mesmas condições de produção, nem detalham endpoints, autenticação ou particularidades de infraestrutura. Esses itens precisam ser confirmados diretamente no pacote técnico e nos comunicados oficiais vigentes antes de uma implantação produtiva.
Conclusão
A aprovação da DeRE 1.3.0 consolida um pacote técnico que alcança documentação funcional, leiautes, tabelas, validações e schemas XML. Os destaques oficiais — D-2252, D-1121, fechamento D-1199, reabertura D-1198, bases negativas, atualizações em tabelas e retornos transacionais — indicam que a adequação exige mais do que atualizar um arquivo XSD.
Para desenvolvedores Delphi e equipes de ERP, a resposta mais segura é estruturar a integração em camadas, versionar os artefatos, tratar retornos assíncronos e controlar dependências entre eventos. Para contadores e profissionais fiscais, a prioridade é validar a aplicabilidade por cliente, assegurar a coerência entre plano de contas, balancete e deduções, e formalizar a conferência antes do fechamento.
O cronograma divulgado reforça uma lição operacional: eventos cadastrais processados com sucesso vêm antes da escrituração mensal. Com dados consistentes, fila de transmissão controlada e testes de fechamento e reabertura, o sistema estará melhor preparado para acompanhar a evolução da DeRE sem transformar atualizações técnicas em surpresas no período de apuração.
Referências
BRASIL. Receita Federal do Brasil. Atos Técnicos Conjuntos. Brasília, DF: Receita Federal do Brasil, 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/reforma-tributaria-do-consumo/legislacao/atos-tecnicos-conjuntos. Acesso em: 8 out. 2026.
BRASIL. Receita Federal do Brasil. Receita Federal publica versão 1.3.0 da documentação técnica da DeRE. Brasília, DF: Receita Federal do Brasil, 7 out. 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/assuntos/noticias/2026/outubro/receita-federal-publica-versao-1-3-0-da-documentacao-tecnica-da-dere. Acesso em: 8 out. 2026.
BRASIL. Sistema Público de Escrituração Digital. DeRE: esclarecimentos sobre o cronograma, a vigência dos eventos de tabela e as regras de transmissão da Declaração de Regimes Específicos (DeRE). Brasília, DF: Sped, 26 ago. 2026. Disponível em: https://www.gov.br/sped/pt-br/assuntos/comunicados/dere/dere-esclarecimentos-sobre-o-cronograma-a-vigencia-dos-eventos-de-tabela-e-as-regras-de-transmissao-da-declaracao-de-regimes-especificos-dere-ato-conjunto-rfb-cgibs-no-4-de-30-de-julho-de-2026. Acesso em: 8 out. 2026.
BRASIL. Sistema Público de Escrituração Digital. DeRE – Receita Federal e CGIBS publicam versão 1.3.0 da documentação técnica da DeRE. Brasília, DF: Sped, 2 out. 2026. Disponível em: https://www.gov.br/sped/pt-br/assuntos/comunicados/dere/dere-receita-federal-e-cgibs-publicam-versao-1-3-0-da-documentacao-tecnica-da-dere. Acesso em: 8 out. 2026.
BRASIL. Sistema Público de Escrituração Digital. Declaração de Regimes Específicos – DeRE. Brasília, DF: Sped, 2026. Disponível em: https://www.gov.br/sped/pt-br/assuntos/documentos-fiscais/dere. Acesso em: 8 out. 2026.
BRASIL. Sistema Público de Escrituração Digital. Manual de Orientação do Usuário da DeRE (MOD), versão 1.3.0. Brasília, DF: Sped, 2 out. 2026. Disponível em: https://www.gov.br/sped/pt-br/assuntos/documentos-fiscais/dere/manuais-e-documentos-tecnicos/versao-atual-1/01-manual-usuario-dere-declaracao-de-regimes-especificos-v-1-3-0.pdf/@@display-file/file. Acesso em: 8 out. 2026.
0 comentário(s)