Rejeição 573: como tratar um evento que já foi registrado

A rejeição 573 informa duplicidade no registro de um evento. Ela pode aparecer depois de uma tentativa que chegou ao serviço fiscal, mas cujo retorno não foi atualizado no emissor. Antes de reenviar, consulte o histórico da nota e recupere o resultado do evento anterior. Não emita outra NF-e nem aumente a sequência apenas para escapar da mensagem.

Na parte geral do registro, a regra 3P15-10 verifica a combinação da chave de acesso, do tipo tpEvento e da sequência nSeqEvento. Isso identifica um registro técnico; não basta comparar o texto da justificativa ou o nome do arquivo. Alguns contratos acrescentam particularidades à consulta, por isso o código precisa ser lido junto do serviço e da versão. MOC 7.0, Visão Geral, páginas 100–104

Um caso comum: o sistema ficou sem a confirmação

A empresa solicita cancelamento. A comunicação é interrompida e o aplicativo continua mostrando uma pendência. O operador tenta novamente, mas o primeiro evento já havia sido registrado. A segunda transmissão pode encontrar a duplicidade.

O mesmo desencontro pode ocorrer na troca de emissor ou quando mais de uma ferramenta registra eventos da empresa. A tela local incompleta não demonstra ausência na SEFAZ. A Oobj descreve esse problema de atualização; a Omie orienta consultar a situação e os eventos antes de atualizar o aplicativo. Oobj: rejeição 573; Omie: consulta e atualização

Também não conclua automaticamente que “tudo deu certo”. É preciso conferir qual evento existe, sua autoria, ambiente, sequência e resultado. Duplicidade de CC-e não significa cancelamento da nota. Duplicidade de uma solicitação de cancelamento de evento exige verificar o evento cancelado e seu vínculo.

Conferência em cinco passos

1. Suspenda reenvios automáticos dessa pendência enquanto investiga. Preserve a requisição e a resposta, com cStat e xMotivo completos.

2. Confirme a chave e o ambiente. Uma consulta em homologação não comprova o registro em produção; consultar outra nota também não esclarece a duplicidade.

3. Busque o evento correspondente no serviço autorizado ou nos recursos de consulta do emissor. Compare tipo, sequência, autor, horário e protocolo. Conforme o contrato, outros campos também importam.

4. Recupere o XML e o retorno do evento já registrado e sincronize o histórico local. O arquivo gerado antes do envio não é prova de registro; o número do lote tampouco substitui o protocolo do evento.

5. Se o registro não for localizado, encaminhe o conjunto ao suporte. Não presuma falha da SEFAZ nem experimente novos identificadores. Pode haver consulta incompleta, serviço incorreto ou integração concorrente a esclarecer.

A IOB mostra como localizar CC-e e protocolo no histórico. Seus menus são específicos do produto; a orientação de avançar numeração só pode ser considerada quando realmente couber uma nova carta, dentro das regras fiscais. Ela não serve para repetir um evento concluído. IOB: consulta da CC-e registrada

O que muda conforme o evento

Cancelamento normal, tipo 110111, usa sequência 1 no contrato correspondente. Cancelamento por substituição, 110112, tem finalidade e requisitos próprios; não é uma segunda tentativa genérica de cancelamento. Se o cancelamento desejado já estiver registrado, o trabalho é reconciliar a situação e os arquivos.

CC-e, tipo 110110, é admitida para NF-e, não para NFC-e. Uma nova correção legítima deve respeitar a sequência de 1 a 20, as restrições de conteúdo e consolidar as correções anteriores; duplicidade não autoriza criar outra carta. A manifestação do destinatário da NF-e 55 também não deve ser refeita só para mudar a tela: a NT 2020.001 v1.60 permite duas ocorrências de cada manifestação conclusiva, mas isso não é licença para qualquer repetição. A H02 antiga de sequência 1 está riscada na página 16, apesar da descrição remanescente em P15. NT 2020.001 v1.60

Comprovante de entrega 110130 e insucesso 110192, com cancelamentos 110131 e 110193, pertencem a contratos diferentes da NF-e 55. No insucesso, “+ chCTe” está riscado na regra 3P15-10 da NT 2023.005 v1.02; no comprovante, a NT 2021.001 v1.01 ainda conserva essa referência na redação. No próprio comprovante, porém, a chave da consulta lista somente chave, tipo e sequência, e o leiaute das páginas 5–6 não contém chCTe. A interpretação operacional dessa divergência do 110130 exige confirmação com o fornecedor; não acrescente nem altere uma chave de CT-e. Essa pendência não se estende ao cancelamento 110131, cuja regra usa a combinação de três campos.

ECONF 110750 e seu cancelamento 110751 atendem modelos 55/65 segundo a NT 2024.002 v1.00, com sequenciais de 1 a 99 e verificação do evento de origem no cancelamento. Ator interessado 110150 usa sequência de 1 a 20 e consulta de duplicidade que inclui cOrgaoAutor; sua versão 1.40 também risca a antiga restrição de chave somente 55. O órgão não pode ser trocado para produzir uma identidade “nova”. Prorrogações de industrialização e respostas fiscais igualmente possuem controle por tipo; a NT 2015.001 v1.30 descreve adoção em SP/MG. NT 2024.002, páginas 11 e 16; NT 2020.007 v1.40, páginas 9 e 11

EPEC: registro do evento não é autorização da nota

EPEC é prévio à autorização. No contrato da NF-e 55, há 573 para duplicidade do evento e 485 para duplicidade de numeração do EPEC. A segunda verificação considera a identidade fiscal da numeração, não apenas o Id transmitido. No contrato de EPEC da NFC-e 65, cuja adoção depende da UF, a duplicidade de numeração está descrita como 485; não se deve importar automaticamente o tratamento do modelo 55.

Nesses contratos, 136 é resultado natural de registro sem vínculo naquele momento, pois a nota ainda não foi autorizada. Não force 135 nem envie outro EPEC para “corrigir” esse resultado. A autorização posterior e a conciliação continuam sendo etapas distintas. SVRS: NT 2014.001 v1.41; NT 2014.003 v1.02, página 12

Outros contratos e confirmação final

Visto Eletrônico 400300 e cancelamento 400301 são reservados ao Fisco. PAA acrescenta controles próprios no escopo da NF-e 55, conforme a NT 2026.001 v1.02b. Eventos da RTC herdam a parte geral, mas o cancelamento 110001, especificado para NF-e 55 na NT 2025.002 v1.52, usa sequência, tipo e protocolo do evento de origem elegível. Não é cancelamento da NF-e nem de qualquer evento. Já 110300, da NT 2026.006, não substitui ECONF: é preparatório, com cronogramas oficiais divergentes e sem exigência dos campos de split payment em produção em 2026.

Por fim, 128 significa lote processado. O resultado individual e o protocolo precisam ser conferidos. 135 indica registro vinculado; 136, quando previsto, registro sem vínculo. Só considere a pendência resolvida depois de identificar o evento correto, reconciliar o aplicativo e verificar a situação fiscal pertinente. Preserve a nota autorizada e seus arquivos.

Base documental: fontes oficiais preservadas em 9–10/10/2026; catálogo consultado em 10/10/2026. Não se afirma ativação uniforme por UF ou ambiente.