Voltar para o blog

NF-e

Rejeição 572: como corrigir o identificador do evento sem alterar a nota

A rejeição 572 indica que o identificador montado no XML do evento não combina com os próprios campos desse evento. O caminho é revisar a geração do pedido de cancelamento, carta de correção ou outro evento transmitido. Esse retorno, sozinho, não significa que a NF-e original foi rejeitada nem autoriza emitir outra…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 572: como corrigir o identificador do evento sem alterar a nota.

A rejeição 572 indica que o identificador montado no XML do evento não combina com os próprios campos desse evento. O caminho é revisar a geração do pedido de cancelamento, carta de correção ou outro evento transmitido. Esse retorno, sozinho, não significa que a NF-e original foi rejeitada nem autoriza emitir outra nota.

Antes de corrigir, localize a mensagem completa e identifique o serviço, o ambiente, a chave e o tipo de evento. NF-e modelo 55 e NFC-e modelo 65 compartilham estruturas, mas não permitem necessariamente os mesmos eventos. A regra P07-10 está na parte geral do registro de eventos; cada contrato acrescenta suas condições. MOC 7.0, Visão Geral, páginas 100–104

O que precisa coincidir

Na parte geral do pedido, o atributo Id de infEvento é formado por quatro partes, nesta ordem: a literal ID, o código tpEvento, a chave chNFe e o sequencial nSeqEvento. No leiaute de 54 caracteres, são duas posições do prefixo, seis do tipo, 44 da chave e duas do sequencial. Assim, uma sequência de valor 1 participa do identificador como 01.

Imagine um cancelamento normal, identificado pelo tipo 110111. Se o corpo traz sequência 1, mas o identificador termina com a representação da sequência 2, há divergência. Também pode acontecer quando a integração troca a chave do documento e conserva o identificador calculado anteriormente. Não copie a chave de outra nota para fazer os campos “baterem”.

Há três identificações diferentes: Id do evento enviado, idLote da transmissão e protocolo devolvido pelo serviço. Renomear o arquivo XML ou trocar idLote não recompõe o Id. O identificador que eventualmente aparece na resposta assinada também tem formação própria, ligada ao protocolo, e não deve ser copiado para o pedido. TecnoSpeed: composição e exemplo do identificador

Por que a sequência depende do evento

Não configure todos os eventos com sequência 1. Cancelamento normal e cancelamento por substituição têm esse valor no contrato correspondente; a CC-e da NF-e admite sequência de 1 a 20 e não é permitida para NFC-e. EPEC utiliza sequência 1, mas tem contratos distintos para os modelos 55 e 65.

Na manifestação do destinatário da NF-e 55, a NT 2020.001 v1.60 conserva uma descrição antiga de P15 indicando 1. Entretanto, o histórico registra duas ocorrências de cada manifestação conclusiva, e a regra H02 antiga está riscada, com máximo 2 na redação substituta. Portanto, não transforme a descrição isolada em proibição geral nem conclua que qualquer repetição é permitida. A manifestação deve corresponder aos fatos e respeitar suas regras específicas. NT 2020.001 v1.60, páginas 3, 11 e 16

Comprovante de entrega, insucesso na entrega e seus cancelamentos, nos contratos da NF-e 55, têm sequenciais de 1 a 99 nos respectivos leiautes. Para registrar novo comprovante ou novo insucesso na mesma nota, há condições sobre o cancelamento anterior. ECONF e seu cancelamento admitem valores de 1 a 99; o cancelamento ainda precisa corresponder à sequência e ao protocolo do ECONF de origem. Nada disso transforma uma sequência disponível em autorização para repetir o mesmo fato.

O evento de ator interessado admite sequência de 1 a 20 e tem validações próprias; a versão 1.40 risca a antiga restrição de chave somente modelo 55 e conserva a validação de chave 55/65. Isso não certifica disponibilidade ou distribuição de qualquer evento em qualquer ambiente. Pedido de prorrogação de industrialização e respostas do Fisco também exigem leitura do tipo específico; a NT 2015.001 v1.30 descreve adoção em SP/MG. Documentação oficial da SVRS: NT 2021.001 v1.01, NT 2023.005 v1.02 e NT 2015.001 v1.30; NT 2020.007 v1.40, páginas 5 e 9

Como resolver com segurança

  1. Preserve o XML enviado e a resposta original. Anote o horário, o ambiente, o tipo, a sequência e a versão da integração. Esses dados permitem reproduzir a falha sem mexer no documento fiscal autorizado.

  2. Confirme que o evento se refere à nota correta e que quem está tentando registrá-lo pode fazê-lo. Corrigir o identificador não elimina restrições de autoria, modelo ou prazo.

  3. Peça ao suporte para comparar cada segmento do Id com os campos efetivamente enviados. Verifique prefixo, ordem, tamanho, preenchimento da sequência e reaproveitamento indevido de dados entre notas.

  4. Corrija o gerador do evento e refaça sua assinatura pelo fluxo normal do emissor. Como infEvento é assinado, editar o XML pronto pode criar outra rejeição. Preserve o XML autorizado da nota.

  5. Se houve tentativa anterior sem resposta conclusiva, consulte os registros antes de retransmitir. Um evento já registrado pede recuperação do resultado, não fabricação de outra identidade.

O empresário normalmente não precisa montar esses campos manualmente. A orientação prática da NDD é conferir a composição; a documentação da NS7 recomenda revisar a geração automática. Esses procedimentos ajudam a localizar o defeito, mas seus exemplos não substituem o contrato atualizado de cada evento. NDD: rejeição 572; NS7: revisão do identificador

Eventos especiais e versões de 2026

Visto Eletrônico e seu cancelamento são eventos do Fisco, não alternativas que o contribuinte deve selecionar. O PAA da NT 2026.001 v1.02b acrescenta controles e assinaturas no seu escopo de NF-e 55; sua tabela geral não elimina regras específicas de CC-e e outros tipos. Na RTC, o cancelamento 110001, especificado para NF-e 55, exige a sequência, o tipo e o protocolo do evento de origem. Seu alcance é o conjunto de eventos elegíveis da NT 2025.002 v1.52, páginas 86–87; não é cancelamento geral de qualquer evento ou da nota.

O evento 110300, de vinculação de pagamento, é diferente do ECONF. A NT 2026.006 v1.00 tem cópias oficiais com cronogramas divergentes e informa caráter preparatório, sem exigência de uso dos campos de split payment em produção em 2026. Não se presume ativação universal. NT 2026.006, cópia nacional, páginas 3 e 9–10

Como saber se terminou

Confira o retorno individual: 128 informa processamento do lote, não sucesso de todos os eventos. Na parte geral, 135 identifica registro com vínculo e 136 registro sem vínculo, quando admitido pelo contrato. EPEC tem tratamento próprio. Guarde XML e retorno do evento e confira a situação fiscal correspondente. Se aparecer 573, investigue duplicidade; aumentar a sequência não é correção da 572.

Base documental: fontes oficiais preservadas em 9–10/10/2026; consulta ao catálogo em 10/10/2026. As versões citadas não comprovam implantação uniforme por UF.

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.