Rejeição 776: conferir quem assinou o documento emitido por PAA

Se o retorno disser que a emissão por PAA deve ser assinada pelo CNPJ do provedor, a conferência começa pela identidade do certificado que efetivamente assinou o documento. Na NT 2026.001 PAA v1.02b, o código 776 indica divergência entre o CNPJ-base do certificado de assinatura e o CNPJ-base do provedor informado em CNPJPAA. CNPJ-base corresponde às oito primeiras posições usadas pela regra, e não à comparação obrigatória dos quatorze caracteres completos.

O mesmo número aparece no MOC 7.0 com uma mensagem sobre resposta síncrona. Portanto, registre a descrição completa, o serviço, o ambiente e o arquivo enviado antes de mudar qualquer configuração. A numeração isolada não distingue esses dois problemas. Uma orientação destinada ao processamento do lote não corrige a identidade de quem assinou uma emissão por PAA.

O que a regra de PAA compara

Na autorização, a ZG02-40 prevê a verificação quando existe o grupo infPAA: o CNPJ-base do certificado de assinatura deve corresponder ao CNPJ-base de CNPJPAA. A tabela traz modelos 55/65, aplicação obrigatória e implementação somente na SVRS. Na versão examinada, uma referência anterior à SVRS como alternativa de assinatura está riscada, assim como o código anterior 1183; o código 776 permanece na redação apresentada.

Isso não transforma a coluna 55/65 em autorização geral para emitir NFC-e por PAA. A própria nota técnica contém restrição específica para modelo 65 nas séries de PAA. A possibilidade de uma emissão depende do conjunto das regras, do credenciamento e do vínculo, não apenas da linha que valida o certificado.

Para eventos, a P81-50 está documentada para modelo 55, aplicação obrigatória e somente SVRS. Havendo infPAA, compara a base do certificado de assinatura com a base de CNPJPAA. Confira o XML do evento rejeitado; examinar apenas o certificado usado na autorização da nota pode deixar passar uma configuração diferente utilizada pelo serviço de eventos.

Compare o certificado usado, não apenas o cadastrado

Um cadastro pode mostrar o provedor correto e, mesmo assim, o componente de assinatura selecionar outro certificado. A investigação deve identificar o certificado que consta na assinatura efetivamente transmitida e o CNPJ de PAA escrito naquele mesmo documento. Não basta verificar o nome amigável de um arquivo, a empresa selecionada na tela ou o certificado disponível no computador.

Imagine que o vínculo legítimo seja com o provedor A, mas uma configuração reutilizada tenha assinado a mensagem com o certificado do provedor B. A correção é restaurar a seleção autorizada do certificado de A e gerar novamente a mensagem pelo fluxo correspondente. Trocar CNPJPAA por B apenas para fazer a comparação coincidir pode criar inconsistências de cadastro, vínculo, série e chave pública.

O certificado ICP-Brasil usado pelo provedor e a assinatura RSA interna do emitente têm funções diferentes. A rejeição 776, neste contexto, trata da identidade ligada ao certificado. A validação da assinatura RSA interna possui regra própria, associada à rejeição 856. Um erro nessa assinatura não se resolve automaticamente escolhendo outro certificado no computador do usuário.

Roteiro para tratar o retorno

1. Separe o retorno original e confirme se a mensagem realmente menciona PAA. Anote autorização ou evento, modelo, ambiente, horário e versão do integrador. Se o envio ficou sem resposta conclusiva, consulte sua situação antes de produzir outra tentativa.

2. Localize infPAA/CNPJPAA no arquivo rejeitado. Compare sua base com a identidade do certificado presente na assinatura efetiva. Faça a análise com o suporte responsável pelo componente; não divulgue senha, arquivo de certificado ou chave privada para demonstrar a divergência.

3. Confira qual provedor está legitimamente associado ao emitente e qual configuração foi usada por aquele serviço. Se houver várias empresas ou provedores, investigue seleção indevida, reaproveitamento de configuração e diferença entre homologação e produção.

4. Corrija a causa comprovada e regenere o documento pelo processo de assinatura da integração. Não substitua fragmentos de XML já assinado nem copie a assinatura de outra nota ou evento.

5. Confira o novo retorno. A ausência da 776 não equivale à autorização da nota ou ao registro do evento: outras validações podem permanecer, e o resultado final precisa ser confirmado no protocolo correspondente.

Quando a mensagem falar de resposta síncrona

No MOC 7.0, página 73, a GAP03a-2 usa 776 para a solicitação de resposta síncrona, indSinc=1, a UF que não disponibiliza esse atendimento. A aplicação aparece como facultativa. Esse registro documental é distinto das regras de PAA; não demonstra, sozinho, que uma UF ou um serviço específico ainda utilize hoje aquela validação.

Se essa for a descrição recebida, o suporte deve conferir o modo de processamento aceito pelo serviço e pela versão em uso. Não há fundamento para trocar o certificado por causa dessa mensagem. Também não se deve mandar alterar indSinc de forma indiscriminada, pois as condições atuais do fluxo utilizado precisam ser preservadas. O texto literal, a identificação do serviço e a documentação aplicável orientam a decisão.

Informações úteis para o atendimento

Encaminhe o retorno completo, os dados públicos necessários à comparação das bases e a identificação da configuração de assinatura usada. Indique se o problema começou depois de troca de provedor, certificado ou atualização. Um exemplo com dados protegidos pode ajudar, desde que preserve os campos relevantes e não exponha credenciais. O arquivo original deve ficar disponível apenas no canal autorizado de atendimento.

A página 3 da nota técnica registra, para a versão 1.02, homologação em 03/08/2026 e produção em 05/10/2026; as revisões 1.02a e 1.02b não apresentam novas datas. Esse cronograma não certifica implantação individual ou habilitação de uma empresa. Não foi demonstrado um procedimento de configuração no ALRA, portanto não há indicação de menu ou garantia de suporte automático ao fluxo de PAA.

Fontes e limites

Pesquisa em 15/10/2026, horário de Brasília. As capturas oficiais desse dia foram reutilizadas por identidade; as páginas de apoio tiveram captura direta nesse mesmo dia. Não houve teste de emissão, evento, validação criptográfica ou demonstração de configuração do ALRA.

• NT 2026.001 PAA v1.02b: PDF 703310, HTTP 200 em 16/10 às 00:10 UTC, correspondente a 15/10 no Brasil. Páginas 3 a 7 e 10 a 18 efetivamente lidas para o conjunto; PNGs existentes 3, 10, 12, 13, 14, 17 e 18 pessoalmente vistos. ZG02-40/776 e ZG04-10/856 na página 14, P81-50/776 e P83-10/856 na 18. Códigos anteriores e exceção riscada não foram apresentados como vigentes. Cronograma da página 3 não comprova implantação individual.

• Índice da SVRS: entrada da v1.02b de 29/07/2026 na captura de 15/10. A data 31/07 apresentada pelo apoio ATVI não foi adotada em substituição. A busca nos seis caches de NTs de 2026 não encontrou os alvos deste conjunto; isso não certifica ausência de qualquer atualização externa.

• MOC 7.0 Anexo I: PDF 5eb4cf, captura HTTP 200 de 15/10 reutilizada. Páginas 73 e 97 lidas integralmente por extração, sem alegar inspeção visual dessas duas páginas. Uso histórico separado: GAP03a-2 facultativa/776 e LA03d-10 obrigatória/55/856. Não prova ativação atual de regra antiga.

• NT 2023.001 v1.60: PDF 2b18d9 HTTP 200 de 15/10 reutilizado. Página 16 inteira lida e PNG existente da 29 pessoalmente visto nesta redação: exclusão expressa da LA03d-10. Não transportar a regra antiga do GLP para a assinatura RSA.

• Schemas oficiais: pacote 010f e declaração integral de infPAA no leiaute, com CNPJPAA, SignatureValue e RSAKeyValue, lidos como apoio estrutural. Não houve compilação de XSD, validação do evento por XSD ou de XML real.

• Buscador NCM 776: ficha HTTP 200, corpo específico lido, conferência editorial de 12/10 e consolidação de 09/10. Mistura o significado histórico com a regra de PAA e rotula esta como todas as UFs, contrariando a observação SVRS que ela mesma transcreve. Para 856, a orientação genérica de conferir totais não é solução da assinatura; para 776, não generalizar a facultatividade histórica para a regra obrigatória de PAA. Generalizações sobre denegação, numeração e outros documentos não foram adotadas.

• TecnoSpeed PAA: panorama de 29/07/2026, HTTP 200 e trecho WEB pertinente efetivamente lidos. Grupo, fluxo e duas assinaturas contextualizados. Séries 970–979, B26-20 e códigos substituídos preservados como divergências do apoio, sem adoção contra o PDF. Garantias de produto e referências legais indiretas não demonstram suporte no ALRA.

• ATVI PAA: corpo técnico HTTP 200 inteiro lido; panorama da v1.02b, com descrição de chaves, grupo e assinaturas. Sua data editorial diverge da entrada SVRS; não substitui o cronograma oficial nem comprova habilitação individual.

Há três editores com material pertinente, uma ficha e dois panoramas gerais de PAA; não foram encontrados três tutoriais completos exclusivos da rejeição 776. As hipóteses técnicas são encaminhamentos para verificação, não diagnóstico de uma integração real. Não foram processadas credenciais, alterados dados fiscais ou geradas imagens, capas e publicação.