Rejeição 796: CNPJ recebedor do pagamento inválido

A rejeição 796 indica problema no CNPJ informado como beneficiário do pagamento. Para NF-e, modelo 55, e NFC-e, modelo 65, a regra YA07a da NT 2023.004 verifica o campo CNPJReceb: quando informado, o identificador não pode estar preenchido com zeros nem apresentar dígito inválido. A correção começa pelo registro do pagamento e pelo XML efetivamente enviado. Trocar o cadastro do cliente sem localizar esse campo pode deixar a causa intacta.

O número da rejeição, sozinho, não identifica qual cadastro alimentou o documento. Guarde o retorno completo, com cStat, xMotivo, eventual nOcor, chave, modelo, ambiente e horário. Esses dados permitem encontrar a ocorrência de pagamento envolvida e comparar o documento rejeitado com o arquivo regenerado. Preserve também os comprovantes da transação, evitando expor dados financeiros em canais públicos.

Identifique o beneficiário correto

No leiaute examinado, o caminho é pag/detPag/card/CNPJReceb. O campo identifica o estabelecimento beneficiário do pagamento. Embora o grupo se chame card, sua descrição inclui cartões, PIX, boletos e outros pagamentos eletrônicos. Portanto, o nome do grupo não autoriza concluir que qualquer ocorrência de PIX esteja automaticamente fora desse diagnóstico.

Existem outros CNPJs próximos, com funções diferentes. O campo card/CNPJ identifica a instituição de pagamento, adquirente, subadquirente ou intermediador, conforme a situação descrita no leiaute. Já CNPJPag, com a respectiva UF, trata do estabelecimento onde o pagamento foi processado quando ele difere do estabelecimento emissor. O CNPJ do destinatário está em outro grupo e identifica o comprador. Copiar qualquer um deles para CNPJReceb, apenas porque o formato parece válido, não demonstra que o beneficiário esteja correto.

Consulte o comprovante e a identificação fornecida pela integração financeira. Em empresas com filiais, verifique qual estabelecimento efetivamente recebe o pagamento. A semelhança entre nomes comerciais ou a coincidência da raiz do CNPJ não substitui essa conferência. Se o dado veio de uma integração, rastreie o campo de origem e o mapeamento que produziu o XML, em vez de alterar apenas uma tela sem confirmar o resultado.

Confira o valor que chegou ao XML

Abra a ocorrência indicada pelo retorno e procure CNPJReceb dentro de card. Verifique se houve envio de zeros como valor provisório, truncamento, perda de caracteres, espaços indevidos ou transformação incorreta durante a integração. Compare o conteúdo com o cadastro confirmado do beneficiário e com o domínio do schema aplicável à emissão. Não complete uma identificação desconhecida com zeros nem gere um número artificial com dígito aparentemente válido.

É importante separar validade formal de identidade. Um identificador que supera uma conferência de dígitos ainda pode pertencer a outra empresa. Inversamente, a existência de um cadastro correto no sistema não garante que a integração tenha enviado esse mesmo valor. A análise precisa reunir o dado verdadeiro e sua representação no documento transmitido.

Como exemplo, considere uma venda com dois detalhamentos de pagamento. O primeiro contém o beneficiário confirmado; o segundo recebeu um valor provisório preenchido com zeros. O tratamento é corrigir a origem da segunda ocorrência e regenerar o documento. Não basta revisar o primeiro pagamento ou substituir todos os beneficiários pelo CNPJ do emitente. O exemplo ilustra a localização do erro, sem oferecer uma identificação fictícia para uso fiscal.

Corrija a origem sem modificar o fato ocorrido

Se o cadastro estiver incorreto, atualize-o com base em documentação confiável e confirme qual registro é utilizado pela emissão. Se o cadastro estiver correto, mas o XML apresentar outro conteúdo, encaminhe o caso ao suporte com o arquivo rejeitado, a ocorrência e a evidência do mapeamento esperado. Nesse cenário, a falha pode estar na montagem ou transformação do documento, e não no preenchimento feito pelo operador.

Depois da correção, gere novamente o XML e confira o mesmo caminho. Confirme também se a mudança afetou somente as ocorrências necessárias. A remoção indiscriminada do grupo card pode criar outra rejeição e eliminar informações verdadeiras de pagamento. O caráter opcional de um campo no leiaute não transforma a exclusão em solução universal para qualquer operação ou obrigação aplicável.

Não altere o meio de pagamento para esconder o campo, não informe o CNPJ de uma instituição financeira no lugar do beneficiário e não simule outro estabelecimento recebedor. Se houver dúvida sobre quem deve ser identificado em uma operação concreta, esclareça a relação financeira antes da retransmissão. A rejeição aponta uma inconsistência técnica; ela não autoriza redefinir os participantes da transação.

Versão, ambiente e nova tentativa

A NT 2023.004 versão 1.20 conserva essa verificação para os modelos 55 e 65. Sua alteração expressa de limite de troco pertence a outra regra e não deve ser transportada para a 796. Atualizações posteriores de schema, identificação ou vinculação financeira precisam ser avaliadas em seu próprio contexto. Não se deve presumir que um campo de nome semelhante em outro evento substitui CNPJReceb no documento fiscal.

As fontes práticas ajudam a localizar o problema, mas exemplos de XML com hierarquia incorreta e orientações genéricas sobre emitente ou destinatário não substituem o leiaute oficial. Também não há, neste artigo, uma sequência de menus ALRA validada. Use os nomes dos campos para orientar a investigação e peça ao suporte a localização correspondente na versão instalada.

Antes de reenviar, verifique o estado atual do documento para evitar uma segunda emissão quando já existir autorização. Depois da tentativa, leia o retorno completo: uma nova rejeição exige outro diagnóstico. Guarde os XMLs anterior e corrigido e o protocolo efetivamente recebido. Corrigir CNPJReceb resolve o ponto examinado pela 796 quando essa é a causa real; não comprova, por si só, autorização ou regularidade integral da operação.

Fontes

• Portal Nacional da NF-e: NT 2023.004 v1.20, páginas 4, 12 e 14, preservada nas evidências desta revisão.

• TecnoSpeed: artigo específico sobre a rejeição 796, corpo consultado via WEB; captura HTTP local retornou bloqueio.

• FiscalPro: ficha do campo CNPJReceb, consultada no alcance registrado em fontes.

• Buscador NCM: ficha da rejeição 796; orientações genéricas foram confrontadas com a regra oficial.

Documentos oficiais citados: NT 2023.004 v1.20.