B
Glossary
Billing Period
A billing period is the span of time that a single invoice covers. It sets the boundaries for every charge on that invoice: which usage events count toward it, which subscription fees apply, and which date the billing system uses to close the books and generate the document.
Key Takeaways
The billing period is a window with a start and an end. The billing cycle is the repeating pattern those windows follow.
An anchor date, not the calendar month, decides where most billing periods start and end.
A subscription created on 31 January produces period boundaries on 28 February, 31 March, and 30 April under end-of-month clamping, so period lengths vary from 28 to 31 days.
Usage charges belong to the period the event timestamp falls in, not the period the event arrived in.
Changing a plan mid-period splits the window into two priced segments rather than moving the boundary.
What decides where a billing period starts and ends?
The anchor date decides it, and the anchor date is usually the subscription's start date rather than the first of the month. Billing systems store that anchor and derive every subsequent boundary from it, which is why two customers on identical plans get invoices on different days.
The rules a billing system applies, in order:
Read the anchor date from the subscription.
Add the period interval (monthly, quarterly, annual) to produce the next boundary.
Clamp the result to the last valid day if the target day doesn't exist in that month.
Fix the boundary time in a single timezone, usually UTC, so the window doesn't shift twice a year.
Clamping is where the edge cases live. A subscription anchored on the 31st behaves like this:
Period | Start | End | Days |
|---|---|---|---|
1 | 31 Jan | 27 Feb | 28 |
2 | 28 Feb | 30 Mar | 31 |
3 | 31 Mar | 29 Apr | 30 |
4 | 30 Apr | 30 May | 31 |
Two things follow from that table. Period length isn't constant, so any per-day calculation has to read the actual boundary rather than assume 30 days. And clamping doesn't reset the anchor: period 3 returns to the 31st because the system still remembers the original anchor rather than the clamped date it used in February.
Billing period vs billing cycle: is there a difference?
In careful usage, yes: a billing period is one window, and a billing cycle is the recurring pattern that produces them. In everyday usage the two are interchangeable, and most billing platforms use them that way.
Where the distinction earns its keep:
"The customer's billing period is 1 March to 31 March" names one specific window.
"The customer is on a monthly billing cycle" names the cadence that generates every window.
A cycle can stay monthly while an individual period runs short, which is exactly what a mid-period plan change or a cancellation produces.
For how periods behave across a whole subscription, see the subscription management guide. If a document uses the two terms in the same sentence, read period as the noun and cycle as the pattern. If it uses only one, the meaning is almost always the window.
What happens to a billing period when the subscription changes?
A mid-period change splits the period into segments and prices each one separately. The boundary itself doesn't move, which surprises people who expect an upgrade to restart the clock.
What each change does to the window:
Upgrade or downgrade. The period splits at the change date and the next boundary stays where the anchor put it. How the amount gets divided across the two segments is proration, covered on the billing cycle page.
Cancellation. The final period runs short, ending at the cancellation date instead of the anchor boundary.
Interval change, monthly to annual. The current period closes early and a new anchor is set, because an annual window can't inherit a monthly boundary.
Usage charges during any of the above. They stay attached to the segment their event timestamp falls in. An event at 14:00 on the change date belongs to whichever segment holds that instant.
That last point is the one that generates disputes. Usage lands in a period by event timestamp, not by arrival time, so backdated usage can change a period's total after the period ended. Systems handle it either by holding the invoice in draft until a watermark passes or by re-rating the closed period and issuing an adjustment.
Related terms
Every term here either defines the window, fills it, or reacts to it closing.
Billing cycle is the recurring pattern that generates each period, and it owns proration.
Billing in arrears describes invoicing after a billing period ends rather than before it starts.
Usage aggregation sums the events that fall inside a period's boundaries.
Draft invoice is the state an invoice holds between the period closing and finalizing.
Backdated usage is usage whose timestamp lands in a period that has already ended.
Watermark (event processing) is the mechanism that decides a period is finally safe to close.
FAQ
How long is a billing period?
As long as the subscription interval says, most commonly a month. Monthly periods run 28 to 31 days depending on where the anchor date falls, so treating every month as 30 days will produce proration errors of a few percent.
Can a billing period be shorter than the billing interval?
Yes. A cancellation, a plan change, or a subscription that starts partway through produces a short period. Billing systems price these by proration rather than by charging the full interval amount.
Does the billing period reset when a customer upgrades?
No. The anchor date holds and the next boundary stays where it was. The upgrade splits the current period into two priced segments instead of starting a fresh one.
What timezone does a billing period use?
Whatever the billing system anchors to, and it should be one fixed timezone for the whole account, usually UTC. Anchoring boundaries to a local timezone that observes daylight saving means two periods a year are an hour longer or shorter than the rest, and usage events near the boundary land in the wrong window.
Back to glossary
