Cobrar un SaaS desde Colombia

Muchos SaaS se concentran en que el cliente pueda ingresar una tarjeta y se olvidan de lo que ocurre 30 días después. Una suscripción necesita reglas para renovación, cancelación, upgrade, downgrade, prorrateo y reactivación. Cuando esas reglas quedan repartidas entre el procesador, una hoja de cálculo y decisiones manuales del equipo, los errores aparecen justo cuando empieza a crecer la base de clientes. Ese ciclo merece una prueba deliberada antes de adquirir tráfico. Simule una renovación normal, otra fallida y una reactivación, y compruebe qué ve el cliente y qué registra su sistema. Si el equipo necesita intervenir manualmente para entender qué ocurrió, todavía existe deuda operativa que crecerá junto con el MRR.

Con 500 clientes de USD 20 mensuales, cinco puntos de fallo en renovaciones representan 25 clientes y USD 500 en riesgo durante el ciclo; el porcentaje real será distinto para cada negocio, pero la lógica no cambia: recuperar pagos fallidos suele costar mucho menos que reemplazar clientes perdidos. Reintentos, actualización del método de pago y comunicaciones de recuperación merecen diseño propio. También conviene separar fallo técnico de churn voluntario. Un cliente que quería seguir pagando pero tuvo una tarjeta vencida no debe analizarse igual que quien decidió cancelar; mezclar ambos casos distorsiona retención y decisiones de producto. Mida recovery rate, tiempo hasta recuperación y pérdida definitiva para saber si el proceso realmente protege ingresos.

Trial, activo, pago vencido, periodo de gracia, cancelado y reactivado son estados distintos. Defina qué puede hacer el usuario en cada uno y qué evento mueve la cuenta al siguiente estado. Separar el estado de la factura del estado de acceso también permite tratar un fallo de pago con criterio, en lugar de bloquear a todos de inmediato. Los estados deben ser pocos, comprensibles y accionables. Cada estado necesita una regla de entrada, una consecuencia para el acceso y una salida prevista; de lo contrario aparecen excepciones manuales que nadie recuerda semanas después. Esa disciplina facilita soporte, reporting y automatización sin convertir el billing en una caja negra.

La infraestructura internacional no borra la facturación, el soporte documental ni el tratamiento tributario que corresponda; el flujo debería dejar claro quién procesa el pago, quién emite documentos al cliente, cómo se registra el ingreso y cómo llega ese movimiento a la contabilidad local. Tecnología y cumplimiento tienen que encontrarse en algún punto verificable. El punto práctico es que cada movimiento financiero pueda explicarse después. Factura, pago, reembolso, crédito, payout y asiento contable deberían compartir identificadores o referencias suficientes para reconciliarse. Cuando esa trazabilidad existe, un problema puede investigarse en minutos; cuando no existe, cada cierre mensual se convierte en reconstrucción manual.

Después del cargo vienen moneda del saldo, conversión, calendario de payout, retenciones, mínimos y banco receptor. Dos soluciones con una comisión parecida pueden producir resultados muy diferentes si una liquida más rápido o convierte en mejores condiciones. Para un SaaS, los días hasta disponibilidad importan porque servidores, nómina y adquisición se pagan con caja, no con ventas aprobadas. Añada una métrica de liquidez al tablero del SaaS. No basta con MRR contratado si parte del saldo todavía no está disponible, está sujeto a reservas o se convertirá antes de llegar al banco. Registrar días promedio hasta caja y costo efectivo de conversión permite comparar proveedores con una medida que refleja operación real.

Contratos con clientes, inversión, socios, personal o presencia real en Estados Unidos pueden justificar una entidad; si el problema es únicamente cobrar suscripciones, abrir una LLC no sustituye billing, dunning, conciliación ni payout. La entidad agrega una capa societaria; no arregla automáticamente la operación recurrente. Si la razón para la LLC es únicamente habilitar una cuenta de pagos, compare el beneficio contra todo el trabajo que seguirá pendiente. Billing, dunning, impuestos, soporte y conciliación no desaparecen por tener una entidad. La estructura societaria solo merece entrar cuando resuelve una necesidad adicional que seguiría siendo válida aunque cambiara el proveedor.

Cree un cliente de prueba y recorra alta, renovación, pago fallido, reintento, cambio de plan, cancelación, reactivación y payout. Documente qué evento ocurre en cada paso y qué sistema toma la decisión. Ese ejercicio suele descubrir más fallas que comparar listas de funcionalidades de proveedores. Documente el resultado de la prueba como si otra persona tuviera que operar el sistema mañana. Incluya eventos, responsables, mensajes al cliente, tiempos y ruta de escalamiento. Ese documento se convierte en una especificación operativa y evita que las decisiones queden escondidas en configuraciones que nadie revisa.