- App Store
xTuple ERP offers a comprehensive and flexible design for taxation intended to address the unique requirements for sales Tax around the world. This section illustrates how this capability can be adapted to wide-ranging requirements. It also offers tips for users migrating from previous releases of xTuple ERP.
In this scenario, we will show the setup for and operation of a simple Tax scheme in which there are two Tax Authorities (described as "Tax Zones"). Two Tax Types will also be defined—one for Normal Products (Tax Type 1) and one for Educational Products (Tax Type 2). The same Customer will ship to two different stores, each of which will fall under the jurisdiction of a different Tax Authority. In one case, Educational Products are taxed at 1% and Normal Products at 5%. In the other, both are taxed at 5%. Two Items will be defined—one a normal toy truck (YTRUCK1) and the other an educational toy truck (ETRUCK1). We will demonstrate how xTuple ERP applies the appropriate Tax to each S/O Line Item depending on the Item ordered and the Ship-To Address selected. Tax Codes have been established to determine the Tax Rate to apply (5% or 1% in this example) and the appropriate General Ledger (G/L) Account to use.
Creating G/L Accounts for Taxation
xTuple ERP gives you the ability to collect Taxes on Sales Orders. There are generally two methods for recording the collection of sales Tax in the General Ledger:
- Tax Liability: Taxes collected from Customers are recorded as a liability on the balance sheet. When the Tax is paid, the liability is reduced based on the amount of the payment. In this section, we will create two Expense Categories—one for each of the Customer scenarios. Each Expense Category is linked not to a G/L expense Account (as the name implies) but rather to a liability Account corresponding to the type of Tax being paid. When a Voucher for a Tax payment is posted, the liability Account linked to the Expense Category is cleared and the cash Account on which the Check is drawn is charged.
- Tax Revenue: Using the method described above assumes that Tax collected from a Customer is revenue and as such is posted to a revenue Account in the G/L. Expense Categories are established that charge G/L expense Accounts when the Tax is paid to the Tax Authority thereby offsetting Tax revenues and Tax expenses on the Income Statement.
These two methods are not mutually exclusive, but the relationships between Tax Codes, Expense Categories, and corresponding G/L Accounts and Tax Authorities must be carefully thought out.
You will setup your G/L Accounts with the level of detail necessary to provide the insight and reporting you require for your situation. The following screen shows the Account detail for a Tax liability Account:
G/L Account Definitions
In this example we have created Accounts that relate to Tax Types and Tax Authorities. This may be desirable if you plan to use the Financial Reporting Engine (FRE) to perform financial analysis or to generate supporting documents for Tax returns that require this level of detail.
The following Tax-related screens are grouped together in the "Tax" section of the Account Module:
- Tax Authorities
- Tax Codes
- Tax Types
- Tax Selections
- Tax Registrations
We will look at each of these Master Information categories—with the exception of Tax Registrations, which are used (optionally) to store Tax Account numbers by Tax Authority.
Creating Tax Authorities
Tax Authorities are defined as CRM Accounts in xTuple ERP, as shown in the following screenshot:
Tax Authority CRM Account Definition
If you need to generate a Check to pay Taxes to a Tax Authority, the parent CRM Account should also be defined as a Vendor in order to facilitate the payment process.
The detail under a Tax Authority provides a place to store Account information, Contacts, and Addresses.
Customer Ship-To Tax Definitions
In this scenario, we will use one Customer who ships to stores that fall under the Tax jurisdiction of two different Tax Authorities, each with different Tax Rates on different types of products.
Customer Ship-To Tax Definition
The critical field for taxation is the "Tax Authority" field. In this case we see that Store 1 falls under the Tax jurisdiction of TAXZONE1. Store 2 (not shown) falls under TAXZONE2.
Tax Code Definitions
Tax Codes hold both the rate(s) at which Tax is calculated and the G/L Account(s) Tax transactions are posted to. You can see a sample Tax Code detail in the following screen:
Sample Tax Code Detail
You may define up to three Tax Rates. Each is calculated independently, unless the "Cumulative" box is checked. When that option is selected, Tax is calculated cumulatively on the previous Tax Rate. Such a scenario is very rare.
Notice that G/L Accounts are also linked to each Tax Rate. The same Account may be used for all three Tax Rates—or a different Account may be used for each to capture more detail for G/L and Tax reporting purposes.
Tax Type Definitions
Tax Types are linked to Items and Tax Authorities in an Item's P/D record. You should think carefully about how to approach Tax Types. For example, you may consider creating Tax Types that relate to different Tax Authorities. In this case, you might have Tax TYPE10 and Tax TYPE15. A single Item could be linked to each—TYPE10 for each Tax Authority that taxes it at 10% and TYPE15 for each that taxes it at 15%.
A sample Tax Types list is shown in the following screen:
Another strategy is to relate the Tax Type to Product Categories. In our scenario, we have Normal Products and Educational Products. The relationship between Item, Tax Type, and Tax Authority is then established based on how each Tax Authority treats that type of product.
When considering your Tax Types set up, the following example may prove useful. It illustrates a case where if Tax Types are defined effectively, you can get away with only one Tax reference on affected Item masters.
In some places ice cream is considered a non-essential item, and it is taxed at the standard tax rate. In other places, the same ice cream is considered a food item and so is taxed at an intermediate rate. And in yet other places, ice cream is classified as a dairy item, meaning it is "essential" and so is not taxed at all. This handling of ice cream is unique. Other edibles sold and bought in the same places are not handled in exactly the same way. Milk, for example, is always considered essential and so it is never taxed. The result is that anyone who sells ice cream items in areas with different tax structures needs to create a specific Tax Type ICECREAM to be able to enter just one Item Tax record for each ice cream Item in the system. A Tax Type of FOOD would be insufficient, since ice cream and milk are both foods--but they are not taxed the same in all places.
Some Tax Authorities charge Tax on Freight. A reserved Tax Type called Freight is pre-populated in the xTuple ERP database specifically for this purpose. On the Tax Selection screen (see below), the freight Tax Type is then linked to a) Tax Authorities that charge Tax on freight and b) Tax Codes that contain the appropriate rate.
Tax Selection Matrix
Before we look at an Item and its relationship to Tax Types, let's take a look at Tax Selections. The Tax Selections screen creates a matrix combining the Tax Type (linked to the Item), the Tax Authority (also linked to the Item), and the Tax Code. The following screen shows a sample Tax Selections master list:
Here we see that Tax Authority TAXZONE1 links two different Tax Types (one for Normal Products and one for Educational Products) to two distinct Tax Codes. Tax Code ZONE1-TYPE1 will calculate the Tax at 5% and post it through to a special G/L Account. Tax Code ZONE1-TYPE2 will calculate the Tax at 1% and post it through to a different G/L Account. Any Tax Type linked to TAXZONE2 will result in a 5% Tax calculation defined in the Tax Code ZONE2-TYPE1. A distinct Tax Code was defined ONLY because this Tax Code links a G/L Account specifically defined to hold Tax Authority TAXZONE2 balances. Were this not desired, a single 5% Tax Code could have been use for both TAXZONE1 and TAXZONE2.
Item Tax Type Assignments
The Item record contains a tab called "Tax Types." This tab is used to associate an Item with a Tax Type and corresponding Tax Authority.
The same Tax Type may be taxed differently by different Tax Authorities. This is controlled on the Tax Selections screen, where Tax Authorities/Tax Types are linked to Tax Codes (which determine Tax Rates).
The following screen shows the "Tax Types" tab on a sample Item master:
Item Tax Types Assignments
By default, an Item is not taxed if no relationship has been created to link it to a Tax Type and Tax Authority. However, it may be desirable in some cases to intentionally indicate that an Item is not taxed for a specific Tax Authority. If so, you would set this up by creating an appropriate Tax Type/Tax Authority relationship on the Item master. You would then link this relationship to a Tax Selection record pointing to a Tax Code having a 0% Tax Rate. Again, this is optional and may or may not be desirable.
Clearing Tax Liability with Expense Categories
Because we are charging Customers Tax that we must ultimately pay to Tax Authorities, it is important to have a mechanism for making payments to Tax Authorities. Sales Tax is a liability that must be settled. As we saw in <xref></xref>, our sample Tax Code references a liability Account. By creating an Expense Category that links to the same liability Account, we can clear our Tax liability when we post Vouchers that pay Tax Authorities.
The following screen shows a sample Expense Category detail:
Expense Categories for Tax
Notice how the "Expense" field for Expense Category TAXZONE1-TYPE1 is linked to a liability Account. When we Voucher our payment to the Tax Authority, we will use this Expense Category to clear the liability.
An alternate method for clearing Tax liability is to book the Sales Tax collected to a Revenue Account—and then offset it with an Expense Category linked to an expense Account.
Sample Sales Order
Let's create a Sales Order for a Customer Ship-To Address that taxes Educational Products at one rate and Normal Products at another. In addition, we will use a Tax Selection record that links the Freight Tax Type to a Tax Code, thereby causing Tax to be calculated on the freight charge.
The following screen shows the Line Item Tax detail for the sample Sales Order will be using:
Sales Order Line Showing Tax Detail
To view Line Item Tax detail, simply click on the "Tax" hyperlink found on the Sales Order Item screen.
While Tax is calculated at the Line Item level, we can see the Tax impact for an entire Sales Order from the "Line Items" tab, as shown below:
Sales Order Line Items Showing Tax Breakdown
From the "Line Items" tab screen, click on the "Tax" hyperlink to see an overview of the Tax calculation for the entire Order. In this case, the total Tax resulted from the educational Item taxed at 1%, a normal Item taxed at 5%, and freight taxed at 5%.
When the product is shipped and the corresponding Invoice is posted, the appropriate Tax Accounts will be reflected in the G/L.
G/L Transactions After Invoice Posting
You will recall that in this scenario we are posting Sales Tax to a liability Account. And even though it is not necessary to do so, our example uses a different G/L Account for each different Tax Type/Tax Authority combination we are using. This varied approach enables us to better demonstrate how the Financial Reporting Engine (FRE) can be used as a Tax reporting tool.
The following screen shows a summary of the G/L transactions recorded after we posted the Invoice corresponding to our initial Sales Order:
Summarized G/L Transactions for Sales Tax on an Invoice
Now that we have accrued the liability for the sales Tax, we must next pay the Tax Authority.
Tax Payment at Vouchering
While a Miscellaneous Check could be used to pay the sales Tax we have collected, a Voucher provides an additional level of control—and also give us the ability to define amounts specific to the different types of Tax being paid. A Miscellaneous Check may only be linked to a single Expense Category; whereas, a Voucher can have an unlimited number of distributions to different Expense Categories.
The following screen shows a sample Miscellaneous Voucher Distribution:
Voucher for Tax Payment
Miscellaneous Distributions on a Miscellaneous Voucher enable us to select the appropriate Expense Category for each type of Tax being paid on a single payment. You may recall that our scenario links an Expense Category to the same G/L Account used for accruing sales Tax liability. Paying taxes in this way enables us to clear the appropriate liability Account when we post Miscellaneous Vouchers.
In the following screen you can see a summary of the G/L transactions which resulted from out posting of the Miscellaneous Voucher:
G/L Postings After Voucher Posting
Posting the Voucher cleared the liability Accounts associated with the Expense Categories used on the Voucher. The A/P liability will subsequently be cleared when a Check paying the Voucher is posted.
Taxes on Purchases
Just as we calculated sales Tax for our Customers, our Vendors will do the same for us. Tax on purchases appears on the Vendor's invoice—and should be recorded during the vouchering process. Again, when vouchering we can use Miscellaneous Distributions along with Expense Categories to record purchasing Tax.
The following screen shows a sample Expense Category we have established to record Tax on purchases:
Expense Category for Taxes on Purchased Items
We will use the Expense Category during a vouchering scenario. In our example, the Vendor is charging us Tax on one or more Items of Type 1. The following screen shows the Voucher for this purchase, as well as the Miscellaneous Distribution for Tax purposes:
Miscellaneous Distribution of Voucher to Pay Tax
The Purchase Order we are vouchering is for a Vendor invoice totaling $220.00. Of this amount, $200.00 is for the product and $20.00 is for Tax. The Tax is accounted for using the Expense Category corresponding to the type of Tax being paid. Because Expense Categories are linked to G/L Accounts, the Tax amount will be posted to the appropriate Account.
If multiple types of Taxes are identified on a Vendor invoice, multiple Expense Categories pointing to different Tax Accounts may be used.