We've recently run into circumstances where the auto-added order variance line item is being added to the order, but the order total still isn't right. It happens 1-2 times a day.
Example: Shopify order total is 399.30.
In NetSuite before the variance is added, the order total is calculated as 399.29.
The IA adds a variance line of 0.01.
The new order total calculated in NetSuite is 399.32.
If we remove the variance line, it goes back to 399.29. So the solution in this case is to leave the original variance line and manually add a second variance line of -0.02.
Applicable other info:
-We recalculate taxes in NetSuite using Avatax. (So it seems like it's crossing a line where tax rounding bumps to the next level or something?)
-We have per-line taxes on transaction enabled in NetSuite.
-This only seems to be happening since we started using cart-level discounts in Shopify. (Previously everything was line-level discounts.)
Any ideas? Can Celigo do another variance line? Or is this just a NetSuite tax calculation fluke we need to adjust to?
In my experience if both systems separately calculate the gross amount from an ex Tax Amount it will always lead to penny/rounding differences on some orders and the need for a variance line.
My preferred solution in case of a webshop > NetSuite order integration is to map to the Gross Amount on the item line, that way NetSuite will calculate the ex vat amounts backwards from that, and the order total amount will always be the same as in the webshop.
This might not be possible with all NetSuite tax setups though.
Another approach and perspective that might help is to handle this at the line level:
Set the Price Level to "Custom" (-1) on all item lines in Netsuite
Map Shopify's exact line prices (already inclusive of discounts) directly into NetSuite.
Disable automatic price and tax recalculation by default.
Add a custom checkbox on the line item (e.g. Recalculate Tax?) that can be manually or programmatically enabled when recalculation is explicitly needed.
This gives you full control over what gets recalculated and prevents unexpected tax bumps from rounding when a variance line is added. If necessary, you can also script a second variance line based on delta detection, but ideally with gross price mapping and controlled recalculation, it's rarely needed.
This hybrid approach works well when you want Shopify to remain source of truth for order totals, but still need to accommodate edge cases in NetSuite’s tax logic.
We do use price level of custom, map the exact line prices inclusive of discounts (except cart-level discounts which, as noted, is the problem), and we need to recalculate tax because the transactions are sent to Avalara from NetSuite, not from Shopify. Even if we didn't recalculate on the sales order after adding the variance line, the cash sale would recalculate as it creates - and that is transaction actually sent as the document to Avalara.
@basvanditzhuijzen We are fine with penny rounding differences leading to need for a variance, we've dealt with that for 3.5 years. It's when the added variance is still wrong and a second variance line is needed that we can't figure out how to handle automatically.
So if I understand correctly, you’re mapping the line prices as-is from Shopify, and then Avalara recalculates tax on the cash sale, which is the transaction actually submitted to Avalara.
Since this issue only occurs after AvaTax recalculates the tax on the cash sale, one approach would be to handle it via SuiteScript:
Run logic on the cash sale afterSubmit,
Compare the NetSuite total vs. the original Shopify order total (ideally stored in a custom field),
If the difference exceeds a small threshold (e.g. ±$0.01),
Automatically add a second variance line to correct the total.
This would probably catch those rare edge cases where the initial variance line causes AvaTax to adjust the tax total again, pushing the final amount out of sync.