NF-e e NFC-e
Rejeição 225: como localizar a falha no schema XML do lote
A rejeição 225 informa que a mensagem enviada não passou pela validação de estrutura do XML. Para resolver, valide o arquivo realmente transmitido com o schema correspondente ao serviço e à versão em uso, localize o elemento recusado e corrija sua origem no emissor.
A rejeição 225 informa que a mensagem enviada não passou pela validação de estrutura do XML. Para resolver, valide o arquivo realmente transmitido com o schema correspondente ao serviço e à versão em uso, localize o elemento recusado e corrija sua origem no emissor.
Mensagem: “Rejeição: Falha no Schema XML do lote de NFe”.
Embora a mensagem mencione o lote, a causa pode estar dentro de uma das notas. Alterar apenas o identificador do lote ou reenviar os mesmos arquivos não corrige um campo ausente, um formato inválido ou um grupo montado incorretamente.
O erro pode estar no lote ou em uma nota dele
O schema, ou XSD, define campos, formatos, ordem dos elementos e combinações aceitas no XML. Na autorização, a regra D01 do MOC associa a 225 à validação da área de dados. O manual esclarece que essa conferência percorre a mensagem inteira: uma falha de schema em uma NF-e pode rejeitar todo o lote. MOC 7.0, Anexo I, seção 4.1.3.
Por isso, não conclua que todas as notas têm dados errados nem restrinja a análise ao elemento externo enviNFe. É preciso localizar o ponto indicado pelo validador.
Na mesma tabela, a 215 é a falha genérica de schema da área de dados. A distinção não significa que a 215 sempre examine uma nota isolada e a 225 examine somente seu envelope. O serviço que recebeu a mensagem faz parte do diagnóstico.
Confira qual operação foi rejeitada
Na emissão de NF-e, modelo 55, ou NFC-e, modelo 65, investigue a mensagem de autorização e o documento que ela contém. Até um envio com uma única nota usa uma estrutura de lote. Para NFC-e, essa estrutura só admite uma nota por envio; não agrupe várias NFC-e. NT 2023.002 v1.01, seção 3.1.
A 225 também aparece nas especificações da manifestação do destinatário e do EPEC da NF-e. Se você estava registrando um desses eventos, examine o envio do evento. Não regenere a venda nem altere uma nota já autorizada para tentar corrigir aquela mensagem. NT 2020.001 v1.60, seção 6.3.6, NT 2014.001 v1.41, seção 3.7.
Esses serviços têm requisitos próprios de modelo e disponibilidade. A presença de uma mensagem no manual não permite usar qualquer evento em qualquer UF.
Como descobrir o campo responsável
Guarde a resposta completa, incluindo cStat, xMotivo e eventual indicação de elemento, linha ou caminho no XML. O aviso resumido da tela pode esconder esse detalhe.
Registre a operação, a UF, o ambiente, o horário e a versão do emissor. Identifique quais notas ou eventos compunham o envio.
Separe o XML efetivamente transmitido. Validar uma prévia, um arquivo corrigido depois ou somente o XML individual pode deixar o defeito de fora.
Valide a mensagem contra o conjunto oficial de schemas adequado ao serviço, à versão e ao cronograma de implantação. Prefira validação local ou um canal oficial autorizado, preservando os dados fiscais.
Peça ao suporte que traduza o elemento apontado para o cadastro, campo ou regra de geração responsável. Corrija a origem e gere novamente a mensagem.
A Treeunfe orienta validar a estrutura antes de gerar e transmitir o XML corrigido. A TotalERP mostra um diagnóstico em que a validação identifica o campo de CEP incompleto. O campo concreto precisa vir do seu arquivo, não de uma lista genérica de causas.
O que fazer em cada cenário
O validador aponta um dado cadastral: confira a informação verdadeira e corrija o cadastro ou documento de origem. Depois, confirme se a nota já preparada recebeu a atualização. Não acrescente dígitos fictícios ou substitua uma identificação real apenas para cumprir o tamanho do campo.
O valor está certo na tela, mas errado no XML: peça a correção do gerador ou da integração. Separador decimal, elemento vazio e ordem dos grupos podem ser problemas da conversão realizada pelo software. Não é necessário mudar o valor comercial para corrigir sua representação.
A falha começou após atualização: confira a compatibilidade entre emissor, schemas e ambiente autorizador. Um campo previsto em uma versão publicada pode ainda não estar implantado no ambiente utilizado. Não remova grupos fiscais indiscriminadamente nem selecione uma versão antiga por tentativa e erro.
Uma nota provoca a rejeição do lote inteiro: localize e corrija o documento apontado. O suporte pode reorganizar os envios quando apropriado, mas separar o lote não corrige o XML defeituoso. Acompanhe individualmente as notas para evitar duplicidade.
A validação local passa e a SEFAZ continua rejeitando: compare o arquivo validado com o conteúdo enviado, o serviço de destino e o pacote de schemas. Uma integração pode modificar a mensagem depois da validação. Encaminhe os dois arquivos e os retornos ao fornecedor.
Exemplo hipotético
Uma loja tem uma venda de R$ 1.250,00 corretamente registrada. Uma atualização passa a gravar o campo vNF do XML como “1.250,00”, reproduzindo a apresentação da tela. O validador aponta formato incompatível com o campo numérico.
O fornecedor corrige a serialização para representar aquele mesmo valor como “1250.00” no XML. O sistema gera novamente o documento, aplica a assinatura e transmite. A loja confirma o protocolo da nota. O total da venda não foi reduzido ou recalculado para passar pela validação; sua representação técnica foi corrigida.
Como confirmar a solução
Na autorização, confira o retorno definitivo e o protocolo de cada nota. Em um serviço de eventos, confira o resultado do evento pretendido. Uma mensagem de “lote recebido” ou o desaparecimento do aviso local não substitui essa verificação.
Se uma tentativa anterior terminou sem resposta conclusiva, consulte a situação antes de retransmitir ou criar outra nota. Não mude número ou série apenas para contornar a 225.
Atenção às versões disponíveis em 2026
Em 05/10/2026, o ENCAT adiou a implantação 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. Esse comunicado demonstra por que a data de publicação de um schema não deve ser confundida com sua entrada em uso. A alteração se refere às versões citadas, não a todas as regras da NF-e. Aviso oficial da SVRS.
Revisão: 09/10/2026.
Referência prática complementar
vhsys, leitura do detalhe do retorno e identificação do campo: https://ajuda.vhsys.com.br/categorias/erros-e-rejeicoes-nfes/rejeicao-225-falha-no-schema-xml-do-lote-de-nfe
Restrições de caracteres dependem do campo e do schema aplicável. Não apague acentos, símbolos ou informações verdadeiras com base apenas em uma recomendação genérica de limpeza do XML.