Rejeição 1216: relacione o recebimento à nota do fornecimento anterior

Se sua empresa recebeu o pagamento de um fornecimento já realizado para um ente governamental e a NF-e retornou 1216, confira a nota anterior selecionada. O documento atual identifica o recebimento depois da entrega, mas a referência precisa apontar para uma operação governamental de fornecimento com pagamento posterior.

A mensagem oficial é “Rejeição: DFe referenciado em operação com ente governamental deve ser de fornecimento com pagamento posterior [nOcor:nnn]”. Preserve o retorno completo: a ocorrência indicada ajuda a localizar qual referência exige investigação. Não tente resolver simplesmente mudando o tipo de pagamento na tela financeira.

A sequência que a regra verifica

A regra obrigatória BB05-190 da NT 2025.002-RTC v1.52, página 35, aplica-se à autorização de NF-e modelo 55. Sua condição é precisa: a nota atual informa gCompraGov/tpOperGov=2, recebimento do pagamento com fornecimento já realizado. Quando há chaves em gCompraGov/refDFeAnt, cada documento referenciado deve ser de operação governamental com tpOperGov=1, fornecimento com pagamento posterior.

Em termos práticos, a referência conecta duas etapas: primeiro a empresa fornece e fica aguardando o pagamento; depois documenta o recebimento correspondente. Não basta que a chave pertença à mesma empresa ou que o valor seja parecido. A classificação do documento anterior também precisa representar a etapa prevista pela regra.

O campo tpOperGov não é o mesmo que tPag, usado no grupo de pagamento. Trocar boleto por transferência, ou alterar uma condição comercial, não corrige uma referência cujo tipo de operação governamental está inadequado. A redação e os valores de tpOperGov constam na página 17 da nota técnica.

Modelo, versão e cronograma

Embora a NT trate de NF-e e NFC-e, a coluna da BB05-190 indica somente modelo 55. Este artigo não orienta emissão de NFC-e modelo 65, consulta pública ou evento. A UF, o autorizador e o ambiente do retorno devem constar no registro do atendimento.

A regra foi incluída no bloco da versão 1.40, cujo cronograma na página 5 da v1.52 indica homologação até 01/07/2026 e produção em 03/08/2026. Em 05/10, o ENCAT anunciou 26/10 em homologação e 16/11 em produção para as NTs ali enumeradas, incluindo a v1.52. Não se conclui desse aviso que a BB05-190, já documentada anteriormente, tenha sido suspensa até novembro.

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. A linha BB05-190 não apresenta ressalva de implementação futura. Isso é evidência documental, não teste de ativação em todas as UFs. Considere a versão do sistema e os campos preenchidos, mantenha a operação verdadeira e consulte o autorizador quando houver divergência.

Diagnóstico com os documentos na mão

Reúna o XML rejeitado, o retorno da SEFAZ e o XML autorizado de cada referência. Separe os comprovantes de entrega e recebimento que sustentam a sequência. O objetivo é descobrir se o vínculo está errado, se o documento atual foi classificado incorretamente ou se o documento anterior já contém uma inconsistência fiscal.

Confira os seguintes pontos:

1. A nota atual realmente representa recebimento posterior a um fornecimento já realizado?

2. O XML atual contém tpOperGov=2, conforme a tela e os documentos da operação?

3. Cada chave em refDFeAnt corresponde à nota anterior pretendida?

4. O XML anterior contém o grupo governamental e tpOperGov=1?

5. A referência corresponde ao contrato, fornecimento e recebimento investigados?

Examine todas as ocorrências encontradas, inclusive as indevidas. A expressão “cada documento” da BB05-190 não permite juntar várias chaves no tipo 2: a BB05-20 exige a referência e a BB05-30 rejeita mais de uma, conforme a página 33. Se a integração reuniu uma lista, corrija a origem e a documentação cabível; encontrar um antecedente do tipo 1 não regulariza as outras ocorrências.

Correção por cenário

Foi escolhida uma nota de outra etapa

A equipe pode ter selecionado um documento de recebimento antecipado ou outra movimentação do mesmo contrato. Localize a nota que documentou o fornecimento com pagamento posterior. Antes de substituir a chave na nota rejeitada, confira itens, operação e vínculo com o recebimento.

Não use qualquer nota com tpOperGov=1 somente para satisfazer a validação. Ela precisa ser o antecedente real. Conservar o histórico da seleção ajuda a corrigir filtros e evitar a repetição do erro em outros contratos.

O documento atual foi classificado como recebimento indevidamente

Se a mercadoria ainda será entregue e o pagamento foi antecipado, a classificação do atual pode não corresponder ao fato. O responsável fiscal deve determinar o tratamento correto a partir da sequência comprovada. Só então ajuste os campos da nota rejeitada pelo emissor.

Não transforme uma entrega futura em fornecimento já realizado para manter um tipo disponível no sistema. A data de um lançamento financeiro não prova, sozinha, que a entrega aconteceu.

A nota anterior não tem o grupo ou informa outro tipo

Se a referência pretendida foi autorizada com dados inadequados, não edite o XML armazenado como se o autorizador passasse a enxergar a alteração. A nota autorizada e seu protocolo precisam permanecer íntegros. Leve o caso ao responsável fiscal para definir a regularização cabível, considerando situação, prazos e regras aplicáveis.

Uma eventual providência sobre o documento anterior depende dessa análise; não existe substituição universal de campo autorizada pelo 1216. Depois de regularizar, a referência da nota atual precisa corresponder ao documento válido resultante.

A tela mostra a referência certa, mas o envio é outro

Compare a chave e o tipo no XML efetivamente transmitido. Uma integração pode utilizar uma cópia antiga do pedido, recuperar o primeiro documento do contrato ou misturar registros de ambientes diferentes. Corrija a origem comprovada do vínculo e regenere o documento rejeitado pelo sistema, incluindo sua assinatura.

Exemplo hipotético

Uma fornecedora entrega 30 cadeiras para uma unidade municipal e documenta o fornecimento com pagamento posterior. Após receber o valor, prepara a nota da etapa de recebimento. Por engano, seleciona a chave de uma nota de adiantamento relacionada a outro lote do contrato. O documento atual informa tpOperGov=2, mas a referência não informa tpOperGov=1.

A equipe confronta os XMLs com os registros de entrega e encontra o vínculo errado. Seleciona a nota do fornecimento efetivamente pago, revisa todas as referências e gera novo XML pelo emissor. O exemplo ilustra a causa documental; não determina o tratamento tributário individual nem garante autorização.

Como confirmar a solução

Antes do novo envio, confirme a sequência no XML: atual com tipo 2 quando representar esse fato; cada referência com operação governamental de tipo 1. Confira também emitente, ambiente, chave, situação e correspondência com o fornecimento. Outras rejeições podem apontar condições diferentes e precisam de diagnóstico próprio.

Leia a nova resposta e preserve o resultado e o protocolo correspondentes. O desaparecimento do 1216 não substitui a comprovação da autorização da NF-e correta.

Acione o suporte quando o XML transmitido divergir da tela ou o vínculo for reconstruído automaticamente. Encaminhe ao responsável fiscal quando a classificação da etapa estiver incerta, faltarem documentos anteriores ou a nota já autorizada precisar de regularização. Não remova referências verdadeiras nem altere fatos para evitar a regra.

Fontes

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

• NT 2025.002-RTC v1.52: BB05-190, 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, 1216. 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.