Voltar para o blog

NF-e e NFC-e

Rejeição 423 quando o transportador já está autorizado a acessar o XML

A rejeição 423 informa que o CNPJ ou CPF indicado já está autorizado a acessar o XML da NF-e. No evento Ator Interessado, código 110150, a providência costuma ser localizar a autorização existente e investigar a obtenção do arquivo, em vez de insistir em conceder o mesmo acesso.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 423 quando o transportador já está autorizado a acessar o XML.

A rejeição 423 informa que o CNPJ ou CPF indicado já está autorizado a acessar o XML da NF-e. No evento Ator Interessado, código 110150, a providência costuma ser localizar a autorização existente e investigar a obtenção do arquivo, em vez de insistir em conceder o mesmo acesso.

O retorno rejeita a nova solicitação de evento. Ele não cancela a nota, não demonstra que o acesso anterior foi removido e não significa que o download já aconteceu. Para resolver, separe o direito de acesso, o registro do evento e a resposta do serviço de distribuição.

As duas origens possíveis da autorização

A NT 2020.007 v1.40 apresenta dois caminhos para a mesma rejeição. Na regra P24-18, o identificador autorizado no evento já consta no grupo autXML da nota, identificado como GA01 no leiaute. O acesso foi previsto no próprio documento, antes da tentativa posterior.

No segundo caminho, a consulta ao banco de eventos encontra autorização para o mesmo CNPJ ou CPF e a mesma chave, pelo evento 110150. Essa verificação aparece como 3P15-10 no bloco “Banco de Dados: Evento 2”. O transportador já havia sido autorizado por outro registro desse tipo. NT 2020.007 v1.40, página 11

Portanto, olhar apenas o autXML da nota pode deixar o diagnóstico incompleto. Se o identificador não estiver ali, examine os eventos anteriores. A autorização posterior não precisa aparecer como alteração do XML original: o evento é um registro próprio associado ao documento.

A diferença para duplicidade de evento

A 573 identifica um evento já existente pela combinação documentada de chave, tipo de evento, sequência e órgão autor. A 423 olha para o acesso do participante, que pode ter sido concedido na nota ou em outro evento.

Por isso, aumentar nSeqEvento para fugir da duplicidade não resolve um acesso que já existe. O sistema pode produzir uma solicitação formalmente diferente e continuar recebendo 423. Também não se deve trocar o CNPJ por outro estabelecimento ou alterar o CPF apenas para obter uma resposta diferente.

Na emissão da nota, as rejeições 324 e 326 verificam se o CNPJ ou CPF incluído em autXML coincide com o do destinatário. Esse é outro serviço e outro momento. A correção dessa coincidência antes da autorização não deve ser aplicada indiscriminadamente a uma nota já autorizada, muito menos mediante remoção de acesso legítimo.

Um roteiro para conciliar o sistema

Primeiro, confirme a chave, o ambiente e a pessoa que realmente precisa do XML. Confira se a aplicação está consultando o mesmo estabelecimento selecionado no evento. Nome comercial parecido não comprova identidade, e uma tentativa feita em homologação não demonstra autorização em produção.

Depois, examine o autXML do documento autorizado e os registros anteriores do evento 110150. Guarde o protocolo e o retorno individual que comprovem a situação encontrada. Não marque a última tentativa rejeitada como se tivesse sido aceita; registre no controle interno que o acesso foi concedido anteriormente, quando houver essa evidência.

Se a autorização existente estiver correta, encerre as tentativas redundantes e passe à investigação da distribuição. Caso a aplicação continue oferecendo o botão de autorização, revise como ela identifica acessos já concedidos. Evitar reenvios desnecessários melhora o diagnóstico sem mudar permissões fiscais.

Se houver divergência entre o retorno e o histórico disponível, preserve os registros e encaminhe uma análise técnica com dados mínimos. Não publique XML completo, certificados ou identificadores desnecessários em fóruns. A ausência de um evento na tela local não prova que ele inexiste no Ambiente Nacional.

Exemplo de uma repetição entre equipes

Uma distribuidora fictícia inclui a transportadora contratada no autXML ao emitir a nota. Mais tarde, outra equipe tenta liberar esse mesmo participante pelo evento 110150 e recebe 423. A equipe deve localizar a autorização no documento e verificar por que a transportadora ainda não recebeu o arquivo.

Em outro cenário, a transportadora não consta no autXML original, mas um evento anterior já lhe concedeu acesso. Reenviar com nova sequência não acrescenta a permissão pretendida. A conciliação precisa considerar as duas origens para evitar diagnósticos contraditórios entre faturamento e logística.

Por que o XML ainda pode não aparecer

A distribuição nacional é regulamentada pela NT 2014.002. Ela exige autenticação compatível com o ator e estabelece quais documentos cada participante recebe. Um acesso autorizado não garante que qualquer ferramenta, certificado ou consulta retorne imediatamente o arquivo. NT 2014.002 v1.40, páginas 4 a 7

Os documentos ficam disponíveis por até 90 dias após a recepção pelo Ambiente Nacional, conforme essa especificação. A geração de NSU também tem condições próprias, inclusive para usuários novos ou que ficaram sem utilizar o serviço. Não prometa recuperar todo o histórico simplesmente repetindo o evento.

O prazo de seis meses para apresentar o evento 110150 não equivale a seis meses garantidos de recuperação do XML. O grupo de transporte da nota também pode estabelecer um papel de acesso; confira essa condição antes de planejar uma autorização, sem apresentá-la como um terceiro gatilho da 423 que a regra focal não descreve.

Ter acesso tampouco significa poder autorizar outro transportador. As condições de subcontratação e redespacho, incluindo a permissão pertinente, são verificadas separadamente. Não remova um acesso existente nem tente recriá-lo com poderes maiores apenas para solucionar uma falha de download.

O que continua válido nas versões atuais

Os dois ramos da 423 estão preservados na NT 2020.007 v1.40. A antiga rejeição que limitava a chave ao modelo 55 aparece riscada; a validação atual admite 55 ou 65. Isso não comprova distribuição nacional do XML de NFC-e. A aplicação deve verificar o serviço e a disponibilidade correspondentes ao modelo.

A exclusão de cOrgaoAutor na v1.40 alcança a chave de consulta cadastral do autorizado na regra 371, não o campo inteiro do evento. A NT 2026.004 também atualiza o CNPJ autorizado para formato alfanumérico. Preserve a identidade completa; mudanças de formato não autorizam criar outro participante para contornar a duplicidade. Atualização de schema, página 14

Conferência documental em 10/10/2026, sem afirmar implantação operacional universal. Foram lidos os guias da TecnoSpeed, Focus NFe e Oobj/Avalara, confrontados com as versões oficiais preservadas. A solução depende do acesso real e do serviço usado, não apenas do número isolado da rejeição.

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.