Voltar para o blog

NF-e e NFC-e

Rejeição 371 no acesso ao XML: transportador autorizado sem habilitação

A rejeição 371, “CNPJ/CPF Autorizado não é emitente de CT-e”, pertence ao evento Ator Interessado na NF-e, código 110150. Ela aponta para a pessoa indicada como autorizada a acessar o XML. Não significa, por si só, que a NF-e de venda foi rejeitada ou que o vendedor deveria emitir um documento de transporte.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 371 no acesso ao XML: transportador autorizado sem habilitação.

A rejeição 371, “CNPJ/CPF Autorizado não é emitente de CT-e”, pertence ao evento Ator Interessado na NF-e, código 110150. Ela aponta para a pessoa indicada como autorizada a acessar o XML. Não significa, por si só, que a NF-e de venda foi rejeitada ou que o vendedor deveria emitir um documento de transporte.

O evento serve para permitir acesso aos dados do documento por transportadores participantes da operação. A tentativa é analisada pelo serviço de eventos do Ambiente Nacional. Para diagnosticar, guarde o XML do evento, sua resposta individual, a chave referenciada, o ambiente e a identificação de quem deveria receber o acesso.

Quem é o autorizado e quem é o autor?

O autor é quem apresenta o evento. O autorizado é o CNPJ ou CPF informado dentro de detEvento/autXML, que receberia acesso ao documento. As duas posições precisam ser conferidas separadamente.

A regra 4P24-10 consulta o Cadastro Centralizado de Contribuintes, CCC, para verificar o autorizado. Ela rejeita quando esse participante não é emitente de CT-e em nenhum modal ou não está ativo para a UF. Um cadastro empresarial existente não basta, isoladamente, para demonstrar a habilitação exigida pelo serviço.

Já a rejeição 448 avalia o autor quando ele atua como transportador contratado, tpAutor=3. Trocar o certificado do vendedor para tentar resolver a 371 pode atingir a identidade errada e criar outros problemas. O diagnóstico deve começar pelo autorizado indicado no evento.

A NT 2020.007 v1.40 retirou cOrgaoAutor da chave de consulta da regra 371. Esse campo continua presente no leiaute e aparece em outras validações, inclusive na 448. Não é correto remover a tag do evento ou alterar a UF do autor para “encontrar” o transportador. NT 2020.007 v1.40, página 11

Como investigar sem trocar participantes

Primeiro, confirme o estabelecimento ou a pessoa efetivamente contratada. Um nome comercial pode corresponder a mais de um cadastro, e a seleção automática do sistema pode apontar para outro participante. Compare o cadastro de origem com o conteúdo de autXML, sem presumir que a matriz e todas as filiais possuam a mesma habilitação operacional.

Depois, verifique a situação no cadastro fiscal pertinente. CPF válido, CNPJ ativo na Receita Federal ou atividade econômica relacionada a transporte não substituem a verificação de habilitação como emitente de CT-e utilizada pela regra. Se houver divergência entre o cadastro estadual e a resposta centralizada, reúna a evidência e encaminhe a análise ao responsável cadastral ou ao suporte oficial.

A regularização necessária deve corresponder à atividade real e às exigências aplicáveis. Não se deve cadastrar uma empresa como transportadora apenas para obter XML, informar outra empresa habilitada ou emprestar um certificado. Também não é adequado alterar o transportador da operação só para fazer a validação passar.

Um exemplo hipotético

Uma distribuidora fictícia já tem sua NF-e autorizada. Depois, identifica a transportadora contratada e solicita o acesso pelo evento 110150. O sistema seleciona, por engano, o cadastro de uma empresa de apoio administrativo com nome parecido. O evento retorna 371.

Nesse cenário, a correção é identificar o cadastro verdadeiro do transportador e verificar sua habilitação antes de reenviar o evento. Não é necessário concluir que a venda perdeu a autorização. Tampouco seria correto usar qualquer transportadora habilitada: o acesso deve refletir quem participa daquela operação.

Se a identificação enviada já estiver correta, a próxima etapa é investigar a situação cadastral. Repetir o evento sem alteração ou esclarecimento do cadastro não resolve a condição rejeitada.

Condições do evento que continuam importantes

A identificação correta do autorizado não dispensa as demais regras. A geração pelo emitente, pelo destinatário ou pelo transportador contratado segue condições próprias. Para o destinatário, a modalidade de frete é relevante; na subcontratação ou no redespacho, devem existir as autorizações pertinentes para liberar acesso a outro transportador.

O leiaute contém um autorizado por evento e sequência de 1 a 20. O prazo documentado para o evento é de seis meses após a autorização da nota. Quando emitente ou destinatário permitem que o transportador autorize outros participantes, tpAutorizacao e a condição de uso precisam refletir essa decisão real. Essas permissões não devem ser ampliadas apenas para solucionar um erro cadastral.

Os códigos ajudam a separar problemas: 323/325 tratam da validade do identificador autorizado; 421/422, da indicação do próprio emitente ou destinatário; 423, de acesso já concedido. A 371 permanece ligada à habilitação do transportador autorizado. Leiaute e regras do evento

NF-e, NFC-e e disponibilidade do XML

O contexto usual desse evento é o transporte associado à NF-e modelo 55. Entretanto, a documentação atual risca a antiga rejeição que limitava a chave exclusivamente ao modelo 55 e apresenta validação para modelos 55 ou 65. Portanto, não se deve manter um bloqueio local baseado apenas na regra eliminada.

Essa aceitação na validação da chave não garante, sozinha, distribuição nacional do XML de uma NFC-e. É preciso separar o registro do evento, a disponibilidade do documento no Ambiente Nacional e o serviço de distribuição efetivamente aplicável. A orientação não autoriza prometer download de qualquer modelo em qualquer UF. NT 2020.007, página 9

O grupo autXML que integra a nota na emissão também não deve ser confundido com o evento posterior. O evento 110150 é voltado ao transportador; não funciona como procuração genérica para liberar qualquer contador, software ou terceiro após a autorização.

Depois da correção

Reenvie pelo sistema, com assinatura válida do autor apropriado, e leia o resultado individual. Um lote processado não significa que seu evento foi aceito. Depois do registro, a obtenção do XML ocorre em outra etapa, pelo serviço correspondente, respeitando autenticação e disponibilidade.

A distribuição tem limitações próprias, inclusive janela documental e geração de NSU. O prazo de seis meses para registrar o evento não equivale a seis meses de garantia de recuperação do XML. NT 2014.002, distribuição de DF-e

A NT 2026.004 adapta o CNPJ autorizado no evento ao formato alfanumérico. Preserve letras, zeros e a identidade correta; o CPF continua distinto. Aceitar o novo formato não concede habilitação como transportador. NFF, avulsa e PAA também não transformam automaticamente seus usuários ou provedores em autorizados aptos nesse evento. NT 2026.004 v1.01

Fontes e atualização

Conferência documental em 10/10/2026. A v1.40 registra homologação em 25/07/2024 e produção em 01/08/2024. Guias práticos lidos: TecnoSpeed, Focus NFe e Oobj/Avalara. Versões antigas e textos riscados foram confrontados com a especificação vigente.

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.