Rejeição 601 na NF-e: como conferir o total do Imposto de Importação

A rejeição 601 informa que o total do Imposto de Importação da NF-e não corresponde à soma desse imposto nos itens. A primeira providência é comparar o XML transmitido com os valores da operação e com o detalhamento da importação. Corrigir somente o número apresentado na tela, sem descobrir de onde veio a diferença, pode deixar a nota coerente na soma e errada no conteúdo fiscal.

O retorno tratado aqui é “Total do II difere do somatório dos itens”, na autorização da NF-e modelo 55. O II é o Imposto de Importação. Ele não representa o custo completo da mercadoria importada, a base do ICMS nem o total de tributos da nota.

Quais valores precisam fechar

A regra W11-10 compara o campo total/ICMSTot/vII, identificado como W11, com os valores det/imposto/II/vII, identificados como P04. Cada det representa um item. Assim, a conferência é entre o total de II e os valores de II efetivamente informados nos respectivos itens. A regra consta do MOC 7.0, página 121.

Dentro do grupo II também existem vBC, vDespAdu e vIOF. Eles registram, respectivamente, a base do imposto, despesas aduaneiras e IOF. Nenhum deles substitui P04 nessa soma. Um relatório que reúna todos os custos da importação pode ser útil para a gestão, mas não reproduz necessariamente o cálculo da rejeição 601.

O leiaute orienta informar o grupo II quando o item estiver sujeito a esse imposto. Itens sem esse grupo não fornecem um vII para a soma; isso não autoriza apagar o grupo de um item que deveria tê-lo. A ausência de dados de II em certas operações de importação é outro problema, associado à rejeição 599. Tampouco se acrescentam PIS, COFINS, ICMS-ST ou valores de ISSQN à soma do II.

Um exemplo para localizar a diferença

Considere uma NF-e ilustrativa com três itens. Os valores de II registrados são R$ 35,20 no primeiro e R$ 14,80 no segundo. O terceiro não possui II. A soma dos valores informados é R$ 50,00. Se o totalizador vII contiver R$ 60,00, há uma diferença de R$ 10,00 a investigar.

Se os dois valores dos itens estiverem corretos segundo os documentos e a apuração da operação, o total deveria refletir R$ 50,00. Se o valor real devido for R$ 60,00, reduzir o total para obter autorização esconderia um erro nos itens. Nesse caso, é necessário corrigir a origem do cálculo ou da distribuição antes de totalizar novamente. O exemplo mostra apenas a conciliação aritmética, sem indicar alíquota ou enquadramento fiscal.

Por que isso aparece em notas de importação

Uma possibilidade é o total ter sido lançado no cadastro da importação, enquanto os valores individualizados vieram de outra rotina. Também pode haver um item incluído, excluído ou alterado após o cálculo inicial. Quando o sistema conserva o total antigo, o XML fica com duas versões da mesma operação.

Outra hipótese é a distribuição de um valor entre vários itens. Um rateio com centavos exige um critério consistente e rastreável. A orientação da TOTVS para o módulo Varejo Moda mostra a comparação entre o imposto gravado na importação e o somatório dos itens. É uma pista operacional daquele sistema; qualquer ajuste precisa preservar o imposto real e a distribuição fiscal correta.

Também vale comparar o arquivo gerado pelo ERP com aquele efetivamente enviado pelo integrador. Um valor correto na tela pode não ter sido levado ao grupo II do XML final. Não atribua a diferença à assinatura digital sem verificar em que etapa os dados mudaram.

Como corrigir com segurança

1. Guarde o retorno completo da Sefaz e o XML da tentativa rejeitada, com data, modelo e ambiente.

2. Liste os itens e seus vII, separadamente de base, despesas aduaneiras e IOF.

3. Refaça a soma usando os valores monetários enviados, com duas casas decimais.

4. Compare o resultado com W11 e depois confronte ambos com os documentos e cálculos da importação.

5. Corrija no ERP a origem identificada, refaça a distribuição quando cabível e gere novamente o XML pelo fluxo normal do emissor.

6. Confira o novo total de II e os demais totais afetados antes de retransmitir.

A Dynamicca descreve a localização de vII nos totais do XML; a Oobj reforça a conferência do detalhamento. Esses procedimentos ajudam a investigar, mas não substituem a revisão fiscal da operação. Evite editar manualmente uma cópia de análise e reapresentá-la como documento válido.

Centavos e modelos exigem atenção

Os campos monetários de II usam duas casas decimais. Some os valores finais dos itens; não some números internos com mais casas e arredonde apenas no total, sem conferir a política de cálculo do sistema.

Há orientações práticas que mencionam tolerância de um centavo. A linha W11-10 do MOC 7.0 consultado não declara esse limite. Documentação antiga também contém tolerâncias diferentes, que não devem ser importadas automaticamente. Trabalhe para obter a igualdade da soma e peça ao suporte a regra vigente do autorizador se a discussão depender exclusivamente de centavos.

O MOC 7.0 limita W11-10 ao modelo 55. Uma versão histórica da NT 2013.005 ainda mostrava 55/65; a consolidação posterior e o manual já distinguem a NFC-e, que tem validação própria contra o grupo II, P01-10, rejeição 743. Portanto, o título genérico “NF-e/NFC-e” de uma ferramenta não amplia o alcance atual de 601. O identificador antigo GW11 corresponde ao mesmo assunto histórico, não a uma nova rejeição.

A regra é facultativa no MOC, de modo que sua adoção deve ser verificada por UF e ambiente. As cópias oficiais mineiras consultadas a indicam como aplicada, sem permitir generalização nacional. No corpus documental até 09/10/2026 não foi identificada mudança que substitua esta totalização pelos grupos de IBS/CBS. Encerrada a correção, confirme o novo retorno e o protocolo de autorização; o desaparecimento de 601, isoladamente, não comprova autorização.

Base documental: MOC 7.0, páginas 51, 58, 118 e 121; histórico MOC 5.0 e NT 2013.005; NT 2025.002-RTC v1.52, setembro de 2026. Fontes práticas consultadas: TOTVS, Dynamicca e Oobj. Revisão documental em 10/10/2026, sem certificação de ativação universal por UF.