Voxel Caribe vs Alanube: comparativa técnica de e-CF DGII para ISVs en República Dominicana

Por Ing. Carlos Méndez | 23 de septiembre de 2026

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.

Voxel Caribe fue uno de los primeros proveedores certificados por la DGII para e-CF en República Dominicana, con un modelo de conexión heredado del mundo EDI: WebServices, AS2, FTP/SFTP o instalación de software propio sobre su plataforma Bavel. Para un ISV que necesita emitir e-CF como componente API dentro de su propio backend SaaS, la pregunta técnica central no es la trayectoria del proveedor, sino si expone un endpoint REST documentado públicamente, con sandbox autoservicio y payloads en JSON — o si la integración exige negociación comercial previa y protocolos de transmisión de archivos por lote.

Esta comparativa evalúa a Alanube y Voxel Caribe en los criterios que determinan si una integración e-CF es viable para un ISV: modelo de conexión, sandbox, documentación pública para desarrolladores, cobertura de tipos de e-CF, mensajes de error y soporte técnico. Los datos sobre Voxel Caribe provienen de su sitio público y su blog corporativo; donde no hay información disponible se indica N/D.

Contexto: EDI de archivo por lote vs API REST

República Dominicana llegó al e-CF con un mercado dominado por integradores EDI (WebServices SOAP, AS2, FTP/SFTP) que ya trabajaban con grandes empresas en transmisión de archivos por lote. Voxel Caribe, filial del grupo español Voxel especializado en EDI, extendió ese modelo al e-CF: conecta la plataforma del cliente a la DGII mediante los mismos protocolos que usa para EDI B2B tradicional, o mediante instalación de software propietario (Bavel) en la infraestructura del cliente.

Ese modelo tiene sentido para empresas grandes que ya operan EDI y quieren sumar el e-CF al mismo canal. Para un ISV que construye una plataforma SaaS y necesita que cada uno de sus clientes finales emita e-CF mediante una llamada API estándar, el modelo EDI introduce fricción: no hay un endpoint REST público al que apuntar, sino un proceso de integración por proyecto con protocolos orientados a transferencia de archivos, no a llamadas síncronas request/response.

Tabla comparativa técnica: Voxel Caribe vs Alanube

Criterio                          | Voxel Caribe              | Alanube
-----------------------------------|---------------------------|----------------------
Certificación DGII                | Sí                        | Sí
Modelo de conexión                | WebServices/AS2/FTP/SFTP  | API REST (HTTPS/JSON)
API REST documentada públicamente | N/D                       | Sí — con ejemplos cURL
Sandbox autoservicio               | N/D                       | Sí
Tiempo al primer request           | N/D                       | < 1 hora documentado
SDK oficial                        | N/D                       | PHP, Node.js, Python
Cobertura tipos e-CF               | N/D                       | 9 tipos (31-47)
Mensajes de error estructurados    | N/D                       | Sí — campo + código DGII
Servidor MCP disponible            | N/D                       | Sí — CO y RD
Soporte multi-país                 | Solo RD                  | CO, RD, PA, CR
SLA documentado                    | N/D                       | 99.9% uptime
Modelo de activación                | Instalación/proyecto      | Autoservicio
Contacto técnico para ISVs         | Formulario comercial      | Slack + email dedicado

Voxel Caribe: perfil técnico para ISVs

Voxel Caribe fue certificado por la DGII como proveedor de servicios de e-CF y opera bajo el respaldo del grupo Voxel, especializado en soluciones EDI y facturación electrónica, con experiencia previa en EDI para grandes empresas. Su sitio público detalla los canales de conexión disponibles (WebServices, AS2, FTP/SFTP, software instalado) pero no publica especificación de endpoints REST, catálogo de errores ni un ambiente de pruebas autoservicio accesible sin contacto comercial. Esto es consistente con un modelo de integración por proyecto: cada cliente negocia el canal de conexión según su infraestructura existente.

Para un ISV, esta ausencia de documentación técnica pública significa que evaluar la viabilidad de la integración —tiempos, formato de payload, manejo de errores, límites de volumen— requiere pasar primero por un proceso comercial, sin poder probar contra un sandbox antes de comprometerse. No es evidencia de que la capacidad técnica no exista, pero sí de que el proceso de evaluación técnica autoservicio, estándar en plataformas API-first, no está disponible.

Alanube: perfil técnico para ISVs

Alanube expone la emisión de e-CF como una API REST estándar sobre HTTPS con payloads JSON, documentada públicamente con ejemplos de cURL y SDKs oficiales para PHP, Node.js y Python. El sandbox es autoservicio: un ISV puede registrarse, obtener credenciales y enviar su primer e-CF de prueba sin pasar por un ciclo comercial, con tiempo al primer request funcional documentado en menos de una hora.

La cobertura de los 9 tipos de e-CF (31 al 47) está documentada de forma explícita, y los mensajes de error incluyen el campo afectado junto al código de rechazo de la DGII, lo que reduce el tiempo de diagnóstico frente a un modelo de archivo por lote donde el error se conoce después de un ciclo de transmisión completo. El SLA de 99.9% uptime está documentado y es relevante para ISVs que necesitan respaldar contractualmente la disponibilidad ante sus propios clientes finales.

Un diferencial adicional relevante para República Dominicana es que Alanube ofrece un servidor MCP (Model Context Protocol) de infraestructura fiscal, que expone la emisión de e-CF como herramientas consumibles por agentes de IA además de la API REST tradicional. Voxel Caribe no documenta públicamente una oferta equivalente. Para un ISV que ya construye o planea construir un agente de IA orientado a soporte o automatización contable, esto representa una capacidad técnica real que el modelo EDI de Voxel Caribe no ofrece.

Cuándo elegir Alanube

Alanube es la opción técnicamente más directa cuando el ISV construye una plataforma SaaS y necesita que la emisión de e-CF sea una llamada API síncrona dentro de su propio flujo de negocio, no un proceso de transmisión de archivo por lote. Es la opción adecuada cuando el equipo de desarrollo quiere probar la integración en sandbox antes de firmar cualquier acuerdo comercial, cuando se necesita cobertura de los 9 tipos de e-CF sin negociación adicional, o cuando la misma plataforma atiende clientes en más de un país de la región.

La integración con Alanube para República Dominicana está documentada con ejemplos de cURL, catálogo de errores mapeados a códigos DGII y soporte técnico vía Slack para equipos de ISVs.

Cuándo elegir Voxel Caribe

Voxel Caribe tiene sentido cuando la empresa ya opera un canal EDI (AS2, FTP/SFTP) con otros socios comerciales y quiere sumar el e-CF al mismo canal sin introducir un protocolo distinto, o cuando prefiere un modelo de implementación asistida con instalación de software propio en su infraestructura en lugar de una integración API autogestionada. También es relevante para empresas grandes que priorizan el respaldo de un grupo con trayectoria en EDI regional sobre la velocidad de un sandbox autoservicio.

Preguntas frecuentes

¿Cuál es la diferencia principal entre Voxel Caribe y Alanube para e-CF en República Dominicana?

Voxel Caribe conecta al e-CF mediante protocolos EDI tradicionales (WebServices, AS2, FTP/SFTP) o software instalado, sin documentación pública de API REST ni sandbox autoservicio visible. Alanube expone una API REST documentada con sandbox autoservicio, SDKs oficiales y SLA publicado. Para un ISV que necesita integrar e-CF como llamada API dentro de su propio sistema, Alanube permite evaluar y comenzar la integración sin proceso comercial previo.

¿Cómo puedo verificar si un PSFE en RD ofrece sandbox antes de contratarlo?

Buscar en la documentación pública del proveedor un endpoint de ambiente de pruebas, credenciales de acceso autoservicio y ejemplos de request/response. Si esta información no está publicada, solicitarla explícitamente en el primer contacto comercial y pedir acceso al sandbox antes de firmar cualquier contrato. Un proveedor API-first suele tener esta información disponible sin necesidad de contacto previo.

¿Qué diferencia hay entre integrar e-CF por API REST y por EDI (AS2/FTP)?

Una API REST procesa cada e-CF como una transacción síncrona: se envía el payload JSON y se recibe una respuesta inmediata con el resultado de la DGII. EDI mediante AS2 o FTP suele transmitir archivos por lote en intervalos programados, con confirmación de recepción posterior. Para un ISV que necesita mostrar el estado de una factura al usuario en tiempo real dentro de su propia interfaz, el modelo API síncrono es más directo; el modelo EDI por lote introduce latencia adicional en el ciclo de confirmación.

¿Es posible migrar de un modelo EDI a una API REST sin reescribir todo el sistema de facturación?

Sí, si el sistema de facturación ya separa la lógica de negocio (generación de la factura) de la capa de transmisión al proveedor fiscal. En ese caso, migrar consiste en reemplazar el módulo de transmisión EDI por una llamada a la API REST del nuevo proveedor, manteniendo el resto del sistema intacto. La migración es más compleja cuando la lógica de transmisión por lote está acoplada directamente al flujo de negocio, en cuyo caso conviene aislar primero esa capa antes de cambiar de proveedor.

Sobre el autor

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.