Voltar para o blog

NF-e

Rejeição 466: o tipo de autor precisa corresponder ao evento

A rejeição 466, “Evento com Tipo de Autor incompatível”, indica que a classificação do autor não atende à regra do evento apresentado. Isso é diferente de informar um CNPJ inválido ou usar um protocolo errado. O diagnóstico começa pela pergunta: quem pode registrar esse fato fiscal, nesse serviço e nessa versão?

Blog ALRA
Capa ilustrada da ALRA: Rejeição 466: o tipo de autor precisa corresponder ao evento.

A rejeição 466, “Evento com Tipo de Autor incompatível”, indica que a classificação do autor não atende à regra do evento apresentado. Isso é diferente de informar um CNPJ inválido ou usar um protocolo errado. O diagnóstico começa pela pergunta: quem pode registrar esse fato fiscal, nesse serviço e nessa versão?

Não existe um valor de tpAutor que resolva a 466 em qualquer situação. O emitente da nota, o destinatário, uma transportadora e o Fisco têm papéis próprios. Alterar o número apenas para ultrapassar a validação pode transformar uma correção técnica em uma declaração incompatível com a operação.

Tipo de autor não é identidade nem beneficiário

O CNPJ ou CPF do autor identifica quem apresenta o evento. O campo tpAutor classifica o papel dessa pessoa ou organização quando previsto no detalhamento. Já cOrgao identifica a recepção, e cOrgaoAutor segue a identificação territorial ou institucional exigida pelo serviço.

Em eventos de acesso ao XML, existe ainda o beneficiário informado em autXML. A transportadora autorizada a obter o documento não se torna, por isso, autora do evento. Da mesma forma, o funcionário que clica no sistema não substitui a pessoa jurídica ou física que deve constar como autora.

A documentação da Unimake para EPEC separa essas propriedades. Isso ajuda a investigar a integração, mas uma biblioteca disponibilizar um campo ou uma enumeração não comprova que todos os valores sejam aceitos em todo evento.

EPEC: duas especificações que não devem ser misturadas

No EPEC 110140 da NF-e modelo 55, a regra P21-10 da NT 2014.001 v1.41 exige o tipo 1, descrito como empresa emitente/pessoa física. A nota técnica também possui regras próprias para identificação e série do emitente pessoa física. O número 1 expressa esse papel de emissão, sem dispensar as demais verificações. EPEC NF-e, página 11

O EPEC da NFC-e modelo 65 tem especificação própria, NT 2014.003 v1.02, cuja P21-10 também indica tipo 1, empresa emitente. Entretanto, esse documento contém restrição específica a autor pessoa física na P11-20. Não se deve transportar a ampliação do EPEC modelo 55 para o 65 apenas porque o código do evento coincide. A habilitação desse ramo para CPF exige confirmação específica do ambiente. EPEC NFC-e, página 11

Os guias de FlexDocs e TecnoSpeed detalham montagem, assinatura e tratamento do EPEC. São fluxos de produtos e versões; suas observações antigas não certificam disponibilidade atual em todas as UFs.

No evento do Fisco, o papel exigido é outro

O BT 2018.002 v1.00 documenta a 466 em P21-10 para Visto Eletrônico do Fisco, 400300, e para seu cancelamento, 400301. Nesses serviços da NF-e modelo 55, a classificação exigida é 5, Fisco. Há validações separadas para o órgão habilitado e sua identificação. Boletim, páginas 13–14 e 20

Isso não é uma alternativa de preenchimento disponível ao empresário. Se uma integração empresarial selecionou um evento reservado ao Fisco, a correção é revisar a finalidade e o serviço escolhido. Marcar tpAutor=5 não concede competência fiscal. Quando houver necessidade legítima de intervenção do órgão, o procedimento depende do canal oficial aplicável.

O fato de o contribuinte conseguir consultar um visto vinculado à sua nota também não o autoriza a produzir ou cancelar esse registro.

Cuidado com regras eliminadas e previsões futuras

No evento 110150, Ator Interessado na NF-e – Transportador, a antiga P21-10 associada à 466 aparece riscada na NT 2020.007 v1.40. Não deve ser apresentada como regra atual desse ramo apenas porque um extrator de PDF ainda encontra o texto. A exclusão não elimina as demais condições de autoria, habilitação e autorização de acesso. Versão 1.40, página 10

Na RTC, as regras 2P12-20/30 associadas à 466 já aparecem riscadas na versão 1.50 e não constam nas versões 1.51/1.52 consultadas. Os eventos continuam com papéis específicos, inclusive destinatário, sucessora e Fisco; isso não permite ressuscitar automaticamente aquele código de rejeição.

Já a NT 2026.006 v1.00 prevê 466/P21-10 no evento 110300, vinculação da transação de pagamento, para tipo diferente de 1. O documento abrange modelos 55/65, mas qualifica os campos de split payment como preparatórios, sem exigência de uso em produção em 2026. A previsão deve ser acompanhada pelos atos e cronogramas oficiais, sem afirmar ativação universal. NT 2026.006, páginas 3 e 9–10

Uma sequência segura de correção

  1. Guarde o XML enviado e o retorno individual, com ambiente, versão, modelo e tpEvento.

  2. Confira a identidade do autor e sua relação real com a nota. Separe emitente, destinatário e eventual beneficiário.

  3. Identifique a regra da versão usada pelo serviço. Não escolha o valor com base em uma lista geral de tipos.

  4. Revise o cadastro ou mapeamento somente se ele não representar o autor legítimo. Não empreste identidade nem substitua certificado para simular outro papel.

  5. Consulte a situação da nota e dos eventos antes de nova tentativa, sobretudo após falha de comunicação.

  6. Transmita apenas o evento efetivamente necessário e confira seu resultado individual.

Por exemplo, uma empresa fictícia monta seu EPEC como emitente, mas o sistema reaproveita a classificação de destinatário usada em outro fluxo. Confirmados documento e autoria, a integração precisa gerar o detalhamento correto. O exemplo não autoriza um destinatário verdadeiro a se declarar emitente.

Cancelamentos e resultado final

Comprovante de entrega, insucesso, ECONF e prorrogação possuem contratos próprios. Não transplante a 466 para eles sem regra específica. No cancelamento genérico 110001 da RTC v1.52, a identidade e o órgão do autor são confrontados com o evento original por validações distintas; não se deve inserir tpAutor inexistente no leiaute específico.

A rejeição não cancela a nota nem apaga eventos anteriores. Preserve os fatos fiscais verdadeiros e os retornos armazenados. A conferência foi realizada em 10/10/2026 com documentos oficiais preservados e três editores técnicos lidos; exemplos de software foram usados para investigar campos e fluxos, sem substituir a norma ou comprovar implantação por UF.

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.