While testing Orders/Payments I’m seeing some orders getting the error “The total of the requested payments does not match the total of the sale order”. I saw reference to “Bankers rounding” in another forum thread, and wanting to confirm this as the issue. For an item with a cost of $6.00, with a tax rate of 11.75%, it seems to calculate .70 as the sales tax. Because this actually results in .705 and we’re applying standard nearest rounding, we calculate .71 as the tax amount. So we’re declaring 600 for the line item, 71 for the tax amount, and making a payment of 671 - but it fails. Is this expected behavior or is there another declaration I need to make in the Create order API call to set the tax?
Hi @joel.h, welcome to the forums!
We do use bankers rounding and in the case of “0.0705” it would be rounded to the closest even number, which in this case is 0.70. There’s no way to change how we round these numbers, but you would be able to retrieve the order totals before creating the payment to confirm the numbers if needed. Please let me know if you have additional questions or concerns!
Thanks for the quick response and confirmation @sjosey
@sjosey - I’m seeing some inconsistencies here. I’ve shifted to rounding to the nearest even, but I have an example where square is rounding to an odd number.
Subtotal is $30.20
Tax rate: 11.75%
Unrounded: 3.5485
We’re rounding down to $3.54 for tax, but the 200 response from square shows that $3.55 was calculated for tax and the payment fails. So it only rounds half to even, and in this scenario it would still round up - is that right?
Sorry for the confusion, bankers rounding only comes into play when the end result is half (5). In the case of the above unrounded 3.5485, it’s 3.548, so normal rounding takes place, and it goes up to 3.55. If it had been 3.545, it would’ve been rounded down to 3.54.
I see your edit clarified this, so to your edit: yes, that is correct! 
Awesome, thanks @sjosey - I appreciate your support!
1 Like