Stripe deprecated quantity on invoice items. Here's what it breaks downstream.

This is the first entry in our API-changes log: vendor changes in the HubSpot / Stripe / QuickBooks chain, what each one breaks, and what to do about it. We track these so the integrations we run don't stop working on a Tuesday.

What changed

With the 2026-03-25.dahlia API version, Stripe added decimal quantity support for Invoice Items and Invoice Line Items, with up to 12 decimal places of precision, through a new quantity_decimal parameter that accepts string values in decimal format. The existing quantity property is now deprecated but still available, and Stripe has said it will be removed in a future breaking API version.

Alongside it, the official SDKs shipped a related breaking change: all decimal_string fields changed type from plain strings to a vendored Decimal type, affecting quantity_decimal and unit_amount_decimal on InvoiceItem and InvoiceLineItem among others, so code reading or writing these as strings has to construct and serialize them through the new type.

So there are two moving parts: a field deprecation on the API, and a type change in the SDKs.

Why it matters if you post to a ledger

On its face this is a feature — usage-based billing genuinely needs fractional quantities, and integer quantity was always a poor fit for metered products priced per GB or per API call.

The risk is in the downstream hop. A typical CRM → Stripe → QuickBooks chain reads the line items off an invoice and creates a QuickBooks SalesItemLineDetail with Qty and UnitPrice. If your code reads quantity and the real value is 2.5, one of three things happens depending on how the field is populated and how you handle it:

• You read a rounded or truncated integer and post the wrong amount
• You read null and post a line with no quantity
• Your parser throws on an unexpected type and the whole invoice fails to post

The third is the good outcome, because it's loud. The first is the dangerous one: the invoice posts, the number is wrong by a fraction, and nothing alerts. It surfaces at close as an unexplained difference between what Stripe collected and what the books show.

What to check in your own integration

1. Search your code for quantity on invoice items and line items. Anywhere you read it and pass it downstream is a candidate.
2. Check what API version you're pinned to. Stripe now ships monthly API versions and the current version at the time of writing is 2026-08-26.dahlia. A pinned older version keeps working, but it's borrowed time, and the SDK you upgrade next will move underneath you.
3. Check the destination's precision. QuickBooks accepts decimal quantities, but your own canonical model might not — if you typed the field as an integer somewhere in the middle, that's where the rounding happens, not at either end.
4. Decide the rounding rule explicitly. If a fractional quantity has to become a ledger line, someone has to decide whether you round the quantity or carry the fraction through to the amount. Carrying it through is almost always right, because the amount is what has to reconcile.

What to do

Read quantity_decimal where it's available, fall back to quantity while it exists, and store the value as a decimal type all the way through your pipeline — not an integer, not a float. Money and quantities both deserve exact arithmetic; float is how you get $1,499.9999999998 in a ledger.

If you're using an official SDK, expect the Decimal type change when you upgrade major versions and handle construction and serialization at the boundaries of your code rather than scattering it through your business logic.

The general lesson

This is a well-behaved deprecation. Stripe added the new field, kept the old one, documented the removal, and gave a long runway. That's about as good as vendor changes get.

It's still a change that will break integrations, because the failure mode isn't an error — it's a slightly wrong number in a system nobody diffs against another system. The only real defence is that somebody reads the changelogs on a schedule and asks "what does this do to the money?" for each entry.

That's not a heroic engineering activity. It's just a job that has to belong to someone, and at most companies it belongs to nobody.

TruelineHQ tracks vendor changes across HubSpot, Stripe and QuickBooks and publishes what each one would break. See how it works.