Rejeição 634: CNPJ do PAA inválido

Na autorização por Provedor de Assinatura e Autorização, a rejeição 634 aponta para a identificação do próprio PAA. A regra ZG02-10 da NT 2026.001 v1.02b é aplicada quando o grupo infPAA está informado e o CNPJ do provedor é inválido. O campo a conferir é CNPJPAA, não o CNPJ do cliente, do fornecedor de mercadorias ou, automaticamente, o do emitente da nota.

Antes de corrigir o cadastro, confirme o serviço e a mensagem completa. O número 634 também aparece em documentação histórica de download com outro significado. Além disso, o mesmo problema de identificação do PAA tem código diferente em uma regra de eventos. Uma tabela genérica de rejeições pode esconder essas diferenças.

Quem deve estar identificado no campo

O emitente é o contribuinte que realiza a operação, identificado por CPF ou CNPJ no grupo próprio da NF-e. O PAA é o provedor habilitado que participa da assinatura e da autorização. Seu CNPJ aparece em infPAA/CNPJPAA.

Esses papéis não se tornam iguais porque o certificado utilizado pertence ao provedor. Um produtor identificado por CPF continua sendo emitente pessoa física mesmo quando o fluxo utiliza o certificado do PAA. Copiar o CNPJ do provedor para o cadastro do emitente, ou fazer o inverso, altera a identidade fiscal do documento.

Confira a identificação fornecida oficialmente pelo PAA contratado e o vínculo utilizado pela empresa. Se o ERP atende vários contribuintes ou provedores, investigue troca de perfil, configuração reaproveitada e associação incorreta entre contas. Uma informação válida para outra integração pode ser inadequada para a emissão em análise.

Verifique o valor que realmente chegou ao XML

O leiaute da NT PAA v1.02b define CNPJPAA como campo de caracteres, com tamanho 14. Compare o cadastro original, o valor armazenado na integração e o conteúdo efetivamente transmitido. O erro pode surgir entre essas etapas.

Procure truncamento, espaços acrescentados, pontuação indevida, caracteres alterados e perda de zeros iniciais. Não trate o CNPJ como número para cálculos: uma conversão numérica pode destruir informações necessárias ao identificador. A validação precisa usar o schema e as regras correspondentes à versão adotada.

O contexto alfanumérico merece atenção. CNPJ de 14 caracteres não significa obrigatoriamente 14 algarismos. O padrão novo admite letras e números nas primeiras 12 posições e mantém duas posições numéricas de verificação. Cadastros numéricos existentes continuam válidos. Uma rotina que simplesmente remove tudo o que não seja algarismo pode corromper uma identificação legítima.

Se houver validação de dígito verificador no sistema, ela deve acompanhar o padrão aplicável. A especificação alfanumérica mantém o cálculo por módulo 11, com conversão dos caracteres conforme a tabela ASCII e subtração de 48. Para o empresário, a providência é exigir uma biblioteca compatível e testes do fornecedor, não calcular outro DV e alterar o CNPJ para que a nota passe.

A rasura da nota técnica não dispensa a validade

Na ZG02-10, a v1.02b mantém “CNPJ do PAA inválido” e risca a redação anterior “deve ser válido (zeros, DV)”. A leitura visual é importante: o texto extraído do PDF pode juntar as duas redações.

Essa edição não deve ser interpretada como autorização para enviar zeros, retirar dígitos verificadores ou ignorar o cadastro oficial. A conferência prática continua partindo da identificação real do provedor e da especificação aplicável. Também não comprova, sozinha, que todo software e todo ambiente já estejam preparados para qualquer CNPJ alfanumérico.

O cronograma da NT 2026.004 v1.01 sobre schemas e as regras de formação da Receita Federal dão contexto à transição. A compatibilidade concreta do sistema precisa ser confirmada; atualizar uma máscara na tela não garante que armazenamento, XML e validação foram corrigidos juntos.

Não confunda formato, cadastro, vínculo e assinatura

Um identificador corretamente formado não prova que o PAA esteja habilitado na base da Sefaz. Na autorização, a ZG02-20 usa a rejeição 671 para o provedor inexistente ou em situação inválida. A ZG02-30 trata do vínculo do emitente com o PAA, com o código 936 nessa versão.

A série atribuída ao vínculo é examinada separadamente, assim como a chave pública e as assinaturas. Portanto, resolver a 634 não é uma confirmação de que todas as demais condições foram atendidas. Se surgir uma nova mensagem, registre-a e trate sua causa específica.

As rejeições 495 e 503 relacionam identidade do emitente e série. A 451 trata de processo fiscal avulso, enquanto o PAA utiliza procEmi 4. Nenhuma delas justifica trocar o CNPJ do provedor. A Nota Fiscal Fácil tem processo próprio e não serve de alternativa automática a uma falha cadastral do PAA.

Roteiro para o suporte e a equipe fiscal

1. Separe a resposta com cStat e xMotivo, o XML enviado, o ambiente, a data e a versão do sistema.

2. Identifique o PAA efetivamente contratado e compare seu CNPJ oficial com CNPJPAA, preservando todos os caracteres e zeros.

3. Peça a conferência do mapeamento, do tipo de armazenamento, do schema e da validação de CNPJ utilizada pela integração.

4. Corrija a origem comprovadamente errada. Não substitua a identificação por uma de exemplo ou de outro provedor.

5. Gere novamente o documento pelo fluxo do sistema, com as assinaturas exigidas. Não edite manualmente o XML já assinado.

6. Confira a resposta individual e, quando houver resultado anterior incerto, reconcilie a situação antes de retransmitir.

Uma situação possível é a tela guardar o CNPJ correto, mas uma rotina intermediária retirar letras antes de montar o XML. A correção deve eliminar essa transformação e validar o valor original. Repetir o envio sem corrigir a integração apenas reproduz o defeito.

Eventos, modelos e o significado histórico

Na autorização, 1180 e 670 aparecem riscados na ZG02-10, ficando 634. Entretanto, a P81-10 de eventos modelo 55 mantém 670 para “CNPJ do PAA inválido”. Portanto, 670 não é um código globalmente extinto: serviço e regra continuam decisivos.

A tabela ZG02-10 indica 55/65, mas a própria NT proíbe modelo 65 com séries PAA 970–989 pela B07-10. Não interprete essa coluna como liberação de NFC-e por PAA. Consultas públicas por QR Code também não integram a correção aqui descrita.

No antigo download, 634 comparava a raiz do CNPJ do destinatário com a do solicitante. Esse ramo serve para entender registros históricos, não para orientar a autorização atual por PAA. A conclusão do atendimento exige confirmar o identificador correto no fluxo correto e guardar a resposta obtida, sem inventar dados para superar a validação.

Fontes consultadas

• NT 2026.001 v1.02b, páginas 11–14 e 18, leiaute, regra, rasuras e diferença entre autorização e evento

• Receita Federal: perguntas e respostas sobre CNPJ alfanumérico, formação e DV

• TecnoSpeed: PAA, TOTVS: PAA v1.02 e ATVI: PAA v1.02b, contexto prático de campos, vínculo e integração, com prevalência da fonte oficial

Base documental conferida em 10/10/2026. PDFs utilizados a partir do corpus autorizado, sem nova captura dos arquivos sob suspensão. Os três editores práticos contextualizam o PAA; não oferecem três guias exclusivos da rejeição 634.