Software a medida e integración SUNAT (CPE, PLE, SIRE)

El CPE es la representación digital de la factura, boleta de venta y notas de crédito y débito, con la misma validez tributaria que el papel. SUNAT los administra desde su portal de comprobantes de pago electrónicos, donde están las especificaciones técnicas, los ambientes de prueba y la normativa legal vigente. Emiso o no según tu régimen y tu calidad de agente de retención; si emites, el XML ya no es opcional desde hace años.

Para un software a medida, “emitir CPE” significa un flujo técnico concreto: armar el XML con la estructura oficial, firmarlo con certificado digital, enviarlo a la infraestructura de SUNAT (a través de un Operador de Servicios Electrónicos o directamente), recibir la Constancia de Recepción (CSR) y la CLIR/CDR con la respuesta del operador, y guardar todo para fiscalización. Eso último —guardar para fiscalización— es la parte que los proyectos livianos olvidan y los auditores recuerdan.

Si vienes de un Excel o de un ERP viejo, el primer inventario no es de pantallas: es de comprobantes. Qué emites hoy, a qué ritmo, con qué impuestos y quién es tu proveedor de facturación. El software nuevo habla con ese proveedor; no reinventamos el certificado digital ni el PSE.

Son tres capas distintas del mismo sistema electrónico, y confundirlas es la fuente número uno de cotizaciones mal estimadas. El CPE es el comprobante de una operación. El PLE (Programa de Libros Electrónicos) es el libro donde esos comprobantes se registran y se remiten mensualmente a SUNAT. El SIRE (Sistema Integrado de Registros Electrónicos) es la evolución: una plataforma que registra de forma dinámica las ventas y compras, alimentada por información de los propios comprobantes, y con plazos de envío definidos en el reglamento del SIRE.

La consecuencia para tu software cambia radicalmente por capa. Con CPE, integras emisión por operación. Con PLE, integras conciliación y remesa mensual con sus tablas de errores. Con SIRE, la obligatoriedad ya no es un archivo que tú armas a tu ritmo: SUNAT te muestra lo que le llegó de tus comprobantes y de los de tus proveedores, y tú corroboras, corriges o completas. Tu sistema pasa de “reportar” a “reconciliar contra una verdad externa”, que es ingenierilmente más difícil.

El camino corto: no construyas el motor de emisión desde cero. El camino profesional tiene seis pasos, y su orden es parte del resultado:

Cada paso tiene su riesgo propio, y el tercero es donde más proyectos se duermen: un contrato PSE/OSE con velocidad de emisión limitada te puede caer caro en campaña. Si tu caso es solo “conectar un facturador” al e-commerce, el alcance es un proyecto de integración —no un ERP entero— y debe cotizarse como tal.

¿Quién hace qué en este camino? Regla sana: el proveedor del servicio de emisión pone la infraestructura certificada y el contacto con SUNAT; tu software pone el dato de negocio correcto —cliente, monto, impuestos, serie—; y tu contador pone el criterio tributario. Los proyectos que mezclan esos roles, con un facturador opinando de contabilidad o un contador opinando de APIs, son los que acumulan rechazos sin dueño.

• 1. Inventario de comprobantes y casos: qué emites, con qué impuestos, a qué volumen diario.
• 2. Elección del camino de emisión: proveedor comercial (PSE/OSE), APIs de tu facturador actual, o el módulo gratuito de SUNAT para volúmenes bajos.
• 3. Mapeo de catálogo e impuestos: tu SKU contra el código SUNAT, IGV, ISC, detracciones, exoneradas.
• 4. Pruebas en ambiente de homologación de tu operador, no contra producción a las 11 pm.
• 5. Producción con monitoreo: colas de reintentos, alertas por CDR rechazados y plan para emisión en contingencia.
• 6. Reconciliación mensual con PLE o SIRE, con el contador como dueño del criterio tributario.

Los errores caros no son XML mal formado —eso lo bota el validador antes—; son errores de diseño del flujo. El clásico: el e-commerce confirma el pedido, cobra con tarjeta, y la emisión del comprobante falla veinte segundos después “por un problema interno”. Ya le dijiste al cliente que su compra está lista; ahora tienes una venta sin comprobante y una pila de tickets.

Por eso el orden de estados tiene que ser explícito en el diseño: pedido → pago → emisión aceptada → stock descontado → confirmación al cliente. La emisión va antes de la promesa. Y el stock, si es crítico, se reserva antes del pago y se libera si el CDR llega rechazado. Todo lo que no esté escrito así en el alcance, va a pasar.

• Confirmar el pedido antes de recibir el CDR favorable del operador.
• Descontar stock cuando el comprobante todavía puede rechazarse.
• No reintentar con idempotencia: duplicar comprobantes cuando SUNAT o el operador devuelven timeout.
• Ignorar la CAU (constancia de estado de la recepción) y descubrir el rechazo una semana después.
• Guardar solo el PDF bonito y no el XML + CDR firmados, que es lo que fiscaliza SUNAT.
• Olvidar notas de crédito automáticas cuando hay anulación o devolución, y pelearte con el PLE en el cierre del mes.

La integración no se paga como “un módulo más”: se paga por flujo validado. Estos son rangos referenciales de Bytes en soles para trabajo de integración técnica, sin contar la suscripción de tu proveedor de emisión (un contrato aparte que suele medirse en decenas de soles al mes según volumen).

El número sube con los casos especiales: detracciones, operaciones con moneda extranjera, guías de remisión, retenciones de agente, multi-empresa con distintos RUC. Todos son válidos y frecuentes en mediana empresa peruana; ninguno es “chiquito” cuando hay que probarlo.

No existe una “homologación del software” como tal para el régimen general. Lo que existe es un sistema de emisión autorizado: un PSE (Proveedor de Servicios Electrónicos), un OSE (Operador de Servicios Electrónicos, registrado y vigilado por SUNAT), o el módulo de emisión gratuita del portal del CPE para volúmenes bajos y medianos. Tu software pasa por encima de alguno de esos caminos; lo que homologas son tus comprobantes contra los servicios del operador, en sus ambientes de prueba.

Con eso claro, la pregunta que sí debes hacerle a tu proveedor técnico es: ¿quién sostiene la operación cuando el operador cambia sus endpoints o la normativa saca un nuevo campo obligatorio? La respuesta decente es monitoreo, actualizaciones incluidas y un contrato de soporte; la respuesta peligrosa es “eso ya funciona así”.

Y para ser honestos con tu contador: Bytes integra el flujo técnico y deja la parametrización tributaria en sus manos. No somos estudio contable, y un software que factura bien no reemplaza un criterio tributario bien tomado.