## TL;DR

On a Stripe invoice, coupons reduce the subtotal first and customer balance (credit) applies against what remains. So a 20 percent coupon plus a 50 credit on a 200 invoice yields 160 after the coupon, then 110 after the credit, not some other combination. When the numbers look off, check this order before assuming a bug. If you need a different effective order, convert one of the two into the other form: turn the coupon into a fixed credit or the credit into a coupon.

## The query

```text
Stripe discount stacking on invoices: coupon plus customer balance order
```

## Use this when

- Invoice total wrong when a coupon and credit both apply
- Understanding Stripe discount application order
- Customer balance not reducing the invoice as expected

## Not for

- Tax computation order (separate rules)
- Multiple coupons on one invoice (Stripe allows one coupon per customer/subscription by default)

## Steps

1. Pull the finalized invoice and read the discount lines and the starting_balance / ending_balance fields.
   Expected output: You see the actual application order on the record.
2. Verify the coupon applied to the subtotal before the balance.
   Expected output: The math matches: coupon first, credit second.
3. If the coupon is percentage-based, confirm it computed on the pre-credit subtotal.
   Expected output: No double-dipping surprises.
4. If the business wants credit applied first, restructure: use a fixed-amount coupon instead of balance.
   Expected output: The effective order matches the commercial intent.
5. Document the order in your billing runbook for support.
   Expected output: Discount-stacking questions get a canonical answer.

## Variant phrasings

### Stripe coupon and customer balance order

### discount stacking Stripe invoice

### customer balance applied before or after coupon Stripe

## Root cause

Coupons apply first because they are discounts on the sale itself, while customer balance is a payment-like credit against the amount owed. The invoice object models them in separate fields (discounts vs starting_balance), which is why the order is fixed rather than configurable.

## Edge cases

- Negative invoice totals from over-stacking become customer balance credit automatically
- Proration invoices follow the same order; verify with the upcoming-invoice preview

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IiL8UyTRIms6ke17l9nzEA