Rejeição 392: dados ausentes na operação de cartão integrada
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 392, regra YA05-10, aponta a ausência do CNPJ da instituição de pagamento ou do código de autorização no pagamento com cartão integrado. A existência do grupo card não basta: seus dados precisam corresponder à transação efetivamente realizada.
O que a regra exige
Nos modelos 55/65, a YA05-10 parte de card informado e pagamento com cartão integrado, card/tpIntegra=1. Nesse contexto, exige card/CNPJ e card/cAut. A NT 2025.001 v1.03 corrigida, p. 11, substitui a classificação facultativa do MOC por obrigatória e rasura a observação de escolha da UF. A exceção em produção para notas emitidas antes de 01/04/2016 permanece. O cronograma geral prevê produção até 01/09/2025; a observação de implementação futura do 55 na 391 não foi estendida à 392.
O CNPJ é da instituição de pagamento, adquirente ou subadquirente; se o intermediador processou o pagamento, a descrição do campo manda informar seu CNPJ. cAut identifica a autorização da transação de pagamento. Não confunda esse identificador com o protocolo de autorização fiscal, com o número da nota, com a bandeira do cartão ou com a identidade do beneficiário.
Exemplo de integração com retorno incompleto
Suponha que o pagamento tenha sido aprovado pelo processador e o sistema marque tpIntegra=1. Se a integração perde o campo da instituição ou mapeia o código de autorização para uma observação livre, o grupo card pode chegar incompleto à SEFAZ. Compare a resposta do processador com os campos da mesma transação no XML enviado.
Em outro cenário, uma configuração marca 1 embora o processo seja manual. Fabricar cAut ou copiar um CNPJ qualquer não resolve a causa. É necessário verificar a integração efetiva e as condições da UF, inclusive a 737 quando se tratar de processo não integrado.
Um XML sintético não comprova CNPJ nem autorização do pagamento. Os exemplos são textuais; a conclusão depende do original protegido e do comprovante/retorno real do processador. Não envie número completo de cartão, credenciais ou chave privada para comprovar a causa.
Não transportar exigências entre meios
A NT 2023.004 v1.20 amplia a descrição de card para outros pagamentos eletrônicos e cAut para cartões, PIX, boletos e outros. Isso não reescreve automaticamente a condição específica da YA05-10, que menciona cartão integrado. A 391 inclui PIX na exigência do grupo na NFC-e, mas grupo obrigatório e exigência interna de campos são verificações distintas.
Confira modelo, ambiente, meio, integração e ocorrência do retorno. Se os dados reais existem e foram omitidos, corrija o mapeamento. Se não existem na origem, obtenha-os pelo processador responsável e confirme o processo verdadeiro antes de gerar outra tentativa. Não mude para 2 apenas para dispensar campos.
Após corrigir a causa, confira a 437 para validade do CNPJ e as demais regras aplicáveis. Valide o documento rejeitado e examine o resultado individual; preserve autorizado e esclareça resultado fiscal incerto antes de um novo envio.
Fontes oficiais
- MOC 7.0 — Anexo I: p. 63 instituição/cAut; p. 126 YA05-10 e exceção.
- NT 2016.002 v1.61: pp. 66–67 YA05-10 e exceção.
- NT 2023.004 v1.20: pp. 12–13 descrições card/CNPJ/cAut; p. 14 YA04-10.
- NT 2025.001 v1.03 corrigida: pp. 2–3 cronograma; pp. 7,10–11 atualização pagamentos, condições, obrigatoriedade e rasuras.