PostHog adds Metronome billing data as a warehouse source

Billing records enter the analytics workspace

PostHog’s 7 September 2026 changelog introduces Metronome as a data warehouse source. The release describes synchronizing billing objects including customers, contracts, invoices, products and rate cards using an API token. For teams already using both products, this creates another route for bringing commercial records alongside product activity.

The announcement establishes the availability of a source connection. It does not establish that a particular revenue metric is correct, that every historical record will be complete or that a joined dataset can predict customer retention. Those outcomes depend on source coverage, identity mapping and the definitions applied after the data arrives.

Sources: PostHog original release

A connection is only the first part of the model

PostHog’s data warehouse documentation describes linking external data for analysis. A billing integration is useful because product events and commercial records answer different questions. Product activity can describe what happened in an application; an invoice can describe what a billing process charged. Neither should be treated as a universal substitute for the other.

Start with the question the team needs to answer. Is it reconciling billable usage, investigating an invoice dispute, understanding adoption within a paid account or reviewing an expansion hypothesis? Each requires a different grain and observation window. Writing that question before building a dashboard prevents a convenient join from becoming an accidental business definition.

Sources: PostHog data warehouse documentation

Map billing customers to product accounts deliberately

A billing customer may pay for several workspaces, and one product workspace may contain many people. A person-level event stream joined directly to an invoice table can multiply the same invoice across users. The resulting total may look plausible while being systematically overstated. Define the relationship and its valid period before summing any commercial amount.

Keep an explicit mapping for mergers, migrations, renamed workspaces and accounts that change billing entities. Record unmatched and ambiguous cases instead of silently assigning them to the nearest domain match. Review the mapping with someone who understands the commercial relationship, especially when a parent company pays for several subsidiaries that operate independently in the product.

Separate usage time from invoice time

Usage can occur in one period, arrive late and be invoiced in another. Contracts can carry committed amounts, credits, adjustments or a pricing version that changes the relationship between activity and a charge. An analysis should state which clock and which version it follows. A date filter on invoice creation alone does not define the period in which customers used the service.

Preserve currency and the meaning of each amount. Do not add invoice totals to line-level amounts without checking their relationship, and do not treat billed revenue as recognized revenue without an approved definition. Where a correction changes a previous period, decide whether the report restates that period or records an adjustment separately. Make the choice visible to readers.

Reconcile a bounded period before drawing conclusions

Select one completed billing period and compare the imported population with the source system. Check record counts at the correct grain, missing identifiers, duplicate keys and aggregate amounts using the same currency and status filters. Include a normal invoice, an adjustment, a cancelled or voided record where applicable and an account with more than one product workspace.

Then trace several records through the join to product activity. Explain why each event belongs to the selected customer and why each amount appears once. Document exclusions and unresolved differences. This is a proposed validation procedure, not a claim that the new connector automatically reconciles billing with analytics or supplies an accounting control.

Use the result as evidence, not a predictive label

Once the joined model is trustworthy, operators can investigate concrete questions: whether a paid account has active teams, whether a charge corresponds to the expected activity, or whether a product change coincides with a change in billable usage. These are observations to review with context. Low recorded activity can reflect tracking coverage, seasonality or a different workflow rather than an imminent cancellation.

A useful rollout therefore has two owners: one for the commercial definition and one for the analytical implementation. Retain the source identifiers, model version and reconciliation notes so a customer-facing team can challenge the result. The new source broadens the available evidence; it does not remove the need to establish what each record means before using it in a revenue decision.

When a source token is rotated or the sync is interrupted, rerun the same reconciliation rather than assuming the next successful job repairs every gap. Record the last verified period and expose incomplete periods in reporting. A visible incomplete state is more useful than a precise total built from an unknown population.