UK: 
USA:
I was recently asked a question along the lines of: ‘How can Oracle E-Business Tax be configured so that, for the same customer and province, one group of products is taxed at 5% while another group of products is treated as zero-rated or exempt?’
This is actually a very common Canadian Oracle tax requirement, and the good news is that Oracle Cloud or E-Business Tax can handle this very effectively, provided the tax configuration is structured correctly.
One of the biggest mistakes I see in Canadian eBTax implementations is configuring Canada in the same way as a US jurisdiction-based tax model. While this may seem logical initially, it often creates unnecessary complexity and makes the solution much harder to maintain over time.
In many cases, a cleaner and more scalable approach is to:
- Create the Canadian provinces as separate taxes
- Use tax rules to drive tax determination including different tax logic by tax if a province needs special treatment
- Use item classification codes to identify the treatment of goods and services sold
- Combine determining factors to support province-specific tax logic
This provides significantly more flexibility and keeps the configuration easier to support long term.
Why avoid a jurisdiction-based Canada setup?
The US tax model is heavily jurisdiction-driven because taxes are typically determined by combinations of:
- State
- County
- City
- District
Canada generally does not require this same level of jurisdictional complexity.
Trying to force Canada into the same jurisdiction-based structure inside Oracle eBTax can make rule management unnecessarily difficult, particularly when:
- Different provinces have different exemption rules
- Certain products are exempt only in specific provinces
- Customer-specific exemptions must also be considered
Instead, a much cleaner design is to:
- Create each province as its own tax
- Use determining factors and tax rules to control when the tax applies
This naturally allows the place of supply to drive the provincial tax logic and most of the tax rules can simply be assigned to each tax without having to be duplicated
Driving logic from classifications
You can determine tax treatment directly from the item description.
A better practice is to use things like:
- Item fiscal classification codes
- Product classification codes
- Intended use classifications
Examples might include:
- INSURANCE
- MEDICAL_EQUIPMENT
- ZERO_RATED
- EXEMPT
- SERVICES
These classifications can then be used directly inside Oracle tax determining factors and tax rules.
This approach is:
- Easier to maintain
- More scalable
- More auditable
- Far cleaner than relying on descriptions or custom hardcoded logic
Example: British Columbia exemption logic
For example, under the British Columbia tax setup, you could create a rule such as:
Rule conditions
- Ship-To Province = British Columbia
- Item Classification Code = EXEMPT
Result
- Apply exempt tax status
Because the rule is created specifically under the British Columbia tax, it will only apply to BC transactions.
Combining multiple determining factors
One of the major strengths of Oracle tax is the ability to combine multiple determining factors together.
For example:
British Columbia
- If Item Classification = EXEMPT
- Then transaction is exempt
Quebec
- If:
- Item Classification = EXEMPT
- Customer Party Classification = ALLOW_EXEMPT_SALES
- Then transaction is exempt
This allows:
- The same item classification codes to be reused globally
- Province-specific logic to remain isolated
- Customer-specific exemptions to be layered on top
The end result is a highly flexible and maintainable configuration.
What if you truly need product description logic?
If the requirement genuinely requires taxation based on the actual product description itself, this is also possible for Oracle R12, although I would generally recommend treating this as a last resort.
In this scenario, Oracle eBTax Tax Extensibility can be used.
With the relevant patches applied, the Tax Extensibility framework allows custom code to execute between:
- The transaction tax call
- The execution of the Oracle tax engine
This means you can:
- Read the actual product description
- Apply custom logic
- Derive additional tax attributes
- Pull additional data from external systems
- Populate extensibility fields
- Use those fields inside standard eBTax rules
This framework is extremely powerful and can support highly complex tax determination requirements while still allowing the final tax calculation to remain inside standard Oracle EBTax processing.
Final thoughts
Oracle E-Business Tax is extremely flexible, but success depends heavily on how the initial tax structure is designed.
For Canadian implementations specifically, my recommendation is generally to:
- Avoid using jurisdictions in the same way as the US
- Use province-based taxes
- Drive logic through rules
When configured correctly, Oracle tax can support very sophisticated Canadian tax requirements without excessive customisation.
