Rejeição 816: confira o ICMS interestadual destinado à UF do remetente

A rejeição 816 informa que o valor do ICMS interestadual destinado à UF do remetente, enviado no item da NF-e, difere do cálculo esperado pelo autorizador. O campo conferido é vICMSUFRemet. A resposta pode identificar o item em nItem e apresentar o valor informado e o calculado, permitindo localizar a divergência sem alterar indiscriminadamente todos os produtos.

O diagnóstico precisa considerar a versão da regra. A NT 2020.005 v1.21 corrigiu a documentação da NA17-10 e trouxe condições que nem todos os tutoriais reproduzem. Utilizar uma fórmula antiga ou mudar somente o valor final pode esconder um problema nas bases, nas alíquotas ou na partilha.

Quando a regra se aplica

Na página 19 dessa nota técnica, a NA17-10 está classificada como obrigatória para NF-e, modelo 55, quando o CST do ICMS é 00 e o grupo ICMSUFDest foi informado. Existe uma exceção expressa: a regra não se aplica à nota fiscal de entrada, identificada por tpNF=0.

Isso não autoriza trocar CST, tipo de operação ou modelo para evitar a rejeição. Esses campos devem representar a operação efetiva. Se o retorno parecer incompatível com essas condições, reúna o XML transmitido, a resposta integral, a versão utilizada e a identificação do ambiente para análise técnica.

Também não basta encontrar um campo no leiaute para concluir que ele pode ser usado em qualquer documento. A NT 2026.002 v1.11 trata, pela regra 807, do grupo ICMSUFDest informado em NFC-e ou NF-e com DANFE Simplificado Tipo 2, tpImp=6. Essa é outra validação; não amplia o alcance da 816 nem transforma a troca do formato de impressão em solução.

Como conferir a conta

A fórmula documentada para a parcela do remetente é:

((vBCUFDest × pICMSUFDest) − (vBC × pICMSInter)) − vICMSUFDest

Os percentuais precisam ser convertidos corretamente no cálculo: uma alíquota de 18% corresponde a 0,18, por exemplo. vBCUFDest é a base da UF de destino; vBC é a base do ICMS do item. A fórmula atual usa essas duas bases, que não devem ser tratadas automaticamente como iguais.

pICMSUFDest representa a alíquota interna de destino e pICMSInter, a interestadual. O valor vICMSUFDest, ao final da expressão, corresponde à parcela já destinada à outra UF. Portanto, sua apuração também precisa estar coerente: um erro do lado do destino pode repercutir na conferência do remetente.

Se o resultado for negativo, a regra determina informar 0.00. Havendo benefício de redução da base no destino, a respectiva base deve considerar esse benefício. Não aplique uma redução presumida nem escolha uma alíquota apenas porque o cálculo passa; confirme o enquadramento com a contabilidade.

A nota de rodapé prevê arredondar o resultado da multiplicação para duas casas decimais e considerar tolerância de R$ 0,01 para mais ou para menos na validação. Essa margem serve à comparação técnica; não permite ajustar valores sem fundamento ou adotar qualquer método de arredondamento como se fosse obrigatório em todos os cálculos fiscais.

Atenção aos exemplos antigos de partilha

O leiaute registra a evolução da partilha para o destino: 40% em 2016, 60% em 2017, 80% em 2018 e 100% a partir de 2019. Por isso, uma nota normal atual não deve herdar automaticamente a parcela de origem de um exemplo de 2016.

Há uma particularidade na regra própria do percentual, NA11-10: em finalidades diferentes da normal ou em CFOP de retorno de mercadorias, ela considera o ano da nota referenciada. Essa previsão não elimina a exceção das notas de entrada da NA17-10. São verificações distintas, e uma devolução exige avaliar seus dados concretos antes de reaproveitar a tributação anterior.

Considere um exemplo exclusivamente didático: bases de origem e destino de R$ 1.000,00, alíquotas hipotéticas de 12% e 18%, respectivamente, e parcela de destino corretamente apurada em R$ 60,00. A conferência resulta em (180,00 − 120,00) − 60,00 = 0,00. Se o sistema carregar R$ 24,00 para o remetente, haverá uma diferença de R$ 24,00. Os números ilustram o raciocínio; não indicam as alíquotas de uma operação real.

Como corrigir com segurança

1. Guarde o XML enviado e o retorno completo. Confira se o item apontado corresponde ao produto que você está examinando e se a rejeição realmente é 816.

2. Verifique modelo, CST, presença de ICMSUFDest, tipo de operação e finalidade. Confirme também se a aplicação do grupo faz sentido para a operação.

3. Confira as bases e as alíquotas na origem dos dados. Observe benefícios fiscais comprovados, a partilha aplicável e o cálculo da parcela de destino. O FCP tem campos próprios e não deve ser somado indevidamente à alíquota interna usada nesta conta.

4. Corrija a configuração ou o lançamento que produziu a divergência. Depois, gere novamente o XML pelo fluxo normal do emissor e confira o item e os totais relacionados antes de transmitir.

5. Examine a nova resposta. A correção desta diferença não garante autorização, pois outras regras continuam sendo verificadas.

Evite editar manualmente o XML assinado ou retirar o grupo apenas para eliminar a mensagem. Alterações precisam manter os fatos e a documentação fiscal. Se houver dúvida sobre um envio anterior sem resposta, consulte sua situação antes de criar outra nota ou repetir a operação.

Quando encaminhar ao suporte

Se a conta continuar divergindo, encaminhe por canal seguro a chave, o item, os valores informado e calculado, as bases, as alíquotas, a partilha, o ambiente e a versão do emissor. Informe se é entrada, saída, devolução ou retorno e apresente a referência fiscal quando pertinente.

Não envie senha ou arquivo do certificado digital. O suporte pode rastrear de onde o sistema obtém cada campo, enquanto a contabilidade confirma o tratamento tributário. Este guia não pressupõe menus específicos do ALRA nem comprova a configuração de uma UF ou contribuinte. A rejeição 815 verifica a parcela de destino; a 816 trata da parcela do remetente no item.

Fontes e limites da consulta

Consulta documental em 16/10/2026: NT 2020.005 v1.21, páginas 4–5 e 19; MOC 7.0, Anexo I, páginas 49 e 117; declaração ICMSUFDest do schema PL010f; NT 2026.002 v1.11, páginas 3 e 17. O MOC conserva fórmula anterior e indicação de implementação futura; o cotejo utiliza a correção posterior da NT, cujo cronograma histórico informa homologação até 20/10/2021 e produção até 25/10/2021. Não houve teste no autorizador.

Foram lidos os corpos específicos de SIGE Cloud, Berga e InvoiSys. Fórmula simplificada, identificação incorreta de campo, percentuais históricos e promessas de correção automática foram confrontados com as primárias, sem reproduzir seus menus ou imagens.