#nick-billing_cycle_anchor

1 messages · Page 1 of 1 (latest)

tame summit
muted stag
#

Hey there 👋 are you seeing an invoice being generated and charged when using trial_end to move the billing cycle anchor?

tame summit
#

Yes can you please elaborate on:

without having Stripe finalize and attempt to charge the upcoming invoice?

cursive cave
#

I would have expected adding a trial with proration_behavior=none to at most create a $0 invoice?

#

This is the CLI command I ran to do the update: stripe subscriptions update sub_K3G048D8yMfoTT -d "proration_behavior"=none -d "trial_end"=1633060800

muted stag
#

Instead of none for proration_behavior, could you try using create_prorations while also setting proration_date to the same value that you are using for trial_end and see if that does what you're expecting?

cursive cave
#

Will try and let you know

#

So I don't think it created any invoice at all this time

#

Is that what you expected to happen @muted stag ?

muted stag
#

According to the events on the subscription I did this on in my account, a $0 invoice was created/charged.

#

It also moved the billing cycle anchor to the desired date, and took into account what the customer paid for up front and prorated the next invoice to account for this.

cursive cave
#

So what would have happened if in the previous month, this customer paid more than $0? Wouldn't that get prorated on the first of oct?

muted stag
#

For my scenario:

  • A subscription was created today (Sept 29) - to be billed monthly at $75 a month.
  • The customer paid this immediately because we bill upfront
  • I introduced a trial period to move the billing_cycle_anchor to the 1st of the month (in this case Oct 1st)
  • The customer is scheduled to be billed again on Oct 1 for $75 but they are being credited $70 for the 28 days that they didn't use from when they paid previously. So they will be billed $5.
cursive cave
#

I think the problem is because I have line items that utilize prices that the subscription isn't subscribed to

#

We bill the next month up front at $0, and then calculate the actual invoice (its a per seat model, full month and partial month users) nightly to get a "forecasted" total. These seem to be what get charged every time

unknown.png
#

I think I can get the desired result by adding some code to delete the non-zero line-items before adjusting the trial, and then adding them back later. That should bill at $0 for the adjustment, and then I can fix the invoice later

muted stag
#

Apologies, juggling a couple threads at the moment, will get back to this and review the additional details asap.

cursive cave
#

Thanks!

muted stag
#

Ah, I think I see what you're saying, but just want to be sure. Some of the items being pulled into the invoice aren't from the subscription that you're shifting the billing anchor for?

cursive cave
#

We bill per seat at the end of the month. So we have 3 prices per product

  1. the price that you actually subscribe to, with a $0 quantity
  2. the price for a user that was active the full month
  3. the price for a user that was active part of the month

We add 2 and 3 to the upcoming invoice nightly, it's like our own version of your metred billing

#

So it seems that when I adjust the subscription, if any of 2 and 3 have a non-zero value, it'll charge them

muted stag
#

It does seem like building an approach that does the following would work, but I'm still consulting with teammates to see if there is an easier option:

  1. Delete the pending invoice items from the customer (being sure to save all of their information)
  2. Add the trial period to shift the billing anchor on the sub
  3. Wait for the $0 invoice to generate and complete
  4. Recreate the pending invoice items with the information saved from step 1