detPag na NF-e: detalhe de cada meio de pagamento
<detPag>pag › detPagRevisã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
- MOC 7.0 — Anexo I, 7.0; Grupo Y/YA, p. 61–62 e 125–126.
- NT 2023.004 — Informações de Pagamentos e Outros, 1.20; p. 3–6, 11–12, 14–15.
- Tabela de meios de pagamento, Publicada SVRS 04/03/2026; Plan1!A2:E26.
- NT 2024.002 — Evento de Conciliação Financeira ECONF, 1.00; seções 1–3.
- NT 2026.006 — Vinculação da transação de pagamento, 1.00; p. 3 e 7.
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.