#samuelDSR - ACH vs CC tax
soft hemlock
Hello, that is a good question. As far as I know, you shouldn't need to do anything if this is automatic tax calculation. Do you have the ID of the invoice that this happened for?
hearty perch
I need to ask, it happened on production and I have no access, is there a way we can close the latest invoice and recreate it after the PM changed?
soft hemlock
If it is for a subscription, I don't think so unfortunately.
And just to ask quickly, do you know if your integration uses automatic tax calculation here with these invoices or if you define custom rates?
hearty perch
Oh, I just noticed that taxes are being calculated from our side, it's legacy backend code, so we aren't currently using any rates, the rates are being calculated from backend and added to the total price
Sorry 😅 , so there is no workaround here for that cases? Our subscription is being updated with the correct taxes on the price field, but old failed invoices are charging ACH tax
soft hemlock
Ah gotcha. I am trying to think of what you can do here. You can't change the price on a finalized invoice unfortunately. To be clear, is that $3.50 higher or lower than what they should have been taxed?
hearty perch
It's lower, CC taxes are a percent value and ACH are $3.50
For large amounts is cheaper ACH
I thought I can draft the invoice and recreate it, but it seems I can't 😕
soft hemlock
You can create another invoice but it wouldn't be related to the subscription. So you would need to write your own logic to mark the original invoice as paid once this other invoice is paid
The other thing that I can think of would be crediting the user if they pay too much or charging a bit more the next month if they paid too little. Not sure how your users would react to that but that could definitely be a way to get the exact amount you need overall.
I will consult my colleagues on whether they have other ideas
hearty perch
Ok, if you find another idea let me know pls, thanks for the help
soft hemlock
Sounds good, just reached out and will get back to you with what we can think up.
soft hemlock
Hey, apologies for the delay. When talking to my colleagues, it sounds like we have already covered the two main options here if you want to charge this way.
- Creating another invoice for the proper amount, marking the original invoice as paid when that one is
- Passing the difference on to the next month by crediting/debiting the user for the difference
Moving to Stripe Tax and having us calculate the tax rate may also be an option here. Though honestly this is the first time I'm really hearing of a different tax rate based on payment method. Is this more of a processing fee thing or is this the actual tax rate changing?
hearty perch
I'm not sure if that is the real tax rate changing but the price calculation service we have was no implemented by me so I suppose is real