Rejeição 955: código numérico não zerado na referência com sigilo

A rejeição 955 indica que uma NF-e foi referenciada no campo destinado ao sigilo, refNFeSig, mas o código numérico dessa referência não foi zerado. O problema está na representação da referência enviada, e não em uma ordem para zerar a chave inteira ou o número da nota fiscal.

A regra BA02a-74 da NT 2022.003, versão 1.11, trata da NF-e modelo 55 e aparece como facultativa. Para corrigir, primeiro confirme se a operação admite a referência com sigilo. Depois, ajuste sua geração no emissor, preservando a identidade do documento original e as exigências fiscais da operação.

O que a Sefaz está conferindo

O grupo NFref reúne os documentos relacionados à nota atual. Dentro dele, refNFe informa a chave completa; refNFeSig representa a referência com código numérico zerado, criada para preservar o sigilo da NF-e referenciada. São alternativas com finalidades diferentes, não campos intercambiáveis por conveniência.

O código numérico, identificado como cNF na composição da chave, tem oito dígitos. Ele não é o número da nota, nNF, nem a série. Uma implementação que copia a chave completa para refNFeSig, sem preparar corretamente essa representação, pode manter o código numérico original e provocar o 955.

A própria NT esclarece que a referência pela chave completa continua obrigatória nas devoluções, nas notas complementares e quando a legislação exigir. Portanto, selecionar “sigilo” não é uma solução genérica para qualquer documento relacionado. Se a referência completa é exigida, a correção começa pela escolha adequada do campo, com base na operação real.

Como localizar a referência que precisa de ajuste

Guarde o XML transmitido e a resposta completa da autorização. Confira o cStat=955, o motivo e o indicador [nOcor:nnn], quando retornado. Ele ajuda a localizar a ocorrência entre os documentos referenciados; não deve ser confundido com o número de um produto.

No emissor ou com o suporte técnico, identifique o NFref correspondente e verifique se foi gerado refNFeSig. Compare essa referência com o documento que realmente fundamenta a operação. Confira estabelecimento, modelo, série, número e demais componentes antes de qualquer alteração.

Não edite o XML autorizado da nota original. Também não altere sua chave armazenada no cadastro ou nos arquivos fiscais. O tratamento de sigilo pertence à referência da nova NF-e. Modificar a identidade original ou substituir dígitos ao acaso pode criar uma referência a outro documento ou apenas deslocar o problema para outra rejeição.

Passos para corrigir com segurança

1. Confirme o enquadramento. Verifique a finalidade da nota atual, a exigência de referência e a possibilidade de usar sigilo segundo a legislação aplicável. A contabilidade deve orientar essa decisão quando houver dúvida sobre a operação.

2. Confira o campo gerado. Se a chave completa é exigida, obtenha-a do documento legítimo e configure a referência apropriada. Se o sigilo é cabível, mantenha essa modalidade e corrija a formação de refNFeSig.

3. Ajuste somente a representação necessária. Na referência com sigilo, o bloco do código numérico deve ficar zerado. Número da nota, série e identificação do emitente continuam correspondendo ao documento verdadeiro. O sistema deve tratar a composição conforme o leiaute utilizado.

4. Gere novamente e confira o XML. Compare o resultado com os dados de origem e verifique se o mesmo erro não aparece em outras referências. A escolha de uma opção na tela, sozinha, não comprova o conteúdo transmitido.

5. Transmita e examine o retorno. A correção do 955 não garante aprovação nas demais validações. Encerre o atendimento somente após conferir a situação da NF-e e o protocolo correspondente.

Se houve falha de comunicação em outra tentativa, consulte a situação antes de repetir o envio. Não crie outra numeração apenas para contornar a rejeição ou porque um tutorial afirma que qualquer número está automaticamente disponível.

Exemplo prático sem alterar o documento original

Considere uma operação em que a referência com sigilo seja efetivamente permitida. O sistema localizou a nota correta, mas copiou sua chave completa para refNFeSig. O bloco do código numérico permaneceu, por exemplo, 12345678.

Nesse caso didático, a representação em sigilo deve usar 00000000 nesse bloco, mantendo a identidade da nota referenciada. Isso não significa trocar o nNF por zero, apagar a referência ou modificar o XML original. O exemplo mostra apenas o bloco envolvido; não constitui chave completa válida nem demonstra um algoritmo de montagem ou de dígito verificador.

Se a mesma operação exigir a chave completa, esse exemplo não se aplica: será necessário corrigir a modalidade da referência com os dados autênticos, e não insistir no sigilo.

Diferença entre 955 e 956 e limites por UF

O 955 verifica o código numérico não zerado em refNFeSig. O 956 trata de outra condição: uma referência com sigilo em UF que não permite essa forma. Zerar o código pode corrigir a primeira condição sem resolver a segunda.

A observação sobre Pernambuco aparece na regra BA02a-120, do 956. Ela não restringe o 955 a Pernambuco nem significa que somente Pernambuco autoriza o sigilo. Na documentação estadual consultada em 16/10/2026, São Paulo lista o 955 como “Ativada com a NT2022.003”, e Minas Gerais marca sua validação como “SIM”. Esses registros não certificam a situação individual de um contribuinte ou de cada ambiente.

O cronograma original da NT previa testes em 07/02/2023 e produção em 03/04/2023. São datas históricas do projeto, não comprovação de ativação uniforme em todas as UFs.

Cuidados com versões e suporte

A NT 2026.002, versão 1.11, também prevê uma restrição própria ao grupo NFref para NFC-e e NF-e com DANFE Simplificado Tipo 2, tpImp=6. Essa é a regra 708; não amplia o 955 para o modelo 65 nem autoriza mudar o modelo ou o formato de impressão para contornar a operação.

Com as adaptações ao CNPJ alfanumérico, evite validadores que presumam que toda chave possui apenas algarismos. O código numérico continua sendo um componente específico. A implementação deve respeitar o schema e a versão do ambiente, sem remover letras legítimas da identificação.

Ao solicitar suporte, envie o retorno, o XML e os dados da referência pelo canal apropriado. Este guia não presume nomes de telas do ALRA nem comprova autorização de uma emissão real.

Fontes consultadas e limites da pesquisa

Base: NT 2022.003 v1.11, páginas 3–5, 7 e 9–11; MOC, campo B03; NT 2026.002 v1.11, páginas 3 e 9; NT 2026.004 v1.01 e declaração TChNFe do schema consultado. As capturas oficiais compartilhadas foram reutilizadas com seus hashes, sem apresentá-las como novos downloads.

Foram confrontados três corpos específicos: Oobj, Dominium e Buscador NCM. Oobj amplia indevidamente o modelo e inverte a conclusão sobre Pernambuco; Dominium mistura a causa do 956; Buscador é uma ficha, com generalizações não adotadas. O corpo Dominium foi lido pela ferramenta web; a tentativa direta retornou HTTP 500 vazio. Não são três receitas concordantes. A tabela da SEF-MG e a lista da Sefaz-SP são evidências documentais delimitadas, sem teste de transmissão.