Estructura XML del e-CF tipo 31 en República Dominicana: campos obligatorios y validaciones DGII

Por Ing. Carlos Méndez | 7 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.

El generador de XML pasa todas las validaciones internas del sistema pero la DGII devuelve error de esquema. El documento se ve correcto visualmente, pero el XSD de la DGII es estricto en el orden de elementos, en los tipos de datos de campos numéricos y en la presencia de campos condicionales que se vuelven obligatorios según el contexto. Desconocer esas reglas implica ciclos de rechazo en homologación que pueden retrasar semanas el go-live.

Esta guía documenta la estructura XML del e-CF tipo 31 (Factura de Crédito Fiscal) campo por campo, con las reglas de validación DGII que no están documentadas de forma explícita en la guía técnica oficial. El tipo 31 es el e-CF más complejo en términos de requisitos de campos porque aplica a transacciones B2B con ITBIS deducible.

Por qué el tipo 31 tiene la estructura más exigente

El e-CF tipo 31 (Factura de Crédito Fiscal) es el único tipo que permite al receptor deducir el ITBIS pagado como crédito fiscal ante la DGII. Por eso, exige datos del receptor que otros tipos no requieren: el RNC del comprador es obligatorio y debe ser un contribuyente activo verificable en el padrón DGII. Además, los campos relacionados con el ITBIS deben estar perfectamente alineados entre el detalle de ítems y el resumen.

El tipo 31 también es el más común en sistemas ERP y software de gestión para PyMEs y empresas medianas, ya que la mayoría de las transacciones B2B en República Dominicana se documentan con este tipo de comprobante.

Bloque Encabezado: campos y reglas

Sección IdDoc

TipoeCF: valor fijo "31" para este tipo de comprobante. No puede ser null ni estar ausente. eNCF: la secuencia del comprobante electrónico. Formato: letra E + 2 dígitos del tipo + 10 dígitos secuenciales (ej: E310000000001). La secuencia debe ser única por RNC emisor, nunca reutilizable. FechaVencimientoSecuencia: fecha límite de uso de la secuencia autorizada, formato DD-MM-AAAA. IndicadorMontoGravado: indica si el monto incluye ITBIS (1) o si está exento (2). Para tipo 31 con ITBIS, siempre 1. TipoIngresos: código DGII de clasificación de ingresos (01: Ingresos por operaciones, 02: Ingresos financieros, etc.). TipoPago: 1 (contado), 2 (crédito), 3 (gratuito). FechaPago: obligatorio cuando TipoPago es 1 o 2. Fecha de pago efectivo o fecha límite de pago a crédito.

Sección Emisor

RNCEmisor: el RNC del emisor habilitado como contribuyente electrónico. Debe coincidir exactamente con el RNC del certificado digital usado para firmar. Una discrepancia entre el RNC del certificado y el RNC en el XML genera rechazo inmediato. RazonSocialEmisor: razón social como aparece registrada en la DGII. DireccionEmisor: dirección fiscal registrada. NombreComercialEmisor: opcional para tipo 31, pero si se incluye debe corresponder al nombre comercial registrado. FechaEmision: fecha del documento en formato DD-MM-AAAA. Debe ser la fecha real de emisión, no puede ser futura ni anterior en más de los días establecidos por la DGII.

Sección Comprador

RNCComprador: obligatorio para tipo 31. Debe ser un RNC válido y activo en el padrón DGII. La DGII rechaza el documento si el RNC no existe o está inactivo. RazonSocialComprador: razón social del comprador. Debe coincidir con la registrada para ese RNC en la DGII, aunque la DGII acepta variaciones menores de formato. ContactoComprador y CorreoComprador: opcionales para tipo 31, útiles para notificaciones al receptor pero no validados por esquema.

Bloque DetallesItems: lógica de ítems y ITBIS

Cada elemento Item del bloque DetallesItems representa una línea de la factura. Los campos críticos son: NumeroLinea (entero secuencial desde 1), IndicadorFacturacion (1: normal, 2: exento, 3: propina), NombreItem (descripción del bien o servicio, máximo 80 caracteres), IndicadorBienOServicio (1: bien, 2: servicio), CantidadItem (decimal, punto como separador), ValorUnitarioItem (decimal, punto como separador), TablaSubcategoria (código de categoría ITBIS: 1 para 18%, 2 para 16%, 3 para 0%), y MontoItem (debe ser exactamente igual a CantidadItem * ValorUnitarioItem, la DGII valida la aritmética).

El campo ITBIS1 a nivel de ítem (por línea) es obligatorio cuando la línea está gravada. Su valor es la tasa decimal (0.18 para 18%, 0.16 para 16%). El monto de ITBIS por línea se calcula: MontoItem * ITBIS1. La DGII valida que la suma de ITBIS por línea cuadre con el TotalITBIS del bloque Resumen dentro de una tolerancia de RD$0.01. Diferencias mayores generan código de error de discrepancia aritmética.

<DetallesItems>
  <Item>
    <NumeroLinea>1</NumeroLinea>
    <IndicadorFacturacion>1</IndicadorFacturacion>
    <NombreItem>Licencia de software anual</NombreItem>
    <IndicadorBienOServicio>2</IndicadorBienOServicio>
    <CantidadItem>3</CantidadItem>
    <ValorUnitarioItem>50000.00</ValorUnitarioItem>
    <TablaSubcategoria>1</TablaSubcategoria>
    <OtraCondicion>0</OtraCondicion>
    <PrecioConDescuento>50000.00</PrecioConDescuento>
    <DescuentoMonto>0.00</DescuentoMonto>
    <ITBIS1>0.18</ITBIS1>
    <MontoItem>150000.00</MontoItem>
  </Item>
  <Item>
    <NumeroLinea>2</NumeroLinea>
    <IndicadorFacturacion>2</IndicadorFacturacion>
    <NombreItem>Capacitación (exenta ITBIS)</NombreItem>
    <IndicadorBienOServicio>2</IndicadorBienOServicio>
    <CantidadItem>1</CantidadItem>
    <ValorUnitarioItem>20000.00</ValorUnitarioItem>
    <TablaSubcategoria>3</TablaSubcategoria>
    <MontoItem>20000.00</MontoItem>
  </Item>
</DetallesItems>

Bloque Resumen: aritmética y consistencia

El bloque Resumen debe ser aritméticamente consistente con el bloque DetallesItems. Los campos clave son: MontoGravadoI1 (suma de MontoItem de líneas con TablaSubcategoria 1), MontoGravadoI2 (para tasa 16%), MontoExento (suma de líneas con TablaSubcategoria 3), TotalITBIS1 (MontoGravadoI1 * 0.18), TotalITBIS2 (MontoGravadoI2 * 0.16), MontoTotal (MontoGravadoI1 + MontoGravadoI2 + MontoExento + TotalITBIS1 + TotalITBIS2 - Descuentos), y MontoAPagar (igual a MontoTotal si no hay retenciones aplicadas).

MontoNoFacturable y MontoPeriodo son campos de periodicidad: aplican cuando la factura cubre un período (contratos mensuales, servicios continuos). Si la factura es puntual, MontoNoFacturable va en 0.00 y MontoPeriodo es igual a MontoAPagar. Omitir estos campos genera error de esquema porque el XSD los marca como required en la versión vigente del esquema tipo 31.

Errores de esquema más frecuentes en el tipo 31

Los errores de validación de esquema más frecuentes al integrar el tipo 31 son: (1) Orden de elementos incorrecto: el XSD de la DGII define un sequence estricto; los elementos deben aparecer en el orden exacto del esquema. (2) Coma como separador decimal: la DGII espera punto (.) como separador decimal en todos los campos monetarios. (3) RNCComprador ausente: en tipo 31 siempre es obligatorio; en tipo 32 es opcional. (4) TotalPaginas ausente o con valor 0: debe ser 1 o el número real de páginas. (5) Monto ITBIS en líneas exentas: para líneas con TablaSubcategoria 3, el campo ITBIS1 no debe estar presente; si se incluye con valor 0, puede generar advertencias o rechazos dependiendo de la versión del esquema.

Validación XSD local: herramientas recomendadas

Antes de enviar a la DGII, validar el XML generado contra el esquema XSD oficial. En Java, la librería javax.xml.validation.Validator es suficiente. En Python, lxml con etree.XMLSchema. En .NET, XmlSchemaSet con XmlReader. El esquema XSD de la DGII para e-CF es descargable desde su portal técnico. La versión del esquema debe coincidir con la declarada en el campo Version del XML; en 2026 la versión vigente es 1.0 para la mayoría de tipos.

from lxml import etree

def validar_ecf_xml(xml_string: str, xsd_path: str) -> tuple[bool, list]:
    """Valida un XML de e-CF contra el XSD de la DGII.
    Retorna (es_valido, lista_de_errores)
    """
    with open(xsd_path, 'rb') as f:
        schema_doc = etree.parse(f)
    schema = etree.XMLSchema(schema_doc)
    
    try:
        xml_doc = etree.fromstring(xml_string.encode('utf-8'))
        schema.validate(xml_doc)
        errores = schema.error_log
        if errores:
            return False, [str(e) for e in errores]
        return True, []
    except etree.XMLSyntaxError as e:
        return False, [f'XML mal formado: {str(e)}']

Preguntas frecuentes

¿Cuál es la diferencia entre el e-CF tipo 31 y tipo 32 en términos de estructura XML?

La diferencia principal es que el tipo 31 requiere RNCComprador como campo obligatorio, mientras que el tipo 32 (Factura de Consumo para B2C) no lo requiere. Además, el tipo 32 acepta receptores sin RNC (consumidores finales), usando en su lugar campos opcionales de identificación alternativa. La estructura XML base es similar, pero los campos obligatorios del bloque Comprador difieren entre ambos tipos.

¿Cómo puedo representar descuentos comerciales en el tipo 31?

Los descuentos en el tipo 31 se representan a nivel de línea de ítem usando el campo DescuentoMonto (monto absoluto del descuento por línea) y PrecioConDescuento (precio unitario tras aplicar el descuento). El MontoItem debe reflejar el precio con descuento, no el precio bruto. A nivel de Resumen, existe el campo TotalOtrasFormasDeDesgravar para descuentos globales que aplican sobre el total del comprobante.

¿Qué diferencia hay entre TipoIngresos 01 y 06 en el encabezado del tipo 31?

TipoIngresos clasifica el origen del ingreso según los códigos DGII: 01 es Ingresos por Operaciones (el más común para venta de bienes y servicios del giro ordinario), 02 es Ingresos Financieros, 03 es Ingresos Extraordinarios, 04 es Ingresos por Arrendamientos, 05 es Ingresos por Exportaciones, 06 es Otros Ingresos. La clasificación correcta afecta la declaración de renta del emisor; un tipo de ingresos incorrecto no genera rechazo del e-CF por la DGII pero sí puede generar observaciones en una auditoría.

¿Es posible tener líneas de ítems con diferentes tasas de ITBIS en el mismo tipo 31?

Sí. Un e-CF tipo 31 puede contener líneas con ITBIS al 18% (TablaSubcategoria 1), al 16% (TablaSubcategoria 2) y exentas (TablaSubcategoria 3) en el mismo documento. El bloque Resumen debe incluir los subtotales separados: MontoGravadoI1 y TotalITBIS1 para la tasa del 18%, MontoGravadoI2 y TotalITBIS2 para la del 16%, y MontoExento para las líneas exentas. La DGII valida que la suma de subtotales cuadre con el MontoTotal.

Sobre el autor

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.