NF-e e NFC-e
Rejeição 439: por que o grupo do intermediador está sobrando no XML
Quando uma nota declara que a venda ocorreu sem intermediador, mas também envia os dados de um marketplace, as informações se contradizem. Essa é a situação típica da rejeição 439: o grupo infIntermed foi preenchido indevidamente em relação ao indicador da operação.
Quando uma nota declara que a venda ocorreu sem intermediador, mas também envia os dados de um marketplace, as informações se contradizem. Essa é a situação típica da rejeição 439: o grupo infIntermed foi preenchido indevidamente em relação ao indicador da operação.
A regra YB01-20 da NT 2020.006 v1.31 vale para a autorização de NF-e, modelo 55, e NFC-e, modelo 65. Sua condição é o indicador do intermediador diferente de 1 acompanhado das informações do intermediador. O diagnóstico depende dessa combinação; a simples existência de um cadastro de plataforma no sistema não basta para explicar o retorno.
Onde está a incoerência
Há duas peças distintas no XML. O campo indIntermed informa se houve intermediação comercial: 0 para operação sem intermediador e 1 para operação em site ou plataforma de terceiros. O grupo infIntermed detalha o CNPJ da empresa intermediadora e o perfil do vendedor nela.
Se indIntermed=0 e infIntermed está presente, a nota afirma simultaneamente ausência e presença da intermediação. Não adianta corrigir o CNPJ para um número válido: a incoerência entre indicador e grupo continuará existindo. A validade do identificador é tema da rejeição 440.
Também é preciso distinguir a 439 da 438. Na 438, a nota declarou intermediação e deixou de trazer o grupo necessário. Na 439, enviou o grupo numa combinação que não o admite. Uma rotina que “sempre preenche tudo” pode corrigir um problema e criar o outro.
A solução depende de como a venda aconteceu
Quando a operação foi realmente direta, mantenha a classificação verdadeira e retire da geração daquela nota o grupo indevido. Isso não significa apagar o cadastro legítimo da plataforma do sistema inteiro. A empresa pode precisar dele para outros pedidos que efetivamente tenham sido intermediados.
Quando a venda veio de marketplace, mas foi marcada como direta, remover o grupo apenas esconderia a participação comercial da plataforma. Nesse caso, a informação incorreta é o indicador, que deve ser ajustado conforme a origem documentada do pedido. Confira também a compatibilidade de indPres e os dados completos do intermediador.
Em ambos os caminhos, corrija o ponto de origem: pedido, natureza de operação, importação ou vínculo cadastral. Alterar manualmente apenas uma cópia do XML, sem corrigir a rotina que o produz, pode deixar o sistema repetindo o mesmo erro nas próximas emissões.
Um exemplo de cadastro residual
Uma loja vende acessórios tanto no próprio site quanto em marketplace. Ao copiar um pedido antigo para lançar uma venda direta, o operador mantém o cadastro da plataforma ligado à nota. A opção de intermediação, porém, está corretamente marcada como zero.
O XML termina levando infIntermed com dados da venda anterior. Para esse pedido direto, a correção é remover o vínculo indevido que gera o grupo, preservando o indicador condizente com a operação. A informação de pagamento, se correta e necessária, continua em seu grupo próprio; não se deve excluir indiscriminadamente dados de outras partes da nota.
Agora imagine a situação inversa: o cadastro do marketplace pertence à venda atual, mas uma configuração padrão força indIntermed=0 para todos os pedidos. A investigação deve corrigir esse padrão para o canal intermediado. A aparência semelhante do erro na tela não torna iguais as duas soluções.
Pagamento, entrega e software têm funções diferentes
Um site próprio pode usar uma empresa para processar cartões e outra para entregar mercadorias. Essas contratações não justificam inserir os respectivos CNPJs como intermediador comercial. O fabricante do emissor e o fornecedor que hospeda a loja também não assumem automaticamente esse papel.
A NT distingue o CNPJ de YB02 do CNPJ da instituição de pagamento em YA05. Os valores podem coincidir quando uma mesma empresa intermedeia a transação e faz o repasse financeiro, mas um campo não substitui o outro.
Se a operação envolve uma cadeia de marketplaces, a identificação deve seguir o intermediador que encaminhou a informação da venda ao vendedor, conforme a orientação oficial. Essa regra não deve ser confundida com a escolha de qualquer serviço técnico que encaminhou uma mensagem eletrônica. É preciso confirmar a função comercial de quem será identificado.
Operação presencial também pede atenção
A palavra “site” na mensagem da rejeição não autoriza concluir que toda operação presencial deve ficar sem dados de intermediador. A NT 2020.006 explica que, quando uma operação presencial tem intermediação, indIntermed=1 e as informações correspondentes devem ser preenchidos.
A retirada da exigência automática de B25c-10 para indPres=1 não elimina esse dever. Presença, indicador de intermediador e grupo detalhado devem ser coerentes entre si. Se o usuário apaga o indicador e mantém o grupo, não resolveu essa coerência; apenas mudou uma das peças.
Os modelos 55 e 65 estão expressamente abrangidos por YB01-20 na versão 1.31. O histórico atribui a inclusão do modelo 65 à v1.10. Já o adiamento de B25c-10 para produção em 04/04/2022 diz respeito à 434, não a uma nova data universal para a 439. Artigos de suporte antigos precisam ser lidos com esse recorte.
Como validar a correção
Compare o XML antes e depois do ajuste. Para uma venda direta, verifique se infIntermed realmente deixou de ser gerado. Um grupo vazio ou campos sem conteúdo não equivalem a retirar o grupo e podem causar falhas de esquema. Para uma venda intermediada, confira indicador, CNPJ e idCadIntTran, que identifica o perfil do vendedor, não o comprador.
O CNPJ alfanumérico acrescenta um cuidado cadastral: a NT 2026.004 v1.01 atualizou YB02 para caracteres, mantendo 14 posições. Essa alteração não torna o grupo obrigatório para operações diretas. Também não justifica trocar o CNPJ da plataforma por outro apenas porque o emissor ainda trata o campo como numérico.
Depois de transmitir novamente, confira a resposta completa e o protocolo aplicável. Se a 439 persistir apesar de os campos parecerem coerentes, verifique se o sistema enviou a versão regenerada do XML, qual ambiente recebeu o arquivo e se o código veio efetivamente da autorização. Esses elementos permitem ao suporte investigar o caso sem alterar artificialmente a venda.
Fontes e base documental
Conferência em 10/10/2026, usando NT 2020.006 v1.31 e NT 2026.004 v1.01 preservadas em 09/10/2026. As referências práticas foram lidas; rótulos de versão e cronogramas não corroborados por documento oficial não foram adotados.