Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Cobrança e pagamentos

detPag na NF-e: detalhe de cada meio de pagamento

<detPag>pag › detPag

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

detPag detalha um meio de pagamento dentro de pag, em /nfeProc/NFe/infNFe/pag/detPag. O grupo aparece de 1 a 100 vezes. Cada ocorrência contém obrigatoriamente tPag e vPag; os demais dados dependem do contexto e das regras do meio.

Uma associação de meio, valor e transação

tPag responde qual meio foi usado ou declarado; vPag informa o valor atribuído a esse detalhe. indPag informa à vista 0 ou a prazo 1; dPag é a data do pagamento, quando existente. Esses campos não substituem uns aos outros: indicar prazo não identifica o instrumento, e indicar o instrumento não demonstra que houve liquidação.

xPag só é a descrição do meio quando tPag=99, conforme as regras próprias. O par CNPJPag/UFPag identifica estabelecimento transacional diferente daquele que emite a nota; ele é opcional em conjunto e não deve ser usado para o CPF/CNPJ do cliente. card reúne dados de pagamentos eletrônicos, incluindo o tipo de integração e os identificadores documentados da transação, instituição, beneficiário e terminal.

Os dados devem vir da venda, acordo e retorno do prestador de pagamento da mesma empresa. Preserve a correspondência: o código de autorização de um detalhe de cartão não pertence a outro PIX ou cartão do mesmo documento.

Exemplo com dois meios, sem duplicar o total

Suponha uma operação de R$ 200,00 com R$ 50,00 em dinheiro e R$ 150,00 em cheque, sem troco. Fragmento parcial e sintético, sem os demais grupos da NF-e/NFC-e e sem aptidão para transmissão:

<pag xmlns="http://www.portalfiscal.inf.br/nfe">
  <detPag><indPag>0</indPag><tPag>01</tPag><vPag>50.00</vPag></detPag>
  <detPag><indPag>0</indPag><tPag>02</tPag><vPag>150.00</vPag></detPag>
</pag>

A soma é 50 + 150 = 200. Informar vPag=200.00 em ambos produziria R$ 400,00, embora a venda fosse de R$ 200,00. Se houve valor entregue acima do total, o troco real deve ser conferido na equação do grupo pag; vTroco fica fora dos detalhes e após eles.

O texto acima exemplifica divisão por meios. dup, no grupo de cobrança, descreve parcelas e vencimentos; não deve gerar detalhes repetidos automaticamente sem considerar a forma real de pagamento. Para pagamento posterior, a tabela vigente inclui 91, com observação para pagamento integral ou parcial posterior; isso difere do 90-Sem Pagamento. Não crie data ou autorização fictícia para completar um detalhe futuro.

Quando card é aplicável e quando é incompatível

A NT 2023.004 v1.20 descreve card como grupo de cartões, PIX, boletos e outros pagamentos eletrônicos. A YA04-10, para NFC-e, contempla cartão 03/04 e PIX dinâmico 17, com implementação opcional a critério da UF. Já a YA04-20 dos modelos 55/65 proíbe card se tPag for diferente de 03, 04, 10, 11, 12, 13, 15, 17 ou 18, código 963. Um meio existente na tabela não passa automaticamente a aceitar todos os subgrupos.

Se card existe, tpIntegra é obrigatório nele. A eventual exigência de CNPJ e cAut depende da integração e das regras documentadas; a opcionalidade no XSD não substitui essa verificação. Não altere a integração declarada para esconder a falta de um retorno do prestador.

Como investigar um detalhe rejeitado

Use o XML enviado e o índice nOcor do retorno quando disponível para localizar a ocorrência. Confira o tPag na tabela atual, seu vPag, a ordem dos elementos e os dados daquele pagamento. Uma falha de data ou CNPJ no segundo detalhe não deve ser “corrigida” copiando o primeiro.

Se o erro é no total, some todos os detalhes e confronte com vNF e vTroco. Se é no meio ou card, compare o instrumento real e o retorno da integração com a configuração que gerou o XML. Se é identificação transacional, confirme o estabelecimento e sua UF, separando cliente, instituição e beneficiário. Corrija a origem e valide o rascunho regenerado, sem editar nota assinada.

Recebimentos posteriores podem ser tratados em evento próprio ECONF, conforme seu contrato e aplicabilidade; não são inclusão retroativa de detPag no XML assinado. O grupo YC preparatório da NT 2026.006 não substitui esse detalhe, YA/YB ou ECONF e não tem exigência de uso em produção em 2026. Veja card e seus dados eletrônicos e CNPJPag, que não é o CNPJ do pagador.

Fontes oficiais

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/pag/detPag
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–100 no contexto do elemento pai
Tipo
inline:complexType
Preenchimento no catálogo
Obrigatório

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.