Rejeição 594: confira a sequência permitida para cada evento fiscal

A rejeição 594 informa que o número de sequência enviado não atende à regra do evento. Para corrigir, a empresa precisa identificar qual evento está tentando registrar e comparar seu histórico com o contrato aplicável. O código não significa, por si só, que a NF-e perdeu validade nem que todas as notas admitem vinte eventos.

O problema costuma aparecer depois de uma migração de sistema, integração entre plataformas ou tentativa repetida sem consulta do retorno. Também pode representar um limite efetivamente alcançado. Essas situações exigem providências diferentes: corrigir um controle local comprovadamente errado não equivale a ganhar autorização para registrar mais eventos.

O que precisa ser identificado primeiro

Solicite o XML do evento enviado, a resposta completa e o histórico oficial da chave de acesso. Confira o modelo do documento, o ambiente, o serviço utilizado e os campos tpEvento, nSeqEvento, chNFe e verEvento. Registre também a UF e quem aparece como autor.

nSeqEvento identifica a sequência de determinado tipo de evento. Não é o número da nota, o identificador do lote nem a quantidade de documentos transmitidos. Um lote que comporta vinte eventos não concede vinte tentativas para qualquer evento de uma mesma nota.

Leia o resultado individual: cStat 128 informa processamento do lote, não aprovação de todos os eventos. A equipe deve conferir a resposta daquele evento e seu protocolo antes de considerá-lo registrado.

Os limites mudam conforme a operação

Os contratos oficiais consultados mostram estas diferenças:

• Carta de Correção Eletrônica, evento 110110: na NF-e modelo 55, a regra GA03 do MOC aceita sequência de 1 a 20. A NFC-e modelo 65 não admite CC-e; seu impedimento próprio não desaparece com uma sequência válida

• Cancelamento normal, 110111, e cancelamento por substituição, 110112: o contrato de cancelamento exige sequência 1. É preciso verificar separadamente o modelo 55/65, a modalidade disponível e suas condições. Esse número não comprova que a empresa pode utilizar a substituição

• EPEC, 110140: tanto o contrato da NF-e 55, NT 2014.001 v1.41, quanto o contrato específico da NFC-e 65, NT 2014.003 v1.02, exigem sequência 1. O ramo NFC-e depende do serviço adotado pela UF; não deve ser confundido com contingência offline

• Manifestação do destinatário da NF-e 55: há até duas ocorrências de cada manifestação conclusiva, observados os demais requisitos. Ciência da Emissão não integra essa ampliação

• Ator interessado, 110150: a NT 2020.007 v1.40 estabelece sequência de 1 a 20. Seu contrato atualizado aceita chaves dos modelos 55 e 65; a restrição antiga a 55 está riscada. O serviço é o do Ambiente Nacional, com condições próprias de autoria e acesso

• Prorrogação de industrialização: os pedidos 111500/111501, seus cancelamentos 111502/111503 e as respostas fiscais correspondentes possuem controle pelo último sequencial acrescido de um, conforme o tipo. A regra não é um teto genérico de vinte eventos

• Visto Eletrônico do Fisco, 400300: o BT 2018.002 exige, para sequência diferente de 1, o cancelamento do evento anterior do mesmo tipo. Esse cancelamento é o evento 400301. Trata-se de atuação do Fisco, não de uma correção disponível ao empresário

Os limites de pedidos de prorrogação ainda sem resposta, associados a 638/639 e à opção da UF, são controles distintos da sequência 594. Da mesma forma, um contrato documental não certifica disponibilidade operacional em todas as UFs e ambientes.

A manifestação mudou, e a versão importa

A ampliação para duas ocorrências de cada evento conclusivo aparece na NT 2020.001 desde a versão 1.50, com produção prevista para 1º de agosto de 2024. Abrange Confirmação da Operação, Desconhecimento da Operação e Operação não Realizada, códigos 210200, 210220 e 210240.

Na versão 1.60, a regra H02 que exigia sempre 1 aparece integralmente riscada e foi substituída por máximo 2. Entretanto, o quadro do campo P15 ainda conserva a instrução antiga de informar 1. Ler apenas esse quadro produziria um diagnóstico desatualizado. A interpretação deve combinar a alteração expressa, as regras específicas e o Ajuste SINIEF 7/05.

A última manifestação registrada é a válida, mas isso não permite alternar declarações fictícias nem repetir Ciência para escapar de outro erro. Também existem prazos de retificação e de apresentação. Uma sequência admissível pode ser recusada por outro motivo.

Como corrigir sem apagar o histórico

1. Identifique o fato real que o evento deveria comunicar. Confirme se o usuário escolheu a operação correta no sistema

2. Consulte os eventos já registrados na mesma chave e ambiente. Inclua registros feitos por outro sistema ou antes de uma migração

3. Compare o histórico com o número efetivamente enviado. Se houver divergência, peça ao suporte que reconcilie o controle local com os registros oficiais, preservando protocolos e arquivos

4. Verifique se ainda existe uma ação fiscal legítima dentro do limite e do prazo. Se o limite foi alcançado, encaminhe o caso à área fiscal para definir o procedimento cabível

5. Somente depois da correção comprovada, gere e assine o evento pelo sistema e confira o resultado individual da transmissão

Não apague eventos para reiniciar a contagem. Excluir uma linha do ERP não exclui o registro fiscal. Também não altere o XML da nota autorizada, sua chave ou sua numeração para produzir um histórico aparentemente novo.

Sequência válida não é solução para duplicidade

Imagine que o ERP tenha perdido a resposta de um cancelamento. O evento já pode estar registrado, embora a tela ainda mostre pendência. Enviar outro número não é a solução: o contrato exige sequência 1, e a tentativa pode esbarrar em 594. É necessário recuperar a situação e o protocolo existentes.

A rejeição 573 trata duplicidade segundo a chave de identificação do evento; a 594 trata a sequência permitida. Por isso, aumentar o número apenas para fugir da duplicidade pode criar uma informação indevida ou outra rejeição. O número deve representar o histórico verdadeiro, e não uma tentativa de obter resposta positiva.

O que encaminhar ao suporte

Envie modelo, chave, tipo de evento, sequência, ambiente, serviço, versão e resposta completa, além dos protocolos anteriores. Descreva se houve migração ou transmissão por outra plataforma. Não encaminhe senha, chave privada ou arquivo de certificado com credenciais.

A prevenção mais útil é manter um histórico compartilhado entre os sistemas usados pela empresa. O próximo evento deve ser decidido a partir desse histórico e das regras do seu tipo, nunca de um contador genérico aplicado a todas as operações.

Base consultada

Consulta documental em 10/10/2026, com PDFs oficiais preservados de 09/10/2026 e legislação consultada ao vivo. MOC 7.0, Visão Geral, pp. 106, 111, 115, 119 e 121; NT 2020.001 v1.60, pp. 3, 5, 11 e 16; NT 2020.007 v1.40, pp. 4–5 e 9–10; Ajuste SINIEF 7/05, cláusula décima quinta-C. Complementos: NT 2014.001 v1.41, NT 2014.003 v1.02, NT 2015.001 v1.30, NT 2018.004 e BT 2018.002.

Leitura prática: TOTVS, 594 no Datasul, TecnoSpeed, 594 e Omie, manifestação do destinatário. Omie é contextual. Procedimentos de exclusão de registros locais e generalizações de vinte eventos não foram adotados.