Summary
An overview of AvaTax Cloud and related articles can be found in the Avalara AvaTax Cloud Integration article. This article covers how to setup the AvaTax Cloud EngageIP integration and how to test taxation.
Requirements
In order to configure and use the AvaTax cloud integration you will need:
A high bandwidth internet connection
EngageIP version 9.1.0 or higher
Access to the EngageIP app server and database
Avalara AFC SaaS Pro Tax service login credentials (provided by Avalara)
Base Configuration
This section explains how to configure AvaTax cloud in EngageIP. If you are presently using the on-prem AvaTax integration in EngageIP you should reference the Avalara Billsoft article instead.
EngageIP and AvaTax cloud integrate through RESTful API, so unlike the older on-prem billsoft solution configuration is simplified. The AvaTax cloud configuration does not require tax vendor scripts or action scripts.
Base Configuration Steps:
Import Service TaxTypes (These will be the 'Service Tax Categories' associated to your services on setup)
click Setup on the left sidebar
under Data Management click Import
import the following service tax types XML: TaxTypes-Import.xml (The 'TaxType' element should be 'name' for the final xml import, example per image below)
the result should indicate success
Optional: setup or import Account Tax Categories (AvaTax supports the following tax categories – Residential, Residential Incorporated, Business, Business Incorporated)
click Setup on the left sidebar
under Data Management click Import
import the service tax types XML (see the AccountTaxCategoryXMLImport.xml file below this list)
Note: you need to update owner in the XML file to match your systemResidential Incorporated
Residential
Business Incorporated
Business
SeniorCitizen
Industrial
SeniorCitizen Incorporated
Industrial Incorporated
If Service Tax Category was not setup in step #1, you can add them manually: setup Service Tax Categories
Populate the Tax Type Mapping table
access the EngageIP Database
run the EZTaxTaxTypeMappingInsertScript script found at the bottom of this list
ensure there are no errors and that the EZTaxTaxTypeMapping table is populated
Add a Tax Vendor for AvaTax
click Setup on the left sidebar
under the Taxes heading select Tax Vendor
if the Default tax vendor does not exist click Add
in the TaxVendor Type list select AvaTax
Populate the Tax Vendor settings (credentials provided by Avalara)
Enable taxation on invoice close select the 'Invoice Level Taxing' option here. It's recommended that this option always be selected / used
Ensure a Default tax code is setup in the AdminPortal
a. click Setup on the left sidebar
b. under the Taxes heading select Tax Codes
c. if the Default tax code does not exist click Add
d. ensure the tax code is Name is 'Default' with a capital 'D' (as the name is case sensitive) and that
the Tax Vendor is set to the AvaTax tax code you setup aboveTest to ensure that taxation is functioning: see the Post Configuration Testing section below
Optional: enable UDR (usage) taxing and other required features described below
AccountTaxCategoryXMLImport.xml
EZTaxTaxTypeMappingInsertScript
Tax Exemption Configuration
XML Import file: TaxExemptTypes
Tax Exempt Levels which are valid for Avatax (different for Billsoft) include the following (any extras in the database should be removed if coming from a prior configuration):
Federal
State
County
Local
Tax Inclusive Configuration
For inclusive taxing, you can add the 'inclusive tax' component to the service.
A void will reverse the tax as expected for inclusive taxing.
Only config needed other than the main Avatax configuration is the inclusive tax component, no service restarts necessary here
Inclusive taxing does not work for credits, usage or reversed transactions. Usage taxing will continue to tax on top of the existing charge.
Configuring UDR / Usage Taxing
Notice: All EngageIP Windows Services should be stopped before configuring UDR batch taxing.
Once the base configuration described above has been completed and tested you can configure taxing on usage. There are several options available for UDR taxing, these include:
Taxing per record (UDR) during rating
Taxing usage (UDRs) in batches for improved performance
Taxing usage when the invoice is closed
The sections below covers these three configurations.
Usage Taxation Requirements
The mediation code must have TaxThisUDR, TaxServiceType, TaxTerminationType & TaxTransactionType set, otherwise normal sales tax will be applicable to the usage instead of usage specific taxes
The EngageIP option CDRLevelTax needs to exist in the EngageIPOption table for per UDR and batch UDR billing to function. If CDRLevelTax is not present in the table then usage taxing will occur when usage is billed
Configuring Taxing Per Record (UDR)
Ensure your mediation code is configured to tax the appropriate tax types (see the usage requirements section above)
Ensure the CDRLevelTax EngageIP option exists in the EngageIP database / EngageIPOptions table. If not add it with the insert statement below
INSERT INTO EngageIPOption (Name,VALUE) VALUES ('CDRLevelTax','true')
Ensure normal usages charges (without tax) are applied for test usage (i.e. usage feeds, UUIH, rates, rate groups, rate plans, tax code setup the service tax category)
On the Setup page under UDR Feeds click the relevant feed to edit it
Under the Processors section click Add
Select SetUDRTaxing, choose a sort order and click Save
Setup a service with a service tax category (in order to apply usage specific taxes)
Ensure a tax code is configured with the service tax category and the tax code's tax vendor is set to the avatax vendor
Add the service with the service tax category to a test package and ensure the package is configured with a UDR Rate Plan containing the proper usage rates
Configure a test account, test user-package and test usage data to ensure usage taxing is working. See the Per Transaction Testing section below for steps
Configuring Batch Taxing Records (UDR)
Enable batch taxing on the Configuration page
Load the Tax Vendor and set the UDR Batch Size (this setting only appears if the 'Batch Taxing On Usage' option described above is enabled)
Note: A maximum batch size of 1,000 is recommended by Avalara as performance degrades above that size
Optional: Access the EngageIP app server and load the EngageIP\Services\UDRBatchTaxService.exe.config file. In the config file verify/adjust the settings to suit your environment:
the frequency that the usage taxes should be processed (pollingDelayInSeconds)
the number of threads to use (MinThread, MaxThread)
how long to retain data on taxes that have been processed (UDRBatchPendingTaxRecordRetentionPeriodInDays)
Follow the same configuration as described in the Configuring Taxing Per Record (UDR) section above
Start the Batch Taxing service
Test to ensure taxes are applied in the batch size and time interval you configured. See the Testing Batch Usage Taxation section below for steps
Configuring Usage Taxing on Invoice Close
Ensure Invoice Level Taxing is enabled on the Tax Vendor (credentials are provided by Avalara)
Follow the same configuration as described in the Configuring Taxing Per Record (UDR) section above
Test to ensure usage is taxed with the appropriate taxes and rates when a test account's invoice is closed. See the Testing Invoice Level Taxation section below for steps
Configuring Usage Taxing on Billing/Invoice Close
To enable taxing on billing or invoice close (whichever occurs first) you simply have to delete the CDRLevel tax entry in the EngageIPOption table. Otherwise the configuration instructions are identical to the Configuring Taxing Per Record (UDR) section above.
Configuring Tax Overrides
Tax overrides are configured in the AvaTax Admin Console. If you have issues accessing or using the Admin Console please contact Avalara.
Configuring Tax Bundles
Run the queries below to add the custom bundle name into the database for use in the UI
Insert into EZTaxTaxTypeMapping (Name, Module, TransactionType, ServiceType)
values ('CustomEzTaxBdl1', 'Custom', 20000, 20001)
Insert into EZTaxTaxTypeMapping (Name, Module, TransactionType, ServiceType)
values ('CustomEzTaxBdl2', 'Custom', 20000, 20002)Add the Service Tax Category accordingly on the Setup menu:
Edit the associated service where this bundle is to be applied and add the ‘Service Tax Category’ component and select this item from the list
Post Configuration Testing
Per Transaction Testing
Create a test account in the AdminPortal
Setup a valid address on the billing contact
After the address is loaded click on the address on the contact and a Jurisdiction Code should be displayed
Note: if a Jurisdiction Code is not added check the Event Log Report to see if there are any errors in relation to adding the JCodeCheck the account's Overview page to ensure the Default Tax Code is listed
Add a package to the test account and bill it (i.e. leave the Bill Now checkbox enabled)
Configure a Service with valid TaxType, if Service is not configured with TaxType, then Default TaxType: Sales Product is used (i.e. TransactionType: 10 and ServiceType: 15).Load the Transactions page and the taxed amount should be shown
Clicking the ID column on the Transactions page (not shown in the image above) will provide additional details. Specifically the Tax Code used to apply the tax and the specific tax and rate applied will be displayed
Testing Usage Taxation
Create a test account and add an address to the billing contact
Ensure the Jurisdiction Code is added to the billing contact's address after the address is added
Add the test package to the test account and ensure the usage identifier (UUIH) value is populated when configuring the user-package
If not already running, start the EngageIP rating and billing Windows services
Add test usage / a usage record relating to the test service's UUIH and ensure it the usage record is processed without a rating exception
On the Tools page bill the account and ensure the Date and DateEnd range you enter covers the time the usage occurred / the date specified in the test usage record
Check the account's Transactions page and locate the usage
Note: the transactions may not appear for a minute or two depending on how busy the EngageIP app server is with queued events/jobsClick on the usage charge to edit it and the Transactions section will list the taxes that have been applied. The expected taxes and rates for the usage in question should be displayed
Testing Batch Usage Taxation
Follow the Testing Usage Taxation steps above
Verify that the batch taxing occurs when the pollingDelayInSeconds (configured frequency) is reached. Even if only one usage record needs to be taxed the data will be sent to the Avalara server for tax calculation (the system will not wait until the batch size is reached)
Generate enough test usage to exceed the UdrBatchSize. When the polling time is reached check the Event Log to verify that the UdrBatchSize is broken up into more than one batch (Event Log 'Action' column can be filtered by 'ProcessBatchUDRTaxes' to find the batch taxing events. The total number of batches and records will be shown in the 'Result' column)
If you wish to see the transactions and taxes applied to the test account, load the account and bill it via Tools / Bill Account. Ensure the date range you bill for covers the date the usage occurred on
Testing Invoice Level Taxation
This process is very similar to the per transaction test steps above, you simply have to add the step of closing the invoice once the package has been billed on the test account. After the invoice is closed taxes will appear on the Transactions tab as described above.
Note: Taxing at an invoice level as configured on the Tax Vendor config on setup will tax based on the invoice date (transaction date is not considered when applying tax in this fashion). When the invoice is closed, the invoice date is calculated based on bill group settings for invoice close date, and at that time, it calculates the tax using the invoice date that is set on the invoice.
Logs and Reports
The Tax Log contains a high level of detail on taxes that have been applied
The Event Log captures system event details and is useful for verifying which events have occurred or failed. For instance, if jurisdiction codes are not being added to contact addresses the event log should contain failure messages indicating the cause (e.g.