Rejeição 243: XML malformado antes da validação fiscal
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 243, regra B02, indica que o XML de dados não pôde ser interpretado corretamente como XML. Isso antecede a conferência de leiaute e das regras fiscais. Um documento pode estar malformado mesmo quando seus valores de negócio parecem corretos na tela.
Nesta página:
- Como localizar a primeira falha de interpretação?
- Exemplo: texto com e-comercial sem escape
- Por que um arquivo salvo localmente pode passar?
- Como distinguir 243, 225 e 402?
Como localizar a primeira falha de interpretação?
Valide os bytes efetivamente enviados em um analisador XML, em ambiente protegido, e registre a primeira linha e coluna apontadas. Confira abertura e fechamento de elementos, aspas de atributos, caracteres proibidos e declaração XML. A primeira falha pode impedir a leitura do restante do arquivo; uma longa lista de erros derivados não significa várias causas independentes.
B02 é facultativa no quadro do MOC. Isso significa que o autorizador pode tratar a falha por outro mecanismo, não que XML malformado seja permitido. A ausência de 243 não comprova sintaxe correta.
Fontes: MOC Anexo I, regra B02.
Exemplo: texto com e-comercial sem escape
Suponha que uma informação adicional contenha um e-comercial legítimo. Se o gerador concatena esse texto diretamente à marcação, o caractere pode ser interpretado como início de entidade. A origem do problema é a serialização, não a descrição comercial em si.
Uma biblioteca XML deve preservar o texto e produzir seu escape, como a representação textual &. Na leitura, o valor continua sendo o e-comercial original. Fazer escape novamente sobre texto já escapado pode produzir outro conteúdo; compare o valor de origem e o valor lido pelo parser, sem remover caracteres legítimos.
Fontes: MOC Anexo I, regra B02.
Por que um arquivo salvo localmente pode passar?
O conteúdo transmitido pode ter sido convertido, concatenado, truncado ou encapsulado depois do arquivo validado. Compare a saída do gerador com o conteúdo da área de dados entregue ao cliente SOAP. O MOC exige uma única declaração XML no documento; concatenar documentos completos com declarações internas pode torná-lo inválido.
Não use editores para remendar um XML já assinado. Corrija a etapa responsável, regenere o documento e confira novamente sintaxe, XSD e assinatura sobre a versão final.
Fontes: MOC Anexo I, regra B02.
Como distinguir 243, 225 e 402?
A 243 trata de XML malformado; a 225, do schema do lote de autorização; a 402, de codificação diferente de UTF-8. Um XML bem formado ainda pode violar o XSD ou falhar na assinatura. Após o reparo, valide essas camadas separadamente e preserve o retorno original. Em caso de envio com resultado incerto, consulte a situação antes de repetir qualquer ação fiscal.
Fontes: MOC Anexo I, regra B02.
Limite do exemplo e preservação dos dados
A falha de sintaxe pode depender do ponto exato em um documento protegido. O exemplo textual explica escape sem fabricar nota completa ou apresentar um XML inválido como modelo transmissível. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.
Fontes oficiais
- MOC 7.0 — Anexo I, versão 7.00. p. 71, regra B02, código 243; p. 72, notas de tamanho e indisponibilidade.
- MOC 7.0 — Visão Geral, versão 7.00. pp. 49–51, declaração, caracteres especiais, montagem e validação XSD.