Rejeição 899 na NFC-e: confira o meio de pagamento enviado como 90

Se uma venda no caixa recebeu a rejeição 899, confira se a NFC-e foi enviada com o meio de pagamento Sem Pagamento, código 90. Esse preenchimento é o motivo específico previsto pela regra deste artigo. A solução depende de identificar o recebimento real ou a condição comercial verdadeira e corrigir sua representação no documento.

A mensagem é “Rejeição: Informado incorretamente o campo meio de pagamento”. Apesar de parecer genérica, na regra YA02-40 ela se refere à autorização da NFC-e modelo 65 com tPag=90. Não trate qualquer erro de cartão, troco, Pix ou credenciadora como causa desse mesmo retorno.

Delimite o documento e o serviço

No MOC 7.0, Anexo I, página 125, a YA02-40 é obrigatória para o modelo 65. O meio de pagamento fica em pag/detPag/tPag, grupo YA, página 62. O campo não é o número da parcela, o indicador de pagamento à vista ou a prazo, nem a descrição livre de uma condição comercial do cliente.

A conferência documental de 15/10/2026 usa o MOC novamente obtido, a NT 2016.002 v1.61, o pacote XML 010f e a tabela oficial de meios de pagamento. A YA02-40 não apresenta exceção própria nem condição de valor ou troco. A indicação obrigatória no documento não é um teste de execução em cada UF, autorizador ou ambiente. XML 4.00 é a versão do leiaute, distinta da versão do manual.

Há uma diferença essencial em relação à NF-e modelo 55: na regra YA02-04, finalidades de ajuste e devolução exigem Sem Pagamento e podem retornar 871 se outro meio for enviado. A solução daquele contexto não deve ser transportada para um cupom NFC-e. Confirme sempre modelo e mensagem completa.

Por que o código 90 pode aparecer no caixa

Uma forma interna chamada “a prazo”, “crediário” ou “pendente” pode estar vinculada incorretamente ao código 90. Também pode haver uma configuração compartilhada com a rotina de devolução de NF-e, ou uma integração que substitui um meio não reconhecido por Sem Pagamento.

Outra causa é o operador alterar a tela e o sistema continuar usando os dados gravados na primeira tentativa. O nome mostrado no fechamento da venda pode estar correto, mas o arquivo transmitido conserva outro valor. O diagnóstico precisa comparar venda, comprovantes e XML; olhar apenas a lista de formas de recebimento não resolve a divergência.

Não considere ausência de dinheiro físico como ausência de pagamento. Cartão, transferência e outros meios eletrônicos também podem representar um recebimento; confira o que ocorreu na operação. Do mesmo modo, uma promessa de pagamento futuro exige a representação documental aplicável, não a escolha automática de 90.

Confira cada detalhe de pagamento

Preserve a resposta da SEFAZ e o XML rejeitado. Registre número, série, ambiente, UF, autorizador e horário. Na venda, separe os valores recebidos por cada meio, eventuais valores a receber e troco. Confronte essas informações com todas as ocorrências de detPag.

Procure especialmente uma ocorrência residual com tPag=90. Em pagamento misto, corrigir apenas a primeira forma pode deixar a segunda errada. Verifique também vPag e os dados associados ao meio escolhido, conforme a documentação atual e a exigência aplicável na UF.

Se o XML não apresentar 90, confirme se o arquivo analisado corresponde à tentativa que recebeu 899. Pode ser um arquivo regenerado posteriormente, o XML de outra venda ou um resultado armazenado sem vínculo correto. Antes de mudar outros campos, peça ao suporte a correlação entre requisição e resposta.

Corrija conforme a causa comprovada

O recebimento ocorreu, mas o cadastro está mapeado incorretamente. Ajuste a associação entre a forma interna e o código fiscal verdadeiro. Se a operação foi em dinheiro, não declare cartão apenas para deixar de usar 90. Depois, atualize a nota rejeitada pelo emissor e confira o arquivo regenerado.

A venda combina dois meios. Preserve a divisão real dos valores e revise as duas ocorrências. Não concentre todo o pagamento em uma modalidade fictícia. A reconciliação com o caixa deve continuar demonstrando o recebimento de cada parte e o eventual troco.

Existe pagamento posterior. A tabela oficial consultada, de 04/03/2026, distingue 90 — Sem Pagamento de 91 — Pagamento Posterior. O código 91 tem início de vigência registrado em 03/11/2025 e se refere a pagamento integral ou parcial após a emissão ou o fato gerador, especialmente no contexto da vinculação de pagamentos. Confirme o enquadramento real com o responsável fiscal, sem trocar todo código 90 automaticamente por 91.

A NT 2025.001 v1.03 inclui o 91 nas regras distintas YA03-10/865 e YA03-30/904. Nesta última, vPag diferente de zero com 90 ou 91 é outro motivo de rejeição. Essas disposições não criam exceção à 899, não dispensam os campos aplicáveis e não autorizam inventar um recebimento. A tabela geral conservar o código 90 também não libera seu uso na NFC-e.

O documento escolhido não representa a operação. Se o caso é devolução, remessa ou outra situação que não corresponde à emissão de NFC-e pretendida, interrompa a tentativa e confirme o documento cabível. Não altere a natureza da operação, seu valor ou a finalidade apenas para contornar a rejeição.

Exemplo de um mapeamento incorreto

Uma mercearia fictícia vende R$ 84 em produtos. O cliente paga R$ 50 em dinheiro e R$ 34 por cartão de débito. Na integração do caixa, uma das formas locais ainda está ligada ao código 90, mesmo que o fechamento mostre os dois recebimentos. A SEFAZ retorna 899.

A equipe preserva os comprovantes e identifica a ocorrência errada no XML. Corrige o mapeamento, mantém os valores de R$ 50 e R$ 34 e regenera o documento pelo emissor. Também confere os dados exigidos para o pagamento eletrônico. Não refaz a venda com todo o valor em dinheiro e não apaga o movimento de cartão.

Como confirmar o resultado

Após uma nova tentativa controlada, leia o retorno completo. Confira se a NFC-e corresponde à venda, se foi autorizada e se seu XML e protocolo foram preservados. Se aparecer outro código, faça o diagnóstico da nova regra: corrigir a 899 não garante atendimento a todas as validações.

Compare novamente pagamento, caixa e comprovantes. O encerramento exige que o documento fiscal e a movimentação financeira representem os mesmos fatos. Evite excluir a venda e criar outra antes de identificar a situação fiscal da tentativa anterior.

Acione o suporte quando o mapeamento correto não chegar ao XML ou quando o histórico de respostas estiver divergente. Envolva o contador em dúvidas sobre documento, pagamento posterior e tratamento de uma operação sem recebimento. Mantenha evidências e limite as retransmissões aos arquivos efetivamente corrigidos.

Fontes

Conferência documental em 15/10/2026. Sem emissão de teste ou validação operacional do ALRA.

• MOC 7.0, Anexo I, páginas 62 e 125, YA02-40/899. NT 2016.002 v1.61, páginas 5 e 65–66.

• NT 2025.001 v1.03 Corrigido, páginas 10–11. Esquemas XML do Portal Nacional, pacote 010f.

• Tabela oficial de meios de pagamento, 04/03/2026 e Informe Técnico 2024.002 v1.11: códigos gerais não dispensam validações por modelo.

• Apoios específicos: Oobj, TecnoSpeed, Webmania. Menus e exemplos desses produtos não são procedimentos comprovados do ALRA.