We had to increase ours too, but I don’t think it’s avalara or Epicor’s fault, it’s just how it is.
The recommendation for now is to make sure the invoice is as complete as possible before calculating taxes, so only check Ready To Calculate until almost the end, because every change that can result in tax changes(dates, addresses, amounts, categories, etc) will make another call to Avalara.
1 Like
Yes
We’re an ECC e-commerce based sales organization. Orders can be processed in a matter of minutes as well as credit cards processed. I’m not sure how we could utilize the “Ready To Calculate” hold option.
Agree, it’s not Avalara causing the charge. Yes, it seems to be the way it works.
We’re leaning on Avalara more and more as our needs grow. They’ve been easy to work with and have provided great support.
1 Like
For sure Jeff, easy to work with and integrate with. I will say controlling the costs is really not in our control as we grow, but Jonathan does make a great point.
Not sure how the integration works, but there is a checkbox “Ready to Process” at the order level that determines if tax should be calculated. The default value comes from company configuration.
Now, the idea is for the tax to be calculated as the last step, or if the order requires a lot of changes to turn it off first.
So if the integration is creating the order and adding lines and sending every change while the Ready to Process flag is on, it will call Avalara as many times as it needs.
Sorry to get off topic regarding API Call charges.
Would I recommend Avalara? Absolutely!
2 Likes
We’ve been using Avalara for 3 years and are very pleased with it. We file in 20+ states. It did take some set-up, but not more than I would expect with a new system.
1 Like
Oh!!! That would be awesome if you could share it. I probably answer a call from sales every few weeks on “why didn’t this get sales tax charged”, and this would help them answer it themselves. We have our A/R department enter the customer tax exemptions on the Avalara portal… (I think exemptions get charged a different rate per transaction from Avalara as well).
Avalara is pretty comprehensive, but setup can get tricky to get things dialed in. Ours gets interesting with how freight is taxed or not, based on the part getting shipped or what state/county/town it’s going to…
One other thing to add to your process will be reconciling tax discrepancies - Avalara will calculate on Quote, again on Order, and again when invoiced. If there are any changes (like a shipto going to a field address instead of corporate), tax will be different, and the customer will need to be notified.
For kicks, you can turn on change logs and see how often Avalara recalculates tax on an order. It’s mind boggling. It’d be hilarious (or not) to have a counter on the order form showing each Avatax call!
1 Like
Well, I was going to do something on BAQ windowing function for the panel at insights, but I guess this project has a lot more interest. I’ll most likely share this project, and work on getting a sanitized version (I hardcoded passwords… I’m ashamed) set up to be shared on github.
2 Likes
Overall we are pleased with the avalara module. One issue is ecc orders for tax exempt customers. Once in kinetic the order cannot be changed. We can create a new kinetic order that links to the avalara exemption, but cc data will be lost so we have to call customer to collect payment details. We are having many issues with ecc customers entering poor addresses and erroring out in quickship module. We are trying to determine now if adding more states to our avalara config will assist with this.
ECC like Epicor commerce connect or electronic credit card?
Are you using Avalara’s address verification function? You should be able to call that with the API in ECC.
Well, since this topic got bumped, figure I may as well mention that as an alternative to using Cert Capture, we just attach a customer’s exemption certificate(s) to their Customer record in Epicor (using DocStar, but could also just use a link to a network folder) and mark them with an appropriate “Entity/Use Code” on the Billing tab in Customer Entry and on their Ship To records (it is then copied by Epicor to any new order releases for that Ship To). This has been working for both full and partial tax exemptions for us. It’s entirely self-managed, though, and Cert Capture probably has other features that you’d like to use as well, I imagine.
1 Like
The Entity/Use Code is a useful trick, but is generally ignored when you are setup as SST for relevant states. Streamlined Sales Tax (SST) can save a lot on Avalara fees, but has a few gotchas.
Agreed that Avalara is better than most third party integrations with Epicor. I use Avalara for tax calcs, Exemption management, return filing, and registrations.
1 Like
wow… old thread bumped… but I am glad to read the many great responses and positive experiences. It confirms what I have been telling customers over the years.
My FIRST Avalara implementation was WAAAyyy back when we first hooked up with Avalara (2008/2009?). I had a customer who collected sales tax for nearly every shipment to every state. The fact that we had a tax calculation for them actually caused our project to change shape, and them implemented AR/AP/GL first with a data integration to their old system transferring in the financial data… then a year later, we got the first manufacturing site live.
Avalara worked elegantly, and the one problem that they ran into with some tax calculation being wrong in the one specific state was quickly remedied.
Following my experience, I always recommended Avalara if they had not purchased it as part of their original sale. I “Won” the argument that they should not attempt to “build their own system” most of the time… but there were other times where I “lost” and the customer went with a custom tax solution “because it is cheaper”…
BUT in at least 2 of those… the customer build a custom solution, and a year or two later, gave up, and moved to Avalara… (no, i didn’t say “Told you so”… but it was tempting).
1 Like
I would like to elaborate just a bit on Paul’s reply. If you register with SST states and engage Avalara as your Certified Service Provider (CSP) for those states and qualify for “Volunteer” status in those states, then the entity/use codes on the shipment invoices pertaining to those states are not only ignored by AvaTax, but also technically are not allowed, per the Streamlined Sales and Use Tax Agreement. Customers’ exemptions cannot be passed on the invoice level; to properly exempt the customers from tax, relevant customer information must be entered in AvaTax via the Exemptions tab or in Avalara Exemption Certificate Management. Entering that information is more time-consuming, but the payback in the forms of free processing and audit protection is a worthwhile tradeoff!
We are about to start with Avalara soon.
We invoice our sales orders in terms, one ADV invoice and one SHP invoice. After shipment the SHP invoice is created and the ADV amount is automatically deducted.
Is it normal that no sales tax is calculated on the ADV invoice and tax is therefore calculated at the SHP invoice for the full order amount - resulting in a strange looking tax amount.
It could even be that the ADV is 100% of the ordervalue which will result in a SHP invoice that only contains sales tax.
Yes, I believe that is normal. If the goods/services have not been shipped/provided, then the buyer has not yet received anything in return for their prepaid consideration. Accordingly, the buyer should not be taxed based on the value of something not yet received.