Rejeição 931: histórico da I05f-20 e compatibilidade entre cBenef e CST
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
Esta página trata da I05f-20, regra histórica com código 931 que comparava o tipo de benefício informado em cBenef com o CST do item. A linha foi retirada na revisão 1.10 da NT 2019.001 e permanece rasurada. Há outras identidades com código 931, inclusive N12-88, também histórica, e N12-94, de uso atual conforme a UF. O código isolado não distingue essas verificações.
O sentido da verificação antiga
O MOC 7.0, Anexo I, p. 91 conserva a I05f-20 em rasura. Sua condição começava pela presença de det/prod/cBenef e examinava se o tipo de benefício correspondia ao CST com benefício fiscal. O exemplo oficial era a correspondência entre código de isenção e CST de isenção. A implementação era facultativa, por UF e modelo 55/65.
Esse exemplo descrevia uma relação a verificar, não uma instrução para escolher isenção. cBenef identifica um benefício da UF; o CST fica no grupo de ICMS de det/imposto/ICMS. Estarem no mesmo item é necessário para a comparação: usar o benefício do item seguinte ou de outro produto pode produzir uma associação indevida.
Como a documentação foi reorganizada
A NT 2019.001 v1.10 histórica, pp. 4–5 e 11 explica os ajustes e nomes das regras e já mostra I05f-20 rasurada. O cronograma geral dessa revisão é testes até 22/07/2019 e produção em 02/09/2019. As ativações posteriores são específicas por regra e UF.
Na NT 2019.001 v1.70, pp. 16 e 18, I05f-20 continua retirada. A N12-94 verifica código de benefício informado e CST segundo a tabela da Fazenda da UF, com implementação a critério da UF, por modelo e CST, e retorna 931 com descrição de incompatibilidade entre benefício, CST e UF. A palavra referente a verificar vigência está rasurada nessa linha atual; não deve ser revivida como parte da condição de N12-94. Existência e vigência têm verificação própria na N12-98, mensagem 946.
As exceções da N12-94 incluem devolução interestadual ou com exterior e, conforme ativação da UF, devolução em geral, ajuste e entrada. Para alguns CST sem benefício, a UF pode exigir o literal SEM CBENEF segundo sua tabela; esse texto não é um código genérico que se possa inserir para afastar a crítica.
Exemplo: código existente, associação de item incorreta
Dois itens possuem tratamentos fiscais já definidos e benefícios próprios. Um importador associa a ambos o cBenef do primeiro item. O fato de o código existir não demonstra compatibilidade com o CST do segundo. A investigação compara cada par item, CST e benefício, com a tabela da mesma UF e os documentos de suporte; não muda o CST para combinar com o código copiado.
Em um retorno atual, uma aplicação pode exibir o nome I05f-20 porque sua tabela de mensagens é antiga. Antes de concluir que o autorizador executa uma regra removida, confirme o texto integral, o item e a condição real. Se for N12-94, sua aplicação por UF e suas exceções precisam ser verificadas.
O exemplo é textual porque o benefício aplicável depende da operação e do fundamento fiscal. Um XML com código inventado ou CST sugerido não demonstraria a compatibilidade real.
O que encaminhar para confirmação
Reúna envio, retorno, UF, modelo, ambiente, item e versão do emissor. Preserve a tabela fiscal consultada, com versão e data, e os dados reais da operação. O responsável fiscal confirma CST, benefício e fundamento; o trabalho técnico confere se os dados confirmados chegaram ao mesmo item do XML.
Não remova benefício verdadeiro, não altere CST ou empresa para contornar a validação e não edite XML assinado. Preserve documentos autorizados e esclareça tentativas de resultado incerto antes de novo envio.