Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Identificação

gPagAntecipado: referência às notas de antecipação de pagamento

<gPagAntecipado>ide › gPagAntecipado

Revisão editorial em 27 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

gPagAntecipado reúne chaves de NF-e anteriores relacionadas a antecipações de pagamento. Ele fica na identificação, em /nfeProc/NFe/infNFe/ide/gPagAntecipado. O grupo cria um vínculo documental; não contém o comprovante bancário nem informa sozinho o valor recebido ou o saldo a pagar.

A NT 2025.002 v1.51, página 17, descreve seu uso para abater parcelas de antecipação conforme o art. 10, §4º. Antes de conferir o XML, identifique quais notas anteriores correspondem às antecipações da operação real. Um recebimento comercial sem essa identificação não fornece automaticamente uma chave para o grupo.

Vínculo fiscal e comprovação financeira

A origem de refNFe é a chave do XML da NF-e anterior de antecipação, modelo 55. Pedido, parcela, ID interno, boleto ou comprovante de Pix podem ajudar a reconciliar a operação, mas não substituem a chave de acesso.

A existência de uma nota referenciada também não prova, por si, que um pagamento bancário tenha sido liquidado. A conferência financeira depende dos registros reais de recebimento. A documentação fiscal e a financeira precisam se relacionar à mesma operação, com os respectivos papéis preservados.

Exemplo comercial hipotético: uma operação de R$ 1.000 possui antecipações comprovadas de R$ 200 e R$ 300. A diferença aritmética comercial é R$ 500. Essa conta não determina automaticamente vNF, vNFTot, bases tributárias ou os valores de pagamento da NF-e. O tratamento fiscal e a representação dos valores precisam ser confirmados conforme a operação; o grupo contém referências, não uma fórmula de totalização.

Estrutura e origem das chaves

O grupo ocorre zero ou uma vez. Quando existe, deve conter de uma a 99 ocorrências de refNFe, cada uma com uma chave de 44 caracteres de uma NF-e modelo 55 emitida anteriormente. Portanto, um gPagAntecipado vazio não representa “sem antecipação”; ele fica sem o filho obrigatório.

O schema 010d v1.03 lido já contém essa estrutura em ide/gPagAntecipado. Isso difere da nova referência governamental refDFeAnt, ausente do tipo governamental desse pacote histórico. Não use a versão de uma estrutura como prova automática da outra.

Trecho sintético parcial:

<gPagAntecipado xmlns="http://www.portalfiscal.inf.br/nfe">
  <refNFe>52260911222333000181550010000001231876543218</refNFe>
</gPagAntecipado>

A chave fictícia tem UF 52, ano-mês 2609, modelo 55, série 001, número 000000123 e DV 8. O dígito foi calculado para o exemplo. A sequência não pertence a uma nota cuja existência, finalidade ou autorização tenha sido comprovada. O fragmento omite os demais grupos da NF-e e não deve ser transmitido.

Para várias notas aplicáveis, cada chave ocupa seu próprio refNFe dentro do mesmo grupo. Não concatene chaves nem use o número fiscal de nove dígitos em lugar da chave completa.

Homônimos no XML

O nome refNFe aparece também em ide/NFref/refNFe, como referência geral. Aqui, o pai é gPagAntecipado, e a função é ligar notas de antecipação. Já gCompraGov/refDFeAnt liga etapas governamentais.

Não procure todas as tags chamadas refNFe como se fossem uma lista única. Use o caminho completo e o namespace http://www.portalfiscal.inf.br/nfe. Um diagnóstico precisa identificar qual grupo gerou a mensagem.

Os dados de meio e valor de pagamento, como tPag e vPag, cumprem outra função. Uma chave inserida em gPagAntecipado não substitui o preenchimento correto desses dados quando aplicáveis.

Diagnóstico de modelo e existência

A regra 11BC01-10, página 74, prevê 1146 quando a referência de antecipação aparece na NFC-e modelo 65. Confira ide/mod e o pai da tag. Trocar a chave não resolve uma restrição do modelo.

A regra 11BC01-20 prevê 1147 para NF-e referenciada de antecipação inexistente. Ela registra duas exceções:

  • A UF da chave diverge da SEFAZ autorizadora.
  • A nota anterior foi emitida em contingência com tpEmis=2, 4 ou 5, desde que seu ano-mês de emissão esteja no intervalo inferior a um mês da data atual, ou exista EPEC.

Preserve as condições completas da exceção. Não importe a inclusão de NFF ou restrições de finalidade encontradas em regras de referência geral para este grupo: 11BC01-20 tem seu próprio texto.

No diagnóstico, recupere o XML original, confira a chave copiada, o modelo, a UF e o tipo de emissão e registre o ambiente e o retorno. Uma exceção à consulta de existência não comprova que a referência escolhida corresponda à antecipação correta.

Regra futura sobre o tipo da nota

11BC01-30 prevê 1143 quando a nota anterior não é de débito do tipo 06=Pagamento antecipado. A mesma linha declara “Implementação Futura”. No corte de 26/09/2026, essa observação impede tratar a regra como uma rejeição já ativada por uma data presumida.

O fato de a verificação automática ser futura não muda a descrição documental do grupo na página 17. Confirme a relação com antecipação e a documentação real, sem usar a ausência de rejeição como prova de adequação fiscal. Esta página não escolhe uma finalidade de emissão nem orienta criar ou alterar documentos para atender à regra.

Evidência para a conferência

Organize a nota atual, a lista de chaves anteriores, os XMLs correspondentes e a reconciliação documental das parcelas. Identifique se a falha é modelo, estrutura vazia, chave copiada incorretamente, consulta de existência ou vínculo com a operação errada. Não altere o XML assinado arquivado nem retransmita documentos durante essa análise.

Referências

NT 2025.002 v1.51, página 17, BC01–BC02, e página 74, 11BC01-10 a 11BC01-30; schema 010d v1.03, ide/gPagAntecipado. Documentos atuais consultados no catálogo SVRS. Corte: 26/09/2026.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/ide/gPagAntecipado
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
0–1 no contexto do elemento pai
Tipo
inline:complexType
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.