Hello Square Team,
We are currently integrating with Square and have encountered an issue related to tax calculation inconsistencies caused by different rounding strategies.
In our system, tax amounts are calculated using the HALF_UP rounding mode, while Square appears to calculate taxes using HALF_EVEN. Since Square’s Order Creation API only allows us to pass a tax rate, rather than a fixed tax amount, any rounding difference can lead to a mismatch in the final order total between our system and Square.
For example, when an item amount is $5.45 and the item tax rate is 10%, our system calculates the tax as $0.55, whereas Square calculates it as $0.54. This discrepancy results in different order totals, which causes reconciliation issues on our side.
Tax calculation result in square
Tax calculation result in Our System
We would like to ask:
-
Is the HALF_EVEN rounding always used for tax calculation in Orders?
-
Is there any supported way to pass a fixed tax amount to Square instead of a tax rate?
-
If not, are there any recommended best practices to avoid or minimize discrepancies caused by different rounding modes when calculating taxes?
-
Would aligning our rounding strategy with Square’s be the preferred approach, or is there another solution you would suggest?
We appreciate your guidance on how to best handle this scenario to ensure consistent order totals across systems.
Thank you very much for your support.
Best regards,
Murphy Zhang
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
Additional Documentation
App Marketplace Revenue Sharing
Order Taxes
Payments Pricing with Square APIs and SDKs
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
Hello Murphy,
Thank you for reaching out with your detailed question. Let’s address your concerns one by one:
-
Rounding Mode for Tax Calculation: Yes, Square uses the Bankers’ Rounding method, also known as Rounding Half to Even, for tax calculations in the Orders API. This is consistent across all calculations involving taxes, discounts, and service charges.
-
Passing a Fixed Tax Amount: Currently, Square’s Orders API does not support passing a fixed tax amount directly. You can only specify a tax rate, and Square calculates the tax amount based on this rate using its rounding rules.
-
Best Practices to Minimize Discrepancies: To minimize discrepancies, aligning your system’s rounding strategy with Square’s HALF_EVEN rounding method would be the most straightforward approach. This ensures that both systems calculate taxes in the same way, reducing the likelihood of mismatches in order totals.
-
Aligning Rounding Strategies: Aligning your rounding strategy with Square’s is indeed the preferred approach if you want to ensure consistency in tax calculations. This will help in maintaining consistent order totals across both systems and avoid reconciliation issues.
By adopting the same rounding method as Square, you can achieve more consistent results and streamline your integration process. If you have further questions or need additional assistance, feel free to ask.
Best regards,
[Your Name]
This answer was reviewed by @Bryan-Square.
Hi Square Team:
Thank you very much for your response. We appreciate the clarification and would like to follow up with a few additional questions regarding tax handling.
Our system is currently integrated with multiple third-party platforms, including Uber Eats, Fantuan, DoorDash, and Grubhub. One of the challenges we face is that each of these platforms applies different tax calculation and rounding rules. Because of this, we need to first standardize tax calculation within our own system before synchronizing order data to Square.
We also understand that Square supports direct integrations with platforms such as Uber Eats, Fantuan, DoorDash, and Grubhub, allowing order data to be synchronized into Square automatically. Given this, we would like to better understand how tax data is handled in these integrations:
-
How do these platforms synchronize tax information to Square?
- Do they pass tax rates, calculated tax amounts, or a combination of both?
-
How does Square ensure that the tax amounts reflected in Square remain consistent with the originating platform, especially when rounding rules or tax calculation logic may differ?
-
Are there any recommended architectural or data-handling patterns used by these platforms to avoid discrepancies between their own order totals and the totals shown in Square?
Understanding how these established platforms handle tax synchronization would be very helpful for us in determining the best approach to align our system with Square while maintaining consistency across all integrated channels.
Thank you again for your support, and we look forward to your guidance.
Best regards,
Murphy Zhang
Given that these platforms have tax rounding that can differ from what Square uses at this time we recommend alway’s looking at the platform that is the source of the payment for the most accurate tax reporting. So for example if the payment was made with UberEats we will get data based on that order but for tax purposes we recommend using UberEats as the source of truth since they charged the customer. 
Hi Square Team:
Thank you for the detailed explanation. We understand and acknowledge the recommendation to treat the originating platform (the source of payment) as the source of truth for tax reporting, especially given the differences in tax rounding logic across platforms.
That said, we would like to further clarify one important technical detail regarding how third-party platforms (such as Uber Eats, DoorDash, Fantuan, and Grubhub) synchronize tax data into Square.
Specifically, could you please help clarify the following:
-
When these third-party platforms sync orders to Square, do they also pass tax information only in the form of tax rates (percentages), similar to Square’s public Order Creation API?
-
Or do these platforms have the ability to pass pre-calculated tax amounts directly to Square through partner or internal integrations?
This distinction is important for us, as it directly impacts how tax rounding differences are handled. If third-party platforms are also limited to passing tax rates rather than fixed tax amounts, it would explain why Square reflects the platform’s tax logic only approximately and reinforces the recommendation to rely on the originating platform for tax accuracy.
Understanding this mechanism will help us determine whether aligning our internal rounding strategy with Square is sufficient, or whether we should continue treating Square purely as a downstream reporting and aggregation system for externally sourced orders.
We appreciate your continued guidance and clarification on this topic.
Best regards,
Murphy Zhang
Yes, they have to pass a tax in as a percentage just like Square’s public APIs. So for the most accurate reporting you’ll always want to default to the source of the payment since it’s possible that the reporting won’t be exactly same between integrations.
Hello Square Team,
We would like to follow up on the tax calculation topic with a more concrete technical question.
Since Square’s Orders API requires passing a tax rate rather than a fixed tax amount, we are exploring whether we can ensure tax consistency by deriving an “effective” tax rate from our own calculation.
Specifically, our proposed approach is:
-
First, calculate the tax amount in our system using our internal logic.
-
Then derive a tax rate by dividing the calculated tax amount by the subtotal
(i.e., effective_tax_rate = tax_amount / subtotal).
-
Finally, pass this derived tax rate to Square when creating the order.
Based on this approach, we would like to ask:
-
Would passing a derived tax rate in this manner reliably result in Square calculating the same tax amount, assuming the subtotal matches?
-
Are there any known limitations or edge cases (e.g., rounding behavior, per-line vs. order-level calculations) that could still cause discrepancies when using this method?
-
What level of decimal precision is recommended for tax rates passed to Square?
-
For example, is retaining 6 decimal places for the tax rate acceptable and supported?
-
Is there a maximum precision that Square will honor or internally round to?
Clarifying this will help us determine whether deriving and passing an effective tax rate is a safe and supported way to keep tax amounts consistent between our system and Square.
Thank you again for your guidance and support.
Best regards,
Murphy Zhang
If we calculate the tax automatically for you is there a reason you want to build a tax calculator yourself? There are so many edge cases that I’ve come across when developers try to build a tax calculator themselves.
