Hello all,
We are currently working through the testing phase of implementing Avalara into our system. One problem we are having is that some of the addresses for our customers do not validate. They are either in remote areas where the address is not even on google maps or they are someone who’s address is literally “At the end of Johnson road on the right” because they are more so pop-up shops where they go to a location, mine sand for a few months, then leave.
Is there a way to manually assign a customer a tax rate or tax jurisdiction so that Avalara still processes these customers when their address cannot possibly validate?
Thanks
We have similar issues, as we deliver to oil fields, and remote pipelines. Occassionally the Ship To is a set of GPS coordinates.
Our work around is to find real address in the same tax jurisdiction, and make a ShipTo for that. Then use that address. Since our shipments go by flatbed, it’s not like we’re butting shipping labels on boxes that get moved from truck to truck. So we focus on the the trucking company having the correct shipto “location”, over what the packer says.
If a customer gets antsy about it, will change the ShipTo to one Avalera can compute, just during the Invoicing.
I have to say that is one hell of a work around. I am shocked Avalara doesn’t just allow you to manually assign tax jurisdictions.
Avalera can be super picky. We occasionally ship to Puerto Rico and the following street address fails:
HC 01 BOX 7928
It has to be:
HC 1 BOX 7928
We use “GENERAL DELIVERY” as Address line 1 when shipping to remote locations. I believe this causes Avalara to default the tax calculation to use only the ZIP code.
4 Likes
Is the City and state left blank?
edit
After a quick test, I see that a ShipTo with just a name, zip code, and country, Avalera can do the tax calculation. It still fails an Address Validation, but does calc the tax.
At least on an Order … I don’t have a sandbox setup in Avalera, so I can’t test it on an invoice.
ShipTo Info on Order Release:
And the correct tax is calculated for the Zip code used
2 Likes
With Address1 blank in the Cust ShipTo, doing an address validation gives you:
Setting Address1 to “GENERAL DELIVERY”, still allows it to calc the tax, but now get a different error when validating addresses:
1 Like
This is interesting and may be the route we have to take for these remote customers. I do currently have a case with Avalara support asking whether it is possible to override the tax jurisdiction, but I am doubting the answer will be yes even if it isn’t that technically demanding.
One thing I am curious about though is that if the system cannot assign a tax jurisdiction to an invalid address, but it can from the ZIP on the GENERAL DELIVERY example, why couldn’t it just assign a jurisdiction based on the ZIP only in the invalid address?
1 Like
Probably because Zip code areas might not align perfectly with tax jurisdiction areas. I think it is Louisiana that has a different tax jurisdiction for every parish (what they call counties).
Calvin,
That is correct, we are in Louisiana and Sales Tax here can be a nightmare, which is why even with the GENERAL DELIVERY workaround with the ZIP it may not pull the correct jurisdiction.
@dishmael, you are correct the GENERAL DELIVERY work around is not perfect, but its the best we had. As for the address format we would just bump everything down a line
Customer Name
GENERAL DELIVERY
123 Main Street
Sometown NY 1345
2 Likes
Andrew,
I really do appreciate the work around though as it may really help us out.
Thanks
1 Like
Avalara documentation says it can support Lat/Lon coordinates in the US but the ERP is not designed to enter them nor use them. I encourage you and anyone in a similar position to contact support to create an enhancement request or to attach your call to an existing one.
As a side note I wasn’t aware of the GENERAL DELIVERY workaround, I didn’t get an Object Reference error although that would depend on the ERP version.
I can confirm that at least in Invoice Entry I got the same results as @ckrusen
Hey Guys,
I actually managed to get a response from Avalara. There is actually a Jurisdiction Override in the Avalara Advanced settings. These are the steps I received:
- In AvaTax, go to Settings > All AvaTax Settings.
- Next to Advanced Account Settings, select Manage.
- Under Jurisdiction Overrides, select Manage Jurisdiction Overrides.
- Select Add a Jurisdiction Override.
- Fill out the information for the override.
- Enter an override a name that’s easy to remember.
- Select an effective date to tell AvaTax when to start applying the override.
- Decide if the override should apply to a zip code or a specific address.
- Enter the zip code or the address and select Save.
- Select the jurisdictions you want to use.
- Select Save Override.
Apparently the main concern with this is that creating a Jurisdiction Override might affect your company’s tax compliance, which would be an issue if you assigned the wrong jurisdiction.
Anyway I hope this helps some of you out.
3 Likes
That’s WAY better than our workaround!!!
@dishmael - When you say “In AvaTax…”, you’re referring to the web based dashboard?
@ckrusen Yes, I logged into the website and found the setting, you have to be on an Avalara administrator account to do it.
Although I have not tested it yet, but I am putting together a plan to test our customers’ tax rates so we can correct them if necessary.
Please let us know how it affects the Address Validation. Because even if it does calc the tax properly, most of my users get thrown when they see any kind of failure or error message.
I am expecting it will override the address validation altogether and you won’t have to validate, but we will see when I test it.
I am looking to see which addresses were validated through tax connect (Avalara) and which address failed. I found two fields in the customer table (Customer_TaxValidationStatus and Customer_TaxValidationDate), but they are blank.
Does anyone know where to find the fields that show which address validated and which one didn’t?
1 Like