+33 4725 3833 Contacto

¿XML o JSON para controles volumétricos? El formato sí importa

abril 14, 2026 · Angel Castellanos
Terminal de almacenamiento de combustibles con pantalla de monitoreo de datos volumétricos al atardecer — tecnología de controles volumétricos en el sector energético mexicano.

Cuando una empresa del sector energético configura su sistema informático de controles volumétricos hay una decisión que suele pasar desapercibida, pero que tiene consecuencias reales en el día a día: ¿en qué formato generar los reportes que se envían al Servicio de Administración Tributaria (SAT)? La normativa vigente —el Anexo 21 de la Resolución Miscelánea Fiscal (RMF) 2026— da al contribuyente la libertad de elegir entre XML y JSON: ambos son válidos, ambos cumplen, pero no son iguales y en esta ocasión te vamos a compartir nuestro análisis.

Te comentamos que en este artículo analizaremos las diferencias técnicas entre los dos formatos en el contexto específico de los controles volumétricos; explicamos por qué esa decisión no es trivial y muestraremos las ventajas operativas que el formato JSON ofrece a las empresas que buscan no solo cumplir con el SAT, sino operar con eficiencia.

Lo que dice la norma: XML y JSON en igualdad regulatoria

Empecemos por lo que no está a discusión: el SAT publica en su portal de controles volumétricos dos conjuntos de especificaciones técnicas: uno para la generación de archivos XML y otro para la generación de archivos JSON. Las guías de llenado —tanto del reporte diario como del mensual— describen la estructura, forma y sintaxis que deben contener los reportes en cualquiera de los dos formatos; los esquemas de validación también están disponibles para ambos: archivos XSD para XML y esquemas JSON para JSON.

Esto significa que, ante la autoridad, no hay preferencia por un formato sobre otro. Un reporte mensual de controles volumétricos en JSON tiene exactamente la misma validez fiscal que uno en XML, siempre que cumpla con las especificaciones publicadas y contenga la información completa. La regla 2.8.1.6 de la RMF establece los plazos de envío, y las guías técnicas detallan los campos, complementos y validaciones, todo aplicable a ambos formatos.

La decisión, entonces, no es regulatoria, es técnica y operativa… y allí es donde las diferencias importan.

Qué es cada formato y de dónde viene

XML (Extensible Markup Language) es un lenguaje de marcado que se diseñó a finales de los años noventa para transportar y almacenar datos con estructuras jerárquicas complejas. ¿Cómo funciona? Con etiquetas de apertura y cierre que envuelven cada dato, a su vez requiere del uso de namespaces, que son identificadores que evitan conflictos cuando se combinan vocabularios de distintas fuentes. En el contexto del SAT, los reportes XML de controles volumétricos usan el namespace “Covol:” para los elementos principales y prefijos adicionales como “ns:” para los complementos; por ejemplo Almacenamiento, Comercialización, Distribución, Expendio, Transporte, entre otros.

JSON (JavaScript Object Notation) es un formato de intercambio de datos ligero, creado a principios de los años 2000, que usa pares de clave-valor y una sintaxis minimalista, a diferencia del formato XML, no emplea etiquetas ni namespaces; su estructura se basa en objetos (delimitados por llaves) y arreglos (delimitados por corchetes), lo que produce archivos más compactos y de lectura más directa; incluso, las propias preguntas frecuentes del portal de controles volumétricos del SAT confirman que la especificación JSON no emplea namespaces dentro de su estructura, una diferencia que simplifica la generación y validación de los reportes.

Ambos formatos pueden representar la misma información, la diferencia está en cómo lo hacen.

Tres diferencias técnicas que impactan tu operación

1. Tamaño del archivo: menos peso, más velocidad

Un reporte de controles volumétricos contiene volúmenes de recepciones, entregas y existencias, información de CFDI asociados, datos de dictámenes de laboratorio y complementos según la actividad del contribuyente. Cuando esta información se estructura en XML cada dato se envuelve en una etiqueta de apertura y otra de cierre. El formato JSON, en cambio, usa solo el nombre de la clave seguido del valor, sin duplicar etiquetas.

El resultado es concreto: un archivo JSON que contiene exactamente la misma información que su equivalente XML es significativamente más pequeño. Dependiendo de la complejidad del reporte —número de operaciones, complementos incluidos, cantidad de CFDI referenciados— la diferencia de tamaño puede ser considerable; esto se traduce en un menor uso de almacenamiento — recuerda que los reportes deben conservarse al menos cinco años conforme a la normativa— , tiempos de transferencia más cortos al momento de enviar al SAT y menor consumo de recursos del servidor que genera y almacena los archivos.

Claro, para una estación de servicio con pocas operaciones diarias la diferencia puede parecer marginal, pero para una comercializadora con cientos de CFDI mensuales, una distribuidora con múltiples instalaciones o una empresa de transporte con decenas de autotanques el peso acumulado de los archivos XML —diarios y mensuales, mes tras mes, durante años— se convierte en un costo operativo real y, con esa reflexión, vale la pena cuestionarse qué tan redituable es usar ese formato frente a JSON.

2. Complejidad de generación: sin namespaces, menos errores

Este punto es particularmente relevante para los programas informáticos que generan los reportes: XML exige que cada elemento del reporte lleve su namespace correctamente asignado; el reporte principal usa “Covol:”, y cada complemento (Almacenamiento, Distribución, Expendio u otro) tiene su propio prefijo “ns:” con su namespace específico; si un namespace está mal escrito, falta o no corresponde al esquema XSD publicado por el SAT, el archivo es rechazado por el sistema de validación; debes de saber que es una fuente frecuente de errores técnicos que obliga a depurar y reenviar.

JSON elimina esta capa de complejidad: al no requerir namespaces, la estructura del archivo depende únicamente de que las claves y los valores correspondan al esquema JSON publicado por el SAT; esto reduce la superficie de error en la generación del reporte y simplifica las pruebas de validación. Para los equipos de desarrollo que mantienen el programa informático, lo anterior significa menos tiempo dedicado a diagnosticar fallas de formato y más tiempo enfocado en la integridad del dato.

3. Compatibilidad con sistemas modernos y APIs

La tendencia global en el desarrollo de software es clara: JSON se ha convertido en el formato estándar para el intercambio de datos entre sistemas. Las APIs REST —el mecanismo predominante de comunicación entre aplicaciones web y servicios en la nube— operan de forma nativa con JSON. Otra ventaja es que los lenguajes de programación más utilizados en la industria (Python, JavaScript, Go, Java, C#) tienen soporte nativo o bibliotecas maduras para leer, escribir y validar JSON con un mínimo de código.

¿Por qué esto importa para controles volumétricos?, porque el programa informático que genera los reportes no opera en aislamiento, se conecta a instrumentos de medición, consulta datos de CFDI, interactúa con sistemas ERP y eventualmente envía los archivos al portal del SAT; cuando toda esa cadena habla en JSON la integración es más fluida, el mantenimiento es más simple y la probabilidad de errores de conversión entre formatos se reduce.

Hay distribuidores de gas natural que ya operan con integración directa de datos mediante APIs entre sus sistemas de medición y los de sus clientes, en esos escenarios JSON es la elección natural: es el formato que las APIs producen y consumen. Generar un reporte en JSON a partir de datos que ya viajan en JSON es un proceso limpio; por el contrario, generar un reporte en XML a partir de esos mismos datos requiere una transformación adicional, con su correspondiente riesgo de introducir errores.

La falsa creencia de que XML es más seguro

Existe una percepción en ciertos círculos del sector de que XML es un formato “más robusto” o “más seguro” que JSON, esta idea tiene raíces históricas —XML fue durante años el estándar de facto en sistemas gubernamentales y bancarios— pero no refleja la realidad técnica actual.

La seguridad e integridad de un reporte de controles volumétricos no depende del formato del archivo, depende del programa informático que lo genera, de las bitácoras que registran cada evento, de la cadena de trazabilidad desde el sensor hasta el dato reportado y de los mecanismos de firma electrónica que el contribuyente aplica al momento del envío. El Anexo 21 de la RMF 2026 exige bitácoras automáticas protegidas contra modificación o eliminación y, atención, ese requisito aplica independientemente de si el reporte final es XML o JSON.

De hecho, la estructura de XML introduce un vector de vulnerabilidad que JSON no tiene: los ataques de tipo XXE (XML External Entity), que pueden explotarse cuando un parser XML no está configurado de forma segura; JSON, por su diseño más simple, no está expuesto a esta clase de ataques. Claro, no es que esto sea un riesgo frecuente en el contexto de los controles volumétricos, pero desmiente la idea de que XML es inherentemente más seguro.

Lo que vemos en el sector: XML como inercia, JSON como decisión

Si JSON tiene estas ventajas, ¿por qué muchas empresas siguen usando XML? La respuesta es simple: inercia.

Cuando los controles volumétricos se volvieron obligatorios muchos proveedores de software desarrollaron sus sistemas generando XML porque era el formato dominante en la interacción con el SAT para otros trámites fiscales (CFDI, por ejemplo, se basa en XML); esos sistemas se instalaron, se verificaron y quedaron operando.

Cambiar de formato no es un trámite regulatorio, no requiere autorización del SAT ni modificación de permisos, pero sí implica una decisión técnica: el programa informático debe estar diseñado para generar JSON conforme a los esquemas publicados y el contribuyente debe validar que los archivos cumplen con las especificaciones antes del envío. Para empresas que ya operan con un sistema que genera XML la migración tiene un costo; no obstante, para empresas que están implementando su sistema por primera vez —o que están considerando un cambio de proveedor— elegir JSON desde el inicio es la decisión técnicamente más sólida.

Cuándo JSON marca la mayor diferencia en Controles Volumétricos

No todos los contribuyentes experimentan las ventajas de JSON de la misma manera, el impacto es más notable en ciertos perfiles:

Comercializadoras y distribuidoras con alto volumen de operaciones. Cuando un reporte mensual incluye cientos de recepciones, entregas y CFDI asociados la diferencia de tamaño entre XML y JSON se amplifica. Archivos más ligeros significan generación más rápida, envíos más ágiles y menor carga de almacenamiento a lo largo de los cinco años de conservación obligatoria.

Empresas con múltiples instalaciones o permisos. Si el contribuyente opera varias instalaciones —cada una con su reporte— el volumen acumulado de archivos crece rápidamente, JSON mantiene esa carga bajo control.

Operaciones que integran datos vía API. Cuando el sistema informático de controles volumétricos se conecta con ERP, sistemas de facturación o plataformas de monitoreo remoto, JSON es el formato nativo de comunicación; operar toda la cadena en un mismo formato elimina conversiones intermedias y reduce puntos de falla.

Empresas en proceso de implementación. Si estás eligiendo proveedor de sistema informático por primera vez, optar por una solución que opere en JSON te posiciona con tecnología actual desde el día uno, sin la carga técnica heredada de formatos más antiguos.

Diagrama de Volumetrics by AIVARA que explica las diferencias de usar un formato XML frente a JSON para los reportes de Controles Volumétricos.

¿Cómo Volumetrics by AIVARA te ayuda con los reportes de controles volumétricos?

En Volumetrics by AIVARA tomamos la decisión técnica desde el diseño: nuestro sistema genera los reportes históricos de controles volumétricos en formato JSON; no es un accidente, es una elección fundamentada en eficiencia, compatibilidad y reducción de errores. Nuestro programa informático se conecta directamente a la instrumentación de campo, procesa los datos conforme a las especificaciones del Anexo 21 de la RMF 2026 y produce archivos JSON validados contra los esquemas oficiales del SAT, listos para envío. Te ayudamos con archivos más ligeros, generación más limpia y una cadena de datos sin conversiones innecesarias.

¿Estás evaluando un sistema de controles volumétricos y quieres conocer cómo funciona la generación de reportes en JSON? Contáctanos para una demostración en www.volumetrics.com.mx o escríbenos por WhatsApp al +52 1 56 6410 1241.

Fuentes consultadas