Acuse de Recibo y Respuesta del Receptor en e-CF: Cómo Funciona en República Dominicana
El acuse de recibo y la respuesta del receptor son partes clave del flujo del e-CF en República Dominicana. El receptor debe responder dentro del plazo establecido por la DGII.
El mensaje de aceptación o rechazo es el documento que el receptor de un e-CF Tipo 31 debe transmitir a la DGII para confirmar si acepta, acepta condicionalmente o rechaza la factura de crédito fiscal recibida. No es opcional ni cosmético: tiene consecuencias tributarias directas sobre el crédito fiscal del ITBIS y plazos legales específicos. Para empresas con volúmenes altos de facturas recibidas, automatizar esta gestión es operativamente crítico.
Esta guía explica cómo funciona el mensaje de aceptación del receptor de e-CF en República Dominicana, cuándo es obligatorio enviarlo, qué estados puede declarar el receptor, los plazos legales aplicables, la estructura técnica del mensaje y los errores frecuentes en su gestión que generan exposición tributaria.
Qué es el mensaje de aceptación
Definición técnica
El mensaje de aceptación es un documento electrónico estructurado que el adquiriente de un e-CF Tipo 31 firma y transmite a la DGII. Contiene una referencia al e-CF original (por su CUDE), el estado declarado por el receptor (aceptado, aceptado condicional, rechazado), la fecha de la declaración, e identificación del receptor. Tiene su propio XML, su propia firma XAdES y su propio ciclo de transmisión y validación ante la DGII.
Marco normativo
El mensaje de aceptación está definido en el esquema oficial de la DGII para facturación electrónica y forma parte del ciclo del e-CF desde el lado del adquiriente. Su propósito normativo es triple: confirmar que el adquiriente aceptó el contenido del e-CF, habilitar el derecho al crédito fiscal del ITBIS cuando aplica, y registrar formalmente el cierre del ciclo del documento entre emisor, receptor y DGII.
Cuándo es obligatorio
e-CF Tipo 31 con derecho a crédito fiscal
Cuando una empresa recibe un e-CF Tipo 31 (factura de crédito fiscal) y quiere tomar el ITBIS cargado como crédito fiscal en su declaración, debe emitir el mensaje de aceptación declarando que acepta (total o condicionalmente) el documento. Sin mensaje válido transmitido a la DGII, el crédito fiscal puede ser cuestionado en una revisión tributaria posterior. Por eso, para empresas con muchas facturas recibidas, automatizar la emisión del mensaje es esencial.
Plazos legales
La DGII establece plazos específicos para transmitir el mensaje de aceptación desde la recepción efectiva del e-CF. Pasado ese plazo, el documento se entiende tácitamente aceptado en algunos casos o puede afectar el ejercicio del crédito fiscal en otros. La práctica recomendada es transmitir el mensaje el mismo día de recepción del e-CF, o máximo dentro del siguiente día hábil. Para volúmenes altos, esto significa integrar la emisión del mensaje al flujo de aprobación contable, no como trámite separado.
e-CF Tipo 32 y otros tipos
Los e-CF Tipo 32 (factura de consumo) no requieren mensaje de aceptación porque el receptor no se identifica como contribuyente. Para los demás tipos (notas, compras, gastos menores, etc.), la obligación del mensaje depende del tipo específico y de si genera derecho a crédito fiscal. Las notas crédito y débito asociadas a un Tipo 31 original también suelen requerir mensaje de aceptación.
Estados posibles del mensaje
Aceptación total
El receptor declara que acepta completamente el contenido del e-CF: confirma que los bienes o servicios facturados se recibieron correctamente, que los montos son los acordados y que asume el crédito fiscal correspondiente del ITBIS. Es el estado más frecuente y el flujo natural cuando la operación se ejecutó como se esperaba comercialmente.
Aceptación condicional
El receptor acepta el e-CF pero registra observaciones específicas: algún detalle del documento difiere de lo acordado pero no invalida la operación. La aceptación condicional habilita el crédito fiscal igual que la aceptación total, pero deja registro formal de las observaciones para auditorías futuras o eventuales correcciones.
Rechazo
El receptor rechaza completamente el e-CF: no reconoce la operación, no recibió los bienes o servicios, o los datos son incorrectos en grado tal que invalidan el documento. El rechazo elimina el derecho al crédito fiscal sobre esa factura y obliga al emisor a emitir nota crédito (Tipo 34) anuladora si corresponde, seguido eventualmente de una nueva factura corregida.
Estructura técnica del mensaje
Referencia al e-CF original por CUDE
El mensaje de aceptación referencia el e-CF original por su CUDE único, no por su número secuencial ni por la identificación del emisor. Ese CUDE debe corresponder exactamente a un e-CF previamente aceptado por la DGII. Un mensaje que referencia un e-CF inexistente o rechazado genera rechazo a su vez.
Firma del receptor
El mensaje de aceptación se firma con el certificado digital del receptor (no del emisor). Eso significa que la empresa que recibe debe contar con su propio certificado digital vigente para poder emitir mensajes de aceptación. La firma sigue los mismos algoritmos y canonicalización que la del e-CF: SHA-256, RSA-SHA256, C14N Exclusiva.
Errores frecuentes en la gestión
Omisión del mensaje por desconocimiento
El error más costoso operativamente es no emitir mensaje de aceptación cuando corresponde. La empresa registra el crédito fiscal del ITBIS en su declaración pero la DGII no tiene constancia formal de la aceptación. En una revisión posterior, esos créditos pueden ser desconocidos. Prevención: integrar la emisión del mensaje en el mismo flujo de aprobación contable de las facturas recibidas, no como paso separado opcional.
Aceptación por inercia de facturas que deberían rechazarse
Cuando la automatización acepta todos los e-CF recibidos sin filtro humano, las facturas erróneas (montos incorrectos, productos no recibidos) pasan a aceptadas automáticamente. Corregir después implica notas crédito y reemplazos. La práctica recomendada es automatizar la aceptación solo de facturas que pasan validaciones internas (cruce con orden de compra, verificación de recepción física) y derivar a revisión humana las que no las pasan.
Mensajes enviados fuera de plazo
Sistemas con cola de mensajes que se procesan en batch pueden caer fuera del plazo legal cuando el batch no se ejecuta. Si el plazo se vence sin enviar el mensaje, las consecuencias dependen del caso pero suelen implicar pérdida del crédito fiscal o aceptación tácita automática. Monitorear el tiempo desde la recepción de cada e-CF hasta el envío del mensaje es parte del checklist operativo básico.
Preguntas frecuentes
¿Cuál es la diferencia entre aceptación expresa y aceptación tácita? La aceptación expresa es cuando el receptor transmite efectivamente un mensaje declarando que acepta el e-CF. La aceptación tácita ocurre cuando el receptor no transmite ningún mensaje dentro del plazo legal: dependiendo del caso, la DGII puede asumir aceptación por defecto. La aceptación expresa es la práctica recomendada porque deja registro formal y elimina ambigüedades en revisiones posteriores. La tácita, aunque legalmente válida en algunos contextos, deja al receptor expuesto a interpretaciones y puede complicar la defensa del crédito fiscal ante una eventual revisión.
¿Cómo puede automatizarse el envío de mensajes de aceptación sin perder control sobre facturas problemáticas? Mediante reglas de validación previas a la aceptación automática. Antes de generar mensaje de aceptación, el sistema cruza el e-CF recibido contra: la orden de compra original (si existe), la confirmación de recepción física (si aplica), el catálogo de proveedores autorizados y los límites de monto aprobados sin revisión humana. Solo e-CF que pasan todas las validaciones se aceptan automáticamente; los que no pasan se derivan a aprobación humana antes de generar el mensaje. Esa combinación da control sin sacrificar eficiencia.
¿Qué diferencia hay entre rechazar un e-CF con mensaje y solicitar al emisor que la anule? Son dos mecanismos complementarios. Rechazar mediante mensaje de aceptación es la acción del receptor que declara formalmente ante la DGII que no reconoce el e-CF. Solicitar anulación al emisor es una comunicación comercial que pide que el emisor emita una nota crédito (Tipo 34) anuladora. Ante un error grave, conviene hacer ambas: rechazar con mensaje para no asumir el crédito fiscal indebidamente y solicitar al emisor la nota crédito para cerrar contablemente el ciclo. Solo rechazar sin nota crédito puede dejar la factura en estado complicado: rechazada por el receptor pero aún válida en el sistema de la DGII.
¿Es posible enviar un mensaje de aceptación que corrija uno enviado previamente con error? En la mayoría de los casos no de manera directa: una vez transmitido y aceptado por la DGII, el mensaje queda registrado. Si el receptor envió por error una aceptación cuando debía rechazar (o viceversa), el camino correctivo suele ser coordinar con el emisor: solicitar emisión de nota crédito que anule el e-CF y posteriormente la emisión de una nueva factura corregida que reciba el mensaje correcto. La automatización del mensaje debe contemplar esta imposibilidad de corrección directa: vale más un mensaje en revisión humana antes de enviar que un envío rápido que después requiere ciclo de corrección.
Artículos Relacionados
Los 10 tipos de comprobantes fiscales electrónicos (e-CF) en República Dominicana: cuándo usar cada uno
Referencia práctica de los 10 tipos de comprobantes fiscales electrónicos en República Dominicana: código, caso de uso, flujo de emisión (síncrono o asíncrono) e implicaciones técnicas para developers e integradores.
Cuánto tiempo toma integrar la API de facturación electrónica de la DGII: benchmark por método
Desglose honesto del tiempo de integración de la API de facturación electrónica de la DGII por etapa: lectura de documentación, construcción de payloads, manejo de estados y diagnóstico de rechazos. Comparativa REST vs MCP con estimaciones transparentes.
Errores de rechazo de la DGII en e-CF: cómo diagnosticarlos y corregirlos desde un agente de IA
Los rechazos de la DGII en e-CF tienen causas precisas y acciones correctivas definidas. Esta guía explica el ciclo de vida del documento, los códigos de error más frecuentes y cómo un agente de IA puede diagnosticar y corregir rechazos de forma autónoma.