Checklist técnico para evaluar un proveedor de e-CF en República Dominicana

Integrar Comprobantes Fiscales Electrónicos en República Dominicana presenta un desafío que los ISVs suelen descubrir demasiado tarde: la validación de la DGII es asíncrona. A diferencia de Colombia, donde la DIAN responde en el mismo request, en RD el estado del e-CF puede tardar minutos u horas. Los proveedores que no gestionan bien ese estado asíncrono dejan al ISV implementando polling manual en producción.

Este checklist cubre 8 criterios técnicos para evaluar cualquier Proveedor de Servicios de Facturación Electrónica (PSFE) o proveedor de API e-CF antes de iniciar la integración. Cada criterio incluye una prueba concreta ejecutable en el sandbox del proveedor.

Criterio 1 — Habilitación ante la DGII como PSFE

La DGII habilitada a los Proveedores de Servicios de Facturación Electrónica (PSFE) mediante un proceso formal que incluye pruebas técnicas y certificación. Antes de evaluar el sandbox, verificar que el proveedor esté en el listado oficial de PSFEs habilitados por la DGII. Un proveedor no habilitado no puede transmitir e-CFs válidos a la DGII.

Verificación mínima de habilitación

Antes de evaluar el sandbox:
☐ Proveedor aparece en el listado DGII de PSFEs habilitados
☐ Cubre los 9 tipos de e-CF (e-31, e-32, e-33, e-34, e-41, e-43, e-44, e-45, e-47)
☐ Soporte para firma digital con certificado aprobado por la DGII
☐ Soporte para el formato e-CF válido (XML con SHA-256)
☐ Sandbox disponible sin necesidad de completar incorporación comercial

Criterio 2 — Gestión del estado asíncrono de la DGII

Este es el criterio que más diferencia a los proveedores maduros en el mercado dominicano. La DGII procesa los e-CFs de forma asíncrona: el PSFE envía el documento y la DGII puede tardar desde segundos hasta horas en devolver el estado. Si el proveedor no tiene webhooks nativos para notificar ese cambio de estado, el ISV debe implementar polling para consultar el estado periódicamente.

Prueba de flujo asíncrono en sandbox

// Paso 1: Emitir e-CF
POST /v1/ecf
{ "type": "e-31", ... }
// Respuesta esperada inmediata:
{
  "ecfId": "E310000000001",
  "ncf": "E310000000001",
  "status": "pending",   // <-- estado inicial correcto
  "submittedAt": "2026-08-24T10:00:00Z"
}

// Paso 2: Verificar webhook vs. polling
// Si el proveedor tiene webhooks:
// Tu endpoint recibe: { "ecfId": "E310000000001", "status": "accepted", "dgiiCode": "0" }
// Si no hay webhooks: debes GET /v1/ecf/E310000000001 cada N segundos

// Red flag: status "accepted" devuelto en el POST inicial (indica sandbox no asíncrono real)

Criterio 3 — Cobertura de los 9 tipos de e-CF

La DGII define 9 tipos de e-CF, cada uno con sus propias reglas de validación y campos obligatorios. Los más comunes en ISVs de gestión son: e-31 (Factura de Crédito Fiscal), e-32 (Factura de Consumo), e-33 (Nota de Débito), e-34 (Nota de Crédito) y e-41 (Compras). Para ISVs del sector gobierno o con operaciones especiales: e-43, e-44, e-45, e-47.

Mapear antes de integrar cuáles tipos necesita el ISV y verificar en el sandbox si cada tipo tiene endpoint propio, si las validaciones por tipo están documentadas y si el proveedor cubre los tipos menos comunes sin costo adicional o como add-on.

Criterio 4 — NCF y estructura del e-CF

El NCF (Número de Comprobante Fiscal) de los e-CFs tiene un formato específico: tipo de e-CF (e-XX) seguido del número de secuencia. La DGII asigna rangos de secuencia autorizados al emisor, y el PSFE debe gestionar esa secuencia de forma confiable. Un fallo en la gestión de secuencias puede generar NCFs duplicados o fuera de rango, que la DGII rechaza.

Qué verificar sobre la gestión de NCF

Checklist de gestión de NCF:
☐ El proveedor gestiona los rangos de secuencia autorizados por la DGII
☐ El ISV recibe el NCF en la respuesta de cada emisión
☐ El proveedor notifica cuando el rango se acerca al límite autorizado
☐ Hay mecanismo de contingencia cuando el rango se agota
☐ Los NCFs no se pueden reutilizar en caso de fallo de transmisión

Criterio 5 — Mensajes de error de la DGII traducidos a errores accionables

La DGII devuelve códigos de rechazo en el XML de respuesta. Algunos proveedores reenvían ese XML directamente al ISV sin procesarlo; otros traducen cada código a un mensaje en su propia API con el campo afectado identificado. La diferencia en tiempo de diagnóstico entre ambos enfoques es significativa cuando hay rechazos en producción.

Criterio 6 — Webhooks nativos para eventos de estado

Dado el modelo asíncrono de la DGII, los webhooks no son opcionales — son necesarios para cualquier integración que opere a volumen. El webhook debe notificar al ISV cuando el e-CF pase de "pending" a "accepted" o "rejected", incluyendo el código de respuesta de la DGII y el NCF definitivo. Sin webhooks, el polling se vuelve la única opción y genera carga innecesaria en ambas partes.

Criterio 7 — Historial de actualizaciones del Anexo Técnico DGII

La DGII ha publicado actualizaciones al Anexo Técnico de e-CF en varias oportunidades desde el inicio del régimen. Cada actualización puede modificar campos obligatorios, formatos de fecha, validaciones de RNC o la estructura del XML. Preguntar al proveedor cuántos días tardó en implementar la última actualización y si los clientes recibieron notificación con antelación.

Criterio 8 — Documentación y tiempo al primer e-CF funcional

El estándar e-CF tiene peculiaridades que no son obvias sin documentación clara: el formato del XML, la firma digital con el certificado del emisor, la secuencia del NCF y el flujo asíncrono. Un proveedor con buena DX debe tener ejemplos de código funcionales para los tipos de e-CF más comunes, una guía de onboarding que cubra el ciclo completo (emitir + consultar estado + recibir webhook) y acceso al sandbox sin pasar por el equipo comercial.

Para comparar cómo aplican estos criterios en los cuatro mercados de la región, consultar la guía 5 criterios técnicos para elegir una API de facturación en LATAM.

Preguntas frecuentes

¿Cuál es la diferencia entre un e-CF aceptado y un e-CF con aviso de la DGII?

Un e-CF aceptado es un documento que la DGII validó completamente y asignó el NCF definitivo. Un e-CF con aviso es un documento que la DGII acepta con observaciones no bloqueantes — el documento es válido legalmente pero hay campos que no cumplen perfectamente con el Anexo Técnico. Los avisos deben resolverse en actualizaciones futuras del sistema porque acumulados pueden convertirse en rechazos cuando la DGII endurezca las validaciones. El proveedor debe notificar ambos estados claramente al ISV.

¿Cómo puedo verificar que el proveedor gestiona correctamente los rangos de NCF?

Solicitar en el sandbox que se emitan e-CFs hasta agotar un rango de prueba pequeño y observar cómo responde el sistema: debe notificar cuando queden pocos NCFs disponibles, debe rechazar la emisión cuando el rango esté agotado con un error claro (no un 500), y debe tener un mecanismo documentado para solicitar y activar un nuevo rango sin downtime del servicio.

¿Qué diferencia hay entre el RNC del emisor y el RNC del comprador en la validación DGII?

El RNC del emisor es validado por la DGII contra el registro de contribuyentes habilitados para emitir e-CF. El RNC del comprador se valida solo en algunos tipos de e-CF — principalmente en el e-31 (Factura de Crédito Fiscal), donde el comprador debe ser un contribuyente activo para que el documento sea válido como crédito fiscal. En el e-32 (Consumo) el RNC del comprador es opcional. Un proveedor que no aplica esta distincción puede devolver rechazos confusos cuando el comprador es consumidor final.

¿Es posible integrar e-CF sin un PSFE certificado usando solo la API directa de la DGII?

Técnicamente sí — la DGII permite la integración directa sin intermediario PSFE si el emisor está habilitado como Facturador Electrónico Directo. Esto requiere que el emisor obtenga su propio certificado digital, implemente la firma del XML, gestione la secuencia de NCFs y maneje el flujo asíncrono con la DGII de forma autónoma. Para ISVs que emiten a nombre de terceros, la figura del PSFE es prácticamente obligatoria porque no es viable que cada cliente gestion su propia habilitación directa.

Este checklist es la aplicación República Dominicana de los 5 criterios técnicos generales para LATAM. La documentación oficial del flujo e-CF está disponible en el portal de la DGII.

Los proveedores certificados como PSFE ante la DGII incluyen: Gosocket, Edicom (presencia internacional), Alanube, Factura Dominicana, Uruware (opera como mifactura.do), Luganis y Polaris. La disponibilidad de documentación técnica pública varía entre ellos — un indicador de DX por sí mismo al evaluar.