Rejeição 215: como identificar e corrigir a falha no schema XML

A rejeição 215 informa que o XML enviado à SEFAZ não passou pela validação da estrutura exigida para aquela mensagem. Para resolver, identifique qual envio falhou, localize o campo apontado pelo validador e corrija sua origem no sistema. Repetir a transmissão sem mudar a causa tende a produzir a mesma resposta.

Mensagem: “Rejeição: Falha no schema XML”.

O código é genérico. Sozinho, ele não informa qual campo está errado nem permite concluir que o problema está no cadastro do cliente, nos impostos ou no certificado.

A rejeição é da nota ou de outro serviço?

O schema, também chamado de XSD, define como o XML deve ser organizado: campos, ordem, formatos, tamanhos e combinações permitidas. A conferência precisa considerar o serviço que recebeu o arquivo.

O MOC contempla NF-e, modelo 55, e NFC-e, modelo 65. Na regra D01, distingue a falha da área de dados, código 215, da falha de schema do lote no serviço de autorização, código 225. A validação alcança toda a mensagem: uma inconsistência dentro de uma nota também pode rejeitar o lote. Por isso, confira o código e a mensagem completos, mesmo que o programa mostre apenas “erro de XML”. MOC 7.0, Anexo I, seção 4.1.3.

A 215 também aparece em especificações de Distribuição DF-e, pedido de prorrogação de industrialização, EPEC da NFC-e e gerenciamento de CSC. Nessas situações, o arquivo rejeitado pode ser uma consulta, um pedido ou um evento. A presença do código no manual não significa que todos esses serviços estejam disponíveis em qualquer UF.

Se o erro surgiu ao cancelar uma nota ou enviar uma carta de correção, investigue o envio do evento. A validação do schema específico do evento tem ainda o código 493; não atribua qualquer falha de um campo de evento à 215. Uma nota já autorizada não perde sua autorização porque um evento posterior foi rejeitado. Orientação sobre eventos.

O que pode provocar a falha

Entre as possibilidades estão campos obrigatórios ausentes, valores com tamanho ou formato incompatível e uma versão de XML diferente da esperada pelo serviço. Nomes de elementos incorretos também entram na investigação. Referência prática de diagnóstico.

Há ainda problemas na geração do arquivo, como elementos fora de ordem ou grupos montados no lugar errado. O dado pode parecer correto na tela e chegar diferente no XML transmitido.

Textos copiados de planilhas e documentos merecem atenção, mas evite apagar acentos ou símbolos indiscriminadamente. A restrição depende do campo e da representação correta do conteúdo no XML. Quem deve corrigir essa representação é o emissor; alterar a razão social ou a descrição verdadeira do produto para contornar o erro pode criar outro problema.

Como encontrar a causa sem mexer no que está certo

1. Registre a operação que estava fazendo: emitir, consultar, cancelar, corrigir ou baixar documentos. Anote também UF, ambiente de produção ou homologação, horário e retorno completo.

2. Separe o XML efetivamente enviado e a resposta recebida. Uma prévia do DANFE ou um arquivo exportado antes da transmissão pode não representar a mensagem rejeitada.

3. Peça a validação desse XML contra o schema correspondente ao serviço e à versão aplicável. A recomendação de validar antes de corrigir aparece também na orientação da Oobj sobre a 215.

4. Localize o elemento citado no resultado. O suporte deve traduzir o nome técnico para o cadastro, campo ou configuração responsável.

5. Corrija a origem e gere novamente o arquivo pelo emissor. Se houver assinatura digital, ela precisa corresponder ao conteúdo corrigido. Não edite manualmente o arquivo já assinado para transmiti-lo.

Prefira validação local ou um canal oficial e autorizado. XMLs fiscais podem conter dados de clientes e detalhes comerciais; não os envie a sites desconhecidos.

O que fazer em cada cenário

Um cadastro específico provoca o erro: confirme o dado verdadeiro, ajuste o campo indicado e confira se a correção foi incorporada à nota ou ao pedido já preparado.

Várias notas passaram a falhar depois de uma atualização: solicite ao fornecedor a conferência do gerador de XML, do pacote de schemas e do serviço utilizado. Uma correção isolada em cada produto dificilmente resolve uma incompatibilidade comum.

O XML passa no validador, mas o envio continua rejeitado: o suporte deve comparar o arquivo validado com a mensagem realmente transmitida e conferir o serviço de destino. Validar somente um trecho pode deixar de fora o problema.

O erro está em consulta, evento ou gerenciamento do CSC: corrija a mensagem daquele serviço. Não refaça a venda nem revogue o CSC apenas por causa do código 215.

Exemplo hipotético

Uma papelaria pede ao emissor a consulta da situação de uma NF-e e recebe 215. O suporte valida a mensagem enviada e identifica que o gerador omitiu tpAmb, campo obrigatório que informa o ambiente da consulta. A correção é feita no gerador, mantendo o ambiente verdadeiro da operação. O sistema gera e envia uma nova consulta, e a responsável confere a situação devolvida. Nenhuma venda é refeita por causa dessa falha de consulta. MOC, leiaute de consulta da situação, página 82.

Como confirmar a solução

Após corrigir, confira o retorno definitivo da operação. Na emissão, procure a autorização e o protocolo correspondentes à nota. Em um cancelamento, confirme a aceitação do evento e a situação atual do documento. O desaparecimento do aviso na tela não basta.

Se houve timeout, interrupção ou retorno inconclusivo, consulte a situação antes de retransmitir ou criar outra nota. Não altere número ou série apenas para escapar da rejeição.

Acione o suporte quando houver erro de estrutura, assinatura, versão ou transmissão. Envolva o contador se a correção exigir decidir o conteúdo fiscal, a possibilidade de cancelamento ou os próximos passos diante de um prazo.

Atenção à versão e à data

Atualização publicada não significa implantação imediata. Em 05/10/2026, um comunicado da Coordenação Técnica do ENCAT adiou as implantações anunciadas das NTs 2025.002 v1.52, 2026.007 v1.10 e 2026.008 v1.00 para 26/10/2026 em homologação e 16/11/2026 em produção. O fornecedor deve conferir o cronograma aplicável antes de trocar schemas. Comunicado oficial.

A NT 2026.006 também documenta 215 para repetição de nPag ou idTransacao no grupo de vinculação de pagamento. O documento informa que esses campos são preparatórios, sem exigência de preenchimento em produção em 2026. As cópias oficiais da mesma versão consultadas apresentavam cronogramas diferentes; esse ramo exige confirmação do pacote e da implantação no ambiente utilizado, sem presumir que já esteja ativo. NT 2026.006, páginas 3 e 7.

Revisão documental: 09/10/2026. Condições de aplicação conforme o serviço e as ressalvas indicadas.

Referências complementares

• Portal Nacional, pacotes oficiais de schemas: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?AspxAutoDetectCookieSupport=1&tipoConteudo=BMPFMBoln3w%3D

• NT 2015.001 v1.30, pedido de prorrogação: https://www.nfe.fazenda.gov.br/Portal/exibirArquivo.aspx?conteudo=CGAKR5siRHM%3D

• NT 2014.002 v1.40, Distribuição DF-e: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=uWO2d%2FgTuWg%3D

• NT NFC-e 2014.003 v1.02, EPEC NFC-e: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D

• NT NFC-e 2014.001, gerenciamento do CSC: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=wI3fsjkCDWg%3D