#Gkiokan-invoice

1 messages · Page 1 of 1 (latest)

olive dagger
#

hi! this is going to be hard to help with without having access to your account and speaking German so it might be easier to work with Support.

Overall I think you're missing the fact the proration is time-based

#

But why is the ìnvoice.subtotal` is 53,70 and not 35,80 as expected?
the invoice charges for 3 separate things:

#
  1. the updated Price : so that's 2 * 17,90 EUR = 35,80. yes , the line item called 2 × Premium (at €17.90 / month)
#
  1. it charges for time between the time you make the update call and the start of the next billing cycle, on a prorated basis (i.e what percentage of the month is left, that percentage of the new Price). That's Remaining time on 2 × Premium after 31 May 2022
olive sky
#

so far correct

olive dagger
#
  1. it credits (negative amount) for unused time on the old price, prorated in the same way(what percentage of the month was already paid for on the old plan). That's Unused time on Premium after 31 May 2022
#

so its 35.80 + 35.80 - 17.90 which is what you see

olive sky
#

But isn't the customer charged already for the first 35,80?

olive dagger
#

yep, and now they are getting a refund for that, and charged instead on a prorated basis for 2x35.80

#

But isn't the customer charged already for the first 35,80?
actually, no

olive sky
#

But this is not shown on the upcomming invoice

#

Maybe it helps when I try to explain the flow what the dashboard does

olive dagger
#

we help with API questions here

olive sky
#

Sure. It would help me if the upcomming invoice would only show the next month and not the next 2 months

olive dagger
#

it does

olive sky
#

Currently it is overcharging the customer

olive dagger
#

or a different subscription

olive sky
#

yep this is the correct subscription

olive dagger
#

ok then give me a few minutes to understand that specific subscription

#

ok so

#

ugh

#

will try again in a bit..

olive sky
#

Can you run the upcomming invoice api on that customer to see what I mean? I think the dashboard shows it correct but the response of upcomming invoice have a different subtotal due the additional calculation of the overnext month

#

I would assume that the current invoice would be updated for theperiod of 31.05.2022 - 30.06.2022 which says (35,80 - 17,90) which is correct because existig quantity upgraded from 1 to 2

#

But it calculates the months 05, 06 (with the changes) + 07

olive dagger
#

ok so

  1. you create the subscription using the €0 plan, on a trial period until 30 June. No charge yet since it's a trial. That's the €0 invoice in_1L5So3Ha5WPIKK5IKbfaSRew

  2. you change the subscription a few minutes later to replace the €0 plan with a €189 one. Per https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment that resets the billing cycle and charges for the amount upfront. That's what in_1L5SqLHa5WPIKK5ICaPXoglS is

  3. you change the subscription a few minutes later to replace the €0 plan with a €17.90 one. Since you use proration_behavior:always_invoice, that generates an invoice to refund the customer the €189 they paid and charge them a prorated amount for the 17.90, which works out to negative €171.90 , which is in_1L5SzCHa5WPIKK5I1hkf1fVd

  4. you change the subscription a few minutes later to change the quantity of the €17.90 plan to 2. No immediate invoice this time. So instead, proration items are created. As described above, that is a prorated refund of the 17.90 plus prorated charge of 2x17.90, which is €35.80 - €17.90. Since this is the upcoming invoice, it also includes the amount of the next billing period, so that's another €35.80. So 35.80- 17.90 + 35.80 = 53.70 and looks totally normal to me

olive sky
#

I see. I think I get confused because there is the proration that flows into the next invoice but is not shown directly because no immediate invoice.

olive dagger
#

yes, because you used proration_behavor:create_prorations on that last update instead of always_invoice

#

so what it does is create "floating" proration line items, those get pulled into the next invoice for the customer

#

the upcoming invoice is going to be for the current, updated status of the subscription (2x 17.90), plus any floating line items it pulls in

#

which is exactly what you see

olive sky
#

I see. That makes total sense, sure. Is there a way to put all the changes from one period that belongs to one invoice together?

#

Like when I did the Step 3 and doe changes afterwards like on Step 4, that thoose changes will be reflected on the current invoice, too. Is this even possible or is this not the way how it works?

olive dagger
#

don't follow you, sorry.

olive sky
#

When I change the subscription and invoice the customer immediately and have quantity changes afterwards, can we put the quantity changes on that invoice or are they always shown on the upcomming invoice?

olive dagger
#

well you could combine them

#

like have the API call change to the new Price and the new quantity at the same time, instead of doing steps 3 and 4 separately as you did in this case

olive sky
#

I see

olive dagger
olive sky
#

But in my app use case the user can upgrade the quantity based on his registered users so this is a thing I must be able to change anytime he upgrades and prorate as stripe does.

#

I will have a deeper look into that. Thanks for your help

#

One quick question. Which property on the upcomming invoice response shows me when the customer will be charged for it?

#

next_payment_attempt would be always set right?

median marsh
#

Hey! Taking over here

#

next_payment_attempt is likely the best option here. due_date won't be set for charge_automatically subscriptions

olive sky
#

perfect, thanks