Rejeição 441: informe a descrição quando o pagamento for “Outros”

A rejeição 441 ocorre quando a NF-e ou a NFC-e informa tPag igual a 99, “Outros”, mas não apresenta a descrição do meio de pagamento em xPag. A solução começa por uma pergunta: o recebimento realmente pertence à categoria “Outros”? Se pertence, descreva o meio utilizado no campo próprio. Se já existe um código específico na tabela oficial, corrija a classificação em vez de criar uma descrição para justificar o código errado.

A regra YA02a-10 está documentada para NF-e 55 e NFC-e 65. Na NT 2020.006 v1.31, ela não está eliminada nem marcada para implementação futura. O cronograma registra sua implantação em produção em 01/09/2021. Essa base documental não substitui a verificação da UF, ambiente e versão envolvidos em uma falha concreta. NT 2020.006 v1.31

A descrição precisa estar no lugar certo

xPag pertence a cada ocorrência de detPag, dentro do grupo de pagamentos. Não basta escrever o meio de recebimento nas informações complementares da nota, na observação do pedido, na mensagem ao cliente ou na descrição de uma parcela que o emissor não exporta.

O leiaute define xPag como texto de 2 a 60 caracteres, destinado à descrição do meio quando tPag é 99. Uma tag vazia ou preenchida apenas com espaços não é uma descrição útil. Também não ajuda repetir “Outros” sem esclarecer o que aconteceu. A exigência formal de presença e tamanho não equivale a uma verificação automática da qualidade de toda frase; ainda assim, a informação deve representar o recebimento com clareza.

Por exemplo, se uma modalidade contratual efetivamente não estiver na tabela, a descrição deve identificá-la de forma objetiva. Não coloque ali justificativas como “sistema sem opção”, “conforme combinado” ou “regularizar depois”. Esses textos descrevem uma dificuldade interna, não o meio de pagamento da operação.

A tabela mudou: reveja os cadastros antigos

Um cadastro que usava 99 por falta de opção pode ter deixado de ser adequado. O IT 2024.002 acrescentou e ajustou modalidades ao longo de suas versões. Na tabela consultada em 2026, Pix dinâmico, Pix estático e Pix automático têm códigos distintos: 17, 20 e 23. O código 24 corresponde a TEF “Book Transfer”, transferência entre contas do mesmo banco; 18 descreve TED.

Também há diferença entre 05, para cartão da loja e modalidades de crediário, e 21, crédito em loja decorrente de valor anterior ou devolução. Pagamento posterior tem código 91 e não deve ser confundido com 90, sem pagamento. Assim, “Pix”, “crédito” ou “transferência” no cadastro comercial podem precisar de um relacionamento mais preciso com a tabela fiscal. IT 2024.002 v1.11

Para 23 e 24, o informe registra testes em 02/04/2026 e produção em 04/05/2026. Não use uma lista antiga do ERP como prova de que essas opções inexistem. Por outro lado, a existência de um código não autoriza empregá-lo sem conferir sua definição e as demais regras da operação.

Passo a passo para corrigir

1. Abra o retorno original e confirme a mensagem 441. Separe o XML transmitido da prévia exibida no sistema.

2. Localize todas as ocorrências de tPag=99. Em pagamentos combinados, cada detPag tem seus próprios dados; a descrição de uma ocorrência não completa a outra.

3. Confira a modalidade com quem registrou o recebimento e com o comprovante disponível. Compare-a com a tabela fiscal vigente.

4. Se houver código específico adequado, ajuste tPag e não exporte xPag naquela ocorrência. Se 99 for correto, preencha xPag com a descrição verdadeira, respeitando o limite do campo.

5. Salve e regenere o XML. Confira se a informação chegou ao arquivo antes de retransmitir.

6. Leia o novo retorno e confirme a autorização. Corrigir um campo pode revelar outra pendência que antes não aparecia.

A Senior documenta uma situação importante: os códigos internos do ERP diferem dos códigos da SEFAZ, e a descrição gerada pode resultar da combinação de campos. Portanto, selecionar algo que parece correto na tela não comprova o conteúdo de xPag. A inspeção do XML fecha essa verificação.

Quando a descrição some mesmo depois de preenchida

Investigue o caminho entre pedido, parcela, nota e integração. Pode existir um valor padrão por filial, uma regra personalizada ou um conector que ignora o campo. A correção precisa ser aplicada onde a informação é gerada; editar apenas a aparência do documento não corrige o arquivo assinado.

Faça um teste controlado em homologação, com dados apropriados ao ambiente, para confirmar o mapeamento. Se a descrição é cortada ou não chega ao XML, apresente ao suporte o campo de origem, o resultado esperado e o trecho realmente produzido. Preserve o pagamento registrado no financeiro para não criar diferenças de conciliação.

A explicação da McDoc confirma a combinação que causa a rejeição: 99 sem xPag. A TOTVS também relaciona “Outros” à descrição e destaca a vigência da tabela. Essas referências ajudam na investigação, mas versões antigas de produto e listas de pagamento não substituem o documento oficial atualizado.

Evite transformar 441 em outro problema

Se mudar o código para uma modalidade específica e conservar xPag, poderá surgir a rejeição 442, que trata da descrição não permitida. Já o código inexistente pertence à 436. CNPJ da instituição e bandeira são outros campos, com validações próprias; xPag não é lugar para preenchê-los.

Não use “Outros” para escapar de dados exigidos em pagamento eletrônico, nem declare dinheiro para esconder um cartão. Não peça nova cobrança ao cliente: o problema está no registro fiscal. A descrição também não deve conter senha, número completo de cartão ou dados de segurança.

A prevenção mais eficaz é manter o relacionamento entre os cadastros e a tabela fiscal, revisar padrões de filial e validar o par tPag/xPag antes do envio. Para 99, uma descrição específica; para os demais códigos, ausência de xPag. Essa conferência simples reduz retrabalho sem modificar a realidade financeira da venda.

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