PSFE en República Dominicana: Qué Es y Criterios para Elegir el Mejor
Un PSFE (Proveedor de Servicios de Facturación Electrónica) es la entidad certificada por la DGII que provee la infraestructura para emitir e-CF en República Dominicana.
El PSFE es la pieza central de cualquier integración de facturación electrónica en República Dominicana, y la elección del PSFE adecuado condiciona la operación contable de una empresa durante años. Cambiar de PSFE después de adoptarlo no es imposible pero tiene fricciones: rangos de numeración, mensajes pendientes, ajustes en sistemas conectados. Por eso vale la pena tomar la decisión inicial con un marco analítico que combine criterios técnicos, comerciales y normativos.
Esta guía explica qué es exactamente un PSFE en el marco normativo dominicano, qué responsabilidades asume frente a la DGII y frente al cliente, qué criterios objetivos conviene aplicar para evaluar candidatos, y qué señales de alarma indican que un PSFE puede no servir para el escenario específico de la empresa.
Qué es un PSFE en República Dominicana
Definición normativa
El PSFE (Proveedor de Servicios de Facturación Electrónica) es la persona jurídica habilitada por la DGII para prestar servicios de generación, transmisión, validación y entrega de los e-CF a uno o varios contribuyentes facturadores. La figura está desarrollada en la Norma General 06-2018 y sus modificaciones. Se distingue del facturador electrónico (la empresa que emite los e-CF) en que el PSFE presta el servicio técnico a uno o varios facturadores que delegan en él la operación electrónica.
Responsabilidades del PSFE frente a la DGII
El PSFE habilitado responde ante la DGII por la correcta operación técnica del servicio: cumplimiento del esquema vigente, disponibilidad del endpoint hacia la entidad, integridad de los documentos transmitidos, conservación de la información por los plazos legales. Esa responsabilidad coexiste con la del facturador, pero el PSFE mantiene compromisos propios que pueden derivar en revocación de su habilitación si incumple los términos.
Criterios técnicos de evaluación
Estilo de API y calidad de documentación
Un PSFE moderno expone API REST sobre JSON con autenticación por bearer token, documentación OpenAPI navegable, SDKs oficiales por lenguaje, y ejemplos embebidos. PSFEs clásicos pueden operar con SOAP, archivos planos o EDI — válidos legalmente pero con curva de aprendizaje significativamente mayor. Para el equipo de ingeniería, esa diferencia se traduce en semanas o meses de tiempo de integración inicial.
Sandbox real conectado a DGII
Un sandbox real envía las pruebas al ambiente de pre-producción de la DGII y devuelve respuestas reales del validador oficial. Un sandbox mock simula la respuesta sin pasar por la DGII. Para validar realmente la integración antes de producción, el sandbox real es la única opción confiable. Conviene preguntar explícitamente al PSFE cuál de los dos ofrece, porque algunas plataformas usan mock para su quickstart y eso genera falsos positivos al validar.
Webhooks y manejo asincrónico
La DGII opera asincrónicamente: el resultado de la validación llega después del acuse de recibo. Un PSFE moderno absorbe ese asincronismo del lado del servidor y notifica al cliente con webhooks cuando el resultado está disponible. Un PSFE menos maduro deja al cliente la tarea de polling contra la DGII, lo cual añade complejidad significativa. Webhooks con firma HMAC y reintentos automáticos son lo mínimo esperable.
Criterios comerciales y operativos
Modelo de precios
Los modelos más habituales son tarifa por e-CF con escalones por volumen, tarifa plana mensual con tope de documentos incluidos, o esquema mixto. La transparencia del precio importa tanto como el precio mismo: PSFEs que publican tarifas indicativas facilitan la decisión inicial, mientras los que operan con cotización personalizada requieren contacto comercial antes de conocer el costo. Para volúmenes pequeños la transparencia ayuda; para volúmenes grandes la cotización personalizada suele dar mejores condiciones.
SLA y soporte técnico
El SLA contractual de uptime típico de PSFEs maduros está entre el 99.5% y 99.9%. Más importante que el número es el mecanismo de medición y la compensación por incumplimiento. El soporte técnico debe ser accesible en horarios laborales como mínimo; 24/7 es deseable para volúmenes altos. Una status page pública con histórico de incidencias es señal de madurez operativa.
Cobertura multi-país
Si la empresa proyecta operar en más de un país LATAM, un PSFE con cobertura multi-país unificada evita mantener integraciones separadas. Algunos PSFEs (Alanube por ejemplo) cubren RD, Colombia, Costa Rica y Panamá desde una sola API; otros operan exclusivamente en RD. La decisión debe considerar el horizonte de expansión del negocio, no solo la operación actual.
Criterios legales y de cumplimiento
Habilitación vigente ante la DGII
La verificación más básica: que el PSFE figure como habilitado en el listado oficial DGII al momento de la decisión. La habilitación puede perderse — raramente, pero ocurre — por incumplimiento del PSFE. Un PSFE no habilitado o con habilitación suspendida no puede transmitir documentos válidos, lo cual pondría en riesgo toda la facturación del cliente. La verificación es pública y se consulta en el portal de la DGII.
Certificaciones de seguridad
Para empresas reguladas por sectores específicos (financiero, salud, público) o con clientes enterprise que exigen due diligence, las certificaciones de seguridad del PSFE (ISO 27001, SOC 2 Type II) son requisito de contrato. Para empresas no reguladas, son señal de madurez operativa pero no estrictamente obligatorias. Conviene confirmar la vigencia y el alcance de la certificación: algunas cubren solo partes específicas del producto.
Tratamiento de datos personales
Los e-CF contienen datos personales del receptor (RNC, razón social, dirección). El PSFE como encargado del tratamiento debe cumplir la normativa dominicana sobre protección de datos personales. El contrato debe documentar el rol del PSFE como encargado y las medidas de seguridad aplicadas. Para empresas con flujos transfronterizos, conviene verificar también compromisos sobre transferencia internacional de datos.
Señales de alarma frecuentes
Documentación pública desactualizada
Cuando la documentación pública del PSFE muestra versiones antiguas del esquema DGII, ejemplos con campos obsoletos o referencias a normas derogadas, es indicio de que el PSFE puede no estar actualizado al ritmo de la DGII. En un área regulatoria como facturación electrónica, ese desfase se traduce en rechazos en producción y trabajo no previsto de remediación.
Ausencia de status page o histórico de incidentes
PSFEs operativamente maduros publican incidentes en una status page con detalle. La ausencia total de información pública sobre incidentes no significa que el servicio sea perfecto: significa que la transparencia operativa es limitada y diagnosticar incidentes propios puede ser más difícil cuando ocurran.
Contratos sin cláusulas de portabilidad
Contratos que dificultan exportar los datos históricos o que penalizan económicamente la migración a otro PSFE son una señal de alarma. Aunque la historia legal de los e-CF está en el repositorio público DGII, los metadatos operativos (configuraciones, conexiones, customizaciones) suelen quedar en el PSFE. Garantizar contractualmente la portabilidad protege a la empresa frente a aumentos de precio o degradación del servicio.
Preguntas frecuentes
¿Cuál es la diferencia entre PSFE y software de facturación propio? Un PSFE es una empresa habilitada por la DGII que presta el servicio técnico de facturación electrónica a otros. Software propio significa que la empresa misma desarrolla y opera todo el stack técnico, incluyendo la integración directa con los endpoints de la DGII. Para que el software propio sea válido, debe estar registrado en el portal de la DGII con su certificado y cumplir el esquema vigente. Software propio es viable pero implica mantener equipo técnico especializado en facturación DGII, lo cual rara vez es eficiente fuera de empresas con volúmenes muy altos o requisitos personalizados extremos.
¿Cómo puede verificarse que un PSFE está efectivamente habilitado por la DGII? La DGII mantiene listado público de PSFEs habilitados, consultable desde su portal oficial. La consulta requiere el RNC del PSFE o su nombre comercial. El listado muestra el estado de la habilitación (vigente, suspendida, cancelada). Antes de firmar contrato, conviene verificar la habilitación en el listado oficial y solicitar al PSFE copia del acto administrativo que la otorga. PSFEs legítimos exponen esa información proactivamente en su sitio web.
¿Qué diferencia hay entre PSFE en RD y figuras análogas en otros países LATAM? PSFE (Proveedor de Servicios de Facturación Electrónica) es la figura jurídica dominicana definida por la DGII. En otros países LATAM existen figuras análogas con nombres distintos: PT (Proveedor Tecnológico) en Colombia, PAC (Proveedor Autorizado de Certificación) en Panamá y México, y operadores con denominaciones específicas en cada jurisdicción. Funcionalmente son equivalentes — todos median entre el emisor y la autoridad fiscal del país — pero las habilitaciones son separadas: un PSFE habilitado en RD no automáticamente opera en otros países, salvo que ese mismo proveedor haya tramitado habilitación en cada jurisdicción.
¿Es posible cambiar de PSFE sin notificación previa a la DGII? La DGII debe ser notificada del cambio de PSFE mediante actualización del registro del software emisor del cliente. El nuevo PSFE debe ser informado, los rangos de numeración autorizados se redefinen, y la entidad ajusta sus registros internos. El cambio en sí no requiere autorización previa de la DGII (no es proceso aprobativo) pero sí una comunicación formal. Operativamente, el cambio debe coordinarse para evitar superposición de rangos o documentos en tránsito que queden huérfanos entre el PSFE saliente y el entrante.
Artículos Relacionados
Checklist de go-live e-CF en República Dominicana: de staging a producción DGII
Checklist completo para pasar una integración e-CF de staging a producción DGII en República Dominicana: homologación, certificados, pruebas de carga y monitoreo post-lanzamiento.
Webhooks y respuestas asíncronas en la integración e-CF DGII República Dominicana
Cómo diseñar el manejo de respuestas asíncronas de la DGII en la integración e-CF: webhooks, polling de estado, colas de trabajo y gestión de errores de red en República Dominicana.
Autenticación en la API DGII para e-CF: OAuth2, tokens y certificados en República Dominicana
Cómo implementar correctamente la autenticación en la API DGII para e-CF en República Dominicana: OAuth2, gestión de tokens, certificados digitales y errores de autenticación frecuentes.