Convertirte en Emisor de e-CF habilitado por la DGII no es algo que se haga en un fin de semana. Son 15 pasos que combinan trámites administrativos, pruebas técnicas, auditoría manual y verificación final. La documentación oficial de DGII te dice cuáles son los pasos, pero no qué se pone difícil en cada uno.
Este post es la guía que hubiéramos querido tener antes de empezar nuestra propia certificación (RNC 132901322, completada este año en 14 días). Vamos paso por paso.
Prerequisitos antes del Paso 1
Antes incluso de pisar el portal de DGII, necesitas tener tres cosas listas:
- RNC activo y al día — verificable en
consultarnc.dgii.gov.do. Sin esto no puedes ni empezar. - Certificado digital — un archivo
.p12(PKCS#12) emitido por DigiFirma, Cámara TIC o Avansi. Costo aproximado: RD$3,500/año. Tiempo de emisión: 1-3 días hábiles tras validación presencial. - Acceso a Factura Electrónica activado — desde tu Oficina Virtual DGII (oficinavirtual.dgii.gov.do) solicitás "Acceso a Facturación Electrónica". DGII te aprueba en 1-2 días.
Una vez tienes los tres, puedes empezar.
Paso 1 — Postulación
Qué es: registro inicial en el sistema de Factura Electrónica de DGII.
Cómo: desde el portal fe.dgii.gov.do cargás un XML de postulación firmado con tu certificado digital. El XML declara: RNC emisor, datos de la empresa, ERP que usarás, escenarios que vas a probar en Pasos 2-4.
Tiempo típico: mismo día a 1 día hábil.
Gotcha: la firma XMLDSig que requiere DGII en este XML es exigente — algunos firmadores genéricos producen XMLs que la DGII rechaza por canonicalización incorrecta. Si usas NexConnect, te generamos el XML postulación firmado por API. Si lo haces a mano, asegúrate de usar SHA-256 + canonicalización exclusiva (no la default de la mayoría de librerías).
Paso 2 — Pruebas de Datos e-CF
Qué es: enviar 29 e-CFs de prueba que cubren los 11 tipos del sistema (31, 32 ≥250k, 32 \<250k, 33, 34, 41, 43, 44, 45, 46, 47).
Cómo: DGII te entrega un Excel con los datos exactos que cada e-CF debe contener. Tu sistema los genera, firma y envía vía API a los endpoints de certificación.
Tiempo típico: 2-4 horas si todo está validado contra los XSDs antes.
Gotcha crítico: DGII tiene un sistema de resets. Si un solo e-CF es rechazado, todo el set se reinicia. Tienes que pre-validar los 29 contra sus XSDs localmente antes de tocar el endpoint de DGII. Y hay tipo-específicos: tipo 43 no permite el elemento <Comprador>, tipo 32 \<250k es un caso especial que se sube por UI (no por API) y un solo rechazo borra el progreso de los otros 28.
Paso 3 — Pruebas Aprobación Comercial
Qué es: DGII te envía 11 e-CFs ficticios como si fueras el comprador. Tu sistema debe aprobarlos o rechazarlos vía ARECF (Aprobación Comercial e-CF).
Cómo: descargás los 11 e-CFs del portal, generás 11 respuestas ARECF firmadas, las enviás de vuelta.
Tiempo típico: mismo día.
Gotcha: los 11 ARECFs deben ser aprobaciones — DGII espera que tu sistema apruebe todo el set de prueba. Si rechazás alguno por "motivo de prueba", puedes trabar el paso.
Paso 4 — Pruebas Simulación de e-CF
Qué es: emites 11 e-CFs reales (no de prueba) que pasan por tu pipeline completo de producción.
Cómo: usas tu ERP normal (Perfex, Odoo, API) para emitir las 11 facturas. DGII las valida en tiempo real.
Tiempo típico: 1-2 horas.
Gotcha crítico para Paso 5: persiste los XML firmados en disco/storage. La razón: el CodigoSeguridad que va en el QR de la Representación Impresa (Paso 5) son los primeros 6 caracteres del <ds:SignatureValue>. Si tu sistema vuelve a firmar al generar el PDF, la firma cambia, el CodigoSeguridad cambia, y la auditoría te rebota. Guarda el XML firmado de Paso 4 exacto para usarlo en Paso 5.
Paso 5 — Pruebas Simulación de RI
Qué es: subir al portal los 11 PDFs (Representación Impresa) de los e-CFs emitidos en Paso 4.
Cómo: generás los 11 PDFs con tu sistema, los subís individualmente o como ZIP (límite 10MB total).
Tiempo típico: subir es rápido. La validación inicial del portal toma minutos.
Gotcha: la auditoría real viene en Paso 6 — Paso 5 sólo valida que los archivos existen y son legibles.
Paso 6 — Validación Representación Impresa
Aquí es donde la cert se hace lenta.
Qué es: un auditor humano de DGII abre cada uno de tus 11 PDFs y los compara contra el "Modelo Ilustrativo" oficial. Revisa logo, layout, datos del emisor, QR Consulta Timbre, posición de cada campo.
Tiempo típico: 3-7 días hábiles por ronda. Y son frecuentes 2-3 rondas — en nuestro caso fueron 4.
Gotchas que te van a rebotar:
- R1 — Razón Social mal escrita: DGII compara letra-por-letra con su registro RNC. "NexConnect Solutions SRL" se va a rebotar porque el registro la tiene en mayúsculas: "NEXCONNECT SOLUTIONS SRL".
- R2 — NCF Modificado faltante: en tipos 33 (Nota Débito) y 34 (Nota Crédito), la RI debe mostrar el NCF original que está siendo modificado, en una posición específica del header (no del body).
- R3 — QR Consulta Timbre con formato incorrecto: el URL del QR debe usar CamelCase exacto (
RncEmisor,ENCF,MontoTotal,CodigoSeguridad,FechaEmision,FechaFirma,RncComprador). Para tipo 32 \<250k, el QR usa un host distinto (fc.dgii.gov.do) y sólo 4 parámetros. - R4 — CodigoSeguridad incorrecto: no es un hash. Son los primeros 6 caracteres literales del
<ds:SignatureValue>en el XML firmado, sin transformación.
Nuestro proceso tuvo R1, R2, R3 y un R4 separado antes de que R5 fuera aceptado. Cada ronda agregó 3-5 días.
Paso 7 — Configuración Servicios de Pruebas
Qué es: registrar en el portal las URLs de tu receiver para que DGII pueda llamarlas en Pasos 8-11.
Cómo: desde el portal, cargás tres URLs (autenticación, recepción, aprobación comercial) y validás conectividad HTTPS.
Tiempo típico: minutos.
Gotcha: las URLs deben ser públicas y con HTTPS válido. Localhost no funciona, ngrok funciona pero es frágil. Si tu sistema corre en una IP privada o detrás de un proxy raro, vas a tener que ajustar.
Paso 8 — Pruebas Inicio Autenticación
Aquí empieza la maratón técnica.
Qué es: DGII llama a tu endpoint /fe/autenticacion/api/Semilla, te entrega un XML "semilla", espera que lo firmes con tu certificado y lo devuelvas. A cambio te emite un JWT que vas a usar en Pasos 9-10.
Tiempo típico: debería ser minutos, pero si tu sistema tiene bugs en la verificación XMLDSig, puedes perder horas.
Gotcha catastrófico: la librería estándar signxml de Python rechaza firmas válidas de DGII por un bug interno (verificación cae sobre canonicalización inclusiva vs exclusiva). Lo descubrimos a las 5 horas de debugging en el Paso 8. La solución: implementar verificación manual usando cryptography puro (~30 líneas) en lugar de signxml. Si tu proveedor no ha pisado este bug, su receiver va a rebotar todo el tráfico de DGII.
Paso 9 — Pruebas Inicio Recepción
Qué es: usando el JWT del Paso 8, DGII envía e-CFs firmados a tu endpoint /fe/recepcion/api/ecf. Tu sistema debe verificar la firma, extraer datos, persistir el ReceivedInvoice, y responder con ARECF firmado.
Tiempo típico: minutos si Paso 8 anduvo limpio.
Gotcha: el campo RNCEmisor del ARECF que envías de vuelta debe venir del cuerpo del e-CF, no del sub del JWT. Para certificados personales (cédula), el sub del JWT contiene la cédula (17 chars con prefijo IDCDO-), no el RNC. Si usas el sub como RNCEmisor en tu respuesta, DGII te rebota con "El acuse de recibo no es válido" — porque su validador XSD espera un RNC numérico de 9 o 11 dígitos.
Paso 10 — Pruebas Inicio Aprobación Comercial
Qué es: DGII envía ACECFs (Aprobación Comercial e-CF) firmados a tu endpoint /fe/aprobacioncomercial/api/ecf. Tu sistema debe firmar y responder con ACECF de aprobación.
Tiempo típico: minutos.
Gotcha: DGII puede enviar ACECFs para eNCFs que tu sistema nunca recibió en Paso 9. Si tu receiver responde 404 ("no encontré ese e-CF"), el paso falla. La solución: lookup-or-create. Si el eNCF no existe en tu base, generás un ReceivedInvoice placeholder con los datos del ACECF entrante y respondés normalmente.
Paso 11 — Verificación
Qué es: el portal DGII consolida los resultados de Pasos 8, 9, 10 y los marca como "Verificado".
Cómo: automático, sin acción tuya.
Tiempo típico: minutos a 1 hora desde que Paso 10 termina exitosamente.
Paso 12 — URL Servicios Producción
Qué es: registrar las URLs de producción (no las de pruebas) en el portal. En muchos casos son las mismas, pero la DGII las pide explícitamente.
Tiempo típico: minutos.
Paso 13 — Declaración Jurada
Qué es: descargás un PDF de "Declaración Jurada de Compromiso", lo firmás digitalmente con tu certificado, lo subís de vuelta.
Tiempo típico: 10-15 minutos.
Gotcha: la declaración tiene una validación de firma similar a Paso 1 — usa la misma herramienta que firmó tu postulación.
Paso 14 — Verificación Estatus
Qué es: DGII cruza tu información (RNC activo, certificado vigente, todos los pasos anteriores marcados completos) y te aprueba para producción.
Tiempo típico: automático, segundos a horas.
Paso 15 — Finalizado
Qué es: el portal cambia el estado a "Finalizado" y te llega un mensaje:
"Ha completado de manera exitosa el proceso de certificación como Facturador Electrónico, favor acceder a su Oficina Virtual (OFV) donde estará recibiendo información adicional sobre el envío y recepción de e-CF."
A partir de este momento eres un Emisor de e-CF habilitado y puedes emitir comprobantes con valor fiscal real.
Tiempos reales agregados
Para una empresa que arranca desde cero, con un equipo competente y empujando rápido:
Etapa | Días útiles |
|---|---|
Prerequisitos (certificado INDOTEL + activación FE) | 4-7 |
Pasos 1-5 (técnicos, controlados por tú) | 3-5 |
Paso 6 (auditoría DGII) — sin re-rondas | 3-7 |
Paso 6 con 2-3 re-rondas (caso típico) | 9-21 |
Pasos 7-11 (técnicos, alta complejidad) | 1-3 |
Pasos 12-15 (administrativos finales) | 1-2 |
Total mínimo: 12-17 días. Realista con auditoría: 3-5 semanas. Y con un equipo aprendiendo el sistema desde cero: 6-10 semanas.
Cómo NexConnect acelera esto para tú
Cuando un cliente nuestro arranca su cert, no parte de cero — parte de un sistema que ya pasó los 15 pasos. Eso significa que:
- Los XMLs de Paso 1, 2 y 13 los generamos correctamente con la firma exacta que DGII acepta.
- El generador de RIs (PDFs de Paso 5) ya está alineado con los Modelos Ilustrativos y pasó las 4 rondas R1-R4.
- El receiver del cliente — los endpoints de Pasos 7-11 — son los mismos que nosotros usamos en producción, ya con los 12 bugs del Paso 8-11 resueltos.
En la práctica: Pasos 1-5 y 7-15 los completamos en menos de una semana. Lo único fuera de nuestro control es Paso 6 (auditoría manual de DGII), pero como entregamos PDFs ya validados contra los criterios R1-R4, frecuentemente pasa en 1-2 rondas en lugar de 4.
Si quieres que te acompañemos en tu cert, escríbenos a ventas@nexconnect.do. Para detalles más finos sobre los gotchas, puedes seguir con 7 trampas que rebotan tu cert DGII o con la maratón de 12 horas resolviendo el receiver.
Esta guía está basada en el proceso real que NexConnect Solutions SRL completó este año. Algunos detalles operativos (orden de pasos, número de rondas) pueden cambiar con futuras versiones del portal DGII. Fuente: experiencia operativa + documentación oficial de DGII en fe.dgii.gov.do.