Saltar a contenido

Entrega del e-CF al receptor

El modelo de la DGII tiene cuatro pasos obligatorios, y el tercero no es la DGII:

1) El emisor electrónico envía el e-CF a la DGII al momento de la emisión. 2) La DGII responde entregando un TrackID. 3) Luego el emisor electrónico envía el e-CF al receptor electrónico. 4) El receptor electrónico debe acusar recibo del e-CF al emisor.

— Informe Técnico e-CF v1.0, §8, Figura I

El TrackID del paso 2 es entre el emisor y la DGII. A usted le llega en el track_id del documento al transmitirse —nunca en el 202, que sólo confirma la recepción y el encolado—, y en el resumen RFCE de una factura de consumo (32 por debajo de RD$250.000) no existe. Todo, en estados.md.

Y si el receptor no es electrónico, el paso 3 se sustituye por entregarle la representación impresa (Figura II). Esta API se encarga de las dos ramas: usted no tiene que decidirlo ni implementarlo.

Cómo funciona

Cuando el e-CF queda fiscalmente válido (aceptado o aceptado condicional):

  1. Se consulta el directorio de facturadores con el RNC del comprador.
  2. Si es electrónico, se le transmite el XML firmado a su servicio de recepción. Si publica un servicio de autenticación, primero nos autenticamos contra él (semilla → token, firmando con el certificado del emisor).
  3. Se procesa su acuse de recibo (ARECF): Estado 0 = recibido, 1 = no recibido con su motivo.
  4. Si no es electrónico, se marca que la entrega corresponde a la representación impresa y, si el e-CF declara un correo del comprador, se le envía por correo.

Por qué después de la aceptación y no inmediatamente: la norma fija el orden ("luego"), no la inmediatez. Enviarle al receptor un comprobante que la DGII acabara rechazando obligaría a desdecirse, así que se espera la resolución — que normalmente llega en segundos.

Consultarlo

GET /api/v1/documents/{identificador} incluye, dentro de document (la forma de la respuesta):

{
  "document": {
    "…": "…",
    "entrega_al_receptor": {
      "via": "electronic",
      "descripcion": "Transmitido al servicio de recepción del receptor.",
      "acuse_recibido": true,
      "mensajes": [],
      "entregado_en": "11-08-2026 15:42:10"
    }
  }
}
via Significado
electronic Transmitido a su servicio, con acuse de recibo afirmativo.
printed No es facturador electrónico (o el e-CF no lo identifica): le corresponde la RI.
failed Es electrónico pero su servicio no aceptó el e-CF, o no respondió.
pending Aún no se ha intentado.

Correo al comprador: cuándo se envía y cuándo no

Qué dice la DGII. La norma fija que, si el receptor no es facturador electrónico, el emisor le entrega la representación impresa (Informe Técnico e-CF v1.0, §8, Figura II) y que, en las facturas de consumo por debajo de RD$250.000 (resumen RFCE), la entrega de la representación impresa al comprador y la conservación del e-CF completo por 10 años siguen siendo del emisor. No fija el canal: el correo es el que esta API ofrece para cumplirlo. Por eso el correo sólo sale donde esa entrega aplica, nunca a un receptor que ya recibe el XML en su propio servicio.

Se envía cuando se cumplen todas estas condiciones:

# Condición
1 El e-CF es fiscalmente válido: aceptado o aceptado condicional (incluye el resumen RFCE).
2 El comprador no es facturador electrónico (no figura en el directorio) o el e-CF no lo identifica (factura de consumo sin RNC).
3 El e-CF declara al menos un correo válido del comprador (comprador.correo, uno o varios separados por «;»; CorreoComprador en el modo XML).
4 Es una operación real: no son comprobantes del set de pruebas ni de la simulación de la certificación.
5 Aún no se envió: un solo correo por e-CF. Reenviar el mismo folio no lo repite.

No se envía en estos casos, y queda constancia del motivo:

Caso Por qué
Rechazado, en proceso, sin resolver o con error del sistema El e-CF no tiene validez fiscal (todavía): no hay nada que entregar.
El comprador es facturador electrónico Recibe el XML firmado en su servicio de recepción y acusa recibo; el correo sería un duplicado.
El e-CF no declara correo No hay a quién escribir. Los tipos 43 (Gastos Menores) y 47 (Pagos al Exterior) ni siquiera lo llevan: la RI se entrega por otro medio.
Ninguno de los correos declarados es una dirección válida No se intenta enviar a un destinatario inexistente.
El servicio de correo no está configurado en el despliegue Se omite; no es un error de la emisión.

A quién se envía. El correo sale a todos los correos del comprador (comprador.correo, separados por «;») como destinatarios (TO) y lleva en copia (CC) los correos del emisor: los de emisor.correo si el e-CF los declaró (tienen prelación), y si no, el correo registrado de la empresa emisora. Cada dirección se valida individualmente; una inválida en la lista se rechaza con 422 al emitir.

Qué lleva el correo. Un cuerpo con los datos del comprobante y el enlace para verificarlo en la DGII, y dos adjuntos con el nombre estándar de la DGII (RNC del emisor + e-NCF): la representación impresa ({RNC}{e-NCF}.pdf) y el e-CF firmado ({RNC}{e-NCF}.xml). No se envía sin la representación impresa: si el PDF aún no está generado, el correo espera y se reintenta cuando exista.

Reintentos. Si el servicio de correo no responde, o responde 429 o 5xx, o el PDF aún no existe, se reintenta con espera creciente (30 s, 1 min, 2 min, 5 min, 15 min, 30 min, 1 h; 8 intentos). Si lo rechaza (401, 422…), no se reintenta: repetirlo daría lo mismo. Un fallo del correo nunca altera el estado fiscal del e-CF.

GET /api/v1/documents/{identificador} lo informa, también dentro de document:

{
  "document": {
    "…": "…",
    "correo_al_comprador": {
      "estado": "sent",
      "destinatario": "[email protected]; [email protected]",
      "motivo": null,
      "enviado_en": "07-10-2026 14:05:31"
    }
  }
}
estado Significado
sent Enviado al destinatario.
skipped No correspondía enviarlo; motivo dice por qué.
failed El correo no pudo enviarse (el servicio falló o el PDF nunca llegó); motivo trae el error. Si era pasajero, se reintenta.
null Aún no se ha decidido (el e-CF no ha quedado válido o la entrega al receptor no ha corrido).

La representación impresa y el XML también quedan conservados en la plataforma: el detalle del documento (GET /api/v1/documents/{identificador}) los devuelve en base64 cuando el e-CF es válido (Mis documentos).

Un fallo aquí NO invalida su e-CF

Si el servicio del receptor está caído o rechaza el acuse, el comprobante sigue aceptado ante la DGII: es válido y ya está reportado. Por eso el estado de la entrega vive en su propio campo y nunca altera el estado fiscal del documento. Lo que procede en ese caso es reintentar o entregar la representación impresa, no volver a emitir.

Tampoco se reenvía un e-CF ya entregado: el receptor podría contarlo como duplicado.

Reintentos

Si la entrega falló porque su infraestructura no respondió (o el directorio de la DGII no estaba disponible), se reintenta automáticamente con espera creciente: 5 min, 15 min, 1 h, 3 h y 6 h, hasta 8 intentos. Después se deja de intentar y el caso queda para gestión manual — el e-CF sigue siendo válido.

Un acuse negativo NO se reintenta. Si el receptor respondió rechazando el acuse (firma inválida, duplicado, RNC que no corresponde), el problema es el documento y reintentar daría exactamente el mismo resultado. Lo mismo con la entrega impresa: ahí no hay a quién reintentar.

Referencias