Rejeição 813: entenda o escape do QR-Code antigo e confira a versão

Ao encontrar a mensagem 813 em um retorno ou registro de emissão, preserve o XML original e confirme qual versão de QR-Code estava sendo usada. A expressão “Usar CDATA” se refere a uma condição documentada do formato antigo. Aplicar essa orientação a qualquer QR-Code pode deixar a causa real sem solução.

A mensagem literal é “Rejeição: QR-Code com sequência de escape para o e-comercial. Usar CDATA”. O problema tratado nessa regra está na representação do conteúdo do QR-Code no arquivo. Trocar a impressão do cupom, sozinho, não corrige o dado que foi transmitido.

Qual é o contexto da regra

O MOC 7.0, Anexo I, página 129, associa ZX02-22 à autorização da NFC-e modelo 65. A condição é explícita: QR-Code versão “100” contendo sequência de escape para o caractere &, indicada na especificação por &. A nota da regra orienta usar CDATA nesse contexto.

Existe uma ressalva histórica: em produção, a regra não se aplica a documentos com emissão anterior a 03/04/2017. Esse marco deve ajudar a interpretar arquivos antigos; não é uma permissão atual para emitir com aquele leiaute.

O corpo oficial do MOC foi conferido novamente em captura de 15/10/2026. A documentação preserva essa condição histórica, mas sua presença no manual não comprova execução atual em todas as UFs, autorizadores ou ambientes. Confira o contexto do retorno efetivamente recebido.

Não volte ao QR-Code “100” para corrigir a emissão

A mesma base MOC, página 128, registra a rejeição 903 para QR-Code “100” com emissão posterior a 30/09/2018. Portanto, o cenário histórico da 813 não deve virar orientação para reativar esse formato em uma emissão nova.

A NT 2025.001 v1.03, página 14, documenta as versões 2 e 3, com estruturas próprias e parâmetros separados por |. Para essas duas versões, o documento informa que não existe necessidade de colocar a tag qrCode dentro de CDATA.

O Manual DANFE NFC-e e QR-Code v6.0 também separa os formatos online e offline das versões 2 e 3. Confira a especificação correspondente à emissão e ao ambiente. Não altere somente o número da versão mantendo parâmetros de outro leiaute.

Versão do QR-Code e versão do XML são coisas diferentes. Uma NFC-e com XML 4.00 não significa, por isso, QR-Code versão “100”, 2 ou 3. O gerador precisa produzir o conjunto correto de informações.

O que CDATA faz e o que não faz

CDATA delimita um trecho do XML que deve ser tratado como texto. No formato antigo documentado, isso permitia representar a URL com o separador & sem transformar esse caractere em texto escapado dentro do conteúdo.

Porém, envolver uma URL já alterada em CDATA não recupera automaticamente seu valor. Se o texto fornecido ao gerador contém literalmente &, esse texto pode continuar dentro da seção. O suporte deve conferir a montagem da URL e sua serialização, não apenas acrescentar delimitadores.

Um exemplo apenas de caracteres, sem representar parâmetros fiscais, ajuda a perceber a diferença: A=1&B=2 e A=1&B=2 são sequências distintas. Não use esses trechos como URL válida de NFC-e.

Também não faça uma substituição global de & por & em todo o XML. Outros campos precisam respeitar suas próprias regras de representação. A correção deve acontecer no gerador e no ponto comprovadamente errado.

Como reconhecer o cenário

Reúna retorno completo, XML enviado, chave, data, modelo, UF emitente, autorizador, ambiente e tipo de emissão. Localize o campo infNFeSupl/qrCode e identifique o formato efetivo da URL.

Separe o conteúdo original da forma como uma tela ou relatório o exibe. Um visualizador HTML pode representar caracteres com entidades; ver & na tela não prova, sozinho, que o arquivo fiscal contém o defeito descrito na regra.

Se o registro usa “100”, examine o contexto histórico e a codificação do conteúdo. Se informa versão 2 ou 3, confronte os parâmetros e a versão do emissor com a documentação pertinente. Não atribua automaticamente qualquer falha de leitura do QR-Code à 813.

Correção por cenário

O registro antigo recebeu 813 por codificação do conteúdo

Peça ao suporte para localizar onde a URL foi escapada indevidamente ou enviada com o tratamento incompatível com o formato documentado. Confira o conteúdo antes e depois da serialização e a utilização de CDATA quando cabível naquele contexto histórico.

A análise de um arquivo antigo não autoriza reenviar uma emissão fora das regras atuais. Preserve o histórico e separe a correção do software da eventual regularização fiscal.

A mensagem reaparece em uma rotina de emissão nova

Confira se o programa está reutilizando um gerador antigo, uma resposta guardada ou um XML preparado antes da atualização. O fornecedor deve demonstrar qual arquivo e retorno correspondem à tentativa atual.

Ajuste a geração para o leiaute aplicável e confirme seus parâmetros completos. Não mantenha “100” nem monte um formato misto apenas para afastar a mensagem.

O gerador trabalha com versão 2 ou 3

Nesses formatos, a exigência de CDATA da ZX02-22 histórica não é uma solução geral. Verifique endereço de consulta, versão, ambiente, modo online ou offline e parâmetros correspondentes.

A NT 2025.001 v1.03, novamente obtida em 15/10/2026, descreve a adoção exclusiva da versão 3 como mudança futura, sem data definida. Isso não comprova a situação atual de cada UF. O suporte deve conferir a regra vigente, sem inventar um prazo universal nem remover controles de uma versão ainda utilizada.

Como exemplo de conferência do endereço, a página oficial paulista consultada em 15/10/2026 publica bases distintas para homologação e produção: www.homologacao.nfce.fazenda.sp.gov.br/qrcode e www.nfce.fazenda.sp.gov.br/qrcode, ambas com HTTPS. São bases de consulta, às quais o gerador acrescenta os parâmetros; não são URLs completas para copiar em qualquer nota ou UF. O manual admite que outras UFs utilizem um mesmo endereço para ambos os ambientes.

O cupom já está autorizado e o problema aparece na consulta

Confira se o aviso veio da autorização ou da página aberta pelo QR-Code. Os códigos da consulta pública têm contexto próprio. Compare a URL impressa com a informação preservada no documento, sem alterar manualmente o XML autorizado.

O suporte deve investigar geração e impressão. Não emita outra nota para a mesma venda apenas porque a leitura do QR-Code falhou.

Exemplo condicional

Em um teste fictício do leiaute antigo, a rotina monta uma URL com separadores &. Antes de gravar qrCode, outra camada converte esses separadores para o texto literal &. Mesmo delimitado por CDATA, o conteúdo conserva essa sequência e o teste recebe 813.

A equipe corrige a preparação do conteúdo e confere a serialização naquele teste. Depois verifica separadamente o gerador destinado às versões 2 ou 3. O exemplo não reproduz uma chave, URL oficial ou emissão real, nem orienta a usar “100” atualmente.

Verificação e escalonamento

Após corrigir a rotina, compare o conteúdo gerado com a especificação aplicável e com o documento correspondente. Em uma emissão pendente, faça o processamento pelo fluxo apropriado do emissor e leia o novo retorno.

O desaparecimento da 813 não garante autorização nem comprova que a consulta pública está correta. Preserve os arquivos e, quando houver autorização, seu protocolo. Acione o suporte para codificação, versão ou impressão; procure o responsável fiscal se houver documento autorizado incorreto ou necessidade de regularização.

Fontes

Documentação e apoios conferidos em 15/10/2026. A conferência é documental; não houve emissão de teste ou validação da rotina ALRA.

• MOC 7.0, Anexo I: páginas 66, 70, 128 e 129, campo ZX02 e regras ZX02-15/903 e ZX02-22/813.

• NT 2025.001 v1.03: páginas 5 e 14, versões e uso de CDATA.

• Manual DANFE NFC-e e QR-Code v6.0: formatos online/offline, páginas 20–22 e 28–30; mensagens próprias da consulta na página 39.

• Sefaz SP, Web Services da NFC-e: endereços publicados para consulta por QR-Code.

• Apoios: Dynamicca, ficha Fiscal Pro e Berga. A orientação genérica de sempre usar CDATA foi limitada pelo alcance das fontes oficiais.