Rejeição 326: como remover o CPF do destinatário da autorização de XML

A rejeição 326 surge quando o CPF do destinatário foi repetido na lista de pessoas autorizadas a acessar o XML. Ela pede uma revisão de papéis no documento: o destinatário deve continuar identificado corretamente, enquanto sua entrada redundante em autXML precisa ser retirada.

A regra GA03-20 do MOC 7.0, página 88 está documentada para autorização de NF-e e NFC-e, modelos 55 e 65. O confronto é entre dest/CPF e autXML/CPF. O CPF pode estar perfeitamente válido e, mesmo assim, a repetição causar o retorno.

Não confunda repetição com CPF inválido

A validade do CPF autorizado é tratada pela rejeição 325. Já a 326 verifica se o identificador informado na lista é o do destinatário. Alterar seus verificadores, trocar a pessoa ou retirar a identificação correta do cliente não resolve adequadamente esse problema.

Também não é uma indicação de nota duplicada, bloqueio cadastral do consumidor ou incompatibilidade de endereço. Antes de seguir um procedimento encontrado pelo número do erro, confira a mensagem integral, o modelo e o serviço que responderam. Números isolados podem aparecer em outros contextos.

No XML, dest e autXML são grupos separados. O primeiro identifica o destinatário; o segundo registra autorizações de acesso. O leiaute de autXML admite até dez ocorrências, cada uma com CPF ou CNPJ. O limite não exige que a empresa preencha todas as posições nem autoriza incluir terceiros sem necessidade.

Quando o cadastro padrão encontra o destinatário

Um caso ilustrativo é a venda para uma pessoa que também atua como contador da empresa. Seu CPF está na lista padrão de acesso e passa a constar como destinatário dessa nota. A integração precisa tratar essa coincidência sem mudar quem realizou a compra e sem apagar indiscriminadamente configurações necessárias para outras operações.

A TOTVS, na documentação do WinThor, descreve esse tipo de situação e aponta vínculos de pessoas autorizadas no cadastro do cliente. A orientação é útil para localizar a origem, mas os nomes e números de rotinas não se aplicam a todo emissor.

Outro cenário é a implantação de uma integração que copia o CPF do comprador para qualquer campo de documento pessoal. O pedido comercial está correto, porém o mapeamento cria autXML sem necessidade. O ajuste deve impedir a montagem equivocada nas notas seguintes, além de atualizar aquela que foi rejeitada.

A Softdata orienta conferir a lista de pessoas autorizadas nos parâmetros da filial. A Alterdata localiza o ajuste na autorização de download da nota. As duas abordagens mostram por que vale examinar tanto os parâmetros quanto o documento preparado.

Passo a passo para a empresa

1. Guarde o XML e o retorno 326 da tentativa rejeitada. Confira a data, o ambiente e a nota associada, evitando trabalhar sobre arquivo antigo.

2. Verifique dest/CPF e confirme se é o identificador verdadeiro do destinatário da operação.

3. Examine cada autXML/CPF e localize o mesmo CPF. A comparação deve usar o identificador completo, preservando seus 11 algarismos, inclusive zeros iniciais.

4. Remova a ocorrência redundante na origem adequada. Não substitua o CPF por documento de familiar, sócio, funcionário ou outra pessoa para contornar a regra.

5. Atualize o documento rejeitado e gere um novo XML pelo emissor. Confira se a lista automática não recolocou a informação.

6. Deixe o programa assinar e transmitir a versão corrigida, acompanhando o retorno final.

Se o emissor mantém notas em fila, uma alteração cadastral pode não alcançar o arquivo já gerado. Peça ao suporte para confirmar qual versão foi transmitida. A conclusão exige comparar o conteúdo enviado, e não apenas observar que a tela deixou de mostrar o CPF.

Também verifique os efeitos internos da edição. Uma nota rejeitada pode ter pedido, estoque e financeiro associados no sistema. Não duplique esses registros criando outra operação por impulso. Quando houver tentativa anterior sem resultado conhecido, consulte a situação antes de repetir o envio.

Preserve as autorizações necessárias

Retirar a entrada do destinatário não implica eliminar os demais autorizados. Cada permanência precisa ter finalidade legítima, e cada exclusão deve considerar a configuração da empresa e as exigências aplicáveis.

O MOC, página 138, prevê controles 486 e 487 para identificação da contabilidade em NF-e, opcionais a critério da UF. Por isso, a solução não deve ser apresentada como “deixe sempre a lista vazia”. Havendo conflito entre o cadastro contábil e os papéis daquela operação, o responsável fiscal e o suporte precisam conferir a regra estadual e o XML gerado.

Um CPF ausente ou desconhecido também não deve ser substituído por número de teste. O cadastro precisa preservar identidade, legitimidade e finalidade do acesso, mesmo quando uma validação matemática aceitaria outro valor.

“Já autorizado” tem limites

A expressão da rejeição não promete que o destinatário conseguirá baixar imediatamente o XML completo em qualquer sistema. O NFeDistribuicaoDFe, na NT 2014.002 v1.40, tem autenticação, documentos distribuídos por papel e manifestação do destinatário nas hipóteses previstas.

O emitente precisa guardar seus próprios arquivos; a tabela desse serviço não oferece a NF-e emitida para recuperação pelo próprio emitente. Transportadores e terceiros possuem condições diferentes das do destinatário. A existência de autXML na autorização dos modelos 55 e 65 não permite presumir que a distribuição nacional de NF-e funciona igualmente para NFC-e.

Há ainda o evento 110150, Ator Interessado na NF-e, voltado ao transportador. A NT 2020.007 v1.40, página 10 associa a indicação do destinatário como autorizado ao código 422. O procedimento da 326 não deve ser transferido automaticamente para esse evento, que possui autor, permissões e prazo próprios.

Se precisar de suporte, use canal seguro e compartilhe somente o necessário para comparar os campos. Não exponha CPF completo, certificados ou o arquivo fiscal em espaços públicos. A correção estará bem encaminhada quando a repetição desaparecer do XML e sua origem deixar de recriá-la, sem alterar a identidade do destinatário.

Referência documental: 09/10/2026. Conferir versão, UF e ambiente; a documentação não certifica execução uniforme das regras em todos os autorizadores.