Rejeição 516: a mensagem XML não começa pela raiz esperada pelo serviço

A rejeição 516, “Falha no schema XML – inexiste a tag raiz esperada para a mensagem”, indica um desencontro entre a estrutura enviada e o contrato do serviço fiscal chamado. O caminho de correção é identificar a operação, a mensagem transmitida e seu schema. Mudar imposto, CNPJ ou cadastro do cliente sem essa investigação tende a desperdiçar tempo.

No MOC 7.0, D01a é uma verificação facultativa feita quando falha a validação de schema. Para a raiz do lote de autorização, o manual distingue a rejeição 565. Portanto, “todo XML da NF-e deve começar com a mesma tag” é uma premissa inadequada: consulta, inutilização e registro de evento têm mensagens diferentes.

O que significa raiz nesse diagnóstico

Raiz é o elemento principal da mensagem de dados. O sistema pode colocar essa mensagem dentro de uma comunicação SOAP, que possui sua própria estrutura. A raiz fiscal esperada não se confunde automaticamente com Envelope ou com o cabeçalho do transporte.

Pense numa empresa que tenta consultar a situação de uma nota, mas sua integração envia o arquivo completo que arquivou após a autorização. O arquivo pode ser legítimo para guarda documental, porém não ser a solicitação exigida pelo serviço de consulta. Renomear a primeira tag não transforma todo o conteúdo no pedido correto.

Também é necessário distinguir pedido e resposta. Arquivos com protocolos ou resultados não devem voltar como solicitações. O fornecedor precisa examinar o conteúdo efetivamente transmitido, pois uma prévia correta pode sofrer alteração na montagem final do envio.

Qual mensagem cada serviço espera

O MOC apresenta contratos distintos. Entre os exemplos úteis para diagnóstico:

• Retorno da autorização: consulta com raiz consReciNFe, conforme consReciNFe_v4.00.xsd; não é reenvio do lote original

• Consulta da situação da nota: consSitNFe, no leiaute 4.00, com a chave a consultar

• Status do serviço: consStatServ, no schema consStatServ_v4.00.xsd

• Inutilização: inutNFe, conforme inutNFe_v4.00.xsd

• Consulta cadastral: ConsCad, com essas maiúsculas, conforme consCad_v2.00.xsd

• Recepção geral de eventos: envEvento, cuja estrutura externa é descrita em envEvento_v1.00.xsd e complementada pelo evento específico

• Consulta GTIN da NT 2022.001: consGTIN, com schema descrito como consGTIN_v9.99.xsd

O sufixo v9.99 usado em alguns manuais representa a indicação genérica da versão no nome do arquivo. Não é valor para copiar cegamente para a configuração. O pacote e a versão admitidos pelo serviço precisam ser identificados antes da validação.

No envio para autorização, a mensagem é enviNFe, conforme enviNFe_v4.00.xsd. A comparação serve para separar contratos: no MOC atual, a ausência dessa raiz de lote tem o código específico 565. Não converta toda ocorrência de 516 numa ordem para acrescentar enviNFe.

Os eventos compartilham uma raiz, mas não todo o conteúdo

As notas técnicas consultadas documentam 516 também em EPEC, manifestação do destinatário, ator interessado, comprovante de entrega, insucesso na entrega, conciliação financeira e prorrogação de industrialização. Nesses ramos, a mensagem externa é envEvento; o schema específico e as condições de uso variam.

Para EPEC de NF-e 55, a NT 2014.001 v1.41 identifica eventoEPEC no leiaute; o MOC também apresenta envEPEC. Para EPEC de NFC-e 65, a NT 2014.003 v1.02 mantém contrato próprio. Não copie a configuração entre os dois modelos: disponibilidade na UF e ambiente precisa ser confirmada.

Manifestação utiliza a família envConfRecebto. Cancelamento comum e por substituição têm envEventoCancNFe e envEventoCancSubst, respectivamente. Entrega e seu cancelamento usam envEventoEntregaNFe e envEventoCancEntregaNFe; insucesso e cancelamento, envEventoInsucessoNFe e envEventoCancInsucessoNFe.

Ator interessado e ECONF usam a estrutura genérica de eventos acompanhada de suas definições específicas. Pedido de prorrogação, seu cancelamento e resposta do Fisco aparecem na NT 2015.001 v1.30 com envPProrrogNFe, envCancelPProrrogNFe e envFiscoNfe. A resposta do Fisco é produzida pela administração tributária; não é um evento que o empresário deva fabricar para resolver uma falha.

O BT 2018.002 v1.00 também documenta esse diagnóstico no Visto Eletrônico do Fisco: schema envVistoEletronico_v1.0.xsd, raiz envEvento e atributo versao obrigatório. É um evento de autoria da SEFAZ. Essa ocorrência serve para interpretar o retorno no contexto certo, sem atribuir à empresa a emissão de um visto ou presumir disponibilidade em todas as UFs.

Esses nomes identificam famílias documentais, não substituem o pacote XSD completo. Mesmo quando envEvento está correto, um detalhe incompatível pode levar a outra rejeição. É preciso validar tanto a estrutura geral quanto a parte específica da operação.

Um roteiro para o suporte resolver a causa

1. Registre a ação que falhou: consultar, inutilizar, registrar determinado evento ou pedir autorização. Informe modelo, UF, ambiente e horário.

2. Confirme o endereço e o método efetivamente chamados, usando a relação oficial de serviços e a configuração correspondente ao ambiente.

3. Compare a raiz da área de dados com a prevista no contrato. Verifique também namespace, grafia e distinção entre mensagem de entrada, resposta e arquivo de guarda.

4. Valide uma cópia de trabalho contra o conjunto oficial de schemas aplicável, incluindo seus arquivos dependentes. Aponte ao fornecedor o primeiro erro reproduzível.

5. Corrija a geração ou o encaminhamento no sistema de origem. Depois, gere novamente a solicitação e acompanhe o retorno completo.

Se houve interrupção ou resposta inconclusiva em outra tentativa, consulte a situação antes de repetir uma ação com efeitos fiscais. Um erro na consulta não prova que a nota original esteja sem autorização. Da mesma forma, lote de eventos processado não significa que cada evento tenha sido aceito.

Por que uma solução encontrada na internet pode divergir

Manuais antigos, como o MOC 5 e partes do MOC 6, também usaram 516 ao descrever falha de raiz em lote. O MOC 7 separa o diagnóstico específico 565. Um log antigo deve ser interpretado com o serviço e a versão de sua época, sem impor automaticamente sua nomenclatura à integração atual.

A aplicação tampouco é universal: a tabela paulista consultada marca D01a/516 como inativa; a publicação mineira consultada registra aplicação. Isso ajuda a entender por que erros estruturais parecidos podem retornar códigos diferentes. Não é motivo para desativar validações locais, trocar UF ou mudar o ambiente para obter aceitação.

Os guias de Berga, Oobj e TecnoSpeed reforçam, respectivamente, a conferência do serviço e a investigação de falhas de schema. Os dois últimos foram usados como contexto técnico da rejeição genérica 215, não como comprovação de todas as ocorrências de 516.

A solução segura preserva os XMLs autorizados, corrige o gerador e mantém assinatura, certificado e segurança da comunicação. Não edite documentos autorizados, remova controles ou publique arquivos fiscais completos em ferramentas desconhecidas para experimentar combinações.

Fontes consultadas

Base oficial preservada, lida em 10/10/2026: MOC 7.0, Anexo I, página 72, e MOC Visão Geral, capítulos 5.1 a 5.14; NT 2014.001 v1.41; NT 2014.003 v1.02; NT 2015.001 v1.30; NT 2018.004 v1.00; NT 2020.001 v1.60; NT 2020.007 v1.40; NT 2021.001 v1.01; NT 2022.001 v1.00; NT 2023.005 v1.02; NT 2024.002 v1.00; BT 2018.002 v1.00. Publicações de São Paulo e Minas Gerais, esta na versão 2.00 de 13/03/2026. Disponibilidade operacional individual não testada.

Leituras práticas: Berga: rejeição 516, Oobj: investigação de schema e TecnoSpeed: falha de schema.