Voltar para o blog

Rejeições fiscais

Rejeição 671: provedor de assinatura e autorização não existe na base da SEFAZ

A rejeição 671, com a mensagem “Provedor de Assinatura e Autorização não existe na base da SEFAZ”, exige conferir o cadastro do PAA identificado no envio. A regra abrange duas situações: o CNPJ do provedor não foi encontrado ou sua situação é inválida. Por isso, a mensagem não permite concluir, sozinha, que basta…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 671: provedor de assinatura e autorização não existe na base da SEFAZ.

A rejeição 671, com a mensagem “Provedor de Assinatura e Autorização não existe na base da SEFAZ”, exige conferir o cadastro do PAA identificado no envio. A regra abrange duas situações: o CNPJ do provedor não foi encontrado ou sua situação é inválida. Por isso, a mensagem não permite concluir, sozinha, que basta cadastrar novamente a empresa ou renovar um certificado.

Antes de alterar qualquer dado, identifique se a resposta veio da autorização de uma nota ou do registro de um evento. O código está previsto nos dois serviços, com regras próprias. Guarde a mensagem completa, o ambiente e a solicitação correspondente. Uma descrição resumida na tela pode omitir informações necessárias para distinguir o problema do provedor de outras rejeições.

O que a SEFAZ verifica

A NT 2026.001 v1.02b estabelece a ZG02-20 na autorização e a P81-20 no registro de eventos. Em ambas, quando o grupo infPAA está informado, o sistema acessa o Cadastro de PAA usando CNPJPAA como chave de pesquisa. A rejeição ocorre se esse CNPJ não existe no cadastro ou apresenta situação inválida. As linhas são obrigatórias dentro dessas condições e indicam implementação somente na SVRS.

O quadro da ZG02-20 identifica os modelos 55/65; a P81-20 identifica o modelo 55. Esse detalhe precisa ser lido junto às demais restrições do projeto. A B07-10 rejeita o modelo 65 quando utilizada série do PAA. Assim, a referência 55/65 em uma validação cadastral não constitui permissão geral para emitir NFC-e por esse processo.

CNPJPAA é a identificação do Provedor de Assinatura e Autorização. Na nota, fica no grupo infPAA de infNFe; no evento, no grupo infPAA de infEvento. Os campos que identificam o emitente e o autor do evento cumprem outras funções. Preencher o CNPJ do contribuinte no lugar do provedor pode provocar uma consulta cadastral à empresa errada.

CNPJ válido, cadastro e vínculo são conferências diferentes

Conferir comprimento e dígitos verificadores ajuda a identificar problemas de preenchimento, mas não comprova que o provedor está registrado e apto na base consultada. Da mesma forma, um comprovante de inscrição da empresa no CNPJ não substitui a verificação específica do Cadastro de PAA. A 671 deve ser investigada no contexto do serviço utilizado, sem presumir que a situação encontrada em outro cadastro seja suficiente.

O vínculo do emitente com o PAA também é uma relação diferente. No serviço de autorização, a ZG02-30 consulta esse vínculo e utiliza o código 936 na versão examinada. Nos eventos, a P81-30 conserva 672 para o emitente não associado. Essas condições não devem ser confundidas com a existência e a situação do próprio provedor verificadas pela 671.

Há ainda regras separadas para CNPJ inválido, certificado de assinatura e assinatura RSA. A ZG02-10 usa 634 na autorização, enquanto a P81-10 conserva 670 nos eventos. A ausência de uma dessas mensagens não comprova que todas as respectivas validações passaram: o diagnóstico deve se apoiar no conteúdo enviado e no retorno efetivo, sem pressupor uma ordem universal de processamento.

Como investigar a causa

Primeiro, recupere o XML que gerou a resposta e localize CNPJPAA. Compare o valor com a identificação do provedor contratado e efetivamente usado pela integração. Não se limite ao nome comercial exibido no sistema. Confira se há dados antigos após uma migração, ambiente configurado de forma diferente ou preenchimento padrão vindo de um cadastro incompleto.

Em seguida, confirme com o provedor sua habilitação e situação no cadastro correspondente ao fluxo PAA da SVRS. O Portal da Plataforma de Emissão Simplificada disponibiliza serviços de credenciamento de provedores e cadastro de empresas usuárias. A existência desses serviços públicos não comprova que determinado CNPJ está habilitado; a situação concreta precisa ser verificada pelo responsável autorizado.

Se o CNPJ enviado estiver errado, corrija o cadastro ou o mapeamento que produziu o valor e gere novamente a solicitação pelo fluxo competente, incluindo as assinaturas necessárias. Se a identificação estiver correta, o provedor deve apurar a inexistência ou a situação inválida apontada e adotar a regularização cabível. Repetir a mesma transmissão sem mudança ou confirmação cadastral pode apenas reproduzir o retorno.

Registre o ambiente de homologação ou produção utilizado, a chave da nota, o tipo de evento quando houver, o horário e a resposta completa. Encaminhe essas informações ao suporte responsável quando a divergência persistir. Evite afirmar que existe atraso de sincronização ou um prazo fixo de atualização sem orientação concreta do provedor ou da administração tributária.

Exemplo de uma divergência de integração

Considere uma empresa que já utiliza o provedor B, mas cuja integração continua preenchendo CNPJPAA com a identificação do antigo provedor A. A SVRS devolve 671 ao consultar esse identificador, inexistente ou em situação inválida no cadastro. As letras A e B representam empresas hipotéticas, sem fornecer CNPJs para reprodução.

A correção começa pela confirmação de qual provedor realmente executou o serviço e de quais vínculos e configurações devem ser utilizados. Havendo erro de mapeamento, a integração precisa recuperar os dados corretos desse relacionamento. Copiar o CNPJ de outro provedor apenas porque ele aparece como habilitado não corrige o serviço prestado e pode causar outras inconsistências.

Depois de ajustar a origem, o documento ou evento deve ser gerado e assinado pelo fluxo adequado. Não se deve editar manualmente o XML já assinado, excluir infPAA para esconder o problema ou trocar modelo, série e processo de emissão por tentativa. Esses elementos precisam representar a operação e a forma de emissão efetivamente adotadas.

Como confirmar que o atendimento terminou

Se a rejeição ocorreu em um evento de uma NF-e autorizada, ela não desfaz automaticamente a autorização dessa nota. Por exemplo, tentar cancelar e receber 671 não significa que o cancelamento foi registrado. Consulte a situação do documento e o resultado do evento antes de refletir a mudança no sistema.

Se ocorreu na autorização, confira o resultado real dessa solicitação após o ajuste. A eliminação da 671, isoladamente, não garante autorização: outras regras podem impedir o processamento. Em caso de retorno incerto, recupere a situação efetiva antes de decidir por uma nova tentativa ou por outro documento.

O cronograma da versão 1.02 do PAA registra testes em 03/08/2026 e produção em 05/10/2026, com ajustes documentais posteriores nas versões 1.02a e 1.02b. Essas datas não atestam o cadastro de uma empresa específica. O atendimento fica concluído quando a identidade e a situação do provedor foram conferidas, a solicitação correta foi processada e a resposta correspondente foi preservada.

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.

  • BuscadorNCM 671: ficha específica com corpo HTTP200 de 15/10, da regra às perguntas e referências. O predicado cadastral converge; a aplicação genérica em todas as UFs e a receita centrada em certificado não foram adotadas.

  • Contábeis — atualização do PAA: corpo integral da notícia lido, apoio ao contexto de versão e calendário. Não é tutorial específico de regularização cadastral da 671.

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.

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.