Rejeição 831: transportador contratado não autorizado a liberar acesso à NF-e

A rejeição 831 ocorre no evento Ator Interessado na NF-e — Transportador, código 110150, quando a autorização registrada não permite ao transportador liberar o acesso a outro transportador. A regra 3P15-20 da NT 2020.007 v1.40 consulta a base de eventos: existe um registro com tpAutorizacao=0 para a identificação autorizada correspondente ao autor do evento atual.

Por isso, o diagnóstico não se limita ao indicador de uma tela ou ao XML da última tentativa. É necessário conferir qual permissão foi registrada para aquela nota e para o CNPJ ou CPF que agora tenta autorizar outra pessoa. Ter acesso ao XML e poder conceder acesso a terceiros são permissões diferentes.

O que pode ser autorizado pelo evento

O emitente pode identificar o transportador que terá acesso ao XML. O destinatário também pode registrar o evento nas condições previstas para sua participação no transporte. Havendo subcontratação ou redespacho, o transportador contratado poderá indicar outro transportador participante da mesma operação, desde que atenda à cadeia de autorização e às demais regras do serviço.

O campo tpAutorizacao expressa uma decisão adicional do emitente ou destinatário. Com 0, não permite que o transportador autorizado libere o documento a outros transportadores. Com 1, permite essa extensão. O valor 0 não significa cancelamento do acesso do próprio transportador, nem transforma a nota em documento fiscal cancelado.

A distinção entre as pessoas envolvidas precisa aparecer corretamente no diagnóstico. O autor é quem registra o evento; o grupo autXML identifica a pessoa que receberá acesso. O beneficiário de um evento anterior pode ser o autor de uma nova tentativa. É a permissão associada a essa identidade que interessa à verificação da 831.

Por onde começar a conferência

Guarde o retorno completo e a mensagem enviada. Confirme que se trata de tpEvento=110150, da chave correta e do ambiente esperado. Verifique o CNPJ ou CPF do autor, sua participação real na operação e o transportador indicado como novo beneficiário. Um cadastro local com nome semelhante não comprova igualdade dos documentos de identificação.

Depois, localize os registros e protocolos dos eventos relacionados àquela nota. Compare o beneficiário autorizado anteriormente com o autor da tentativa rejeitada e confira o valor de tpAutorizacao no registro pertinente. A pergunta central é se essa pessoa recebeu permissão para estender o acesso, e não apenas se conseguiu baixar o XML em algum momento.

Quando a aplicação mostra uma autorização mais ampla do que a documentada, investigue a origem da diferença. Pode haver confusão entre uma opção ainda não transmitida e um evento registrado, entre ambientes ou entre participantes da operação. Essas são possibilidades a verificar; nenhuma delas deve ser declarada como causa sem confrontar os arquivos e retornos correspondentes.

O que não resolve a rejeição

O transportador não deve tentar conceder a si próprio a permissão que falta, acrescentando tpAutorizacao=1 à mensagem. A regra P26-20 proíbe informar esse campo quando o autor não é o emitente nem o destinatário. Essa orientação, encontrada em materiais antigos, pode produzir outra inconsistência sem modificar a autorização existente.

Também não se deve trocar o tipo de autor, usar o documento de outra empresa ou alterar o XML já assinado para aparentar uma permissão diferente. Uma configuração interna não modifica o conteúdo de um evento registrado na base fiscal. O eventual certificado utilizado tampouco substitui a legitimidade do participante indicado na mensagem.

A tentativa rejeitada não autoriza cancelar ou reemitir a nota. Não demonstra que a numeração possa ser reutilizada, nem permite apagar registros anteriores para refazer a cadeia. O problema analisado é a extensão de acesso por evento, e deve ser tratado nesse contexto.

Como encaminhar uma solução legítima

Confirme primeiro se o novo transportador realmente participa da mesma operação e se o compartilhamento pretendido está autorizado pelo responsável. Se o registro existente não permite delegação, encaminhe a necessidade ao emitente ou destinatário legitimado, juntamente com a chave, as identificações envolvidas e os eventos que sustentam o diagnóstico.

Não presuma que transmitir outro evento para o mesmo beneficiário substituirá automaticamente o indicador anterior. A nota técnica também contém verificações de duplicidade e de pessoa já autorizada. O procedimento cabível para a situação deve ser confirmado no serviço e com seu suporte técnico, sem inventar uma função de alteração ou de cancelamento de autorização que o retorno 831 não documenta.

Se a identificação usada na tentativa estiver incorreta, corrija sua origem somente após comprovar qual participante deveria constar. Gere a mensagem adequada com a assinatura correspondente, preservando os registros anteriores. Se a falta de permissão for real, corrigir apenas a montagem do XML não cria o direito de delegar.

Exemplo de uma cadeia de acesso

Considere uma nota para a qual o emitente autorizou o transportador A a acessar o XML, registrando tpAutorizacao=0. Posteriormente, A tenta indicar o transportador B por causa de um redespacho. O acesso de A ao documento não inclui, nesse registro, a permissão para liberar o acesso de B; essa é a distinção relevante à 831.

A equipe deve conferir a necessidade real do redespacho e solicitar orientação ao responsável pela autorização. Não basta mudar o indicador na tentativa de A. As letras representam participantes hipotéticos: não são identificações para preencher o evento, nem promessa de que uma nova transmissão será aceita após uma única mudança.

Diferenças em relação a outros retornos

A regra atual da rejeição 585 verifica a inexistência de evento para o autor atual e a chave indicada. A 831 trata da autorização registrada com indicador 0. Já a 423 identifica pessoa que já possui acesso. São situações distintas; o aparecimento de um desses códigos não comprova uma ordem fixa de validações ou o atendimento de todos os demais requisitos.

A NT estabelece o serviço no Ambiente Nacional. A versão 1.40 mantém a validação genérica da chave para modelos 55 e 65 e exclui a antiga restrição a modelo diferente de 55. Isso não certifica disponibilidade irrestrita em qualquer aplicativo, UF ou operação. Confira modelo, ambiente, participação no transporte e demais condições do serviço efetivamente utilizado.

O prazo documental de recepção é de seis meses após a autorização da nota. O cronograma específico da versão 1.40 altera a regra cadastral 4P24-10, sem criar uma nova data particular para a 831. Após qualquer encaminhamento válido, confira o resultado individual: 128 significa lote processado, não acesso liberado. Registro, vinculação à nota e obtenção posterior do XML precisam ser verificados nos respectivos retornos.

Fontes

Pesquisa documental de 16/10/2026. NT 2020.007 v1.40, páginas 3–6 e 9–13, captura HTTP de 16/10 reutilizada. A exclusão das redações antigas foi cotejada com registro vetorial existente; não houve nova renderização, inspeção visual ou teste fiscal nesta autoria.

Apoios: InforSystem — 831, Buscador NCM — ficha 831, Focus — panorama da NT e FlexDocs — estrutura do evento. São um guia específico, uma ficha e dois materiais de contexto. Não foram adotadas a receita de o transportador informar indicador 1, a interpretação de nota não autorizada ou a liberação de numeração. Não houve consulta individual ou demonstração de funcionamento no ALRA.