Chargebee

Chargebee exposes a broad set of objects: customers, subscriptions, invoices, credit notes, transactions, events, plans, coupons, and payment sources. This integration focuses on two objects — subscriptions and invoices — which are the closest to attributable revenue performance in a SaaS billing context. Objects such as customers and events are used internally to resolve owner attribution and detect payment failures, but they are not tracked as standalone units of performance. Five KPIs were retained, selected against three criteria: ability to attribute to an identified owner, resistance to gaming, and balance between leading and lagging indicators. A foundational constraint shapes this entire integration: Chargebee has no native owner field. Attribution is entirely dependent on a custom field convention — a team-configured email field on the subscription or customer record — which makes KPI reliability contingent on data hygiene upstream.

Revenue dynamics: reading MRR through three complementary lenses

Three KPIs cover subscription-level revenue movement, each measuring a distinct component of the MRR equation. New MRR captures the monthly recurring revenue generated by subscriptions activated during the period. Churn MRR captures the monthly recurring revenue lost when subscriptions are cancelled. Expansion MRR captures the incremental recurring revenue added when existing customers upgrade their plans.

The three indicators are designed to be read together rather than independently, because each one alone is insufficient and potentially misleading. A high New MRR for a given account manager reveals revenue acquisition, but says nothing about the quality of that revenue: a portfolio grown rapidly through oversold contracts will manifest as elevated Churn MRR in subsequent periods. Reading New MRR alongside Churn MRR for the same owner neutralizes this risk — an account manager who consistently generates new revenue while holding Churn MRR flat demonstrates durable performance, not tactical inflation.

Expansion MRR completes the picture by surfacing upsell activity within the existing customer base. When Expansion MRR is growing for an owner while New MRR is stable, it reveals a different commercial posture: deepening existing relationships rather than acquiring new ones. When both are growing simultaneously alongside controlled Churn MRR, it confirms a compounding portfolio dynamic. A manager reading only one of these three indicators operates with an incomplete model of what their team is actually building.

Revenue-at-risk: failed payments as an early signal

Failed Payment Count records the number of payment failure events on invoices attributed to a given owner during the period. Its position in the indicator set is structurally different from the three MRR indicators: it operates upstream of cancellation, measuring a condition that, if unaddressed, will eventually convert into Churn MRR. An increase in failed payments for a specific owner's portfolio signals that a segment of their customer base is experiencing billing friction — friction that may stem from expired cards, insufficient funds, or bank-side restrictions.

This indicator is actionable in a way that churn is not: a cancelled subscription is a completed event, while a failed payment is an open condition where intervention remains possible. A CSM or account manager who monitors Failed Payment Count on their portfolio can initiate proactive outreach before dunning cycles exhaust themselves and trigger automatic cancellation. The KPI is therefore a leading indicator of revenue risk, not a lagging confirmation of loss. Its gaming risk is effectively zero — payment failure timestamps are system-generated by the billing infrastructure and cannot be artificially manipulated by the owner.

Cash collection efficiency: the operational dimension

Average Days to Collect measures the mean number of days elapsed between invoice generation and payment receipt, computed on paid invoices within the period. It captures the efficiency of the cash collection cycle, which in subscription businesses with annual or multi-year contracts can be a meaningful source of working capital variance. A finance operations team that reduces Average Days to Collect shortens the gap between recognized revenue and cash in account.

This indicator is the least susceptible to gaming of the five retained KPIs: payment timestamps are recorded by the billing system at the moment of transaction confirmation, leaving no room for manipulation at the individual level. Its relationship with Failed Payment Count is worth noting: a portfolio with a high failed payment rate will also tend to show a degraded Average Days to Collect, because the invoices that do eventually get paid after dunning rounds inflate the collection delay. Reading both indicators together allows a finance team to distinguish between customers who pay slowly but reliably and customers whose payment failures are delaying collection across the entire period.

Scope and limits of the integration

Chargebee records billing events and revenue state with high fidelity, but the integration does not capture the commercial judgment or relationship quality that underlies these numbers. An account manager's Churn MRR figure does not reveal whether the cancellation was foreseeable and preventable, or the result of a customer decision made for reasons entirely outside the account manager's influence — a company acquisition, a market exit, a cost-cutting program. The API data treats all cancellations identically regardless of cause.

The more significant structural limit is the absence of a native owner attribution field. All five KPIs depend on a custom field — typically configured as an email address on the customer or subscription record — that must be created, named, and consistently populated by the Chargebee tenant. If this field is absent or irregularly filled, KPIs degrade to company-level aggregates that cannot feed individual OKRs. The reliability of this integration is therefore not solely a function of how Chargebee is used, but of how deliberately the team has configured and maintained its attribution convention. This is a dependency that no technical design can substitute for.