El módulo de Facturación Electrónica le permite emitir, firmar y enviar comprobantes fiscales electrónicos (e-CF) a la DGII de manera completamente automatizada.
| Código | Nombre | Cuándo Usar |
|---|---|---|
| E31 | Factura de Crédito Fiscal | Ventas a empresas - el comprador tiene RNC |
| E32 | Factura de Consumo | Ventas a consumidores finales (sin RNC) |
| E33 | Nota de Débito | Ajustar una factura al alza (cobrar más) |
| E34 | Nota de Crédito | Devoluciones, descuentos, correcciones a la baja |
| E41 | Compras | Facturas de compra a proveedores |
| E43 | Gastos Menores | Gastos pequeños sin comprobante formal |
| E44 | Régimen Especial | Facturación bajo régimen especial de tributación |
| E45 | Gubernamental | Ventas a entidades gubernamentales |
| E46 | Exportación | Ventas de exportación |
| E47 | Compras para Retención | Compras con retención de impuestos |
Borrador → Firmado → Enviado → Aceptado ✓
→ Rechazado ✗ (puede reintentar)
| Estado | Significado | Qué Puede Hacer |
|---|---|---|
| Borrador | Creado, aún no firmado | Editar, eliminar |
| Firmado | Firma digital aplicada | Enviar a DGII, reintentar |
| Enviado | Enviado a DGII, esperando respuesta | Esperar, reintentar |
| RFCE Enviado | Resumen de consumo enviado (E32 < 250k) | Esperar |
| Aceptado | La DGII aprobó el comprobante | Descargar PDF, anular |
| Rechazado | La DGII rechazó el comprobante | Ver error, corregir, reintentar |
La pantalla principal de e-CF muestra todos sus comprobantes con:
| Columna | Descripción |
|---|---|
| Tipo | E31, E32, E33, etc. |
| NCF | Número de comprobante fiscal asignado |
| RNC Emisor | Su RNC |
| RNC Receptor | RNC del comprador |
| Monto | Total en RD$ |
| ITBIS | Impuesto cobrado |
| Fecha | Fecha de emisión |
| Estado | Badge de color según estado |
A la derecha de la lista verá información importante:
Datos del comprador (E31 solamente):
Líneas de ítems:
Para cada producto o servicio:
| Campo | Descripción |
|---|---|
| Nombre del ítem | Nombre del producto o servicio |
| Descripción | Detalle adicional (opcional) |
| Cantidad | Número de unidades (decimales permitidos) |
| Precio unitario | Precio por unidad |
| Tasa de ITBIS | 18%, 16%, o 0% (exento) |
Totales (se calculan automáticamente):
Además de los campos anteriores, necesita:
| Campo | Descripción |
|---|---|
| NCF Modificado | El NCF del comprobante original que está ajustando |
| Código de Modificación | 1=Devolución, 2=Ajuste de precio, 3=Descuento, 4=Error de facturación |
Las ventas del POS generan comprobantes automáticamente:
No necesita hacer nada adicional - el sistema firma y envía al completar la venta.
Haga clic en cualquier comprobante de la lista para ver todos sus datos:
| Acción | Cuándo | Descripción |
|---|---|---|
| Descargar PDF | Aceptado | Descarga el comprobante en formato PDF |
| Firmar y Enviar | Borrador | Firma digitalmente y envía a la DGII |
| Reintentar | Firmado/Enviado | Reintenta el envío si falló |
| Anular | Aceptado | Anula el comprobante (genera nota de crédito) |
Cada tipo de comprobante tiene su propia secuencia numérica. Por ejemplo:
En el panel lateral de la lista de documentos, vea:
Cuando los números se estén agotando, solicite más a la DGII y actualice la secuencia en el sistema.
Las facturas de consumo (E32) por montos menores a RD$250,000 no se envían individualmente a la DGII. En su lugar, se agrupan en un Resumen de Factura de Consumo Electrónico (RFCE) que se envía como lote.
El sistema maneja esto automáticamente:
Si un comprobante queda atascado (por ejemplo, la DGII estaba en mantenimiento):
El sistema reintenta hasta 5 veces con pausas progresivas (15 segundos el primero, luego el doble cada vez, máximo 2 minutos).
Solo se pueden anular comprobantes en estado Aceptado:
Para emitir comprobantes necesita un certificado digital emitido por la DGII.
Puede tener múltiples certificados pero solo uno activo a la vez.
Configure el ambiente en Configuración → Perfil de Empresa:
| Ambiente | URL | Uso |
|---|---|---|
| Set de Pruebas | TesteCF | Desarrollo y pruebas - no afecta registros reales |
| Certificación | CerteCF | Proceso de certificación con la DGII |
| Producción | eCF | Emisión real de comprobantes legales |
Importante: Use "Set de Pruebas" para pruebas. Solo cambie a "Producción" cuando la DGII le haya otorgado la certificación.
Vaya a e-CF → Herramientas para acceder a funciones especiales:
Para firmar archivos XML manualmente (útil durante el proceso de certificación):
Este es el proceso más importante y donde los usuarios suelen tener más dificultades. Axentra automatiza completamente este proceso.
La DGII requiere que toda empresa que quiera emitir e-CF pase un proceso de certificación. Esto consiste en enviar 25 comprobantes específicos con datos exactos que la DGII le proporciona en un archivo Excel.
La mayoría de los sistemas le piden que:
Esto puede tomar horas o días y es propenso a errores.
Axentra tiene un Test Set Runner que automatiza todo el proceso:
El sistema le muestra una vista previa de los 25 casos organizados por oleada:
| Oleada | Tipos | Cantidad | Método de Envío |
|---|---|---|---|
| 1 | E31, E32(≥250k), E41, E43, E44, E45, E46, E47 | 18 documentos | Automático vía API |
| 2 | E33, E34 | 3 documentos | Automático - usa los NCF de Oleada 1 |
| 3 | E32(<250k) resumen RFCE | 4 documentos | Automático vía API |
| 4 | E32(<250k) XML completo | 4 documentos | Subida manual al portal DGII |
Para cada caso puede ver:
Los 4 documentos de la Oleada 4 requieren subida manual al portal de la DGII:
| Sin Axentra | Con Axentra |
|---|---|
| Interpretar manualmente un Excel de 5,215 columnas | El sistema lee el Excel automáticamente |
| Crear 25 documentos uno por uno | Un clic ejecuta los 25 |
| Calcular mantos, ITBIS, líneas manualmente | Todo se calcula del Excel |
| Recordar el orden correcto de envío | Las oleadas se ejecutan en orden automáticamente |
| Mapear NCF entre notas de débito/crédito y facturas originales | El sistema mapea automáticamente |
| Si falla, empezar de cero | Reejecutar con un clic |
| Horas o días de trabajo | Minutos |
Una vez que los 25 comprobantes son aceptados:
La certificación DGII consta de un flujo de 7 pasos que se completan en el portal CerteCF antes de pasar a Producción. Axentra automatiza varios de estos pasos; el estado actual de cada uno se resume aquí.
| Paso | Nombre DGII | Descripción | Estado en Axentra |
|---|---|---|---|
| 1 | Postulación | Formulario inicial con datos de la empresa y URLs de contacto | ✅ Automatizado (agente DGII) |
| 2 | Pruebas de Datos (Set de Pruebas) | 25 comprobantes en 4 oleadas - los datos vienen de un Excel de la DGII | ✅ Automatizado - ver la sección 🎯 arriba |
| 3 | Aprobaciones Comerciales (ACECF) | Firma de aprobación comercial por cada E31 del set | ✅ Automatizado (runner ACECF) |
| 4 | Simulación de Actividad Comercial | Emisión de los 10 tipos de e-CF a través del pipeline real de firma + XSD + envío | ✅ Automatizado - simulador integrado |
| 5 | Representaciones Impresas | PDF con QR para cada tipo de comprobante, subidos en formato ZIP | ✅ Automatizado - botón Descargar ZIP genera todo |
| 6 | Configuración de URL + Juramento | Declarar sus endpoints de recepción y firmar el juramento legal | ⏳ Manual por ahora - se automatizará |
| 7 | Solicitud de NCF (Oficina Virtual) | Solicitar los rangos de NCF para producción en la Oficina Virtual | ⏳ Manual por ahora - se automatizará |
Cuando declare sus URLs de recepción en el portal de la DGII (Paso 6), la DGII enviará pruebas contra sus endpoints para verificar que responden correctamente. Si está certificando desde un ambiente local o de pruebas que no tiene IP pública, use un túnel (ej: tunnelmole o ngrok) para exponer temporalmente su servidor:
tmole 8080
Copie la URL https://...tunnelmole.net que le da el túnel y péguela en el portal de la DGII como URL de recepción. La DGII hará las llamadas de prueba contra ese túnel. Una vez certificado en producción, reemplace la URL por la definitiva.
Importante: algunos túneles gratuitos cambian el subdominio cada vez que se reinician. Si reinicia el túnel, actualice la URL en el portal antes de ejecutar la prueba.
La DGII prueba las 4 URLs del protocolo Emisor-Receptor:
GET /fe/autenticacion/api/semilla - obtener semillaPOST /fe/autenticacion/api/validacionCertificado - validar firma del emisorPOST /fe/recepcion/api/ecf - recibir comprobante y devolver ARECFPOST /fe/aprobacionComercial/api/ecf - recibir aprobación comercialAxentra expone los 4 endpoints correctamente, incluyendo variantes en mayúsculas y minúsculas (DGII mezcla ambas en sus pruebas).
En Configuración → Perfil de Empresa, puede activar o desactivar la facturación electrónica:
Cuando está desactivada:
Cuándo desactivar:
Axentra implementa los 4 endpoints del protocolo Emisor-Receptor de la DGII. Esto permite que proveedores, plataformas certificadas y la propia DGII le envíen comprobantes electrónicos directamente a su sistema, sin necesidad de descargarlos manualmente del portal.
Cuando un proveedor le emite un e-CF, su sistema puede enviar el XML firmado directamente a sus endpoints. El proceso es:
Su sistema expone estos endpoints bajo la ruta /fe/:
GET /fe/autenticacion/api/semilla
Retorna un XML SemillaModel que el emisor debe firmar digitalmente. La semilla contiene un valor aleatorio y una fecha de expiración. No requiere autenticación.
Respuesta: XML con la semilla fresca
POST /fe/autenticacion/api/validacioncertificado
POST /fe/autenticacion/api/validacionCertificado (variante con C mayúscula)
El emisor envía la semilla firmada con su certificado digital. El sistema verifica que:
SignedInfo canónico)serialNumber del SubjectEntrada: Multipart form con campo xml (semilla firmada)
Respuesta: JSON con el token JWT de 24 horas
{ "token": "eyJhbGciOiJSUzI1NiIs..." }
El token tiene como sub (subject) el RNC o cédula del emisor, para que los endpoints de recepción sepan quién está autenticado.
POST /fe/recepcion/api/ecf
POST /fe/recepcion/api/eCF (variante protocolar de DGII)
El emisor envía el comprobante fiscal electrónico firmado. Requiere el token Bearer obtenido en el paso anterior.
Entrada: Multipart form con campo xml (e-CF firmado)
Respuesta:
El comprobante recibido se almacena automáticamente en el sistema y queda disponible en la pestaña e-CF → Recibidos.
POST /fe/aprobacioncomercial/api/ecf
POST /fe/aprobacionComercial/api/ecf (variante camelCase de DGII)
Cuando un comprador aprueba o rechaza comercialmente un e-CF que usted emitió (E31), envía la aprobación firmada (ACECF) a este endpoint.
Entrada: Multipart form con campo xml (ACECF firmado)
Respuesta: JSON confirmando el procesamiento
{
"codigo": "01",
"estado": "Aprobación Comercial Procesada.",
"mensaje": []
}
Emisor Su Sistema (Axentra)
│ │
├── GET /fe/autenticacion/api/semilla ──→│
│←── XML SemillaModel ──────────────────┤
│ │
│ [Emisor firma la semilla] │
│ │
├── POST /fe/.../validacionCertificado ─→│
│←── { "token": "..." } ───────────────┤
│ │
│ [Emisor firma el e-CF] │
│ │
├── POST /fe/recepcion/api/ecf ────────→│
│←── XML ARECF (acuse de recibo) ──────┤
│ │
Axentra valida la firma de toda semilla entrante contra las autoridades certificadoras reconocidas por la DGII en República Dominicana. Actualmente aceptamos certificados emitidos por:
| CA | Organización | Uso típico |
|---|---|---|
| DigiFirma CA Subordinada 1 | Cámara de Comercio y Producción de Santo Domingo | Contribuyentes dominicanos - personas físicas y jurídicas |
| Viafirma / Avansi | Avansi SRL | Certificados de prueba de la DGII y ciertos emisores |
Si un certificado presentado por un emisor no se encadena a una de estas autoridades, la semilla se rechaza con código HTTP 401. Si su proveedor usa una CA distinta que la DGII reconoce pero aún no hemos incluido, abra un ticket con el administrador del sistema para añadirla al almacén de confianza.
En el modelo estándar de la DGII, una plataforma certificada (por ejemplo, un proveedor de software) puede autenticarse con su propio certificado y luego reenviar e-CFs firmados por muchos contribuyentes distintos. El flujo es:
IDCDO-00199999996 - "Pedro Pérez" en el ambiente de pruebas de la DGII)POST /fe/recepcion/api/ecf cuyo <Emisor><RNCEmisor> en el XML del comprobante no coincide con el del token - porque el emisor real es un contribuyente cliente de la plataformaEl sistema registra ambas identidades en los logs (jwt_sub + payload_rnc_emisor) para trazabilidad, pero no rechaza la divergencia. Este es el comportamiento que la DGII prueba en el Paso 6 de la certificación.
sub para auditoríavalidacionCertificado, eCF) porque la DGII mezcla casings en sus pruebasLa pestaña e-CF → Recibidos muestra en tiempo real todos los comprobantes que su empresa recibe a través del protocolo Emisor-Receptor. Se actualiza automáticamente cada 5 segundos.
En la parte superior de la página verá 4 tarjetas con cifras del día:
| Tarjeta | Significado |
|---|---|
| Recibidos | Total de comprobantes recibidos hoy |
| Aceptados | Comprobantes con ARECF entregado exitosamente |
| Rechazados | Comprobantes cuyo ARECF no pudo entregarse (error de firma, datos, etc.) |
| Aprob. pendiente | Comprobantes E31 que esperan su aprobación o rechazo comercial |
La tabla muestra los comprobantes en orden descendente por fecha de recepción, con:
| Columna | Descripción |
|---|---|
| Tipo | E31, E32, E41, etc. |
| NCF | Número del comprobante (E310000000001) |
| Emisor | RNC del emisor + razón social |
| Monto | Total en RD$ |
| ARECF | Badge de estado: Recibido / Rechazado / No aplica |
| Aprob. Comercial | Badge: Pendiente / Aprobado / Rechazado / No aplica |
| Recibido | Hora exacta de recepción |
En la esquina superior derecha, el punto verde pulsante indica que la página está conectada y actualizándose. No necesita refrescar manualmente.
Cada comprobante que entra por los endpoints se:
received_ecf_documents con el XML original completoLos comprobantes quedan disponibles para:
Para ver la pestaña Recibidos necesita el permiso received_ecf.read, que está incluido por defecto en los roles ADMIN, MANAGER, ACCOUNTANT y AUDITOR. Otros roles no verán la opción en la navegación.
Tanto la lista principal de comprobantes emitidos como la lista de recibidos usan paginación del lado del servidor. Esto significa que:
Los controles del paginador son los mismos en todas las listas de Axentra:
Revise el mensaje de error en el detalle del documento. Los errores comunes son:
No. Los comprobantes deben firmarse y enviarse a la DGII, lo cual requiere internet. Sin embargo, puede crear borradores sin conexión y enviarlos cuando se restablezca.
5 reintentos con pausas progresivas (15s, 30s, 1min, 2min, 2min). Si después de 5 intentos sigue fallando, puede reintentar manualmente.
Sí. Para las facturas de consumo (E32), el código de seguridad son los primeros 6 caracteres de la firma digital, y se genera automáticamente al firmar.