Rejeição 830: não permitido preencher o campo Condição de Uso

A rejeição 830 indica uma incompatibilidade entre o tipo de autorização informado e a declaração de condição de uso no evento Ator Interessado na NF-e — Transportador, código 110150. Pela regra P27-20 da NT 2020.007 v1.40, quando tpAutorizacao é informado com valor diferente de 1, não é permitido preencher xCondUso.

O primeiro cuidado é identificar o que foi rejeitado. Esse retorno pertence ao processamento do evento de acesso ao XML. Ele não significa, por si só, que a nota perdeu sua autorização, que deve ser emitida novamente ou que sua numeração ficou disponível. A correção deve começar pela mensagem do evento que recebeu a 830.

O que a condição de uso representa

O evento permite identificar um transportador autorizado a acessar o XML. Existe, porém, uma decisão adicional: permitir que esse transportador autorize outros transportadores envolvidos em subcontratação ou redespacho da mesma operação. É essa extensão de permissão que o campo tpAutorizacao controla.

O valor 0 significa que essa extensão não é permitida; o valor 1 permite ao transportador autorizado pelo emitente ou destinatário autorizar outros transportadores. Portanto, 0 não deve ser interpretado como cancelamento do acesso concedido ao próprio transportador. Confundir esses efeitos pode levar a uma correção que altera a intenção do responsável pelo documento.

A declaração xCondUso acompanha a decisão de permitir essa extensão. Seu conteúdo descreve a ciência do emitente ou destinatário sobre o acesso de transportadores subcontratados ou redespachados. Não é um campo livre para observações logísticas, instruções de entrega, justificativas comerciais ou uma mensagem genérica de autorização.

Como localizar a inconsistência

Separe o retorno completo e o XML efetivamente transmitido. Confira o código do evento, a chave da nota, o ambiente e a identificação do autor. O CNPJ ou CPF de quem registra o evento não deve ser confundido com o CNPJ ou CPF informado no grupo autXML, que identifica a pessoa autorizada a acessar o documento.

Em seguida, examine juntos tpAutorizacao e xCondUso. Uma configuração que sempre acrescenta a declaração, independentemente da decisão de delegação, pode produzir a combinação rejeitada. O mesmo pode ocorrer quando um modelo de mensagem é reaproveitado e conserva um texto incompatível com o indicador. São hipóteses de diagnóstico; o arquivo enviado é que permite confirmar a causa concreta.

Se a tela mostra uma opção e o XML contém outra, encaminhe essa diferença ao responsável pela integração. Conferir apenas o cadastro ou uma prévia não demonstra o conteúdo recebido pelo serviço. Guarde a mensagem rejeitada para comparação, sem alterar o arquivo assinado para tentar fazê-lo coincidir com a tela.

Como corrigir sem ampliar uma permissão indevidamente

Quando a decisão legítima é não permitir que o transportador estenda o acesso, e o evento informa tpAutorizacao=0, a geração da mensagem deve respeitar essa decisão e não incluir a declaração incompatível. Ajuste a origem do preenchimento e gere novamente o evento com a assinatura correspondente. Remover o campo indevido não equivale a cancelar o acesso do transportador.

Não substitua 0 por 1 apenas para conservar um texto que o sistema acrescentou. Essa troca expressaria uma permissão diferente. Se o responsável realmente pretende permitir a extensão, é necessário conferir sua legitimidade como autor, os participantes da operação e o preenchimento exigido para essa decisão, inclusive a declaração prevista no leiaute.

Também não basta apagar indiscriminadamente o indicador. A regra P26-10 exige tpAutorizacao quando o autor é o emitente ou o destinatário; a P26-20 proíbe esse campo quando o autor não é nenhum deles. O ajuste depende de quem está registrando o evento. Declarar um tipo de autor diferente da participação real não é uma solução válida.

Exemplo de diagnóstico

Imagine que o emitente queira disponibilizar o XML ao transportador contratado, sem permitir que ele libere o documento a outros transportadores. O evento informa tpAutorizacao=0, mas a integração acrescenta automaticamente a condição de uso que declara a permissão de extensão. Essa combinação corresponde ao problema descrito na P27-20.

A correção consiste em adequar a geração do evento à decisão efetiva, sem a declaração indevida. Não exige cancelar a nota, modificar a mercadoria, alterar o frete ou emitir outro documento fiscal. Se houver outra necessidade de transporte, ela deve ser analisada separadamente; o exemplo não autoriza ampliar permissões nem comprova que todas as demais validações serão atendidas.

Regras próximas que merecem atenção

A rejeição 829 trata do cenário complementar: informado tpAutorizacao=1, a condição de uso é obrigatória. Já a 831 envolve a permissão registrada para o transportador na base de eventos. Corrigir o conteúdo responsável pela 830 não demonstra, sozinho, que existe uma cadeia válida de autorizações para outro transportador.

O leiaute apresenta esses campos com ocorrência opcional, mas as regras de negócio determinam quando são exigidos ou proibidos. A marcação de opcionalidade na estrutura não permite preencher qualquer combinação. Da mesma forma, cumprir a P27-20 não elimina as verificações de identidade, existência da nota, duplicidade e prazo do evento.

Modelo, ambiente e resultado da tentativa

A NT situa esse serviço no Ambiente Nacional. Na versão 1.40, a validação genérica da chave contempla modelos 55 e 65, enquanto a antiga linha que rejeitava modelo diferente de 55 está excluída. Não se deve usar um tutorial antigo restrito ao modelo 55 como prova de exclusão geral da NFC-e, nem concluir que todo cenário ou aplicativo oferece o evento sem outras condições.

Confira o serviço efetivamente utilizado, o ambiente e as condições aplicáveis à operação. O cronograma da versão 1.40 altera especificamente a regra cadastral 4P24-10; não estabelece uma nova data particular para a 830. A nota técnica também prevê recepção em até seis meses após a autorização da nota, regra distinta do conteúdo da declaração.

Após corrigir a origem da mensagem, examine o resultado individual do evento. O código 128 informa processamento do lote, e não aprovação automática de cada registro. Preserve o retorno e eventual protocolo, verificando registro e vinculação ao documento. O acesso posterior ao XML segue o serviço de distribuição e suas condições; a simples ausência da rejeição 830 não comprova download liberado.

Fontes

Pesquisa documental de 16/10/2026. Base normativa: NT 2020.007 v1.40, páginas 3–6 e 9–13, captura HTTP de 16/10 reutilizada. A análise das alterações gráficas foi textual e vetorial, sem nova renderização ou teste de serviço.

Apoios lidos: InforSystem — 830, Berga — 830, Focus — panorama da NT e FlexDocs — estrutura do evento. São dois guias específicos e dois apoios de contexto. A associação de indicador 0 a cancelamento de acesso e a orientação de reemitir a nota não foram adotadas. Não houve emissão, consulta individual ou validação de funcionamento no ALRA.