Pay before or pay after.

What each timing means

Advance is the right default for flat, predictable charges — the customer knows the amount before the period starts, so there is nothing to wait for. Arrears is the right choice for anything metered, where the final amount can only be known once the period has actually happened.

When each invoice goes out

• The base price is always billed ahead: on the first day for the first period, then for each next period at renewal.
• Invoice timing sets when a renewal’s ahead invoice is raised: a number of days before the renewal date, or on the renewal date when it is 0. Each client can have its own value per billing period; otherwise the workspace default applies, and otherwise 0. A client set to 0 keeps invoicing on the renewal date whatever the workspace says.
• A usage charge billed in advance goes on the same ahead invoice as the base, at the quantity the period starts with.
• A usage charge billed in arrears goes on the renewal invoice for the period that just ended, so its first charge comes one full period after the subscription starts.
• With invoice timing above 0 and a charge billed after the period, the client gets two invoices each period: the base and advance charges a few days before renewal, then usage once the period has ended. With invoice timing 0, both are on one renewal invoice.
• A free trial raises no invoice until it converts. A subscription awaiting go-live bills nothing until it is activated.

Readings: the final figure for a period

• Only a charge counted per period needs a reading. A standing quantity bills its level and never waits on anyone.
• When a period closes, its reading waits 24 hours for late reports, then seals and is billed. The renewal invoice stays a draft until every reading on it is sealed or waived.
• With invoice timing 0, the base price is on that same renewal invoice and waits with the usage. With a lead, the base already went out, so only the usage waits.
• Usage capture API (from the integration): if nothing was reported, a charge set to “Hold the invoice for review” raises a task and the invoice waits; one set to “Bill zero automatically” bills zero.
• Usage capture Manual (entered by someone): someone enters the figure after each period. A task is raised and the invoice waits for it.
• When an API charge closes at zero, workspace admins are warned before it bills and can enter a figure or hold it for review. Where zero is normal for one subscription, the warning can be switched off on that subscription’s component.

The settings that decide it

Usage capture is set on the client, not in the catalog: API (from the integration) or Manual (entered by someone), API when unset. It can be changed for one component on one subscription.

Choosing settings for a charge

In the dashboard, the same guide opens from How billing works on the Catalog page, and each subscription shows its own next invoices under How it bills.

Three levels, most specific wins

1. 1
   Component default

   Every Variable Component has a billingTiming field — this is what every subscription inherits unless something more specific overrides it.
2. 2
   Per-subscription override

   One customer’s copy of a component can be pinned to Advance or Arrears independent of the product default, with a required reason for the audit trail. Set to null to fall back to whatever the live product default is.
3. 3
   Custom Pricing Agreement override

   A Custom Pricing Agreement can opt BILLING_TIMING into its overrideScope, pinning timing as part of a broader negotiated deal rather than a standalone toggle.

Changes are prospective, by design

A billing timing override never rewrites the invoice for a cycle that has already been scheduled or generated. It takes effect at the next period reset boundary — the same point where component pricing and usage counters reset. Flipping a component from Advance to Arrears mid-cycle doesn’t retroactively delay the invoice you already sent; it changes how the next cycle is billed.

Because of this, the dashboard always shows three things side by side when you’re looking at a component’s timing: the product default, what’s actually billing this cycle, and what will bill next cycle if an override is pending. A reason is required for every override, and the full history — who changed it, when, and why — is kept separately for audit.

Next up

• Pricing models reference ›
• Custom Pricing Agreements ›
• Overriding base & component pricing ›