Rejeição 827: informe corretamente a permissão do transportador no evento

A rejeição 827, “Obrigatório informar o tipo de autorização”, ocorre no evento Ator Interessado na NF-e, código 110150, quando o emitente ou o destinatário produz o evento sem preencher tpAutorizacao. Esse campo informa se o transportador indicado poderá autorizar outros transportadores da operação a acessar o XML.

O primeiro cuidado é identificar o serviço que devolveu a mensagem. Neste contexto, foi rejeitado um evento posterior, não necessariamente a autorização da nota fiscal. Não conclua que a NF-e deixou de existir ou que seu número pode ser reutilizado. Guarde a resposta completa e confira a chave e a situação do documento original.

O que significa o tipo de autorização

A NT 2020.007 v1.40 define dois valores para tpAutorizacao: 0, que não permite a delegação, e 1, que permite ao transportador autorizado pelo emitente ou destinatário autorizar outros transportadores a acessar o arquivo.

Essa escolha é diferente do acesso concedido ao próprio transportador indicado no evento. Informar zero não equivale a cancelar uma autorização anterior, excluir a pessoa do documento ou cancelar a NF-e. Informar um também não significa apenas “enviar o evento”: representa uma permissão adicional que precisa corresponder à decisão real do emitente ou destinatário.

O campo aparece com ocorrência opcional no leiaute, mas possui uma obrigação condicionada nas regras de negócio. A P26-10 exige seu preenchimento quando o autor é o emitente ou o destinatário. Portanto, a indicação “opcional” não autoriza omiti-lo nesse cenário.

Confira quem está produzindo o evento

O leiaute distingue três papéis em tpAutor: emitente, destinatário e transportador contratado. Os dados de quem produz a mensagem não devem ser confundidos com o CNPJ ou CPF do transportador autorizado, informado no grupo autXML do evento.

Para emitente ou destinatário, a falta de tpAutorizacao é tratada pela 827. Para autor que não seja nenhum desses dois, a P26-20 proíbe o campo e corresponde à rejeição 828. Assim, preencher o indicador em toda mensagem, sem considerar o papel do autor, pode simplesmente trocar uma rejeição por outra.

Confira os dados transmitidos, não apenas o nome mostrado no cadastro. Verifique se a integração identificou corretamente o autor e sua participação na operação. Não mude o papel para emitente nem utilize a identificação de outra empresa para conseguir enviar uma mensagem que o transportador não poderia produzir.

A condição de uso acompanha a permissão

Quando tpAutorizacao=1, a regra P27-10 exige xCondUso, a declaração de ciência sobre a permissão dada ao transportador. A documentação contém o texto da condição de uso e o sistema deve gerar a informação conforme o leiaute aplicável. Sua ausência é tratada pela 829.

Se tpAutorizacao for diferente de 1, a P27-20 não permite preencher xCondUso, situação relacionada à 830. Não envie uma declaração genérica em todos os eventos nem marque a opção mais permissiva somente para superar uma validação. Primeiro confirme qual autorização foi efetivamente decidida; depois faça a mensagem representar essa escolha.

Exemplo prático

Imagine que o emitente queira permitir que uma transportadora contratada obtenha o XML da nota, sem conceder a ela a possibilidade de autorizar outros transportadores. A integração montou o evento com os participantes corretos, mas deixou o tipo de autorização sem valor.

Confirmada essa intenção e as demais condições do serviço, a equipe deve ajustar a origem dos dados para gerar tpAutorizacao=0 e não incluir a condição de uso reservada à delegação. O exemplo não é um cancelamento de acesso nem uma orientação para preencher zero em todas as operações.

Em outro caso, se houver decisão legítima de permitir a delegação para subcontratação ou redespacho, o valor pertinente é 1, acompanhado da condição exigida. A equipe precisa confirmar a permissão antes de transmitir. Nenhum desses exemplos comprova que um transportador específico está habilitado ou que as demais validações serão atendidas.

Como corrigir o envio

1. Recupere o XML do evento e a resposta integral. Confira tpEvento=110150, chave, ambiente, papel do autor e mensagem 827.

2. Identifique o emitente ou destinatário que está produzindo o evento e o transportador que receberá acesso. Confirme a autorização real e se ela inclui delegação.

3. Revise a configuração ou a integração que gera tpAutorizacao. Diferencie tag ausente, vazia e valor zero; uma tela preenchida não comprova que o valor chegou ao XML enviado.

4. Gere novamente a mensagem pelo fluxo normal, com assinatura e dados coerentes. Não edite manualmente um XML já assinado nem altere a nota autorizada para corrigir o evento.

5. Examine o retorno individual e preserve o protocolo quando houver registro. Se um envio anterior ficou sem resposta, verifique seu resultado antes de criar novas tentativas ou aumentar o sequencial indiscriminadamente.

Há outras verificações sobre identidade, autorização anterior, cadastro do transportador e situação do documento. Corrigir a falta do indicador atende uma condição específica; não concede permissões inexistentes nem garante o download do XML pela aplicação.

Serviço, versão e prazo

A documentação consultada prevê o serviço de eventos do Ambiente Nacional e distingue homologação de produção. A validação geral J02f admite chaves dos modelos 55 e 65; a antiga P12-30A, que restringia ao modelo 55, está riscada na versão examinada. Isso não permite extrapolar a regra para CT-e ou outros serviços que também utilizem o código 827.

A NT estabelece prazo de seis meses após a autorização da nota para gerar o evento, sujeito à verificação específica do serviço. Não transforme esse prazo em uma quantidade fixa de dias. O cronograma da versão 1.40 refere-se à alteração cadastral 4P24-10, não a uma nova data de obrigatoriedade do campo da 827.

O código 128 significa que o lote foi processado, não que todos os eventos foram aceitos. Confira a resposta de cada evento, sua vinculação, chave, tipo, sequencial e protocolo. Caso o problema permaneça, envie esses dados e a descrição da permissão pretendida ao suporte por canal seguro. Este guia não pressupõe menus do ALRA nem atesta uma instalação ou concessão real de acesso.

Fontes e limites da consulta

Conferência em 16/10/2026: NT 2020.007 v1.40, páginas físicas 3–6 e 8–13. Captura oficial compartilhada de hoje, lida pessoalmente; análise textual e vetorial própria das páginas 3 e 9–11, sem gerar imagens. O arquivo tem 13 páginas, embora conserve “/12” no rodapé. A P26-10 está íntegra; as exclusões de outras linhas foram consideradas. Não houve envio, validação XSD ou teste de download.

Foram confrontados FlexDocs, parâmetros da implementação, Focus NFe, panorama das versões, e Berga, 827, guia específico. Não são três receitas concordantes: a associação de zero a cancelamento, a restrição antiga ao modelo 55 e automatismos do produto foram descartados. A ficha Buscador NCM foi consultada adicionalmente; sua conclusão genérica sobre nota não autorizada e número reutilizável não se aplica automaticamente a este evento.