Rejeição 878 na NFC-e: confira o endereço de consulta por chave

Se a emissão do cupom recebeu a rejeição 878, confira o endereço de consulta por chave de acesso que o sistema enviou. A divergência pode estar em uma configuração antiga, na seleção da filial ou na geração do arquivo. Antes de repetir o envio, identifique qual endereço foi usado e qual fonte oficial sustenta sua correção.

A mensagem deste contexto é “Rejeição: Endereço do site da UF da Consulta por chave de acesso diverge do previsto”. Ela trata de uma informação da NFC-e, não do site comercial da empresa. Também não demonstra, por si só, que a internet caiu ou que o serviço de autorização está indisponível.

O campo que precisa ser conferido

No MOC 7.0, Anexo I, a regra ZX03-20 está associada ao modelo 65, no serviço de autorização. O endereço fica em infNFeSupl/urlChave, campo ZX03. A página 66 define sua finalidade; a página 133 apresenta o predicado completo, e a página 152 contém a mensagem resumida.

Há dois campos próximos, com funções diferentes:

Copiar a URL completa do QR Code para urlChave não substitui essa distinção. Os documentos consultados encaminham os dois campos a referências separadas de endereços por UF. É necessário conferir a fonte e o campo correto, não simplesmente usar qualquer página que abra uma consulta.

Aplicação e limite desta orientação

A ZX03-20 aparece como facultativa por UF, com marco documental de 01/04/2019. Isso não comprova ativação em todos os autorizadores ou ambientes. A UF do estabelecimento, o autorizador utilizado e o ambiente de produção ou homologação precisam acompanhar o diagnóstico. Uma SEFAZ virtual compartilhada não torna automaticamente iguais os endereços de consulta das UFs atendidas.

A conferência de 15/10/2026 utiliza o MOC novamente obtido, a NT 2025.001 v1.03 e a declaração de urlChave no pacote XML 010f. A versão do QR Code é outra identificação. A regra documental não comprova a ativação em cada UF ou ambiente nem permite escolher um endereço apenas porque ele abre no navegador.

Consulte a referência oficial do campo certo

No Portal Nacional da NFC-e, acesse a área do desenvolvedor e a relação URL por UF utilizada para consulta chave. A página encaminha a uma tabela de consulta por chave, separada da relação de URLs do QR Code. Há estados com endereço compartilhado entre ambientes e outros com linhas próprias para homologação e produção.

Na tabela consultada, São Paulo possui referências distintas para os dois ambientes. Isso ilustra por que copiar a configuração de homologação para produção pode produzir uma divergência; não constitui comprovação de uma tentativa real. Preserve a publicação usada e confirme a orientação da SEFAZ do estabelecimento antes de configurar.

Páginas oficiais também podem conservar referências antigas ou apresentar diferenças entre caminhos de acesso à tabela. Na consulta realizada, as duas páginas de consulta por chave divergiam na linha da Paraíba. Havendo conflito, reúna os endereços e peça confirmação ao atendimento da UF; não escolha pelo resultado de uma tentativa nem copie o endereço de outra modalidade de consulta.

Reúna as evidências da tentativa

Guarde o XML efetivamente enviado e a resposta completa. Registre chave, modelo, filial, UF, ambiente e horário. Localize urlChave no arquivo e compare com a configuração usada para aquela emissão. O valor exibido hoje na tela pode ser diferente do que foi transmitido anteriormente.

Confira também o conteúdo de qrCode, mantendo os campos separados. Procure endereço pertencente a outra UF, referência desatualizada, caminho diferente ou transformação feita pela integração. Essas são hipóteses de diagnóstico: nenhuma autoriza trocar protocolo, retirar partes da URL ou acrescentar parâmetros por tentativa.

Se o erro estiver apenas na página aberta pelo consumidor, primeiro confirme a situação fiscal da nota. Uma falha na consulta de um documento já autorizado exige análise própria; não é motivo para criar outra NFC-e para a mesma venda.

Corrija conforme a origem comprovada

Configuração antiga de endereço. O suporte deve confrontar a URL enviada com a referência oficial aplicável à UF e ao contexto da emissão. Havendo substituição comprovada, atualize a configuração que gera urlChave. Uma lista antiga ou o link encontrado em um cupom de outra empresa não basta como confirmação.

Filial ou UF selecionada incorretamente pelo sistema. Compare o estabelecimento verdadeiro com a origem da configuração. Corrija a associação da filial ao endereço pertinente, sem mudar a UF do emitente ou outros fatos fiscais para combinar com uma URL disponível. Revise integrações que compartilham parâmetros entre estabelecimentos.

Endereço do QR Code colocado no campo de consulta por chave. Separe as duas origens no gerador. Preserve os parâmetros de qrCode segundo sua versão e preencha urlChave conforme sua própria especificação. Não tente corrigir o 878 alterando CSC, assinatura do QR Code ou dígitos da chave sem uma divergência específica comprovada.

Tela corrigida, arquivo ainda incorreto. Investigue configuração em cache, serviço de emissão separado ou rascunho preparado antes da alteração. Regenere o documento rejeitado pelo fluxo do emissor e compare a nova informação. Corrigir somente o endereço impresso deixa sem explicação o valor transmitido à SEFAZ.

Exemplo condicional de uma filial

Uma rede fictícia configura uma nova filial usando parâmetros copiados de outro estabelecimento. Na tentativa de emitir uma venda de R$ 73, o sistema monta urlChave com a referência de outra UF e recebe 878.

Se o suporte confirmar que essa é a causa e obtiver a referência oficial aplicável, deverá corrigir a seleção da configuração. A venda continua com o mesmo estabelecimento real, produtos e valores. O arquivo regenerado precisa mostrar o endereço destinado àquela filial. O exemplo não indica uma URL concreta nem garante autorização: as demais validações continuam aplicáveis.

Mudança de QR Code não resolve automaticamente o 878

A NT 2025.001 v1.03, página 8, mantém urlChave separado de qrCode. Sua previsão de migração do QR Code não fornece uma nova URL de consulta por chave. Trocar CSC, versão, ambiente ou contingência para evitar a mensagem não corrige uma seleção indevida de endereço. O esquema aceita o formato do campo; isso não comprova que a URL corresponde à UF.

Confira o resultado e saiba quando escalar

Depois de corrigir a causa comprovada, faça uma tentativa controlada e examine o retorno inteiro. Confira se houve autorização, se a chave corresponde à venda e se o XML e seu protocolo foram preservados. O desaparecimento do 878 não basta para considerar a nota autorizada.

Com a situação fiscal confirmada, verifique a coerência entre urlChave e o endereço indicado no DANFE NFC-e. Se a consulta pública falhar, registre o endereço e o erro observado para investigação; evite novas emissões sem conferir o documento existente.

Encaminhe ao suporte quando configuração e XML divergirem, faltar a referência atual ou o retorno persistir após conferência. Havendo conflito entre publicações oficiais e comportamento do autorizador, o atendimento da SEFAZ deverá esclarecer o ambiente e a regra aplicada. Nenhum resultado operacional foi testado nesta elaboração.

Fontes

Conferência documental em 15/10/2026, sem emissão de teste ou validação operacional do ALRA.

• MOC 7.0, Anexo I: páginas 66 e 133, urlChave e ZX03-20/878. Schemas XML do Portal Nacional, pacote 010f.

• NT 2016.002 v1.61: página 73.

• NT 2025.001 v1.03, página 8. Portal Nacional da NFC-e: consulta por chave, com tabela vinculada e caminho alternativo da tabela. Consulta pública da tabela não equivale a teste de aceitação em cada ambiente.

• Apoios práticos: TecnoSpeed, Sankhya, Vinco. Exemplos e comandos de outros emissores não descrevem procedimentos comprovados do ALRA.