Stripe Billing Cycle Anchors and the Day Revenue Lands

Two businesses run the same subscription product at the same price with the same 400 customers. One of them collects on the first of the month, in a single batch. The other collects on 400 different days, because every customer bills on whatever date they happened to sign up.

Same revenue. Same customers. Completely different books, completely different month-end, and completely different answers to "how much did we bill in February".

The field that decides which of those two businesses you are is the billing cycle anchor, and in most Stripe accounts nobody has ever set it deliberately.

Stop hand-keying Stripe invoices into QuickBooks. Acodei syncs finalized Stripe invoices and their payments into QuickBooks Online, whatever day of the month they land on. Start a free trial.

The anchor is what decides your billing date

Stripe is direct about it. A subscription's billing period depends on two factors: the recurring interval of its price, and the anchor.

The billing cycle anchor is "the reference point that aligns future billing period dates. It sets the day of week for week intervals, the day of month for month and year intervals, and the month of year for year intervals."

Then the sentence that explains why so few businesses have chosen theirs: "The default value is either the subscription creation date or the trial end date (if you're using a trial period)."

If nobody set it, your billing calendar is a record of when people happened to click subscribe. That is not a decision anyone made. It is the absence of one, and it shapes every revenue report you will ever run.

Stripe's examples make the mechanics concrete:

• A monthly subscription anchored to September 2 "always bills on the 2nd day of the month."
• A weekly subscription anchored to Friday, June 3 "bills every Friday thereafter."
• A monthly subscription anchored to January 31 "bills the last day of the month closest to the anchor date, so February 28 (or February 29 in a leap year), then March 31, April 30, and so on."

That third one is the interesting case, and it is the one worth setting on purpose.

Anchoring to month end, and the field that handles short months

If you want every subscription to renew at the end of the month, the anchor timestamp alone is an awkward way to say so, because months are different lengths.

Stripe's answer is a separate parameter. For monthly and yearly subscriptions it recommends billing_cycle_anchor_config over a raw timestamp "because it automatically factors in short months and leap years for you." Set day_of_month to 31 "to create a monthly subscription that renews at the end of the month, even in months with less than 31 days. If a month has less than 31 days, the subscription renews on the last day of that month."

The same parameter carries month for yearly and multi-month subscriptions. Stripe's example is a fiscal-year alignment: to cycle yearly subscriptions on the first of July, create the subscription with a month of 7 and a day_of_month of 1.

Two details in that parameter cause trouble later if you do not know them at setup.

The clock is UTC. You can specify hour, minute and second, and "if you don't specify the hour, minute, and second, they default to the values of the subscription creation time." Stripe then says what that means: "The billing cycle anchor uses Coordinated Universal Time (UTC). For example, if you create a subscription using billing_cycle_anchor_config at 5 PM EST without specifying the hour, the time is recorded in the system as 10 PM UTC."

Create subscriptions in the evening in North America and some of your anchors land on the following day in UTC. That timestamp is what every downstream system reads, including the invoice that eventually reaches your accounting file. A subscription an operator thinks of as billing on the 31st can produce documents dated the 1st.

The anchor can sit further out than the first invoice. Stripe warns that billing_cycle_anchor_config "might result in a billing_cycle_anchor that's more than one billing period in the future. However, the date for the first full invoice always falls within one billing period from the creation of the subscription."

Their example is a two-month subscription created in February with day_of_month set to 31. The next month with 31 days on two-month intervals from February is August, so the anchor lands on August 31. The customer is still invoiced in February: "There's an initial, prorated period from subscription creation until February 28 (or 29 during a leap year), followed by a full two-month billing period."

Which brings up the invoice most people are not expecting.

The stub invoice at the start of every anchored subscription

When you anchor a subscription to a date that is not its start date, you have created a gap, and Stripe bills for it.

"Regardless of which API parameter you use, Stripe automatically creates a prorated invoice to bill for the period between the subscription creation date and the first full invoice date."

So a customer who signs up on the 12th on a plan anchored to the 1st gets two documents in their first month: a prorated invoice for the 12th to the 1st, and then a full invoice on the 1st. Neither is wrong, and neither is the plan price.

If you do not want that first charge, Stripe documents two alternatives, and they behave differently in your books.

Disable the proration. Set proration_behavior to none, "making the initial period up to the first full invoice date free. This action doesn't generate an invoice at all until the first billing period." No stub charge, and no stub document either. The customer's first invoice is a full one, dated at the anchor.

Combine the anchor with a trial. Set trial_end to the date the trial ends. Stripe notes this "might result in a prorated invoice following the trial period", and gives the arithmetic: with a 7 day trial and monthly billing on the 1st, a customer who subscribes on the 15th gets a prorated invoice on the 22nd covering the 22nd to the 1st, then full invoices on the 1st thereafter. A customer who subscribes on the 28th has a trial that runs past the 1st, so the prorated invoice waits until the following month.

The reason this matters for accounting rather than for billing is counting. In the first month of any anchored cohort, the number of invoices is not the number of customers, and the amounts are not the plan price. Anyone reconciling invoice counts against subscriber counts is going to find a discrepancy that is not a discrepancy.

Changing the anchor on a subscription that is already running

Moving an existing customer to a new billing date is where the real money errors live, because the customer has already paid for days you are about to re-bill.

Stripe documents two deliberate routes.

Reset to now. Update the subscription with billing_cycle_anchor set to now, which sets the anchor to the time of the update request. "After you reset the billing cycle anchor, Stripe immediately sends an invoice." The warning attached to it is the important half: enable proration to credit the customer for days already paid in the previous period, because "disabling proration might result in overcharging your customer."

There is a mode-specific exception worth checking before you script this against a lot of subscriptions. In flexible billing mode, "resetting the billing cycle anchor to now doesn't automatically generate a new invoice. To trigger an invoice on a BCA reset, you must also set proration_behavior to always_invoice." Stripe notes one exception to the exception: if you change subscription items alongside the reset so the prorations do not fully cancel, an invoice is generated regardless.

Use a trial to move the date. Setting trial_end moves the anchor to the trial end date. Stripe's worked example is the cleanest description of what your books will show. A customer bills next on July 23. On July 15 you add a trial ending August 1. The customer "receives a 0 USD invoice on July 15", is not billed on July 23, and the new cycle billed on August 1 "is a full cycle at the normal rate, then again on the 1st of each month after that."

The days between the 24th and the 31st are the free ones, because the customer already paid through July 23. Stripe recommends proration_behavior=none here for exactly that reason: "the length of the trial period accounts for the portion already paid from the previous billing period."

That route produces a zero dollar invoice, and zero dollar invoices are the one part of this that has a specific rule on the QuickBooks side. More on that below.

The anchor resets nobody asked for

The routes above are deliberate. These are not, and each one moves a customer's billing date as a side effect of something else.

Stripe lists them plainly. The billing cycle date changes when:

• All prices on the subscription are zero-amount and you add a paid price, which "immediately resets the billing period."
• You set or change cancel_at to a date before the subscription would next renew, in which case the anchor "resets to the cancel_at date."
• You switch a subscription to a price with a different recurring.interval, in which case the anchor "resets to the current time."

That last one is the one to write down. Moving a customer from monthly to annual, the most ordinary upgrade there is, resets their anchor to the moment you did it. A business that carefully aligned every customer to the first of the month loses that alignment one upgrade at a time, and nothing about the change looks like a billing-date change while you are making it.

One qualifier, and it is a significant one: Stripe states that "if you create or update a subscription with billing_mode[type]=flexible, the billing cycle anchor remains unchanged." Which billing mode your subscriptions use decides whether these resets apply to you at all, so check before you assume either way.

What all of this looks like in QuickBooks

Here the honest answer is narrower than the Stripe half, and the narrowness is the point.

Acodei's documented trigger is the finalized Stripe invoice. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice reproducing every line item, and tax lines, as your mapping settings allow. When it is paid, by a successful charge, by a manual payment according to your settings, or by a credit balance offset, a QuickBooks Payment Receipt or Credit Memo follows and is applied to the invoice created earlier.

Nothing documented in that path reads the anchor, and nothing needs to. An anchor change is not a special event. It changes how many invoices Stripe produces and what dates they carry, and each of those invoices then travels the ordinary route. Telling one kind of invoice from another once they arrive is a separate exercise, worked through in what a Stripe invoice's billing reason tells you. Which is why the anchor decision belongs at the Stripe end: by the time a document reaches your accounting system, the shape is already set.

Two specifics are worth knowing before you go looking for records.

Zero dollar invoices have their own rule. The trial route above produces one, and it may not appear in QuickBooks at all. Acodei's documented behaviour is that an invoice containing only zero-amount line items is not synced. An invoice whose amount due is zero but which carries at least one line item above zero can sync, but only when the admin-level setting for zero dollar invoices is enabled, and that setting is off by default. So a 0 USD invoice generated by moving somebody's billing date is a document that may exist in Stripe and not in your books. The full treatment of that case, including the negative-total variant, is in zero dollar and negative Stripe invoices in QuickBooks.

Service dates are a separate question from billing dates. Acodei documents three mutually exclusive Service and Supply Date toggles, all Admin-level and all off by default. Nothing documented writes a per-line service period into QuickBooks. That distinction, and why the invoice-level period is not the service period, is worked through in mixed interval subscriptions and the invoice covering two service periods. If your deferral schedule reads the invoice date rather than the line period, read that one before you change any anchors.

Choosing an anchor policy on purpose

There are really only two policies, and each has a shape your accounting will inherit.

Anchor everyone to a fixed date. Invoices arrive in one batch, revenue lands in a concentrated block, failed payments cluster on the same days, and the month has a clear billing event in it. Reconciliation is simpler because the volume is predictable. The costs are a stub invoice or a free stub period at the start of every subscription, and a single day each month where a payment provider outage would affect your entire book.

Anchor to each customer's start date. No stub invoices, no proration at signup, and revenue that arrives evenly. The cost is that every day is a billing day, dunning runs continuously, and month-over-month comparisons include a variable number of billing days per customer cohort.

Neither is more correct. What is not defensible is the third option, which is what most accounts actually run: a mix, because a few customers were anchored deliberately, some upgraded and got silently reset, and the rest kept whatever date they signed up on.

The check is quick. Pull your active subscriptions, group them by the day of month in billing_cycle_anchor, and look at the distribution. If you meant to bill everyone on the 1st and you see a scatter, the resets above are where it came from. Pair that with the month end close checklist so the shape you find is the shape you reconcile against.

For deferral, the anchor is what sets the period boundaries, and the boundaries are what the schedule is built on. Revenue recognition for Stripe subscriptions covers the schedule itself. If you are migrating subscriptions in from another system and need existing billing dates preserved, the anchor travels with backdate_start_date, and that combination is covered in backdating a Stripe subscription.

Frequently asked questions

What is a billing cycle anchor in Stripe?

It is the reference point that aligns future billing period dates on a subscription. Stripe documents it as setting the day of week for weekly intervals, the day of month for monthly and yearly intervals, and the month of year for yearly intervals. If you do not set one, the default is either the subscription creation date or the trial end date when a trial is used.

How do I make every Stripe subscription bill on the first of the month?

Set the anchor when you create the subscription. For monthly and yearly prices Stripe recommends billing_cycle_anchor_config with day_of_month set to 1, because it handles short months and leap years for you. Expect a prorated invoice covering the period between signup and the first full invoice date, unless you disable proration or use a trial to bridge the gap.

What happens to a monthly subscription anchored to the 31st?

Stripe bills it on the last day of the month closest to the anchor date. A subscription anchored to January 31 bills on February 28, or February 29 in a leap year, then March 31, then April 30. Setting day_of_month to 31 through billing_cycle_anchor_config produces the same end-of-month behaviour without you calculating timestamps.

Does changing a Stripe subscription's billing date charge the customer twice?

It can, and Stripe warns about it. When you reset the anchor to now, Stripe immediately sends an invoice, and disabling proration at that moment might result in overcharging the customer for days they already paid for in the previous cycle. Enabling proration credits those days back. Using a trial that ends on the new billing date achieves the same alignment without a proration, because the free days account for the portion already paid.

Can a Stripe subscription's billing date change without me changing it?

Yes. Stripe documents three cases: adding a paid price to a subscription whose prices are all zero-amount resets the billing period immediately, setting a cancel_at date earlier than the next renewal resets the anchor to that date, and switching to a price with a different recurring interval resets the anchor to the current time. That last one means a monthly to annual upgrade moves the customer's billing date. Stripe also states that the anchor remains unchanged when creating or updating a subscription in flexible billing mode, so which mode you run decides whether these apply.

Does an anchor change create a special record in QuickBooks?

No. Acodei's documented trigger is the finalized Stripe invoice, which becomes a QuickBooks Invoice reproducing every line item and tax lines as your mapping settings allow, with a Payment Receipt or Credit Memo following when the invoice is paid. An anchor change alters how many invoices Stripe produces and what dates they carry, and each one then follows that ordinary path.

Will the zero dollar invoice from a trial-based anchor change reach QuickBooks?

Not necessarily. An invoice containing only zero-amount line items is not synced. An invoice with an amount due of zero but at least one line item above zero can sync, but only when the admin-level zero dollar invoice setting is enabled, and it is off by default. If you move billing dates using a trial, expect the 0 USD invoice to exist in Stripe without a matching document in QuickBooks unless that setting is on.

The takeaway

The anchor is a one-field decision that determines the shape of every subsequent month: how many invoices you get, when they arrive, whether the first one is a partial, and where a period boundary falls relative to your close.

Set it deliberately at creation, know which routine changes reset it, and check the distribution of anchors across your active subscriptions before you trust a month-over-month comparison. The books downstream will reproduce whatever pattern you chose, including the one you did not choose.

Ready to stop rebuilding Stripe invoices by hand? Acodei posts finalized Stripe invoices and their payments into QuickBooks Online, with your line items, products, and tax treatment already applied. Start a free trial.