Resposta rápida
A rejeição 1273 acontece quando o grupo de vinculação com a transação de pagamento (split payment) traz no campo tpMeioPgto um código fora da lista aceita: só valem 15 (boleto), 17 (Pix com QR Code), 18 (TED), 20 (Pix por chave ou QR Code estático), 23 (Pix automático) e 24 (TEF). Cartão, dinheiro e "outros" não entram, mesmo sendo válidos no grupo de pagamento comum. Corrija o código no cadastro do sistema e transmita a nota de novo com o mesmo número.
Abaixo estão a tabela de códigos, a diferença entre os dois grupos de pagamento da nota, um exemplo, as causas, o passo a passo, o evento de vinculação e a rejeição 1274.
Neste artigo
- O que significa a rejeição 1273
- Códigos aceitos no meio de pagamento
- Por que o código certo no pagamento dá erro aqui
- Exemplo de rejeição 1273
- Principais causas da rejeição 1273
- Como resolver a rejeição 1273
- Rejeição 1273 no evento de vinculação
- E a rejeição 1274?
- Quando a rejeição 1273 começa a valer
- Rejeições parecidas
- Perguntas frequentes
O que significa a rejeição 1273
1273 - Rejeição: Meio de pagamento inválido [nPag: 999]
A rejeição 1273 é do split payment. Ela aparece quando a nota traz o grupo de vinculação com a transação de pagamento (gPgtoVinc) e o campo do meio de pagamento (tpMeioPgto) tem um código que não está na lista aceita para esse grupo.
O [nPag: 999] no fim da mensagem mostra qual pagamento do grupo está errado. A regra vale para a NF-e e a NFC-e e está na Nota Técnica 2026.006, que entra em produção em 16/11/2026.
Códigos aceitos no meio de pagamento
O grupo de vinculação aceita só seis códigos, definidos no Informe Técnico 2026.001 (versão 1.01):
| Código | Meio de pagamento |
|---|---|
| 15 | Boleto |
| 17 | Pix com QR Code (dinâmico) |
| 18 | TED |
| 20 | Pix por chave ou QR Code estático |
| 23 | Pix automático |
| 24 | TEF (book transfer) |
Qualquer outro código dá rejeição 1273, mesmo que seja válido no grupo de pagamento comum da nota. Dinheiro (01), cartão de crédito (03), cartão de débito (04), vales, depósito (16) e "outros" (99) não entram no grupo de vinculação. A lista completa do grupo de pagamento comum está no post da rejeição 899.
Por que o código certo no pagamento dá erro aqui
A nota tem dois lugares que falam de pagamento, e eles não aceitam os mesmos códigos:
| Grupo de pagamento (já existente) | Grupo de vinculação (split payment) | |
|---|---|---|
| Para que serve | Informar como a venda foi paga | Ligar a nota a uma transação financeira já iniciada |
| Campo do meio | tPag | tpMeioPgto |
| Códigos aceitos | Toda a tabela nacional (01 a 99) | Só 15, 17, 18, 20, 23 e 24 |
| Quando preencher | Conforme a legislação de cada estado | Quando o pagamento começa antes da nota (boleto, Pix gerado antes) |
| Erro no código | Rejeição 899 | Rejeição 1273 |
O erro mais comum é o sistema copiar o tPag do grupo de pagamento para o tpMeioPgto. Numa venda com cartão, por exemplo, isso leva o código 03 ou 04 para o grupo de vinculação, e a nota volta com a 1273.
Exemplo de rejeição 1273
Uma loja gera um boleto e um Pix antes de emitir a nota e informa os dois no grupo de vinculação. No segundo pagamento, o sistema mandou o código do grupo de pagamento comum:
| nPag | Transação | tpMeioPgto | Resultado |
|---|---|---|---|
| 1 | Boleto | 15 | Aceito |
| 2 | Pix com QR Code | 99 | Rejeição 1273 [nPag: 2] |
Principais causas da rejeição 1273
| Causa | Quando acontece |
|---|---|
| Código do grupo de pagamento copiado | O tpMeioPgto recebe o mesmo código do tPag (01, 03, 04, 99 etc.) |
| Grupo preenchido sem necessidade | O sistema monta o grupo de vinculação em toda venda, inclusive em dinheiro ou cartão |
| Cadastro da forma de pagamento | A forma de pagamento do sistema não tem o código do split, ou tem um código errado |
| Tabela desatualizada | O sistema não conhece os códigos 23 (Pix automático) e 24 (TEF) e manda outro no lugar |
Como resolver a rejeição 1273
- Veja o número do pagamento em
[nPag]na mensagem. - Abra o XML e localize o grupo
gPgtoVinc; em cadagPgto, confira otpMeioPgto. Veja como ler o XML da NF-e. - Troque pelo código certo da tabela acima: 15, 17, 18, 20, 23 ou 24.
- Se a transação não começou antes da nota, como numa venda no cartão, o grupo de vinculação não precisa ser enviado. Em 2026, o preenchimento não é exigido.
- Corrija no sistema, no cadastro da forma de pagamento, nunca direto no XML, que perde a assinatura.
- Transmita de novo. Como a nota foi rejeitada, o mesmo número pode ser reaproveitado. Teste no ambiente de homologação antes.
Rejeição 1273 no evento de vinculação
Quando a nota já foi autorizada e o pagamento é gerado depois, como um Pix com QR Code emitido sem a chave da nota, a vinculação é feita pelo evento 110300 (Vinculação Pagamento). O evento tem o mesmo campo de meio de pagamento e a mesma regra: código fora da lista dá rejeição 1273, sem o número do pagamento na mensagem.
O evento só pode ser enviado pelo emitente da nota (outro autor dá rejeição 466). Para desfazer uma vinculação, usa-se o evento de cancelamento de evento (110001).
E a rejeição 1274?
1274 - Rejeição: CNPJ do recebedor do pagamento inválido [nPag: 999]
A 1274 é a vizinha da 1273, no mesmo grupo. Ela confere o CNPJReceb, o CNPJ completo (14 dígitos) de quem recebe o dinheiro do cliente. Pode ser a própria empresa ou outra, como uma plataforma que recebe em nome dela.
Uma confusão comum é colocar nesse campo o CNPJ do banco ou da instituição de pagamento. Esse vai em outro campo, o CNPJBasePSP, e só com os 8 primeiros dígitos (o CNPJ base).
Quando a rejeição 1273 começa a valer
| Quando | O que acontece |
|---|---|
| Até 26/10/2026 | Regras da NT 2026.006 implantadas em homologação |
| 16/11/2026 | Entram em produção na NF-e e na NFC-e |
| 2026 | Nenhuma exigência de preencher o grupo de vinculação: a 1273 só aparece se o sistema enviar o grupo |
| A partir de 2027 | Início previsto do split payment, de forma gradual |
Nos outros documentos fiscais eletrônicos (CT-e, BP-e, NF3-e, NFCom, entre outros), a mesma tabela de seis códigos vale, mas o erro sai como rejeição 1003, "Tipo de Pagamento inválido". Para entender o split payment do começo, veja o guia split payment: o que é e quando começa.
Rejeições parecidas
| Rejeição | O que significa |
|---|---|
| 1274 | CNPJ do recebedor do pagamento inválido, no mesmo grupo de vinculação |
| 215 | Falha no schema: número do pagamento (nPag) ou identificador da transação repetido no grupo |
| 899 | Meio de pagamento informado incorretamente no grupo de pagamento comum |
| 466 | Evento de vinculação enviado por quem não é o emitente da nota |
As demais rejeições do IBS e da CBS estão na lista de rejeições da reforma tributária, e o cronograma completo no guia da reforma tributária na nota fiscal.
Perguntas frequentes
O que é a rejeição 1273?
É a rejeição "Meio de pagamento inválido" do grupo de vinculação com a transação de pagamento (split payment), criado pela NT 2026.006. O campo tpMeioPgto tem um código fora da lista aceita para esse grupo.
Quais códigos de meio de pagamento são aceitos no split payment?
Seis, pelo Informe Técnico 2026.001 v1.01: 15 (boleto), 17 (Pix com QR Code), 18 (TED), 20 (Pix por chave ou QR Code estático), 23 (Pix automático) e 24 (TEF ou book transfer).
Posso usar o código de cartão de crédito no grupo de vinculação?
Não. Cartão de crédito (03), cartão de débito (04), dinheiro (01) e outros (99) são válidos no grupo de pagamento comum da nota, mas dão rejeição 1273 no grupo de vinculação.
Como resolver a rejeição 1273?
Veja o número do pagamento na mensagem, troque o tpMeioPgto por um dos seis códigos aceitos (ou deixe de enviar o grupo, se o pagamento não começou antes da nota), corrija o cadastro no sistema e transmita a nota de novo com o mesmo número.
A rejeição 1273 já vale em 2026?
As regras entram em produção em 16/11/2026, mas o preenchimento do grupo de vinculação não é exigido em 2026. A rejeição só aparece se o sistema enviar o grupo com um código inválido.
Qual a diferença entre a rejeição 1273 e a 1274?
A 1273 confere o código do meio de pagamento; a 1274 confere o CNPJ de quem recebe o pagamento (CNPJReceb), que deve ser o CNPJ completo do recebedor, e não o da instituição de pagamento.
Escreve sobre emissão de documentos fiscais e rejeições da Sefaz a partir do dia a dia das empresas atendidas pela UmPontoDois, que há mais de três décadas desenvolve sistemas de gestão.