Campos obligatorios del XML e-CF DGII: estructura técnica y validaciones

Por Ing. Carlos Méndez | 18 de septiembre de 2026

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.

Sumario: El XML del e-CF DGII tiene tres bloques obligatorios: Encabezado (datos de emisor, receptor y tipo), DetallesItems (líneas de la transacción) y Totales (ITBIS, exento, gravado y monto final). La omisión de cualquier campo obligatorio produce rechazo inmediato con código de error específico.

La especificación XML del e-CF en República Dominicana está definida por la DGII en su documentación técnica oficial y no sigue estrictamente estándares internacionales como UBL 2.1 o CFDI. Esto significa que los ISVs que han implementado facturación electrónica en Colombia (UBL 2.1) o México (CFDI) deben estudiar la especificación DGII desde cero, sin asumir compatibilidad de estructura o nomenclatura de campos.

Este artículo documenta los campos obligatorios de los tres bloques principales del XML e-CF: Encabezado, DetallesItems y Totales. Incluye el tipo de dato esperado, las validaciones que aplica la DGII y los errores más comunes por campo. Es la referencia técnica de este cluster; la guía de integración completa está en el artículo HUB de este cluster.

Bloque Encabezado: campos obligatorios

El bloque <Encabezado> es el primero dentro de <ECDF> y contiene la información de identificación del comprobante, el emisor y el receptor. Sus subcampos obligatorios son:

Identificación del comprobante

eTipoECF: código numérico del tipo de comprobante (31, 32, 33, 34, 41, 43, 44, 45, 47). Este campo determina los campos adicionales que son obligatorios para ese tipo específico. eNoComprobanteSecuencial: número de secuencia dentro del rango asignado por la DGII para el tipo de e-CF. Debe ser único por emisor y tipo. FechaEmision: fecha de emisión en formato YYYY-MM-DD. No puede ser una fecha futura ni anterior a 30 días (la DGII rechaza XML con más de 30 días de antigüedad). NumericVersion: versión del esquema XML. Actualmente la DGII acepta la versión 1.0.

Datos del emisor

RNCEmisor: RNC del contribuyente emisor (9 dígitos numéricos sin guiones). Debe coincidir exactamente con el RNC asociado al certificado digital INDOTEL. La DGII valida esta correspondencia como parte del proceso de autenticación. RazonSocialEmisor: razón social registrada en la DGII para el RNC emisor. NombreComercialEmisor: nombre comercial (opcional pero recomendado). DireccionEmisor: dirección registrada en la DGII. La DGII no valida la dirección contra su base de datos pero el campo es obligatorio para tipos 31, 32, 41 y 44.

Datos del receptor

Los datos del receptor varían según el tipo de e-CF. Para tipo 31 (Crédito Fiscal): RNCComprador es obligatorio. Para tipo 32 (Consumo): RNCComprador es opcional si el monto es menor al umbral definido por la DGII (actualmente RD$250,000 para identificación con cédula). Para tipos 33 y 34 (Notas): el RNC del receptor debe coincidir con el emisor del e-CF original al que hace referencia la nota. Para exportaciones (tipo 47): en lugar de RNC se usa el identificador del receptor extranjero.

Bloque DetallesItems: campos obligatorios por línea

El bloque <DetallesItems> contiene los ítems de la transacción. Cada ítem es un elemento <Item> con los siguientes campos obligatorios: NumeroLinea (número secuencial de la línea, comenzando en 1), IndicadorBienoServicio (B para bienes, S para servicios), Descripcion (descripción del ítem, máximo 200 caracteres), CantidadItem (cantidad numérica con hasta 4 decimales), PrecioUnitarioItem (precio por unidad con hasta 4 decimales), DescuentoMonto (monto de descuento aplicado, 0 si no hay descuento), TabasImpuestoItem (indicador de si aplica ITBIS: 1 para gravado 18%, 2 para gravado 16%, 3 para exento).

El campo TabasImpuestoItem es fuente frecuente de errores: un ISV que no distingue entre tasa del 18% y 16% generará inconsistencias en los totales de ITBIS. La DGII tiene productos gravados a ambas tasas y los cálculos deben separarse en el bloque Totales. La validación de la DGII comprueba que la suma de los ítems gravados al 18% multiplicada por 0.18 coincida con el campo ITBIS18% en Totales.

Bloque Totales: campos obligatorios y reglas de consistencia

El bloque <Totales> es donde ocurre la mayor cantidad de rechazos por inconsistencias de cálculo. Campos obligatorios: MontoGravadoTotal (suma de los montos de ítems gravados con ITBIS 18% o 16%, antes de impuesto), MontoGravadoI1 (monto gravado al 18%), MontoGravadoI2 (monto gravado al 16%, si aplica), MontoExento (suma de ítems exentos de ITBIS), ITBIS18 (resultado de MontoGravadoI1 × 0.18), ITBIS16 (resultado de MontoGravadoI2 × 0.16, si aplica), MontoTotal (suma de todos los montos más ITBIS).

Regla de consistencia crítica: MontoTotal debe ser igual a MontoGravadoTotal + MontoExento + ITBIS18 + ITBIS16 + otros impuestos aplicables. La DGII usa una tolerancia de RD$0.01 para diferencias de redondeo en MontoTotal, pero NO aplica tolerancia en los campos de ITBIS individuales. Errores de redondeo en los decimales del ITBIS son la causa más difícil de depurar porque la diferencia puede ser de RD$0.01.

Campos adicionales por tipo de e-CF

Notas de Crédito (tipo 34) y Débito (tipo 33): requieren el campo eNCFModificado que referencia el número del e-CF original que se está modificando. La DGII valida que el e-CF original exista y esté autorizado. Si el e-CF original fue emitido por un PSFE diferente, puede haber problemas de validación cruzada.

Gubernamentales (tipo 45): requieren el código de la institución gubernamental receptora. Exportaciones (tipo 47): requieren datos del transporte, país de destino y términos de pago en divisa extranjera. Regímenes Especiales (tipo 44): requieren el número de resolución de régimen especial emitido por la DGII. La documentación técnica completa por tipo está disponible en el portal oficial de la DGII en ecf.dgii.gov.do.

Preguntas frecuentes sobre la estructura XML del e-CF DGII

¿Cuál es el encoding correcto para el XML del e-CF DGII?

El XML del e-CF debe estar codificado en UTF-8 sin BOM (Byte Order Mark). El uso de BOM es una causa frecuente de rechazo porque el parser XML de la DGII lo interpreta como un carácter inválido al inicio del documento. En idiomas como Java, verificar que el XMLStreamWriter no agregue BOM. En .NET, usar UTF-8Encoding(false) en lugar de Encoding.UTF8 que agrega BOM por defecto en algunas versiones.

¿Cómo puedo validar el XML del e-CF antes de enviarlo a la DGII?

La DGII publica el XSD (XML Schema Definition) del e-CF en su portal técnico. Se puede validar el XML contra el XSD localmente antes de enviarlo. Adicionalmente, algunos PSFEs ofrecen endpoints de pre-validación que simulan la respuesta de la DGII sin autorizar el comprobante. La validación local contra XSD detecta errores de estructura pero no errores de negocio como secuenciales duplicados o RNC inválido.

¿Qué diferencia hay entre MontoGravadoTotal y MontoGravadoI1 en el bloque Totales?

MontoGravadoTotal es la suma de todos los montos base gravados con ITBIS (tanto al 18% como al 16%). MontoGravadoI1 es específicamente el monto base gravado al 18%. MontoGravadoI2 es el monto base gravado al 16%. La relación es: MontoGravadoTotal = MontoGravadoI1 + MontoGravadoI2. Si todos los ítems tienen la misma tasa, MontoGravadoTotal = MontoGravadoI1 y MontoGravadoI2 = 0 o se omite.

¿Es posible incluir más de un tipo de ITBIS en el mismo e-CF sin errores de validación?

Sí. Un mismo e-CF puede tener ítems gravados al 18%, ítems gravados al 16% e ítems exentos simultáneamente. La clave es que el bloque Totales separe correctamente los montos base y los ITBIS calculados por tasa. El campo TabasImpuestoItem en cada ítem indica la tasa aplicable. La validación de la DGII agrupa los ítems por tasa y verifica que los cálculos de ITBIS en Totales sean correctos para cada grupo.