Raising Prices on Stripe Subscriptions and QuickBooks

You have 200 customers on a $49-a-month plan and you have decided it should cost $59. In most billing tools you would edit the number. In Stripe you can't. A Price's amount is fixed once the Price exists, so a price increase is really a migration: you create a new Price, move each subscription onto it, and decide when each customer's bill changes and whether the switch is prorated.

Every one of those decisions shows up in QuickBooks. Change the price mid-cycle with the defaults and your next invoices carry proration lines on two different Price IDs. Change it at renewal and they don't. Either way the new Price ID is something your product mapping has never seen, and that is the part of a Stripe price increase that quietly sends a month of revenue to the wrong income account.

Price changes, synced as Stripe bills them. With Acodei's Invoice Sync, a paid-plan feature, a finalized Stripe invoice becomes a QuickBooks invoice with every line reproduced as your mapping settings allow, and the payment is applied when the invoice is paid. Start a free trial.

This post covers why a price increase in Stripe means a new Price, the three ways to move existing subscriptions with worked numbers for each, grandfathering, the two update mistakes that bill customers wrongly, and what to set up in QuickBooks before the first invoice at the new price is finalized.

Why you can't just edit the price in Stripe

Stripe's guide to managing prices is direct about it: "you can't change a price's amount in the API. Instead, we recommend creating a new price for the new amount, switch to the new price's ID, then update the old price to be inactive."

So the $59 plan is a different object from the $49 plan, with its own ID. Both can belong to the same Product, and that matters later, because a QuickBooks mapping can key on the Product or on the Price.

Creating the new Price changes nothing for anyone already subscribed. Their subscriptions still point at the old Price ID and keep renewing at $49 until you move them. Stripe says the same about archiving: "If you archive a price, any existing subscriptions that use the price remain active until they're canceled." Archiving stops the old Price from being used for new purchases. It does not raise anyone's bill.

New customers are the easy half. If your pricing page reads prices by lookup key, the same Stripe guide documents the move in one step: "create a new price and transfer the lookup key to that new price using transfer_lookup_key=true." New signups get $59 from then on. Existing customers need one of the three routes below.

Three ways to move existing Stripe subscriptions to the new price

Moving a customer means updating their subscription item to point at the new Price. What differs between the routes is timing and proration. All three examples use one customer, $49 a month, billed on the 1st, moved to $59 in April.

1. Update now, with proration (the default)

Stripe's subscription update reference explains what happens when you switch prices mid-period without changing anything else: "By default, we prorate subscription changes." proration_behavior defaults to create_prorations, which creates the proration items but does not invoice them right away. They wait for the next invoice.

Make the change on April 16, halfway through a 30-day month, and the May 1 invoice carries three lines:

Line	Price	Amount
Unused time on the old plan, April 16 to 30	$49 Price	-$24.50
Remaining time on the new plan, April 16 to 30	$59 Price	+$29.50
May subscription	$59 Price	+$59.00
Total		$64.00

Stripe prorates to the second, so real amounts land a few cents off these round halves. The structure is what matters. One invoice now mixes two Price IDs: the credit for late April on the old one, and the charges for late April and for May on the new one. Stripe's own proration example shows the same shape, with the credit line carrying the previous plan's Price. At 2.9% + 30¢ for a domestic card, from Stripe's pricing page, the $64.00 charge carries a $2.16 fee.

Proration is fair to the customer to the day. It is also the route that puts the most lines in front of your product mapping.

2. Update now, without proration

Pass proration_behavior=none on the same update. Stripe's proration guide describes it as disabling prorations "on a per-request basis", with no credit and no partial charge.

The customer finishes April at $49, and the May 1 invoice is one line: $59.00 on the new Price. The fee on it is $2.01.

The cost is the half month of the increase you didn't bill, $5.00 here. Across 200 customers changed mid-month, that is about $1,000 of one-time revenue you chose to give up in exchange for simpler invoices. Plenty of businesses take that trade on purpose.

Note that none applies to that one request. Stripe is explicit that "No parameter turns off all future prorations for a subscription."

3. Schedule the change for the renewal date

A subscription schedule changes the price when the current period ends, with no proration because nothing changes mid-period. Stripe's own change-price guide recommends this route: "If you're changing a subscription at the end of its billing period, consider using a subscription schedule to manage the transition."

The API route is two calls, set out in Stripe's schedule use cases. First create a schedule from the existing subscription with from_subscription, and Stripe "creates a schedule with a phase that matches the subscription's current billing period and configuration." Then update the schedule with the current phase plus a second phase on the new Price, which "starts automatically when the current phase ends."

The customer pays $49 for April and $59 from May 1, on a one-line invoice. This is the cleanest route for both the customer and your books, and it gives you a fixed date to put in a notice.

The three routes side by side

	Proration (default)	No proration	Schedule at renewal
When the new price starts	Day of the change	Next renewal	Next renewal
Partial-month charge	Yes, net +$5.00	No	No
May 1 invoice total	$64.00	$59.00	$59.00
Price IDs on the May 1 invoice	Old and new	New only	New only
Card fee on that invoice	$2.16	$2.01	$2.01

Grandfathering: leaving some customers on the old price

Grandfathering in Stripe is simply not moving a subscription. Archive the old Price so nobody new can buy it, leave the existing subscriptions alone, and they keep renewing at $49 for as long as they stay. Stripe's archive rule quoted earlier is what makes this work.

The consequence for your books is that the old Price never goes away. Every grandfathered renewal is still billed on it, and every invoice from it still needs a mapping. A price increase with grandfathering leaves you with two Price IDs producing revenue for the same product for months or years. Our post on why Stripe charges land on the wrong QuickBooks product covers that two-stream state in detail, including why deleting the old mapping row early is the mistake to avoid.

Partial grandfathering is common too. You might keep annual customers on the old price until their renewal, or give long-standing customers 6 more months. A subscription schedule handles both, because a phase can last as long as you set before the new Price starts.

Two update mistakes that bill customers wrong

Both of these come straight from Stripe's change-price guide, and both are easy to make in a script that moves 200 subscriptions at once.

Forgetting the subscription item ID. Stripe warns: "You must specify the subscription item to replace the current price with the new price. Failing to do so results in adding the new price so both prices are active for the subscription." The customer is then billed $49 and $59 every month. In QuickBooks that arrives as invoices with two subscription lines, and nothing about the sync looks wrong, because it is reproducing exactly what Stripe billed.

Dropping the quantity. "Updating a subscription price automatically reverts the quantity to the default value of 1." On a per-seat plan, a customer with 12 seats moved to the new price without passing quantity=12 is billed for one seat at the new price. That is a price increase that cuts their bill from $588 to $59, about 90%. Pass the existing quantity on every update.

There is a third trap when schedules are involved. If a subscription already has a schedule attached, Stripe says to "use the Subscription Schedule API to modify the subscription, instead of the Subscriptions API", because direct changes "might be overwritten by the subscription schedule when the next phase is entered." When you update a schedule, Stripe also notes that it "unsets omitted parameters", so a discount you forget to repeat in the new phase disappears at renewal.

How a Stripe price increase reaches QuickBooks

The billing side is only half the migration. The other half is making sure the new Price ID lands on the right QuickBooks product.

With Acodei's Invoice Sync, a finalized Stripe invoice becomes a QuickBooks invoice that reproduces every line item as your mapping settings allow. Each invoice line uses the product returned by Multiple Product Mapping if it is enabled, and the default product if it is not. Whether your price increase needs any mapping work depends on which kind of rule you use.

Product mapping without the pricing tier. All charges and invoices for that Stripe Product route to the same QuickBooks product, whichever Price was used. If both Prices belong to one Product and this is how you map it, the new Price needs no change. That is the strongest argument for keeping a price increase inside the same Product.

Product mapping with the pricing tier. Acodei stores both the Product ID and the Price ID, so it can tell, for example, a monthly Price from an annual one on the same Product. That precision cuts the other way during a price increase. The new $59 Price has no rule until you add one.

Transaction Value mapping. This matches on the gross amount, so a rule set to 49.00 does not match 59.00. Acodei's documentation names this exact limitation: if you change a product's price in Stripe and don't update the rule, transactions at the new price fail to map. Discounts break these rules the same way.

When no rule matches, one of two things happens, depending on your settings. Either the line falls back to your single catch-all default product, or Acodei logs a sync error if your configuration doesn't allow uncategorized items. The fallback is the quieter of the two. The invoice syncs, the total is right, and $59 of subscription revenue sits in whatever income account your default product points at.

Two more details from Acodei's mapping documentation set the order of operations:

• Rule changes apply to future transactions only. Mapping rules are not versioned, and a changed rule affects what syncs next, not what already synced.
• Records that errored can be retried with the new rules. Retrying or resyncing from the Sync Errors queue uses the same mapping logic with your updated rule set.

So add the mapping for the new Price before the first invoice on it is finalized. For a scheduled increase, that is any time before the renewal date. For an immediate update, it is before you run the update, because the proration items on the new Price are created at that moment and billed on the customer's next invoice.

Under the default proration route, also expect the credit line on the old Price and the charge line on the new Price to map separately, because each line is mapped on its own. If you have already removed the old Price's rule, the credit line falls back to the default product (or raises a sync error) while the charge maps correctly, and your income accounts show the April credit and the April charge in different places.

A checklist before you raise prices

1. Create the new Price on the same Product unless you have a reason not to. It keeps product-level mappings working.
2. Add the QuickBooks mapping for the new Price ID before anything is billed on it. Keep the old Price's mapping for as long as anyone is grandfathered.
3. Pick the route on purpose. Prorate for fairness, skip proration for simpler invoices, or schedule at renewal for both.
4. Script carefully. Pass the subscription item ID and the existing quantity on every update, and check for attached schedules first.
5. Preview before you commit. A Stripe preview invoice shows exactly what the next invoice will contain after the change.
6. Give customers a date. Whatever notice your terms promise, a renewal-date change gives you a specific day to name.
7. Watch the first renewal cycle. Look at the QuickBooks invoices for the first few customers on the new price and confirm the product and income account before the rest renew.

If the increase also moves customers between billing intervals, monthly to annual for example, the billing date changes too. Our post on the Stripe billing cycle anchor explains why.

FAQ

Can I change the price of an existing Stripe price?

No. Stripe states that you can't change a price's amount in the API and recommends creating a new price, switching subscriptions to the new price's ID, then making the old price inactive. You can change other properties of a Price, such as whether it is active or its metadata, but never the amount.

Does archiving a price in Stripe change what existing customers pay?

No. Stripe says that when you archive a price, existing subscriptions that use it remain active until they are canceled. Archiving only stops the price from being used for new purchases. Existing customers keep paying the old amount until you update their subscriptions or schedule a change.

How do I raise prices in Stripe without prorating?

Either pass proration_behavior=none when you update the subscription, which starts the new price at the next renewal with no credit or partial charge, or use a subscription schedule that changes the price when the current period ends. Stripe recommends the schedule for changes at the end of a billing period.

Why did a customer's quantity drop to 1 after I changed their price?

Stripe's change-price guide states that updating a subscription price automatically reverts the quantity to the default value of 1. If the customer had more than one unit, such as 12 seats, you have to include the existing quantity in the update to keep it.

Will a new Stripe price map to the right QuickBooks product?

It depends on your mapping. With Acodei, product mapping without the pricing tier sends every price on a Stripe product to the same QuickBooks product, so a new price on the same product needs no change. Mapping by price ID or by transaction value needs a new rule. Without one, lines fall back to the default product or raise a sync error, depending on your settings.

The short version

A Stripe price increase is a migration from one Price ID to another. Decide when each customer moves and whether to prorate, script the update with the item ID and quantity, and treat grandfathered customers as a second revenue stream that keeps its own mapping. Then put the new Price ID into your QuickBooks mapping before the first invoice on it is finalized, because the sync will faithfully reproduce whatever Stripe billed, on whichever product your rules point to.

Your new prices, on the right QuickBooks products. Acodei syncs finalized Stripe invoices into QuickBooks Online line by line, maps each line with your product mapping rules, and applies each payment to the invoice it paid. Start a free trial.