Rule Qualifiers

Rule qualifiers give you the ability to fine tune your tax rules to specific transaction scenarios through the use of four conditions: authority, license, list, and rule. You can use rule qualifiers in scenarios such as:

  • Enterprise zones (zones outside of, and not supported by, Determination; typically an economically disadvantaged area where tax incentives are offered).
  • Excise tax.
  • GL Account code, Plant ID, or other XML element matching.

Determination maintains rule qualifiers in standard ONESOURCE Indirect Tax Content. Rule qualifiers attach to custom rules that you create.

  • Licenses help drive rule selection through the use of rule qualifiers.
  • Excise tax relies on authority conditions to determine which authorities should tax the transaction.
  • Reference lists enable simplified rule selection based on membership of a value in a list.
  • Taken together, the conditions offered by rule qualifiers enable you to be more specific about when a specific tax rule is or is not selected.

When should a Rule Qualifier be used instead of a TransEditor?

You may already be familiar with using TransEditors. TransEditors enable you to modify the actual XML transaction data sent from your ERP system to Determination based on criteria you specify. In some cases, it may be advantageous to use a rule qualifier instead of a TransEditor.

There are two primary reasons to use a qualifier instead of a TransEditor:

  • Scope: If a scenario can be addressed by a qualifier (it is, for example, specific to a single tax authority), use the rule qualifier. If the scenario applies to multiple authorities, a TransEditor may be more appropriate.
  • Maintenance: Rule qualifiers can be easier to read and maintain than TransEditors.

Types of Rule Qualifiers

You can set four conditions types on a rule: Authority, License, List, and Rule. These conditions can be used in combination, or in an "and/or" rule as needed.

Each condition is described in a table below and illustrated with an example.

Authority Condition

Purpose

Allows you to test if another authority will or will not assess tax of the specified type for a particular transaction.

Example

In a pipeline scenario, an Alabama Authority only assesses tax if Florida does not.

License Condition

Purpose

Allows you to test if a transaction's buyer or seller has a license that matches or does not match a specified license type.

Example

The customer has a license that enables exemption from tax for this authority.

List Condition

Purpose

Allows you to test if an XML element contains or does not contain a specific value found in the selected reference list.

Example

Custom Attribute 1 contains a Project ID. You can test to see if the XML element matches a value in the specified reference list.

Rule Condition

Purpose

Allows you to test if an XML element's value meets a specified condition.

Example

You can test to see an Invoice Number begins with the string ZZX.

The license type indicates this example is an Enterprise Zone. When working with enterprise zones, addresses may need to be more specific in some instances (for example, a street address) to arrive at the correct taxation.

As well, ERP systems can identify enterprise zones differently. Depending on your configuration and the frequency of customer applicability, other rule qualifiers could drive the correct taxability.

Combining Conditions on a Rule

You can combine multiple conditions on a rule when:

  • Conditions of various types must resolve as "ands" for the rule to match.
  • If one condition is false, the entire qualifier is false and the rules does not match unless multiple authority conditions are present. Only one must resolve as true. All other conditions of other types must also be true.

Using Reference Lists with Rule Qualifiers

Reference lists allow you to reduce the number of rule qualifiers and TransEditors that you need to create. Using reference lists, you can maintain lists of related items and organize conditions in a manageable way. For example, you can add a selected Project ID for inclusion in a reference list. Then the list of IDs can be referred to on a custom rule to trigger a specific rate.

As shown below, a reference list is simply a table of values, each including a start date and optional end date:

The rule qualifier indicates that the particular Project ID passed in Attribute 1 exists in the Project ID reference list, so the associated rate will be triggered.

Reference lists can also be used with TransEditor to allow a single TransEditor to fire on a value contained in the list. This practice allows one TransEditor for several situations, rather than requiring a custom TransEditor for each. For more information, see TransEditors. You may also want to review Reference Lists.