NF-e e NFC-e
Rejeição 243: como identificar e corrigir um XML malformado
A rejeição 243 informa que a SEFAZ não conseguiu interpretar a estrutura do XML recebido. Para resolver, o suporte deve analisar a mensagem efetivamente transmitida, localizar a primeira falha de leitura e corrigir o gerador ou a etapa que danificou o arquivo.
A rejeição 243 informa que a SEFAZ não conseguiu interpretar a estrutura do XML recebido. Para resolver, o suporte deve analisar a mensagem efetivamente transmitida, localizar a primeira falha de leitura e corrigir o gerador ou a etapa que danificou o arquivo.
Mensagem: “Rejeição: XML Mal Formado”.
Essa ocorrência costuma exigir uma correção técnica. Reenviar o mesmo arquivo, trocar a numeração ou modificar impostos não resolve uma tag sem fechamento, um trecho cortado ou um caractere reservado gravado de forma incorreta.
XML malformado e falha de schema são etapas diferentes
Um XML bem formado obedece às regras básicas da linguagem: elementos corretamente abertos e fechados, encaixe coerente das tags e tratamento adequado dos caracteres reservados. O schema, ou XSD, verifica depois se esse documento segue o leiaute fiscal do serviço.
Assim, um arquivo pode ser legível como XML e ainda falhar no schema porque um campo está fora de ordem ou tem um formato não permitido. No MOC, a B02 trata o XML malformado e retorna 243; a D01 trata a validação de schema, com 225 na autorização e 215 nas demais situações descritas. A B02 é facultativa, o que não significa que seja permitido transmitir XML quebrado. MOC 7.0, Anexo I, seções 4.1.2 e 4.1.3.
A especificação XML do W3C fundamenta essa distinção. Espaços entre elementos, por exemplo, não tornam qualquer XML malformado por si só. O padrão fiscal pode impor restrições adicionais, que precisam ser investigadas na regra correspondente.
Identifique qual mensagem foi recusada
Autorização de NF-e ou NFC-e: examine a mensagem enviada ao serviço e as notas que ela contém, modelos 55 e 65 conforme a operação. Uma prévia correta na tela não comprova que os mesmos bytes chegaram à camada de transmissão.
Consulta ou outra operação dos Web Services: examine o XML da própria consulta ou solicitação. A regra B02 faz parte das validações gerais do MOC. Uma consulta malformada não torna inválida uma nota anteriormente autorizada.
EPEC da NF-e: a NT 2014.001 v1.41 também relaciona a 243 na validação inicial da mensagem de evento. A disponibilidade do EPEC depende das condições próprias do serviço; essa previsão não permite adotá-lo indiscriminadamente como contingência. NT 2014.001 v1.41, seção 3.6.
Não aplique exemplos de BP-e, CT-e ou MDF-e apenas porque mostram o mesmo número de rejeição. Confirme documento, operação, UF, ambiente e mensagem literal do retorno.
Como localizar o problema
Preserve a resposta integral, com cStat, xMotivo, horário e eventual detalhe de linha, coluna ou elemento.
Peça ao suporte o XML de saída da tentativa rejeitada. Guarde o original antes de abrir e salvar em um editor, pois o editor pode mudar a codificação ou outros detalhes.
Faça uma leitura local com um analisador de XML. Ele deve conseguir carregar o arquivo inteiro sem erro de sintaxe.
Investigue primeiro o ponto inicial apontado pelo analisador. Erros posteriores podem ser consequência de uma única tag quebrada mais acima.
Corrija a geração na origem e gere novamente a mensagem. Depois, valide também o schema e a assinatura, quando exigida, antes de transmitir.
A Omie orienta encaminhar a 243 ao suporte para análise técnica. A Sankhya destaca a conferência de tags e do tratamento de caracteres reservados. Faça isso no arquivo e na integração, preservando o conteúdo verdadeiro da operação.
O que fazer em cada cenário
Há uma tag aberta e não fechada: o fornecedor deve corrigir a rotina que monta os elementos. Se o arquivo terminou abruptamente, verifique também se foi gravado ou transmitido antes de estar completo. Acrescentar um fechamento manual ao final pode esconder perda de dados.
O erro aparece em uma descrição com “&” ou “<”: o sistema precisa representar o caractere de maneira compatível com XML no contexto em que ele foi usado. O suporte deve usar a serialização correta, sem apagar o nome, a descrição ou a observação fiscal para contornar o problema. W3C, seção 2.4.
O lote foi montado juntando arquivos prontos: confira se a integração incluiu declarações XML repetidas no meio da mensagem. O MOC exige uma única declaração no início do documento, inclusive quando o lote contém notas. Corrija a montagem do lote; não faça substituições indiscriminadas dentro do conteúdo assinado. MOC, Visão Geral, seção 4.2.1.1.
O arquivo abre localmente, mas a SEFAZ retorna 243: compare o original validado com a mensagem de saída depois da assinatura e da preparação para transporte. Uma conversão pode cortar o texto ou escapar duas vezes um trecho. Se a leitura passou, valide também o XSD: passar por uma etapa não comprova aprovação nas demais.
A análise aponta codificação: confira a declaração e os bytes reais. A 402 trata especificamente a codificação diferente de UTF-8. Trocar apenas a palavra na declaração não converte um arquivo que foi gravado em outra codificação.
Exemplo hipotético
Uma distribuidora cadastrou corretamente o nome fictício “Oficina Cedro & Filhos”. Uma integração montou a tag do nome por concatenação de texto e gravou o “&” sem o tratamento exigido pelo XML. O analisador local apontou o erro naquele ponto.
O fornecedor corrigiu a serialização para representar o mesmo nome com a entidade XML apropriada. O sistema regenerou a nota, fez as validações e produziu nova assinatura. A empresa manteve o nome verdadeiro do cadastro; a correção ocorreu na representação técnica.
Como confirmar a solução
Confirme três etapas: o arquivo completo pode ser lido como XML, passa no schema aplicável e recebe o resultado esperado da operação na SEFAZ. Na autorização, confira o protocolo da nota; em um evento, confira seu resultado individual.
Se houve uma tentativa anterior sem resposta conclusiva, consulte a situação antes de reenviar. Se a 243 ocorreu apenas em uma consulta, verifique a resposta da consulta corrigida, sem reemitir a nota.
A Maxiprod mostra a importância de obter o XML para localizar a falha. Prefira análise local ou suporte autorizado: arquivos fiscais completos não devem ser enviados a validadores públicos desconhecidos.
Revisão: 09/10/2026. Base nacional cotejada com as Notas Técnicas disponíveis; não foi testada a aplicação da B02 em cada UF ou ambiente.