Rejeições fiscais
Rejeição 867: confira o grupo do PAA na NF-e ou no evento
Se o retorno informa que o grupo do Provedor de Assinatura e Autorização não foi enviado, identifique primeiro se a falha ocorreu na emissão da NF-e ou no registro de um evento. A nota pode ter sido preparada pelo processo PAA, mas sua integração omitiu as informações que identificam o provedor e a assinatura…
Se o retorno informa que o grupo do Provedor de Assinatura e Autorização não foi enviado, identifique primeiro se a falha ocorreu na emissão da NF-e ou no registro de um evento. A nota pode ter sido preparada pelo processo PAA, mas sua integração omitiu as informações que identificam o provedor e a assinatura correspondente.
A mensagem tratada aqui é “Rejeição: Grupo de informações do Provedor de Assinatura e Autorização não informado”. Ela exige investigar a ausência de infPAA no contexto correto. Trocar um certificado, repetir a transmissão ou preencher somente o CNPJ em um cadastro não demonstra que o grupo passou a integrar o XML efetivamente enviado.
Dois serviços, duas condições
Na NT 2026.001 PAA v1.02b, página 12, a B26-26 trata da autorização da NF-e modelo 55. Quando procEmi=4, processo de emissão pelo PAA, o grupo infPAA deve estar informado. A linha classifica a validação como obrigatória e registra implementação somente na SVRS.
No registro de evento, a P80-30, página 17, também é obrigatória, modelo 55 e somente na SVRS. Suas condições são diferentes: série na faixa 970–989 e evento do emitente dos tipos 110111, cancelamento; 110112, cancelamento por substituição; ou 110110, Carta de Correção. Nesse cenário, a ausência de infPAA produz o mesmo código 867.
Não transfira automaticamente o campo procEmi da NF-e para o leiaute do evento nem trate qualquer evento como abrangido pela P80-30. A existência desses eventos na regra não dispensa seus requisitos próprios. Antes de reenviar, confirme o serviço, o tipo de evento e a finalidade real da operação com o suporte e o responsável fiscal.
O que deve chegar ao XML
O leiaute da NF-e, página 11 da NT, reúne em infPAA o CNPJ do provedor, CNPJPAA, e a estrutura PAASignature, com assinatura e chave pública. Para eventos, a página 15 apresenta o grupo correspondente no envelope do evento. O provedor precisa gerar o conteúdo no documento correto; uma anotação em informações adicionais não substitui o grupo estruturado.
O schema 010f examinado admite ocorrência opcional de infPAA no leiaute geral. Isso não dispensa sua presença quando a regra condicional do processo PAA a exige. Dentro do grupo, há elementos próprios de identificação e assinatura. Informar uma estrutura incompleta pode levar a outra rejeição ou falha de esquema.
Também separe ausência de grupo, identificação do signatário e validação criptográfica. A 776 trata do CNPJ-base do certificado no contexto pertinente; a 856, da assinatura RSA. Resolver a ausência de infPAA não comprova que suas assinaturas, vínculo ou chave estejam válidos.
Por que o grupo pode desaparecer
Uma integração pode receber a indicação de processo PAA e continuar usando uma versão de geração sem o grupo. Outra possibilidade é preencher os dados no cadastro do provedor, mas não incorporá-los à nota preparada anteriormente. A atualização do cadastro não prova atualização do arquivo rejeitado.
No evento, o sistema pode reutilizar um fluxo genérico que não monta as informações do PAA para os tipos abrangidos. É necessário comparar a solicitação enviada pela aplicação com o XML final. Uma tela mostrando o provedor não confirma seu posicionamento no arquivo.
Existe ainda o cenário de processo escolhido incorretamente. Se a operação não usa PAA, a indicação procEmi=4 precisa ser analisada na origem. Não escolha outro processo apenas para eliminar o retorno; confirme qual modalidade foi efetivamente contratada e utilizada.
Diagnóstico antes de corrigir
Preserve XML, retorno, chave, horário, serviço, modelo, ambiente e autorizador. Na emissão, confira procEmi e a presença de infPAA no XML da NF-e. No evento, confira chave, série, tpEvento e o grupo dentro da estrutura própria do evento, sem comparar documentos de versões diferentes.
Peça ao suporte que rastreie a informação desde a seleção do processo até a geração e assinatura. Identifique se o dado não foi produzido, foi descartado pela integração ou foi colocado em outra estrutura. Verifique também a versão do leiaute utilizada pelo emissor e pelo provedor.
Não tente suprir a falta copiando o bloco de outra empresa ou documento. Assinatura e identificação pertencem ao contexto gerado. Chaves privadas, senhas e arquivos de certificado não devem ser enviados em chamados de atendimento; compartilhe as evidências técnicas pelo canal apropriado do provedor, com proteção dos dados da operação.
Corrija conforme a causa comprovada
A operação usa PAA, mas a integração omitiu o grupo. Corrija a geração para incorporar as informações legítimas do provedor no local previsto. Regenere o documento rejeitado e as assinaturas pelo fluxo autorizado, conferindo o arquivo produzido antes do envio.
O problema ocorre somente no evento. Confirme as condições da P80-30 e ajuste o gerador específico. O fato de a NF-e original conter infPAA não significa que o evento já o recebeu. Preserve o vínculo entre evento, chave e emitente e confira o resultado individual do processamento.
O processo PAA foi indicado indevidamente. Analise a configuração com o fornecedor e o responsável fiscal. Corrija somente o que estiver comprovadamente errado, sem alterar arbitrariamente série, processo ou identidade do provedor. A presença indevida de infPAA tem regras próprias e pode produzir 893.
Exemplo de falha no mapeamento
Uma empresa fictícia utiliza legitimamente PAA para emitir uma NF-e modelo 55. A solicitação registra procEmi=4, mas uma rotina antiga ignora o grupo do provedor. A SVRS devolve 867. A equipe compara a solicitação com o XML, identifica a omissão e atualiza o mapeamento.
Depois, o provedor gera novamente o documento com suas informações e assinaturas correspondentes. A equipe confere a presença do grupo e acompanha a resposta. O exemplo não comprova habilitação de empresa real, disponibilidade do PAA no ALRA ou validade de uma assinatura concreta.
Calendário e confirmação do resultado
O controle da NT, página 3, apresenta homologação em 03/08/2026 e produção em 05/10/2026 para a versão 1.02. As correções 1.02a e 1.02b não indicam novas datas nessa tabela. A consulta documental de 15/10/2026 não equivale a teste individual de implementação. Não use o calendário de outra NT como prorrogação geral deste fluxo.
Se o resultado de uma transmissão anterior estiver incerto, consulte a situação correspondente antes de repetir. Leia o retorno completo da nova tentativa: eliminar a 867 não garante autorização da nota nem registro do evento. Conserve o XML e o protocolo quando o resultado do documento correto estiver confirmado. Acione o provedor e o suporte quando o grupo legítimo continuar ausente ou o retorno persistir com o arquivo coerente.
Fontes e limites
Pesquisa textual em15/10/2026, horário de Brasília. Capturas oficiais desse dia reutilizadas por identidade e novos corpos de apoio. Sem emissão ou evento de teste no ALRA, comprovação de habilitação de empresa/provedor real, validação criptográfica ou certificação de implantação individual.
NT2026.001PAA v1.02b: PDF703310 HTTP200 de15/10local reutilizado. Páginas3/11/12/15/17/18 lidas; PNGs existentes12/14/17/18 pessoalmente inspecionados. B26-26 eP80-30 íntegras, ambas55/Obrig/SVRS. Não são permissão geral para eventos ouNFC-e.
ÍndiceSVRS: captura15/10 reutilizada, entrada v1.02b lida. Registra29/07/2026; o apoioATVI apresenta31/07/2026. Essa divergência de data editorial não foi usada para substituir versão ou cronograma doPDF. Busca emseiscaches2026 não encontrou867/regras/grupoinfPAA; não esgotamento normativo.
Schemas oficiais: pacote010f HTTP200 de15/10 e declaração completa deinfPAA no leiaute lidos. Grupo opcional noXSDgeral não dispensa RVcondicional; sem compilar esquema ouvalidar XMLreal. Leiaute de evento cotejado noPDF, não apresentado comoXSDdoevento validado.
BuscadorNCM867: ficha específicaHTTP200, corpo da regra àsFAQs/referências lido,12/10/2026/consol09/10. A própria regra transcrita dizSVRS; o rótulo todasUFs contraditório não foi adotado. Sugestão genérica de trocar/conferir certificado não resolve a ausência do grupo por si só. Demaisdocumentos/homônimos, numeração e denegação não foram tomados como orientação geral.
TecnoSpeedPAA: panorama técnicoHTTP200 eWEB,29/07/2026, seção pertinente completa lida. Descreve infPAA e fluxo, mas conserva referências antigas a séries970–979/B26-20 e códigos substituídos; prevalece oPDF inspecionado. Garantias de adequação do produto, generalizações paraNFC-e e relação comReforma não comprovam suporteALRA ou habilitação individual.
ATVI: panorama da v1.02bHTTP200, corpo técnico inteiro lido. Explica grupo e assinaturas, sem tutorial específico da867. Data editorial de publicação não substitui a entradaSVRS nem as datas da página3. Procedimentos de vínculo, geração de chaves e eventuais atos legais dependem da documentação oficial aplicável ao caso.
Foram encontrados três editores com material pertinente, incluindo uma ficha e dois panoramas de PAA; não três tutoriais completos exclusivos da867. Nenhum menu ou recurso doALRA foi demonstrado. As assinaturas devem ser produzidas pelo fluxo legítimo, sem copiar blocos de outros documentos. Sem imagens novas, capas ou publicação.