Los dolores de construir tu propio sistema de facturación

Artículo original ↗ Discusión en Hacker News ↗

Construir tu propio sistema de facturación para una empresa SaaS o en línea a menudo parece sencillo, pero rápidamente se vuelve complejo por impuestos, prorrateos, reembolsos, derechos de uso, cumplimiento legal, reglas de redondeo e integración con contabilidad y procesadores de pago. Muchos ingenieros que lo han hecho advierten que desvía mucho tiempo y riesgo del trabajo sobre el producto principal, y defienden plataformas de facturación especializadas o servicios de merchant of record; mientras que una minoría responde que los sistemas internos, limitados e incrementales, pueden ser viables para necesidades simples o de etapas tempranas. Un tema recurrente es el valor de separar la facturación de los derechos de uso y tratar la facturación como un subsistema rigurosamente auditable y guiado por políticas, en lugar de un conjunto de scripts improvisados acoplados a Stripe o APIs similares.

Construir vs comprar para la facturación

  • Hay un fuerte consenso en que la facturación es engañosamente compleja; muchos sostienen que la mayoría de las empresas no debería construir la suya propia y debería usar Stripe/Braintree/Chargebee/Lago/killbill/etc.
  • Punto de vista contrario: para productos sencillos o etapas tempranas puedes empezar en pequeño, construir de forma incremental y aceptar algo de trabajo manual; el consejo demasiado general de “nunca lo construyas” se ve como exagerado.
  • Otra postura: construyes facturación si es central para tu negocio o si operas en lugares donde los principales proveedores no funcionan (por ejemplo, algunas jurisdicciones fuera de EE. UU./UE).

Complejidad y casos límite ocultos

  • El verdadero dolor está en la larga cola: reglas de prorrateo, mejoras/degradaciones, derechos adquiridos, pruebas, acuerdos empresariales personalizados, pagos a afiliados, reembolsos/contracargos y ejecutar todo el flujo “al revés” (créditos, correcciones, devoluciones parciales).
  • Zonas horarias, distintos ciclos de facturación, facturación por adelantado frente a facturación a vencimiento, precios basados en uso, descuentos por niveles y comportamiento de redondeo interactúan de formas no obvias.
  • Muchos relatos de sistemas hechos a medida que causan grandes pérdidas financieras por errores de redondeo, problemas de escalado y lógica frágil de “cinta adhesiva”.

Derechos de uso vs facturación

  • Fuerte respaldo a separar la facturación (dinero, facturas, rev‑rec) de los derechos de uso (lo que el cliente realmente puede usar).
  • Arquitectura sugerida: los derechos de uso almacenan capacidades/límites; la facturación calcula los cargos; una capa de política separada los conecta y admite casos puntuales y ajustes manuales.
  • Debate sobre usar feature flags para los derechos de uso: cómodo y flexible, pero corre el riesgo de sobrecargar un solo sistema; algunos prefieren servicios dedicados de derechos de uso/autorización.

Seguridad, cumplimiento y regulación

  • Discusión sobre la idea de “volcar un archivo en S3 + cron”: se considera ingenua, pero técnicamente puede hacerse robusta; el cifrado en tránsito/en reposo es estándar, pero puede no satisfacer modelos de amenaza más estrictos.
  • Algunos sostienen que solo el cifrado del lado del cliente con claves independientes cumple realmente la intención de “cifrado en reposo”.
  • Afirmaciones contradictorias sobre las normas de la UE: varios aclaran que escribir tu propia facturación está permitido; la regulación apunta principalmente al procesamiento de pagos y a los flujos PSD2, no a la facturación interna.

Contabilidad, impuestos y cuestiones legales

  • Integrarse con contabilidad/ERP, el reconocimiento de ingresos, la conciliación de efectivo en tránsito, el cierre de mes/trimestre y la auditabilidad son cargas enormes.
  • El IVA/impuesto sobre ventas, las distintas normas por país, las facturas correctivas, la numeración de documentos y los requisitos de conservación se describen como agotadores pero obligatorios.
  • Los errores pueden llevar a multas o algo peor; debes poder explicar “por qué este cliente pagó esta cantidad”.

Herramientas y plataformas

  • Stripe es elogiado por facilitar los pagos, pero criticado por APIs confusas, abstracciones de alto nivel débiles y lagunas operativas (pérdida de webhooks, sincronización de estado).
  • Se mencionan plataformas de facturación de código abierto y comerciales (por ejemplo, motores OSS genéricos, startups de facturación basada en uso, servicios de merchant of record) como opciones, aunque la opacidad de precios es una queja común.

Patrones de diseño y antipatróns

  • Patrones recomendados: separación clara de responsabilidades (derechos de uso vs libro mayor vs facturación), contabilidad estilo libro mayor, procesos programados en lugar de acoplamiento en tiempo real, operaciones idempotentes, reglas de redondeo configurables.
  • Antipatrones: “blob” monolítico de facturación, acoplar estrechamente los derechos de uso con los pagos, efectos secundarios en tiempo real por todas partes y historiales ingenuos de máquina de estados que no escalan.

Anécdotas y actitudes

  • Las historias incluyen cheques de “dinero mágico” de aseguradoras, conciliación caótica de cuentas por cobrar en sanidad, sistemas de viajes y telecomunicaciones que se volvieron inmantenibles, y una pequeña historia de éxito donde la facturación a medida desbloqueó métodos de pago flexibles.
  • Varios ingenieros con experiencia comparan la facturación con la “fontanería séptica”: desagradable, arriesgada y poco apreciada, pero técnicamente interesante y siempre demandada.