Voltar para o blog

NF-e e NFC-e

Rejeição 435: a presença do comprador combina com a intermediação declarada?

A rejeição 435 aponta uma incompatibilidade entre duas informações da NF-e ou NFC-e: como a operação foi realizada e a declaração de participação de intermediador. Ela não significa que o CNPJ da plataforma esteja necessariamente errado. Trocar esse cadastro sem conferir os indicadores costuma deixar a causa original…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 435: a presença do comprador combina com a intermediação declarada?.

A rejeição 435 aponta uma incompatibilidade entre duas informações da NF-e ou NFC-e: como a operação foi realizada e a declaração de participação de intermediador. Ela não significa que o CNPJ da plataforma esteja necessariamente errado. Trocar esse cadastro sem conferir os indicadores costuma deixar a causa original intacta.

Para os modelos 55 e 65, a regra B25c-20 da NT 2020.006 v1.31 proíbe indIntermed=1 quando indPres é diferente de 1, 2, 3, 4 ou 9. A precisão importa: a redação consolidada não descreve uma proibição indistinta de qualquer valor da tag. Guias antigos podem apresentar uma condição mais ampla.

Dois campos, duas perguntas

O indicador de presença, indPres, informa a modalidade da operação. Entre suas opções estão 0, não se aplica; 1, presencial; 2, não presencial pela internet; 3, teleatendimento; 4, NFC-e com entrega em domicílio; 5, presencial fora do estabelecimento; e 9, outras operações não presenciais.

Já indIntermed responde se houve intermediação comercial: 0 representa venda sem intermediador, inclusive em plataforma própria; 1 representa operação intermediada por site ou plataforma de terceiros. A palavra “internet” no primeiro campo não obriga a escolher 1 no segundo. Uma venda online pode ser direta, e uma operação presencial pode contar com intermediador.

Essas definições não dispensam as demais regras do modelo. A presença 4 está vinculada à descrição de entrega de NFC-e; a lista usada em B25c-20 não autoriza transportar todas as opções indiscriminadamente entre documentos. O diagnóstico deve considerar o conjunto do XML.

Por que receitas antigas podem confundir

No material consolidado, indPres=1 integra o conjunto compatível com indIntermed=1. Portanto, é incorreto tratar toda operação presencial com intermediador como causa da 435. A NT também esclarece que, havendo intermediação numa operação presencial, suas informações devem ser prestadas, embora B25c-10 não imponha automaticamente o indicador a todas as vendas presenciais.

Outro ponto merece cuidado: o teste de B25c-20 é especificamente contra o valor 1 fora daquele conjunto. Um exemplo antigo com indIntermed=0 não demonstra, sozinho, a condição atual dessa rejeição. Isso também não transforma zero numa solução universal. A ausência de uma vedação nessa regra particular não elimina outras validações nem autoriza uma declaração contrária aos fatos.

Se o retorno real parecer incompatível com a redação documental, preserve o XML enviado e confirme a versão e o ambiente com o suporte. A tela do sistema pode exibir dados posteriores à transmissão, e mensagens locais podem resumir incorretamente o retorno da SEFAZ.

O erro de carregar dados de outro pedido

Considere uma nota complementar corretamente classificada com indPres=0. O emissor aproveitou uma configuração de pedidos de marketplace e incluiu indIntermed=1, embora a situação documentada não corresponda àquela classificação. O problema nasce do reaproveitamento do cadastro, não da necessidade de transformar o complemento em venda pela internet.

A correção exige revisar quais informações pertencem à operação complementar e quais foram herdadas indevidamente. Quando não houver intermediação a declarar e o indicador não couber naquele contexto, o sistema deve deixar de enviar a informação inadequada. Também precisa revisar eventual grupo infIntermed residual, evitando a rejeição 439.

Em outra situação, o pedido efetivamente veio de marketplace, mas indPres foi preenchido com uma opção que não descreve a venda. O caminho é corrigir a classificação comprovadamente errada, preservando a intermediação verdadeira. Escolher uma presença aleatória somente porque pertence ao conjunto aceito não é uma solução fiscal.

Quando a empresa não consegue conciliar a forma real de contratação com os campos disponíveis, o caso precisa de análise fiscal e técnica. A dúvida sobre enquadramento não se resolve apagando fatos do documento.

Um roteiro que preserva a operação

Comece pelo retorno completo, identificando cStat, mensagem, modelo e ambiente. Depois compare indPres e indIntermed no XML transmitido com o pedido e com os documentos que mostram o canal da negociação. Registre de onde cada informação veio: cadastro da natureza, tipo de operação, plataforma ou preenchimento manual.

Verifique se a configuração serve somente àquela situação ou foi aplicada como padrão a todos os canais. Uma loja pode ter vendas diretas, intermediadas e documentos de finalidade diferente no mesmo emissor. Um padrão criado para acelerar o faturamento pode estar produzindo combinações indevidas.

Faça o ajuste no ponto que gera o XML, seguindo a rotina do sistema, e confira o novo arquivo antes de reenviar. Se a operação for realmente intermediada e a presença estiver corretamente classificada, mantenha o grupo infIntermed com os dados legítimos. Se não houver intermediador, não deixe esse grupo preenchido por herança.

O responsável pelo pagamento não se torna automaticamente intermediador da venda. Uma adquirente pode apenas processar o cartão; uma transportadora pode somente entregar; o fornecedor do sistema pode apenas emitir a nota. Essas funções não justificam indIntermed=1. Uma mesma empresa pode acumular papéis, mas isso deve corresponder ao negócio concreto.

Como ler o histórico sem aplicar a data errada

A NT 2020.006 passou por mudanças importantes. A versão 1.10 incorporou a presença 1 ao tratamento das regras B25c e estendeu as regras do grupo YB à NFC-e. A versão 1.20 retirou a exigência automática de B25c-10 nas operações presenciais, sem transformar essa retirada numa proibição de declarar intermediador.

O adiamento para 04/04/2022 se refere à B25c-10, que gera a rejeição 434. Não deve ser apresentado como novo prazo geral de todas as validações sobre marketplace. A versão 1.31 manteve o tratamento documental aqui explicado e alterou I08-90, tema distinto.

Em 2026, a mudança para CNPJ alfanumérico atualizou o campo YB02, mantendo 14 posições. Essa adequação não altera a comparação entre presença e intermediação. Uma rejeição 435 não se corrige substituindo o CNPJ verdadeiro por outro numérico, nem removendo caracteres válidos do cadastro.

Conferência final

Depois da correção, confira o novo retorno e guarde o protocolo aplicável. Não interprete o simples desaparecimento da 435 como aprovação integral do enquadramento: uma informação pode passar pela validação automática e ainda representar incorretamente a operação.

A prevenção mais eficaz é manter o vínculo entre canal de venda, finalidade do documento e cadastro do intermediador, com revisão das exceções. Assim, o sistema não depende de mudanças manuais de última hora para produzir uma combinação coerente.

Fontes e base documental

Conferência em 10/10/2026, com NT 2020.006 v1.31 preservada em 09/10/2026, especialmente páginas 7, 8, 10 e 11. Os três guias práticos foram comparados com a NT; suas simplificações de presença e exemplos antigos não prevalecem sobre B25c-20.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.