A billing cycle is the time window between two consecutive invoice dates for a subscription. It defines when the customer is charged, when usage resets, and when overage is calculated. Every subscription has a billing cycle, and understanding how it works is foundational to understanding how SaaS billing operates.
How billing cycles are anchored
Billing cycles are anchored to the subscription start date, not the calendar month. If a customer subscribes on January 15 with monthly billing, their cycle runs from the 15th to the 15th. Their invoices are generated on January 15, February 15, March 15, and so on.
This means different customers on the same plan have different billing cycle dates. Customer A who signed up on March 3 and Customer B who signed up on March 20 will have their invoices generated on different dates. There is no global "billing day" for your product.
Anchor-based billing matters because it determines when all time-dependent calculations happen: usage resets, overage calculations, proration for plan changes, and renewal charges.
What happens within a billing cycle
A billing cycle has a clear sequence of events.
At the start of the cycle, the plan's base price is charged in advance. The customer pays for the upcoming period. If the plan includes a usage quota (10,000 API calls, 500 credits, $100 balance), that quota resets to its full amount.
Throughout the cycle, the system tracks every usage event. API calls, token consumption, seat additions, feature activations. All of it is attributed to the current billing period. The customer can see their running usage at any time.
At the end of the cycle, the system takes a snapshot. For metered billing, it compares actual usage against the included quota and calculates overage. For credits-based billing, unused plan credits expire (purchased credit packs carry forward). For balance billing, any spend beyond the plan's balance becomes overage. The closing invoice includes the next period's advance charge plus any usage charges from the period that just ended.
Billing intervals
Commet supports three billing intervals, and the choice affects how long each cycle lasts.
Monthly cycles are approximately 30 days, anchored to the subscription date. A subscription starting January 15 has its first cycle from January 15 to February 15 (31 days), the second from February 15 to March 15 (28 days in a non-leap year). The cycle length varies slightly because months have different numbers of days.
Quarterly cycles span approximately 90 days. A subscription starting January 15 renews on April 15, then July 15, then October 15.
Yearly cycles span 12 months. A subscription starting January 15, 2026 renews on January 15, 2027.
Regardless of the billing interval, usage-based overage is always evaluated on a monthly cadence. A customer on a yearly plan still has their metered usage checked against the monthly quota every 30 days. This prevents usage front-loading. See recurring billing for more on how this works.
Cycle boundaries and edge cases
Billing cycle boundaries create specific scenarios that the system must handle correctly.
Late-arriving usage events. If a usage event arrives after the cycle has closed but belongs to the previous period, it is attributed based on its timestamp, not arrival time. The system may need to adjust a finalized invoice or carry the late event into the next period depending on configuration.
Timezone handling. Cycles close based on the organization's configured timezone. A cycle ending at midnight on March 15 in UTC is different from midnight on March 15 in America/Sao_Paulo. Getting this wrong means attributing usage to the wrong period.
Month-end dates. A subscription starting on January 31 creates an edge case: February has no 31st. The system rolls to the last day of February, then returns to the 31st for March.
Billing cycles and plan changes
When a customer changes plans mid-cycle, the billing cycle does not reset. The customer's renewal date stays the same. The proration calculation adjusts the charges for the remaining days in the current cycle, and the new plan takes full effect at the next renewal.
For example, a customer whose cycle runs from the 10th to the 10th upgrades on the 25th. They receive a prorated credit for 15 unused days on the old plan and a prorated charge for 15 days on the new plan. The next invoice on the 10th charges the full new plan price.
This behavior is intentional. Keeping the original anchor date means the customer's billing date is predictable and does not shift with every plan change.
Why billing cycles matter
Every billing calculation references the billing cycle. Proration uses the cycle's total days to compute daily rates. Usage quotas reset at cycle boundaries. Overage is measured against the cycle's quota. Invoice generation triggers at cycle close.
If the billing cycle is wrong, every downstream calculation is wrong. A one-day error in cycle length changes every prorated amount, every usage attribution, and every overage calculation across every customer on that billing date.
Related
- Recurring Billing: the automated charge process that operates within each billing cycle
- Proration: mid-cycle plan change calculations that depend on cycle length
- Subscription Billing: the broader model that billing cycles support
- Invoices and Billing Cycles: detailed documentation on cycle mechanics and invoice generation