Rejeição 585: transportador sem autorização para registrar o evento

A rejeição 585, no evento Ator Interessado, indica um problema na autorização relacionada ao autor e ao documento informado. O evento pode ser necessário quando uma transportadora precisa liberar o acesso ao XML para outra transportadora da mesma operação. Ter contrato de frete, conhecer a chave ou possuir certificado válido não substitui o vínculo exigido pelo serviço.

O primeiro cuidado é identificar a operação rejeitada. Aqui, o assunto é o evento 110150, “Ator Interessado na NF-e”, documentado na NT 2020.007. A rejeição desse evento não cancela a nota previamente autorizada nem exige, por si só, emitir outra nota. Também não deve ser confundida com um código igual apresentado na emissão de CT-e.

O que a regra efetivamente verifica

Na NT 2020.007 v1.40, a regra 3P15-21 conserva como condição a inexistência de evento no banco de dados para o autor atual e a chave indicada. Portanto, a investigação deve conferir o histórico reconhecido pelo Ambiente Nacional para aquela identidade e aquele documento.

Há uma diferença relevante em relação a explicações antigas: o trecho que limitava expressamente a regra a tpAutor=3 e descrevia uma busca com tpAutorizacao=1 está riscado no PDF. Ele não pode ser reproduzido como se ainda fosse a redação vigente. A verificação de uma autorização anterior com tpAutorizacao=0 permanece em outra regra, 3P15-20, associada à rejeição 831. NT 2020.007 v1.40, página 11.

Essa edição não explica, na própria linha 585, como conciliar o teste com o primeiro evento gerado pelo emitente ou destinatário, previsto na finalidade da NT. Se o retorno surgir nessa situação, peça ao fornecedor a identificação do contrato aplicado e a análise do XML. Não crie um evento anterior fictício nem conclua que qualquer autor precisa previamente autorizar a si mesmo.

Quem autoriza quem

O leiaute distingue três posições: emitente, destinatário e transportador contratado. A cadeia deve corresponder à operação real:

• O emitente pode identificar o transportador que receberá acesso ao XML

• O destinatário pode gerar o evento quando o transporte for de sua responsabilidade. A regra específica verifica sua identidade e exige modalidade de frete 1 ou 4

• Em redespacho ou subcontratação, o transportador contratado pode autorizar outro participante da mesma operação, observadas as permissões recebidas e as demais validações

Para emitente ou destinatário, tpAutorizacao é obrigatório: o valor 0 não permite que o transportador beneficiário autorize outros; o valor 1 permite, acompanhado da declaração xCondUso prevista no leiaute. Quando o autor não é emitente nem destinatário, o preenchimento de tpAutorizacao não é permitido. Assim, o transportador não pode inserir 1 no próprio envio para conceder a si mesmo um poder que não recebeu.

A autorização é vinculada à chave. Um evento de outra nota, mesmo envolvendo as mesmas empresas, não comprova a permissão para o documento rejeitado. Tampouco receber acesso ao XML significa poder delegá-lo indefinidamente.

Autor, beneficiário e certificado são informações diferentes

No XML, o CNPJ ou CPF diretamente em infEvento identifica quem está praticando o ato. Em detEvento/autXML, identifica quem receberá acesso. Trocar esses campos pode fazer o sistema procurar uma autorização para a pessoa errada.

O certificado de transmissão autentica a conexão; a assinatura do evento também tem suas próprias verificações. A NT prevê comparação entre o CNPJ-base do autor e o certificado de assinatura, ou a correspondência de CPF aplicável. Passar nessa etapa não demonstra que o autor recebeu permissão para autorizar outro transportador.

Existem ainda controles cadastrais separados: 448 verifica o transportador autor; 371, o beneficiário. A v1.40 retirou cOrgaoAutor da chave de consulta cadastral da regra 371, não da identificação geral do evento nem da regra 448. Não altere a UF para simular habilitação e não use identidade ou credenciais de outra empresa.

Um roteiro para resolver sem criar outro problema

1. Guarde o retorno completo e o XML efetivamente enviado. Identifique tpEvento, tpAutor, chave, CNPJ/CPF do autor, beneficiário, ambiente, UF e versão do integrador

2. Compare esses dados com a nota e os eventos já registrados. Confira se a permissão diz respeito à mesma chave e ao autor que está transmitindo agora

3. Se a autorização legítima estiver ausente, encaminhe a regularização ao emitente ou destinatário responsável, conforme a contratação real. A decisão de permitir novas autorizações deve ser expressa; não a marque automaticamente

4. Se houver autorização anterior, confira seu resultado individual e a permissão concedida. Um arquivo preparado no ERP ou um lote processado não prova registro bem-sucedido

5. Corrija apenas um erro demonstrado de cadastro, seleção de empresa ou montagem do evento. Antes de reenviar, verifique tentativas anteriores, sequencial e prazo; depois arquive o retorno individual e o protocolo

Considere uma transportadora contratada para entregar determinada carga, com redespacho. Ela recebeu acesso à nota, mas a empresa responsável não permitiu autorizar outros transportadores. A correção não é mudar seu papel para “emitente”. É esclarecer a autorização com quem pode concedê-la e tratar o retorno correspondente, inclusive a 831 quando aplicável.

Modelo, prazo e download precisam de verificações próprias

A NT estabelece seis meses, contados da autorização da nota, para gerar o evento. Isso não equivale à janela de distribuição: a NT 2014.002 v1.40 prevê disponibilidade dos documentos por até 90 dias após a recepção no Ambiente Nacional. Registrar um evento não recupera automaticamente um XML fora desse período.

Na página 9 da NT do Ator Interessado, a restrição antiga ao modelo 55 está riscada; permanece a validação da chave com modelos 55 ou 65. Entretanto, o serviço de distribuição possui contrato próprio, e sua consulta por chave rejeita modelo diferente de 55. Não se pode transformar essa validação genérica em promessa de download nacional de NFC-e.

O CNPJ alfanumérico também exige integração atualizada. A NT 2026.004 v1.01 altera campos de CNPJ do autor e do beneficiário para tipo caractere. Preserve a identificação completa, inclusive letras e zeros; não faça conversão para número. Essa alteração não muda a finalidade do evento nem transforma CPF em CNPJ.

Fontes e alcance

A base oficial é a NT 2020.007 v1.40, com cronograma de produção em 01/08/2024 para seu ajuste, combinada com a NT 2014.002 v1.40 e a NT 2026.004 v1.01. Foram relidas cópias preservadas do corpus de 09/10/2026; isso não certifica implantação em toda UF ou versão de sistema.

Também foram lidos TecnoSpeed, Focus NFe e Oobj/Avalara. São guias do evento: os dois primeiros discutem a mudança da 585; o terceiro, de 2021, oferece contexto histórico. Datas antigas, afirmações genéricas sobre modelos e expressões como “a qualquer momento” não substituem as condições oficiais acima.