Rejeição 924: identifique a referência ao cupom fiscal antes de corrigir a NF-e

A rejeição 924 aponta para o cupom fiscal referenciado no XML. Para o empresário, a primeira providência é descobrir qual documento de origem o sistema vinculou à nota e por que gerou essa referência. Apagar o vínculo sem entender a operação pode esconder um erro cadastral ou comprometer o histórico de uma devolução.

Na NT 2026.002 v1.11, a BA20-30 proíbe referenciar Cupom Fiscal pela tag refECF na NF-e modelo 55, com aplicação obrigatória. A opção estadual anterior está riscada. O índice SVRS, conferido em 15/10/2026, lista essa versão e avisa sobre possíveis mudanças de datas. Isso não certifica implantação individual por UF e ambiente. [1][4]

Qual mensagem e qual documento estão em análise

Na NT 2026.002 v1.11, página 11, a BA20-30 tem modelo 55, rejeição e aplicação obrigatória. A mensagem literal é “Rejeição: Proibido referenciar Cupom Fisca [nOcor: 999]”. “Fisca” é a grafia do corpo salvo; a regra trata do Cupom Fiscal em refECF. nOcor identifica a ocorrência apontada na descrição do retorno. [1]

A NT 2019.001 v1.70, página 15, conservava “Rejeição: Informado Cupom Fiscal referenciado”, opcional em UF que não permitisse a referência. No MOC 7, página 81, o trecho “/65” está riscado. Portanto, a extração bruta “55/65” não autoriza aplicar a BA20-30 à NFC-e 65. São contextos históricos; não reinserem a opção estadual retirada da tabela de 2026. [2][3]

O serviço tratado aqui é autorização da NF-e, modelo 55. Não confunda uma rejeição devolvida pelo autorizador com mensagem interna do emissor antes do envio. Guarde a resposta integral para identificar quem recusou o documento, o ambiente e a versão usada.

Identifique o tipo de cupom e de documento

O grupo ide/NFref/refECF contém o Cupom Fiscal referenciado. O leiaute contempla modelos 2B, de máquina registradora não ECF; 2C, de PDV; e 2D, emitido por ECF. Portanto, o nome da tag não restringe seu alcance ao equipamento ECF. A existência desses modelos no esquema XML não autoriza seu referenciamento fiscal. [3][4] Uma NFC-e modelo 65 tem identificação eletrônica própria; não se torna ECF porque o estabelecimento a chama de “cupom”. Da mesma forma, uma NF-e modelo 55 impressa com DANFE Simplificado Tipo 2 continua sendo NF-e, identificada por tpImp=6.

Essa distinção muda o diagnóstico. A BA20-30 olha a presença de refECF, sem limitar o teste a um desses três modelos de cupom. A BA02-35 e a VC02-40 tratam de determinados modelos eletrônicos referenciados no cabeçalho e no item, respectivamente, com condições próprias. Não transforme uma chave de NFC-e em número de ECF nem faça a operação inversa para mudar a validação recebida. [1]

Na NT atual, a BA01-10 trata da própria nota emitida como NFC-e ou NF-e com DANFE Tipo 2: veda referências a outros documentos e retorna 708. Essa condição não deve ser confundida com a BA20-30. Não altere o formato de impressão para fugir da validação; ele precisa corresponder à operação real. [1]

O cronograma específico do código 924

O cronograma da NT inclui a alteração da BA20-30 na v1.10, com testes em 01/09/2026 e produção em 05/10/2026. A v1.11 transfere apenas I08-180, BA02-35 e VC02-40 para 14/12/2026 em produção. O adiamento documental não inclui BA20-30. [1]

Datas passadas e publicação não comprovam implantação individual. Confirme versão, ambiente e procedimento cabível com o autorizador responsável quando houver divergência. Essa cautela não transforma “Obrigatória” em “Facultativa” na tabela atual. Os guias de Oobj e TOTVS refletem a redação antiga; até o material Sankhya de outubro de 2026 mantém uma afirmação de opcionalidade incompatível com a NT v1.11.

Confira o arquivo que foi enviado

Preserve XML, resposta, horário e identificação da operação. Compare com o documento entregue ao cliente ou recebido como origem. Verifique:

• Modelo 55 e ambiente tpAmb da nota emitida.

• Todas as ocorrências de NFref, especialmente refECF.

• Dados do cupom, equipamento e operação de origem.

• Tipo, finalidade e documentos vinculados pela tela ou integração.

• Se a nota já foi transmitida antes e qual foi seu resultado.

O documento visível na tela pode estar correto enquanto a espécie cadastral gera uma tag errada. Uma rotina de importação também pode incluir uma referência residual ao copiar outra nota. A correção precisa chegar ao XML regenerado, não apenas ao texto da tela.

Correção conforme a causa comprovada

A origem verdadeira é uma NF-e eletrônica

Quando há NF-e modelo 55 legítima da operação, mas o cadastro a classificou como cupom ECF, corrija a espécie e o mapeamento do vínculo. Use a chave verdadeira do documento correspondente, se o referenciamento for cabível. Não aproveite uma chave de outra venda só porque o emissor aceita sua estrutura.

Depois, regenere e assine a nota pelo fluxo do sistema. Confira que a referência corresponde à origem preservada e que não restaram outras ocorrências indevidas. A classificação correta não dispensa as demais regras aplicáveis à finalidade e ao documento.

A origem é realmente um cupom abrangido por refECF

Nesse cenário, trocar o tipo cadastral falsificaria a origem. Encaminhe o caso à contabilidade para definir o procedimento cabível à operação e ao suporte para conferir a versão implementada e adequar a geração. Preserve o cupom e a relação interna entre os documentos. A adequação da geração deve preservar a origem verdadeira e o procedimento fiscal aplicável.

A linha BA20-30 da NT atual não traz exceção geral para devolução ou complemento. As delimitações de finalidade da BA02-35 e as exceções da VC02-40 pertencem a essas outras regras; não podem liberar refECF no diagnóstico da 924. Tampouco presuma que escrever o número do cupom nas informações complementares substitui toda obrigação de vínculo fiscal. [1]

A referência foi incluída sem relação com a operação

Uma referência residual comprovadamente errada pode ser removida na origem da geração. Registre a causa e preserve a versão rejeitada para comparação. Se o mesmo problema aparece em várias notas, revise a importação ou integração que produz o grupo, em vez de repetir ajustes manuais a cada emissão.

Exemplo e confirmação do resultado

Uma loja fictícia prepara uma entrada vinculada a documento eletrônico de fornecedor. A integração trouxe o número correto, mas classificou a origem como ECF. O XML saiu com refECF e voltou com 924. Ao conferir o arquivo recebido, a equipe encontra a NF-e modelo 55 da mesma compra e corrige o mapeamento para essa origem verdadeira.

Isso é diferente de uma devolução cuja origem é um cupom ECF autêntico. Nesse segundo caso, a empresa precisa de orientação fiscal para o procedimento; não existe chave de NF-e a inventar. O exemplo mostra por que duas ocorrências do mesmo código podem exigir ações distintas.

Se o resultado de um envio anterior estiver incerto, consulte a situação da chave antes de repetir a emissão. Após a correção comprovada, faça uma tentativa controlada e leia o retorno completo. A ausência do 924 não comprova autorização ou atendimento das demais validações. Confira situação fiscal, chave, protocolo quando autorizado e preservação dos documentos de origem. Se houver divergência com o XML conferido, encaminhe as evidências ao suporte e ao autorizador, identificando versão, UF, ambiente e horário.

Fontes e limites

Pesquisa e revisão textual em 15/10/2026, horário de Brasília. Novos corpos práticos e reuso identificado de capturas oficiais desse dia. Sem teste de emissão, implantação estadual individual certificada ou teste de telas do ALRA.

1. NT 2026.002 v1.11, páginas 3, 9, 11 e 18: PDF HTTP 200 de 15/10 e cache correlacionado. Textos 3/9 relidos; PNGs 11/18 existentes inspecionados nesta elaboração. Leituras visuais válidas de 3/9, realizadas nesta conversa em 787/922, reutilizadas explicitamente. Confirmadas a retirada da opção por UF, a grafia “Fisca” e a separação das regras e cronogramas.

2. NT 2019.001 v1.70, página 15: contraponto histórico, com leitura textual válida realizada nesta conversa em 922 e reutilizada. Sem nova captura HTTP ou inspeção visual dessa página; não sustenta permissão atual.

3. MOC 7 — Anexo I, páginas 12/81: captura HTTP 200 de 15/10, textos correlacionados lidos e PNG existente completo da página 81 inspecionado. A definição de refECF inclui 2B/2C/2D; o risco em “/65” foi visto no MOC, sem atribuir esse ato à NT 2019.

4. SVRS — Documentos NF-e: índice HTTP 200 e leitura WEB de 15/10 já realizados em 787, reusados por hash. Esquema 010f capturado em 15/10: declaração integral de refECF lida nesta elaboração; hierarquia de NFref reutiliza a leitura efetiva de 922. Estrutura não substitui regras fiscais; nenhum XML externo foi validado.

5. Oobj: corpo textual completo da rejeição, HTTP 200 e WEB, de 19/09/2024. A opcionalidade por UF é histórica; a orientação de conferir a origem e consultar o responsável fiscal é útil. O fragmento XML ilustrativo não foi validado nem reutilizado como modelo operacional.

6. TOTVS: corpo textual WEB completo de 06/04/2021, separado da tentativa direta HTTP 403. Winthor Fiscal desde a versão 29 e rotina 1452 são específicos do produto. A condição estadual é histórica e não foi adotada como regra atual do ALRA.

7. Sankhya: corpo textual WEB completo de 01/10/2026, separado do HTTP 403 direto. Explica adequação própria à NT v1.10a e preservação de vínculos internos. A frase que mantém opção estadual para BA20-30 contraria a v1.11. Omissão automática de grupos, versões, menus e promessa de autorização não foram transferidos ao ALRA nem tratados como procedimento fiscal universal.

InvoiSys foi lida como apoio adicional, HTTP 200 e WEB, sem data editorial explícita. A solução textual é praticamente igual à da Oobj, portanto não foi contada como terceira abordagem independente. Imagens dos guias não foram inspecionadas. Busca focal em seis caches de NTs de 2026 encontrou BA20-30 nas páginas 3/11 da NT 2026.002; ausência nas demais não prova vigência universal. Históricos preservados, sem autenticar atos antigos. Cruzada independente pendente e publicação não realizada.