nox7_api

[edgy carbon]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1245369283022815312

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[earnest cedar]

I think we have the same rounding logic for all API endpoints as described here
https://support.stripe.com/questions/rounding-rules-for-stripe-fees

[stoic solar]

Thanks for the reply, Hanzo; but unfortunately those rules seem to not be followed in this context (or I am misunderstanding something).

0.5775 turned to smallest units of USD would be 57.75. If I round this, I get 58 (which is what Stripe's API gives me back).

1.155 turned to smallest units of USD would be 115.5. If I round this I get 116 - but Stripe sends back 115. Why would this be the case?

[earnest cedar]

Yeah I am confused too. Let me give it some more thoughts

[stoic solar]

Thanks, looking forward to the response. I think it has something to do with how internals are handling midpoint-rounding; but obviously I wouldn't be privvy to know which approach the API is taking on this (if it's towards zero, etc.).

[earnest cedar]

What setting do you have for Manual tax amount rounding on this page?
https://dashboard.stripe.com/settings/billing/invoice

[stoic solar]

It's set to Round manually entered taxes at invoice level, but I am trying to match my tax rounding estimates with what the Stripe API actually sends back per-line-item (since it sends back per-line-item tax amounts for either setting) so I can show the user this in our CRM. Because, they might have different taxes assigned per line item.

[earnest cedar]

Ah I think that's why you're seeing different behavior on the invoice

If you change it to line-item level rounding and create a new invoice, what amounts are you seeing?

[stoic solar]

I see the expected rounding
115.5 -> 116
57.75 -> 58

The issue is, the connected accounts default to summing at the end of an invoice. How is it that the API is able to send a tax_amounts property for each line item in both cases that sum up to the final tax regardless of the setting?

[earnest cedar]

How is it that the API is able to send a tax_amounts property for each line item in both cases that sum up to the final tax regardless of the setting?
I'm not sure I fully grasp the question. Can you elaborate?
Like what amount are you referring to as the final tax?

[stoic solar]

In an API response, regardless of which invoice setting, Stripe sends back tax_amounts per line item. Here are two screenshots from the original problematic request.

Where 2100 taxed at 5.5% gives "115" and "1050" taxes at 5.5% gives "58"

My question is that Stripe's system seems to know, regardless of the setting, how to calculate the distributed tax amounts and I'm just trying to find out how I can do the same to show accurate tax amount estimates in my UI.

[earnest cedar]

I think we sum the lines (31.5) multiply by the tax rate (5.5%) to get the total tax amount (1.7325) which rounds down to $1.73

Then we split by line item
Line 1 goes first - 21*.055 = 1.15 (order of the invoice items is important here)

Line 2 = total tax - line 1 tax
=> 1.73-1.15 = 58

[stoic solar]

Oh that's interesting

I swapped their order, and the calculation is still the same. 58 and 115 no matter which order.

I think I'll just do what Stripe does for that setting and not show the line item amounts and calculate it at the end of the invoice regardless.

Thanks for looking into it either way.

[stoic solar]

Sorry to bring this back up, but I swapped to trying to use the "invoice level rounding" and don't understand it still. The results are not consistent with what Stripe's UI even shows.

Why is this $3.93 and not $3.94?

The full subtotal shown in the Invoice on Stripe's UI after created with the API. The percentages don't properly round (with standard decimal rounding techniques) to what they should.

[gentle gull]

Looking in to this. can you expound on what you mean by "The results are not consistent with what Stripe's UI even shows."? The math on adding those line items is consistent, are you saying that rounding that cent down is the thing that is inconsistent with the UI?

[stoic solar]

Yes, sorry. I expect the calculation to come back as $3.94 on that - for example - Sales tax.

But I get back $3.93. I followed the documentation on how the rounding for invoice-level works and I cannot replicate what comes back from the API when I create the invoice (that it's $3.93 and not $3.94).

Is tax always rounded down in Stripe? Though that wouldn't make sense either.

5250 * 7.5 = 39,375
3150 * 5.5 = 17,325

[gentle gull]

Gotcha, checking in to this with my colleagues. We know more about the API than how specific calculations happen behind the scenes, so we may need to direct you to support for a better answer, but we will try to figure this out here

[stoic solar]

Alright, I appreciate it. My goal is just to be able to give my users the exact estimates possible when creating Invoices or Subscription line items from our UI before hitting Stripe's. We plan to have growing volume over time so it would be nice not to have to generate previews in the API constantly and just do tax calculations on our end. Because to get $3.93 of tax for $52.50, the tax percentage to multiply by is 7.48% and not the 7.50% that is entered.

[slender kettle]

👋 Hello! Using the API to generate previews is the recommended approach if you want accurate calculations, especially over time. New rules/regulations/laws/bug fixes/etc. will mean the calculations you get from the API will be different from calculations you perform on your end over time. It's best to have a single source of truth instead of trying to keep things in sync.

[stoic solar]

Thanks, and I can do that going forward I guess. But the fact of the matter is just strange that Stripe is saying the exact sales tax for the locality to be collected is $3.93 when that isn't true.

If this were to be used to properly collect local taxes for regions, Stripe is giving the wrong number entirely. Left is Stripe's calculation and right is an accounting calculation for withholdings.

[slender kettle]

I can't speak to a specific tax calculation here, unfortunately. We're focused on technical/developer issues on Discord. For help figuring out specific tax calculations like that one you should contact support: https://support.stripe.com/contact/email