Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · ICMS

adRemICMSDif no ICMS53: campo revogado ainda no XSD

<adRemICMSDif>det › imposto › ICMS › ICMS53 › adRemICMSDif

Revisão editorial em 14 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

adRemICMSDif é um campo legado do ICMS53, originalmente descrito como alíquota ad rem do imposto diferido. A NT 2023.001 o revogou na versão 1.20. Sua declaração continua no PL 010f_v1.04, o que explica sua presença em catálogos e validadores, mas não restaura a orientação fiscal de uso.

Caminho desta página: /nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS53/adRemICMSDif. O prefixo nfeProc identifica o XML processado; no XML da NF-e antes do protocolo, o percurso começa em NFe. O campo pertence ao item det, não aos totais.

Neste artigo

O que a Nota Técnica revogou?

A versão 1.20 da NT 2023.001 revogou qBCMonoDif e adRemICMSDif e criou a representação com qBCMono, adRemICMS, vICMSMonoOp, pDif e vICMSMono; vICMSMonoDif continua representando a parcela diferida. A seção 2.6.2 da versão 1.60 registra a alteração; a tabela da p. 24 conserva os dois campos antigos tachados em vermelho.

O PL 010f_v1.04 ainda declara os campos antigos como opcionais. Portanto, um validador XSD pode aceitá-los sem demonstrar que seu uso está fiscalmente vigente. Ao ler XML legado, preserve documento, data e versão; ao ajustar um gerador, revise sua regra de mapeamento e use os dados reais para construir a representação atual. Não basta renomear tags nem apagar campos de um XML assinado. Fonte: NT 2023.001 v 1.60, p. 15 e p. 24; pacote oficial PL 010f, alternativa ICMS53.

Por que o validador XSD ainda aceita a tag?

No pacote oficial PL 010f, adRemICMSDif permanece como elemento opcional do tipo TDec_0302a04, depois de qBCMonoDif, no fim da sequência ICMS53. A validação de esquema responde se o elemento, sua posição e seu texto se ajustam ao arquivo XSD. Ela não lê sozinha a rasura de uma Nota Técnica nem comprova autorização fiscal.

O tipo aceita até 3 dígitos inteiros e, quando houver parte decimal,2 a 4 casas. O formato 1.5000 pode passar nessa checagem. Isso é uma propriedade técnica do legado, não alíquota recomendada nem modelo de emissão. A distinção evita duas conclusões erradas: tag aceita pelo XSD não significa tag fiscalmente atual; tag legada encontrada em arquivo não prova por si só fraude ou rejeição daquele documento.

Como o diferimento é representado atualmente?

A alíquota ad rem atual fica em adRemICMS, sobre a quantidade qBCMono. O produto desses campos forma vICMSMonoOp, imposto sem diferimento. O percentual pDif determina vICMSMonoDif; a diferença forma vICMSMono. Assim o diferimento parcial é descrito por percentual e valores monetários, sem exigir uma segunda alíquota antiga.

Com hipóteses fictícias de 1.000 unidades, ad rem 1,5000 e diferimento 40%, o imposto da operação é 1.500,00, o diferido 600,00 e o devido 900,00. Em 100%, o diferido é 1.500,00 e o devido 0,00. Não interprete a alíquota legada como 40% nem a substitua pelo percentual por simples renomeação. A documentação original, a unidade e o enquadramento precisam explicar os dados antes de um novo mapeamento. Fonte: NT 2023.001 v 1.60, p. 24.

Qual exemplo pode orientar uma integração nova?

O trecho abaixo mostra a representação atual, com parâmetros fictícios, sem incluir a tag revogada. É parcial em relação à NF-e e não está pronto para transmissão:

<ICMS53 xmlns="http://www.portalfiscal.inf.br/nfe">
  <orig>0</orig>
  <CST>53</CST>
  <qBCMono>1000.0000</qBCMono>
  <adRemICMS>1.5000</adRemICMS>
  <vICMSMonoOp>1500.00</vICMSMonoOp>
  <pDif>40.0000</pDif>
  <vICMSMonoDif>600.00</vICMSMonoDif>
  <vICMSMono>900.00</vICMSMono>
</ICMS53>

Em uma inspeção histórica, o leitor pode localizar o elemento pelo XPath desta página e registrar seu conteúdo sem regravar o documento. Ao gerar um novo XML a partir de um sistema antigo, a mudança envolve origem dos dados e cálculo das parcelas; não é uma operação de apagar adRemICMSDif de um arquivo assinado. A estrutura do exemplo precisa ainda ser combinada com modelo, produto e operação compatíveis.

Como investigar a presença do campo em um sistema?

Identifique se a ocorrência vem do XML original, de um catálogo XSD ou de um objeto interno que nem chega a ser serializado. Anote data de emissão, versão do gerador, versão do esquema, modelo e o item. No catálogo, a presença é esperada pelo PL 010f; no gerador atual, examine o ramo que produz a tag antiga e sua relação com o parâmetro de diferimento.

Compare o cálculo com qBCMono, adRemICMS, vICMSMonoOp, pDif, vICMSMonoDif e vICMSMono. Não infira a situação fiscal apenas da data do arquivo nem converta dados ausentes em zero. A NT registra 20/04/2023 em homologação e 01/05/2023 em produção para a criação da representação do diferimento parcial; esse cronograma não prova como cada XML histórico foi autorizado. Confirme os parâmetros com o responsável contábil e teste o mapeamento em documento de desenvolvimento antes de qualquer envio. Fonte: NT 2023.001 v 1.60, pp. 6, 15, 24.

Fontes oficiais

Leituras relacionadas

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS53/adRemICMSDif
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
0–1 no contexto do elemento pai
Tipo
TDec_0302a04 · string
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

pattern
0|0\.[0-9]{2,4}|[1-9]{1}[0-9]{0,2}(\.[0-9]{2,4})?
whiteSpace
preserve