#geordi-proration-tax
1 messages · Page 1 of 1 (latest)
Thanks!
Can you share the IDs of these invoices? Additionally I'm seeing that there is a verbiage difference in the line between subtotal and total excluding tax, can you tell me a bit more about the steps that were taken which led up to each of these scenarios?
Absolutely.
Real:
First invoice on upgrade to higher tier: in_1LQq4LLLAsLlRiDeNz81iW4o
Adding another license on same day:
in_1LQqTNLLAsLlRiDeoJxknRI0
Test Invoice: in_1LRxRhLLAsLlRiDeGnVY9yAN
Sure. In the real case the customer was recently migrated into Stripe on one product, and upgraded to a higher tier product and on the same day added an additional seat to the subscription.
Oh, okay, multiple changes in a single day may make this look a bit confusing, taking a closer look.
Great, thank you!
Sorry about that, didn't realize there was an ongoing thread not actioned, let me have a look
Okay so tax isn't "prorated" sadly it's one of the limitations of the API in that case and you would end up with "no tax" on those one-off items unfortunately but there are ways around it. I don't really understand your screenshots since they aren't about proration right?
(the Real does but not the Test)
you also gave 3 invoices, which one is problematic?
cc @cloud sundial
Hey thanks! The problematic are the first two - an upgrade plan (first) with additional seat add on (second) - the tax calculation with unused time credited is tricky to understand - if you could help understand the calculation between those invoices
Okay so the problem is when you invoice the "proration" on its own?
like which of the 3 is wrong?
because you gave 3 invoice ids, but 2 screenshots
The second linked “adding another license”
perfect let me look
Yes the screenshot “real” is the second linked invoice
The first was to understand the original upgrade amount/tax 🙂
Cheers!
hmmm I don't really understand that invoice yet, it has absolutely no proration
also why are you passing billing_cycle_anchor: 'now'
Are you literally updating the quantity from 1 to 2 and backdating it?
I don't get why you're doing this, you should 1/ not pass proration_date and 2/ not pass billing_cycle_anchor
@cloud sundial
Are you still around?
Yes I am! The messages are a bit intermittent
Can you reply to everything I mentioned above? I don't understand what you are trying to do unfortunately
This was a recently migrated customer from Braintree to Stripe so some subscription creation settings might be related to the use of the backdating and billing cycle anchor.
Are you seeing those incorrect parameters being passed on the subscription update event or on creation?
I've only focused on that call and I don't understand what you're expecting unfortunately. The way you're making this call doesn't make sense to me, you should not be passing a proration_date in the past and billing_cycle_anchor
you should be passing proration_behavior: 'always_invoice'
“That call” being the subscription, invoice or other?
That call being the invoice creation due to the Subscription update call your code is making