Rejeição 1213: confira o tipo de emissão na chave anterior da compra governamental

Quando a NF-e recebe o código 1213, o primeiro documento a conferir é a nota anterior referenciada na operação com o órgão público. Um componente dessa chave, o tipo de emissão, está fora da lista aceita pela validação. A solução começa recuperando a chave verdadeira do documento anterior, em vez de trocar o modo de emissão da nota que está sendo preparada.

A mensagem oficial é: “Rejeição: DFe referenciado em operação com ente governamental com tipo de emissão inválido [nOcor:nnn]”. Preserve a resposta completa. O número indicado em nOcor ajuda a localizar a ocorrência da referência questionada; não é o número do produto, do pedido ou da própria NF-e.

O que a regra verifica

A regra obrigatória BB05-160, da autorização de NF-e modelo 55, examina cada chave informada em gCompraGov/refDFeAnt. Quando o mês e ano contidos na chave são posteriores a abril de 2011, o componente do tipo de emissão deve pertencer ao conjunto 1, 2, 3, 4, 5, 6, 7 ou 9. Um valor diferente nesse componente caracteriza a condição do 1213. A data é a da chave referenciada, não a data de envio da nota atual. Abril de 2011 ainda não satisfaz a condição “posterior a abril”; isso não torna qualquer chave antiga válida nas demais verificações.

A regra não diz que todos esses modos podem ser escolhidos livremente numa nova NF-e. Ela examina a composição da chave anterior. A inclusão do valor 9 na lista, por exemplo, não autoriza emitir qualquer NF-e em contingência offline. A operação, o documento e o leiaute aplicável continuam determinando quais formas de emissão são cabíveis.

O campo é específico das compras governamentais. Referências gerais de notas, referências por item e notas de antecipação de pagamento possuem verificações próprias. Uma mensagem parecida em outro campo exige diagnóstico próprio. Identifique o grupo que gerou o retorno antes de alterar o documento.

Versão e implantação precisam acompanhar o diagnóstico

A documentação foi conferida em 15/10/2026. A condição e a mensagem na NT 2025.002-RTC v1.52, página 34, coincidem com a v1.51, página 36. A página 5 registra a inclusão da BB05-160 na v1.40, com homologação até 01/07/2026 e produção em 03/08/2026 no cronograma daquele conjunto. A tabela marca a regra como obrigatória; isso não constitui teste de implantação em todos os autorizadores.

O aviso ENCAT de 05/10/2026 informa 26/10/2026 em homologação e 16/11/2026 em produção para as implantações enumeradas no comunicado. Não o interprete como suspensão automática das regras herdadas da v1.40. Confira a UF, o autorizador, o ambiente e a versão aplicada ao retorno recebido. Esta revisão não realizou emissão fiscal em produção ou homologação por UF.

Onde a chave pode ter sido alterada

O problema pode surgir quando um arquivo de integração monta a referência juntando partes de cadastros. Se um código interno de emissão for colocado onde deveria estar o componente fiscal da chave, o resultado pode conservar o tamanho esperado e ainda assim ter conteúdo inválido.

Outra hipótese é uma importação que trata a chave como número. Planilhas e integrações precisam preservar identificadores extensos como texto, sem arredondamento ou reconstrução. Uma alteração pode provocar tamanho, dígito verificador ou outros erros, sem ordem de validação assegurada; por isso, não atribua automaticamente qualquer falha de importação a esse código.

Há ainda a escolha do documento errado. Copiar uma chave de um relatório preliminar, de uma nota preparada em outro ambiente ou de um registro que não corresponde à etapa anterior pode introduzir informações incompatíveis. O suporte deve identificar a origem do valor, e o responsável fiscal deve confirmar sua relação com a operação real.

Uma conferência que o empresário pode organizar

Separe o XML rejeitado, a resposta da SEFAZ e o XML autorizado do documento anterior pretendido. Registre horário, ambiente e autorizador. Compare a chave apresentada na tela com a chave efetivamente gravada em gCompraGov/refDFeAnt no arquivo enviado.

Peça ao responsável técnico que localize a ocorrência apontada, confira o mês e ano da chave e extraia seu componente de tipo de emissão conforme o leiaute oficial. O MOC 7.0, Visão Geral, página 19, tabela 2-1, identifica esse componente com uma posição, campo tpEmis, ID B22. Compare também o dado do XML original, sem reconstruir a chave a partir de um campo isolado. A comparação deve envolver o identificador integral do documento anterior. Olhar somente o algarismo questionado pode ocultar que outras partes também foram modificadas.

Se o arquivo fiscal anterior estiver correto, mas o cadastro atual trouxer outro valor, há evidência para corrigir a importação ou a seleção. Se os arquivos discordarem sobre qual documento anterior pertence à operação, resolva primeiro essa identificação. Não é uma situação para testar vários tipos de emissão até desaparecer a rejeição.

Como corrigir conforme a origem

Erro de cópia ou seleção. Recuperada a nota anterior correta, substitua a referência no emissor pela chave integral comprovada. Gere o XML novamente pelo procedimento normal e compare o resultado com o arquivo de origem. Preserve o retorno antigo para demonstrar o que foi corrigido.

Erro de montagem na integração. Encaminhe o exemplo ao suporte. A rotina deve transportar a chave fiscal original, conservar seus caracteres e separar códigos internos dos componentes oficiais. Uma correção somente na tela não resolve um processo que sobrescreve o campo durante a geração do XML.

Chave de origem já incompatível ou documento não identificado. Interrompa o reenvio e recupere o arquivo autorizado e sua situação no canal oficial. Não altere a data para tornar a chave anterior a maio de 2011, não substitua o tipo de emissão por 1 por conveniência e não recalcule a chave para simular outro documento. Essas mudanças deixam de representar a referência real.

Exemplo original de investigação

Uma empresa fictícia prepara a etapa de recebimento de um fornecimento municipal. No exemplo, a nota anterior foi emitida normalmente em setembro de 2026, e seu arquivo autorizado contém a chave correta. O importador, porém, preenche o componente de tipo de emissão com o código interno 8. A chave do XML transmitido deixa de reproduzir a chave anterior e pode enquadrar-se na BB05-160.

A equipe compara os arquivos, corrige o mapeamento e recarrega a referência integral do documento anterior. O ajuste não muda o modo de emissão da nota atual. Depois, verifica todas as ocorrências geradas, para evitar que apenas o primeiro registro tenha sido corrigido. O exemplo descreve um erro hipotético; não fornece chave fiscal para uso real.

Resultado e encaminhamento

Após o ajuste, confira o XML final e transmita pelo fluxo do emissor. Leia o retorno completo e o protocolo correspondente. A ausência do 1213 demonstra apenas que essa condição não foi novamente apontada; existência, cancelamento, emitente e relação entre etapas podem ser verificados por outras regras.

Se a referência comprovada estiver íntegra e o 1213 persistir, encaminhe ao suporte a chave anterior, os XMLs comparados, a mensagem com nOcor, ambiente e autorizador. Dúvidas sobre qual documento deve ser referenciado exigem participação fiscal. Repetir o envio sem conferir os arquivos não melhora o diagnóstico.

Fontes

Documentação conferida em 15/10/2026.

• NT 2025.002-RTC v1.52: BB05-160, página 34; leiaute, página 17; cronograma, páginas 5–6. V1.51, página 36: comparação da condição.

• Documentos e avisos SVRS: versões e comunicado ENCAT.

• MOC 7.0, Visão Geral, página 19: estrutura da chave de acesso, conforme o leiaute aplicável.

• Confronto específico: Migrate, 1213. Contexto de integração: FlexDocs e CIGAM. A regra oficial fundamenta a orientação; exemplos de integração dependem dos documentos verdadeiros e da etapa fiscal cabível.