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

tPag na NF-e: tabela atual de meios de pagamento e PIX

<tPag>pag › detPag › tPag

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

tPag, em /nfeProc/NFe/infNFe/pag/detPag/tPag, é o código do meio de pagamento de cada detalhe. Ele é obrigatório, possui dois algarismos e deve existir na tabela oficial vigente para a operação. Não é o indicador à vista/a prazo, a bandeira do cartão ou um status de liquidação.

Tabela de meios conferida em 2026

A tabela publicada pela SVRS em 04/03/2026, correspondente ao IT 2024.002 v1.11, contém os seguintes códigos e descrições. No Portal Nacional, a versão de março está catalogada em 06/03/2026; data de publicação não deve ser confundida com a data de início de cada código.

Código Meio de pagamento
01 Dinheiro
02 Cheque
03 Cartão de Crédito
04 Cartão de Débito
05 Cartão da Loja (Private Label), Crediário Digital, Outros Crediários
10 Vale Alimentação
11 Vale Refeição
12 Vale Presente
13 Vale Combustível
14 Duplicata Mercantil
15 Boleto Bancário
16 Depósito Bancário
17 Pagamento Instantâneo (PIX) — Dinâmico
18 TED (Transferência Eletrônica Disponível)
19 Programa de fidelidade, Cashback, Crédito Virtual
20 Pagamento Instantâneo (PIX) — Estático
21 Crédito em Loja
22 Pagamento Eletrônico não informado — falha de hardware do sistema emissor
23 Pagamento Instantâneo (PIX) — Automático
24 TEF — Book Transfer
90 Sem Pagamento
91 Pagamento Posterior
99 Outros

Os códigos 23 e 24 têm início de produção documentado em 04/05/2026. O 91 tem início em 03/11/2025. Não use apenas um schema com padrão de dois dígitos como prova de que um código era vigente em uma nota histórica.

Distinções que mudam o mapeamento

No PIX, 17 é dinâmico, com QR-Code ou URL dinâmica; 20 é estático e sua observação inclui QR code estático, chave PIX ou dados de agência/conta. O 23 corresponde a pagamentos recorrentes configurados para débito automático via PIX, a partir de autorização do pagador. Não classifique todo PIX como 17 nem transforme agendamento interno em PIX automático sem comprovação da modalidade.

O 18 é TED entre contas de diferentes bancos. O 24 é Book Transfer entre contas do mesmo banco. O 05 abrange cartão da loja na forma de crediário, crediário digital e outros crediários, mas a observação exclui cartão da loja bandeirado. O 21 é crédito em loja decorrente de valor pago anteriormente, devolução etc.; não é sinônimo automático do 05.

O 14 identifica duplicata mercantil, com natureza de título vinculada à operação e referência à Lei 5.474/68 na observação. O 15 identifica boleto. A existência de dup no XML, número de parcelas ou um boleto gerado não escolhe por si só o 14. Confirme o instrumento comercial real, sem selecionar sua natureza jurídica por inferência.

O 22 tem cenário restrito: falha de hardware que impede integração do pagamento eletrônico e, por essa falha, torna impossível a emissão offline. Não é opção genérica para cadastro incompleto, erro de software ou autorização desconhecida.

Sem pagamento, posterior e Outros

O 90 não é sinônimo de venda ainda não quitada. A orientação do leiaute o prevê para ajuste/devolução; para NF-e 55, a YA02-04 trata essas finalidades, e vPag não zero com 90 é objeto de YA03-30/904. Na NFC-e modelo 65, informar 90 é condição da rejeição YA02-40/899. A finalidade fiscal deve estar confirmada, não alterada para adaptar o pagamento.

O 91 descreve pagamento integral ou parcial posterior à emissão/fato gerador. Ele não significa inexistência de cobrança nem comprova pagamento liquidado. A observação destaca cenários de integração/vinculação obrigatória por documento ou evento; a obrigação concreta depende da regra aplicável, não nasce universalmente da inclusão do código.

O 99 é reservado a um meio efetivamente fora do rol. Nessa hipótese, xPag deve descrevê-lo; quando tPag é diferente de 99, a descrição não é permitida pelas regras YA02a-10/20. A antiga proibição genérica de 99 da YA02-50 aparece rasurada na NT 2020.006; foi substituída pela verificação de existência do código YA02-60. Não use 99 para encobrir falta de mapeamento de um meio já catalogado.

Exemplo e campos dependentes

Suponha R$ 100,00 realmente pagos em dinheiro. Fragmento parcial e sintético, sem aptidão para transmissão:

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

O 01 é dinheiro; 0 em indPag é à vista. Dados de cartão não devem ser acrescentados a esse detalhe. card tem compatibilidade própria: YA04-20 da NT 2023.004 permite o grupo apenas para 03, 04, 10, 11, 12, 13, 15, 17 e 18 no enunciado documentado, com 963 para outros meios. A tabela de meios e a lista de compatibilidade não são intercambiáveis. Para NFC-e, YA04-10 contempla cartão 03/04 e PIX 17, com aplicação opcional a critério da UF.

Como diagnosticar código inexistente ou incorreto

Na 436, confira o código enviado e a vigência na tabela, incluindo zeros à esquerda. Se o código existe mas descreve outro instrumento, compare retorno do prestador, venda e contrato com o mapeamento do emissor. Na 441/442, confronte tPag e xPag; na 963, confira o grupo card; na 857, confira se foi informado 14-Duplicata Mercantil na NFC-e modelo 65: essa é a condição proibida pela YA02-10.

Pagamentos mistos pedem valores separados em detPag; não escolha um único código por semelhança sem conhecer o rateio. Corrija a origem do rascunho e revalide o XML. Sem documentação do meio, faltam a modalidade efetiva e o valor de cada instrumento, não um código conveniente para forçar autorização.

A tabela de vinculação para split payment do IT 2026.001/NT 2026.006 pertence a outro contrato, tpMeioPgto no grupo YC, e não substitui esta tabela de tPag. A NT 2026.006 declara os campos preparatórios sem exigência de uso em produção em 2026. Veja xPag para 99-Outros e detPag para pagamentos mistos.

Fontes oficiais

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/pag/detPag/tPag
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
inline:xs:string · string
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.

pattern
[0-9]{2}
whiteSpace
preserve