Rejeição 737: integração de pagamento não aceita pela UF
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 737, regra YA04a-20, ocorre quando o pagamento foi declarado não integrado ao sistema de automação (tpIntegra=2) em uma UF que não aceita essa modalidade. A solução exige conferir o processo efetivo de pagamento e a exigência do autorizador.
Integrado e não integrado
Em NFe/infNFe/pag/detPag/card/tpIntegra, 1 identifica pagamento integrado ao sistema de automação, como TEF, comércio eletrônico ou POS integrado; 2 identifica pagamento não integrado, como POS simples. O equipamento ser chamado de “maquininha” não determina sozinho o valor: é necessário saber como os dados da transação chegam ao emissor.
A YA04a-20 aparece para modelos 55/65 e é facultativa, a critério da UF. Sua condição inclui tanto tpIntegra=2 quanto a não aceitação pela UF. Não generalize a proibição a todos os estados nem use a aplicação facultativa como justificativa para ignorar um retorno recebido.
Exemplos de diagnóstico
No primeiro cenário sintético, o cliente informa a venda manualmente no POS e digita o resultado no emissor. Se a UF não aceita esse processo no contexto fiscal, mudar apenas a tag para 1 não cria integração real. É necessário adequar o processo permitido, com o fornecedor do sistema e a orientação oficial da UF.
No segundo, existe integração automática comprovada, mas o gerador mantém 2 por padrão. Compare retorno do processador, vínculo da transação à venda e XML enviado. A correção técnica é representar o processo existente corretamente, não inventá-lo.
Um XML sintético com 1 ou 2 não demonstra como o pagamento aconteceu. Por isso, os exemplos são textuais e dependem do XML original protegido e dos registros reais da integração, sem CNPJ ou código de autorização fabricados.
Campos relacionados e próximo passo
A NT 2023.004 v1.20, p. 12, atualiza a descrição de tpIntegra e dos pagamentos eletrônicos. O MOC 7.0, p. 126, mantém a 737 com a condição da UF. A 392 trata de campos ausentes no pagamento com cartão integrado; a 391 trata do grupo ausente na NFC-e para meios específicos. Não troque um erro de integração por omissão do grupo.
Confirme ambiente, UF/autorizador e a mensagem da tentativa. Reúna a configuração do terminal, versão do integrador e registros de recebimento, preservando credenciais e dados pessoais. Se o sistema declarou 2 por erro, ajuste o mapeamento; se o processo é realmente não integrado, confirme o processo admitido e sua implementação antes de emitir novamente.
Valide o documento rejeitado com os dados verdadeiros e confira o retorno individual. Não edite XML autorizado ou assinado manualmente e não repita envio cujo resultado anterior esteja incerto.
Fontes oficiais
- MOC 7.0 — Anexo I: pp. 62–63 tpIntegra; p. 126 YA04a-20/YA05-10.
- NT 2016.002 v1.61: p. 66 YA04a-20.
- NT 2023.004 v1.20: p. 12 tpIntegra e exemplos TEF/POS.