Bill a prepaid term or a deferred go-live.

01Decide what you are changing: the price, or the invoicing

A billing schedule separates WHEN a subscription is invoiced from WHAT it costs. The plan, the components, and their prices are unchanged — only the invoicing calendar moves (a prepay incentive, below, is an ordinary discount for the prepaid periods, not a new price). That is why a customer who prepays a year reports exactly the same MRR and ARR as one paying monthly: the revenue line reflects the contract, not the payment schedule. Leave the schedule on Standard and the subscription behaves exactly as it always has, one plan charge per period on renewal. Billing schedules are a gated workspace feature, so the Billing schedule options only appear once it is enabled for your workspace. Only two moments ever fire an invoice from a schedule: signing and activation; renewals carry on as usual for whatever the schedule did not pay ahead. Milestone and explicit-date triggers can be stored but nothing fires them.

• Subscription concept ›

02Prepaid term — one invoice covers several periods

Pick "Prepaid term" on the Settings step of the new-subscription wizard and set how many periods are paid upfront (two or more, on the subscription's own cadence — so 3 on a monthly plan and 2 on a quarterly plan use the same field). Signing raises ONE invoice for the whole span: the plan, itemised as quantity × period price, and every component billed ahead at the count it starts with (seats, licences), one line per period, each naming its period. Every renewal inside the span then raises no plan charge and nothing for those components unless the count grew — then only the added units are invoiced — and a renewal with nothing to bill raises no invoice at all, not a $0 one. Billing resumes on its own at the first renewal past the span. Nothing to remember, nothing to switch back on.

• Invoice concept ›

03Trade a discount for the cash — as a discount, not a lower price

The "Prepay incentive (%)" field takes a percentage off what is paid upfront, and "Incentive applies to" says what that is: the base price (the default), the components billed ahead, or both. It lands as a discount on the subscription like any other and ends with the span; a prepaid term sold before the choice existed discounts the base price. It is deliberately not baked into the base price: doing that would restate the customer's MRR at the discounted rate for good, and the day the span ended their portfolio would show an unexplained expansion. Duration-based discounts are counted correctly against a prepaid invoice too — a "first three renewals" discount is used up by a three-period prepayment rather than lingering into period four, and a flat "$50 off the plan" comes off each period the invoice covers.

• Discount concept ›

04What is paid ahead, and what still bills each period

A component billed ahead whose count carries over — seats, licences — is paid for the whole span with the plan, at the count it starts with. Add seats during the span and the next renewal invoices only the added ones, for that period; leave the count alone and nothing is invoiced. Usage counted per period — API calls, hours — cannot be known in advance, so it is never prepaid: it still meters and bills after each period, and a usage-only invoice arriving inside the span is expected, not an anomaly. The cash-flow forecast shows the prepaid cash once, at signing.

• Subscription Variable Usage concept ›

05Deferred activation — sign now, start the clock later

Pick "Deferred activation" when the contract is signed weeks before the customer goes live. The deal exists in the book from day one but nothing recurs until it is switched on. "Billed at signing (%)" takes any split from 0 to 100 — a 50/50, a 100%-upfront, and a nothing-upfront deal are all the same form — and "Setup fee" puts one-time implementation work on the same signing invoice. The setup fee is exempt from plan discounts, so "$50 off the plan" does not also come off the implementation.

06A pending deal counts for nothing until you activate it

While it waits, the subscription is PENDING: out of MRR and ARR, out of active-subscription counts, skipped by the renewal sweep, and usage posted against it is rejected with a 409 telling the integration to activate first. Its start and end dates are provisional and the client file says "Pending activation" rather than showing a term that has not happened. You cannot flip it to active by editing its status — that would skip both the activation charge and the clock start.

• Lifecycle Event concept ›

07Going live is one deliberate action

Activate on the subscription bills the remainder of the first period, re-anchors the term to the real go-live date, and starts recurring billing from that day — so period two renews one cadence after go-live, not after signature. Set the actual date if you are activating a day or two late. Nothing is owed on a 100%-at-signing deal, so no zero-value invoice is raised. Clicking twice is harmless: the second click returns the same result rather than a second invoice, and the customer's acquisition is recorded once, on the go-live date — a deal signed in March and live in June shows up in June's new business.

08Nothing signed gets forgotten

Set an "Activation deadline (days)" — pre-filled from your workspace default — and the Renewals page lists every subscription still waiting, worst-overdue first. Passing the window raises one alert and a task you can assign and close, not a nightly repeat. The alert changes nothing on its own: a deal nobody has switched on is never auto-activated into billing, and never auto-cancelled out of the book.

09Say what cancellation costs before you need to know

"On cancellation" sets the commitment posture for a prepaid span — what happens to money that is already in. Binding owes the whole span, so access and billing continue to the end of what was paid for and churn is recorded when the span actually ends. Refundable credits the unconsumed whole periods back as a credit note — of the plan and of the components paid ahead with it — counting only the periods that were genuinely invoiced. None behaves exactly as cancellation does today. Your workspace default is pre-selected so sales is not deciding policy deal by deal.

10Every firing is on the record

The subscription carries a timeline of its schedule events — signing billed, activated, span covered, completed — alongside the schedule itself and its charges. When a dispute comes down to "when did we bill this and why", that log is the answer. A subscription with no schedule shows the default rather than an empty card, so the question is answerable from one place either way. On a prepaid term the card also shows the prepay incentive and what it discounts, and the subscription's "How this subscription is billed" section says what is prepaid, through which date, and when the next renewal will invoice anything.

• Lifecycle Event concept ›

11Reading a schedule from an integration

The public GraphQL API exposes three read-only fields on a subscription so an integration can tell a renewal that legitimately raised no invoice from one that is missing: billingArrangement, planChargeBilledThrough and awaitingActivation. Reconcile against those rather than assuming one plan charge per period — or one invoice per renewal: inside the span a renewal invoices only components added since signing and usage counted per period, and raises no invoice when there is nothing to bill.

• Public GraphQL — how a subscription is invoiced ›
• Contracts & committed terms ›
• Credit notes — what a refundable span gives back ›