Stripe Usage Billing When the Price Changes Mid-Period

If you raise the price of a metered product in the middle of a billing period, one of two things happens to the usage your customers already ran up. Either Stripe bills it at the price it was reported at, or Stripe does not bill it at all.

Which one you get is decided by a subscription setting most teams have never looked at, it is not reversible in one direction, and the difference on Stripe's own worked example is 0.75 USD against 1.75 USD for identical meter readings. That is not a rounding difference. It is revenue that either exists or does not.

If you are syncing Stripe to QuickBooks and you want the invoice to be right before it becomes a journal entry, start a free trial or see how the integration works.

The setting is billing mode, and it is per subscription

Stripe has two billing modes, classic and flexible. Every subscription is in one of them, and most of what follows is a consequence of which one.

The mode is not an account-level switch you flip once. It belongs to the subscription, which means a book of business built up over several years can hold both, and the same price change can produce two different invoices for two customers on the same plan.

It is also close to permanent. Stripe states it flatly on the comparison of classic and flexible billing mode: "You can't migrate a subscription from flexible billing mode to classic billing mode." You can go one way. You cannot go back.

We have covered what billing mode does to backdated subscriptions, where it decides whether you get one prorated line or one line per period, and to subscriptions carrying two different intervals, which flexible mode allows and classic does not. This post is about the third thing it decides, which is the one that touches revenue rather than presentation: what happens to metered usage that was reported before a price change.

Stripe's worked example, and the usage that disappears

Stripe publishes the case directly. Set up a meter priced at 0.1 USD per 100 API calls. On January 5 the customer runs 1,000 calls. On January 15 you raise the price to 0.15 USD per 100 calls. On January 20 the customer runs another 500 calls.

Under classic, in Stripe's words, "Stripe only bills for the usage that was reported since changing to the current price." The invoice carries 500 calls at the new price. Total: 0.75 USD.

Under flexible, "Stripe bills for all usage in the current period at the price effective at the time it's reported." The invoice carries 1,000 calls at the old price plus 500 calls at the new one. Total: 1.75 USD.

Sit with the classic number for a moment, because the framing matters more than the arithmetic. The 1,000 calls on January 5 are not billed late, and they are not billed at the wrong price. They are not billed. The meter recorded them, the customer consumed them, and no invoice line will ever carry them. Stripe's summary of flexible mode is the giveaway: it "charges for usage based on the price that was in effect when the usage was reported, rather than the most recent price." Classic has only one price to work with, the current one, and usage reported before that price existed falls outside the window.

For a bookkeeper this is a different problem from the ones price changes usually create. A price change that bills at the wrong rate produces a variance you can find, because there is a line to compare against. A price change that silently drops a partial period of usage produces nothing at all: no line, no variance, no exception report. Your revenue for the month is lower and every document you own agrees that it should be.

When usage counts as "reported"

The rule turns on when usage was reported, so it is worth knowing what Stripe records about that moment.

A meter event carries two timestamps. Stripe's meter event object documents created as "Time at which the object was created" and timestamp as "The timestamp passed in when creating the event." Those are different things whenever you batch. A nightly job that ships Monday's usage on Tuesday morning produces events whose timestamp says Monday and whose created says Tuesday.

Stripe's comparison page says "the price effective at the time it's reported" and does not say which of those two fields decides it. That is a gap worth closing against your own data rather than assuming, because the two answers diverge exactly when a price change lands between the usage and the upload. If you batch usage and you are planning a price change, the safest sequence is to flush the meter before the new price goes live, which makes the question moot.

There is a second timing fact in the same area. Stripe notes that it "processes meter events asynchronously, so aggregated usage in meter event summaries and on upcoming invoices might not immediately reflect recently received meter events." An upcoming-invoice preview taken seconds after an upload is not evidence that the upload failed, and it is not evidence that it worked either.

The object that holds all this is the Stripe billing meter, and the amount that reaches the invoice is a Stripe invoice line item like any other once the period closes. Meters also gate a feature that has nothing to do with price changes and everything to do with the same objects: Stripe billing credits can only be applied to subscription items on metered prices that report through Meters, which is why a legacy usage integration quietly fails to accept them.

The zero-amount line that classic writes and flexible does not

The same split shows up at the other end of a usage item's life, when you add one.

Stripe: "Flexible billing mode doesn't create zero-amount line items when you add usage-based items to a subscription. If the invoice is empty as a result, we don't generate one." Classic does the opposite: "A 0 USD line item is generated on the invoice for the usage-based item. This also applies when updating a subscription without cycling to add a usage-based item while using proration_behavior=always_invoice."

There is a carve-out worth reading twice, because it reverses the rule at the moment most invoices are actually produced. Stripe: "However, this doesn't apply to invoices generated during cycling. The invoice contains all usage-based items, including 0 USD line items." So flexible suppresses the zero line when you add the item mid-period, and keeps it on the regular renewal invoice. A customer who used nothing this month still gets a line saying so.

That distinction matters for reconciliation more than for revenue. A zero line changes no total. It changes whether a document exists, and whether a product appears on it.

What actually reaches QuickBooks

Here the Acodei side is straightforward, and the honest version of it is mostly a statement about where the decision was made.

Acodei acts on the finalized Stripe invoice. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice that reproduces every line item, and the tax lines, as the account's mapping settings allow. When the invoice is paid, by a successful charge, by a manual payment according to the account's settings, or by a credit balance offset, Acodei creates a QuickBooks Payment Receipt or Credit Memo and applies it to that invoice, with the automatic application that QuickBooks itself has to have switched on. Each line uses the product returned by Multiple Product Mapping where it is enabled, and the default product otherwise.

Nothing in that path reads a meter. Acodei's documentation covers no reading of meters, no reading of usage records, and no handling of unbilled usage. It does not need to: by the time an invoice is finalized, Stripe has already resolved which usage is on it and at which price. Everything in the sections above happens upstream of anything Acodei sees.

The practical consequence is the one that catches people. If classic mode dropped a partial period of usage, the Stripe invoice is still internally consistent and still adds up: its lines and its total agree, and the missing usage is missing from both. What reaches QuickBooks is a faithful copy of a document that was already short, and nothing about a faithful copy looks wrong. The place that discrepancy is visible is the meter, not the ledger.

One documented behaviour does interact directly with the zero-amount rule. An invoice whose line items are all zero is not synced at all. There is a separate admin-level setting that allows an invoice with an amount due of zero to sync when at least one of its lines is above zero, and it is off by default. Put those together with the classic behaviour above and you get a small, tidy result: if classic generates an invoice carrying only a 0 USD usage line, nothing lands in QuickBooks. Flexible would not have generated the invoice in the first place. Two different mechanisms, the same empty outcome, and neither one is a fault.

Stripe fees are never added to these invoices, since that would break the total against Stripe's own. They are handled separately, through sales receipts, deposits or expenses depending on the account's fee settings. Our walkthrough of which sync settings change your books covers the ones that do move numbers.

Removing a usage item, and the unbilled usage attached to it

The third place billing mode changes the money is deletion, and it is the reverse of the price-change case: here it is flexible that bills more.

When you remove a usage-based subscription item through the API, classic generates no invoice item and no invoice for the unbilled usage sitting on it. Flexible generates an invoice item for it. The usage happened either way. Only one mode asks the customer to pay for it.

Through a subscription schedule phase transition, the behaviour forks again on the incoming phase's proration setting. Stripe's own breakdown: under create_prorations, an invoice item is created for the unbilled usage. Under always_invoice, that invoice item is created and immediately invoiced. Under none, no invoice item is created at all. Classic, by contrast, generates an invoice but no invoice item for the same transition.

If you run plan migrations through schedules, that middle column is where a migration quietly writes off the current period's usage. It is worth checking which value your phases carry before you run a batch of them, not after.

One invoice or two at a phase transition

A smaller difference, but one that shows up in the books as a document count rather than a total.

When a subscription with usage-based items moves between schedule phases, classic generates two invoices. Flexible generates a single consolidated one, which Stripe says "includes both usage-based and licensed items, applies discounts from the previous phase to usage-based billing, and uses tax rates from the next phase."

Read that last clause carefully, because it decides a tax question by fiat. On a consolidated invoice spanning a phase boundary, the next phase's tax rates apply to the whole document, including the usage billed under the previous phase. If a phase transition coincides with a tax rate change, the usage from the old phase is taxed at the new rate. That is a defensible choice and it is documented, but it is not what most people would guess.

Two invoices against one also changes what your reconciliation expects to find, and it changes how the period splits if you are recognising revenue by service date rather than invoice date. We cover that split in revenue recognition for Stripe in QuickBooks.

What to check in your own account

Five things, in the order that matters.

1. Find out which mode your subscriptions are in. Not your account, your subscriptions. Expect a mix if you have been on Stripe for more than a year or two.
2. Before any price change on a metered product, decide what happens to usage already reported this period. On flexible it is billed at the old price. On classic it is not billed.
3. If you batch usage uploads, flush the meter before the new price goes live. That removes the question of which timestamp Stripe reads.
4. Check the proration setting on any schedule phase that removes a usage item. none writes off the current period's usage silently.
5. After the first invoice under a new price, compare one invoice against the meter by hand. One document, once. It is the only check that tests the whole path rather than your understanding of it.

Everything on that list is a Stripe-side decision. The QuickBooks side inherits the answer.

Frequently asked questions

What is the difference between classic and flexible billing mode for usage?

Flexible billing mode charges for usage based on the price that was in effect when the usage was reported, rather than the most recent price. Classic only bills for usage reported since the current price took effect. On Stripe's own example, the same 1,500 metered calls across a mid-period price change produce a 1.75 USD invoice under flexible and a 0.75 USD invoice under classic.

Why is my Stripe usage invoice lower than the meter says?

If the subscription is in classic billing mode and the price changed during the period, usage reported before the change is not billed. Stripe bills only what was reported since the current price took effect. The meter total and the invoice total are both correct and they are measuring different things.

Can I switch a subscription from classic to flexible billing mode?

You can move a subscription from classic to flexible. You cannot move it back: Stripe states that you can't migrate a subscription from flexible billing mode to classic billing mode. Treat it as a one-way decision per subscription.

Does Stripe use the meter event timestamp or the creation time to price usage?

Stripe's comparison page says usage is billed at "the price effective at the time it's reported" without specifying which field. A meter event carries both a timestamp you pass in and a created time recorded by Stripe, and they differ whenever usage is uploaded in batches. Check one invoice against your own events rather than assuming, or upload before a price change so the two cannot disagree.

Why did adding a usage-based item not create an invoice?

In flexible billing mode, adding a usage-based item does not create a zero-amount line item, and if the invoice would be empty as a result, Stripe does not generate one. Classic generates a 0 USD line item instead. Note that this suppression does not apply to renewal invoices, which carry all usage-based items including zero-amount ones.

Does Acodei read Stripe meters or usage records?

No. Acodei's documentation covers no reading of meters, usage records or unbilled usage. It creates a QuickBooks Invoice from the finalized Stripe invoice, reproducing every line item and the tax lines as your mapping settings allow. Which usage is on that invoice, and at what price, is settled by Stripe before Acodei sees it.

What happens in QuickBooks if the Stripe invoice has only a zero-amount line?

An invoice whose line items are all zero is not synced. A separate admin-level setting allows an invoice with a zero amount due to sync when at least one line is above zero, and it is off by default. So a classic-mode invoice carrying only a 0 USD usage line produces no QuickBooks record, and in flexible mode the invoice would not have been generated at all.

Does removing a usage-based item bill the usage on it?

It depends on the mode. Removing a usage-based item through the API generates an invoice item for the unbilled usage under flexible, and no invoice item or invoice under classic. Through a schedule phase transition, flexible follows the incoming phase's proration behaviour: create_prorations creates the invoice item, always_invoice creates and invoices it immediately, and none creates nothing.

The short version

Billing mode is not a formatting preference. On metered products it decides whether a partial period of usage is revenue or nothing, whether removing an item collects the usage attached to it, and which phase's tax rates apply when two periods land on one invoice. It is set per subscription, and the migration only runs one way.

None of that is visible from QuickBooks, because by the time an invoice syncs, the question has already been answered. The place to look is Stripe, and the moment to look is before the price changes rather than after the month closes.

Acodei syncs the invoice Stripe finalized, line for line, into QuickBooks, so that the only thing you have to get right is the invoice. Start a free trial, or read more about how the Stripe to QuickBooks sync works.