Rejeição 214: XML de dados acima do limite de tamanho
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 214, regra B01, indica que o XML de dados excedeu o limite de 500 KB previsto no MOC. A conferência deve ser feita sobre a mensagem efetivamente preparada para o serviço, após sua serialização, e não apenas sobre o tamanho de uma nota exibida na tela.
Nesta página:
- Qual tamanho o emissor precisa controlar?
- Por que a conexão pode cair sem retornar 214?
- Exemplo: nota pequena, lote acima do permitido
- O que pode ser corrigido sem perder informações?
Qual tamanho o emissor precisa controlar?
B01 fala no XML de dados. A aplicação deve medir o conteúdo efetivamente enviado, considerando o lote e os documentos que o compõem. Contar caracteres de um campo ou medir um arquivo intermediário não demonstra o tamanho final da mensagem. A codificação UTF-8 também faz parte da serialização; caracteres e bytes não são medidas equivalentes.
O MOC determina que a aplicação não permita gerar mensagens acima de 500 KB. A documentação não deve ser ampliada por suposição para um novo limite com base no aumento de campos do leiaute. A evolução dos schemas exige conferir o pacote vigente, mas não representa, por si, alteração dessa regra de tamanho.
Fontes: MOC Anexo I, regra B01.
Por que a conexão pode cair sem retornar 214?
O MOC distingue controle no aplicativo da SEFAZ, que devolve 214, de controle na infraestrutura de rede, que pode interromper a conexão sem mensagem de erro. Portanto, uma queda não comprova B01; é necessário medir a mensagem e correlacionar horário e erro técnico.
Guarde o retorno bruto quando existir. Se o resultado de uma tentativa anterior é desconhecido, esclareça-o antes de repetir o envio. Um erro HTTP genérico não substitui o código fiscal nem a consulta da situação do documento.
Fontes: MOC Anexo I, regra B01.
Exemplo: nota pequena, lote acima do permitido
Em um cenário sintético, cada arquivo individual parece pequeno, mas a mensagem reúne vários documentos e o total serializado supera o limite. Medir somente uma NF-e não identifica a causa. Confira o XML final do lote e os limites de quantidade e modalidade de processamento aplicáveis.
Quando o serviço admitir lotes, o integrador pode reorganizar sua composição respeitando essas regras, sem dividir uma nota arbitrariamente ou eliminar dados obrigatórios. Para NF-e em lote unitário, a NT 2025.001 também exige observar a resposta síncrona; fragmentar lotes não dispensa essa condição.
Fontes: MOC Anexo I, regra B01; NT 2025.001 — Simplificação operacional.
O que pode ser corrigido sem perder informações?
O MOC orienta evitar comentários, documentação e caracteres de formatação desnecessários. A correção deve ocorrer no gerador, antes da assinatura, preservando campos exigidos, valores manuais legítimos e zeros explícitos pertinentes. Não apague produtos, tributos ou informações reais apenas para reduzir o arquivo.
Revalide o XML final no XSD, suas assinaturas e o tamanho medido. A passagem por esses controles técnicos não comprova autorização: o desfecho depende do retorno fiscal do serviço solicitado.
Fontes: MOC Anexo I, regra B01.
Limite do exemplo e preservação dos dados
A medição depende dos bytes do lote original protegido; um XML inventado teria outro tamanho e não provaria B01. O exemplo compara a composição da mensagem sem dados fiscais operacionais. 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 B01, código 214; p. 72, notas de tamanho e indisponibilidade.
- MOC 7.0 — Visão Geral, versão 7.00. pp. 50–51, montagem e otimização do XML; pp. 57–59, modelo operacional; p. 71, enviNFe.
- NT 2025.001 — Simplificação operacional, versão 1.03 corrigida. pp. 3 e 6, resposta síncrona unitária; p. 8, GAP03a-3 e condição do lote unitário.
- NT 2025.002-RTC — Adequações NF-e/NFC-e, versão 1.52. pp. 8–9, evolução do leiaute e DFeTiposBasicos; pp. 73–74, lista e registro de eventos, parte geral e schemas específicos.