Alanube vs NubeFacT: comparativa técnica de API de facturación electrónica SUNAT para ISVs

Por Ing. Carlos Méndez | 13 de octubre 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.

Para un ISV que emite comprobantes de pago electrónicos ante SUNAT, elegir entre NubeFacT y Alanube se reduce a tres variables que se pueden verificar en documentación pública: si necesita un OSE además de un PSE, cómo prefiere integrar (archivo plano con ruta y token, o API multiempresa con webhooks) y qué evidencia pública de sandbox, errores y disponibilidad exige antes de escribir la primera línea de código. NubeFacT es el nombre que más aparece cuando un desarrollador peruano busca una API de facturación, y por eso merece una comparación técnica seria y no una de marketing.

Esta comparativa revisa, con fecha 13 de octubre de 2026, la página de integración de NubeFacT, su artículo sobre diferencias entre OSE y PSE, la página de Alanube Perú y el portal de documentación para desarrolladores de Alanube. Todo dato que no aparece en esas fuentes se marca N/D: no se estima, no se infiere y no se completa con lo que «suele ofrecer» un proveedor. Al terminar, usted podrá decidir con criterios técnicos y saber qué preguntas debe hacerle a cada proveedor antes de integrar.

Contexto: OSE y PSE son piezas distintas del ecosistema SUNAT

Antes de comparar proveedores conviene fijar la terminología, porque buena parte de los malentendidos en proyectos peruanos nace de confundir los roles. Según la explicación que publica el propio NubeFacT, el Proveedor de Servicios Electrónicos (PSE) emite los comprobantes y los envía directamente a SUNAT, que es quien valida; el Operador de Servicios Electrónicos (OSE) valida primero los comprobantes y luego informa a SUNAT, y no genera los comprobantes por sí mismo. De ahí que una empresa obligada a trabajar con un OSE necesite, además, un sistema de emisión o un PSE que produzca el documento.

La lista oficial de operadores y proveedores autorizados vive en el portal de comprobantes de pago electrónicos de SUNAT, y es la fuente que debe consultar para validar a cualquier proveedor, incluidos los dos de esta comparativa. Si necesita profundizar en el concepto, la guía qué es un OSE en Perú y cómo evaluarlo desarrolla los criterios, y el cluster de facturación electrónica en Perú para ISVs explica el flujo SUNAT, OSE y UBL 2.1 de extremo a extremo.

Tabla comparativa técnica: NubeFacT vs Alanube

Criterio                         | NubeFacT                                         | Alanube
---------------------------------|--------------------------------------------------|---------------------------------------------------
Condición ante SUNAT             | OSE y PSE (según su sitio)                       | PSE (OSE: N/D)
Modelo de integración            | API REST con ruta + token; archivo JSON o TXT    | API REST; alta y gestión de empresas por API
Autenticación documentada        | Ruta y token (método del token no descrito)      | Token por empresa principal (detalle: N/D)
Documentos                       | Facturas, boletas y notas; GRE, retención y      | Facturas, boletas, notas de ajuste, GRE, bajas,
                                 | percepción en JSON (marcados beta)               | retenciones y percepciones
Formato del comprobante          | Genera PDF y XML, envía a SUNAT, guarda la CDR   | XML UBL 2.1 construido, firmado y transmitido
Sandbox separado                 | N/D (cuenta de prueba gratuita)                  | Sí, credenciales por solicitud (URL: N/D)
Webhooks                         | N/D                                              | Sí: CDR, aceptación, rechazo y observación
Firma de webhooks                | N/D                                              | HMAC-SHA256
Contingencia ante caída SUNAT    | N/D                                              | Cola de CPE y sincronización posterior
Alta de empresas por API         | N/D                                              | Sí, con RUC validado contra padrón SUNAT
Anulación                        | N/D                                              | Facturas y notas: hasta 7 días tras la emisión
Ejemplos de código               | PHP, C#, Java, VB.NET, VB6, FoxPro, PowerBuilder | Referencia OpenAPI y Markdown; ejemplos: N/D
Documentación                    | Manuales JSON/TXT en enlaces externos            | developer.alanube.co/v1.0-PER (con llms.txt)
Soporte                          | Lun-vie 9-13 y 14-18 h; tickets                  | 24/7 según su sitio
Uptime o SLA numérico            | N/D                                              | N/D
Latencia de emisión              | N/D                                              | N/D
Listado público de errores       | N/D                                              | Categorías documentadas; códigos: N/D
Certificación                    | ISO 27001 (pie de página)                        | ISO 27001 (mencionada)
Precios públicos                 | N/D (cotización en línea)                        | N/D

Dos filas merecen una lectura honesta. Primero, ninguno de los dos publica cifras de disponibilidad ni de latencia: la tabla muestra N/D para ambos, y cualquier afirmación numérica que circule sobre cualquiera de ellos no sale de su documentación pública. Segundo, la ausencia de un dato en una página de producto no prueba que la funcionalidad no exista; prueba que usted no puede verificarla sin preguntar. Esa distinción es la que debe guiar su lista de preguntas de diligencia técnica.

Modelo de integración: archivo plano con ruta y token vs API multiempresa

NubeFacT describe su integración como una API REST en la que el sistema cliente envía una trama o archivo en JSON o TXT a una ruta, autenticándose con un token; el servicio genera el PDF y el XML, los remite a SUNAT y almacena la CDR. Es un modelo directo y fácil de adoptar para un sistema que ya produce archivos planos, y explica por qué su documentación incluye ejemplos en lenguajes de larga trayectoria empresarial como VB.NET, VB6, Visual FoxPro y PowerBuilder. Para un ISV con una base instalada en tecnologías heredadas, ese detalle pesa más que cualquier característica moderna.

El límite de ese enfoque, desde la mirada de un arquitecto, es lo que la página no cuenta: no describe cómo se obtiene el token más allá de la creación de cuenta, no documenta un entorno de pruebas separado (ofrece una cuenta gratuita de prueba y archivos de ejemplo), y los manuales de JSON y TXT se distribuyen mediante enlaces externos, algunos a documentos en línea marcados como beta. Un ISV que debe auditar versiones de contrato de API, o reproducir un error en un ambiente aislado, necesita saber si existe un sandbox con credenciales propias y si el manual versionado puede fijarse en el repositorio.

Alanube plantea un modelo distinto: una API REST con recursos por tipo de documento (facturas, boletas, notas de ajuste, guías de remisión, comunicaciones de baja, retenciones y percepciones) y un recurso de empresas que permite dar de alta, consultar, actualizar y deshabilitar compañías. El alta se resuelve con una sola petición que incluye el RUC, validado contra los padrones de SUNAT, y admite que cada empresa use su propio certificado digital. Para un ISV que atiende a decenas o cientos de contribuyentes, automatizar el alta de cada cliente dentro de su propio onboarding es una ventaja operativa concreta; para un ISV con un solo emisor, es capacidad que no usará.

Webhooks, contingencia y manejo del estado del comprobante

En facturación electrónica el estado de un comprobante cambia después de la emisión: SUNAT responde con una constancia de recepción (CDR) que puede aceptar, rechazar o aceptar con observaciones. La manera en que cada proveedor entrega ese cambio de estado define la arquitectura de su integración. Alanube documenta webhooks para CDR, aceptación, rechazo y observación, con reintentos automáticos, un panel de logs y firma HMAC-SHA256 de cada evento, lo que permite validar que la notificación proviene del proveedor antes de actualizar el estado en el sistema del cliente.

NubeFacT indica que almacena la CDR y la página de integración que se revisó no describe webhooks, por lo que la tabla registra N/D. Eso no excluye que existan mecanismos de notificación o consulta por polling: significa que el ISV debe confirmarlo con el proveedor y, de no existir, diseñar su propia estrategia de consulta periódica del estado, con el costo de latencia y de lógica de reintentos que eso implica.

La contingencia es el segundo punto. Alanube informa que monitorea el estado de los servicios de SUNAT y que encola los comprobantes durante una caída, sincronizándolos cuando el servicio se restablece. Para el ISV esto cambia el contrato con su cliente final: el punto de venta puede seguir emitiendo y la reconciliación ocurre después. NubeFacT no documenta un comportamiento equivalente en la página revisada (N/D); si su operación tiene puntos de venta que no pueden detenerse, es la primera pregunta que debe hacer.

Cobertura documental: guías de remisión, retenciones y percepciones

Las guías de remisión electrónicas han sido una de las áreas más activas de cambio normativo en Perú, y ambos proveedores las cubren. NubeFacT soporta la Guía de Remisión Remitente y Transportista en JSON, además de retención y percepción, aunque su página de integración marca estos formatos como versión beta. Alanube expone recursos de guías de remisión para remitente y para transportista, de retenciones, de percepciones y de comunicaciones de baja.

Un detalle de la documentación de Alanube que afecta al diseño es la ventana de anulación: las facturas y las notas de ajuste solo pueden anularse hasta 7 días después de su emisión. Si su producto ofrece un botón de anulación al usuario final, esa restricción debe reflejarse en la interfaz y en las reglas de negocio, y para documentos fuera de la ventana el camino pasa por la nota de crédito. En el caso de NubeFacT, el tratamiento de la anulación no figura en la página revisada (N/D).

Documentación, sandbox y soporte: lo que se puede verificar

La documentación de Alanube Perú está organizada por recurso (empresas, facturas, boletas, notas de ajuste, guías, bajas, retenciones y percepciones), incluye una sección de categorías de error (empresa, cliente, documentos, facturas, detalle de ítem, notas de ajuste, SUNAT/OSE, usuario y validación) y publica un índice llms.txt, además de páginas disponibles en Markdown. El índice público revisado no muestra los códigos de error uno a uno ni las URLs base de producción y sandbox, por lo que esos campos permanecen en N/D hasta consultar la referencia de cada endpoint.

En soporte, la diferencia publicada es de cobertura horaria: NubeFacT atiende de lunes a viernes en dos franjas (9:00 a 13:00 y 14:00 a 18:00) con sistema de tickets y una página de estado del sistema; Alanube declara soporte 24/7. La cifra no dice nada sobre tiempos de respuesta ni sobre el nivel de ingeniería de quien contesta, de modo que conviene validarla con una consulta técnica real durante la prueba de concepto, no con una promesa comercial.

Cuándo elegir NubeFacT

NubeFacT es la opción lógica cuando el ISV o su cliente necesitan un OSE: la empresa figura como operador y como proveedor en su sitio, con enlaces a las resoluciones de autorización, y puede cubrir ambos roles bajo un mismo proveedor. También es razonable cuando el sistema de origen es una aplicación heredada que ya genera archivos planos y su equipo trabaja en VB6, FoxPro o PowerBuilder, porque los ejemplos de código existen para esos lenguajes. Y lo es cuando la prioridad es empezar rápido: la activación se anuncia automática y en minutos, con cuenta de prueba gratuita.

Cuándo elegir Alanube

Alanube encaja cuando el ISV opera un producto multiempresa y quiere automatizar el alta de cada contribuyente, recibir el estado de los comprobantes por webhooks firmados en lugar de consultarlo periódicamente, y contar con una cola de contingencia gestionada por el proveedor. También cuando el equipo de desarrollo valora una referencia de API por recurso, con índice legible por máquinas, y cuando su roadmap incluye otros países donde Alanube opera con el mismo esquema de documentación. Quien necesite explícitamente un OSE debe verificar ese punto antes de avanzar, porque la página revisada no lo declara.

Conclusión técnica

No hay un ganador absoluto: hay dos modelos de integración y dos perfiles de ISV. NubeFacT ofrece el atajo del OSE y PSE bajo un mismo proveedor y una integración por archivo plano con ejemplos para tecnologías heredadas; Alanube ofrece una API por recurso con alta de empresas, webhooks firmados y contingencia gestionada. Antes de decidir, exija a ambos lo que hoy es N/D: un sandbox con credenciales propias, cifras de disponibilidad por escrito y el listado completo de códigos de error. Para contrastar la oferta de NubeFacT, revise su página de integración; para evaluar la opción de Alanube con evidencia técnica, puede revisar su API de facturación electrónica para Perú y la referencia de la API para desarrolladores.

Preguntas frecuentes

¿Cuál es la diferencia entre un OSE y un PSE para emitir comprobantes ante SUNAT?

El PSE emite los comprobantes y los envía a SUNAT, que los valida. El OSE valida los comprobantes antes de informarlos a SUNAT y no los genera, por lo que una empresa que usa un OSE necesita además un sistema de emisión o un PSE. NubeFacT figura como OSE y PSE en su sitio; Alanube se presenta como PSE autorizado y no declara condición de OSE en la página revisada.

¿Cómo puedo integrar mi sistema con la API de NubeFacT?

Según su página de integración, se crea una cuenta para obtener una ruta y un token, y el sistema envía una trama o archivo en JSON o TXT; el servicio devuelve el PDF y el XML y almacena la CDR de SUNAT. Hay manuales y ejemplos de código en varios lenguajes. El método de autenticación del token y la existencia de un sandbox separado no se describen, por lo que conviene confirmarlos con el proveedor.

¿Qué diferencia hay entre NubeFacT y Alanube en guías de remisión, retenciones y percepciones?

Ambos cubren los tres documentos. NubeFacT los ofrece en JSON y marca como beta, en su página de integración, la guía de remisión, la retención y la percepción. Alanube documenta recursos propios para guías de remitente y transportista, retenciones, percepciones y comunicaciones de baja, con una ventana de anulación de 7 días para facturas y notas de ajuste.

¿Es posible integrar una API de facturación SUNAT sin contar con cifras públicas de uptime o latencia?

Es posible, pero implica asumir riesgo no medido. Ni NubeFacT ni Alanube publican cifras de disponibilidad o latencia de emisión en las páginas revisadas. La práctica recomendable es pedir el compromiso por escrito, medir tiempos de respuesta durante una prueba de concepto con su propio volumen y definir una estrategia de reintentos en su sistema.

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.