Rejeição 391: como corrigir a falta do grupo de pagamento eletrônico

Atualizado em 10 de outubro de 2026

A rejeição 391 aparece quando o documento declara uma forma de pagamento que exige o grupo card, mas esse grupo não acompanha o pagamento no XML. O caminho é conferir a forma realmente utilizada, corrigir o cadastro ou a integração responsável e gerar novamente o arquivo. Alterar a venda para dinheiro ou “Outros” apenas para liberar a nota produz uma informação fiscal incorreta.

A mensagem tradicional menciona cartão de crédito e débito, mas o diagnóstico também pode envolver Pix. Pela regra YA04-10, os códigos relacionados são 03, 04 e 17. O texto precisa ser lido com sua versão: há mudanças importantes na obrigatoriedade e uma ressalva expressa para a NF-e modelo 55. NT 2025.001 v1.03, página 11.

O que está faltando no arquivo

O grupo pag reúne as informações de pagamento. Dentro dele, cada ocorrência detPag identifica um recebimento, com o meio tPag e o valor vPag. Quando a condição da regra é atendida, essa ocorrência precisa levar também card.

Por isso, ver “cartão cadastrado” na tela do caixa não basta. O cadastro pode estar correto e a rotina que monta o XML deixar o grupo de fora. Também pode existir uma venda com dois pagamentos, em que somente um deles recebeu os dados complementares. Se o retorno trouxer nOcor, o suporte deve localizar a ocorrência apontada e conferir as demais.

A 391 identifica a falta desse grupo. Já a rejeição 392 trata dos dados exigidos dentro dele quando o pagamento está declarado como integrado. Preencher somente card pode resolver a primeira etapa e revelar outra inconsistência; isso não significa que o primeiro ajuste estava errado.

Cartão e Pix precisam da classificação certa

A NT 2023.004 v1.20 passou a descrever card como grupo de cartões, Pix, boletos e outros pagamentos eletrônicos. O nome da tag permaneceu, mesmo com a ampliação de seu uso. Essa descrição ampla não significa que qualquer pagamento eletrônico acione automaticamente a regra 391. Leiaute oficial, página 12.

Na tabela de meios de pagamento, o Pix dinâmico é identificado por 17; o estático tem código próprio, 20. O IT 2024.002 v1.11 acrescentou ainda 23 para Pix automático e 24 para TEF “Book Transfer”, com cronograma de testes em 02/04/2026 e produção em 04/05/2026. A existência desses códigos não amplia, por si só, a lista 03/04/17 da YA04-10. Nunca converta uma modalidade em outra para fugir da validação. Informe Técnico 2024.002 v1.11.

O alcance mudou e exige cuidado com tutoriais antigos

No MOC e em orientações antigas, a regra aparecia como facultativa, a critério da UF. Na NT 2025.001 v1.03, “Facult.” e a observação de faculdade estadual estão riscados, dando lugar a “Obrig.”. Repetir a classificação antiga como se fosse atual pode levar a uma configuração errada.

Ao mesmo tempo, a própria página mantém “Implementação futura para modelo 55”. Assim, a 391 tem aplicação documental na NFC-e modelo 65, enquanto a ampliação para a NF-e 55 conserva essa ressalva. Se a mensagem surgir em uma NF-e, confirme o XML, a origem do retorno e a regra utilizada pelo autorizador ou pelo validador do sistema.

O DANFE Simplificado Tipo 2, tpImp=6, continua pertencendo ao modelo 55. A NT 2026.002 v1.11 consultada não apresenta uma alteração específica da YA04-10 que permita afastar automaticamente a ressalva. Não basta o documento se parecer com um cupom para tratá-lo como NFC-e.

O cronograma da NT 2025.001 trouxe, na versão 1.00, testes até 02/06/2025 e produção até 01/09/2025; a versão 1.02 registrou a ressalva do modelo 55. A data 03/11/2025 da versão 1.03 se refere às alterações ali listadas, não prova uma ativação geral da 391 no modelo 55. A exceção para emissões anteriores a 01/04/2016 também permanece escrita. Datas documentais não certificam o comportamento de cada ambiente estadual.

Como corrigir sem distorcer o recebimento

1. Confirme o pagamento da venda. Compare o pedido com o registro do caixa e verifique se crédito, débito ou a modalidade de Pix foram classificados corretamente.

2. Confira o XML rejeitado. Localize pag/detPag e verifique se card está presente na ocorrência correspondente. O DANFE impresso não mostra toda essa estrutura.

3. Ajuste a origem dos dados. Revise a forma de pagamento, a instituição responsável e o retorno da integração. O indicador tpIntegra deve representar o processo real: 1 para integrado; 2 para não integrado. POS integrado também pode usar 1, portanto a palavra “maquininha” não define sozinha a classificação.

4. Atualize a nota a partir dos dados corrigidos, gere o XML e confira o resultado antes de retransmitir. Apenas reenviar o arquivo antigo tende a repetir a rejeição.

Os caminhos variam conforme o emissor. No Bling, a orientação passa pelo cadastro da forma de pagamento e pela atualização das parcelas da nota. Confira valores e vencimentos após regenerá-las. A Alterdata documenta ajustes de cadastro e captura dos dados em seus emissores. A TecnoSpeed mostra o mapeamento do grupo na integração. Use essas instruções de produto junto da versão oficial atual, pois parte da documentação prática ainda repete a antiga faculdade por UF.

Exemplo de uma correção segura

Imagine uma compra paga parcialmente em dinheiro e parcialmente no débito. O sistema criou duas ocorrências de pagamento, mas omitiu card naquela de débito. A correção é preservar a divisão e acrescentar os dados correspondentes ao recebimento eletrônico real. Não se deve mudar o valor total para dinheiro, aproveitar a autorização de outra venda nem cobrar o cliente novamente.

A rejeição, sozinha, também não demonstra obrigação universal de contratar TEF. A exigência estadual de integração deve ser verificada separadamente. Quando houver integração obrigatória, marcar tpIntegra=2 artificialmente não resolve o problema de conformidade.

Como encerrar a pendência

Antes de uma nova emissão, consulte a situação do documento se houver dúvida sobre tentativas anteriores. Para a nota efetivamente rejeitada, corrija e retransmita pelo fluxo do emissor, confirmando o protocolo de autorização. Guarde o vínculo entre venda, pagamento e documento, sem expor número completo de cartão, senha ou código de segurança em chamados.

O novo grupo de vinculação financeira da NT 2026.006 v1.00 não substitui as informações de pagamento do grupo YA. Seu cronograma deve ser acompanhado separadamente: a própria nota técnica ressalva que os campos de split payment são preparatórios e não têm preenchimento exigido em produção em 2026. Acrescentá-los não é solução para a ausência de card.