Rejeição 889 em evento pelo PAA: confira quem assinou a solicitação

Se um cancelamento ou uma carta de correção voltou com a rejeição 889 e mensagem sobre o Provedor de Assinatura e Autorização, confira o certificado que assinou o evento e a identificação de quem emitiu a nota. Nesse contexto, alterar produtos, GTIN ou valores não resolve a divergência. Preserve o XML transmitido e a resposta completa antes de preparar outra tentativa.

A mensagem é “Emissão por PAA deve ser assinada pelo CNPJ do Provedor de Assinatura”. A regra completa, porém, também considera a base do CNPJ do emitente. Essa diferença entre a mensagem resumida e o critério técnico é essencial para conduzir o atendimento corretamente.

Qual evento está no alcance da regra

A NT 2026.001 PAA v1.02b, página 18, apresenta a 2P81-10 no serviço de Registro de Evento, com aplicação obrigatória para NF-e modelo 55, somente na SVRS. O cenário envolve nota emitida pelo PAA, com série entre 970 e 989, e evento do emitente de um dos tipos relacionados:

• 110111: cancelamento;

• 110112: cancelamento por substituição;

• 110110: carta de correção.

A inclusão do 110112 na comparação não estabelece permissão geral para substituir qualquer NF-e modelo 55. O cabimento do evento precisa ser conferido separadamente. Também não amplia esse fluxo para NFC-e: a NT contém regras que rejeitam modelo 65 nas séries do PAA.

Identifique tpEvento, chNFe, tpAmb e o autor declarado. A série é a da nota referenciada pela chave, não a sequência do evento. Homologação e produção são ambientes distintos; uma solicitação bem-sucedida em teste não comprova regularidade em produção.

A comparação envolve duas bases de CNPJ

O CNPJ-8 é a base formada pelos oito primeiros caracteres do CNPJ. A 2P81-10 descreve a rejeição quando a base do certificado de assinatura do evento difere da base do PAA que emitiu a NF-e e também difere da base do emitente da NF-e. As duas diferenças compõem a condição.

Portanto, essa regra não exige exclusivamente o certificado do provedor em qualquer circunstância. Mas a coincidência com uma dessas bases também não garante aceitação: continuam existindo verificações próprias de autoria, assinatura, grupo PAA, vínculo e cabimento. A comparação não autoriza assinar em nome de outra empresa.

O PAA considerado é o responsável pela emissão original. Uma contratação posterior não altera automaticamente esse dado da nota. Se houve mudança de provedor, recupere os documentos e registros da emissão anterior antes de investigar o certificado usado no evento atual.

O autor informado no evento também não deve ser substituído pelo provedor para aproximar os CNPJs. Autoria fiscal e assinatura técnica são informações diferentes. A NT prevê validação específica da correspondência entre autor e emitente da chave.

Não confunda 889, 776 e assinatura RSA

Na mesma página, a P81-50, código 776, verifica, quando há infPAA, se a base do certificado difere da base indicada em CNPJPAA. A mensagem é semelhante, mas essa condição não é a comparação dupla da 889.

A assinatura RSA em PAASignature, com SignatureValue e RSAKeyValue, também possui validação própria. Ela não se confunde com a assinatura digital do evento feita com certificado. Atualizar uma chave RSA não corrige automaticamente a utilização de certificado de outra empresa; trocar o certificado não comprova validade da assinatura RSA.

Por isso, registre o código e o texto completos da resposta individual. Um atendimento baseado somente na expressão “assinatura do PAA” pode encaminhar a correção para o componente errado.

Como reunir as informações para corrigir

Separe o XML autorizado da NF-e, seu protocolo, o XML do evento efetivamente transmitido, a resposta recebida, o horário e a versão do emissor. Uma tela mostrando o certificado selecionado não prova qual certificado uma integração utilizou na assinatura enviada.

Peça ao suporte para comparar três identificações: a base do certificado do evento, a do PAA da emissão original e a do emitente. Se houver infPAA, inclua CNPJPAA na análise das regras correspondentes. Preserve os arquivos sem edição, para que a comparação possa ser reproduzida.

Verifique serviços em segundo plano e configurações por estabelecimento. Uma rotina pode preparar o evento em uma configuração e assiná-lo em outra. Use identificação pública do certificado e registros técnicos para o diagnóstico; não envie senha ou chave privada em chamados de suporte.

Quando for comprovado uso de certificado incorreto, o responsável técnico deve corrigir a configuração e reconstruir a solicitação pelo fluxo legítimo. Não basta editar o CNPJ dentro de um XML assinado. Se os dados parecem compatíveis, confirme se os arquivos analisados são exatamente os da tentativa rejeitada e encaminhe a divergência ao provedor ou ao atendimento da SVRS.

Exemplo de investigação

Uma empresa solicita carta de correção para uma NF-e emitida pelo PAA A. Uma integração assina o evento com certificado da empresa B, cuja base difere tanto da do PAA original quanto da do emitente. Essa situação corresponde à comparação descrita pela 889.

O suporte identifica a configuração indevida, guarda a tentativa e prepara o evento no fluxo correto. Não muda a nota original para adaptá-la ao certificado disponível. A nova solicitação ainda depende das demais validações e do cabimento da carta de correção.

Versão atual e o antigo significado sobre GTIN

O cronograma da NT PAA v1.02b registra testes em 03/08/2026 e produção em 05/10/2026 para a atualização 1.02. As revisões 1.02a e 1.02b apresentam ajustes documentais. Essas datas orientam a conferência de versão; não comprovam habilitação individual do emitente ou do provedor.

O mesmo número já identificou obrigatoriedade de GTIN na regra 7I03-10. A NT 2021.003 v1.50, página 12, declara sua eliminação por duplicidade com I03-10 e apresenta a linha riscada. Isso não elimina todas as validações de GTIN e não retira a 889 do serviço de eventos PAA. Em mensagens antigas sobre produto, identifique a data, o item e a origem do retorno, sem inventar código de barras.

Depois da correção, leia a resposta individual do evento e guarde o protocolo. Confira a vinculação à chave correta; em cancelamento, consulte também a situação fiscal da nota. O desaparecimento da 889 não comprova aceitação. Envolva o contador quando houver dúvida sobre conteúdo, cabimento ou prazo do evento.

Fontes e limites

• NT 2026.001 PAA v1.02b: páginas 3–6, 10–12 e 15–18. Reuso do PDF oficial capturado em 15/10/2026; leitura atual dos textos e das imagens documentais existentes das páginas 3, 12, 17 e 18.

• NT 2021.003 v1.50: páginas 12–14, PDF oficial recapturado em 16/10/2026. As imagens existentes das páginas 12 e 13 foram conferidas: 7I03-10 e 9I03-40 estão riscadas. A tabela de mensagens não reativa essas regras.

• Documentos NF-e da SVRS e documentos PES: capturas oficiais de 16/10/2026, com as versões referidas. MOPAA v1.02, páginas físicas 12–13, impressas 11–12: distribuição do cadastro e separação entre identificação, série e chaves; cabeçalho interno conserva 1.01. Não houve consulta cadastral individual.

• TecnoSpeed — visão geral do PAA, Contábeis — atualização do cronograma e ACBr — evolução da NT: três publicadores de contexto, com corpos textuais efetivamente lidos em capturas de 15/10. Não são três tutoriais específicos da rejeição. Séries e códigos de versões anteriores, generalizações por modelo e a troca 669→663 publicada pelo ACBr não foram adotados.

• BuscadorNCM — ficha 889: corpo HTTP200 de 16/10 lido integralmente na parte do código, regras e perguntas. A ficha trata do antigo GTIN e não contempla a 2P81-10. Não fundamenta a retirada geral do código 889, nem o diagnóstico PAA.

A orientação fiscal decorre das fontes oficiais. Busca delimitada em seis caches de NTs de 2026 não encontrou os códigos e regras PAA pesquisados; isso não certifica exaustão normativa ou implantação individual. Não houve transmissão, validação de XML real, configuração de tela ALRA ou publicação.