Voltar para o blog

NF-e

Rejeição 1053: confira por que o código de crédito não permite IBS

Se o emissor recebeu a rejeição 1053, confira o código de crédito presumido do item antes de retirar valores ou mudar sua tributação. O XML levou um grupo de crédito presumido de IBS que o código escolhido não admite. A correção depende de descobrir se o grupo foi gerado sem necessidade ou se o código selecionado…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 1053: confira por que o código de crédito não permite IBS.

Se o emissor recebeu a rejeição 1053, confira o código de crédito presumido do item antes de retirar valores ou mudar sua tributação. O XML levou um grupo de crédito presumido de IBS que o código escolhido não admite. A correção depende de descobrir se o grupo foi gerado sem necessidade ou se o código selecionado está errado para a operação.

A mensagem é “Rejeição: Crédito Presumido para o IBS informado indevidamente [nItem: 999]”. O número indicado identifica o item afetado; 999 é a representação usada na documentação. Guarde a resposta completa, pois o mesmo retorno pode vir da autorização da nota ou do registro de um evento.

Primeiro identifique o documento e o serviço

Na autorização da NF-e, modelo 55, a regra UB123-10 compara o código cCredPres da operação com seu indicador ind_gIBSCredPres. Quando esse indicador é 0, o grupo IBSCBS/gCredPresOper/gIBSCredPres não deve estar presente. A regra está na página 66 da NT 2025.002-RTC v1.52.

No evento 211110, Solicitação de Apropriação de crédito presumido, a regra 2P26-10 faz a mesma verificação sobre gCredPresOper/gIBSCredPres, na página 77. A página 76 define NF-e 55 e autoria pelo emitente ou destinatário, conforme a situação descrita. Confira a chave referenciada, o item e a identidade do autor. Uma rejeição do evento não permite concluir que a NF-e original perdeu sua autorização.

Não transporte este procedimento para NFC-e 65. Na versão consultada, a UB120-10 e a 2P12-10 vedam o crédito presumido nesse modelo e apontam o retorno 1049. Uma permissão exibida em tabela compartilhada entre documentos não afasta a regra específica da NF-e/NFC-e.

O código de crédito não é o CST

O cCredPres identifica a hipótese do crédito presumido. O CST e o cClassTrib identificam a tributação do item e têm verificações próprias. Para a 1053, o indicador determinante é aquele associado ao código de crédito, não uma escolha livre de CST que permita preencher IBS.

Há outra distinção útil: ind_gCredPresOper=1, relacionado ao cClassTrib, permite o grupo geral da operação, sem exigir seu uso. Isso não significa que todos os códigos dentro desse grupo admitam IBS e CBS simultaneamente. Primeiro se verifica a operação e sua classificação; depois, o código de crédito e os subgrupos correspondentes.

A tabela oficial consultada em 10/10/2026 mostra hipóteses específicas para um só tributo. Os códigos 5 e 6, por exemplo, aparecem ligados a crédito automotivo de CBS, sem aplicação de IBS. Esse registro não estabelece que sua empresa pertence ao regime nem autoriza aproveitar o benefício hoje: a tabela também contém datas próprias de vigência, inclusive futuras.

Como encontrar a origem do preenchimento indevido

Reúna o XML enviado, o retorno, a chave, o ambiente e a versão do emissor. Compare o item apontado com a linha correspondente na tabela oficial. Registre o código realmente transmitido, seu significado, o indicador de IBS e se a hipótese prevê apropriação no documento ou por evento.

Depois verifique a origem dos dados no sistema. Uma configuração copiada pode preencher IBS e CBS para qualquer código. Outra causa possível é a troca de código de crédito sem remover o subgrupo que acompanhava a escolha anterior. Integrações também podem usar uma tabela antiga ou confundir o código interno do cadastro com o valor fiscal.

Não basta olhar o valor exibido na tela. Um grupo com valor zero continua sendo um grupo presente; a UB123-10 trata da inclusão indevida, não apenas do montante. Compare o XML final para confirmar se a configuração realmente deixou de gerar o elemento.

Corrija conforme a causa comprovada

O código está correto e não admite IBS. Após confirmação fiscal, ajuste a geração para não incluir gIBSCredPres naquele contexto. Preserve outros grupos que sejam efetivamente necessários, inclusive CBS quando cabível. Evite apagar todo o grupo da operação sem conferir sua função e os demais campos.

O código não corresponde à operação. O responsável fiscal deve identificar a hipótese verdadeira e sua vigência. Corrija a seleção com base nessa análise e regenere os subgrupos conforme os indicadores da linha correta. Não escolha outro número só porque ele deixa a rejeição desaparecer.

O cadastro está correto, mas o XML diverge. Encaminhe ao suporte a comparação entre configuração, tabela e arquivo transmitido. A correção deve alcançar o mapeamento ou a montagem do XML. Na nota rejeitada, gere e assine novamente pelo fluxo do emissor, sem modificar manualmente um arquivo já assinado.

O retorno veio do evento. Trabalhe no XML do evento 211110 e no item da NF-e referenciada. Confirme que a hipótese aceita apropriação por evento e que o autor corresponde ao emitente ou destinatário previsto. Não cancele nem reemita a nota original apenas para tratar esse retorno.

Exemplo de teste, sem antecipar benefício fiscal

Uma empresa prepara em homologação um cenário futuro do regime automotivo. A análise fiscal seleciona o código 5, cuja tabela consultada indica CBS e não IBS, com início de vigência de CBS em 01/01/2027. O emissor copia uma configuração genérica e acrescenta também gIBSCredPres ao item 2.

Se o ambiente executar a UB123-10, essa combinação pode receber 1053. A equipe compara a hipótese aprovada com o XML, corrige a montagem para excluir o subgrupo indevido e preserva o restante do cenário validado. O teste demonstra a estrutura; não comprova elegibilidade da empresa nem permite apropriação antecipada em produção.

Cronograma e conferência do resultado

Esta revisão usa a v1.52, publicada no portal em 01/10/2026. As regras de crédito já constavam de versões anteriores; a UB123-10 e o leiaute do evento tiveram alterações na v1.40. O aviso ENCAT de 05/10/2026 adiou a implantação da v1.52 para 26/10 em homologação e 16/11 em produção. Ele não suspende automaticamente todas as regras herdadas. A leitura documental não confirma ativação em cada UF/autorizador.

Após a correção, confira o novo XML e leia o retorno no mesmo ambiente e serviço. Na autorização, preserve o protocolo correspondente à chave se houver autorização. No evento, confirme o resultado individual e seu vínculo com a nota. Procure a contabilidade se faltar fundamento para o crédito; acione o suporte ou o autorizador se tabela, hipótese e XML estiverem coerentes e a divergência persistir.

Fontes

Consulta e revisão documental por IA: 10/10/2026. Sem teste de emissão em UF/autorizador específico.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.