Rejeição 1217: confira a nota do pagamento anterior ao fornecimento

Se o envio de uma NF-e governamental retornar 1217, confira o documento anterior selecionado. No fornecimento depois do pagamento, a referência deve representar a etapa do recebimento com fornecimento posterior.

A mensagem oficial é “Rejeição: DFe referenciado em operação com ente governamental deve ser de recebimento do pagamento com fornecimento posterior [nOcor:nnn]”. Use nOcor para localizar a ocorrência. Preserve o retorno e o XML transmitido.

Uma baixa financeira antes da entrega não prova o enquadramento exigido. Compare os XMLs com os registros de recebimento e fornecimento.

O que a BB05-200 exige

A regra obrigatória BB05-200 da NT 2025.002-RTC v1.52, página 35, trata da autorização de NF-e modelo 55. Ela parte da nota atual com gCompraGov/tpOperGov=3, fornecimento com pagamento já realizado. Se houver chaves em gCompraGov/refDFeAnt, cada documento referenciado deve ser de operação com ente governamental e ter tpOperGov=4, recebimento do pagamento com fornecimento posterior.

A referência liga o fornecimento atual ao recebimento anterior. A presença da referência no tipo 3 é exigida pela BB05-40; a BB05-200 confere a etapa documentada, sem substituir as outras validações. Autorização, valor igual ou mesmo contrato não bastam: a etapa identificada no XML anterior precisa corresponder à condição da regra.

No 1216, o fluxo é outro: nota atual de recebimento após fornecimento, tipo 2, referencia fornecimento com pagamento posterior, tipo 1. Não troque essas sequências.

Onde essa orientação se aplica

A coluna da BB05-200 é exclusiva do modelo 55. A nota técnica também abrange NFC-e, mas isso não inclui o modelo 65 nesta regra. O diagnóstico deste artigo é de autorização da NF-e; um número semelhante em outro documento, serviço ou consulta exige sua própria documentação.

O leiaute da página 17 distingue gCompraGov/refDFeAnt de gPagAntecipado/refNFe. Preencher uma chave apenas no grupo de antecipação não demonstra atendimento à comparação em refDFeAnt. Não transfira referências automaticamente entre grupos.

A observação sobre Nota Fiscal Avulsa, NFA, na página 35 pertence à BB05-180/1215, não à BB05-200. Ela não dispensa a conferência da etapa governamental exigida pelo 1217.

Cronograma documental e seus limites

A documentação foi conferida em 15/10/2026. A condição e a mensagem da v1.52, página 35, coincidem com a v1.51, página 37.

O texto da página 5 inclui BB05-200 no conjunto v1.40: teste/homologação até 01/07/2026 e produção em 03/08/2026. A linha textual da página 35 não traz nota de implementação futura.

O aviso ENCAT de 05/10 preservado enumera as NTs abrangidas, incluindo a v1.52, e registra 26/10 em homologação e 16/11 em produção. Não comprova suspensão de todas as regras anteriores do bloco governamental.

Calendário e coluna de aplicação não certificam ativação em toda UF/autorizador/ambiente. Identifique versão do emissor e retorno concreto. A ausência da rejeição em um ambiente não valida referência inadequada.

Como localizar a divergência

Reúna o XML rejeitado, o retorno, os arquivos autorizados das notas anteriores e os documentos que permitem ligar o pagamento ao fornecimento. A comparação deve responder:

1. O fornecimento atual realmente ocorreu depois do recebimento do pagamento?

2. O XML transmitido contém tpOperGov=3 para essa etapa?

3. A chave enviada em refDFeAnt corresponde ao documento anterior pretendido?

4. Esse documento possui o grupo governamental e tpOperGov=4?

5. O pagamento documentado se relaciona ao fornecimento que a empresa está registrando?

Confira todas as chaves, inclusive quando o sistema reuniu mais de uma parcela ou documento anterior. Uma referência correta não elimina a necessidade de investigar outra ocorrência. Não confunda o tipo governamental com o meio de pagamento tPag: transferência, boleto ou outra modalidade não definem essa sequência.

Como corrigir em cada situação

Foi selecionada uma nota de fornecimento

Uma busca pelo contrato pode retornar vários documentos. Se o operador escolheu outra nota de entrega, em vez do documento do recebimento anterior, procure o antecedente correto. Confira sua chave, seu tipo e a relação com o fornecimento antes de atualizar a nota rejeitada.

Não selecione qualquer nota com tipo 4 para satisfazer a condição. Ela precisa representar o pagamento anterior pertinente. A correção do filtro de seleção deve evitar que o sistema repita o vínculo errado na próxima operação.

A classificação da nota atual não corresponde aos fatos

Se o fornecimento aconteceu antes do pagamento, a classificação de fornecimento com pagamento já realizado pode estar errada. O responsável fiscal deve conferir a cronologia e definir a documentação cabível. A equipe só deve alterar o campo depois de comprovar o fato que a nota precisa representar.

Não antecipe uma data, invente um recebimento ou mude o tipo apenas porque existe uma referência disponível. O retorno técnico não substitui os registros da empresa nem a análise fiscal da operação.

O documento anterior autorizado informa outro tipo

Se o arquivo que deveria documentar o recebimento tem tipo inadequado ou não contém o grupo pertinente, preserve o XML autorizado. Editar uma cópia local não altera o documento que o autorizador verifica.

Leve a inconsistência ao responsável fiscal para determinar a regularização permitida, considerando os documentos, sua situação e os prazos. Não há procedimento universal de cancelamento, substituição ou ajuste autorizado apenas pelo código 1217. A nota atual deve se vincular ao antecedente válido definido após essa análise.

O XML difere do que aparece na tela

Uma integração pode recuperar uma chave antiga, selecionar o primeiro documento do contrato ou preencher somente outro grupo de referências. Compare o XML efetivamente enviado com os registros aprovados. Corrija a origem do vínculo no sistema e regenere a nota rejeitada pelo fluxo do emissor, com assinatura coerente com o conteúdo.

Exemplo hipotético

Uma empresa recebe antecipadamente o pagamento de equipamentos destinados a uma autarquia. O recebimento é documentado como operação governamental com fornecimento posterior, tipo 4. Na etapa da entrega, a nota atual informa tipo 3, mas uma importação seleciona a chave de uma nota de fornecimento de outro pedido. Esse vínculo não atende à condição da BB05-200; o cenário é didático, sem emissão real ou retorno observado.

A equipe confere o contrato, o recebimento e os dois XMLs. Localiza o documento do pagamento anterior pertinente, corrige a seleção e revisa todas as referências. A investigação resolve o vínculo identificado; o novo documento ainda precisa atender às demais regras de autorização.

Verificação final e encaminhamento

Antes de transmitir novamente, confira a relação entre a nota atual de tipo 3 e cada antecedente governamental de tipo 4, quando esse for o cenário real. Revise chave, emitente, ambiente, situação e correspondência documental. Preserve o histórico para demonstrar o motivo da alteração.

Leia a nova resposta e confirme o resultado e protocolo associados à NF-e correta. O desaparecimento do 1217 não comprova sozinho a autorização. Se surgir outra rejeição, investigue sua condição específica.

Acione o suporte quando a seleção automática divergir do cadastro ou os arquivos corretos continuarem rejeitados. Procure o responsável fiscal se a cronologia, a classificação ou o documento anterior autorizado estiverem inconsistentes. Nunca omita uma referência verdadeira ou altere o fato fiscal para contornar a comparação.

Fontes

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

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

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

• Confronto específico: Migrate, 1217. 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.