Suscripción, cobro y factura no son el mismo evento: arquitectura para un SaaS recurrente

El matiz que cambia la arquitectura

“Facturar después del pago” no puede convertirse en una regla técnica absoluta. En Perú, el Reglamento de Comprobantes de Pago establece que, para servicios, el comprobante debe emitirse cuando ocurra primero la culminación del servicio, la percepción total o parcial de la retribución o el vencimiento del plazo pactado.

Por lo tanto, la arquitectura correcta no espera indefinidamente un pago. Debe evaluar el hecho que genera la obligación de emitir. Si el cobro se confirma antes que cualquier otro supuesto, el pago puede disparar la emisión. Si el vencimiento o la culminación ocurre primero, el sistema debe emitir en ese momento y tratar el pago posterior como cobranza de un documento pendiente.

Esta distinción evita que una preferencia operativa contradiga la obligación tributaria.

1. El pedido define la intención comercial

El pedido conserva cliente, producto, plan, precio, moneda y condiciones aceptadas. No representa todavía cada renovación. Su función es establecer la venta que origina el contrato.

2. El contrato administra la relación recurrente

El contrato de suscripción mantiene vigencia, frecuencia, próxima fecha, estado y reglas de renovación o cancelación. El calendario pertenece al contrato, no a la factura.

SAP Subscription Billing, por ejemplo, separa suscripciones, modelos de precio, ciclos y datos de facturación; además permite definir cargos anticipados o vencidos. Esa separación refuerza que la recurrencia debe modelarse antes de generar documentos contables o fiscales.

3. Cada periodo genera un ciclo de cobro único

El ciclo identifica el periodo que se intenta cobrar. Debe tener una clave estable —por ejemplo, contrato más periodo— para impedir que un reintento cree una segunda obligación.

El ciclo puede pasar por estados como pendiente, en proceso, pagado, rechazado, vencido o conciliado. La máquina de estados hace visible la operación y evita inferirla desde mensajes sueltos del proveedor de pago.

4. La confirmación del proveedor es un evento, no una orden ciega

Los pagos recurrentes son asíncronos. El proveedor puede confirmar, rechazar o reenviar un evento; además, los eventos pueden llegar fuera de orden. La documentación de Stripe recomienda verificar la firma del webhook, manejar cambios de estado y no depender del orden de entrega.

Por eso, el receptor debe aplicar controles explícitos:

• Validar la autenticidad y la firma del evento.
• Registrar su identificador y rechazar duplicados ya procesados.
• Consultar el estado vigente cuando exista ambigüedad.
• Responder rápidamente y ejecutar el trabajo pesado de forma desacoplada.

5. La emisión requiere un orquestador

El orquestador de facturación decide qué acción corresponde según el estado del ciclo y la regla tributaria aplicable. No reemplaza al ERP ni al sistema de emisión electrónica; coordina responsabilidades.

Cuando corresponde emitir, envía al ERP una solicitud idempotente con la referencia única del ciclo. El ERP crea el documento comercial y el registro contable; luego el componente fiscal genera y remite el comprobante electrónico y conserva la respuesta. Si la respuesta se pierde, el sistema consulta por la misma referencia en lugar de generar otro documento.

Riesgos y controles

Los principales fallos no se resuelven con una sola transacción larga, sino con estados recuperables y referencias estables.

• Evento duplicado: identificador único, registro de eventos procesados e idempotencia.
• Eventos fuera de orden: máquina de estados y consulta del estado vigente.
• Pago confirmado con ERP indisponible: cola durable, reintentos y estado pagado pendiente de emisión.
• Respuesta fiscal perdida: consulta por referencia antes de reemitir.
• Vencimiento sin pago: evaluación de la obligación de emisión y creación de la cuenta por cobrar cuando corresponda.
• Diferencia de importe: bloqueo, alerta y conciliación antes de cerrar el periodo.
• Devolución o contracargo: flujo separado de reversión y documento correctivo, sin modificar el ciclo original.

La conciliación es parte del producto

El flujo no termina cuando el proveedor responde “pago aprobado”. Termina cuando coinciden el ciclo de cobro, la transacción del proveedor, el documento del ERP y el comprobante electrónico con su respuesta fiscal.

La conciliación debe detectar pagos huérfanos, ciclos sin documento, documentos rechazados, diferencias de importe y eventos pendientes de reproceso. Sin este cierre, la automatización solo desplaza el trabajo manual hacia el final del mes.

Cómo evaluaría el diseño

El diseño todavía no debe atribuirse resultados no medidos. Su evaluación debe considerar:

• Cero documentos duplicados por reintentos.
• Porcentaje de pagos conciliados automáticamente.
• Tiempo entre confirmación y emisión.
• Ciclos que requieren intervención manual.
• Recuperación después de una caída del ERP o del emisor electrónico.
• Trazabilidad completa desde el pedido hasta el comprobante.

Limitaciones

La arquitectura es conceptual y no prescribe un proveedor de pagos, un producto ERP ni un operador de emisión electrónica. La regla tributaria debe validarse para el tipo de servicio, contrato y jurisdicción específicos. Tampoco presenta métricas de producción: define qué debe medirse antes de afirmar eficiencia o reducción de errores.

Conclusión accionable

Antes de automatizar un cobro recurrente, conviene identificar qué evento crea la obligación comercial, qué hecho confirma el pago, qué regla determina el momento legal de emisión y cómo se demostrará la conciliación entre pago, ERP y comprobante.

Si esas respuestas viven en una sola transacción, el diseño será frágil. Si cada responsabilidad tiene un estado, una referencia y un control, el flujo puede recuperarse sin duplicar dinero ni documentos.

Una suscripción no es una factura programada. Es un sistema de eventos que debe conservar identidad, cumplimiento y trazabilidad de extremo a extremo.