Tus facturas de junio salieron de Stripe Billing y las de julio salen de Orb, y ahora tu contable hace una pregunta que ninguno de los dos sistemas puede responder por sí solo: cuántos ingresos medidos ganaste realmente este trimestre? La plataforma anterior valoró el uso de junio con un conjunto de reglas de agregación, la nueva valora el de julio con otro, y el libro mayor que hay en medio guarda dos meses de periodificaciones de cuentas por cobrar no facturadas que ya no cuadran con nada de lo que informa ninguno de los dos sistemas. Esa brecha — entre eventos de uso, facturas e ingresos reconocidos — es donde las migraciones de plataformas de facturación fallan en silencio. No en la integración de la API, que lleva días, sino en la conciliación, que lleva meses si no la planificas.
Hoy es un problema generalizado. Una encuesta de enero de 2025 a 100 empresas SaaS reveló que el 85 % había adoptado precios por uso, y Stripe informa que el 74 % de los proveedores había adoptado modelos por uso en 2026. En las empresas de IA el cambio es aún más pronunciado: en la encuesta de 2025 de Stripe a directivos de empresas de IA, el 56 % declaró precios híbridos y el 38 % precios puramente por uso. Y el panorama de proveedores sigue moviéndose bajo tus pies — Stripe completó la adquisición de Metronome en enero de 2026 y Adyen completó la de Orb en julio de 2026 — así que incluso quedarte donde estás significa que la hoja de ruta, los precios y las integraciones de tu plataforma pueden cambiar a mitad de contrato. Los fundadores cambian para conseguir métricas definidas en SQL, medición en tiempo real, compromisos y créditos prepagados, o una velocidad de iteración de precios que su plataforma actual no ofrece. El cambio en sí es la parte fácil. Mantener la contabilidad creíble durante el cambio es el verdadero proyecto.
Por qué dos sistemas de facturación nunca coinciden entre sí
Una factura por uso es la salida de un proceso de valoración: entran eventos de uso sin procesar, unas reglas de agregación los convierten en cantidades facturables, la tarifa los valora, y los ajustes (créditos, mínimos, prorrateos, eventos tardíos) producen las líneas finales. Cada plataforma implementa cada etapa de forma ligeramente distinta, y esas diferencias se acumulan.
Las reglas de agregación difieren en los detalles que importan. Una plataforma suma una propiedad tokens en todos los eventos; otra toma el máximo concurrente, el último valor informado o un recuento de valores únicos. Los umbrales gratuitos, los límites de los tramos y el redondeo (por evento frente a por factura) mueven los totales en pequeñas cantidades que parecen ruido hasta que intentas conciliar una factura migrada con el uso que tu producto realmente midió. La única forma fiable de detectar estas diferencias es reinyectar un periodo completo de facturación de eventos sin procesar en el nuevo sistema y comparar la salida valorada con facturas que ya enviaste y sabes que eran correctas.
Los eventos tardíos y corregidos caen en periodos distintos. Los procesos de uso siempre tienen rezagados: eventos que llegan con 24 a 72 horas de retraso, duplicados por reintentos de ingesta, correcciones que tu producto emite a posteriori. Cada plataforma tiene su propio comportamiento de relleno histórico y retroactividad — si un evento tardío reabre un periodo cerrado, si entra como ajuste de regularización en el periodo actual o si se descarta pasado un límite. Durante un mes de migración, el mismo rezagado puede ser contado por un sistema y omitido por el otro, o contado por ambos.
El prorrateo y los límites de periodo son específicos de cada plataforma. Los cambios de plan a mitad de ciclo, las ampliaciones, las regularizaciones de puestos y las fechas de aniversario de facturación se calculan según las reglas de cada sistema. Si mueves un cliente a mitad de ciclo, las dos plataformas pueden repartir el uso del mismo mes en periodos de servicio distintos, y eso importa porque el reconocimiento de ingresos sigue a los periodos de servicio, no a las fechas de factura.
La infraestructura fiscal y de pagos también se mueve. Ni Stripe Billing, ni Orb ni Metronome son proveedores registrados como responsables comerciales: Stripe gestiona los impuestos con el complemento separado Stripe Tax, Orb lo hace mediante integraciones con Avalara o Anrok, y Metronome se apoya en sus integraciones nativas con Stripe. Una migración que cambia cómo se calculan los impuestos o qué pasarela cobra el pago cambia las cuentas de bruto a neto en cada factura, que son exactamente las cuentas que concilia tu cuadre.
La triple conciliación que se rompe: eventos, facturas e ingresos
Según la norma ASC 606, las tarifas por uso son una contraprestación variable, y el ingreso se reconoce en el periodo en que el cliente usa el servicio — no cuando lo facturas. El uso entregado pero aún no facturado al cierre del mes se registra como una cuenta por cobrar no facturada (devengada), incluida solo en la medida en que no se espere una reversión significativa del ingreso una vez resuelta la incertidumbre. En términos llanos, tu contabilidad guarda tres cifras relacionadas cada mes:
- Uso medido — lo que tu producto y la plataforma de facturación coinciden en que el cliente consumió.
- Facturas emitidas — lo que la plataforma realmente cobró, tras valoración, créditos y ajustes.
- Ingresos reconocidos — el uso ganado en el periodo, esté facturado o siga en la cuenta por cobrar no facturada.
En régimen estable estas tres cifras concilian: el ingreso reconocido equivale al uso facturado más la variación de la cuenta por cobrar no facturada. Un cambio de plataforma a mitad de año rompe los tres pilares a la vez. El sistema antiguo deja de emitir facturas pero conserva el único registro de cómo se valoró el uso de junio. El sistema nuevo empieza a emitir facturas valoradas con reglas distintas, así que las facturas de julio no son comparables con las de junio. Y el saldo de la cuenta por cobrar no facturada devengado bajo el régimen anterior tiene que cancelarse con facturas emitidas bajo el nuevo, que no cuadrarán al céntimo. Si no puedes explicar cada diferencia línea por línea, tu auditor tampoco podrá — y «cambiamos de sistema de facturación» es una razón para las diferencias, no un sustituto de conciliarlas.
La guía de migración segura para finanzas
Las migraciones de facturación fallan en la conciliación, no en la integración. Sigue estos pasos en orden y no comprimas la operación en paralelo.
1. Congela los periodos cerrados antes de tocar nada. Bloquea los periodos contables que el sistema antiguo ya facturó, y trata cualquier uso tardío de esos periodos como ajustes de regularización en el siguiente periodo abierto — que es también como lo gestionan de forma nativa las plataformas maduras. Nunca revalores un periodo cerrado en el sistema nuevo ni reexpreses el histórico a menos que estés dispuesto a reemitir facturas y declaraciones fiscales rectificativas a juego.
2. Inyecta los eventos sin procesar en ambos sistemas desde el primer día del cambio. Apunta el flujo de eventos de uso de tu producto a ambas plataformas a la vez, con claves de idempotencia estables (event_id por evento) para que los reintentos de ingesta no cuenten doble. Ambos sistemas deben ver una entrada idéntica; cada diferencia posterior será entonces una diferencia de valoración que puedes investigar, no una diferencia de datos que solo puedes adivinar.
3. Repite un periodo histórico completo y concilia línea por línea. Reinyecta al menos un ciclo completo de facturación de eventos históricos en el sistema nuevo y compara la salida valorada con las facturas que realmente enviaste. Concilia a nivel de línea, no de total de factura: los totales ocultan errores que se compensan — una línea equivocada por arriba y otra por abajo se netean en una diferencia pequeña que supera un control que debería fallar. Apunta a tolerancias estrictas (las guías del sector sugieren en torno al 1 % para medidores de alto volumen y al 0,1 % para eventos críticos de facturación), y registra una causa raíz para cada diferencia antes de la puesta en marcha.
4. Opera un ciclo completo de facturación en paralelo. Ambos sistemas activos, ambos produciendo facturas, solo uno enviándolas. Mantén la plataforma antigua como autoritativa mientras las facturas espejo del sistema nuevo pasan la misma revisión que tus facturas reales. Las guías publicadas tratan la facturación como crítica para los ingresos y sitúan las operaciones en paralelo entre 8 y 16 semanas, no las 2 a 4 semanas de los sistemas no críticos; los plazos de los proveedores que prometen una migración en dos semanas describen la integración, no la aprobación financiera. La propia guía de migración de Orb recomienda mantener a los clientes nuevos en la plataforma nueva durante 60 a 90 días antes de mover la base instalada.
5. Corta a los clientes por oleadas, no de golpe. El patrón más seguro es clientes nuevos en la plataforma nueva mientras los contratos existentes cumplen su ciclo en la antigua, y luego migrar cohortes en fronteras naturales (renovación del contrato, cierre de mes, nunca a mitad de ciclo). Cada oleada se concilia antes de empezar la siguiente. Un corte total concentra cada diferencia de valoración, cada evento rezagado y cada caso límite de prorrateo en un solo cierre — el que tu auditor muestreará primero.
6. Mantén el sistema antiguo en solo lectura, no lo elimines. Necesitas las reglas de valoración antiguas, las facturas antiguas y el registro de eventos antiguo durante al menos un ciclo completo de auditoría. Las administraciones tributarias y los auditores preguntan específicamente por el año de la migración porque esperan la costura; «lo dimos de baja» convierte una diferencia conciliable en una inexplicable.
Cómo se ve el mes del cambio en tu libro mayor
La conexión contable es sencilla una vez que separas las plataformas con cuentas de compensación en lugar de dejar que ambas contabilicen directamente contra ingresos. Devenga cada cierre de mes el uso ganado pero no facturado bajo la plataforma que lo midió, y luego cancela el devengo cuando esa plataforma emita la factura — contabilizando cualquier diferencia de valoración entre ambos sistemas como una regularización explícita, no como un ajuste de relleno.
Supón que el uso de junio se midió en la plataforma antigua y devengaste 4.820 $ de ingresos no facturados al 30 de junio. La plataforma de reemplazo emite la factura real en julio por 4.805,50 $ — una diferencia de valoración de 14,50 $ por el redondeo y un evento tardío que cayó en periodos distintos. En un libro mayor en texto plano eso se ve así:
2026-01-01 open Income:SaaS:Usage
2026-01-01 open Assets:Unbilled-Receivable
2026-01-01 open Assets:Accounts-Receivable
2026-01-01 open Assets:Checking
2026-06-30 * "Accrue June unbilled metered usage (old platform)"
Assets:Unbilled-Receivable 4820.00 USD
Income:SaaS:Usage
2026-07-02 * "Invoice 1042 issued from new platform for June usage"
Assets:Accounts-Receivable 4805.50 USD
Assets:Unbilled-Receivable -4820.00 USD
Income:SaaS:UsageLa segunda transacción se cuadra automáticamente con 14,50 $ contra Income:SaaS:Usage, reduciendo los ingresos reconocidos exactamente en la diferencia de valoración — visible, fechada y explicable en lugar de enterrada. Escala este patrón con subcuentas por plataforma (por ejemplo, Assets:Unbilled-Receivable:Stripe-Billing y Assets:Unbilled-Receivable:Orb) para que el balance de comprobación del mes de migración muestre de qué sistema vino cada dólar. Cuando finanzas puede señalar los saldos de las subcuentas y los asientos de regularización, la pregunta más difícil del auditor — «demuestra que estas dos poblaciones de facturas suman tus ingresos» — ya tiene respuesta. Si sigues métricas de uso junto al libro mayor, la documentación de Beancount sobre cómo consultar tus libros muestra cómo extraer los saldos no facturados por subcuenta al cierre.
Metronome, Orb o simplemente Stripe Billing?
Con el plan de conciliación en la mano, la elección de plataforma se reduce a dónde está realmente tu complejidad:
- Quédate en Stripe Billing si tu modelo de uso son suscripciones medidas sencillas, tus pagos ya corren en Stripe, y tu equipo puede gestionar los impuestos (con el complemento Stripe Tax) y el reconocimiento de ingresos (con su complemento o tu ERP) como piezas separadas. Tras la adquisición, la medición en tiempo real de Metronome está cada vez más disponible dentro del ecosistema de Stripe, lo que estrecha la brecha que antes obligaba a cambiar. El coste ronda el 0,7 % del volumen facturado sobre las tarifas estándar de procesamiento.
- Pásate a Orb si tus precios necesitan métricas definidas en SQL sobre datos de eventos sin procesar — uso multidimensional, lógica de valoración compleja, cambios frecuentes de versiones de precios con migración masiva de clientes entre versiones. Orb reúne medición, facturación e informes de ingresos (vistas de reconocido, diferido y no facturado) en un solo sistema, y sus herramientas de migración importan clientes y suscripciones dejando intactos los registros de clientes y los métodos de pago de Stripe. El precio es personalizado y con venta asistida, así que presupuesta una tarifa de plataforma además de los cargos por facturación.
- Pásate a Metronome si trabajas sobre Stripe y necesitas ingesta continua en tiempo real, modelos centralizados de compromisos y créditos prepagados, o facturación en mercados cloud (AWS, Azure, GCP). El nivel inicial gratuito lo hace accesible desde temprano, con precios personalizados al escalar. La contrapartida es el acoplamiento: es la respuesta correcta si Stripe es tu hogar de pagos a largo plazo, y la equivocada si planeas diversificar procesadores.
Elijas lo que elijas, confirma cuatro cosas antes de firmar: cómo caen los eventos tardíos y los rellenos históricos entre periodos, quién es responsable del cálculo y la declaración de impuestos, cuál es la historia de facturación espejo para tu operación en paralelo, y qué pasa con tus reglas históricas de valoración si alguna vez migras fuera. Las respuestas a esas cuatro preguntas son tu plan de conciliación.
Los errores que convierten un cambio en una reexpresión contable
- Conciliar totales en lugar de líneas. La diferencia neta oculta errores que se compensan. Cada línea material necesita su propio cuadre entre factura antigua, factura nueva y libro mayor.
- Migrar a mitad de ciclo. Un cliente movido el día 15 recibe dos facturas parciales calculadas con dos reglas de prorrateo. Migra en fronteras de ciclo.
- Dejar que ambos sistemas envíen facturas. Durante la operación en paralelo exactamente un sistema es el autoritativo para enviar; el otro produce espejos. Las facturas enviadas por duplicado significan ingresos contabilizados por duplicado y una oleada de reembolsos.
- Saltarse la repetición histórica. Si el sistema nuevo no puede reproducir un mes que ya facturaste correctamente, tampoco facturará bien el mes que viene. La repetición es la prueba más barata que jamás harás.
- Devengar ingresos no facturados sin comprobar la cobrabilidad. La restricción sobre la contraprestación variable existe porque no cada dólar medido es cobrable — el uso por encima del umbral de crédito de un cliente, los excesos disputados y las facturas en borrador necesitan una política antes de convertirse en ingresos.
- Dar de baja la plataforma antigua antes de la auditoría. Mantenla legible durante un ciclo completo. El almacenamiento es barato; un año de migración inexplicable es caro.
Tu último paso útil es pequeño: antes de firmar el nuevo contrato, exporta un periodo completo de facturación — eventos sin procesar, líneas valoradas, facturas y asientos contables — del sistema antiguo a un formato que controles. Esa exportación es la solución con la que se califica cada conciliación posterior. Las migraciones tienen éxito cuando finanzas puede demostrar, línea por línea, que las facturas del sistema nuevo más los asientos de regularización equivalen a los ingresos que el sistema antiguo habría producido. Haz la repetición, opera el ciclo en paralelo, guarda los justificantes — y el cambio de plataforma seguirá siendo un proyecto de ingeniería en lugar de convertirse en uno de contabilidad.
