Rejeição 670: CNPJ do PAA inválido e diferença para local de entrega

O código 670 precisa ser interpretado com a mensagem completa e o serviço utilizado. Quando o retorno informa “CNPJ do PAA inválido”, a conferência deve começar pela identificação do Provedor de Assinatura e Autorização no evento enviado. A mesma numeração também aparece em uma regra sobre local de entrega, com implementação futura. Corrigir um endereço quando o problema está no provedor não resolve a inconsistência e pode alterar dados que estavam corretos.

O PAA é o intermediário técnico que participa da assinatura e do encaminhamento de documentos fiscais. Seu CNPJ identifica o provedor. Ele não se confunde com o CNPJ ou CPF do contribuinte, do destinatário ou do autor do evento. Mesmo quando o emitente é pessoa física, o campo destinado ao provedor continua sendo CNPJPAA.

Quando a 670 se aplica ao PAA

Na NT 2026.001 v1.02b, a regra P81-10 pertence ao serviço de registro de eventos. Para o modelo 55, quando existe o grupo infPAA, ela verifica a validade do CNPJ do PAA, incluindo preenchimento zerado e dígitos verificadores. A aplicação é obrigatória dentro dessa condição, com observação de implementação somente na SVRS.

O leiaute do evento coloca CNPJPAA dentro de infPAA, por sua vez ligado a infEvento. Já o CNPJ ou CPF do autor ocupa outro campo. Por isso, uma integração que copia a identificação do emitente para todos os locais pode preencher o provedor incorretamente. É preciso conferir o conteúdo efetivamente enviado, não apenas o nome da empresa que aparece na tela.

O grupo infPAA também contém elementos de assinatura. A rejeição por CNPJ inválido não equivale, por si só, a certificado vencido, assinatura RSA inválida ou ausência de vínculo entre emitente e provedor. Essas verificações possuem condições próprias. Renovar um certificado sem investigar o campo apontado pode deixar a causa original intacta.

Por que a autorização da nota usa outro código

A mesma NT apresenta uma validação de CNPJ do PAA na autorização da nota, denominada ZG02-10. Nessa linha, os códigos anteriores 1180 e 670 aparecem substituídos por 634. A troca não foi reproduzida na P81-10, que conserva 670 para eventos. Portanto, não é correto dizer que a rejeição 670 desapareceu de todo o fluxo PAA.

Se a aplicação mostrar 670 durante a autorização de uma nota, recupere o retorno original do autorizador. Confira se a mensagem veio dessa solicitação, de um evento ou de uma tradução interna do sistema. Uma tabela local desatualizada pode exibir descrição diferente do retorno recebido; isso deve ser confirmado por comparação, sem presumir falha da SEFAZ.

A existência de linhas com modelo 55/65 no quadro de autorização também não libera NFC-e pelo PAA. A B07-10 prevê rejeição do modelo 65 quando utilizada série do PAA. O diagnóstico do CNPJ não é motivo para mudar modelo, série ou processo de emissão apenas para contornar uma validação.

Como conferir e corrigir com segurança

Comece guardando o XML enviado e a resposta completa, com cStat, xMotivo, ambiente, horário, tipo do evento e chave da NF-e. Identifique se a tentativa ocorreu em homologação ou produção. Esses dados permitem relacionar a rejeição à solicitação correta e ajudam o suporte a investigar o preenchimento sem repetir transmissões às cegas.

Compare CNPJPAA com a identificação oficial do provedor realmente utilizado. Confira a origem desse dado na integração, possíveis valores padrão, perda de caracteres e divergências entre o cadastro e o XML. O leiaute reserva 14 caracteres para o campo; conferir apenas o comprimento não comprova a validade do CNPJ, seus dígitos verificadores ou a identidade de quem presta o serviço.

Também não é seguro eliminar letras de um identificador automaticamente. O tipo TCnpj do schema consultado admite caracteres alfanuméricos nas primeiras posições e dois dígitos finais. Isso não dispensa a validação aplicável nem autoriza inventar um identificador. A correção deve recuperar o dado verdadeiro do provedor e respeitar o leiaute utilizado.

Quando houver erro de mapeamento ou cadastro, corrija a origem e gere novamente o evento pelo fluxo do emissor e do provedor, com as assinaturas exigidas. Não edite manualmente um XML já assinado. Se o dado enviado corresponde ao provedor e a rejeição continua, encaminhe as evidências ao responsável pela integração para confrontar regra, versão e ambiente. Não envie senhas ou chaves privadas nesse atendimento.

Exemplo de diagnóstico

Imagine um evento de uma NF-e modelo 55 cujo retorno seja 670, “CNPJ do PAA inválido”. Na conferência, a equipe encontra CNPJPAA preenchido somente com zeros porque a integração não carregou o cadastro do provedor. A hipótese é compatível com a P81-10.

A solução é recuperar a identificação correta do PAA e corrigir o carregamento desse campo antes de gerar e assinar uma nova solicitação. Preencher um CNPJ qualquer, copiar o do destinatário ou excluir infPAA não resolve adequadamente o processo. Depois da correção, ainda devem ser avaliadas as demais regras e a resposta efetiva do serviço.

Uma rejeição do evento também não cancela automaticamente a NF-e já autorizada. Se o evento pretendido era cancelamento, o documento não deve ser tratado como cancelado apenas porque houve uma tentativa. Consulte a situação e o processamento efetivo antes de concluir a operação no sistema.

Quando a mensagem fala em local de entrega

A NT 2026.002 v1.11 apresenta outra 670: G01-10, “Local de entrega informado indevidamente”. Ela trata do grupo entrega em NFC-e ou NF-e com DANFE Simplificado Tipo 2, identificado por tpImp=6. A linha conserva expressamente a observação “Implementação futura”.

Essa previsão não deve ser anunciada como validação já ativada. Se essa for a mensagem recebida, confira o serviço, a versão e a orientação do autorizador antes de agir. Não apague endereço verdadeiro nem altere o formato do documento por tentativa. O cronograma geral da NT não elimina a ressalva da própria linha, e o prazo de dezembro atribuído a outras regras não fornece uma data para G01-10.

Como confirmar a solução

Para o PAA, o cronograma da versão 1.02 registra testes em 03/08/2026 e produção em 05/10/2026; as versões 1.02a e 1.02b trazem ajustes documentais sem novas datas nesse quadro. O calendário não comprova a configuração de uma empresa nem o resultado de uma transmissão específica.

Considere o atendimento concluído quando o dado correto estiver na solicitação e o retorno do serviço confirmar o processamento pretendido. A ausência da 670, isoladamente, não prova aceitação do evento ou autorização de nota. Guarde o resultado e mantenha a distinção entre situação da NF-e, situação do evento e cadastro do provedor.

Fontes e limites

• NT 2026.001 PAA v1.02b: páginas 3–6, 11–18. Condições, serviços, leiautes e calendário; páginas 12, 13, 14 e 18 conferidas em imagens documentais existentes. PDF oficial capturado em 15/10/2026, reutilizado por identidade.

• Portal PES e documentos da SVRS: serviços públicos de cadastro e credenciamento e referência da versão. Consulta pública não comprova habilitação de um provedor específico.

• NT 2026.002 v1.11: páginas 3 e 11; G01-10/670 permanece com indicação de implementação futura, em cenário distinto do PAA.

• Schemas oficiais da NF-e: pacote 010f capturado em 15/10, declarações infPAA/CNPJPAA/TCnpj conferidas. A estrutura não comprova dígito verificador, cadastro ou autorização.

• TecnoSpeed — visão geral do PAA: artigo de 29/07/2026, corpo completo lido em captura HTTP200 de 15/10. Contextualiza provedor e assinatura, mas conserva trechos de versões anteriores e atribui 671 à ZG02-30; esses trechos não orientam os códigos atuais.

• Contábeis — atualização do PAA e ACBr — evolução da NT: corpos textuais lidos em capturas HTTP200 de 15/10. A troca 670→634 na autorização não foi generalizada aos eventos. ACBr apresenta 663 para ambiente onde a NT usa 633; essa numeração e calendários antigos não foram adotados.

• BuscadorNCM 670: ficha examinada, descartada como fundamento do PAA. Seu título sobre CNPJ de entrega não corresponde à descrição G01-10 da NT; não substitui a distinção por serviço e mensagem.

Há três publicadores de apoio com profundidades diferentes, sem três tutoriais completos do erro. A NT oficial governa a orientação. Busca delimitada em seis caches de NTs de 2026 encontrou G01-10/670 na NT 2026.002 e não encontrou os alvos PAA pesquisados nesses seis documentos; isso não demonstra exaustão normativa. Nenhuma transmissão, consulta cadastral individual, tela ALRA ou autorização foi certificada. Sem capas ou publicação.