
Stripe compró Metronome: el cobro por uso se vuelve nativo (y qué le hace a tu CFDI)
Stripe cerró la compra de Metronome el 14 de enero de 2026 (reportada cerca de mil millones). El cobro por uso e híbrido ya es nativo dentro de Stripe: la app de Metronome vive en el Dashboard, con commits, precios multidimensionales y pagos en streaming con Tempo. Si operas un SaaS mexicano, lo difícil que los blogs de lanzamiento omiten es conciliar esas facturas medidas con tu CFDI.
Qué pasó de verdad: Stripe cerró la compra de Metronome
Stripe completó la adquisición de Metronome el 14 de enero de 2026. Lo confirma la propia sala de prensa de Stripe: el trato está cerrado y Metronome ya es parte de Stripe. Sobre el monto, la cifra de cerca de mil millones de dólares que circula por todos lados es la reportada por la prensa, no un número que Stripe ponga en la página de cierre. Así que trátalo como reportado, no como oficial.
Para los que no lo ubican: Metronome es el líder en orquestar la facturación de modelos de cobro por uso complejos. Es la capa de medición que usan negocios del tamaño de OpenAI, Anthropic y NVIDIA cuando cobran por tokens, llamadas a API o cómputo consumido. No es un detalle menor de ingeniería; es justo la parte difícil de cobrar por uso a escala.
El encuadre de Stripe es directo: precios medidos como el modelo de negocio nativo de la era de la IA. Lo que antes era un complemento de terceros que tú conectabas a mano, ahora vive dentro de Stripe.
¿Por qué debería importarte si construyes desde Puebla o desde cualquier lado de LATAM? Porque si tu SaaS cobra por créditos, tokens, llamadas a API o un esquema de usuarios-más-uso, la capa de medición que antes cableabas tú mismo ahora es de primera mano. Y eso cambia qué construyes y qué dejas de mantener. Si quieres la base, ya escribí sobre facturación por uso para SaaS de IA con Stripe.
Qué salió en Sessions 2026: la app de Metronome en tu Dashboard
En Stripe Sessions 2026 anunciaron lo que ya puedes usar y lo que viene en camino. Esto es lo que salió, según el resumen oficial de todo lo que anunciaron en Sessions 2026:
- Modelos de cobro por uso e híbridos con Metronome: administra commits, precios multidimensionales y contratos a medida, con visibilidad de ingresos en tiempo real hasta el nivel de cuenta, contrato y producto.
- Acceso y administración de contratos, clientes y datos de Metronome directamente en el Dashboard de Stripe. La app de Metronome ahora vive ahí.
- Seguimiento de saldos de crédito, alertas de saldo bajo y auto-recargas de crédito, listados como disponibles en el resumen.
- Pagos en streaming: combinas Metronome + Tempo para cobrar en el instante en que entregas valor y se incurre el costo.
Y luego está el roadmap, que conviene etiquetar como roadmap y no como algo que ya puedas usar hoy: descuentos por volumen sobre créditos con pago obligado o auto-recarga, créditos por usuario, cuentas jerárquicas y el cobro en tiempo real con latencia de menos de un segundo. Anunciado, sí. Disponible para todos, no necesariamente. No diseñes tu producto asumiendo que ya están en producción; confirma cada item contra el resumen oficial antes de construir alrededor.
La diferencia práctica es la consolidación. Antes saltabas entre tu propio sistema de medición, el Dashboard de Stripe y tu hoja de reconciliación. Ahora la lógica de contratos y el cómputo de líneas viven en el mismo lugar donde ya cobras.
Medición casera antes vs. nativa ahora: ¿qué dejas de construir?
Vamos a lo concreto, porque aquí es donde se siente el cambio. Si ya operaste cobro por uso, conoces el dolor.
Antes: ingerías eventos de uso en tu propio almacén, corrías jobs de agregación cada noche, mapeabas tiers y commits a mano, y empujabas líneas ya calculadas hacia las facturas de Stripe. Más toda la plomería de reconciliación y un montón de matemática de casos límite que nadie quiere mantener.
Ahora: los eventos de uso, los commits, los precios multidimensionales y la lógica de contratos viven dentro de Stripe/Metronome. La factura llega con las líneas ya calculadas.
¿Qué dejas de construir? El pipeline de agregación, la lógica de drawdown de commits, el tracking de saldos de crédito y ese paso frágil de “calcular y luego pegar a la factura”. Para un equipo chico, eso es infraestructura real que mantenías mal porque no tenías gente para mantenerla bien.
¿Qué NO dejas de ser dueño? La capa específica de México. Stripe calcula el cargo; el SAT sigue gobernando el CFDI. Ese mapeo es tuyo, y nadie lo va a hacer por ti.
Opinión, y la etiqueto como opinión: esto es una ganancia genuina para equipos pequeños, menos infra que cuidar. Pero profundiza el vendor lock-in, y la costura entre el cargo medido y el CFDI ahora es la parte que tienes que cuidar con más cuidado. El cobro por uso también mueve tus métricas de negocio; si quieres entender qué cambia, revisa las métricas de facturación SaaS como MRR y churn.
Antes: medición casera
- Ingieres eventos de uso en tu propio almacén
- Corres jobs de agregación cada noche
- Mapeas tiers y commits a mano
- Empujas líneas calculadas a la factura
- Mantienes la plomería de reconciliación
Ahora: nativo en Stripe + Metronome
- Eventos, commits y precios viven en Stripe
- La factura llega con líneas ya calculadas
- Dejas de construir el pipeline de agregación
- Dejas el drawdown de commits y el tracking de créditos
- Sigues siendo dueño del mapeo a CFDI + IVA
La parte que el blog de lanzamiento omite: conciliar el cobro medido con el CFDI
Aquí está el moat, lo que los blogs de lanzamiento no te cuentan porque no operan en México. Cada factura de Stripe/Metronome tiene que convertirse en un CFDI, y cada línea de esa factura tiene que mapear a un concepto del CFDI con su ClaveProdServ, ClaveUnidad, valorUnitario e IVA correctos.
El flujo conceptual es así: evento de uso → Stripe/Metronome agrega → factura con líneas → mapeas cada línea a un concepto del CFDI + IVA → timbras con tu PAC → afirmas que el total del CFDI concilia con el total de la factura de Stripe.
¿Por qué el cobro medido hace esto más difícil que una suscripción de monto fijo? Por tres razones que se acumulan:
- Agregar-y-luego-facturar significa que las líneas se calculan tarde, casi al cierre del ciclo. No tienes un monto estable que conozcas desde el día uno.
- Los créditos a mitad de ciclo y los drawdowns de commits cambian el monto neto. Lo que el cliente debe no es lo que consumió por su precio de lista.
- Las facturas en varias monedas necesitan un tipo de cambio que coincida con el TipoCambio del CFDI. Si tu factura está en USD y tu CFDI en MXN, el FX es donde los totales se desvían.
La afirmación de conciliación es tu red de seguridad. Si el total del CFDI no es igual al total de la factura (dentro de una tolerancia de redondeo), NO timbras. Te detienes e investigas. Timbrar un CFDI que no concilia es generar un comprobante fiscal incorrecto, y eso es un problema que no quieres tener con el SAT.
Límite honesto: soy ingeniero, no contador. Las claves exactas, el tratamiento de IVA sobre los créditos y las reglas de FX son territorio del SAT y de tu contador. Tú cableas la conciliación; deja que tu contador valide el mapeo fiscal. Si ya tienes el timbrado automático, esto se conecta con la facturación CFDI automática con Stripe y Mercado Pago.
El patrón de conciliación, paso a paso
Bajemos esto a pasos accionables. El código de abajo es ilustrativo: adáptalo a tu PAC y confirma claves e IVA con tu contador.
Paso 1 — Trae la factura. Obtén la factura finalizada de Stripe y sus líneas, cada una con su monto, moneda, cantidad y el price o meter del que vino.
Paso 2 — Mapea cada línea a un concepto. Traduce cada línea a un concepto del CFDI (ClaveProdServ, ClaveUnidad, cantidad, valorUnitario) y anexa el traslado de IVA. Mantén una tabla de mapeo estable del ID de price/meter de Stripe al concepto.
Paso 3 — Maneja créditos, commits y moneda. Aplica los créditos a mitad de ciclo y los drawdowns de commits como descuentos o ajustes negativos para que el neto cuadre; para facturas que no estén en MXN, registra Moneda + TipoCambio consistente con el tipo de cambio aceptado por el SAT.
Paso 4 — Timbra. Manda el comprobante armado a tu PAC; captura el UUID y guárdalo contra el ID de la factura de Stripe.
Paso 5 — Afirma que los totales concilian. Concilia sobre la misma base imponible: si el IVA NO lo calcula Stripe, compara el subtotal del CFDI contra el subtotal de Stripe; si tienes Stripe Tax activo, compara el total con IVA contra el total de Stripe. Confirma la igualdad en la moneda de la factura, dentro de una tolerancia de un centavo.
// Ilustrativo. Adapta a tu PAC y valida claves/IVA con tu contador.
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
// Tabla de mapeo estable: price/meter de Stripe -> concepto CFDI
const CONCEPTO_POR_PRICE: Record<string, { claveProdServ: string; claveUnidad: string }> = {
price_tokens_ia: { claveProdServ: "81112500", claveUnidad: "E48" }, // servicio de software
price_llamadas_api: { claveProdServ: "81112500", claveUnidad: "E48" },
};
const IVA = 0.16; // tasa general; confirma el tratamiento con tu contador
// Si tu cálculo de IVA vive en Stripe Tax, pon esto en true; si el IVA del
// CFDI lo computas aquí (lo habitual en MX), déjalo en false.
const STRIPE_CALCULA_IVA = false;
// La ruta del price en las líneas depende de la versión de API que tengas fijada:
// en API moderna es pricing.price_details.price; antes era price.id. Cubrimos ambas.
function priceIdDeLinea(line: Stripe.InvoiceLineItem): string {
return (
(line as any).pricing?.price_details?.price ??
(line as any).price?.id ??
""
);
}
async function conciliarFactura(invoiceId: string) {
const invoice = await stripe.invoices.retrieve(invoiceId, { expand: ["lines"] });
const conceptos = invoice.lines.data.map((line) => {
const map = CONCEPTO_POR_PRICE[priceIdDeLinea(line)];
if (!map) throw new Error(`Sin mapeo CFDI para la línea ${line.id}`);
// Stripe trabaja en la unidad mínima (centavos)
const importe = line.amount / 100;
const cantidad = line.quantity ?? 1;
return {
claveProdServ: map.claveProdServ,
claveUnidad: map.claveUnidad,
cantidad,
valorUnitario: importe / cantidad,
importe,
traslados: [{ impuesto: "002", tasa: IVA, importe: +(importe * IVA).toFixed(2) }],
};
});
// Créditos y drawdowns de commits llegan como líneas negativas en Stripe;
// entran arriba como importes negativos, así que el neto ya cuadra.
const subtotalCfdi = +conceptos.reduce((s, c) => s + c.importe, 0).toFixed(2);
const ivaTotal = +conceptos.reduce((s, c) => s + c.traslados[0].importe, 0).toFixed(2);
const totalCfdi = +(subtotalCfdi + ivaTotal).toFixed(2);
// Paso 5: la red de seguridad. Compara sobre la MISMA base imponible.
// Sin Stripe Tax, el total de Stripe viene sin IVA -> compara subtotales.
// Con Stripe Tax, el total ya trae IVA -> compara totales.
const baseCfdi = STRIPE_CALCULA_IVA ? totalCfdi : subtotalCfdi;
const baseFactura =
(STRIPE_CALCULA_IVA ? invoice.total : invoice.subtotal) / 100;
const tolerancia = 0.01; // un centavo
if (Math.abs(baseCfdi - baseFactura) > tolerancia) {
throw new Error(
`Conciliación falló: CFDI ${baseCfdi} != factura ${baseFactura}. No se timbra.`,
);
}
// Moneda y tipo de cambio para facturas que no estén en MXN
const moneda = invoice.currency.toUpperCase();
const tipoCambio = moneda === "MXN" ? undefined : await obtenerTipoCambioSat(invoice.created);
return { conceptos, subtotalCfdi, ivaTotal, totalCfdi, moneda, tipoCambio };
}
declare function obtenerTipoCambioSat(timestamp: number): Promise<number>;
Fíjate que el paso 5 es el que importa. Todo lo demás es plomería; esa aserción es lo que evita que mandes un comprobante fiscal incorrecto al SAT. Si construyes desde cero la integración de Stripe, primero asegura la base de Stripe en tu SaaS.
- Trae la facturafactura finalizada de Stripe con sus líneas
- Mapea cada línea a un conceptoClaveProdServ, ClaveUnidad, valorUnitario + IVA
- Maneja créditos, commits y monedadescuentos para el neto; TipoCambio si no es MXN
- Timbra con tu PACcaptura el UUID contra el ID de la factura
- Afirma sobre la misma basesubtotal vs subtotal, o total con IVA si hay Stripe Tax
¿Adoptar el cobro por uso nativo ya? Mi opinión
Aquí va mi lectura, etiquetada como opinión porque lo es.
Si ya estás sobre Stripe Billing y cobras por uso o créditos, Metronome nativo vale la pena pilotarlo. Te quita infraestructura real que de otro modo mantendrías mal a escala chica. Esa es la ganancia clara y no la voy a minimizar.
Sé deliberado con el lock-in. Mantén también tus eventos de uso en un almacén que tú controles, para que la fuente de verdad de “qué consumió el cliente” no viva únicamente dentro del proveedor. El día que quieras migrar, o el día que necesites auditar un cargo disputado, vas a agradecer tener esos eventos en tu propia base.
Para LATAM en específico: la historia de pagos en streaming con Tempo es emocionante, pero trátala como algo a futuro. Tu valor a corto plazo es la medición y la consolidación en el Dashboard, no la liquidación instantánea en México. No diseñes tu flujo de caja asumiendo settlement inmediato que aún no está confirmado para tu mercado.
Y no dejes que “nativo y fácil” te tiente a saltarte la conciliación con CFDI. Mientras más fácil se vuelve la facturación río arriba, más la costura fiscal es lo único que se interpone entre tú y una factura que no cuadra.
En corto: adopta la medición, sé dueño de la conciliación, etiqueta los items de roadmap como roadmap, y verifica todo lo fiscal con un contador.
Preguntas frecuentes
¿Cuándo cerró Stripe la compra de Metronome? El 14 de enero de 2026, según la sala de prensa de Stripe. La cifra reportada de cerca de mil millones de dólares se cita por todos lados, pero no aparece en la página de cierre; trátala como reportada, no como oficial.
¿El cobro por uso ya está completamente dentro de Stripe? La app de Metronome está en el Dashboard de Stripe con commits, precios multidimensionales, seguimiento de saldos de crédito con alertas de saldo bajo y auto-recargas, y pagos en streaming con Metronome + Tempo. Otros items (descuentos por volumen sobre créditos, créditos por usuario, cuentas jerárquicas, cobro en tiempo real) se anunciaron como roadmap.
¿Esto genera mi CFDI automáticamente? No. Stripe/Metronome calculan el cargo; tú sigues mapeando las líneas de la factura a conceptos del CFDI + IVA y timbrando con un PAC. Las reglas del SAT gobiernan el CFDI.
¿Qué rompe la conciliación más seguido? Los créditos a mitad de ciclo y los drawdowns de commits, junto con las facturas en varias monedas y conciliar sobre bases distintas (con IVA contra sin IVA). El monto neto, el TipoCambio y la base imponible son donde los totales se desvían.
¿Puedo usar pagos en streaming con Tempo para liquidar en México hoy? Trátalo como algo a futuro. Verifica la disponibilidad para tu mercado y tus monedas antes de diseñar alrededor de eso. Cifras y disponibilidad son como están en 2026, confirma lo vigente. Para más guías de pagos, revisa las integraciones.
Cierre
El titular es real: el cobro por uso ya es nativo en Stripe después de que la compra de Metronome cerró el 14 de enero de 2026. Eso te quita infraestructura que mantenías mal.
Pero el trabajo en la orilla sigue siendo tuyo. Mapea las líneas medidas a conceptos del CFDI + IVA y afirma que los totales concilian sobre la misma base antes de timbrar. Esa aserción es tu red de seguridad.
Adopta la medición, sé dueño de la conciliación, y deja que tu contador valide lo fiscal. Ingeniero, no contador, y orgulloso de la diferencia.