Recientemente el portal de la DGII marcó el Paso 15 de nuestra certificación como "Finalizado". NexConnect Solutions SRL (RNC 132901322) quedó oficialmente habilitada como Emisor de e-CF en el sistema de Factura Electrónica de República Dominicana.
Quiero contar qué significa esto en términos prácticos — para nosotros, para los clientes que ya nos eligieron y para los que están evaluando plataformas.
Lo que cambia con la certificación
Antes de la certificación, NexConnect podía ayudar a otros contribuyentes a configurar su propia certificación, pero técnicamente operábamos en ambiente certification de DGII (un sandbox supervisado). Tras Paso 15, dos cosas cambian:
- Podemos emitir e-CFs en producción — usando nuestro propio RNC para facturar a clientes. Esto cierra el ciclo: cuando un cliente nos contrata, recibe un e-CF formal de DGII por su pago, no una factura tradicional.
- Tenemos visibilidad operativa real del Servicio Producción de DGII — los endpoints
/fe/recepcion/api/ecf,/fe/aprobacioncomercial/api/ecf, etc. ahora reciben tráfico productivo y los hemos monitoreado a lo largo de varios ciclos.
La diferencia entre estar certificado y estar en proceso es enorme. Un proveedor "en cert" todavía está aprendiendo los gotchas que la DGII no documenta (te explico abajo cuáles). Un proveedor certificado ya los pisó y los arregló.
El timeline real: 14 días, no semanas
Por transparencia, este fue el calendario exacto:
Día (de 14) | Hito |
|---|---|
Día 1 | Paso 1 — Postulación enviada y aceptada el mismo día |
Día 2 | Pasos 2, 3, 4, 5 — Pruebas de datos e-CF + Aprobación Comercial + Simulación + RIs (29 e-CFs + 11 PDFs en un solo día) |
Día 5 | Paso 6 — Auditoría de RIs rechazada (R1: razón social incorrecta) |
Día 6 | Paso 6 — R2 rechazado (NCF Modificado faltante en NC/ND) |
Día 7 | Paso 6 — R3 rechazado (formato QR Consulta Timbre incorrecto) |
Día 11 | Paso 6 — R4 rechazado (CodigoSeguridad mal computado) |
Día 12 | Paso 6 — R5 aceptado ✓ |
Día 14 (mañana) | Pasos 7-11 — La maratón de 12 horas (Servicio Recepción + Aprobación Comercial + 12 bugs resueltos en una sesión continua) |
Día 14 (tarde) | Pasos 12-15 — URL Servicios Producción + Declaración Jurada + Verificación Estatus + Finalizado |
Total: 14 días contados desde Paso 1 hasta Paso 15. Para contexto: la documentación oficial de DGII estima 4-8 semanas, y muchos proveedores tardan más. Nosotros lo hicimos rápido pero no fue limpio — hubo 4 rondas de rechazo en Paso 6 que documentamos en un post aparte sobre 7 trampas que rebotan tu cert DGII.
Que haya sido rápido importa menos que el hecho de haberlo terminado. Y de haber documentado cada falla.
Lo que aprendimos en el proceso (y tú no vas a tener que descubrir)
Pasar por los 15 pasos te enseña cosas que no están en ninguna guía:
- R1 — Razón Social: la DGII compara letra-por-letra con el registro RNC en mayúsculas. "NexConnect Solutions SRL" no es válido — debe ser "NEXCONNECT SOLUTIONS SRL". Y debe incluir el nombre comercial en el bloque emisor.
- R2 — NCF Modificado: Notas de Débito (tipo 33) y Crédito (tipo 34) deben mostrar en su Representación Impresa el NCF original que están modificando, en una posición específica. Si tu PDF lo omite o lo pone en otro lado, la auditoría te rebota.
- R3 — QR Consulta Timbre: el URL del QR debe usar CamelCase exacto en los parámetros (
RncEmisor,ENCF,MontoTotal,CodigoSeguridad, etc.) y el path correcto por tipo de e-CF. Para tipo 32 < RD$250mil va a un host distinto (fc.dgii.gov.do) con sólo 4 parámetros — no 7. - R4 — CodigoSeguridad: no es un hash SHA-256 — son literalmente los primeros 6 caracteres del
<ds:SignatureValue>del XMLDSig, sin transformación. - Paso 8 — Verificación de firmas DGII:
signxmlde Python rechaza firmas válidas de DGII por un bug interno. La solución es verificar manualmente concryptographypuro (~30 líneas). Si tu proveedor usa una librería estándar sin haber pisado este bug, su receiver va a rebotar el tráfico de DGII. - Paso 9 —
RNCEmisoren respuestas: el JWT que devuelve DGII tiene unsubque no es necesariamente el RNC del emisor real — para certs personales es la cédula. La respuesta ARECF debe usar el<RNCEmisor>que viene en el cuerpo del e-CF, no elsubdel JWT. - Paso 10 — ACECFs para eNCFs no recibidos: DGII envía aprobaciones comerciales (ACECF) para eNCFs que tu sistema nunca recibió en Paso 9. Si tu receiver responde 404, fallás el paso. La solución: lookup-or-create — generar un placeholder y responder firmado.
Cada uno de estos puntos costó horas resolverlo. Para los próximos clientes nuestros, ninguno es problema — ya están parchados en nuestro stack productivo.
¿Qué significa para los clientes?
Para clientes actuales
Ningún cambio operativo. Si emites e-CFs hoy a través de NexConnect, todo sigue igual — sólo que ahora el RNC emisor de tu cuenta opera contra DGII Producción y no Certification. Las URLs de tu Perfex/Odoo no cambian, tus integraciones no cambian, tus API keys no cambian.
Para clientes que están evaluando
Tres preguntas concretas que conviene hacerle a cualquier proveedor antes de firmar:
- ¿Cuándo se certificaron como Emisor e-CF? Si la respuesta es "estamos en cert" o "muy pronto", el riesgo es real. La cert es donde se descubren los bugs operacionales — tú no quieres ser quien los descubra junto con ellos.
- ¿Pueden mostrarme un e-CF emitido en producción con su propio RNC? Una factura suya, emitida desde su sistema, aceptada por DGII, con TrackId real. Esto demuestra capacidad técnica completa, no marketing.
- ¿Qué pasó cuando un cliente suyo falló Paso 6 de auditoría? Si nunca pasaron por ese escenario (porque nunca tuvieron clientes en cert), la respuesta va a ser teórica. Si lo vivieron, te van a contar cuáles son los 5-6 motivos comunes y cómo se arreglan.
Roadmap inmediato
Con la cert cerrada, lo que viene en el corto plazo:
- Onboarding de primeros clientes en producción — Instituto Oncológico Regional del Cibao primero, después contribuyentes Pequeños y Medianos que ya están en pipeline.
- MCP NexConnect (Plan I.1) — un paquete Python que permite a los clientes emitir e-CFs hablando con Claude, Cursor o Copilot CLI. Es un wedge competitivo único: ningún proveedor de e-CF en LATAM tiene integración MCP nativa.
Si estás evaluando plataformas de Factura Electrónica para tu empresa, escríbenos a ventas@nexconnect.do. Y si te interesa el lado técnico de cómo se ve por dentro una integración seria con DGII, sigue con la maratón de 12 horas o con los 15 pasos explicados.