Addresses are a crucial part of the sales tax calculation process. There are various factors that go into sales tax calculation, but addresses are probably the most important. The total sales tax rate that you pay is made up of several smaller rates, and each of those is allocated to a different tax jurisdiction (think state, county, city).

AvaTax determines the correct tax jurisdictions based on the addresses provided. This may seem fairly straightforward, but there are a huge number of different tax jurisdictions, and the boundaries aren’t always clean or simple to determine. Avalara has a content research team that does the legwork on this so you don’t have to – you just need to give us the address, and we’ll determine the correct tax jurisdictions for you.

Supported address types

The table in this section describes the address types supported in AvaTax.

The simplest type of transaction is a retail point of sale transaction, where the origin address and the destination address are the same. This type of transaction uses the address type singleLocation. For example, in this scenario, a customer makes a purchase in a retail location and takes possession of the product at that location.

For transactions where the origin and destination addresses aren’t the same, the two address types that factor into sales tax calculation are origin addresses and destination addresses. For example, if you live in Washington and you’re selling a mug to someone in California, your origin address (of type shipFrom) would be Washington and your destination address (of type shipTo) would be California.

While only the city, state, and postal code are required for calculation, it’s best practice to provide as much address information as you have available. This will help to ensure the most accurate tax calculation possible.

You can specify addresses at either the document level or the line level.

Document level: A transaction, as a whole, uses document-level addresses as the default. If a transaction doesn't have any addresses at the line level, each line will be assumed to use the addresses from the document level. When you record a single transaction, and all invoice lines on the transaction have the same addresses, you only need to set your address values once at the root level of your transaction, no matter how many invoice lines you’re calculating.

Line level: Line-level addresses represent individual, separate shipments. It's possible to have a scenario where an end customer checks out of the cart with the products/services from different merchants. In this case, the shipFrom address differs for some or all lines. The shipTo address is likely to always remain the same for a given checkout process, but in this case, pass them together at line level.

Note:
Don't create transactions that include both document-level and line-level addresses. For example, if your transaction includes multiple lines, and those lines include line-level addresses, then all lines should include line-level addresses.

Field Name	Model	Summary
`singleLocation`	AddressLocationInfo	If a transaction occurred at a retail point-of-sale location, provide that single address here and leave all other address types null.
`shipFrom`	AddressLocationInfo	The origination address where the products were shipped from or from where the services originated.
`shipTo`	AddressLocationInfo	The destination address where the products were shipped to or where the services were delivered.
`pointOfOrderAcceptance`	AddressLocationInfo	The location where the order was accepted by your supplier, such as a call center, business office where purchase orders are accepted, and server locations where orders are processed and accepted. AvaTax uses this address to determine the establishment country of your supplier in the transaction. Include this address in Purchase document types.
`pointOfOrderOrigin`	AddressLocationInfo	The location from where your customer (home or business) placed the order to you. This is used to determine the establishment country of your customer. Include this address in Sales document types.

Specifying latitude and longitude in addresses

In some cases, a location or service site can only be pinpointed by geolocation. For these situations, AvaTax supports specifying a latitude and longitude when configuring any of the above address types. If a user provides these along with a line, city, region, country, and postal code, AvaTax will use only the latitude and longitude and will discard the line, city, region, country, and postal code information for the transaction.

Ensure that you have the correct latitude/longitude information for an address before using the AddressLocationInfo API. If you provide either a latitude or longitude but not both, AvaTax uses the line, city, region, country, and postal code for the addresses.

Advice:
You can only specify latitude and longitude for US addresses.

Resolving addresses

We require that you validate/resolve addresses against an address validation system. If use Avalara's address validation system, call the ResolveAddress API. (Note again that Avalara's address validation service is only available for US and Canadian addresses.) When you call this API, Avalara returns a response indicating whether the address can be found or whether any errors or typos have been detected - and your users may appreciate this help when typing in an address. Here’s how to do it:

When the user types data into an address field, call ResolveAddress with the information the user provided.

If the ResolveAddress function reports that ResolutionQuality is External or NotCoded, this indicates that AvaTax can't identify the address the user typed in. Return a warning to your user and ask them to verify the address.

If the user chooses to accept an incorrect address, it's possible to specify line1 = "GENERAL DELIVERY". This is a special code recognized by the USPS that allows nonrecognized addresses to be processed even if automated address validation doesn't identify the correct location. For more information, see the USPS website on General Delivery.

Addresses in transactions