Qué es un OSE en Perú y cómo evaluarlo técnicamente

Un ISV que está diseñando su integración de facturación para Perú tiene que tomar una decisión arquitectónica temprana que no existe en otros países de la región: qué OSE usar. A diferencia de Colombia, donde el Proveedor Tecnológico ya incluye la validación fiscal, en Perú la plataforma del ISV (PSE) y el validador (OSE) son dos capas separadas. Elegir mal el OSE es elegir mal la disponibilidad y los errores que verá en producción.

Esta guía explica qué es un OSE, cómo obtiene su acreditación ante SUNAT, qué criterios técnicos usar para evaluarlo y cómo estructurar la lógica de fallback cuando el OSE no está disponible.

Qué es un OSE y cómo obtiene su acreditación

Un Operador de Servicios Electrónicos (OSE) es una entidad privada autorizada por SUNAT mediante Resolución de Superintendencia para recibir, validar y registrar comprobantes de pago electrónicos. La acreditación implica que el OSE ha demostrado ante SUNAT capacidad técnica, infraestructura de seguridad y continuidad operativa. El listado oficial de OSEs acreditados está publicado en el portal de SUNAT y debe consultarse antes de seleccionar uno, ya que las acreditaciones pueden suspenderse.

Qué valida el OSE antes de emitir el CDR

El OSE ejecuta tres tipos de validación antes de devolver el CDR. Validación estructural: el XML cumple el esquema XSD definido por SUNAT para el tipo de comprobante. Validación de firma: el bloque XAdES-BES es válido y el certificado no está revocado. Validación fiscal: los datos del emisor corresponden al RUC activo en SUNAT, los cálculos de IGV y totales son correctos, y no existe un comprobante con el mismo número de serie previamente registrado. Si alguna validación falla, el CDR devuelve estado Rechazado con el código de error correspondiente.

Criterios técnicos para evaluar un OSE

Disponibilidad documentada: el OSE debe publicar o proveer contractualmente un SLA de disponibilidad. Sin ese número, no hay forma de estimar el impacto de las caídas en el servicio del ISV. Latencia del CDR: el tiempo entre el envío del XML y la recepción del CDR es crítico para ISVs que emiten comprobantes en flujos síncronos (punto de venta, checkout de e-commerce). Un CDR en menos de 2 segundos es el estándar esperado para integraciones de alto volumen.

Checklist de evaluación antes de integrar

Verificar: (1) el OSE aparece en el listado vigente de SUNAT con acreditación activa; (2) tiene sandbox disponible sin requerir contacto con ventas; (3) el sandbox devuelve CDRs reales con firma válida del OSE, no simulaciones; (4) documenta los códigos de error del CDR con descripción y acción correctiva; (5) expone un endpoint de estado de servicio o status page pública; (6) el contrato incluye SLA de disponibilidad con penalización; (7) tiene canal de soporte técnico separado del canal comercial.

Protocolo de integración con el OSE

La mayoría de OSEs exponen un web service SOAP con el método sendBill para comprobantes individuales y sendSummary para resúmenes de boletas (SummaryDocuments). El ISV envía el XML firmado empaquetado en un archivo ZIP nombrado con el formato: RUC-TipoDoc-Serie-Correlativo.xml, comprimido en RUC-TipoDoc-Serie-Correlativo.zip. El OSE responde con el ticket del CDR (para operaciones asíncronas) o con el CDR directamente (para sendBill síncrono).

Nomenclatura de archivos para el OSE

La convención de nombres es: 20123456789-01-F001-00000001.zip para una Factura (tipo 01) con RUC 20123456789, serie F001 y correlativo 1. Para Boleta de Venta: 20123456789-03-B001-00000001.zip. Para Resumen de Boletas: 20123456789-RC-20260901-1.zip (RC = Resumen Comunicación, fecha de referencia, correlativo del resumen). Un archivo mal nombrado es rechazado por el OSE antes de procesar el XML.

Fallback a SUNAT: cuándo y cómo implementarlo

SUNAT exige que el PSE tenga implementado el canal directo como contingencia. El ISV debe detectar automáticamente cuando el OSE no responde dentro de un timeout configurado y redirigir el comprobante al endpoint directo de SUNAT. Los comprobantes enviados al canal de contingencia deben ser informados a SUNAT mediante el proceso de Comunicación de Baja si luego no son válidos, y el ISV debe reconciliar los estados una vez el OSE recupere disponibilidad.

Preguntas frecuentes

¿Cuál es la diferencia entre un CDR con estado Observado y uno Rechazado?

Un CDR con estado Aceptado (ResponseCode 0) significa que el comprobante es válido y está registrado ante SUNAT. Un CDR Observado significa que el comprobante fue aceptado pero con advertencias no bloqueantes, como inconsistencias menores en datos del receptor que no afectan el crédito fiscal. Un CDR Rechazado significa que el comprobante no fue aceptado y el número de serie queda disponible para reuso: el PSE debe corregir el error y re-emitir el comprobante con el mismo número o con uno nuevo.

¿Cómo puedo verificar si un OSE está vigente antes de contratar?

Consultar el listado oficial en el portal de SUNAT antes de integrar. El estado del OSE debe ser Vigente o Acreditado, no Suspendido ni en proceso. La lista se actualiza cuando SUNAT otorga o revoca acreditaciones, por lo que conviene verificarla al momento del diseño de la integración y nuevamente antes del despliegue a producción.

¿Qué diferencia hay entre sendBill y sendSummary en el protocolo del OSE?

sendBill se usa para comprobantes individuales que requieren respuesta síncrona: Facturas, Notas de Crédito y Notas de Débito. El OSE responde con el CDR en la misma llamada. sendSummary se usa para envíar resúmenes diarios de Boletas de Venta (SummaryDocuments) y Comunicaciones de Baja. En este caso el OSE responde con un ticket numérico y el PSE debe hacer polling con getStatus para obtener el CDR una vez que el OSE procesa el lote, lo cual puede tomar entre segundos y varios minutos.

¿Es posible cambiar de OSE sin afectar los comprobantes ya emitidos?

Sí. Los comprobantes ya validados por un OSE tienen su CDR almacenado y están registrados en SUNAT de forma permanente. Cambiar de OSE no afecta los documentos históricos. Para los nuevos comprobantes, el PSE simplemente apunta a los endpoints del nuevo OSE. La migración debe planificarse con un período de traslape en sandbox para verificar que el nuevo OSE valida correctamente los mismos tipos de comprobante antes de cambiar el tráfico de producción.

Para el contexto completo del modelo de facturación electrónica en Perú, ver la guía principal sobre SUNAT, OSE y UBL 2.1 para ISVs.