Rejeição 324: retire o CNPJ do destinatário da lista de acesso ao XML

A rejeição 324 acontece quando o CNPJ do destinatário também aparece no grupo de pessoas autorizadas a acessar o XML. A correção é localizar essa repetição e retirar a ocorrência indevida da lista de acesso, preservando a identificação verdadeira do destinatário da nota.

A comparação está na regra GA02-20 do MOC 7.0, página 88: dest/CNPJ é confrontado com autXML/CNPJ, na autorização de NF-e e NFC-e, modelos 55 e 65. O código não significa que existe outra nota com a mesma numeração, nem que o CNPJ esteja irregular na Receita Federal.

Dois campos, duas finalidades

O grupo dest informa quem é o destinatário da operação. Já autXML contém pessoas autorizadas a acessar o arquivo fiscal. Copiar o CNPJ do primeiro para o segundo não acrescenta uma autorização necessária para aquela pessoa e provoca a rejeição documentada.

A conferência deve considerar o CNPJ completo, incluindo o estabelecimento. A GA02-20 não manda comparar apenas a raiz de oito posições e não descreve toda repetição entre participantes como 324. Uma filial, um escritório de contabilidade e uma transportadora não são intercambiáveis. Mesmo quando pertencem a um grupo econômico, seus identificadores não devem ser substituídos para eliminar a mensagem.

O emitente também tem campo próprio, emit/CNPJ. Encontrar seu CNPJ em uma configuração chamada Contabilidade não permite concluir, isoladamente, que essa é a causa da 324. É preciso verificar se o valor coincide com o destinatário daquele XML. Essa distinção evita corrigir o cadastro errado em operações nas quais os papéis se sobrepõem.

Por que o destinatário pode aparecer na lista

Um emissor pode montar autXML a partir de parâmetros fixos da empresa, do cadastro do cliente ou de informações recebidas de outro sistema. Assim, o operador pode selecionar o cliente corretamente e ainda transmitir uma autorização redundante sem perceber.

Imagine uma venda para o escritório que presta serviços contábeis à empresa. Ele já consta na lista padrão de pessoas autorizadas. Nessa venda específica, o mesmo estabelecimento passa a ser destinatário. A solução é impedir a repetição naquele documento, preservando o acesso legítimo previsto para outras operações e eventuais exigências estaduais.

Outra possibilidade é a integração copiar automaticamente o documento do cliente para todos os campos chamados CPF/CNPJ. O problema precisa ser corrigido no mapeamento, pois remover a entrada manualmente de uma nota não impede a próxima ocorrência.

A Bling localiza a edição na seção de pessoas autorizadas. A Alterdata usa o campo Autorização de download. São exemplos de nomes de tela para a mesma investigação, sem dispensar a análise do arquivo.

Roteiro para corrigir sem apagar informações necessárias

1. Confirme o retorno 324 e a tentativa de autorização correspondente. Registre modelo, ambiente e versão do emissor.

2. Identifique dest/CNPJ no XML rejeitado e confira se representa o destinatário real da operação.

3. Percorra as ocorrências de autXML/CNPJ e encontre o mesmo identificador completo.

4. Retire a ocorrência redundante da lista que alimenta esse documento. Não altere o destinatário correto e não substitua o CNPJ por outro escolhido apenas para passar na validação.

5. Atualize a nota rejeitada, gere novamente o XML e confira se a configuração automática não recolocou o valor.

6. Deixe o emissor assinar e transmitir a versão corrigida. Acompanhe a resposta final, pois outras validações podem ser apontadas depois.

A Oobj destaca a retirada apenas da ocorrência que contém o destinatário. A página apresenta o identificador da regra de forma divergente; para a referência técnica, prevalece GA02-20, confirmado no MOC.

O leiaute permite até dez ocorrências de autXML, com CNPJ ou CPF em cada uma. Não é preciso limpar a lista inteira. Antes de excluir autorizações adicionais, confirme sua finalidade, a legitimidade dos beneficiários e eventual obrigação estadual de identificar a contabilidade. As regras 7GA01-10 e 7GA01-20 do MOC são próprias desse controle para o modelo 55 e dependem da UF.

Atenção aos efeitos dentro do sistema

A nota rejeitada pode estar vinculada a lançamentos internos. A documentação da Bling, por exemplo, pede conferir contas e estoque antes da edição. Isso não transforma estorno em solução fiscal universal: é uma etapa particular do programa, a ser feita somente quando aplicável e com conciliação dos registros.

Também não crie automaticamente outra venda ou outra nota para fugir do erro. Se houve mais de uma tentativa, consulte a situação do documento cujo resultado não está claro. A repetição de acesso ao XML não é uma autorização para duplicar faturamento, estoque ou contas a receber.

Persistindo a mensagem, compare o arquivo transmitido após a correção com o anterior. A tela pode estar atualizada enquanto uma fila de integração ainda usa a versão antiga. Encaminhe ao suporte a indicação dos campos coincidentes e o retorno, por canal seguro, sem divulgar o XML completo desnecessariamente.

CNPJ alfanumérico e serviços diferentes

O formato atual de CNPJ admite letras nas primeiras doze posições. A NT 2026.004 v1.01, página 6 atualiza tanto dest/CNPJ quanto autXML/CNPJ. A comparação precisa preservar a inscrição completa; remover letras ou zeros não é saneamento cadastral. A rejeição de validade do CNPJ autorizado é 323, distinta da repetição tratada aqui.

O evento 110150, Ator Interessado na NF-e, também possui grupo autXML, mas segue outras regras. Na NT 2020.007 v1.40, indicar o destinatário como autorizado está associado ao código 422. Não transporte automaticamente o procedimento da 324 para esse evento nem reemita uma nota autorizada porque seu evento foi rejeitado.

Por fim, “já autorizado” não significa download imediato e sem condições em qualquer canal. O NFeDistribuicaoDFe tem autenticação, documentos disponíveis por papel e manifestação do destinatário nas hipóteses previstas. A regra de autorização da nota não substitui essas condições nem estende esse serviço automaticamente à NFC-e.

Referência documental: 09/10/2026. Conferir versões, UF e ambiente; a marcação obrigatória no MOC não certifica execução uniforme em todos os autorizadores.