#geordi-proration-tax

1 messages · Page 1 of 1 (latest)

calm vine
#

Hi there đź‘‹ taking a look

cloud sundial
#

Thanks!

calm vine
#

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?

cloud sundial
#

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.

calm vine
#

Oh, okay, multiple changes in a single day may make this look a bit confusing, taking a closer look.

cloud sundial
#

Great, thank you!

rocky stump
#

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

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

rocky stump
#

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

cloud sundial
#

The second linked “adding another license”

rocky stump
#

perfect let me look

cloud sundial
#

Yes the screenshot “real” is the second linked invoice

#

The first was to understand the original upgrade amount/tax 🙂

#

Cheers!

rocky stump
#

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?

cloud sundial
#

Yes I am! The messages are a bit intermittent

rocky stump
#

Can you reply to everything I mentioned above? I don't understand what you are trying to do unfortunately

cloud sundial
#

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?

rocky stump
#

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'

cloud sundial
#

“That call” being the subscription, invoice or other?

rocky stump
#

That call being the invoice creation due to the Subscription update call your code is making