Rejeição 436: como corrigir o código do meio de pagamento

A rejeição 436, com a mensagem “Código do meio de pagamento inexistente”, indica que o código enviado em tPag não foi encontrado na tabela de meios de pagamento usada na validação da NF-e ou da NFC-e. O primeiro passo é comparar o XML efetivamente transmitido com a tabela oficial, preservando a forma real de recebimento. Trocar tudo por dinheiro ou por “Outros” apenas para liberar a nota pode criar uma informação fiscal incorreta.

A regra atual é YA02-60, documentada para os modelos 55 e 65. Ela verifica a existência do código. Ser um código existente, porém, não significa que ele sirva para qualquer operação ou modelo: outras regras podem restringir seu uso. NT 2020.006, versão 1.31

Por que algumas consultas ainda associam 436 ao código 99

Versões antigas vinculavam o número 436 à mensagem sobre informar “99-Outros”. Essa regra, YA02-50, foi eliminada. Na versão 1.31 da NT 2020.006, ela permanece visível como histórico, mas está riscada; logo abaixo aparece a YA02-60, sobre código inexistente.

Assim, encontrar uma lista antiga com “436: Informado 99-Outros” não prova que o uso de 99 esteja proibido hoje. Quando “Outros” realmente corresponde ao pagamento, há uma exigência distinta: informar sua descrição em xPag. A ausência dessa descrição é tratada pela rejeição 441. Receber uma mensagem antiga exige conferir o retorno original da SEFAZ e a versão do emissor, sem concluir que toda ocorrência de 436 tem a mesma causa histórica.

Use a tabela atual, não uma lista fixa do programa

A tabela oficial passou por atualizações relevantes. O IT 2024.002 v1.11, consultado integralmente, e a planilha publicada pela SVRS em 04/03/2026 distinguem, por exemplo:

• 17: Pix dinâmico; 20: Pix estático, por chave ou pelas informações de agência e conta

• 23: Pix automático; 24: TEF “Book Transfer”, descrito como transferência entre contas do mesmo banco

• 18: TED, relacionada à transferência entre contas de bancos diferentes

• 05: cartão da loja, crediário digital e outros crediários; 21: crédito em loja decorrente, por exemplo, de valor anteriormente pago ou devolução

• 90: sem pagamento; 91: pagamento posterior

Essas diferenças evitam dois erros comuns: tratar qualquer Pix como uma única modalidade e confundir crédito já disponível na loja com financiamento da compra. Também não se deve interpretar o código 24 como indicação de qualquer venda processada por equipamento TEF: a descrição da tabela delimita a modalidade de transferência. IT 2024.002 v1.11

Para os códigos 23 e 24, o informe prevê homologação em 02/04/2026 e produção em 04/05/2026. Para 91, registra 20/10/2025 e 03/11/2025, respectivamente. Essas são datas documentais específicas; não devem ser confundidas com o início histórico da YA02-60, em maio de 2021 nos testes e setembro de 2021 em produção. Uma divergência concreta requer verificar a versão instalada, a UF e o ambiente utilizado.

Um roteiro que localiza a origem do erro

1. Guarde o XML enviado e a resposta completa. Confira cStat, xMotivo, modelo, ambiente, horário e autorizador. A descrição resumida do ERP pode estar desatualizada.

2. Liste cada ocorrência de detPag. Uma venda dividida entre dois meios pode ter apenas uma ocorrência incorreta. O código deve ter dois caracteres e corresponder ao valor exportado para tPag.

3. Compare o código com a tabela oficial, considerando a vigência. Diferencie o código fiscal do identificador interno do cadastro, que pode ser outro número.

4. Recupere a informação do pedido, comprovante e integração financeira. Identifique a modalidade verdadeira antes de alterar o cadastro.

5. Corrija o relacionamento no emissor e gere novamente o XML. Confira o arquivo novo antes do reenvio, porque uma fila de transmissão pode conservar o anterior.

6. Consulte o resultado da nova tentativa. O trabalho termina com a situação fiscal confirmada e o protocolo correspondente, não apenas com a mensagem “enviado”.

A orientação da Omie ajuda a localizar o meio de pagamento nas parcelas do pedido. Esse caminho pertence àquele produto; a regra fiscal é conferir o valor produzido em tPag. A página ainda mostra nomenclaturas antigas, como “Transferência bancária, Carteira Digital” para 18, que não substituem a tabela de 2026.

Quando a estrutura passa, mas a SEFAZ rejeita

É possível o XML obedecer ao formato do campo e continuar errado. O ACBr explica a diferença entre validar dois dígitos no esquema e consultar a existência do código na tabela. Sua lista histórica, porém, não contempla todas as inclusões posteriores.

A Oobj também relaciona o problema ao código exportado. O cuidado operacional é não copiar o código de um exemplo sem verificar o recebimento da própria venda. Se o cadastro interno usa “07” para representar cartão de débito, isso não autoriza exportar 07; a integração precisa converter o identificador interno para o código fiscal aplicável.

O que não resolve a rejeição

Não refaça a cobrança do cliente para corrigir tPag. Não use 90 quando houve pagamento, nem 91 para esconder informação que já existe. O código 22 tem condição específica de falha de hardware e impossibilidade de emissão offline; não é uma alternativa geral para integração defeituosa. O código 99 exige uma modalidade fora do rol e descrição adequada.

Também não reduza a tabela inteira aos seis códigos do IT 2026.001 v1.01. Esse informe delimita o grupo de vinculação da transação ao split payment e menciona a rejeição 1003. Ele não transforma os demais meios válidos do grupo de pagamentos em causas de 436. IT 2026.001 v1.01

Para prevenir recorrências, mantenha a tabela versionada, teste o relacionamento entre pedido e XML e revise os pagamentos múltiplos. A correção deve fazer o documento representar a operação, sem alterar artificialmente o que aconteceu no caixa.

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