A Reforma Tributária do Consumo costuma ser discutida em termos amplos, como IBS, CBS, regras de transição e documentos eletrônicos. Para quem desenvolve ou mantém um ERP, porém, a mudança ganha forma em pontos bastante concretos: origem de um campo, regra de cálculo, seleção de fundamento legal, arquivo anexado e histórico de transmissão. Na importação, a Duimp mostra com clareza essa dimensão operacional.
A orientação da Receita Federal para a Reforma Tributária do Consumo na Duimp informa que as alterações foram disponibilizadas em produção em 27 de setembro de 2026 e que já estavam acessíveis no ambiente de Treinamento/Validação. Entre os elementos descritos estão o local da operação de consumo, o cálculo de CBS e IBS por item, campos adicionais que podem compor a base de cálculo e os totais apresentados no resumo da declaração.
Isso não autoriza conclusões sobre qualquer efeito jurídico ou econômico de um dado incorreto. As fontes analisadas não permitem afirmar, por exemplo, que toda falha cadastral resulte automaticamente em imposto incorreto, perda de crédito, autuação ou responsabilidade para uma parte específica da operação. O ponto verificável é outro: há informações estruturadas, regras de preenchimento e evidências documentais que precisam ser tratadas pelo processo e pelo sistema.
Este artigo percorre o que está confirmado para a Duimp, como separar versão publicada de expectativa, quais controles um ERP pode implementar e como desenvolvedores Delphi e profissionais contábeis podem testar a integração de maneira auditável.
O que a orientação oficial confirma para a Duimp
A página da Receita Federal dedicada à RTC na Duimp descreve requisitos operacionais já relevantes para a preparação de software e processos. O primeiro é a informação de UF e município do local da operação de consumo, destinada à tributação relativa à CBS e ao IBS. O segundo é o cálculo dos tributos da RTC por item da declaração. No resumo, a orientação informa a apresentação de totais de CBS, IBS estadual e IBS municipal.
Esses pontos merecem leitura cuidadosa. A presença de cálculo por item não significa que a equipe de ERP possa reduzir o trabalho a um total por declaração. Ao contrário: se o sistema interno consolida valores, ele precisa conseguir demonstrar como cada total foi formado a partir dos itens, das informações da operação e das regras vigentes na versão utilizada. Essa é uma necessidade técnica de reconciliação; não é uma tese sobre consequências tributárias além das descritas pela fonte.
Há ainda um requisito objetivo de documentação. Quando existirem valores diferentes de zero nos campos adicionais que compõem a base de cálculo de CBS e IBS e que não sejam obtidos automaticamente da Duimp, a memória de cálculo deve ser juntada ao dossiê vinculado à declaração. Portanto, a memória não deve ser vista somente como um relatório gerencial produzido depois da transmissão. Ela precisa ser tratada como evidência vinculável à operação.
Outro detalhe evita uma implementação equivocada. Na versão documentada pela Receita, o importador não deve preencher cClassTrib: o sistema o define com base no fundamento legal. Para o time técnico, a consequência prática não é ignorar a classificação tributária, mas mudar o foco do controle. A governança deve recair sobre a seleção, a origem, a aprovação e o versionamento do fundamento legal informado, pois é essa escolha que alimenta a definição realizada pelo sistema.
A mesma página esclarece que, em 2026, os valores de CBS e IBS exibidos no resumo de cálculo da Duimp não devem ser recolhidos. Esse esclarecimento é específico para os valores apresentados nesse contexto e nesse ano. Ele não deve ser expandido para afirmar dispensa geral de obrigações, alteração de cronograma ou regra aplicável a outros sistemas e documentos.
Dados fiscais como objetos rastreáveis
Em muitas aplicações, um campo é modelado apenas pelo seu tipo: texto, decimal, data ou chave estrangeira. Para dados fiscais associados à Duimp, essa modelagem é insuficiente como controle operacional. Além do valor, o ERP precisa preservar informações sobre sua procedência e seu contexto de uso.
Uma abordagem útil é tratar cada informação relevante como um objeto rastreável. Para a UF e o município do local da operação de consumo, por exemplo, não basta guardar os códigos e as descrições. É recomendável registrar de qual cadastro, documento ou etapa operacional eles vieram; qual usuário ou rotina os definiu; quando isso ocorreu; e se o dado foi alterado antes de uma transmissão ou retificação.
O mesmo raciocínio vale para os componentes adicionais da base de cálculo. Se o valor não é obtido automaticamente da Duimp e for diferente de zero, haverá necessidade de memória de cálculo no dossiê. Assim, um campo calculado internamente deve manter ligação clara com a evidência que explica sua formação. Na prática, isso aproxima o modelo de dados do modelo de auditoria: cada valor relevante precisa poder ser reencontrado, explicado e associado a uma versão de regra.
Matriz de campos, responsabilidades e evidências
Uma matriz de governança é uma forma simples de organizar essa necessidade. Ela não substitui a orientação oficial nem decide o tratamento tributário de uma operação. Sua função é transformar requisitos conhecidos em responsabilidades verificáveis dentro do ERP e da área fiscal.
Para cada campo ou grupo de campos, a matriz pode conter:
- nome funcional da informação e sua representação no banco ou no payload de integração;
- origem do dado, como cadastro, documento operacional, cálculo interno ou retorno da Duimp;
- responsável pela manutenção e responsável pela aprovação fiscal;
- regra de validação implementada e referência à versão que a motivou;
- documento ou memória de cálculo que sustenta valores não automáticos;
- identificador da transmissão, retificação ou evento relacionado;
- período de vigência da regra no sistema e situação da versão.
Considere o fundamento legal. Mesmo que cClassTrib seja definido pelo sistema da Duimp, o ERP pode registrar o fundamento efetivamente selecionado, a data da seleção, o usuário ou processo que a realizou e a versão da tabela interna de correspondência usada como apoio. Isso permite explicar o estado da operação sem tentar reproduzir no ERP uma regra que a orientação atribui ao sistema da Duimp.
Para equipes Delphi, a matriz também ajuda a separar responsabilidades entre camadas. A interface deve orientar o usuário e impedir inconsistências que a empresa decidiu controlar. O domínio deve registrar regras, versões e estados. A integração deve conservar o payload enviado, a resposta recebida e os identificadores necessários à conciliação. Já o repositório documental deve manter a memória de cálculo acessível a partir da operação correspondente.
Versionamento não é apenas controle de código
Em projetos de software, Git, branches e tags resolvem parte do problema: permitem saber qual código foi implantado. No contexto fiscal, porém, a versão do executável não basta. Também precisam ser identificáveis as tabelas, os parâmetros, os textos de fundamento legal, os modelos de memória de cálculo e as configurações de integração usados em uma transmissão.
Uma solução prática é definir uma entidade de versão fiscal. Ela pode reunir identificador, data de ativação, fonte de referência, responsável pela aprovação e escopo afetado. O objetivo não é criar burocracia sem utilidade, mas responder a perguntas operacionais: qual configuração estava ativa quando a declaração foi preparada? A memória de cálculo foi gerada pela mesma regra registrada no ERP? Uma alteração posterior de cadastro mudou dados de uma operação já transmitida?
Esse desenho também favorece uma distinção essencial: versão publicada não é previsão, e disponibilidade em ambiente de testes não é, por si só, regra permanente para qualquer cenário. A orientação oficial informa a existência das alterações em Treinamento/Validação e em produção nas datas mencionadas. A equipe deve usar esse fato para testar e revisar sua integração, sem extrapolar a fonte para anunciar leiautes futuros, prazos não confirmados ou comportamentos que não constem da documentação vigente.
Fundamento legal e classificação: controle sem preenchimento indevido
A regra informada para cClassTrib é especialmente importante porque combate um erro comum de desenho: transformar toda informação exibida por uma integração em campo editável do usuário. Segundo a orientação da Receita, nessa versão o importador não deve preencher cClassTrib, pois o sistema o define com base no fundamento legal.
Logo, uma tela que exija o preenchimento manual de cClassTrib para a Duimp estaria desalinhada dessa orientação. Isso não significa, contudo, que o ERP deva ocultar o contexto da classificação. Uma alternativa mais segura é apresentar o campo como resultado informativo quando ele estiver disponível e concentrar a edição, as validações e a trilha de auditoria no fundamento legal aplicável à operação.
A tabela de correspondência entre fundamento legal e classificação, mencionada nas limitações da pesquisa, não deve ser copiada para o código como se fosse imutável. A própria documentação pode receber atualização. Em vez de constantes distribuídas em formulários, unidades Delphi e procedures, prefira uma estrutura parametrizável, com versão, vigência e mecanismo formal de publicação interna.
A contabilidade participa desse processo ao validar a interpretação e a seleção do fundamento legal dentro do fluxo adotado pela empresa. O desenvolvimento, por sua vez, deve garantir que a escolha aprovada se converta em dados consistentes na integração, seja registrada e possa ser recuperada posteriormente. Não se trata de transferir uma atribuição para a outra área, mas de tornar visível onde começa e termina cada responsabilidade.
Limitações e fronteiras da evidência
A preparação responsável depende tanto do que está confirmado quanto do que ainda não foi comprovado. Nas fontes primárias analisadas, não foi localizado um novo leiaute da Duimp publicado ou previsto para 3 de novembro de 2026. Como essa data estava no futuro no momento da pesquisa, ela não pode ser apresentada como disponibilidade, vigência ou obrigatoriedade.
Também não há confirmação, nas fontes fornecidas, de 1º de janeiro de 2027 como prazo específico da Duimp. Esse marco não deve ser usado como cronograma da declaração de importação sem nova consulta a texto oficial acessível e aplicável ao tema.
O Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, estabelece datas de início da obrigatoriedade de emissão de documentos fiscais eletrônicos previstas nos regulamentos do IBS e da CBS. Ele é referência de cronograma para DF-e, mas não prova requisito técnico particular da Duimp. Da mesma forma, a comunicação sobre adiamento de validações de determinados documentos fiscais eletrônicos não deve ser estendida à Duimp, porque ela não é listada naquele comunicado.
Por fim, a página da Duimp consultada foi atualizada em 6 de outubro de 2026. Antes de implantar ou publicar orientações técnicas, vale reabrir a documentação oficial, conferir versões posteriores e registrar a URL, a data de consulta, o ambiente e a vigência de cada requisito adotado.
Aplicação prática
A seguir está um roteiro para transformar as evidências disponíveis em decisões concretas de arquitetura, configuração e homologação.
1. Faça um inventário orientado à transmissão
Liste os dados do ERP que participam da preparação da Duimp: itens, local da operação de consumo, fundamento legal, componentes adicionais de base e documentos de suporte. Para cada um, identifique se a informação nasce no cadastro, em documento operacional, em cálculo interno ou em interação com a própria Duimp.
Evite começar pelo layout de tela. Comece pela pergunta: “consigo demonstrar a origem deste valor depois que a declaração for transmitida?”. Se a resposta for negativa, falta um vínculo de dados, uma trilha de alteração ou uma evidência documental.
2. Crie a matriz campo → origem → regra → evidência
Formalize a matriz de governança com os responsáveis técnico e fiscal. Para os campos adicionais da base de CBS e IBS que não sejam obtidos automaticamente, inclua uma regra objetiva: se o valor for diferente de zero, a operação deve apontar para a memória de cálculo a ser juntada ao dossiê. O ERP pode controlar a existência do documento e seu vínculo; a validação de conteúdo deve seguir o procedimento interno e a orientação oficial vigente.
Registre também a situação de cada informação: pendente, validada, bloqueada para transmissão, transmitida ou retificada. Essa modelagem reduz o risco de uma alteração silenciosa em cadastro afetar uma operação já preparada sem deixar histórico.
3. Versione parâmetros e decisões fiscais
Crie uma versão fiscal para regras e tabelas usadas pela integração. A alteração de um fundamento legal, de uma parametrização ou de uma lógica de cálculo deve gerar identificador, data de ativação e responsável pela aprovação. Em Delphi, esse controle pode ser centralizado em tabelas de parametrização e serviços de domínio, evitando regras espalhadas pela interface.
Ao gerar uma transmissão, grave o identificador da versão fiscal junto com o payload e com os dados apresentados ao usuário. Em caso de retificação, preserve a referência à transmissão anterior e à nova versão utilizada. Não sobrescreva o histórico como se a operação nunca tivesse passado pelo estado anterior.
4. Homologue cenários com foco em reconciliação
Como as alterações foram disponibilizadas no ambiente de Treinamento/Validação antes da produção, esse ambiente deve ser usado para validar o fluxo completo. Monte cenários que cubram itens com diferentes dados de local de consumo, itens com valores adicionais de base iguais a zero e diferentes de zero, e seleções de fundamento legal compatíveis com o processo da empresa.
O objetivo do teste não é presumir resultados não documentados. É conferir se o ERP conserva os valores por item, se o local de consumo enviado corresponde à origem registrada, se a seleção do fundamento legal fica auditável, se a memória de cálculo é vinculada quando necessária e se os totais retornados podem ser conciliados com os itens da declaração.
5. Estabeleça uma revisão conjunta antes da produção
A revisão deve envolver desenvolvimento, fiscal, contabilidade e operação de importação. O time técnico confirma dados, versões, logs e anexos. A área fiscal avalia a seleção e a documentação que sustenta a operação. A operação confirma se a informação representa o fluxo real de importação.
Ao final, arquive uma evidência da revisão e mantenha a referência da documentação oficial consultada. Essa disciplina não garante, por si só, qualquer resultado tributário; ela cria condições para que a empresa saiba o que enviou, com base em qual regra e com qual documentação.
Conclusão
A Duimp oferece um exemplo operacional claro de como a Reforma Tributária do Consumo alcança o desenho de dados do ERP. A orientação oficial confirma a presença de informação sobre o local de consumo, cálculo de CBS e IBS por item, totais no resumo, exigência de memória de cálculo em situações determinadas e definição de cClassTrib pelo sistema com base no fundamento legal.
Para desenvolvedores Delphi e profissionais de contabilidade, a resposta não deve ser preencher mais campos indiscriminadamente. O caminho mais consistente é organizar a origem do dado, o responsável, a versão de regra, a evidência documental e o histórico de transmissão. Dessa forma, o ERP passa a sustentar uma integração verificável, em vez de apenas produzir um envio.
A recomendação final é manter o escopo ligado ao que foi efetivamente publicado. Antes de cada implantação, valide a documentação vigente, trate novas versões como novas versões — e não como continuação automática do comportamento anterior — e separe requisitos confirmados de hipóteses sobre cronogramas ou efeitos jurídicos. Essa distinção é parte essencial da governança técnica e fiscal.
Referências
COMITÊ GESTOR DO IBS. Atos Conjuntos. [S. l.], 2026. Disponível em: https://www.cgibs.gov.br/atos-conjuntos. Acesso em: 2 nov. 2026.
RECEITA FEDERAL DO BRASIL. Atos Conjuntos — Reforma Tributária do Consumo. [S. l.], 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/reforma-tributaria-do-consumo/legislacao/atos-conjuntos/. Acesso em: 2 nov. 2026.
RECEITA FEDERAL DO BRASIL. Reforma Tributária do Consumo — Duimp. [S. l.], 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/manuais/despacho-de-importacao/sistemas/duimp/rtc. Acesso em: 2 nov. 2026.
RECEITA FEDERAL DO BRASIL; COMITÊ GESTOR DO IBS. Receita Federal e CGIBS esclarecem adiamento das regras de validação dos documentos fiscais eletrônicos. [S. l.], 6 ago. 2026. Disponível em: https://www.cgibs.gov.br/receita-federal-e-comite-gestor-do-ibs-esclarecem-adiamento-das-regras-de-validacao-dos-documentos-fiscais-eletronicos. Acesso em: 2 nov. 2026.
0 comentário(s)