#ibgoldbergs
frigid smelt
I know we support billing in arrears for some usecases
https://stripe.com/docs/billing/subscriptions/usage-based#billing-in-arrears
tiny forge
Do you know if we should be using usage based pricing instead of quantities? Or how we should think about it?
tiny forge
Thanks
simple onyx
Yep so the way to use arrears is to use a metered Price.
Can you clarify about proration -- you do or don't want to deal with proration?
Like do you just want to bill at the end of the month for whatever the final quantity is set to?
tiny forge
We do want proration, or else we would be losing out on money
which is one of the primary reasons for wanting to bill in arrears
simple onyx
When you say "lose out on money" do you mean because of potential downgrades mid-cycle?
tiny forge
well potential upgrades mid-cycle actually
simple onyx
Well you are going to charge at the end of the cycle so the upgrade would be included, right?
Metered Prices bill in arrear based on the usage you submit over the course of the period.
So the question is really around whether or not the timing of the upgrade/downgrade matters or if you will just charge post-mortem for the actual service performed.
tiny forge
Well this is how I was thinking about it...
They have 5 essentials products, and 10 priority products, but one of those essentials upgrades to priority 15 days into the cycle (half way through the month). We should charge them for 15 days of essentials, and 15 days of priority during that month.
15 days of 5 & 10 and 15 days of 4 & 11*
simple onyx
Okay that is what I wanted to clarify.
Thanks
That does complicate things
Let me check on best way to handle that.
tiny forge
thanks
vapid pagodaBOT
tiny forge
Feel like I always bring hard ones here 🙂
simple onyx
Hmm okay yeah this is pretty tough. The main issue is that when you upgrade or downgrade the Price mid-cycle it is going to clear the usage. You can't prorate usage to cut an invoice item mid-cycle without handling this manually which gets really really complicated when you think about then trying to handle charging the correct amount for the rest of the cycle which is also just a partial amount.....
With this style of Pricing you really aren't supposed to use arrears.
Arrears are really designed for post-service payment
So there is no real proration involved
Is post-billing 100% necessary?
tiny forge
It feels like a common use-case, no?
Otherwise we have cases where people could downgrade all products to essentials every month
I think it is, because otherwise it’s an accounting reconciliation nightmare
simple onyx
No it is easy to handle proration as long as you bill at beginning of cycle
Which is the common use-case here.
I'm not sure why it is a reconciliation nightmare?
Can you clarify?
tiny forge
Because we need to account for the money in the correct month
simple onyx
People downgrading all products to essentials would still get charged the according amount for the "priority" Price on the following Invoice for the period before they downgraded.
So you are saying the blocker is that the charge would get rolled into the next Invoice?
tiny forge
So each month we need to go through invoices and say x should be accounted for in the previous month
simple onyx
Well the Invoice items specify that already
They will indicate when they are generated due to proration
tiny forge
Yeah but it’s manual invoice by invoice
simple onyx
Yeah that's really just how it works with this model.
Everyone deals with that really.
The other way forward here would be to charge immediately on upgrade or downgrade
Then you can use arrears, but the billing cycle anchor will move constantly
tiny forge
Yeah but that would mean multiple charges to customer every cycle right
simple onyx
It would mean that if they start a monthly Sub Jan 1st then upgrade or downgrade on Jan 15th they would then next get charged Feb 15th (assuming no more upgrade/downgrade during that period).
simple onyx
Yeah I think that's correct.
Not a 100% optimal way forward due to conflicting nature of the want here
tiny forge
yeah- just curious, does the ask to want support of better handling of proration here automatically make sense?
simple onyx
I mean I see your points and the use-case but I think it is just incredibly complicated to use arrears with proration. I think it would essentially require building a new billing model here.
I'm happy to put in a feature request
To ensure the team knows there is interest out there for something like this.
tiny forge
Sure, would be nice to request and I'll type up my findings and we can decide what way to go for now.
simple onyx
Sounds like a plan
tiny forge
Thanks for talking through it with me