Estructura del JSON para DTE en El Salvador: Guía Completa y Ejemplos Reales

Si estás integrando la facturación electrónica en El Salvador, te habrás dado cuenta de que el Ministerio de Hacienda (MH) exige una estructura de datos estricta bajo el formato JSON. Configurar correctamente estos archivos es el paso más crítico para evitar rechazos en el flujo de transmisión en lote o en tiempo real.

En este artículo vamos a desglosar los bloques principales de un JSON para DTE, qué datos van en cada sección y cómo cambia la estructura cuando emites un documento específico, como una Nota de Crédito.

Anatomía general de un JSON para DTE

Aunque existen diferentes tipos de Documentos Tributarios Electrónicos (como el Comprobante de Crédito Fiscal - CCF, Factura Electrónica - FE, o Nota de Crédito - NC), la gran mayoría comparte una estructura base de 12 secciones clave.

A nivel de código, un JSON maestro se ve de la siguiente manera:

{
  "identificacion": {},
  "emisor": {},
  "receptor": {},
  "documentoRelacionado": [],
  "ventaTercero": null,
  "cuerpoDocumento": [],
  "resumen": {},
  "extension": null,
  "apendice": [],
  "selloRecibido": null,
  "firmaElectronica": null
}

Los 12 Bloques del JSON: ¿Qué va en cada uno?

Para que no te pierdas entre tantas llaves, hemos dividido estos campos en tres categorías según su comportamiento:

1. Datos obligatorios comunes (En todos los DTE)

• identificacion: Contiene la información del control del documento (versión del JSON, tipo de DTE, número de control asignado por tu sistema, código de generación UUID y fecha/hora de emisión).
• emisor: Tus datos como contribuyente (NIT, NRC, nombre comercial, actividad económica, dirección y datos de contacto).
• receptor: Datos del cliente. Es obligatorio en CCF y Notas de Crédito (requiere NIT/NRC), pero en Facturas de consumo final puede ser simplificado a cliente general o clientes varios si la venta es menor a la cuantía que exige la ley para identificar al comprador.
• cuerpoDocumento: Es un array (lista) donde se detalla cada ítem vendido o servicio prestado (cantidad, descripción, precio unitario, descuentos y códigos de impuestos aplicables).
• resumen: El cierre numérico del DTE. Aquí consolidás el total de operaciones gravadas, exentas, no sujetas, el cálculo del IVA, retenciones y el monto total a pagar escrito en letras y números.

2. Datos condicionales o específicos

• documentoRelacionado: Crucial para Notas de Crédito y Débito. Aquí se mapea el DTE original (Factura o CCF) que se va a modificar o anular.
• ventaTercero y otrosDocumentos: Se utilizan solo en escenarios específicos, como cuando vendes por cuenta de un tercero o necesitas asociar un documento de transporte (remisión).
• apendice: Un bloque flexible para guardar datos personalizados que tu sistema o tu cliente necesiten (por ejemplo: número de orden de compra, código de sucursal interna, o datos de despacho). Hacienda no lo valida, pero lo respeta.

3. Campos de cierre (Procesados por Hacienda y tu firma)

• extension: Datos de entrega o información específica para la representación gráfica (representante de entrega).
• firmaElectronica: El resultado de firmar el JSON con tu certificado digital privado antes de enviarlo a Hacienda.
• selloRecibido: El string de autorización que te devuelve la API del Ministerio de Hacienda cuando el DTE es aprobado con éxito.

El caso de las Notas de Crédito: ¿Cómo asociar un DTE previo?

Una Nota de Crédito no puede existir flotando en el vacío; por ley, debe corregir o modificar un documento emitido previamente.

Es aquí donde el bloque documentoRelacionado toma el protagonismo. A diferencia de una factura común donde este campo va vacío o en null, en la Nota de Crédito debes estructurarlo así:

Ejemplo real de documentoRelacionado para Nota de Crédito:

"documentoRelacionado": [
  {
    "tipoDocumento": "03", 
    "tipoGeneracion": 2,
    "numeroDocumento": "DTE-03-M001-000000000000123",
    "fechaEmision": "2026-06-08"
  }
]

Tabla de campos clave para la vinculación:

Conclusión

Dominar la estructura del JSON de Hacienda en El Salvador es el reto técnico más grande de la Facturación Electrónica. Un solo espacio en blanco, un tipo de dato incorrecto (enviar texto en lugar de número) o un UUID mal vinculado hará que los servidores del MH rechacen la transmisión.

¿Quieres ahorrarte meses de desarrollo, lectura de manuales técnicos y mantenimiento por cambios en las normativas de Hacienda?

Con Lumen, nos encargamos de toda la lógica pesada. Tú solo nos envías los datos básicos de la venta a través de nuestra API limpia, y nosotros armamos el JSON estructurado, gestionamos la firma digital, resolvemos el flujo de las Notas de Crédito y transmitimos directamente a Hacienda en milisegundos.

👉 Únete a la lista de espera para probar Lumen