Rejeição 667: processo de emissão pelo PAA incompatível com a série da NF-e

A rejeição 667 indica que a NF-e foi apresentada como emissão por Provedor de Assinatura e Autorização, o PAA, mas sua série ficou fora da faixa reservada a esse processo. O diagnóstico começa pela combinação de dois campos do XML: ide/procEmi, que identifica o processo de emissão, e ide/serie, que informa a série da nota.

Na NT 2026.001 PAA v1.02b, a regra B26-24 alcança a NF-e modelo 55, tem aplicação obrigatória e contém uma observação expressa: implementação somente na SVRS. A condição é procEmi=4 com série fora de 970–989. Não basta procurar o número 667 em uma lista genérica: confira também documento, serviço, mensagem completa, autorizador e ambiente do retorno. [1]

Qual série deve ser usada

A faixa 970–989 não funciona como um conjunto de números livres. O leiaute distingue 970–979 para emitente CPF e 980–989 para emitente CNPJ. Além disso, a relação entre emitente e PAA recebe uma série específica, definida no vínculo. O emissor precisa utilizar essa série atribuída, respeitando sua identificação e o ambiente correspondente. [1]

São verificações diferentes. A 667 identifica a série fora da faixa geral do PAA. Já uma série que pertence à faixa, mas difere daquela estipulada para o emitente no provedor, é objeto da regra ZG02-34, associada à rejeição 872. Portanto, colocar qualquer valor entre 970 e 989 pode afastar uma incompatibilidade e deixar outra pendente.

Também não se deve tratar o PAA como sinônimo de qualquer sistema que transmite notas. A nota técnica descreve um processo próprio, com provedor, vínculo e assinaturas. O uso de um software comercial, isoladamente, não comprova que a emissão acontece por PAA nem autoriza preencher procEmi=4.

Confira o arquivo que foi realmente transmitido

Preserve o XML enviado e o retorno correspondente antes de mudar a configuração. Uma tela pode mostrar a série correta enquanto uma integração, um cadastro antigo ou uma configuração específica do estabelecimento gera outro valor no arquivo. Compare os dados do mesmo envio, evitando misturar uma tentativa anterior com o XML já corrigido.

Registre modelo, emitente, número, série, processo de emissão, ambiente e endereço do serviço utilizado. Depois, confirme com o responsável pela integração se aquela operação deveria efetivamente passar pelo PAA. Essa verificação define o caminho de correção; não é adequado alterar apenas o campo apontado na mensagem sem compreender o processo utilizado.

Se o resultado de outro envio estiver incerto, consulte a situação da chave correspondente antes de repetir a operação. O retorno 667 rejeita a tentativa analisada, mas não esclarece sozinho o resultado de todas as transmissões anteriores. Preserve a relação entre pedido, documento, tentativa e resposta para evitar duplicidade operacional.

Quando a emissão é realmente pelo PAA

Se procEmi=4 está correto e o XML contém, por exemplo, série 1, confronte a configuração com a série efetivamente atribuída ao vínculo. Confirme emitente, provedor e ambiente; uma série configurada para outro estabelecimento ou outra relação não resolve o problema.

Após identificar o valor correto, ajuste a origem do dado no emissor ou na integração. Gere novamente o documento pelo fluxo de emissão, permitindo que o sistema recomponha suas informações e assinaturas. Evite editar manualmente um XML já assinado ou simplesmente substituir números no arquivo exportado.

Suponha, apenas para ilustrar, um emitente CNPJ cujo vínculo válido tenha recebido a série 985. Se sua NF-e modelo 55 foi gerada com procEmi=4 e série 1, há a combinação prevista na 667. A correção seria utilizar a série 985 comprovadamente atribuída àquele vínculo. Escolher 980 porque também está na faixa do CNPJ não seria uma solução fundamentada.

O exemplo não comprova credenciamento, vínculo, série ou autorização de um contribuinte real. Depois da correção, continuam existindo outras verificações do documento. O desaparecimento da 667, por si só, não substitui a conferência do retorno final e do protocolo da nota correta.

Quando o PAA foi indicado indevidamente

Se a operação utiliza outro processo de emissão e procEmi=4 surgiu por configuração incorreta, não transfira a nota artificialmente para uma série do PAA. O suporte deve corrigir o mapeamento para representar o processo que realmente será executado, considerando também a série e os demais campos compatíveis com ele.

Essa correção exige coerência do documento inteiro. A NT possui validações próprias para a presença de infPAA, para sua ausência quando exigida e para o ambiente autorizador. Retirar informações de um PAA efetivamente utilizado, ou mudar o processo apenas para contornar a mensagem, não regulariza a emissão. [1]

No ALRA, não foi comprovado nesta pesquisa um menu específico nem uma integração PAA em funcionamento. Encaminhe ao suporte os dados do envio e a série atribuída, usando o canal apropriado para documentos fiscais. Senhas, certificados e chaves privadas não são necessários para explicar a incompatibilidade de série.

Cuidados com referências antigas e ambientes

Há materiais que ainda apresentam 970–979 como faixa geral do PAA ou associam essa verificação à antiga redação de B26-20. No PDF atual, esses trechos aparecem riscados, enquanto B26-24 mantém 970–989. O texto e a aparência da página precisam ser considerados juntos; copiar uma linha antiga extraída do PDF pode produzir orientação incorreta. [1][4]

O cronograma da NT registra homologação em 03/08/2026 e produção em 05/10/2026 para a versão 1.02; as versões 1.02a e 1.02b apresentam ajustes documentais sem novas datas na tabela. Isso não comprova o credenciamento ou a ativação individual de um contribuinte. A limitação “somente SVRS” continua necessária e não deve ser substituída por uma afirmação de aplicação indistinta em todas as UFs.

Se o XML aparentar atender à regra e a rejeição persistir, forneça ao suporte o retorno integral, a versão do emissor, o ambiente e a comprovação da série do vínculo. Essa comparação permite distinguir arquivo desatualizado, configuração incorreta e divergência que dependa do provedor ou do autorizador.

Fontes e limites

Pesquisa em 15/10/2026, horário de Brasília. Artigo novo, sem texto histórico local. Não houve teste no ALRA ou na SVRS.

1. NT 2026.001 PAA v1.02b, páginas 3–7 e 10–14: PDF oficial HTTP 200 de 15/10 reutilizado por hash; textos pertinentes lidos e PNGs já existentes das páginas 3/10/12/13/14 inspecionados. B26-24 íntegra, B26-20 antiga riscada e ZG02-34 distinta. Índice SVRS: entrada v1.02b de 29/07/2026 lida em captura de 15/10.

2. Esquemas XML NF-e: pacote 010f de 15/10 reutilizado; declarações serie, procEmi, CRT, infPAA, TSerie e TProcEmi lidas. Aceitação estrutural não comprova a regra de negócio. Nenhum XML externo foi validado.

3. Buscador NCM — 667: corpo específico completo HTTP 200 lido, “conferido” em 12/10/2026; a versão WEB apresenta 09/10. A frase “obrigatória em todas as UFs” contradiz a observação “somente SVRS” reproduzida pelo próprio guia e foi descartada. Reaproveitamento incondicional da numeração também não foi adotado.

4. TecnoSpeed — PAA: artigo geral HTTP 200 de 29/07/2026 lido integralmente. Cita a 667, mas conserva seções históricas com faixa 970–979 e B26-20; elas não prevalecem sobre a regra atual. Promessas sobre produtos TecnoSpeed não foram atribuídas ao ALRA.

5. Sercom — NF-e: HTTP 200, trechos de séries PAA, vínculo e entrada 668 lidos integralmente; não o manual inteiro. Apoio contextual curto, sem data editorial certificada. A separação CPF/CNPJ foi conferida na primária; menus não foram testados ou atribuídos ao ALRA.

São três editores de apoio, não três tutoriais completos exclusivos da 667. Busca focal em seis caches de NTs de 2026 encontrou “667” como parte do CFOP 5.667 e “C21-20” dentro de outra regra, 12C21-20; isso não altera B26-24 nem prova ausência universal de alterações. Histórico de pesquisa, hashes e limites preservados. Cruzada independente pendente; publicação não realizada.