Rejeição 442: retire a descrição indevida do pagamento

A rejeição 442, “Descrição do pagamento não permitida”, aparece quando o pagamento da NF-e ou da NFC-e tem um código diferente de 99, mas também traz o campo xPag preenchido. Esse campo não funciona como uma observação livre para qualquer recebimento: sua finalidade é explicar o meio classificado como “99-Outros”.

A correção usual é retirar xPag da ocorrência cujo código específico está correto. Antes disso, confirme a modalidade real da venda. Se o erro estiver em tPag, é esse relacionamento que precisa ser ajustado. Mudar automaticamente tudo para 99 apenas para conservar uma descrição pode fazer o XML passar por uma etapa e continuar representando mal a operação.

A regra foi identificada, não apenas a mensagem

A regra YA02a-20 consta na página 11 da NT 2020.006 v1.31, para modelos 55 e 65. Ela proíbe xPag quando tPag é diferente de 99. A linha está preservada, sem a rasura que elimina outra regra na mesma página. O cronograma da nota técnica inclui a YA02a-20 entre as alterações com produção em 01/09/2021 e testes até 03/05/2021. NT 2020.006 v1.31

Há uma particularidade editorial na tabela: a coluna “Efeito” dessa linha contém “XXX”. Isso não autoriza tratar a mensagem como simples aviso ou concluir que a regra foi revogada; a descrição, o predicado e o cronograma permanecem documentados. Também não comprova, por si só, que todos os autorizadores estejam aplicando a rejeição. Diante de um retorno real 442, o diagnóstico deve usar o XML e a resposta do autorizador, com identificação de UF e ambiente.

Por que a informação pode estar sobrando

Um cenário comum é trocar a forma de pagamento e manter a descrição anterior. O pedido estava cadastrado como “Outros”, recebeu uma explicação e depois foi corrigido para boleto, cartão ou dinheiro. Se o emissor conserva xPag, a combinação fica incompatível com a regra.

Outra possibilidade é um conector que exporta o nome comercial de todos os meios para xPag. Uma tela pode precisar exibir “Dinheiro”, “Cartão” ou “Pix” para orientar o operador; isso não significa que esse rótulo deva ser enviado como descrição no XML. O campo do cadastro e a tag fiscal têm finalidades diferentes.

Também vale verificar notas copiadas, configurações padrão por filial e personalizações que reaproveitam dados de uma venda anterior. São hipóteses para investigar, não conclusões automáticas. O que comprova a causa é encontrar a descrição na ocorrência de pagamento que usa um código diferente de 99.

Faça a correção por ocorrência de pagamento

1. Preserve o XML enviado e a resposta completa. Confirme que o código veio da autorização da NF-e/NFC-e, e não de outra mensagem do sistema.

2. Dentro de pag, examine cada detPag. Anote o par tPag/xPag e sua relação com o pedido ou recebimento.

3. Consulte o comprovante e a tabela oficial. Verifique se tPag representa a modalidade real e não apenas um código interno do ERP.

4. Se o código específico estiver correto, faça o emissor omitir xPag nessa ocorrência. Não remova indiscriminadamente dados de outros pagamentos.

5. Se a modalidade realmente for “Outros”, classifique-a corretamente e mantenha uma descrição adequada no campo próprio.

6. Regenere o XML, confira o resultado e retransmita. Uma edição na tela pode não alterar um arquivo já guardado na fila de envio.

Imagine uma venda parcialmente paga em dinheiro e parcialmente por outra modalidade realmente fora da tabela. A ocorrência de dinheiro não deve carregar xPag. Já a ocorrência legitimamente classificada como 99 precisa de sua descrição. Uma configuração que apaga todas as descrições resolve um lado e pode gerar 441 no outro.

A diferença para a rejeição 441

Os dois códigos verificam situações complementares. A 441 trata de 99 sem a descrição exigida. A 442 trata da descrição acompanhando um meio diferente de 99. Portanto, a regra prática é testar o par de campos, não apenas perguntar se existe algum texto no documento.

O leiaute define xPag com 2 a 60 caracteres quando utilizado. Enviar uma tag vazia, espaços ou uma palavra genérica não é uma forma confiável de “desativar” o campo. Se ele não é permitido, deve ser omitido na geração do XML. O emissor continua podendo manter informações internas necessárias ao financeiro, sem exportá-las indevidamente para essa tag.

A SorioDev mostra a correção do campo na tela e a necessidade de gerar novamente o arquivo. A Oobj confirma o cenário de descrição associada a um pagamento específico. Os nomes de botões variam; o resultado técnico esperado é o mesmo par de campos coerente no XML.

Consulte as modalidades atuais antes de escolher “Outros”

A tabela de meios de pagamento possui opções que sistemas antigos podem não mostrar. Pix dinâmico, estático e automático estão separados em 17, 20 e 23. Há também o código 24 para TEF “Book Transfer” e o 91 para pagamento posterior. O IT 2024.002 v1.11 registra a inclusão de 23 e 24, com produção em 04/05/2026. Não use 99 apenas porque a tela ainda não conhece uma modalidade tabelada. IT 2024.002 v1.11

A TecnoSpeed identifica tPag e xPag em seus formatos de integração. Ao usar exemplos de documentação, confira a combinação efetiva de valores: um trecho com código 90 e descrição não é modelo de correção para esta rejeição. A regra oficial prevalece sobre um exemplo inconsistente.

Como evitar repetição

Valide pagamentos mistos, alterações de modalidade e notas copiadas nos testes do emissor. O sistema deve preencher xPag apenas quando necessário e retirar o campo quando o código mudar. Essa verificação precisa alcançar a integração e o arquivo gerado, não só o formulário.

Se a rejeição persistir, entregue ao suporte a ocorrência problemática, modelo, UF, ambiente e versões, com os dados mínimos necessários. Confirme depois a autorização e guarde o protocolo. Não refaça a cobrança, não invente outro meio e não inclua dados completos de cartão: corrigir a descrição fiscal não exige alterar o pagamento do cliente.

Atualização documental: 10/10/2026.