The AvaTax Configuration Dialog Window must allow the user to specify the configuration/connection information

• Account Number
• License Key
• Environment (Sandbox/Production)

Merchants should have the ability to designate which company within their account is linke to this intgration. This is done using the QueryCompanies API.

This is required if a Test Connection button isn't included.

Test the connection to the AvaTax service and verify the AvaTax credentials. This is an important element to allow for successful troubleshooting of the AvaTax Service.

This is required if a Company Code Lookup isn't included.

In order for this connector to be used in conjunction with other integrations to AvaTax, the user must be able to control which connector is used for recording documents to AvaTax. From a technical standpoint, simply use DocType: 'SalesOrder' on all calls and suppress any non-tax calculation calls (i.e. CommitTransaction, VoidTransaction).

If the platform is system of record and there are no further processing of the transaction to other systems, this requirement may be waived as the expectation is that this system will record all transactions to AvaTax.

Enables detailed AvaTax transaction logging within the application including capture of round-trip processing time. We need the complete request/response for each call made to Avalara services. It doesn't need to run all the time as we understand the database will grow unnecessarily large. You are free to only log the last week, 30 days, custom, or have a control for the next N hours, and so on. The spirit of the requirement is to assist customers and support in troubleshooting exercises, so it needs to be retrievable by an end user (or an administrator). It should log Avalara service calls, specifically.

The user must have an option to turn on or off the AvaTax Calculation service independent of any other Avalara product or service.

The User Implementation Guide should contain screenshots and information allowing the end user to configure for AvaTax including where the company code is entered, where the credentials are entered, where customer data is entered, and where tax codes can be mapped within the application. Click Here for a user guide template.

Identify the itemCode value (number, ID) to pass to the AvaTax service.

Identify item/service/charge description to pass to the AvaTax service with a human-readable description or item name.

Users must be able to associate an item or item group to an AvaTax Tax Code to describe the taxability (for example, "Clothing-Shirts" – "B-to-C").

Users must be able to associate an item or item group to a harmonized classification code. HS - 10 digit (Country of Destination specific). This is an array of destination countries.

Users must be able to provide any parameter details associated to items/SKUs.

• General Parameters Required
• Weight
• Volume
• Count (units)

Partners should use the ListParametersUsage API to check if the HS code associated with a product requires specific parameters. This can be done by filtering based on the productCode value.

Association of Freight/Shipping and/or Handling and Insurance charges (if applicable = CIF Countries) to an AvaTax Tax Code to describe the taxability.

Pull in and surface Avalara Tax Codes within application using the ListTaxCodes API.

Values that can come across to AvaTax as the docCode.

Values that can come across to AvaTax as the customerCode. This is used to identify any certificates linked to the customer.

Value comes across to AvaTax as the docDate.

Value sent to AvaTax at the header and line levels for the address where items are shipped from.

Value sent to AvaTax at the header and line levels for the address where items are shipped to.

Your integration should be able to store at the header or line levels the full address where the goods are located when there is no transportation. This is required if your platform accepts this address.

If your application supports Import addresses, then your integration must be able to store at the header or line levels the full address where goods are imported into.

The value for each line within a transaction, specified using a unique line number.

The value for the quantity of an item for each line of a transaction.

Identify the itemCode value (number, ID) to pass to the AvaTax service.

Identify item/service/charge description to pass to the AvaTax service with a human-readable description or item name.

The value sent to AvaTax as the total amount for each line item in a transaction, keeping in mind the status of the isTaxIncluded flag.

Users must be able to specify on each line in a transaction whether the total line amount includes tax.

Value sent to AvaTax as the taxCode for each line of a transaction.

The harmonized classification code of the product. Verify within app HTS (10 digits) can vary by country.

If an HS Code isn't included in the transaction request, then use the estimator functionality.

Users should be able to provide any parameter details associated to items/SKUs.

• Sample HS Code that requires parameters:
• HS6403.20.00

Partners should use the ListParametersUsage API to check if the HS code associated with a product requires specific parameters. This can be done by filtering based on the productCode value.

Your integration may need to include a product category path in the API request.

If a full HSCode (10 digit) isn't included in the transaction request, then this product category path is required.

The handling of shipping and freight in AvaTax must match your application's implementation. For VAT transactions, freight can be included in the total amount or added as a separate line.

Users must ensure that discounts on transactions are processed appropriately.

Confirm that the integration is taking the Tax Amount value from the tax calculation response and using that to decorate the tax fields in the platform. Do NOT take our rate and use it to calculate the tax within the platform itself.

Your integration must mirror your system's workflow as it relates to orders and invoices and use the appropriate document types.

Your integration must mirror your system’s workflow for a transaction lifecycle when committing documents.

Display and store any messaging returned by the AvaTax engine on the customer invoice.

Display and store the VAT code returned by the AvaTax engine in the ERP transaction record.

The three-character currency code at the document level sent to AvaTax for transactions.

Your integration should allow users to specify an exchange rate for transactions.

If your application allows users to input an exchange rate, then you must allow users to also include the currency code for the exchange rate.

If your application allows users to input an exchange rate, then you must also allow users to specify the effective date of the exchange rate in a transaction.

Users should have a way to specify the customer's business identification number (also known as VAT Registration ID). This data element should be found directly on the transaction header.

The value sent to AvaTax as the two-character countryCode in transaction addresses.

Users must be able to specify who in the VAT transaction is responsible for handling the transportation of the physical goods.

Your integration should allow users to specify whether the user is the importer of record for a transaction.

Users should be able to specify whether the goods being sold in a VAT transaction are second hand (used).

Your integration should allow users to specify whether the counterparty in a sales transaction is registered through a fiscal representative in a given country calculating VAT.

Your integration should allow users to specify whether the Avalara client is registered through a fiscal representative in the given Nexus country for VAT.

Your integration must include a document-level parameter that identifies who is responsible for the duties, taxes, and import fees. Available values are:

• DAP (Delivery At Place)- Buyer is responsible
• DDP (Delivery Duties Paid) - Marketplace or Merchant is responsible

• DAP - No import fees applied to transaction (import fees will be returned in messages object of the transaction response).
• DDP - Import fees persist on transaction.

An indicator showing whether the merchant is the buyer’s agent in a given transaction, collecting duties on behalf of the end-customer.

Required if integrating with an Ecommerce or Marketplace application.

If this Buyer Agent flag = True AND IOR = True OR Delivery Term = DDP, then duties and taxes will be calculated.

Ensure that appropriate de minimus messages are displayed in responses.

Your integration must include appropriate Customs Duty and Import Tax details in responses. This includes displaying custom clearance fees, where applicable, as information to the Buyer when the Seller is not the acting as the Importer of Record.

For Custom Clearance fees to be included in the response, the CCF entitlement must be enabled on the merchant's AvaTax account.

Integrations must include information about the connector, such as name, version, and company name, as a signature to each transaction.

There should be no errors except those that would result from normal (but invalid) user input (e.g. invalid address data). Such errors must be logged/displayed appropriately to the system.

In a normal workflow, we expect to see (on average, including abandoned carts) up to 10 tax calculations per finalized document. In a straight-forward order entry process, the number of calls should be about three to five.

Users should have an easy and trouble-free installation experience.

Your integration should provide an option for users to indicate on a transaction whether the CDIT calculation should use a preferred customs duty rate (e.g. USMCA) rather than the standard duty rate otherwise calculated.

This is done using the IsPreferredProgram parameter at either the document or line level.

Example

"name": "IsPreferredProgram" "value": true

Your integration must provide the country code of the country that manufactured the products at the line of each transaction.

This is done using the CountryOfManufacture parameter at either the document or line level.

Example

"name": "CountryOfManufacture" "value": "CN"