Uniformly delivers tax services to
all Oracle Fusion application business flows through one application
interface

Provides a single integration point
for third-party tax products and services

Is configurable and scalable for
adding and maintaining country-specific tax content

With Oracle Fusion Tax, you can model your taxes according
to the needs of the following local and international tax requirements:

Both simple and complex country-specific
tax legislation

Cross-border transactions, including
exports and Intra-European Community transactions

Intercompany transactions

Local compliance requirements for
recording and reporting

Continual changes to tax legislation,
such as new taxes, local law changes, special tax rates, and special
exceptions for products and customers

You can manage the entire configuration and maintenance
of tax content from the one Oracle Fusion Tax application. Using one
application ensures a uniform tax setup across applications, with
a centrally managed system of automated tax services and control over
manual intervention and update.

Define Tax Geographies: Configure
tax geographies to define geographical regions that share the same
tax requirement. These prerequisite tasks are required for core tax
configuration but they might not have been defined in the previous
steps of the Financials offering.

Define Tax Regimes: Configure tax
regimes for the taxes in each country and geographic region where
a separate tax applies. These tasks are most commonly used by all
the implementations. You should be able to calculate taxes on the
transactions based on this configuration.

Define First Party Tax Profiles:
Configure tax profile details that control the transaction tax activities
for your first party legal entities, legal reporting units, and business
units.

Define Third Party Tax Profiles:
Configure tax profile details that control the transaction tax activities
for your third party customer, customer sites, supplier, and supplier
sites.

Define Occasional Implementation
Setups: Configure initial tax setup that impacts tax calculation and
reporting. These tasks either are predefined and you do not have to
configure them unless the predefined data needs to be extended or
these are tasks required only for certain implementations.

Defining Transaction
Taxes: Critical Choices

With Oracle Fusion Tax, you can model your
tax requirements according to the needs of local and international
tax requirements. These requirements include:

Both simple and complex country-specific
tax legislation

Cross-border transactions

Local compliance requirements for recording
and reporting

Continual changes to tax legislation,
such as new taxes, local law changes, special tax rates, and special
exceptions for products and customers

In order to determine how to set up your tax configuration,
you must first analyze your tax requirements.

Analyzing Your Tax Requirements

The following table represents key decisions
that you must make when you analyze your tax requirements and use
Oracle Fusion Tax and other Oracle Fusion applications to implement
a solution

Question

Consideration

Impact to Tax Configuration

Who am I?

You must first answer questions about yourself and
your relationship to the legal and regulatory agencies that enable
you to operate in one or more counties.

Where do I have operations and businesses?

Identify the countries in which you operate. You will
need to identify the country where you are legally registered and
the countries where you have subsidiary companies that are legally
registered or have a legal presence.

Analyze your tax environment for each of the countries
in which you operate.

Set up your tax regimes, taxes, and tax jurisdictions
according to the tax requirements for each country.

What are the operations and businesses that I have?

Consider the types of operations and businesses in
which you are engaged and the countries where you have legal entities
or reporting units. The type of industries that you work under (for
example, mining, telecommunications, and pharmaceuticals), the kind
of operations in which you engage (for example, trading, manufacturing,
and services), and the scale of your operations (for example, your
turnover, company size, and growth) may all impact your taxability.

Use the classifications feature to categorize or classify
your first parties under various classification schemes.

In analyzing your operations, you can associate the
three main classifications of a transaction to:

What you do: Use transaction fiscal
classifications.

What products you buy or sell: Use
product fiscal classifications.

Who your customers and suppliers are:
Use party fiscal classifications.

What do I do?

Identify and classify the transactions that you enter
into. For example, do you primarily sell physical goods? If you do,
do you manufacture them, or do you buy and sell them without additional
manufacturing? Do you sell these goods in another state or province?
Do you export these goods? Do you provide or use services?

Use Oracle Fusion Tax to create fiscal classifications
to classify and categorize your transactions in a common manner across
your organization. Use these fiscal classifications in tax rules to
obtain the appropriate tax result.

What products do I buy or sell?

Determine the products that you buy and sell as they
impact the taxes to which you are subject. For example, you must register
for, and therefore collect and remit, service taxes only if you provide
taxable services. If you manufacture goods for export, you may not
be subject to taxes on the purchases that go into the manufacture
of such goods.

Where Oracle Fusion Inventory is installed use the
Inventory Catalog feature with Oracle Fusion Tax product fiscal classifications
and intended use functionality to classify the taxable nature and
intended use of the items. You can then define tax rules using these
classifications to obtain the appropriate tax result.

Define product category and noninventory-based intended
use fiscal classifications to address classification needs for transactions
that do not use inventory items.

Who are my customers and suppliers?

Determine the types of customers and suppliers with
whom you do business, as they can impact the taxes to which you are
subject or the tax status or tax rate that applies. For example, let's
say that you are a company in the UK that supplies physical goods
to another country that is also a member of the European Union. The
transaction rate for UK VAT is dependant on whether the customer is
registered for VAT in the country to which the supply is made.

Use the party classifications feature to categorize
or classify your customers and suppliers. You can use these classifications
in your tax rules to derive the appropriate tax result.

You create a party fiscal classification by assigning
an Oracle Fusion Trading Community Model class category to a party
fiscal classification type code that you define. The Trading Community
Model class codes defined under the class category become fiscal classification
codes belonging to the party fiscal classification type. You can create
a hierarchy of party fiscal classification types to reflect the levels
of codes and subcodes within the Trading Community Model classification.

Scope Values
for Define Transaction Taxes Task List: Explained

The purpose of scope is to define the parameters
of your implementation project by setting the context of a task list
during initial configuration. The foundation tax setup is an incremental
setup where each step of the foundation configuration builds on the
previous step. The task list is organized sequentially to ensure that
you perform setup tasks in the order required. You can define scope
values at incremental steps in the implementation project to pass
to subsequent tasks to ensure continuity and ease of setup. Additionally,
when exporting setup data based on setup migration services, the scope
values serve as parameters to control the data selected for export
to the respective configuration package. It is important to note that
while scope is a valuable tool when implementing, tax scope values
are not a required element of the implementation and you do not need
to define them.

When implementing tax the foundation setup task of
Define Tax Regimes prompts you to Select and
Add or Create New the
scope value for the implementation project. You can select an existing
tax regime value or define a new tax regime value to set the scope.
You can also Select and Add multiple
scope values to the implementation. When you select the tax regime
value to define the scope of an implementation project the feature
selection is available to further define the constructs of the implementation.

As you continue the incremental setup, the next task
is to define a tax. You are prompted to Select
and Add or Create New the tax value. The tax regime scope value already associated to
the implementation project filters existing taxes and assigns the
tax regime value to any newly defined taxes. This controls the parameters
of the implementation to be within the context of the tax regime.
When there are multiple scope values passed, it is referred to as
a composite scope.

The same logic applies to the next step in the foundation
setup when you define a tax status. The tax status, either new or
existing, is in the context of the tax regime and tax scope values.
Tax regime, tax, tax status, and tax rate are all scope values defined
within the implementation project.

Scope Values

The following table identifies where you define the
scope value in the implementation project and what tasks the scope
value is passed to:

Scope

Where Scope Is Defined

Tasks Impacted by Scope

Tax Regime

Define Tax Regimes

Manage Tax Regimes

Manage Taxes

Manage Tax Jurisdictions

Manage Tax Statuses

Manage Tax Rates

Manage Tax Recovery Rates

Manage Tax Rule Type tasks

Tax

Define Taxes

Manage Taxes

Manage Tax Jurisdictions

Manage Tax Statuses

Manage Tax Rates

Manage Tax Recovery Rates

Manage Tax Rule Type tasks

Tax Status

Define Tax Statuses

Manage Tax Statuses

Manage Tax Rates

Tax Rate

Define Tax Rates

Manage Tax Rates

Foundation
Tax Configuration: Points to Consider

Use Oracle Fusion Tax to set up and maintain
your transaction tax requirements in all geographic locations where
you do business. Foundation tax configuration refers to a set of tax
setup components that you will use to satisfy your tax requirements.
At transaction time, Oracle Fusion Tax uses your tax configuration
to determine the taxes that apply to each transaction and to calculate
the tax amounts.

Foundation tax configuration components consist of:

Tax regimes

Taxes

Tax jurisdictions

Tax statuses

Tax rates

Foundation Tax Configuration

Complete the setup tasks to create a basic
tax configuration for each of your tax regimes. A foundation tax configuration
contains the data applicable to the taxes belonging to a tax regime.
The following table describes the appropriate levels of specifying
setup options for foundation tax components and provides a Canada
Goods and Services Tax (GST) and Harmonized Sales Tax (HST) example
for each component.

Component

Appropriate Level to:

Typically, Not Appropriate Level to:

Canada GST and HST Example

Tax Regime

Share tax content among legal entities
and business units.

Enable partner integration.

Associate fiscal classifications.

Define tax reporting types and codes.

Define features to influence setup
task list.

Define configuration owner tax options.

Define application tax options.

Define party tax profiles.

CA GST & HST

Tax

Enable controls to influence tax
behavior.

Specify defaults that are commonly
applicable.

Define applicability tax rules.

Define customer exemptions.

Specify party registrations.

Share tax content.

Define integration with partners.

CA GST

CA HST

Tax Jurisdictions

Define location-based tax rates.

Define customer exemptions and rate
exceptions.

Specify tax rule defaults.

CA Alberta GST

CA BC HST

Tax Status

Define common rules for tax rates.

Drive reporting needs.

Allow manual override to tax rates.

Specify tax rule defaults.

Define customer exemptions.

Specify party registrations.

GST Standard

HST Standard

HST Reduced

Tax Rates

Define tax rates by effective periods.

Specify tax account variations.

Define tax rate exceptions.

Define tax recovery rates.

Define customer exemptions.

Define applicability tax rules.

Define taxable calculation formulas.

Share tax content.

CA GST Standard

CA GST Reduced

CA GST Exempt

CA HST Standard

Advanced Tax
Configuration: Points to Consider

Create a simple tax model using tax rule defaults
that you define in setting up your foundation tax configuration. You
can also create tax rules for your complex tax requirements that consider
each tax requirement related to a transaction before making the final
tax calculation. When running the tax determination process, Oracle
Fusion Tax evaluates, in order of priority, the tax rules that you
have defined against the foundation tax configuration setup and the
details on the transactions. If the first rule is successfully evaluated,
the result associated with the rule is used. If that tax rule is not
successful, the next rule is evaluated until either a successful evaluation
or a default value is found.

Advanced Tax Configuration

The complexity of tax rule setup falls into
three general categories: no tax rules required, simple tax rule regimes,
and complex tax regimes. This table presents the scenarios and actions
associated with each of these categories.

Category

Scenario

Action

No tax rules required

The tax authority levies tax on all sales and purchase
transactions at the same rate. Neither tax applicability nor the tax
rates and recovery rates vary by the parties to the transaction, the
products or services in the transaction, or the business processes
involved in the transaction.

For the tax, define tax rule defaults for the tax
status, tax rate, and tax recovery rate. The tax determination process
uses the tax rule defaults to determine the tax.

Simple tax rule regimes

The tax authority levies tax on your transactions
at the same rate, with a simple set of identifiable exceptions. The
exceptions either apply to one part of the transaction only, such
as to certain parties, or to a combination of parties, products, and
transaction processes that you can summarize in a simple way.

Create a simple set of rules, for example, to identify
place of supply and tax registration, and use the tax rule default
values for the other processes. The tax determination process uses
the tax rules and the tax rule defaults to determine the tax.

Complex tax regimes

Tax regimes in certain countries require a complex
logic to determine the applicable taxes and rates on a transaction.
Both tax applicability and tax rates can vary, for example, by place
of origin and place of destination, party registration, tax status,
service, or a combination of factors. In some cases, the taxable amount
of one tax may depend upon the amount of another tax on the same transaction.
And in rare cases, the tax amount itself may depend on the tax amount
of another tax.

Set up tax rule to define the logic necessary to identify
each step of the tax determination process. The tax determination
process uses the tax rules to determine the tax.

Define Exception to Default Results

Set a tax rule default value to the most commonly
used value for tax determination. In the case of tax registration
the default or most commonly used value for registration party is
ship-from party. However, you can set up a rule to provide additional
logic to use the registration of the bill-to party if the registration
status is Not Registered for the
ship-from party for purchase transactions. Create a determining factor
set with the registration status and transaction business category
determining factors along with condition sets to provide values for
the respective determining factors.

For this example, the following setup exists for the
Determine Tax Registration tax rule:

Tax rule: If the supplier is not
registered, then you should consider the tax registration of the bill-to
party.

When the following conditions are true, then the tax
registration is the same as that defined for the bill-to party:

Tax Determining Factor Class

Tax Class Qualifier

Tax Determining Factor

Operator

Value

Registration

Ship-from party

Registration status

Equal to

Not registered

Transaction Generic Classification

Level 1

Transaction business category

Equal to

Purchase transaction

The tax determination process determines the tax registration
by first considering the Determine Tax Registration tax rule and then
the default party registration. As a result of this rule, the tax
determination process determines that for a purchase transaction,
if the supplier is not registered, the tax registration of the bill-to
party is considered.

Define Tax Geographies

Place Information: Explained

All tax regimes need information about place or geography.

Information is required to determine:

Where the tax is applicable

The tax rules that can identify when
a transaction is an export, or delivered to another country, or deliveries
inside or outside an economic region such as, the European Community
(EC).

Specific regions such as, city, country,
and states for US Sales and Use Tax or provinces in Canada.

To support these requirements, Oracle Fusion Tax allows
you to define and use geography regions and tax zones. Geography regions
and tax zones provide a conceptual model to use place information
on transactions and information related to the transaction.

The following types of places are supported for tax
purposes in Oracle Fusion Tax:

Country information: Use country
as a specific geography element in tax rules to define tax regimes,
taxes, and tax jurisdictions.

Use place information for determining factors within
tax rules in the tax determination process. Also, use place information
while defining tax regimes, tax geography, and tax jurisdictions.

Country Information

Country is a required field in all of the
tax-related address locations. The country fields are supported by
a predefined ISO 3166 country name and two-character country code.
For more information on country names and codes, see http://www.iso.org/iso/english_country_names_and_code_elements.

You do not set up a country as a specific geography
level in Trading Community Model geography because country is an inherent
part of all tax-related address locations.

Tip

Use the highest level of geography, typically country,
wherever possible.

Geography Elements

Define geography elements as part of Trading
Community Model geography. They control the use of geography and addresses
throughout Oracle Fusion. Oracle Fusion Tax commonly uses the following
features: geography or tax zones, geography levels, address controls,
and geoname referencing.

Use geography levels to define the levels of geography
that are used within a country. For example, addresses in the US comprise
of state, county, city, street, and postal code. Addresses in the
UK comprise of county, city or town, street, and postal code. There
may be other geography elements as well, such as building. From a
tax perspective it is only those elements of the address that are
referenced for tax purposes. For example, state, county, and city
are important for US Sales and Use Tax while county in UK is not relevant
from a tax perspective and therefore, you do not need to set it up.

Tip

When address elements are needed for tax purposes,
such as country and city for US Sales and Use Tax, set these address
levels as mandatory within Trading Community Model geography. This
ensures that these elements are always present on all applicable addresses.

Setting address levels as mandatory ensures that amended
or newly applicable addresses are validated and that the level is
either derived or entered. When you are setting up migrated addresses
ensure that they are also compliant with the mandatory levels being
present. This should be validated and any address levels added as
part of the migration process.

The geoname referencing process within
Trading Community Model geography links specific addresses to the
levels defined in the geography setup. This process is typically automatic.
However, when you encounter issues, you may need to trigger this process
to ensure that all addresses are correctly linked to their applicable
levels.

Tax Zones

Use the tax zone functionality when you need
to identify a group of geography elements while calculating tax. Tax
zones are defined as part of Trading Community Model geography.

For example, in the EC it is important to know whether
goods and services are being delivered within the EC. Use the tax
zone functionality to create a tax zone, which defines the membership
to the EC as well as, the dates on which a country became the member.

Tip

Create a generic tax zone so that you create a tax
zone type that can be used in multiple situations. For example, for
a tax zone type needed to identify EC, create a generic tax zone type
for all economic communities, which can later be used in other situations
where economic communities or trade agreements affect tax determination.

You can also use the tax zone functionality to group
postal codes to provide useful groupings that can identify some higher-level
tax regions such as, cities or counties.

Country Information: How It Works in Tax Rules and on Transactions

Geography determination factors allow you
to use country information in the tax rules. A combination of determination
factor class, class qualifier, and determining factor represent these
determination factors. Specify the taxation country at transaction
time which is used, along with the tax rules, during the tax determination
process.

Country Information in Tax Rules

Use geography as the determining factor class, location
type on the transaction as the class qualifier, and country as the
determining factor. You can also use country as a tax rule qualifier.

The tax determining factors for locations are given
generic names such as ship-to and bill-from, depending on the transaction
types. The transaction types are Order-to-cash, for example, Oracle Fusion Order Management and Oracle Fusion Receivables,
and Procure-to-pay, for example
Oracle Fusion Purchasing and Oracle Fusion Payables.

Oracle Fusion Tax translates these generic locations
into specific locations based on the transaction as shown in the following
table:

Generic Party

Order-to-Cash Party

Procure-to-Pay Party

Bill-from party

Location assigned to the business unit for the transactions

Supplier

Bill-to party

Customer

Location assigned to the business unit for the transactions

Ship-to party

Customer (ship-to) party site

Ship-to location on the line

Ship-from party

Warehouse on the line. If there is no warehouse on
the line, such as with services, the default location assigned in
the Receivables system parameters is used.

Supplier (ship-from) party site

Point of acceptance party

Customer point of acceptance party

Not applicable

Point of origin party

Customer point of origin party

Not applicable

Country Information at Transaction Time

Specify the taxation country on the transaction to
identify the country in which the transaction is deemed to have taken
place for taxation purposes. The default value is the country of the
legal entity. Use the country name to search for country defaults,
which control the fiscal classification defaults, party tax profile
defaults, and tax regime and tax defaults. Use the country name to
select the following fiscal classifications associated with that specific
country:

User-defined fiscal classifications

Product categories

Intended use fiscal classifications

Transaction business categories

Using Country
Information in Tax Rules: Example

For many regimes, it is important to know
if the supply of goods is exported. The easiest way of doing this
is to ensure that the ship-from location is from the country in question
and the ship-to location is a different country.

The following scenario illustrates setting up tax
rule components to identify if the goods are exported from the United
States.

Scenario

Use geography as the determining factor class, country
as the class qualifier for ship-from and ship-to locations, and country
as the determining factor as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Geography

Ship-from

Country

Geography

Ship-to

Country

Create a condition set that refers to this geography
determining factor as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Geography

Ship-from

Country

Equal to

United States

Geography

Ship-to

Country

Not equal to

United States

Use this combination of determining factors in any
situation where you need to identify exports from the United States.

Geography Elements in Tax Rules

Use geography as the determining factor class, location
type on the transaction as the class qualifier, and geography level
such as county, province, or city, as the tax determining factor.

The tax determining factors for locations are given
generic names such as ship-to and bill-from, depending on the transaction
types. The transaction types are Order-to-cash, for example, Oracle Fusion Order Management and Oracle Fusion Receivables,
and Procure-to-pay, for example
Oracle Fusion Purchasing and Oracle Fusion Payables.

These generic locations are mapped to the specific
location, based on the transaction as shown in the following table:

Generic Party

Order-to-Cash Party

Procure-to-Pay Party

Bill-from party

First party legal entity

Supplier

Bill-to party

Customer

First party legal entity

Ship-to party

Customer (ship-to) party site

First party legal entity

Ship-from party

First party legal reporting unit

Supplier (ship-from) party site

Point of acceptance party

Customer point of acceptance party

Not applicable

Point of origin party

Customer point of origin party

Not applicable

You can also use the geography level as a tax rule
qualifier.

Using Geography
Levels in Tax Rules: Example

Use the geography element in tax rules to
identify a specific geography region when taxes in a specific country
need to identify specific geography elements below the country level.
For example, in US Sales and Use Tax for county taxes, there may be
specific rules for a specific state.

The following scenario describes how you can set up
tax rule components to identify when goods are being delivered to
a specific state, such as Ohio.

Scenario

Use geography as the determining factor class, ship-to
as the class qualifier, and state as the determining factor as shown
in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Geography

Ship-to

State

Create a condition set that refers to a specific state
value as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Geography

Ship-to

State

Equal to

Ohio

You can use this combination of determining factors
in any situation where you need to identify specific deliveries to
a specific state.

Tax Zones: How They Work in Tax Rules

Geography determination factors allow you
to use geography elements in the tax rules. A combination of determination
factor class, class qualifier, and determining factor represent these
determination factors.

Tax Zones in Tax Rules

Use geography as the determining factor class, location
type on the transaction as the class qualifier, and tax zone type
such as county, as the determining factor.

The tax determining factors for locations are given
generic names such as ship-to and bill-from, depending on the transaction
types. The transaction types are Order-to-cash, for example, Oracle Fusion Order Management and Oracle Fusion Receivables,
and Procure-to-pay, for example
Oracle Fusion Purchasing and Oracle Fusion Payables.

These generic locations are mapped to the specific
location based on the transaction as shown in the following table:

Generic Party

Order-to-Cash Party

Procure-to-Pay Party

Bill-from party

First party legal entity

Supplier

Bill-to party

Customer

First party legal entity

Ship-to party

Customer (ship-to) party site

First party legal entity

Ship-from party

First party legal reporting unit

Supplier (ship-from) party site

Point of acceptance party

Customer point of acceptance party

Not applicable

Point of origin party

Customer point of origin party

Not applicable

You can also use tax zones as tax rule qualifiers.

Using Tax Zones
in Tax Rules: Example

For the European Community (EC) or the Economic
Union (EU) it is important to know whether goods and services are
being delivered within the EC. Use the tax zone functionality to create
a tax zone that defines the membership of the EC as well as the dates
on which a country became a member.

The following scenario describes the use of a partial
condition set that you can use within tax rules to define when a delivery
is being made to an EC from the United Kingdom.

Scenario

Use geography as the determining factor class, ship-to
as the class qualifier, and all economic communities and country as
the determining factors of the tax zone type as shown in the following
table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Geography

Ship-to

All Economic Communities

Geography

Ship-to

Country

Geography

Ship-from

Country

Create the condition set as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Geography

Ship-to

All Economic Communities

Equal to

European Community

Geography

Ship-to

Country

Not equal to

United Kingdom

Geography

Ship-from

Country

Equal to

United Kingdom

You can use this combination of determining factors
in any situation where you need to identify the deliveries that are
made from the UK to other EU countries.

Define Tax Regimes

Features at
the Tax Regime Level: Critical Choices

Streamline your implementation by selecting
the features that are applicable to the tax regime in scope. Features are
used in rendering the task lists and tasks in the context of the features
applicable to the tax regime in scope.

Features

The following table displays each feature
and the impact of not selecting that feature.

Warning

Once you select a feature for a tax regime, you cannot
disable it. You can enable the feature later if you do not enable
it initially for a tax regime.

Feature

Description

Impact of Not Selecting Feature

Multiple Tax Jurisdictions

Create tax jurisdictions for a particular tax in more
than one geographic region.

The Allow multiple jurisdictions option is not available to taxes within this tax regime.

Offset Taxes

Create offset taxes for tax calculation and recording
of third party payables tax liabilities for reverse charges, self-assessments,
and in the United States, Consumer's Use tax.

The Set as offset tax option is not available to taxes within this tax regime.

Tax
Exemptions

Create tax exemptions to apply to a specific customer
or to a combination of customer and specific product.

The Allow tax exemptions option is not available to taxes within this tax regime.

Tax Rate Exceptions

Create tax exceptions to apply a special tax rate
to products.

The Allow tax exceptions option is not available to taxes within this tax regime.

Tax Recovery

Create tax recovery rates for full or partial recovery
of taxes paid on purchases.

The Allow tax recovery option is not available to taxes within this tax regime.

Tax Registration Statuses

Manage tax registration statuses to be used as determining
factors in tax rules.

The Tax Registration Status field is not available for party tax profiles. You cannot use the
tax registration status of Agent, Registered, or Not Registered in tax rules.

Party Fiscal Classifications

Manage tax classifications used by a tax authority
to categorize a party and which are applicable in the tax determination
process.

The Classifications tab is not available for party
tax profiles. You cannot use party fiscal classifications in tax rules.

Legal Fiscal Classifications

Manage classifications associated with a legal entity
that represents its legal status within a country and which also guide
the tax determination process.

The Legal Classification pages and Associated Legal
Classifications region are not available for party tax profiles. You
cannot use legal classifications in tax rules.

Product Category Classifications

Manage tax classifications for a noninventory-based
product category that is used for tax determination or tax reporting
purposes.

Manage tax classifications used by a tax authority
to categorize a product for a tax and which are applicable in the
tax determination process.

The Product Fiscal Classification pages are not available.
You cannot use product fiscal classifications in tax rules.

Transaction Business Categories

Manage tax classifications to identify and categorize
an external transaction into an Oracle Fusion Tax transaction and
which are applicable in the tax determination process.

The Manage Transaction Business Category Codes page
is not available. You cannot use transaction business category codes
in tax rules.

Transaction Fiscal
Classifications

Manage tax classifications used by a tax authority
to categorize a transaction for a tax and which are applicable in
the tax determination and tax reporting processes.

The Transaction Fiscal Classification pages are not
available. You cannot use transaction fiscal classifications in tax
rules.

Document Fiscal Classifications

Manage tax classifications used by a tax authority
to categorize a document associated with a transaction for a tax and
which are applicable in the tax determination and tax reporting processes.

The Manage Document Fiscal Classification Codes page
is not available. You cannot use document fiscal classification codes
in tax rules.

Intended Use Fiscal Classifications

Manage tax classifications based on the purpose for
which a product is used and which are applicable in the tax determination
process.

The Intended Use Fiscal Classification pages are not
available. You cannot use intended use fiscal classifications in tax
rules.

User-Defined Fiscal Classifications

Manage tax classifications for any tax requirement
that you cannot define using the existing fiscal classification types.

The User-Defined Fiscal Classification pages are not
available. You cannot use user-defined fiscal classifications in tax
rules.

Regimes to
Rates: Explained

Regime to rate setup contains the details
of a tax regime, including all taxes, tax jurisdictions, tax statuses,
and tax rates. You can update existing records or create new records
at any point in the tax regime hierarchy.

Regime to rate setup tasks include:

Tax regimes

Taxes

Tax jurisdictions

Tax statuses

Tax rates

Tax Regimes

Set up tax regimes in each country and geographical
region where you do business and where a separate tax applies. A tax
regime associates a common set of default information, regulations,
fiscal classifications, and optionally, registrations, to one or more
taxes. For example, in the United States create a Sales and Use Tax
tax regime to group taxes levied at the state, county, and district
levels.

The tax regime provides these functions:

Groups similar taxes together

Designates the geography within which
taxes apply

Applies as defaults the settings
and values that you define for each tax in the tax regime

Defines for which taxes the configuration
options apply and a specific subscription option applies

Provides a single registration for
all taxes associated with the tax regime

Defines the use of fiscal classifications
as follows:

Transaction fiscal classifications

Product fiscal classifications

Party fiscal classifications

The common tax regime setup is one tax regime per
country per tax type, with the tax requirements administered by a
government tax authority for the entire country. There are also cases
where tax regimes are defined for standard geographical types or subdivisions
within a country, such as a state, province, country, or city. In
these cases, you base the tax regime on the Oracle Fusion Trading
Community Model standard geography.

There are more rare cases where a tax regime is based
on disparate parts of a country or more than one country. In these
cases, you can create one or more tax zones and set up tax regimes
for these tax zones. You can also set up a tax regime as a parent
tax regime to group related tax regimes together for reporting purposes.

You must set up a tax regime before you set up the
taxes in the tax regime. Some tax regime values appear as defaults
on the taxes that belong to the tax regime in order to help minimize
tax setup.

You must associate a tax regime with all of the first
party legal entities and business units that are subject to the tax
regulations of the tax regime. You can set up tax configuration options
when you create or edit a tax regime or when you create or edit a
first party legal entity tax profile. Both setup flows appear and
maintain the same party and tax regime configuration options.

Taxes

Set up details for the taxes of a tax regime. Each
separate tax in a tax regimes includes records for the tax statuses,
tax rates, and tax rules that are used to calculate and report on
the tax. Oracle Fusion Tax applies as defaults tax information from
the tax regime to each tax that you create under a tax regime. You
can modify this information at the tax level according to your needs,
as well as add additional defaults and overrides. For tax rule defaults,
specify values that apply to the majority of your transactions. Use
tax rules to configure exceptions to the tax rule defaults.

Identify what taxes you must define. Each tax appears
as a single tax line on a transaction. If you need to show or report
more than one tax line per transaction line on a transaction, then
you should set up more than one tax. For example, for US Sales and
Use Tax you would define a tax for each state, county, and city.

You can create a new tax, or create a tax that is
based on an existing tax within the tax regime. You do this to minimize
setup by sharing tax jurisdictions and tax registrations. When you
create a new tax based on an existing tax, the attributes that remain
constant for all taxes derived from the source tax are not available
for update. Attributes that are copied and are display only include:

Tax regime

Tax

Geography information

Tax jurisdiction settings

Note

The enable tax settings are not selected, in the same
way that they are not selected when you access the Create Tax page.

You can enable a tax for simulation or for transactions
only after you have completed all of the required setup.

Tax Jurisdictions

Set up tax jurisdictions for geographic regions or
tax zones where a specific tax authority levies a tax. A tax jurisdiction
specifies the association between a tax and a geographic location.
At transaction time, Oracle Fusion Tax derives the jurisdiction or
jurisdictions that apply to a transaction line based on the place
of supply. You must set up at least one tax jurisdiction for a tax
before you can make the tax available on transactions.

You also use tax jurisdictions to define jurisdiction-based
tax rates. A tax jurisdiction tax rate is a rate that is distinct
to a specific geographic region or tax zone for a specific tax. You
can also create multiple jurisdictions at once using the mass create
functionality for taxes that relate to specific Trading Community
Model geographic hierarchies. For example, create a county jurisdiction
for every county in the parent geography type of State and in the
parent geography name of California.

The tax within a tax jurisdiction can have different
rates for the parent and child geographies. For example, a city sales
tax rate can override a county rate for the same tax. In this case,
you can set up an override geography type for the city and apply a
precedence level to the city and county tax jurisdictions to indicate
which tax jurisdiction takes precedence.

In addition, in some cities a different city rate
applies to the incorporated area of the city, called the inner city.
In these cases, you can set up an inner city tax jurisdiction with
its own tax rate for the applicable customers and receivables tax.
Inner city tax jurisdictions are often based on postal code groupings.

Tax Statuses

Set up the tax statuses that you need for each tax
that you create for a combination of tax regime, tax, and configuration
owner. A tax status is the taxable nature of a product in the context
of a transaction and specific tax on the transaction. You define a
tax status to group one or more tax rates that are the same or similar
in nature.

For example, one tax can have separate tax statuses
for standard, zero, exemptions, and reduced rates. A zero rate tax
status may have multiple zero rates associated with it, such as Intra-EU,
zero-rated products, or zero-rated exports.

You define a tax status under a tax and a configuration
owner, and define all applicable tax rates and their effective periods
under the tax status. The tax status controls the defaulting of values
to its tax rates.

Tax Rates

Set up tax rates for your tax statuses and tax jurisdictions.
For tax statuses, set up a tax rate record for each applicable tax
rate that a tax status identifies. For tax jurisdictions, set up tax
rate records to identify the tax rate variations for a specific tax
within different tax jurisdictions. For example, a city sales tax
for a state or province may contain separate city tax jurisdictions,
each with a specific tax rate for the same tax.

You can also define tax recovery rates to claim full
or partial recovery of taxes paid.

You can define tax jurisdiction and tax status rates
as a percentage or as a value per unit of measure. For example, a
city may charge sales tax at a rate of 8 percent on most goods, but
may levy a duty tax with a special rate of 0.55 USD per US gallon
on fuel. Values per unit of measure are in the tax currency defined
for the tax.

You define tax rate codes and rate detail information
per rate period. Rate periods account for changes in tax rates over
time. A tax rate code can also identify a corresponding General Ledger
taxable journal entry.

Tax Recovery Rates

Set up tax recovery rate codes for the recovery types
identified on the taxes within a tax regime. A tax recovery rate code
identifies the percentage of recovery designated by the tax authority
for a specific transaction. In Canada, where more than one type of
recovery is possible for a given tax, you must set up the applicable
tax recovery rate codes for both the primary and secondary recovery
types that can apply to a transaction.

If you set the Allow tax recovery option for a tax within a tax regime, then you must set up at least
one recovery rate for the tax in order to make the tax available on
transactions. If the recovery rate can vary based on one or more factors,
including the parties, locations, product or product purpose, then
set up tax rules to determine the appropriate recovery rate to use
on specific transactions. At transaction time, Oracle Fusion Tax uses
the recovery rate derived from the recovery tax rules, or uses instead
the default recovery rate that you define, if no recovery rate rules
are defined or if no existing recovery rate rule applies to the transaction.

Minimum Tax
Configuration: Explained

Oracle Fusion Tax provides you with a single
interface for defining and maintaining the taxes that are applicable
in each country where you do business.

The minimum tax configuration path to meet the basic
tax requirements of transactions in a given regime is a 2-step configuration
process:

Define tax regime: This step includes
the tax regime definition as well as the subscription by the appropriate
legal entity or business unit.

The following prerequisite setups must be completed
for minimum tax configuration:

First parties, such as legal entities
and business units

Tax geographies and zones

Ledger and accounts

Currency codes and exchange rates

A legal entity tax profile is automatically created
when a legal entity is defined in the implementation. Similarly, a
business unit tax profile is automatically created when a business
unit is defined. For the business unit, you need to indicate whether
it will use the subscription of the legal entity instead of creating
its own.

In addition, there are seeded event class mappings
that describe the mapping between an application event class and the
corresponding tax event class. For example, the tax determination
process for a sales debit memo and sales invoice are essentially the
same. These two application event classes correspond to the same tax
event class namely, a sales transaction. Although you cannot update
the event class mappings, you can set up configuration specific event
class mappings.

Define Tax Regime

The first step includes the tax regime definition
and subscription by an appropriate legal entity or business unit.
While creating your tax regime, you can minimize configuration and
maintenance costs by creating content that can be shared by more than
one entity. For example, legal entities can subscribe to the shared
reference data instead of creating separate and repetitive data. If
the subscribing legal entities have some variations in their setup,
you can create override data to meet the specific exceptions that
are applicable to these organizations.

Use Oracle Fusion Tax features to enable only those
features that are relevant to taxes in the tax regime. Based on the
features you select, the subsequent setup pages and task lists for
the tax regime are rendered or hidden.

Define Transaction Taxes

The second step includes basic tax definition,
such as geographic information, controls and defaults, direct and
indirect tax rule defaults, and tax accounts.

The basic tax definition includes controls that you
can set to provide the override capability at transaction time. For
example, if you want to allow users to make manual updates on transaction
tax lines, select the Allow override for calculated
tax lines and the Allow entry
of manual tax lines options. However, if you want to enforce
automatic tax calculation on transaction tax lines, do not enable
these options.

Use the direct and indirect tax rule defaults to specify
the values that apply to the majority of your transactions. Create
tax rules to address the exceptions or variations to the defaults.
For example, for the Goods and Services Tax (GST) that applies to
the supply of most goods and services in Canada, set the Tax Applicability
direct tax rule default to Applicable. A luxury tax, on the other hand, is a tax on luxury goods or products
not considered essential. As it would not apply to most goods and
services, set the Tax Applicability direct tax rule default to Not Applicable, and create a tax rule to
make the tax applicable when the product in the transaction satisfies
the luxury requirement.

Assign your default tax accounts for the taxes in
a tax regime to post the tax amounts derived from your transactions.
The tax accounts you associate serve as default accounting information
for taxes, tax rates, tax jurisdictions, and tax recovery rates. The
tax accounts you define at the tax level, default to either the tax
rate accounts or tax jurisdiction accounts for the same tax and operating
unit, depending upon the tax accounts precedence level of the tax
regime. You can update these default tax accounts in the tax rate
or tax jurisdiction setup.

Minimum Tax
Configuration: Points to Consider

The minimum tax configuration setup must be
designed to handle the majority of tax requirements. As part of defining
transaction taxes, decide the direct and indirect tax rule defaults
for the tax and set up the associated tax accounts.

For complex tax requirements, create tax rules that
consider each tax requirement related to a transaction before making
the final tax calculation. During the execution of the tax determination
process, Oracle Fusion Tax evaluates, in order of priority, the tax
rules that are defined against the foundation tax configuration setup
and the details on the transactions. If the first rule is successfully
evaluated, the result associated with the rule is used. If not, the
next rule is evaluated until either a successful evaluation or default
value is found.

Setting Up Direct Tax Rule Defaults

The direct tax rule defaults are the default
values for the direct tax rule types, which include:

Place of supply

Tax applicability

Tax registration

Tax calculation formula

Taxable basis formula

Place of Supply

Use the Place of Supply direct tax rule default to
indicate the specific tax jurisdiction where the supply of goods or
services is deemed to have taken place. For example, in Canada, the
place of supply for GST is typically the ship-to location. To handle
the majority of Goods and Services Tax (GST) transactions, select Ship to as your default place of supply.

Note

The corresponding place of supply differs based on
the type of transaction. For example, a place of supply of Ship to corresponds to the location of your
first party legal entity for Payables transactions. For Receivables
transactions, Ship to corresponds
to the location of your customer site. For exceptions to this default,
create Determine Place of Supply rules.

Tax Applicability

Use the Tax Applicability direct tax rule default
to indicate whether the tax is typically applicable or not applicable
on transactions. For example, the GST in Canada is a tax that applies
to the supply of most property and services in Canada. When you create
the GST tax, select Applicable as your default tax applicability. For exceptions to this default,
create Determine Tax Applicability rules.

Tax Registration

Use the Tax Registration direct tax rule default to
determine the party whose tax registration status is considered for
an applicable tax on the transaction. For example, with a direct default
of bill-to party, Oracle Fusion Tax considers the tax registration
of the bill-to party and stamps their tax registration number onto
the transaction, along with the tax registration number of the first
party legal reporting unit. For exceptions to this default, create
Determine Tax Registration rules.

Tax Calculation Formula

Use the Tax Calculation Formula direct tax rule default
to select the formula that represents the typical calculation of tax
for a transaction line. A common formula, STANDARD_TC, is predefined, where the tax amount is equal
to the tax rate multiplied by the taxable basis. For exceptions to
this default, create Calculate Tax Amounts rules.

Taxable Basis Formula

Use the Taxable Basis Formula direct tax rule default
to select the formula that represents the amount on which the tax
rate is applied. The following common formulas are predefined:

STANDARD_TB: The taxable basis is equal to the line amount of the transaction
line.

STANDARD_QUANTITY: The taxable basis is equal to the quantity of the transaction line.

STANDARD_TB_DISCOUNT: The taxable basis is the line amount of the transaction line less
the cash discount.

For exceptions to this default, create Determine Taxable
Basis rules.

Setting Up Indirect Tax Rule Defaults

The indirect tax rule defaults for a tax include:

Tax jurisdiction

Tax status

Tax recovery rate

Tax rate

Tax Jurisdiction

Use the Tax Jurisdiction indirect tax rule default
to indicate the most common geographic area where a tax is levied
by a specific tax authority. For example, value-added tax (VAT) is
applicable to the supply of most goods and services in Portugal. For
the tax PT VAT, create the default tax jurisdiction as the country
of Portugal. To address specific tax regions such as Azores and Madeira,
which have lower VAT rates than Portugal, define jurisdiction rates
with different VAT rates.

Tax Status

Use the Tax Status indirect tax rule default to indicate
the taxable nature of the majority of your transactions. For example,
if your operations primarily include zero-rated transactions, select
the default tax status as Zero instead of Standard. This setting
facilitates tax determination when multiple zero rates are defined
to handle different reporting requirements for zero rate usage, such
as intra-EU, zero-rated products, or zero-rated exports. For exceptions
to this default, create Determine Tax Status rules.

Tax Recovery

Use the Tax Recovery rate indirect tax rule default
to indicate the recovery rate to apply to each recovery type for each
applicable tax on a purchase transaction. For example, in Canada,
both federal and provincial components of Harmonized Sales Tax (HST)
are 100% recoverable on goods bought for resale. In this case, with
two recovery types, you can set up two recovery rate defaults for
the HST tax. For exceptions to this default, such as when the recovery
rate determination is based on one or more transaction factors, create
Determine Recovery Rate rules.

Tax Rate

Use the Tax Rate indirect tax rule default to specify
the default tax rate that is applicable to the majority of your transactions
associated with this tax. You can create additional tax setup, such
as jurisdiction rates, or create tax rules to set alternate values
as required. For example, HST in Canada is applied at a 13% rate in
most provinces that have adopted HST, except for British Columbia
where the rate is 12% and Nova Scotia where the rate is 15%. To satisfy
this requirement a single rate of 13% can be defined with no jurisdiction
and then a 12% rate can be defined and associated with the British
Columbia jurisdiction (15% rate assigned to Nova Scotia). This minimizes
the setup required by creating an exception based setup. For exceptions
to this default, create Determine Tax Rate rules.

Setting Up Tax Accounts

Set up tax accounts at the tax level. The
application automatically copies the tax account combination to the
tax rates that you subsequently create for the tax for the same ledger
and optionally, the same business unit.

Define tax accounts at any of the following levels.
The defaulting option is only available at the tax level.

Tax

Tax jurisdiction

Tax rate

Tax recovery rate

Note

This is a one-time defaulting opportunity. Any subsequent
changes at the account level are not copied to the tax rate level
nor are they used during the AutoAccounting process. Changes at the
tax level do impact tax account defaulting when you create new tax
rates.

Setting up tax accounts comprise of specifying the
following:

Ledger and Business Unit: The ledger
and business unit for which you are creating the tax accounts.

Interim Tax: An account that records tax recovery or liability until the event
prescribed by the statute is complete. Generally, the payment of the
invoice is the event that triggers the generation of the tax recovery
or liability. You must set up an interim tax account for taxes and
tax rates that have a deferred recovery settlement. Once you set up
an interim tax account for this tax rate, you cannot change the recovery
settlement to Immediate.

Tax Recoverable
or Liability Account: An account that records tax recovery
amounts or relieves tax liability amounts. If you set up recovery
rates for a tax that you also intend to self-assess, then define a
tax recovery account for the associated recovery rates and a tax liability
account for the associated tax rates.

Finance Charge
Tax Liability: An account that records the tax liability
associated with finance charges that is used as a deduction against
overall tax liability.

Nonrecoverable
Tax Accounts: Accounts that record tax amounts on earned
and unearned discounts and adjustments that you cannot claim as a
deduction against tax liability.

Expense and
Revenue Accounts. Accounts that record net changes generated
by adjustments, earned and unearned discounts, and finance charges.
Receivables activities such as discounts and adjustments reduce the
receivable amount, and are therefore considered an expense.

Minimum Tax
Configuration: Worked Example

The following example illustrates the minimum
tax configuration setup to meet the basic requirements in Canada for
the Goods and Services Tax (GST). You set up a tax regime for both
GST and Harmonized Sales Tax (HST). One recovery type is created for
the fully recoverable status of the transaction.

In Canada, GST is a tax that applies to the supply
of most property and services in Canada. The provinces of British
Columbia, Ontario, New Brunswick, Nova Scotia, and Newfoundland and
Labrador, referred to as the participating provinces, combine their
provincial sales tax with GST to create HST. Generally, HST applies
to the same base of property and services as the GST. Every province
in Canada except Alberta has implemented either provincial sales tax
or the HST. In countries like Canada, some or all taxes on business
transactions for registered companies are recoverable taxes.

ABC Corporation is a business with a chain of bookstores
across Canada. It intends to implement the Oracle Fusion Tax solution
at its store in the province of Alberta. The GST rate of 5% is applicable
for sales in Alberta. Input Tax Credit is available for GST included
in purchases. ABC Corporation's primary ledger is CA Ledger, and the
business unit is CA Operations. The tax account 0001-1500-1100-1000
is reserved for the Tax Recoverable
or Liability account.

The tax implications in this scenario are:

Five percent (5%) GST is applicable
on the sale of goods in Alberta

Neither the HST nor provincial sales
tax applies in Alberta

Place of supply for GST tax is generally
based on the place of delivery or ship-to location.

To determine the GST tax in Alberta, perform the following
steps:

Define tax regime

Define transaction taxes

Create the direct tax rule defaults

Create the indirect tax rule defaults

Enable tax

Define Tax Regime

On the Create Tax Regime page, enter the tax regime
code for GST and HST in Canada.

Note

Use a coding convention to indicate both the country
and the type of tax that belongs to this regime. For example, CA GST
and HST.

Select the regime level to define the geographic
area of the tax treatment. The option selected must depict the need
for the tax regime. It should be set to Country for all federal taxes.

Specify Canada as the country for which this tax regime is being defined.

Enter a start date that will appear as a default
to all related tax setup within the tax regime.

Note

Consider your tax planning carefully before entering
the start date. This date must accommodate the oldest transaction
that you want to process within this tax regime. After you create
the tax regime, you can only update this date with an earlier date.
If you enter an end date, you cannot update this date after you save
the record.

Enter tax currency. Enter CAD, which is the three-letter ISO code for the Canadian
dollar.

Tax currency is the currency required by the tax authority.
Use the tax currency to pay the tax authority and to report on all
tax transactions.

Select the Allow cross regime
compounding option to set taxes within the tax regime
to be based on the calculation of, or compounded on, taxes in another
tax regime.

For example, in Quebec, the provincial sales tax is
applied to both the selling price and GST. Enter a value as the compounding
precedence to indicate the order of cross regime compounding. A lower
number indicates that the tax regime will be processed first. Allowing
gaps between numbers provide flexibility in the event that another
higher priority tax regime is introduced in the future.

On the Configuration Options tab, select the party
name that identifies either the legal entity or the business unit
or both for which you will define the configuration options.

For the Configuration of Taxes and Rules, select
the subscription that defines the configuration owner setup that will
be used for transactions of the specific legal entity and business
unit for this tax regime.

This selection also defines whether any shared content
can be overridden by the subscribing party to allow unique, separate
setup for certain tax content.

Enter the effective start date for this configuration
option. Enter a date range that is within the date range of both the
party tax profile and the tax regime.

Define Transaction Taxes

On the Create Tax page, enter the name of the tax
regime that you created in the Define Tax Regime step, such as CA
GST and HST.

Select the configuration owner for this tax. To
minimize configuration and maintenance costs, select Global Configuration Owner as the configuration
owner.

Enter the name of the tax you are defining, such
as CA GST.

Select Province as the geography type.

To minimize setup and maintenance costs, specify
the highest-level parent geography type (Country), unless the tax
is only applicable to a specific geography. Select Country from the list of values. For the
parent geography name, enter Canada.

Enter a value as the compounding precedence to reflect
the order of tax compounding. A lower number indicates that a tax
is processed first. Allowing gaps between numbers provide flexibility
in the event that another higher priority tax is introduced in the
future.

Assign Tax Accounts

Select CA Ledger as the primary ledger to use for
tax accounts and CA Operations as the business unit.

Enter 0001-1500-1100-1000 as the Tax Recoverable
or Liability account.

Create Direct Tax Rule Defaults

Navigate to the Tax Rule Defaults tab.

Select Ship to from the Place of Supply list of values, to specify the default.

Select Applicable from the Tax Applicability list
of values to specify the Tax Applicability default.

Select Ship-from party to specify the Tax Registration default.

Select STANDARD_TC as the Tax Calculation Formula default.

Select STANDARD_TB as the Taxable Basis Formula default.

Create Indirect Tax Rule Defaults

Select Tax Jurisdiction as your rule type and create the rule type default. In the Tax Jurisdiction Code field, enter a tax
jurisdiction code for the province of Alberta, such as CA Alberta.
Select Province as the geography
type. For the geography name, enter AB for Alberta. Set this tax jurisdiction
as your default, and specify your default start and end dates.

Select Tax Status as your rule type and create the rule type default. Enter a tax
status code for GST, such as CA GST STD. Set this tax status as your
default, and specify your default start and end dates.

Select Tax Recovery Rate as your rule type and create the rule type default. Enter a tax
recovery rate code for GST, such as CA GST STD REC RATE. For the recovery
type, select Standard. Enter a
rate percentage of 100 for a fully recoverable tax. Set this tax recovery
rate as your default, and specify your default start and end dates.

Select Tax Rate as your rule type and create the rule type default. In the Tax Status Code field, enter the name of
the tax status that you just created, CA GST STD. Enter a tax rate
code for GST, such as CA GST STD RATE. Enter a rate percentage of
5 for the current GST rate as of January 1, 2008, and specify your
default start and end dates.

Enable Tax

Click the Enable tax for
simulation option. This allows you to verify the tax configuration
using the Tax Simulator.

Once you have verified your tax configuration with
simulated transactions, click the Enable tax
for transactions option. This allows you to use this tax
in transaction processing.

Click Save and Close.

For ABC's transactions in the province of Alberta,
the following is determined by default:

GST tax is applicable and will be
calculated at a percentage rate of 5%.

100% of the GST can be recovered.

Associated
Taxes Setup for a Tax Regime: Explained

When you create a tax regime, you specify the options
and defaults available to the taxes associated with the tax regime.
You also enable the features that are applicable to the tax regime
and its taxes.

The options appearing in the Associated Taxes Setup
Information region on the Edit Tax Regime page are a result of the
features enabled and the options you selected at the tax level. These
options include:

Allow multiple
jurisdictions

Allow tax
recovery

Allow tax
exceptions

Allow tax
exemptions

The preceding options always appear as read-only check
boxes in the Associated Taxes Setup Information region. The option
appears as selected if you selected the option in one of the taxes
within this tax regime. If you did not select the option in one of
the taxes, then the option appears as not selected.

For example, suppose you have a California county
sales tax that applies to all counties, so you need a tax with multiple
jurisdictions. In this case, you must enable the Multiple Jurisdictions feature at the tax regime level
and then select the Allow multiple jurisdictions option at the tax level. When you access the Edit Tax Regime page,
Associated Taxes Setup Information region for this tax regime, the Allow multiple jurisdictions option appears
as selected.

Manage Controls and Defaults

Tax Regime
Controls and Defaults: Points to Consider

A tax regime associates a common set of default information,
regulations, fiscal classifications, and optionally, registrations,
to one or more taxes. Set up tax regimes in each country and geographical
region where you do business and where a separate tax applies.

The tax regime setup details include:

Designating the geography to which
taxes within a tax regime apply

Defining the controls and defaults
that apply to taxes and associated lower level information

Specifying configuration options
and service subscriptions

Designating the Geography

The common tax regime setup is one tax regime
per country per tax type, but you can also have tax regimes based
on parts of a country or more than one country. Select the regime
level as:

Country: The tax regime is applicable to a specific country.

Tax zone: The tax regime is applicable to parts of a country or more than
one country. Enter the tax geography type and tax geography name associate
with the group of countries or the tax zone that you want. The tax
geography type and tax geography name correspond to the tax zone type
and tax zone respectively.

If applicable, designate the tax regime as a parent
regime or indicate the parent regime name if the tax regime belongs
to a parent regime. Use a tax regime defined as a parent tax regime
to group other nonparent tax regimes for reporting purposes.

Defining Controls and Defaults

Set tax-level controls to enable the options
that you want to make available to the taxes in this tax regime. If
necessary, you can disable the options that you enable here for individual
taxes within the tax regime. Enter default values for the taxes in
this tax regime. You can update the default values at the tax level.
If you disable a controlled option at the tax regime level it is not
available as an option at the tax level.

The following table describes the defaults and controls
available at the tax regime level.

Defaults Region

Field

Description

Default Derived from

Default Appears on

Controls

Tax Currency

The default currency of the taxes within this tax
regime

None

Tax

None

Minimal Accountable Unit

The minimal unit of currency that is reported to the
tax authority, for example, 0.05 GBP indicates that 5 pence is the
minimal unit

None

Tax

None

Tax Precision

A one digit whole number to indicate the decimal place
for tax rounding

None

Tax

None

Tax Inclusion Method

A method that describes whether the line amount includes
tax or excludes tax

None

Tax

None

Conversion Rate Type

The specific exchange rate table that is used to convert
one currency into another, for example, the Association of British
Travel Agents exchange rate used in the travel industry

None

Tax

None

Rounding Rule

The rule that defines how rounding is performed on
a value, for example, up to the next highest value, down to the next
lower value, or to the nearest value

None

Tax

None

Allow tax rounding override

Allow the override of the rounding defined on the
tax registration records

None

Tax

None

Reporting Tax Authority

The default tax authority to whom the tax reports
are sent

None

Tax

Tax registration

None

Collecting Tax Authority

The default tax authority to whom the tax is remitted

None

Tax

Tax registration

None

Default Settlement Option

A lookup code to indicate whether an input tax is
recovered when an invoice is recorded or only when the invoice is
paid and whether an output tax is due for settlement when the invoice
is issued or only when the payment is received against it

None

Tax

None

Use legal registration number

Option that controls whether the tax registration
number is the same as the legal registration number of the party

None

Tax

None

General Controls Region

Field

Description

Default Derived from

Default Appears on

Controls

Allow override and entry of inclusive tax lines

Option that controls whether you can override and
enter inclusive or exclusive line amounts

None

Tax

None

Use tax reporting configuration

Option that controls whether the tax reporting details
are available on the first party tax registration record for this
tax regime

None

None

Controls whether you can enter tax reporting configuration
details on the tax registration for this tax regime for your first
parties

Compounding Level Controls Region

Field

Description

Default Derived from

Default Appears on

Controls

Allow cross regime compounding

Option that controls whether cross regime compounding
is needed for this tax regime

None

None

Controls whether this tax regime is compounded based
on the tax calculated from another tax regime

Compounding Precedence

Defines the order in which taxes within the compound
tax regimes need to be calculated. A tax within a tax regime with
a lower value is calculated first.

None

None

Controls the order in which taxes within tax regimes
are calculated

Important

Oracle Fusion Tax provides features at the tax regime
level to streamline your implementation by selecting the features
that are applicable to the tax regime in scope. You must enable the
features to use that functionality for the tax regime and related
taxes.

Specifying Configuration Options and Service Subscriptions

Set up configuration options to associate
tax regimes with the parties in your company that have a tax requirement
under these tax regimes. You can set up tax configuration options
when you create a tax regime or when you create a party tax profile
for a first party legal entity or business unit. Both tax regime and
party tax profile setup flows appear and maintain the same party and
tax regime association. Configuration options only apply to tax regimes
directly linked to taxes and not to tax regimes that are used to group
other tax regimes.

Oracle Fusion Tax lets you use the tax services of
external service providers for tax calculation of US Sales and Use
Tax on receivables transactions. The setup for provider services is
called a service subscription. A service subscription applies to the
transactions of one configuration option setup for a combination of
tax regime and legal entity or business unit.

Note

The level of detail of tax rounding definitions for
the taxes in the tax regime must equal or exceed the level of detail
of the service provider tax rounding definitions.

Inclusive Taxes: Explained

Calculating tax on a transaction as inclusive
of the line amount is generally a business decision. This decision
is based on the relationship between the transacting parties and the
items or taxes involved.

Taxes applicable on a transaction are made inclusive
of the item line amount either:

Manually

Automatically

Manual Approach

In the manual approach, you access the calculated
tax lines on a transaction and select the Inclusive option. This action includes the calculated
tax amount with the item value.

However, this option is controlled through two factors:

Privileges are assigned to the users
for accessing and editing the calculated tax lines.

Setup restrictions are applied to
edit the Inclusive option on the
calculated tax lines.

Automatic Approach

In the automatic approach, you can configure
the tax setup and calculate the tax on a transaction as inclusive
of the item line amount. Since this requirement is primarily driven
by the tax legislation and the business relationship between the transacting
parties, the option for configuring the inclusiveness is made available
on the tax and tax rate definition and the third party and legal reporting
unit tax profiles on the tax registration and general data tabs. The
tax determination process uses a hierarchy approach to evaluate the
defined setup and applies the inclusiveness option on the transaction.

In tax setup there are options to choose for applying
the inclusiveness on a transaction. They are:

Standard
noninclusive handling: This option calculates the taxes
as exclusive of the given transaction line amount.

Standard
inclusive handling: This option calculates the taxes as
inclusive of the given transaction line amount.

Special inclusive
handling: This option calculates the taxes as inclusive
of the given transaction line amount, but the calculation methodology
differs from the standard inclusive process.

The following table illustrates the calculation methodology
used with each of these options when a transaction line amount is
1000 USD and the applicable tax rate is 10% of the taxable basis amount,
for example, line amount:

Method

Calculation

Taxable Basis Amount

Tax Amount

Transaction Line Amount

Standard Noninclusive

1000 USD * 10/100

1000 USD

100 USD

1100 USD

Standard Inclusive

1000 USD * 10/110

909.09 USD

90.91 USD

1000 USD

Special Inclusive

1000 USD * 10/100

900 USD

100 USD

1000 USD

Tax Amount
Rounding: Explained

Taxes applicable on a transaction are generally
calculated as the taxable basis multiplied by the tax rate equals
the tax amount. This calculated amount can result in an odd value
or with a large number of decimal place. You can configure the tax
setup to adjust or round the tax calculation according to the specific
requirements of the transacting parties and tax authority or to the
accepted currency denominations.

Party tax profiles of the parties
or party sites as given in the rounding precedence of the configuration
owner tax options or in the derived registration party

Tax

Note

If you plan to use a third party service provider
then you must define tax rounding information that is at least as
detailed as the rounding information of the service provider.

Manage Configuration Options and Service Subscriptions

Configuration
Options: Explained

Set up configuration options to associate
tax regimes with the parties in your company that have a tax requirement
under these tax regimes.

There are two fundamentally different approaches to
tax configuration options namely:

Using tax configuration setup defined
within Oracle Fusion Tax.

Using an external tax service provider.

Using Tax Configuration Setup Defined Within Oracle
Fusion Tax

Use the tax configuration setup in Oracle Fusion Tax
to calculate, record, and account for transaction taxes on transaction
taxable transactions.

The following concepts control how this setup is managed,
used, and shared:

Tax configuration owner

Tax content subscription

Existing tax option

Tax Configuration Owner

The tax configuration owner is a business unit, legal
entity, or the global configuration owner that owns the data. The
global configuration owner is an abstract owner which is used to define
the owner of content that can be shared by any business units and
first party legal entities.

Identify a specific first party legal entity as a
parent first party organization to allow the configuration to be owned
by a specific first party and shared by other parties. You can then
share this setup with another first party legal entity or business
unit for their transactions. Use a parent first party organization
tax configuration to share among a group of first party organizations
but you still have the tax setup managed by a single first party organization.

In the case of global configuration owner, if you
are assigned the Create Tax Regime privilege, you have update rights
to all tax configuration data maintained by the global configuration
owner.

Tax Content Subscription

Use tax content subscriptions to define which configuration
owner's setup is used for transactions for a specific first party
legal entity or business unit for a specific tax regime. Also, use
tax content subscriptions to specify whether any shared content can
be overridden by the subscribing party to allow unique, separate setup
for certain tax content.

Party override is permitted for the following setup:

Tax

Tax status

Tax rate

Tax recovery rate

Tax rules

Do this
indirectly by adding higher priority rules specific to the subscribing
first party legal entity or business unit.

The content subscription options are:

Tax Content Subscription

Description

Common configuration

For tax processing, the tax determination process
uses the shared tax content defined and maintained by the global configuration
owner.

Party-specific configuration

The specified first party organization defines and
maintains its own tax content. For tax processing, the tax determination
process uses only the tax content owned by the specific first party
legal entity or business unit.

Common configuration with party overrides

This option is similar to the common configuration
in that it allows you to use tax content owned by the global configuration
owner. However, you can also maintain party-specific content which
is used in preference to the common configuration content. In the
absence of tax content owned by the specific first party organization,
the tax determination process uses the tax content owned by the global
configuration owner.

Parent first party organization with party overrides

This option is similar to the common configuration
with party override subscription except instead of the tax content
being owned by the global configuration owner it is owned by a specific
first party legal entity. You can override the specific first party
setup.

A similar concept is used to define where you use
tax exceptions for a specific tax configuration. The tax subscription
option available for product exceptions is dictated to some extent
by the main tax content subscription as follows:

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

Parent first party organization with party overrides

Party-specific configuration

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

Set up tax configuration options when you create a
tax regime or when you create a party tax profile for a first party
legal entity or business unit. Both setup flows display and maintain
the same party or regime definitions. Specify effective start and
end dates to identify which configuration should be used based on
the transaction date. You can enable the business unit so that Oracle
Fusion Tax automatically uses the configuration of the legal entity.
Once you set this option the application records the date it occurred
as the start date. This date is used and compared to the transaction
dates to identify if the application uses the legal entity subscription
in preference to the subscription of the business unit. The specific
first party legal entity that is used is defined by the legal entity
associated with the transaction.

Existing Tax Option

Copy a tax from an existing tax in the Manage Taxes
page to share tax registrations and tax jurisdictions while maintaining
two versions of the same tax, owned by two different tax configuration
owners each with their own tax statuses, tax rates, and tax rules.
For example, this is useful when you set up US sales and use tax that
requires a significant number of tax registrations and tax jurisdictions.

Using External Tax Service Provider

Oracle Fusion Tax lets you use the tax services of
external service providers for tax calculation of US Sales and Use
Tax on Receivables transactions. Oracle Fusion Tax provides transparent
integration between the external provide tax service and Oracle Fusion
Receivables.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

The setup for provider services is called a service
subscription. A service subscription applies to the transactions of
one configuration option setup for a combination of tax regime and
legal entity or business unit. Set up service subscriptions when you
create a tax regime or when you create a party tax profile for a first
party legal entity or business unit. Specify effective start and end
dates to identify which configuration should be used based on the
transaction date.

Content Subscriptions: Critical Choices

Choose which of the following tax content
subscription options to use to optimize your tax setup:

Whether to use service subscriptions
versus Oracle Fusion tax content.

What type of tax configuration options
to use.

When to change from business unit
to using tax configuration at the first party legal entity.

When to use create from an existing
tax option.

Using a Service Subscription Versus Oracle Fusion
Tax Content

Use the tax services of external service providers
where tax content is required for Receivables transactions for a significant
number of tax jurisdictions. You should not use a service provider
if their use is not needed to support US Sales and Use Tax regimes
or you need to create and maintain tax regimes outside of the Unites
States.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

Using Tax Configuration Options

If you decide not to use an external service
provider or you need to create tax content for tax regimes outside
the US then create and maintain your tax content in Oracle Fusion
Tax.

Once the decision is made to use Oracle Fusion Tax
you need to choose the level of tax configuration options. Sharing
tax content prevents the need for duplicate maintenance with its inefficiencies
and potential inconsistencies. Consider these scenarios and options:

Scenario

Option

You have a single central corporate tax center responsible
for maintenance of tax setup for all legal entities and business units.

Use the common configuration with party override option.
This allows a single tax setup to be created and maintained by the
corporate tax center.

You need to have strict control of who can maintain
the tax content.

Use the common configuration option. By not allowing
party override you restrict the access to the global configuration
owner to an authorized user who can maintain all of the tax content.

You have regional centers responsible for tax content.

Use the parent first party configuration with party
override option. This permits a regional setup with an actual or logical
parent legal entity to be created and maintained by each regional
center.

Even if there is no obvious need to share tax configuration,
for example, there is only a single first party legal entity operating
in each tax regime, significant business events such as takeovers
or mergers may mean that there could be a future need to share content.
In this case the original first party legal entity can act as the
configuration owner and then any subsequent first party can subscribe
to the first party's content using the parent first party configuration
with party override. Alternatively, set up the original tax content
using global configuration owner in preparation for any future business
event that requires tax content to be shared.

Changing from Business Unit to Using Tax Configuration
at the First Party Legal Entity

If you can standardize your tax setup across
all business units for a given legal entity then consider moving to
configuring and using tax setup at the legal entity level. Set the Use subscription of the legal entity option
on the business unit tax profile. Oracle Fusion Tax records the date
this occurs and compares it to the transaction date to identify if
the legal entity subscription should be used in preference to the
subscription to the business unit.

Using Create from an Existing Tax Option

Create a tax from an existing tax when you
have a need to share tax jurisdictions and tax registrations. You
maintain the tax jurisdictions and tax registrations once for taxes
with the same name within the same tax regime owned by different configuration
owners.

Tax Configuration
Options in the Tax Determination
Process: How They Are Used

At transaction time the owner of the transaction
derives the configuration options that are used. When you enter a
transaction for a given first party organization, the tax data applied
to that transaction is determined by the configurations defined for
the combination of that first party organization (business unit or
first party legal entity) and the tax regime derived from the addresses
or from the tax classification codes used on the transaction.

Settings That Affect the Application of Tax Data on Transactions

Use tax content subscriptions to define which configuration
owner's setup is used for transactions for a specific first party
legal entity or business unit for a specific tax regime. Also, use
tax content subscriptions to specify whether any shared content can
be overridden by the subscribing party to allow unique, separate setup
for certain tax content.

Tax content subscription options are:

Common configuration

Party-specific configuration

Common configuration with party overrides

Parent first party organization with
party overrides

How Tax Data Is Determined

Based on the defaults and tax rules you have defined,
tax data is applied to transactions as follows:

Configuration for Taxes and Rules Option

Tax Content Available

Common configuration

The tax determination process uses
only the tax content owned by the global configuration owner.

If you manually override tax information
on the transaction only tax content owned by the global configuration
owner is displayed in the list of valid values available.

Party-specific configuration

The tax determination process uses
only the tax content owned by the first party organization, business
unit or fist party legal entity, for whom the transaction is being
entered.

If you manually override tax information
on the transaction only tax content owned by the first party organization
is displayed in the list of valid values available.

Note

For the first party organization it can be the business
unit owning the tax content or the first party legal entity-owned
setup depending on the specific subscription being used.

Common configuration with party overrides

The tax determination process uses
any tax content owned by the first party for whom the transaction
is being entered. In the absence of tax content owned by that first
party organization, the tax determination process uses tax content
owned by the global configuration owner.

If you manually override tax information
on the transaction both the override tax content owned by the specific
first party and the tax content owned by the global configuration
owner that you have not overridden are displayed in the list of valid
values available.

Parent first party organization with party overrides

The tax determination process uses
any tax content owned by the first party for whom the transaction
is being entered. In the absence of tax content owned by the first
party organization, the tax determination process uses tax content
owned by the parent first party organization.

If you manually override tax information
on the transaction both the override tax content owned by the specific
first party and the tax content owned by the designated parent first
party organization that you have not overridden are displayed in the
list of valid values available.

If you are using product exceptions, those exceptions
are applied to the transactions as shown in the following table:

Configuration for Product Exceptions

Tax Exceptions Available

Common configuration

The tax determination process uses only the tax exceptions
defined and maintained by the global configuration owner.

Party-specific configuration

The tax determination process uses only the tax exceptions
owned by the specific first party organization

Setting Up
Tax Configuration Options: Worked Example

This example demonstrates how you set up the
appropriate tax configuration options for your company that has three
regional centers. These centers are responsible for tax setup and
maintenance among other corporate activities. Each of these regional
corporate centers is associated with a first party legal entity and
business unit.

Your company has their regional centers in:

North America (NAM), based in Redwood
City, California, US

Asian and Pacific (APAC), based in
Melbourne, Australia

Europe, Middle East, and Africa (EMEA),
based in London, UK

Each country has a single first party legal entity
with a single business unit, except for:

Countries which have the regional
corporate centers have a first party legal entity and business unit
for each corporate center.

Sales, marketing, and manufacturing
organization has a first party legal entity and business unit.

Create tax regimes for each country and the appropriate
tax configuration options.

Prerequisites

To create the appropriate tax configurations, you
must set up the following:

The legal entities for:

First Party Legal Entity

Country

EMEA LE

UK

GB LE

UK

FR LE

FR

DE LE

DE

APAC LE

AU

AU LE

AU

SI LE

SI

NZ LE

NZ

NAM LE

US

US LE

US

CA LE

CA

The sales, marketing, and manufacturing organization's
business unit uses the tax configuration of the legal entity.

FAQs for Define Tax Regimes

What's a service
subscription?

A service subscription is the setup for provider
services. It applies to the transactions of one configuration option
setup for a combination of tax regime and legal entity or business
unit. Oracle Fusion Tax lets you use the tax services of external
service providers for tax calculation of US Sales and Use Tax on Oracle
Fusion Receivables transactions.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

If you integrate with a tax service provider, these
actions are not required for Receivables transactions:

Tax service provider integration returns the calculated
tax lines to Oracle Fusion Tax. The tax lines for Receivables transactions
returned by tax service providers are stored in Oracle Fusion Tax
similar to the way tax lines calculated by the application itself
are stored.

Why are controls
and defaults important?

Throughout Oracle Fusion Tax care is taken
to minimize your effort in creating setup. One way of doing this is
the extensive use of defaulting so that you can enter your data once
and use the defaults that appear on the subordinate or child records
where applicable. For example, many values you enter on the tax regime
appear as defaults on each tax that is associated to that tax regime.
Generally, you can override the data where necessary if the defaulted
value is not correct.

Also, to ensure maximum flexibility, as well as to
ensure that the accuracy and integrity of the data and transactions
are maintained, Oracle Fusion Use Tax makes extensive use of data-driven
controls that enable and control how tax functionality works. For
example, you have the requirement to set up tax recovery for value-added tax (VAT) processing. Enable the Allow tax recovery option on the tax record so you can set up tax recovery rates for
this type of tax.

Define Product Tax Classifications

Define Product
Tax Classifications: Overview

Many tax regimes define rules for specific
products or types of products. This is often done to stimulate or
enhance trade in these specific products or to ensure that certain
products or product types are excluded from taxes where they are considered
staples of life. To support these requirements Oracle Fusion Tax has
extensive and powerful features to allow items to be classified. They
make extensive use of the Oracle Fusion Inventory catalog functionality.
If you do not implement Inventory you can use product category fiscal
classifications as an alternative classification in Oracle Fusion
Tax. Set up your product classifications in the Define Product Tax
Classifications activity.

For example, value-added tax (VAT) in
the UK exempts children clothing and normal foods from Great Britain's
(GB) VAT. It is also common that tax authorities vary the tax status
of product types depending on how they are planned to be used. For
example, a company purchases products that are subject to VAT. The
use of these items is not related to the company's sale of taxable
supplies. Therefore, the company cannot recover any VAT or can only
partially recover VAT on those purchases.

There has also been a recent trend to introduce antifraud
tax legislation for specific products so that they can be treated
in a different way to prevent fraud. For example, the GB Missing Trader
Intra Community antifraud legislation specifies that certain types
of business-to-business domestic supplies of certain, typically high
value, electronic products, such as mobile phones, computer equipment
and accessories are reversed charged even when there is a domestic
supply. For more information on GB Missing Trader Intra Community legislation
, see Her Majesty's Revenue and Customs (HMRC) - Business Brief 10/06.

The following product classifications for
tax purposes can be used within Oracle Fusion Tax and are summarized
in the following table:

Product Classification

Description

Product fiscal classification types and codes

Use this classification to group items for tax determination
and reporting purposes. This functionality uses the Oracle Fusion
Inventory catalog and item functionality and therefore, you can only
use it when this functionality is installed.

Product category
fiscal classification codes

Use this classification where Inventory is not installed.
It is used to classify transaction lines for tax determination and
reporting purposes.

Intended use fiscal
classifications

Use this functionality for tax determination and reporting
purposes. Use this classification where transaction lines need to
be classified based on the intended use of the product defined on
that item.

Tip

When available use the product fiscal classifications
in preference to product categories, because the application automatically
derives product fiscal classifications at transaction time based on
the items defined on the transaction line and their relationship to
the applicable catalog classification.

You can use product category fiscal classifications
in conjunction with product fiscal classifications. This combination
allows you to define two different determining factors at transaction
time.

Product Fiscal
Classifications: Explained

Use product fiscal classifications to classify items for tax determination and reporting. Define a
product group to use in tax product exemptions.

Define product fiscal classifications by associating
them with an Oracle Fusion Inventory catalog, which in turn is used
to group items using the standard Inventory functionality.

Set up the following options in the Inventory catalog:

Do not select the Enable hierarchies for categories option.

Select Items
at leaf level in the Catalog Content field.

Select the Allow multiple item category assignments option.

Select the Enable automatic assignment of categories option.

Select None in the Source Catalog field.

Do not select a value in the Sharing Control field.

During transaction time, when the association with
the catalog exists, the application automatically derives the default
product fiscal classification code based on the items used on the
transaction line. When no item is defined on the transaction line,
you can manually enter the product fiscal classification on the transaction
line during transaction time. Even the default product fiscal classification
code is derived during the transaction time, it can be overridden
if necessary. The overridden product fiscal classification code is
used in the tax determination process.

While creating the product fiscal classification,
use the number of levels to define the number of hierarchical levels
to link the items to. Also, specify the number of the level of classification
that is to be used in the tax rule setup. When creating the levels
within the product fiscal classification, define the start position
and number of characters for each level. During transaction time,
this ensures that all items with the same values in the start position
and the same number of characters are grouped into the same classification.

For example, set up the following code structure using
the Inventory catalog for the country, Luxemburg:

Code

Name

LUG01

Goods

LUG0100

Normal Rated Goods

LUG0101

Zero Rated Goods

LUG0102

Exempt Goods

LUG0103

Reduced Rate Goods

LUG0103-01

Reduced Rate 1 Goods

LUG0103-02

Reduced Rate 2 Goods

LUG0103-03

Reduced Rate 3 Goods

LUS01

Services

LUS0100

Normal Rated Services

LUS0101

Zero Rated Services

LUS0102

Exempt Services

LUS0103

Reduced Rate Services

LUS0103-01

Reduced Rate 1 Services

LUS0103-02

Reduced Rate 2 Services

LUS0103-03

Reduced Rate 3 Services

The previous code structure is represented
by three levels:

Level

Type Code

Type Name

Start Position

Number of Characters

1

LU Goods or Services

Luxemburg Goods or Service Level

1

5

2

LU Type of Goods or Services

Luxemburg Type of Goods or Service Level

1

7

3

LU Type of Reduced Rate

Luxemburg Type of Reduced Rate Goods or Service

1

10

Use the level two codes to link the items that need
to be classified using Inventory catalog.

Use the product fiscal classification pages to define
the tax regimes for which specific product fiscal classification are
to be used. Also, define if the product fiscal classification is available
to be used in the setup of tax product exceptions. To set up tax product
exceptions, enable the Use in Item Exceptions option. You can only set up one product fiscal classification for
a specific tax regime with the Use in Item
Exceptions option enabled.

Adjust the number of levels by increasing the number
of levels. It is not possible to decrease the number of levels once
the record is stored. In addition, you need to attach tax regimes
to every level that is used in the tax rules.

Tip

While setting up the product fiscal classification,
use different levels so that all of the necessary tax rules can be
defined at the highest level possible, thus minimizing the needed
number of tax rules.

In the previous example, the tax rule can use the
level 1 product fiscal classification to differentiate between goods
and services.

Product Fiscal Classifications in Tax Rules

The product fiscal classification tax determination
factors allow you to use product fiscal classification in tax rules.
A combination of determination factor class and determining factor
represents these determination factors.

Use Product inventory linked as the determining factor class and the product fiscal classification
type code or name as the determining factor. When creating the tax
rule, the value is the name or description associated with the relevant
level.

Product Fiscal Classifications at Transaction Time

When an item is defined on the transaction
line, the application automatically derives the default product fiscal
classification on the transaction line using the default primary Inventory
category set, that is, the Inventory catalog. The primary Inventory
category set is defined in the country defaults of the taxation country.
You can override this default during transaction time. The overridden
default is used in the tax determination process.

The product fiscal classification is stored in the
tax reporting ledger and is available for reporting.

Product Fiscal
Classifications: Example

Many tax regimes use product classification
to control tax applicability as well as the tax rate to be applied.
In value-added tax (VAT) regimes, the type of product being purchased
can drive recoverability.

This scenario illustrates how tax is determined and
reported for newspapers, books, and periodicals in Luxemburg.

Scenario

In Luxemburg, transactions involving newspapers, books,
and periodicals are invoiced with VAT at a reduced rating (currently
3%).

To determine tax:

Configure the Oracle Inventory catalog
functionality

Create a catalogue specifically for
Luxemburg VAT with the name LU VAT PRODUCT CLASSIFICATION. To create
the catalogue, create class categories including Reduced Rate 1 Goods.

This catalog is used for other classifications such
as Reduced Rate, Exempt Rate, and Standard Rate. Link all of the items
that are rated as Reduced Rate 1 Goods in Luxemburg to this class
category. In this case, link any relevant newspapers, books, and periodicals
to this class category.

Introduce a coding structure. An example is shown
in the following table:

Code

Name

LUG01

Goods

LUG0100

Normal Rated Goods

LUG0101

Zero Rated Goods

LUG0102

Exempt Goods

LUG0103

Reduced Rate Goods

LUG0103-01

Reduced Rate 1 Goods

LUG0103-02

Reduced Rate 2 Goods

LUG0103-03

Reduced Rate 3 Goods

LUS01

Services

LUS0100

Normal Rated Services

LUS0101

Zero Rated Services

LUS0102

Exempt Services

LUS0103

Reduced Rate Services

LUS0103-01

Reduced Rate 1 Services

LUS0103-02

Reduced Rate 2 Services

LUS0103-03

Reduced Rate 3 Services

Tip

While using the product fiscal classification, classify
the nonstandard items of your business as standard items. This can
be modeled as a default tax rule and therefore, does not require an
explicit classification or an explicit rule. Classify only exception
items and define specific tax rules for them. For a standard item,
none of the explicit rules are applicable and the default rate applies.

Tip

Do not add the explicit percentage to the naming or
coding convention used for product fiscal classifications. When the
rate changes, you change the rate period on the specific rate and
you do not have to change classification or associated tax rules.

Create a product fiscal classification
and link it with the catalog using the code LU VAT PRODUCT FISCAL
CLASSIFICATION. In this scenario, only a single level is needed, although
other levels may be needed to model nonstandard services or subclassifications
of product types for reporting purposes. The following table represents
this multiple level requirement:

Level

Type Code

Type Name

Start Position

Number of Characters

1

LU Goods or Services

Luxemburg Goods or Service Level

1

5

2

LU Type of Goods or Services

Luxemburg Type of Goods or Service Level

1

7

3

LU Type of Reduced Rate

Luxemburg Type of Reduced Rate Goods or Service

1

10

Create or amend the Luxemburg country
default record and set the primary inventory category set to LU VAT
PRODUCT FISCAL CLASSIFICATION.

Create the determining factor set
and condition set which refer to the product fiscal classification.

Use Product inventory linked as the determining factor class, the level to be defined in the
rule as the class qualifier, and the specific LU product fiscal classification
level as the determining factor as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Product inventory linked

LU Type of Reduced Rate

Create the condition set that refers
to the product category fiscal classification as shown in the following
table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Value

Product inventory linked

LU Type of Reduced Rate

Reduced Rate 1 Goods

Create the tax status rule based
on the determining factor set and condition set with zero tax rate
status as the result as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Value

Result

Product inventory linked

LU Type of Reduced Rate

Reduced Rate 1 Goods

LU Reduced Rate 1 Status

Product Category
Fiscal Classifications: Explained

Use product category
fiscal classifications to classify items for tax determination
and reporting purposes. Use product category fiscal classifications
when Oracle Fusion Inventory is not available. However, you can use
product category fiscal classifications in conjunction with product
fiscal classifications when Inventory is installed.

Product category fiscal classifications use the classification
functionality within Oracle Fusion Tax setup to directly define the
classification to use. This functionality allows a hierarchy of up
to five levels and uses the standard hierarchical features. It also
allows you to associate the classification codes with specific countries.

Note

Leave the country blank on the classification codes
if that code is applicable to multiple countries.

Use Product noninventory linked as the determining factor class, the level to be defined in the
tax rule as the class qualifier, and product category as the determining
factor.

For each of the fiscal classification codes created,
you can associate a tax reporting code, which is associated with the
fiscal classification code. This enables you to report on any transaction
line that uses the product category fiscal classification code to
which the reporting codes is associated. You can associate multiple
reporting codes with a single product category fiscal classification
code, which allows multiple reporting requirements to be modeled.

Tip

Use reporting codes related to the key elements of
the transaction in preference to reporting against the key elements.
This indirect reporting allows grouping of results when the same reporting
code is associated with multiple product category fiscal classification
codes. It also helps in minimizing ongoing maintenance.

Product Category Fiscal Classifications at Transaction
Time

The product category fiscal classification
has a single default that is set up in the relevant country defaults
and appears as the default on the transaction lines. However, during
transaction time, you can enter any applicable alternative product
category fiscal classification code on the transaction line.

This product category is stored in the tax reporting
ledger and is available for reporting.

Product Category
Fiscal Classifications: Example

Many tax regimes use product classification
to control tax applicability as well as the rate that is to be applied.

This scenario illustrates how tax is determined and
reported for newspapers, books, and periodicals in Luxemburg without
configuring Oracle Fusion Inventory.

Scenario

In Luxemburg, transactions involving newspapers, books,
and periodicals are invoiced with VAT at a reduced rating, currently
3 percent.

To model this specific requirement, use the product
category fiscal classification and follow these steps:

Configure product category
fiscal classification based on the following table:

Level

Code

Name

Country

Start Date

1

LUG01

Goods

Luxemburg

1-Jan-1970

2

LUG0100

Normal Rated Goods

Luxemburg

1-Jan-1970

2

LUG0101

Zero Rated Goods

Luxemburg

1-Jan-1970

2

LUG0102

Exempt Goods

Luxemburg

1-Jan-1970

2

LUG0103

Reduced Rate Goods

Luxemburg

1-Jan-1970

3

LUG0103-01

Reduced Rate 1 Goods

Luxemburg

1-Jan-1970

3

LUG0103-02

Reduced Rate 2 Goods

Luxemburg

1-Jan-1970

3

LUG0103-03

Reduced Rate 3 Goods

Luxemburg

1-Jan-1970

1

LUS01

Services

Luxemburg

1-Jan-1970

2

LUS0100

Normal Rated Services

Luxemburg

1-Jan-1970

2

LUS0101

Zero Rated Services

Luxemburg

1-Jan-1970

2

LUS0102

Exempt Services

Luxemburg

1-Jan-1970

2

LUS0103

Reduced Rate Services

Luxemburg

1-Jan-1970

3

LUS0103-01

Reduced Rate 1 Services

Luxemburg

1-Jan-1970

3

LUS0103-02

Reduced Rate 2 Services

Luxemburg

1-Jan-1970

3

LUS0103-03

Reduced Rate 3 Services

Luxemburg

1-Jan-1970

Tip

While using the product category fiscal classification,
only classify the nonstandard items of your business. Handle standard
items by using default tax rules. Thus, for a standard item, none
of the explicit tax rules are applicable and the default
rate applies.

The standard items are included in the table for
completeness only. Modeling these standard items using default tax
rules may be sufficient.

Tip

Do not add the explicit percentage to the naming or
coding convention used for product category fiscal classification.
When the rate changes, you change the rate period on the specific
rate and you do not have to change classifications or associated tax
rules.

Create the determining factor set
which refers to this product category fiscal classification.

Use Product noninventory linked as the determining factor class, the level to be defined in the
rule as the class qualifier, and the product category as the determining
factor as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Product noninventory linked

Level 3

Product Category

Create the condition set that refers
to this product category fiscal classification as shown in the following
table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Value

Product noninventory linked

Level 3

Product Category

Reduced Rate 1 Goods

Create the tax status rule based
on the determining factor set and condition set with zero tax rate
status as the result as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor Name

Value

Result

Product noninventory linked

Level 3

Product Category

Reduced Rate 1 Goods

LU Reduced Rate 1 Status

Intended Use
Fiscal Classifications: Explained

Use intended use fiscal
classifications to classify items for tax determination and
reporting.

Intended use fiscal classifications can be defined
in two ways. When you use the intended use fiscal classification
interface for the first time, you are presented with an option to
choose whether the classification is defined by:

Linking it to an Oracle Fusion Inventory
catalog, which in turn can be used to group items. Items
can be grouped using the standard Inventory functionality. To do this,
select the Inventory Based option.

Using the hierarchical classification
functionality in Oracle Fusion Tax to define the classification to
be used. To do this, select Noninventory based in the Intended Use Classification field.

During transaction time, the application derives the
default intended use fiscal classification. Override the default value
if necessary. The overridden intended use fiscal classification code
is used to determine tax.

Inventory-Based Intended Use Fiscal Classifications

Use inventory-based intended use fiscal classifications
to define a classification that uses the Inventory catalog functionality.

During transaction time, when an item is used on the
transaction line, the application looks for a default intended use
fiscal classification and uses that on the transaction line. At transaction
time you can override the default intended use fiscal classification.
The overridden value is used for tax determination and reporting.
However, unlike product fiscal classification, you define only one
level for the intended use fiscal classification.

Set up the following options in the Inventory catalog:

Do not select the Enable hierarchies for categories option.

Select Items
at leaf level in the Catalog Content field.

Select the Allow multiple item category assignments option.

Select the Enable automatic assignment of categories option.

Select None in the Source Catalog field.

Do not select a value in the Sharing Control field.

Tip

Care should be taken when defining intended use fiscal
classifications based on catalogs as the application may automatically
create a default. This default is not easily visible on the transaction
user interface and therefore, you may not be aware that a default
has been derived and that you may need to change it.

Noninventory-Based Intended Use Fiscal Classifications

Use noninventory-based intended use fiscal
classifications to define classifications that use the functionality
within Oracle Fusion Tax. It allows you to define single level classification
codes.

Optionally, link each classification code to a country
code. This country code is used to restrict the list of noninventory-based
intended use fiscal classifications when you enter them in tax rules
and during transaction time.

By matching this country code to the tax regime country
the list of noninventory-based intended use fiscal classification
codes is restricted. Similarly, the taxation country is used to restrict
the list of intended use fiscal classification codes displayed at
transaction time. In both cases, the list contains the fiscal classification
codes with the matching country or where the country field is blank.

Note

If the code is applicable to multiple countries, leave
the country field blank.

Intended Use Fiscal Classifications in Tax Rules

The intended use fiscal classification tax
determination factors allow you to use the intended use fiscal classification
in tax rules. A combination of determination factor class and determining
factor represents these determination factors.

Use the Transaction input
factor as the determining factor class and Intended use as the determining factor.

Inventory-Based Intended Use Fiscal Classifications
at Transaction Time

During transaction time, when an item is defined
on the transaction line, the application automatically derives the
default intended use fiscal classification. Override this default
intended use fiscal classification at the time of transaction, if
necessary.

The intended use fiscal classification is stored in
the tax reporting ledger and is available for reporting.

Inventory-Based
Intended Use Fiscal Classifications: Example

In value-added tax (VAT) regimes,
most recoverability is driven by the usage of the purchased product.

This scenario illustrates how the usage of the purchased
product can be modeled using intended use fiscal
classifications. Consider that the Oracle Fusion Inventory
functionality is available and therefore, use it to define the intended
use fiscal classification codes.

Scenario

In the United Kingdom the VAT received from purchase
of goods associated with VAT exempt sales cannot be recovered that
is, the recovery rate is zero percent (0%).

To calculate recoverability:

Configure Oracle Fusion Inventory
catalog.

Create a catalog with a name of INTENDED
USE for the intended use fiscal classification.

Create class categories such as,
Linked to Exempt Sales. The catalog is used for other classifications
such as business entertainment and company cars. Link all items that
are associated with exempt sales to the class category as follows:

Code

Name

EXEMPT SALES

Linked to Exempt Sales

BUS ENTERTAINMENT

Business Entertainment

COMPANY CARS

Company Cars

Tip

While using the intended use fiscal classification,
classify the nonstandard items of your business as standard items.
This can be modeled as a default tax rule and therefore, does not
require an explicit classification or an explicit rule. Classify only
exception items and define specific tax rules for them. For a standard
item, none of the explicit rules are applicable and the default rate
applies.

Create an Inventory-based intended
use fiscal classification and link it to the catalog using the code
INTENDED USE.

Create the determining factor set
and condition set that refer to the intended use fiscal classification.

Create a tax recovery rule based
on the determining factor set and the condition set with zero recovery
rate as the result.

Define Basic Catalogs

Catalogs: How They Work Together

A catalog is a collection of categories that
you use to classify items. You can organize the categories into a
hierarchy the represents a taxonomy. You create new categories only
in the context of a catalog. You can add existing categories to one
or more catalogs, either from another catalog or as shared categories
from a source catalog.

You can set the Catalog
Content value to Items at all
levels which allows items to be assigned to any level
within the category hierarchy, not only to the leaf levels.

The following diagram shows the relationships of the
catalog components.

Catalog

A catalog is a collection of categories that are organized
to define a classification of items. The top most level of a catalog
is the catalog root. All categories for the first level in the category
hierarchy are associated with the catalog root through the catalog
category association component.

Category

A category is a component of a catalog that represents
a portion of the classification defined by the categories and category
hierarchy in the catalog. You can associate a category to a catalog
through the catalog category association. Both the shared category
and the native category are associated thorough the catalog category
association.

Catalog Category Association

Catalog category association represents the relationship
between a catalog and a category, or a parent category and a child
category. Each catalog category association represents one relationship
between the catalog and a category or one relationship between a parent
category and a child category.

Item Category Assignment

Item category assignment represents the assignment
of the item to a category in a catalog. Each item category assignment
represents the relationship between a category and an item.

Item

An item represents objects such as a product, service
or template. An item is assigned through the item category assignment
component.

Attachment or Image

Information is associated to the catalog and/or category,
or both, through the attachment framework. Multiple attachments are
supported but you can associate only a single attachment or attachment
type image with a catalog or category.

Formatting
Catalogs: Explained

The format of a catalog is defined at the
time the catalog is created and controls the behavior of the catalog
at runtime.

When you format a catalog the layout controls three
main areas and includes the following tasks, some fields are required,
and others are optional.

Catalog configuration

Date enablement

Category sharing

Catalog Configuration

You can configure the catalog, and this affects how
the content behaves. The catalog configuration contains a set of attributes
that define the catalog configuration. These attributes interact to
define the runtime behavior of the catalog.

The configuration functions are:

Catalog code: A unique identifier
that is used.

Catalog structure: The key flexfield
structure used to define the catalog.

Controlled at: Controls how items
are assigned to categories and has two values. The first value is
master level, which enables the automatic assignment of items to all
child organizations associated with the master organization, if the
current context is a master organization. The second value is organization
level, which assigns the item only to the organization in the current
context.

Default category: Applies any time
a new item is created. The newly created item is assigned to this
category within the catalog automatically. The automatic assigned
is controlled by the functional area.

Catalog content: Controls what content
can be added to the catalog and where the content can be added. This
attribute has three values:

The Item at leaf levels allows items
to be added only to the bottom level categories in the hierarchy.

The Items at all levels allows items
to be assigned to any category in the hierarchy regardless of level.

Categories only allows categories
to be added only to the catalog.

Allow multiple item category assignment:
When this option is selected, you can assign an item to one or more
categories in the catalog. The default is deselected, which means
that each item can be assigned to only one category in the catalog.

Enable hierarchies for categories:
When this option is selected, you can create a hierarchy for the catalog.
The default is deselected, which means that the catalog cannot have
a hierarchy and categories are associated with the catalog root.

Enable automatic assignment of categories:
When this option is selected, the catalog is built by automatically
associating all categories, based on matching the catalog structure
value to the category structure value.

Catalog Date Enablement

The date enablement function controls when the catalog
is in an active state or inactive state by using the start date and
end date attributes.

Category Sharing

The category sharing function enables sharing by reference
to categories from a designated source catalog.

The sharing function has these attributes:

Source catalog: A catalog that does
not have sharing enabled from which categories, category hierarchies,
and assigned items can be added to the catalog.

Sharing content: Controls what content
can be added from the source catalog. This attribute has three values:

Categories only: Only categories
without assigned items can be shared.

Items only: Only categories with
assigned items can be shared.

Items and categories: All categories
can be shared.

Catalog Details: Explained

You can change a default category so that
you can use it for item creation, or modify the inactive date so that
the category is no longer used as you update a catalog. You can correct
mistakes or reclassify the category due to shifting relationships
within the category hierarchy.

You can view and edit a catalog on the Edit Catalog
page when you have editing rights. For users that do not have rights
to edit, the page is in read only mode.

The following aspects are important regarding managing
and editing catalog details:

Catalog header region

Catalog detail tab

Category hierarchy tab

Catalog Header Region

This region contains the catalog name and description,
the selection of the default category and the start and end date for
the catalog.

Catalog Detail Tab

The Detail tab contains:

The configuration attributes for
the catalog that controls the runtime behavior for the catalog.

The sharing attributes for the catalog
which controls the source catalog that will be used for sharing from
and what content can be shared.

The additional information which
contains the descriptive flexfields defined for the catalog.

Category Hierarchy Tab

This contains the category hierarchy region in which
the category hierarchy can be created and maintained. In addition,
items can be assigned, and the usage of the category in other catalog
can be viewed, and the attributes for the category and catalog category
association can be edited.

Automatic Assignment
Catalogs: Explained

The automatic assignment catalog feature enables you to reduce the cost of creating and maintaining
a catalog. It is a simple way to create a nonhierarchical catalog
because you do not have to add categories manually to the catalog.

All categories that have the same category structure
value as the catalog are automatically assigned and associated to
the catalog when you create a catalog category association for each
category. Note that if you create a category in another catalog with
the same structure value as the automatic assignment catalog, the
category is added to your catalog. The categories displayed for auto
assignment catalogs are refreshed only at startup and after you save.

Automatic Assignments

The automatic assignment feature is enabled during
catalog creation when you select the Enable
automatic assignment of category check box. When you
open a new catalog, any categories that have the same category structure
value as the catalog structure value for the catalog are automatically
assigned to the catalog.

For example, Purchasing may maintain a master catalog
containing all categories that represent commodities. Each commodity
team can create categories for their commodity in their own catalog.

The master catalog for Purchasing
is named Purchasing and is configured during creation to support the
automatic assignment of categories.

The Electronic commodity team creates
a catalog named Electronics and proceeds to create categories that
represent the classification of their commodity. The Electronic commodity
team creates the categories televisions, computers, and home theaters.

The other commodity teams create
and maintain separate catalogs.

Because you enabled automatic assignments
for the Purchasing catalog, any categories created by the commodity
teams are added to the catalog automatically. The Purchasing managers
can view the collection of all commodities represented as categories
in the Purchasing catalog.

Manage Catalogs

Editing Catalogs: Explained

The Edit Catalog dialog is a shared page that
has two modes, view and update. The view mode displays the selected
catalog in a read-only file. The update mode displays the selected
catalog in an editable file. You must have edit catalog privileges
to access the catalog in update mode. You can edit only an active
or future-dated catalog.

The following fields are editable in the catalog:

Catalog Name

Description

Start Date

End Date

Default Category

Allow multiple
item category assignment

Addition
Information

Category
Hierarchy

Category
Details

Items assigned
to category

Default Category

You can edit this field to select another
category as the default category for item creation. You cannot remove
the default category if the catalog is assigned to a functional area
that requires a default category to be specified.

Allow Multiple Item Category Assignment

This check box is editable only until you
assign an item to a category in the catalog.

Addition Information

You can edit the values of the descriptive
flexfields attributes.

After you make changes, clicking the Save button saves the changes to the database
but will does not close the Edit Catalog page. Clicking the Save and Close button saves the changes to
the database and closes the Edit Catalog page.

Categories
and Catalog Relationships: Explained

Catalogs are used to organize and classify
collections of items by associating categories to the catalog. The
categories are organized to form a taxonomy and items are assigned
to the categories. When a category is associated with the catalog
a catalog category association is created which specifies the relationship
of the association. The catalog category association may also represent
the relationship between two categories, for example a relationship
between a parent category and a child category.

The following aspect is important regarding catalog
category association:

Date enablement attribute value

Catalog Category Association

The catalog category association is date enabled
providing the control of when the catalog category association is
active in the catalog and when the catalog category association is
inactive. The catalog category association has two attributes to
support date enablement; the start date and the end date. The start
date is value is the first day that the catalog category association
is available or active for use and the end date is the last day the
catalog category association can be used, after this date the catalog
category association is inactive. The date enablement attribute values
are also used to control the visibility of content and the behavior
of the category in the catalog. If a category association is inactive
or end dated, having the value of the end date attribute past the
current date, then the items cannot be assigned to the category.

A catalog category association will be set to inactive
state when the category referenced by the catalog category association
is set to an inactive state automatically, but the display will not
be refreshed automatically.

Date Enablement
for Catalogs and Categories: Explained

The catalog, categories, and catalog category
association use date enablement to determine if the object specified
is active or inactive based on the start date and end date. The following
are date enablement definitions:

Active An object is active when the current date is later than or equal
to the value of the start date, but earlier than or equal to value
of the end date.

Inactive An object is inactive when the current date is later than the value
of the end date.

Future dated An object is future dated when the current date is earlier than
the value of the start date.

You set the date enablement attributes are used to
determine when a catalog, category, or catalog category association
is used or visible.

On the Manage Catalog page, a table
filter determines which catalogs appear. The default value for the
choice list is Active, indicating
that only active catalogs will be displayed. You can select the value All to view both active and inactive catalogs.

On the Edit Catalog page, on the
category hierarchy tab, two table filters determine what categories
and catalog category associations appear. The default values for the
two choice lists are Active, indicating
that only active categories and active catalog category associations
will be displayed. You can select the value All to view both active and inactive categories and catalog
categories associations.

Other applications also use the date
enablement attributes to filter information retrieved through application
programming interfaces or services for catalogs.

The following illustration provides the date enablement
attributes for these objects. The catalog, category, or the catalog
category association has an internal state that is active or inactive.

The following aspects are important regarding date
enablement for catalogs and categories:

Start date

End date

Catalog and category objects

Catalog category association

Catalog and category rules

Start Date

The start date is defined as the first date
that the object can be active. The start date can be future dated
by setting the value to a date later than the current date. The start
date value defaults to the system date if no date is entered during
catalog or category creation.

End Date

The end date is defined as the last date that
the object can be active. The object is end dated one second after
the date specified by the value of End Date, that is the next day at 12:00:01 a.m. You cannot set the end date
in the past. Also, you can change the end date from a condition when
the object is ended to a new end date greater than or equal to the
system date, causing the object to go from inactive to active. The
end date value is optional during catalog or category creation.

Catalog and Category Objects

The start and end dates have been added for
the catalog and catalog category association. The inactive date for
categories has been renamed as the end date and the start date has
been added.

Catalog Category Association

The catalog category association is used to
specify the parent and child relationships between catalogs and categories
and for category to category relationships. The catalog category association
date enablement is independent of the category data enablement, except
for the case where the category is end dated; the association is ended
automatically as well. The catalog category association dates represents
the state of the category for the catalog in which the category is
associated.

Catalog and Category Rules

When a catalog is inactive the following rules apply:

All operations for the catalog are
disabled; the catalog is not editable.

The catalog cannot be used in other
processes.

The catalog can be viewed only if
you set filters on the Manage Catalog page to a value of All, enabling you to view active and inactive
catalogs.

When a category is inactive the following rules apply:

All operations for the category are
disabled; the category is not editable.

The category cannot be added to other
catalogs.

The category can be viewed only if
you set the filters on the Edit Catalog page to a value of All, enabling you to view active and inactive
catalogs.

The system sets the catalog category
association for the inactive category to inactive.

When a catalog category association is inactive the
following rules apply:

The category may be inactive or active;
if the category is active it can be edited.

The catalog category associations
and related category can be viewed only if you set the association
filter on the Edit Catalog page to a value of All, enabling you to view active and inactive catalogs.

When a catalog is future dated the following rules
apply:

All the operations of the catalog
are enabled and the catalog is editable.

The catalog can be used in other
processes, if allowed.

The catalog can be viewed only if
the you set the filters on the Manage Catalog page to value of All.

Catalog Hierarchies: How They Fit Together

You use catalogs to organize and classify
collections of items by associating categories with the catalog. You
organize the categories to form a taxonomy and assign items to the
categories. When you associate a category with the catalog, a catalog
category association is created which specifies the relationship of
the association. The catalog category association may also represent
the relationship between two categories, for example, a relationship
between a parent category and a child category.

The following diagram shows the relationships of the
category hierarchy components:

Components

The components of a category hierarchy are:

Catalog root: The topmost node in
category hierarchy that represents the object called catalog.

Category: The catalog component that
is used to represent the classification structure.

Catalog category association: The
line in the diagram represents the relationship between a catalog
and category or between a parent category and child category.

Item category assignment: The dotted
line in the dialog represents the relationship between a category
and an item.

Reference category: The category
C5 in this diagram is shared as a reference category from a source
catalog.

Leaf level category: The lowest or
bottom-level category in a category hierarchy. You can assign items
to all levels in a category hierarchy if you configure the catalog
to support this.

Browsing category: The category
C2 in this diagram is a browsing category. Browsing categories are
categories that you add to the category hierarchy for the purpose
of classification and do not have items assigned to them.

The category hierarchy does not have a limit on how
many levels can be represented. The category hierarchy can have multiple
hierarchies within a single category hierarchy.

Editing Categories: Explained

Categories can be edited only from within
an Edit Catalog page, the category hierarchy tab. The category can
be edited by selecting row for the category in the category hierarchy
table and editing the category information in the category detail
panel. The category can only be edited if the category is active and
the catalog is active or future dated.

The category information can be edited in both the
details and items tabs.

Details and Items Tabs

The following fields are editable in the category:

Category
name

Description

Attachments

Category
start date

Category
end date

Items assigned
to category

After changes are made the Save button will save the changes to the database but
will not close the Edit Catalog page. The Save and Close button will save the changes to the database
and close the Edit Catalog page.

Editing Catalog
Category Associations: Explained

The catalog category association can be edited
only within the Edit Catalog page, in the category hierarchy tab.
The catalog category association start date and end date attributes
can be edited in the details region.

Category Catalog Associations

You select the category in the category hierarchy
table for the catalog category association that is being edited, the
category details are displayed in the right hand panel. The association
start date and association end date are the only editable fields.

After completing the edits, click on the Save button to save your changes to the database,
the Edit Catalog page will not close. The Save and Close button will save the changes to the database
and close the Edit Catalog page.

Editing Category
Details: Explained

You can update category details when you select
the row with the category in the category hierarchy table, the category
details are displayed in the right hand panel in the user interface
in an edit mode for all native categories. The category detail region
contains information about the category that is associated to the
catalog. It also contains the association start and end dates.

You can view and edit a catalog on the category details
tab when you have editing rights. For users that do not have rights
to edit, the page is in read only mode.

The following aspects are important regarding managing
and editing category details:

Category details tab

Items tab

Where used tab

Category Details Tab

The details tab contains information about the category
that has been associated to the catalog. This information appears
in all catalogs, since a category can be associated to one or more
catalogs. The details tab contains the category configuration, category
date enablement, association date enablement, and the additional attributes
for the category.

The details tab contains attributes that define a
category. Unstructured information is added through attachments.
Images are added to a category and are displayed in the category details
tab.

Items Tab

The item assignments are specific to the catalog where
the category is associated.

Where Used Tab

The Where used tab contains a list of catalogs that
the category is associated with.

Creating Categories: Explained

You can create categories only in the context
of a catalog, on the Edit Catalog page, Category hierarchy tab. When
you select the Create icon in
the category hierarchy table, it launches the Create Category dialog.

Consider the following important aspects when creating
categories for catalogs:

Create category region

Configuration region

Date enablement region

Additional information region

Create Category Region

Enter a name and a meaningful description
of the category in the create category region. Optionally, you can
add an image and an attachment to this category.

Configuration Region

The key flexfield is determined during creation
based on the catalog structure of the catalog. Enter the key flexfield
segment values for the category. The number of key flexfield segment
values depends on how you define the key flexfield at setup time.
The category structure is the key flexfield structure instance that
you create as part of the setup. When you define the key flexfield
structure instance, you define the segments for the structure instance.
For example, the family group and class group are segments. The segments
appear in the Create Category dialog based on the key flexfield structure
instance that you select.

The default value of the category content selection
value is Items and Categories,
but you can change the value. The values in the category content choice
list vary based on the catalog content value.

The category content attribute value controls the
content that you can add to this category.

Items Only: Select to add only items to the category

Categories
Only: Select to add only categories to the category

Items and
Categories: Select to add both items and categories to
the category

Date Enablement Region

Date enablement determines if an object is
active or inactive based on the start date and end date. When categories
are created, the default start date value is the current date. You
can move the category start date beyond the current date to a future
date within the category. The end date value is optional.

Additional Information Region

The additional information region
contains all descriptive flexfield attributes that you set up for
categories. You can edit the values of the descriptive flexfield attributes
at the time of category creation.

After you complete the required fields for the catalog,
clicking OK creates the category
in the database, adds the category to the point of selection in the
category hierarchy, and closes the dialog.

Moving Categories: Explained

You use the move category function in the
category tree table region of the Edit Catalog page. This is a table
row action. The dialog is launched when you select an active or future
dated category within the catalog and select this action. The move
category function is disabled when the Enable
hierarchies for categories check box is not checked or
left unchecked.

Consider the following important aspects when moving
categories within catalogs:

Indentifying the new parent

Indentifying the New Parent

The dialog provides the current category parent
and allows you to pick a new category parent. Only the legal category
parents are displayed in the choice list.

The category list within the New Parent choice list is filtered by based on a set
of rules:

The new parent category must be an
active or future dated category; the end date value of the category
must be later than the current system date.

The value of the category content
for the new parent category must allow the selected category to be
added; the legal values are items and categories and categories only.

A selected category associated with
the catalog at a level below the categories at the root categories
can be moved to the root of the catalog.

The new parent category catalog category
association must be active; the end date value of the catalog category
association must be later than the current system date.

Importing Category
Hierarchies: Explained

Category hierarchy can be created and maintained
through a spreadsheet interface reducing the amount of time to create
and maintain catalogs. Existing catalog content can be exported and
the content used in other catalogs for catalog category hierarchies.

The following aspects are important regarding category
hierarchy import used in catalogs:

Spreadsheet interface

Export category hierarchy

Spreadsheet Interface

You can manage the catalog category hierarchy to use
the spreadsheet interface that is available in the Edit Catalog page
by using the Export Hierarchy button
to download existing catalog content, modify this content in a spreadsheet,
and upload the content back into the Product Information Management
application.

Export Category Hierarchy

You use export category hierarchy for example, when
you need to provide the category hierarchy to a partner. Your partner
has the capability to import the catalog file using an Excel spreadsheet.

You can export the category hierarchy from our catalog
and it can be used by partners. If your partner has the Oracle Product
Information Management solution, they can directly import the category
hierarchy into their catalog.

Managing Attachments
to a Catalog or Category: Explained

Catalogs and categories support attachments
and use a common component for managing attachment content. You can
add attachments on both the Create Catalog and Edit Catalog pages.

The attachment component displays a green plus sign
icon indicating that no attachments are available for the object.
The Attachment dialog appears when you click the green plus sign icon.
You define the attachment by selecting the attachment type, file name
or Uniform Resource Locator (URL), title, description, and by indicating
whether the attachment can be shared with other objects. Once you
define the attachments and click the OK button, that attachment title appears in the attachment component
region of the page along with a red X icon that you can click to delete
the attachment.

The attachment file types are:

File

Repository File/Folder

Text

URL

File

You must provide a title for the file and create a
description for the attachment. You select a file to upload from your
desktop.

Repository File/Folder

You click the Browse button to attach a repository file/folder from the document repository
to a catalog. The attachment repository contains existing attachments
and is organized as a set of folders. The Browse button launches the Attachment Repository dialog
to enable you to select an attachment. You must provide a title for
the repository file/folder and create a description for the attachment.

Text

Enter the text string in the field that you want to
appear as an attachment. You must provide a title for the text and
create a description for the text attachment.

URL

Enter the URL address to a web page that you want
to attach to the catalog. You must provide a title for the URL attachment
and create a description for it.

The Share check
box alerts users that you added an attachment and the date that you
performed the task.

Assigning Items
to Categories: Explained

You can assign items to categories on the
Edit Catalog page, category hierarchy tab, on the category detail
item tab. You can assign items only to active categories and categories
where the Category Content field
value is Items and Categories or Items Only. In addition,
you can configure catalogs to control item assignment to categories
within the catalog by selecting the Allow
multiple item category assignment check box, which allows
items to be added to all levels of the category hierarchy.

You select items from a choice list and add them to
the category. The choice list is filtered based on a set of rules:

Item data level security: Displays
only the items that the user has permission to view and assign.

Organization context: Based on the
organization context that is controlled by a choice list in the item
table header, only the items assigned to organizations are displayed.

Controlling Item Assignment

You also control item assignment by selecting
the value of the Controlled at check box. If you select the Master Level value and the organization context is a master organization, the
items are automatically assigned to all child organizations that are
associated with the master organization.

Publishing
Catalogs: Explained

Other applications can use catalog data if
you export the catalog content. For example, you may want to export
catalog content to use as a monthly report of all items assigned to
a specific catalog. You can use the default publish template provided
in hyper text markup language (HTML). You can specify the content
and layout of the catalog information. When the catalog is published, you select the
format and initiate the creation of the content in the file.

The following aspects are important regarding catalog
data to be published:

Publish a catalog

Type of catalog content that can
be published

Publish a Catalog

You initiate a search for a catalog from the
Manage Catalogs page, select the row corresponding to the catalog
that you want to publish and select the Publish action. The application generates the report based on the default
template in HTML format, and the locale prior to creation of the file.
You can select a new template or format from the report window. The
content displayed for items, categories, catalog categories, and catalog
is based on the publish template.

Type of Catalog Content That Can Be Published

The default catalog publish template allows
the publication of the catalog header details, category hierarchy,
category details, and category item assignments. The order of a published
report begins with the catalog header and the catalog category details.
If the category has a child relationship then the catalog category
association details for the child category follows. If the child category
has a hierarchy, then the complete hierarchy under the category is
published with the catalog category association details and categories
details.

FAQs for Define Basic Catalogs

How can I share
catalog content?

Categories can be shared across multiple catalogs
allowing catalog content to be reused and saving the work needed to
maintain multiple copies of the categories. In the case of category
sharing, the category structure in the source catalog can be different
than the native catalog.

Categories can be shared using two methods; the first
method is directly associating the category to the catalog. The category
is added to the catalog and can be edited in the catalog or any catalog
the category is associated to. The items assigned to the category
are not shared, but are assigned to the category in context with the
catalog the category is associated. For example if the category name
or description is changed in one catalog, the change will be reflected
in all catalogs where the category is associated, but if items are
assigned to a category, the assignment will be for that single catalog.

The second method of sharing categories is adding
a category by reference into the catalog. During the creation of
the catalog, sharing can be enabled by specifying a single source
catalog that will be used for sharing by reference and setting the
value of the sharing content to control what content will be shared
from the source catalog. The advantage of using sharing by reference
is source catalog content can be shared to multiple catalogs and maintained
in a single place, the source catalog. In addition, the referenced
content can be more than one category, for example a complete category
hierarchy and any assigned items to categories in shared content can
also be reference within the catalog.

How can I define
category hierarchies?

Categories can be organized to represent classification
taxonomies. The hierarchy organizations for categories have parent
and child relationships that form a tree structure. The category hierarchy
is created and maintained within the Edit Catalog page, category hierarchy
tab. The category hierarchy is shown in true relationship to the way
it is defined.

The category hierarchy can be created using two methods:
the first is manually creating the hierarchy by adding referenced
categories, duplicating categories or creating category for the catalog.

The second method for creating the hierarchy is by
importing the category hierarchy through the spreadsheet interface.
The category hierarchy can be exported from other catalog or other
sources, edited and imported into a new catalog, additionally it can
be added manually to the spreadsheet.

The category hierarchy can be edited using Move Category. The catalog category association
cannot be deleted, but can be end dated to make the catalog category
association inactive. The category hierarchy table provides a choice
list filter that controls what catalog category associations and categories
area displayed based on the date enablement. The category hierarchy
can also be edited by exporting the complete hierarchy, editing it
and importing the category hierarchy back into the catalog.

How can I duplicate
categories?

You can select and duplicate a category as
a quick way to create a similar category configuration. Selecting
the Duplicate icon action launches
a Create Category dialog that has attribute fields populated based
on the selected category attribute values. The category name is prefixed
with Copy_ followed by the name
of the selected category. You fill in the required field information
in the key flexfield segment values which are blank. Once the category
attributes are updated and the key flexfield segments values are entered,
the OK button adds the newly created
category into the category hierarchy of the selected category you
have configured.

How can I add
categories?

Categories are catalog components that are
associated to a catalog for purpose of classification of items. You
can add existing categories to the point of selection which can be
a category in the hierarchy or the root of the catalog. If no category
is selected, the default is the root of the catalog.

You can add categories by selecting the Add Category field and selecting the value Add Category. You can then search for existing
categories based on the value of the catalog structure for the catalog.
You can narrow the search for existing categories by using the Advance Search region in the dialog. You
can add each selected category by selecting the Apply button and the add category region remains open.
The OK button adds a category
if a category is selected and then closes the dialog.

How can I add
shared categories?

Adding a shared category is similar to
adding an existing category except the category is selected from the
catalog that has been designated as a source catalog. The sharing
content attribute value determines what content is shared from the
source catalog. A category within a source catalog that has been
added to a native
catalog is also known as a referenced category. You
use the drop list menu from the Add Categories menu, and the Shared
Category option will be disabled if the catalog has not been configured
for category sharing.

How can I add
images to a catalog or category?

You can attach an image from your desktop
or from a configured repository to a catalog or a category, or both. The image is displayed
in the catalog detail and the category detail section of the catalog
page. Only one image can be associated with a catalog or category.
To attach an image, select the green plus icon to launch the Manage
Attachment dialog. The image attachment type can have values of File or Repository
File/Folder and is selected in this dialog. The title
you provide for the image attachment will appear under the image that
is displayed in the catalog. The description you provide is not displayed. Browse will allow you to select the file
to be used as the image for the catalog or category. After the information
is entered in to the dialog, you click the OK button to load the image and the image attachment
title will be displayed under the image. The image will not initially
be displayed until the catalog is saved. The image can be replaced
with another image by selecting the red X to delete the existing image
and entering a new image.

What is catalog
mapping?

You use Catalog Category mapping to map categories of different catalogs to the reporting
categories in other catalogs. This feature allows one or more categories
within a catalog to be mapped to category in a second catalog. For
example, suppose that you want to roll up the costs associated with
allow items assigned to a set of categories in catalog. Catalog mapping
allows you to select a category in a catalog, and map all the categories
in the set to that category. When you use this feature you are required
to write code to do the roll up as identified in the example.

FAQs for Manage Default Catalogs

How can I map
default catalogs?

You can map a catalog to be assigned to a
functional area such as Purchasing. When a catalog is assigned to
a functional area, the catalog will behave based on the rules you
defined for that functional area. Only one catalog can be assigned
to a functional area.

Define Transaction Tax Classifications

Define Transaction
Tax Classifications: Overview

Many tax regimes define rules for specific
transactions or information related to the transaction. To support
these requirements Oracle Fusion Tax has extensive and powerful features
to allow the transaction process to be classified. These classifications
provide a conceptual model to classify the type of transactions and
documents related to the transaction. Set up your transaction process
classifications in the Define Transaction Tax Classifications activity.

The following process classifications for tax purposes
can be used within Oracle Fusion Tax and are summarized in the following
table:

Process Classification

Description

Transaction business category

Use this classification to classify a transaction
line to define the type of transaction.

Transaction fiscal classification

Use this classification to group transaction business
categories so that tax rules setup and maintenance can be minimized.

Document fiscal classification

Use this classification where there is a need to relate
documents to a transaction that affect the tax applicability or determination
of transaction taxes on the transaction.

User-defined fiscal classification

Use this classification for classifying transaction
lines where none of other classification are appropriate.

Tip

If possible, use other fiscal classifications that
are automatically derived at transaction time in preference to the
process classification which requires manual intervention at transaction
time.

Use these classifications as determining factors within
tax rules in the tax determination process, although you can also
use them for tax reporting.

Transaction
Business Categories: Explained

Use transaction business categories to classify
transaction lines to drive tax determination and reporting.

Transaction business categories provide a hierarchy
of up to five levels. The first level is predefined with standard
events that are supported by Oracle Fusion Tax. The predefined levels
are:

EXPENSE_REPORT

INTERCOMPANY_TRANSACTION

PAYMENT_REQUEST

PURCHASE_PREPAYMENTTRANSACTION

PURCHASE_TRANSACTION

SALES_TRANSACTION

SALES_TXN_ADJUSTMENT

Use the transaction business category functionality
to add additional levels and transaction business categories to these
levels. However, you cannot add additional level one transaction business
categories, you can only add additional transaction business categories
that are children, or lower levels, of the predefined level one records.

When defining additional transaction business categories,
use the Country field to specify
the taxation countries where the transaction business category is
used. During transaction time, the taxation country is used to restrict
the list of transaction business categories that are available on
the transaction line to those that have been set up with the same
country or where the country is blank.

When setting up transaction business categories, leave
the Country field blank or use
the country name as defined on any parent level of the record that
is being added.

Use the Associated Transaction Fiscal Classifications
region to link a specific transaction business category to the transaction
fiscal classification. You can use this association to allow different
transaction business categories to be linked to the same transaction
fiscal classification. This facilitates in setting up tax rules using
a specific transaction fiscal classification instead of creating multiple
tax rules for different transaction business categories.

Tip

While setting up the transaction business categories,
use different levels so that you can define all of the necessary tax
rules at the highest level possible. This facilitates in minimizing
the needed number of tax rules.

Transaction Business Categories in Tax Rules

The transaction business category tax determination
factors allow you to use the transaction business category in tax
rules. A combination of determination factor class, class qualifier,
and determining factor represent these determination factors.

Use the transaction generic classification as the
determining factor class, the level of the transaction business category
being used, level 1, level 2, level 3, level 4, or level 5 as the
class qualifier, and transaction business category as the determining
factor.

When a country name is specified on the condition
set, the application selects only those transaction business categories
that match the country name or where the country name is blank on
the transaction business category.

Transaction Business Categories at Transaction
Time

During transaction time, enter the transaction
business category on the transaction line to classify the transaction
line for tax determining and reporting purposes.

The transaction business category is stored in the
tax reporting ledger and is available for reporting.

Transaction
Business Categories: Example

The following scenario illustrates how transaction
business categories can be used for tax determination and reporting
in Brazil.

Scenario

In Brazil, you need to identify a transaction correctly
to be able to report and determine the correct applicable taxes. Create
specific transaction business categories as children of the sales
transaction. The transaction business categories include:

Level

Fiscal Classification Code

Fiscal Classification Name

Country

Start Date

1

SALES_TRANSACTION

Sales Transaction

1-Jan-1951

2

INTERSTATE MNFTRD FOR SALE

Interstate Manufactured for Sale

Brazil

The earliest transaction date or start date of tax.

2

INTERSTATE MNFTRD FOR MANUFACTURE

Interstate Manufactured for Manufacture

Brazil

The earliest transaction date or start date of tax.

To create these transaction business categories:

On the Manage Transaction Business
Codes page select the SALES_TRANSACTION record.

Enter the values as shown in the
above table. By default, the start date is the start date of the sales
transaction parent record, that is, 1-Jan-1951.

Specify the latest of:

Earliest applicable transaction to
be used in the implementation.

Start date of the applicable Brazilian
tax.

Tip

Specify the country name while creating transaction
business categories. This ensures that a limited applicable list is
presented while entering the transaction business category during
transaction or tax rule creation.

Tip

While using the transaction business categories classification,
classify the nonstandard items of your business as standard items.
This can be modeled as a default tax rule and therefore, does not
require an explicit classification or an explicit tax rule. Classify
only exception items and define specific tax rules for them. For a
standard item, none of the explicit tax rules are applicable and the
default rate applies.

Transaction
Fiscal Classifications: Explained

Use transaction fiscal
classifications to categorize transaction business categories
so that multiple transaction business categories can be classified
and a single transaction fiscal classification can be used within
the tax rules. This facilitates all of the applicable transaction
business categories to trigger the relevant tax rule.

Transaction fiscal classifications provide a hierarchy
of up to five levels. Each grouping of 1 to 5 levels is given a fiscal
classification type group, which is used to retrieve all of the associated
levels of one transaction fiscal classification type.

You assign each level a fiscal classification type
code and name with associated start and end dates. Use the fiscal
classification type code as the determining factor when you create
tax rules. The start date must be equal to or before the earliest
transaction date that triggers a tax rule that uses the applicable
transaction fiscal classification.

Associate each fiscal classification type record with
a tax regime that is used when the tax rules are created. This ensures
that the list of values of the transaction fiscal classification is
restricted by the tax regime for which the tax rule is being created.

Tip

Set the transaction fiscal classification start date
to the earliest tax regime start date of any tax that uses the given
transaction fiscal classification.

To create these transaction fiscal classifications:

On the Create Transaction Fiscal
Classification Types page save the current transaction fiscal classification
type values before proceeding to the next step of creating transaction
fiscal classification codes, associating business categories, and
specifying tax reporting codes.

Click the Create Child Node to create the subordinate levels. Create
the subordinate levels up to the maximum levels defined for the transaction
fiscal classification type group.

Associate the fiscal classification
type record with one or more transaction fiscal classification codes.
These codes are used to group the transaction business category, which
is used in the tax rule as the condition set value.

Tip

While setting up the transaction fiscal classification,
use different levels so that all of the necessary tax rules are defined
at the highest level possible. This facilitates in minimizing the
needed number of tax rules.

Associate and form a relationship between the transaction
fiscal classification codes and the transaction fiscal classification.
This relationship is used during transaction time to derive the transaction
fiscal classification that validates the tax rules that use the transaction
fiscal classification.

Use the Associated Codes Details region to define
the relationship between transaction fiscal classification codes,
the transaction business category codes, and the tax reporting codes.
Use the Transaction Business Category Codes and the Tax Reporting
Codes tab to define the relationship.

Transaction Fiscal Classifications in Tax Rules

The transaction fiscal classification tax
determination factors allow you to use the transaction fiscal classifications
in tax rules. A combination of determination factor class and determining
factor represent these determination factors.

Use the transaction fiscal classification as the determining
factor class and the specific transaction fiscal classification type
as the determining factor.

Transaction Fiscal Classifications at Transaction
Time

During transaction time, use the transaction
business category entered on the transaction line to classify the
transaction line. The application derives the transaction fiscal classification
using the defined relationship between the transaction business category
and the transaction fiscal classification.

The tax determination process uses the derived transaction
fiscal classification and any associated parent records for the higher
levels to compare against the relevant tax rules.

Transaction
Fiscal Classifications: Example

A transaction fiscal
classification is the grouping multiple transaction business
categories into a single transaction fiscal classification that is
used with tax rules. This facilitates in triggering all of the applicable
transaction business categories with relevant tax rules.

The following scenario illustrates how transaction
fiscal classifications can be used for tax determination and reporting
in Brazil.

Scenario

In Brazil, you need to identify a transaction correctly
to be able to report and determine the correct applicable taxes. Create
specific transaction business categories as children of the sales
transaction. The transaction business categories include:

Level

Fiscal Classification Code

Fiscal Classification Name

Country

Start Date

1

SALES_TRANSACTION

Sales Transaction

1-Jan-1951

2

INTERSTATE MNFTRD FOR SALE

Interstate Manufactured for Sale

Brazil

The earliest transaction date or start date of tax.

2

INTERSTATE MNFTRD FOR MANUFACTURE

Interstate Manufactured for Manufacture

Brazil

The earliest transaction date or start date of tax.

Tip

Specify the country name while creating transaction
business categories. This ensures that a limited applicable list is
presented while entering the transaction fiscal classification during
transaction or tax rule creation.

Tip

In this classification and many other tax classifications,
classify the nonstandard items of your business as standard items.
This can be modeled as a default tax rule and therefore, does not
require an explicit classification or an explicit rule. Classify only
exception items and define specific tax rules for them. For a standard
item, none of the explicit tax rules are applicable,
only the default rate applies.

The tax rules that apply to sales transactions are
also applicable to purchase transactions. In this case, equivalent
set rules are needed to represent the purchase side of the same transaction
type. Therefore, create the following additional transaction business
categories:

Level

Fiscal Classification Code

Fiscal Classification Name

Country

Start Date

1

PURCHASE_TRANSACTION

Purchase Transaction

1-Jan-1951

2

INTERSTATE MNFTRD FOR SALE

Interstate Manufactured for Sale

Brazil

The earliest transaction date or start date of tax.

2

INTERSTATE MNFTRD FOR MANUFACTURE

Interstate Manufactured for Manufacture

Brazil

The earliest transaction date or start date of tax.

In the above scenario, instead of creating tax rules
based on the type of transaction business category, that is, separate
tax rules for sales and purchase transactions, create a single transaction
fiscal classification and both the applicable sales and purchase transactions
can be linked to it.

Create the following specific transaction fiscal classification
with the relevant tax regime and transaction business category associations.
In addition, create appropriate tax rules against this transaction
fiscal classification.

Level

Transaction Fiscal Classification Code

Fiscal Classification Name

Start Date

1

BRAZIL MNFTRD (O2C and P2P) FOR SALE

Brazil Manufacture

1-Jan-1951

At transaction time, the tax determination process
derives this transaction fiscal classification whenever the related
transaction business categories are used on the transaction.

Document Fiscal
Classifications: Explained

Use the document fiscal classification in situations where the documentation associated with the transaction
is needed for tax determination and reporting. Unlike other process
classifications, document classifications are associated with the
header of the transaction and therefore, apply to all the transaction
lines on a transaction.

Document fiscal classifications provide a hierarchy
of up to five levels. When defining the document fiscal classification
codes, use the Country field to
specify the taxation countries where the document fiscal classification
is used.

During transaction time, the taxation country is used
to restrict the list of document fiscal classification on the transaction
line to those that have been set up with the same country or where
the country is blank. When setting up the document fiscal classification,
leave the Country field blank
or use the same country that is defined on any parent level of the
record that is being added.

Tip

While setting up the document fiscal classification,
use different levels so that all the necessary rules are defined at
the highest level possible. This facilitates in minimizing the needed
number of tax rules.

Document Fiscal Classifications in Tax Rules

The document fiscal classification tax determination
factors allow you to use the document fiscal classification in tax
rules. A combination of the determination factor class, class qualifier,
and determining factor represents these determination factors.

Use document as the determining factor class, the
level of the transaction business category being used, level 1, level
2, level 3, level 4, or level 5 as the class qualifier, and the document
fiscal classification as the determining factor.

The value you enter against the condition set is the
document fiscal classification code or name set up for the specific
level defined in the class qualifier, as well as for the same country
or where the country is blank on the document fiscal classification.

Document Fiscal Classifications at Transaction
Time

During transaction time, enter the document
fiscal classification on the transaction to classify the transaction
for tax determining and reporting purposes.

The document fiscal classification is stored in the
tax reporting ledger and is available for reporting.

Document Fiscal
Classifications: Example

The document fiscal classifications classify transactions for tax determination and reporting. Use this
classification when the documentation associated with the transaction
is needed to support the tax determination and reporting processes.

The following scenario illustrates how Intra-EU supplies
are controlled through zero-rating of transactions. A zero-rating
is given to a transaction only when the export documentation related
to the transaction is received.

Scenario

When the export documentation is not received in
time, the customer is invoiced with the VAT that is applicable in
the country of the supplier. The transaction is not zero-rated, which
is the normal case for Intra-EU business-to-business supplies.

To model this scenario, create a document fiscal classification
and attach it to a transaction only when the documentation is received.
If the document fiscal classification is not attached to a transaction,
the Intra-EU goods business-to-business supply rules are not triggered
and the applicable VAT is charged.

When the documentation is received after the invoice
is generated, the invoice that is sent is credited and a new invoice
is produced.

Create the following document fiscal classification:

Level

Fiscal Classification Code

Fiscal Classification Name

Country

Start Date

1

INTRA-EU DOCUMENTS

Sales Transaction

The earliest transaction date or start date of tax.

2

INTRA-EU EXPORT DOCUMENTATION

Intra-EU Export Documentation Received.

The earliest transaction date or start date of tax.

The tax rule that defines the conditions under which
the Intra-EU supply of business-to-business goods are zero-rated includes
a determining factor as shown in the following table:

Determining Factor Class

Class Qualifier

Determining Factor

Operator

Value

Document

Level 2

Document Fiscal Classification

Equal to

INTRA-EU EXPORT DOCUMENTATION

Tip

Specify the country name while creating transaction
business categories. This ensures that a limited applicable list is
presented while entering the document fiscal classification during
transaction or tax rule creation.

Tip

In this classification and many other tax classifications,
classify the nonstandard items of your business as standard items.
This can be modeled as a default tax rule and therefore, does not
require an explicit classification or an explicit rule. Classify only
exception items and define specific tax rules for them. For a standard
item none of the explicit tax rules are applicable, only the default
rate applies.

User-Defined
Fiscal Classifications: Explained

Use user-defined fiscal classification to
classify transactions to drive tax determination and reporting. Use
user-defined fiscal classifications when other classifications are
not appropriate or an additional classification is required. Enter
user-defined classifications on a transaction line at the time of
transaction.

User-defined fiscal classifications provide only one
level. When defining the user-defined fiscal classification codes,
use the Country field to specify
the taxation countries where that user-defined fiscal classification
is used. Leave the country blank if the user-defined fiscal classification
code is used for multiple countries. When setting up user-defined
fiscal classification, leave the country field blank or use the same
country as defined on any parent level of the record that is being
added. During transaction time, the taxation country is used to restrict
the list of user-defined fiscal classifications on the transaction
line to those that are set up with the same country or where the country
is blank on the user-defined fiscal classification.

User-Defined Fiscal Classifications in Tax Rules

The user-defined fiscal classification tax
determination factors allow you to use user-defined fiscal classification
in tax rules. A combination of determination factor class and determining
factor represent these determination factors.

Use the transaction input factor as the determining
factor class and user-defined fiscal classification as the determining
factor.

The value entered against the condition set is the
specific user-defined fiscal classification code or name and the same
country or where the country on the user-defined fiscal classification
is blank.

User-Defined Fiscal Classifications at Transaction
Time

During transaction time, enter the user-defined
fiscal classification on the transaction line to classify the transaction
for tax determination and reporting purposes.

The user-defined fiscal classification is stored in
the tax reporting ledger and is available for reporting.

User-Defined
Fiscal Classifications: Example

Use the user-defined fiscal classification
to classify transactions for tax determination and reporting. This
classification is used when other classifications are not appropriate
or an additional classification is required in tax determination and
reporting.

This scenario illustrates how a user-defined fiscal
classification is used to identify if a customer is a foreign diplomat
and therefore, exempt from value-added tax (VAT).

Scenario

To model this scenario, create a user-defined fiscal
classification that is added to a transaction line only when the customer
is a foreign diplomat and VAT is exempted.

In practice, it is likely that most businesses monitor
such transactions and therefore, specifically create a zero (0%) rate
within the exempt tax status to allow monitoring of such situations.
By reporting this specific 0% rate, all applicable transaction can
be identified.

Create the following user-defined fiscal classification:

Fiscal Classification Code

Fiscal Classification Name

Country

Start Date

FOREIGN DIPLOMAT EXEMPTION

Foreign Diplomat Exemption

United Kingdom

The earliest transaction date or start date of tax.

Set up the following determining factor for the tax
rule that defines the condition where the sales transaction is zero
percent (0%) rated using the special exempt rate, tax status and tax
rate rule:

Determining Factor Class

Class Qualifier

Determining Factor

Operator

Value

Transaction Input Factor

User-Defined Fiscal Classification

Equal to

FOREIGN DIPLOMAT EXEMPTION

This tax rule, to apply a zero tax rate to a transaction,
is applicable only when the user-defined fiscal classification is
associated with the transaction line.

Tip

Specify the country name while creating the user-defined
fiscal classification. This ensures that a limited applicable list
is presented while entering the user-defined fiscal classification
during transaction or tax rule creation.

Define Party Classifications

Party Information: Explained

Party classification defines the different
types of party. Use party classifications to define party types for
tax determination and tax reporting purposes.

Oracle Fusion Tax uses two types of tax party classifications:

Party fiscal classifications

Legal party classifications

Both are used to classify parties to provide determining
factors or building blocks on which tax rules are defined. They are
also used to classify parties so that they can be reported.

Party Fiscal Classifications

Use party classifications to classify your
customers, suppliers, first party legal entities, and first party
legal reporting units for tax determination and tax reporting.

Define the party classification categories and associated
classification codes within the Oracle Fusion Trading Community Model
party classification setup. Create the party fiscal classifications
and associate the specific Trading Community Model party classification
category to these party fiscal classifications, one for each level
of the specific Trading Community Model party classification category.
Associate tax regimes to these party classifications to ensure that
these relationships are only visible and usable where needed. Oracle
Fusion Tax uses this relationship to indicate which Trading Community
Model party classification categories are used for tax purposes. By
reusing the Trading Community Model party classification category
functionality Oracle Fusion Tax can leverage the common classification
setup and where applicable, use that for tax purposes.

Within the party fiscal classifications functionality,
define the Trading Community Model classification level to use within
Oracle Fusion Tax. For example, if you have a three level Trading
Community Model party fiscal classification category, define three
levels, giving each a specific party fiscal classification code and
name. By naming each level, you can use the specific level as a determining
factor when defining tax rules. Use the same party fiscal classification
flow to define the tax regimes with which the party fiscal classifications
are associated.

Note

You can only amend the number of levels by increasing
the number of levels. It is not possible to decrease the number of
levels once the record has been stored.

Once you have defined your Trading Community Model
party classification and associated it with a party fiscal classification
and tax regime, you can use it to classify your parties and party
sites. These parties and party sites are:

Customers

Customer sites

Suppliers

Supplier sites

Legal entities

Legal reporting units

In the case of supplier and customer parties and party
sites, you can associate the specific party classification codes used
for tax purposes using either:

Party tax profile flows within Customer
Maintenance and Supplier Maintenance.

Dedicated flows in Oracle Fusion
Tax.

Legal Party Classifications

Legal party classifications are similar to
party fiscal classifications. Both use the Trading Community Model
party classification setup and allows you to classify the party for
tax determination and tax reporting purposes. However, the legal party
classifications are predefined and are available when you implement
the application.

The following legal classification codes are predefined:

Legal Party Type Code

Legal Party Type Name

LEGAL_ACTIVITY_CODE_CL

Legal activity code for Chile

LEGAL_ACTIVITY_CODE_PE

Legal activity code for Peru

LEGAL_ACTIVITY_CODE_VE

Legal activity code for Venezuela

LEGAL_ACTIVITY_CODE_CO

Legal activity code for Columbia

2003 SIC

Legal activity code for United Kingdom

Use legal party classifications to classify first
party legal entities within the Legal Entity setup functionality.
Use these classifications as determining factors within tax rules.
Association between the legal party classification and specific legal
parties is done within the Legal Entity Maintenance flow.

No specific setup is required as the legal party classifications
are predefined and can be directly used in tax rule setup.

Party Fiscal
Classifications: How They Work in Tax Rules and Tax
Reporting

Party fiscal classification tax determination
factors allow you to use party fiscal classifications in tax rules. A combination of determination factor class, class
qualifier, and determining factor represent these determination factors.
In the tax rules setup, define the actual party to be used to determine
the relevant party fiscal classification by using a generic definition
for class qualifier. You can also use party fiscal classifications
for tax reporting.

Party Fiscal Classifications in Tax Rules

Depending on the type of transaction, the following
generic class qualifiers are defined as class qualifiers when using
the party fiscal classification as a tax determining factor:

Supplier bill-from party

Bill-to party

Ship-to party

Ship-from party

Point-of-acceptance party

Point-of-origin party

Oracle Fusion Tax translates the generic parties into
specific transaction parties as defined in the following table:

Generic Party

Order-to-Cash Party

Procure-to-Pay Party

Bill-from party

First party legal entity

Supplier

Bill-to party

Customer

First party legal entity

Ship-to party

Customer (ship-to) party site

First party legal entity

Ship-from party

First party legal reporting unit

Supplier (ship-from) party site

Point-of-acceptance party

Customer point of acceptance party

Not applicable

Point-of-origin party

Customer point of origin party

Not applicable

Tip

Always use the highest applicable level to define
the party classification. For example, if appropriate, define the
party fiscal classification at the customer or supplier level instead
of defining the same classification on all the party sites for the
customer and suppliers.

Tip

Because party fiscal classifications are automatically
derived during transaction time, use them as determining factors instead
of process-based determining factors, which require manual entry for
every transaction.

Party Fiscal Classifications in Tax Reporting

Use party classifications to classify parties for
tax reporting purposes if specific party classifications need to be
reported. However, you should use tax reporting codes for tax reporting
instead of party fiscal classifications as it offers a more flexible
and less intrusive mechanism to support reporting without creating
unnecessary complexity in setup and maintenance.

Classifying
Parties: Example

The following example illustrates using party
fiscal classifications in tax rules. It is based on the following
scenario:

A company Widget Inc., UK Ltd. produces
widgets that are used by military forces who are part of the North
Atlantic Treaty Organization (NATO).

The widgets are sold to the Belgium
Troops stationed in UK under a joint NATO exercise.

The supply of widgets by Widget Inc.,
UK Ltd. is within the terms and conditions of supplies to NATO forces
which allows a supplier to zero rate supplies to visiting NATO forces.
See Visiting Forces - HMRC Reference: Notice 431 (November 2003).

The NATO International Military Headquarters
at Northwood and High Wycombe.

The American Battle Monuments Commission
in respect of supplies of goods and services for the maintenance of
the US military cemeteries at Brookwood and Madingley.

Creating Party Classifications and Tax Rules

To model this requirement, the company site that represents
the Belgium troops working at the joint NATO exercise is associated
with GB Special Tax Parties, a special party classification type and
NATO Troops, a party fiscal classification code.

To do this:

Create an Oracle Fusion Trading Community
Model party classification of GB Special Tax Parties
with a level one code of Zero Rated Parties.

Create a level 2 code for this level
1 code of NATO.

Create party fiscal classifications
of GB Special Tax Parties Level 1 and GB Special Tax Parties Level
2, which are linked to the Trading Community Model party classification.

Associate the party fiscal classifications
with the GB VAT tax regime using a start date of the earliest transaction
date of supplies to this or similar customer sites.

Associate the company site that represents
the Belgium troops working at the joint NATO exercise to the GB Special
Tax Parties Level 2 party fiscal classification using code of NATO.

Create the determining factor set
and condition set that uses this classification code Zero Rated Parties
of the level 1 party fiscal classification type. No specific Determine
Tax Rate tax rule is needed as you can set up the zero tax rate as
the default tax rate for this tax status.

Create a Determine Tax Status tax
rule linked to a zero tax status by using the determining factor and
condition set created above.

At transaction time the tax determination process
considers this tax status rule and derives a zero tax status when
the customer ship-to party is associated with the level 1 party fiscal
classification of GB Special Tax Parties Level 1 and code of Zero
Rated Parties.

Tip

Use the levels in the Trading Community Model party
classification categories model and the party fiscal classification
setup to group party classification categories together.

Tip

Define tax rules at the highest level possible thus
minimizing the number of tax rules needed. In this example, the tax
rule uses the level 1 party fiscal classification to determine the
zero tax status.

FAQs for Define Party Classifications

What's the difference between legal classifications and fiscal classifications?

Legal classifications are a unique classification
associated with a legal entity that represents its legal status within
a country and that also guides the tax determination process. They
should be defined by the Trading Community Architecture legal entity.
In some countries these legal classifications are defined by:

Business activity type

Business activity code

Business activity description

Party fiscal classifications also are defined
using the Trading Community Architecture application. They determine,
for example, when taxes apply to a party, how much tax applies, and
what percentage of the tax is recoverable.

You can use legal classifications for fiscal classification
purposes. In effect, a legal classification just becomes another party
fiscal classification for tax purposes.

Define Taxes

Regimes to
Rates: Explained

Regime to rate setup contains the details
of a tax regime, including all taxes, tax jurisdictions, tax statuses,
and tax rates. You can update existing records or create new records
at any point in the tax regime hierarchy.

Regime to rate setup tasks include:

Tax regimes

Taxes

Tax jurisdictions

Tax statuses

Tax rates

Tax Regimes

Set up tax regimes in each country and geographical
region where you do business and where a separate tax applies. A tax
regime associates a common set of default information, regulations,
fiscal classifications, and optionally, registrations, to one or more
taxes. For example, in the United States create a Sales and Use Tax
tax regime to group taxes levied at the state, county, and district
levels.

The tax regime provides these functions:

Groups similar taxes together

Designates the geography within which
taxes apply

Applies as defaults the settings
and values that you define for each tax in the tax regime

Defines for which taxes the configuration
options apply and a specific subscription option applies

Provides a single registration for
all taxes associated with the tax regime

Defines the use of fiscal classifications
as follows:

Transaction fiscal classifications

Product fiscal classifications

Party fiscal classifications

The common tax regime setup is one tax regime per
country per tax type, with the tax requirements administered by a
government tax authority for the entire country. There are also cases
where tax regimes are defined for standard geographical types or subdivisions
within a country, such as a state, province, country, or city. In
these cases, you base the tax regime on the Oracle Fusion Trading
Community Model standard geography.

There are more rare cases where a tax regime is based
on disparate parts of a country or more than one country. In these
cases, you can create one or more tax zones and set up tax regimes
for these tax zones. You can also set up a tax regime as a parent
tax regime to group related tax regimes together for reporting purposes.

You must set up a tax regime before you set up the
taxes in the tax regime. Some tax regime values appear as defaults
on the taxes that belong to the tax regime in order to help minimize
tax setup.

You must associate a tax regime with all of the first
party legal entities and business units that are subject to the tax
regulations of the tax regime. You can set up tax configuration options
when you create or edit a tax regime or when you create or edit a
first party legal entity tax profile. Both setup flows appear and
maintain the same party and tax regime configuration options.

Taxes

Set up details for the taxes of a tax regime. Each
separate tax in a tax regimes includes records for the tax statuses,
tax rates, and tax rules that are used to calculate and report on
the tax. Oracle Fusion Tax applies as defaults tax information from
the tax regime to each tax that you create under a tax regime. You
can modify this information at the tax level according to your needs,
as well as add additional defaults and overrides. For tax rule defaults,
specify values that apply to the majority of your transactions. Use
tax rules to configure exceptions to the tax rule defaults.

Identify what taxes you must define. Each tax appears
as a single tax line on a transaction. If you need to show or report
more than one tax line per transaction line on a transaction, then
you should set up more than one tax. For example, for US Sales and
Use Tax you would define a tax for each state, county, and city.

You can create a new tax, or create a tax that is
based on an existing tax within the tax regime. You do this to minimize
setup by sharing tax jurisdictions and tax registrations. When you
create a new tax based on an existing tax, the attributes that remain
constant for all taxes derived from the source tax are not available
for update. Attributes that are copied and are display only include:

Tax regime

Tax

Geography information

Tax jurisdiction settings

Note

The enable tax settings are not selected, in the same
way that they are not selected when you access the Create Tax page.

You can enable a tax for simulation or for transactions
only after you have completed all of the required setup.

Tax Jurisdictions

Set up tax jurisdictions for geographic regions or
tax zones where a specific tax authority levies a tax. A tax jurisdiction
specifies the association between a tax and a geographic location.
At transaction time, Oracle Fusion Tax derives the jurisdiction or
jurisdictions that apply to a transaction line based on the place
of supply. You must set up at least one tax jurisdiction for a tax
before you can make the tax available on transactions.

You also use tax jurisdictions to define jurisdiction-based
tax rates. A tax jurisdiction tax rate is a rate that is distinct
to a specific geographic region or tax zone for a specific tax. You
can also create multiple jurisdictions at once using the mass create
functionality for taxes that relate to specific Trading Community
Model geographic hierarchies. For example, create a county jurisdiction
for every county in the parent geography type of State and in the
parent geography name of California.

The tax within a tax jurisdiction can have different
rates for the parent and child geographies. For example, a city sales
tax rate can override a county rate for the same tax. In this case,
you can set up an override geography type for the city and apply a
precedence level to the city and county tax jurisdictions to indicate
which tax jurisdiction takes precedence.

In addition, in some cities a different city rate
applies to the incorporated area of the city, called the inner city.
In these cases, you can set up an inner city tax jurisdiction with
its own tax rate for the applicable customers and receivables tax.
Inner city tax jurisdictions are often based on postal code groupings.

Tax Statuses

Set up the tax statuses that you need for each tax
that you create for a combination of tax regime, tax, and configuration
owner. A tax status is the taxable nature of a product in the context
of a transaction and specific tax on the transaction. You define a
tax status to group one or more tax rates that are the same or similar
in nature.

For example, one tax can have separate tax statuses
for standard, zero, exemptions, and reduced rates. A zero rate tax
status may have multiple zero rates associated with it, such as Intra-EU,
zero-rated products, or zero-rated exports.

You define a tax status under a tax and a configuration
owner, and define all applicable tax rates and their effective periods
under the tax status. The tax status controls the defaulting of values
to its tax rates.

Tax Rates

Set up tax rates for your tax statuses and tax jurisdictions.
For tax statuses, set up a tax rate record for each applicable tax
rate that a tax status identifies. For tax jurisdictions, set up tax
rate records to identify the tax rate variations for a specific tax
within different tax jurisdictions. For example, a city sales tax
for a state or province may contain separate city tax jurisdictions,
each with a specific tax rate for the same tax.

You can also define tax recovery rates to claim full
or partial recovery of taxes paid.

You can define tax jurisdiction and tax status rates
as a percentage or as a value per unit of measure. For example, a
city may charge sales tax at a rate of 8 percent on most goods, but
may levy a duty tax with a special rate of 0.55 USD per US gallon
on fuel. Values per unit of measure are in the tax currency defined
for the tax.

You define tax rate codes and rate detail information
per rate period. Rate periods account for changes in tax rates over
time. A tax rate code can also identify a corresponding General Ledger
taxable journal entry.

Tax Recovery Rates

Set up tax recovery rate codes for the recovery types
identified on the taxes within a tax regime. A tax recovery rate code
identifies the percentage of recovery designated by the tax authority
for a specific transaction. In Canada, where more than one type of
recovery is possible for a given tax, you must set up the applicable
tax recovery rate codes for both the primary and secondary recovery
types that can apply to a transaction.

If you set the Allow tax recovery option for a tax within a tax regime, then you must set up at least
one recovery rate for the tax in order to make the tax available on
transactions. If the recovery rate can vary based on one or more factors,
including the parties, locations, product or product purpose, then
set up tax rules to determine the appropriate recovery rate to use
on specific transactions. At transaction time, Oracle Fusion Tax uses
the recovery rate derived from the recovery tax rules, or uses instead
the default recovery rate that you define, if no recovery rate rules
are defined or if no existing recovery rate rule applies to the transaction.

Minimum Tax
Configuration: Explained

Oracle Fusion Tax provides you with a single
interface for defining and maintaining the taxes that are applicable
in each country where you do business.

The minimum tax configuration path to meet the basic
tax requirements of transactions in a given regime is a 2-step configuration
process:

Define tax regime: This step includes
the tax regime definition as well as the subscription by the appropriate
legal entity or business unit.

The following prerequisite setups must be completed
for minimum tax configuration:

First parties, such as legal entities
and business units

Tax geographies and zones

Ledger and accounts

Currency codes and exchange rates

A legal entity tax profile is automatically created
when a legal entity is defined in the implementation. Similarly, a
business unit tax profile is automatically created when a business
unit is defined. For the business unit, you need to indicate whether
it will use the subscription of the legal entity instead of creating
its own.

In addition, there are seeded event class mappings
that describe the mapping between an application event class and the
corresponding tax event class. For example, the tax determination
process for a sales debit memo and sales invoice are essentially the
same. These two application event classes correspond to the same tax
event class namely, a sales transaction. Although you cannot update
the event class mappings, you can set up configuration specific event
class mappings.

Define Tax Regime

The first step includes the tax regime definition
and subscription by an appropriate legal entity or business unit.
While creating your tax regime, you can minimize configuration and
maintenance costs by creating content that can be shared by more than
one entity. For example, legal entities can subscribe to the shared
reference data instead of creating separate and repetitive data. If
the subscribing legal entities have some variations in their setup,
you can create override data to meet the specific exceptions that
are applicable to these organizations.

Use Oracle Fusion Tax features to enable only those
features that are relevant to taxes in the tax regime. Based on the
features you select, the subsequent setup pages and task lists for
the tax regime are rendered or hidden.

Define Transaction Taxes

The second step includes basic tax definition,
such as geographic information, controls and defaults, direct and
indirect tax rule defaults, and tax accounts.

The basic tax definition includes controls that you
can set to provide the override capability at transaction time. For
example, if you want to allow users to make manual updates on transaction
tax lines, select the Allow override for calculated
tax lines and the Allow entry
of manual tax lines options. However, if you want to enforce
automatic tax calculation on transaction tax lines, do not enable
these options.

Use the direct and indirect tax rule defaults to specify
the values that apply to the majority of your transactions. Create
tax rules to address the exceptions or variations to the defaults.
For example, for the Goods and Services Tax (GST) that applies to
the supply of most goods and services in Canada, set the Tax Applicability
direct tax rule default to Applicable. A luxury tax, on the other hand, is a tax on luxury goods or products
not considered essential. As it would not apply to most goods and
services, set the Tax Applicability direct tax rule default to Not Applicable, and create a tax rule to
make the tax applicable when the product in the transaction satisfies
the luxury requirement.

Assign your default tax accounts for the taxes in
a tax regime to post the tax amounts derived from your transactions.
The tax accounts you associate serve as default accounting information
for taxes, tax rates, tax jurisdictions, and tax recovery rates. The
tax accounts you define at the tax level, default to either the tax
rate accounts or tax jurisdiction accounts for the same tax and operating
unit, depending upon the tax accounts precedence level of the tax
regime. You can update these default tax accounts in the tax rate
or tax jurisdiction setup.

Minimum Tax
Configuration: Points to Consider

The minimum tax configuration setup must be
designed to handle the majority of tax requirements. As part of defining
transaction taxes, decide the direct and indirect tax rule defaults
for the tax and set up the associated tax accounts.

For complex tax requirements, create tax rules that
consider each tax requirement related to a transaction before making
the final tax calculation. During the execution of the tax determination
process, Oracle Fusion Tax evaluates, in order of priority, the tax
rules that are defined against the foundation tax configuration setup
and the details on the transactions. If the first rule is successfully
evaluated, the result associated with the rule is used. If not, the
next rule is evaluated until either a successful evaluation or default
value is found.

Setting Up Direct Tax Rule Defaults

The direct tax rule defaults are the default
values for the direct tax rule types, which include:

Place of supply

Tax applicability

Tax registration

Tax calculation formula

Taxable basis formula

Place of Supply

Use the Place of Supply direct tax rule default to
indicate the specific tax jurisdiction where the supply of goods or
services is deemed to have taken place. For example, in Canada, the
place of supply for GST is typically the ship-to location. To handle
the majority of Goods and Services Tax (GST) transactions, select Ship to as your default place of supply.

Note

The corresponding place of supply differs based on
the type of transaction. For example, a place of supply of Ship to corresponds to the location of your
first party legal entity for Payables transactions. For Receivables
transactions, Ship to corresponds
to the location of your customer site. For exceptions to this default,
create Determine Place of Supply rules.

Tax Applicability

Use the Tax Applicability direct tax rule default
to indicate whether the tax is typically applicable or not applicable
on transactions. For example, the GST in Canada is a tax that applies
to the supply of most property and services in Canada. When you create
the GST tax, select Applicable as your default tax applicability. For exceptions to this default,
create Determine Tax Applicability rules.

Tax Registration

Use the Tax Registration direct tax rule default to
determine the party whose tax registration status is considered for
an applicable tax on the transaction. For example, with a direct default
of bill-to party, Oracle Fusion Tax considers the tax registration
of the bill-to party and stamps their tax registration number onto
the transaction, along with the tax registration number of the first
party legal reporting unit. For exceptions to this default, create
Determine Tax Registration rules.

Tax Calculation Formula

Use the Tax Calculation Formula direct tax rule default
to select the formula that represents the typical calculation of tax
for a transaction line. A common formula, STANDARD_TC, is predefined, where the tax amount is equal
to the tax rate multiplied by the taxable basis. For exceptions to
this default, create Calculate Tax Amounts rules.

Taxable Basis Formula

Use the Taxable Basis Formula direct tax rule default
to select the formula that represents the amount on which the tax
rate is applied. The following common formulas are predefined:

STANDARD_TB: The taxable basis is equal to the line amount of the transaction
line.

STANDARD_QUANTITY: The taxable basis is equal to the quantity of the transaction line.

STANDARD_TB_DISCOUNT: The taxable basis is the line amount of the transaction line less
the cash discount.

For exceptions to this default, create Determine Taxable
Basis rules.

Setting Up Indirect Tax Rule Defaults

The indirect tax rule defaults for a tax include:

Tax jurisdiction

Tax status

Tax recovery rate

Tax rate

Tax Jurisdiction

Use the Tax Jurisdiction indirect tax rule default
to indicate the most common geographic area where a tax is levied
by a specific tax authority. For example, value-added tax (VAT) is
applicable to the supply of most goods and services in Portugal. For
the tax PT VAT, create the default tax jurisdiction as the country
of Portugal. To address specific tax regions such as Azores and Madeira,
which have lower VAT rates than Portugal, define jurisdiction rates
with different VAT rates.

Tax Status

Use the Tax Status indirect tax rule default to indicate
the taxable nature of the majority of your transactions. For example,
if your operations primarily include zero-rated transactions, select
the default tax status as Zero instead of Standard. This setting
facilitates tax determination when multiple zero rates are defined
to handle different reporting requirements for zero rate usage, such
as intra-EU, zero-rated products, or zero-rated exports. For exceptions
to this default, create Determine Tax Status rules.

Tax Recovery

Use the Tax Recovery rate indirect tax rule default
to indicate the recovery rate to apply to each recovery type for each
applicable tax on a purchase transaction. For example, in Canada,
both federal and provincial components of Harmonized Sales Tax (HST)
are 100% recoverable on goods bought for resale. In this case, with
two recovery types, you can set up two recovery rate defaults for
the HST tax. For exceptions to this default, such as when the recovery
rate determination is based on one or more transaction factors, create
Determine Recovery Rate rules.

Tax Rate

Use the Tax Rate indirect tax rule default to specify
the default tax rate that is applicable to the majority of your transactions
associated with this tax. You can create additional tax setup, such
as jurisdiction rates, or create tax rules to set alternate values
as required. For example, HST in Canada is applied at a 13% rate in
most provinces that have adopted HST, except for British Columbia
where the rate is 12% and Nova Scotia where the rate is 15%. To satisfy
this requirement a single rate of 13% can be defined with no jurisdiction
and then a 12% rate can be defined and associated with the British
Columbia jurisdiction (15% rate assigned to Nova Scotia). This minimizes
the setup required by creating an exception based setup. For exceptions
to this default, create Determine Tax Rate rules.

Setting Up Tax Accounts

Set up tax accounts at the tax level. The
application automatically copies the tax account combination to the
tax rates that you subsequently create for the tax for the same ledger
and optionally, the same business unit.

Define tax accounts at any of the following levels.
The defaulting option is only available at the tax level.

Tax

Tax jurisdiction

Tax rate

Tax recovery rate

Note

This is a one-time defaulting opportunity. Any subsequent
changes at the account level are not copied to the tax rate level
nor are they used during the AutoAccounting process. Changes at the
tax level do impact tax account defaulting when you create new tax
rates.

Setting up tax accounts comprise of specifying the
following:

Ledger and Business Unit: The ledger
and business unit for which you are creating the tax accounts.

Interim Tax: An account that records tax recovery or liability until the event
prescribed by the statute is complete. Generally, the payment of the
invoice is the event that triggers the generation of the tax recovery
or liability. You must set up an interim tax account for taxes and
tax rates that have a deferred recovery settlement. Once you set up
an interim tax account for this tax rate, you cannot change the recovery
settlement to Immediate.

Tax Recoverable
or Liability Account: An account that records tax recovery
amounts or relieves tax liability amounts. If you set up recovery
rates for a tax that you also intend to self-assess, then define a
tax recovery account for the associated recovery rates and a tax liability
account for the associated tax rates.

Finance Charge
Tax Liability: An account that records the tax liability
associated with finance charges that is used as a deduction against
overall tax liability.

Nonrecoverable
Tax Accounts: Accounts that record tax amounts on earned
and unearned discounts and adjustments that you cannot claim as a
deduction against tax liability.

Expense and
Revenue Accounts. Accounts that record net changes generated
by adjustments, earned and unearned discounts, and finance charges.
Receivables activities such as discounts and adjustments reduce the
receivable amount, and are therefore considered an expense.

Minimum Tax
Configuration: Worked Example

The following example illustrates the minimum
tax configuration setup to meet the basic requirements in Canada for
the Goods and Services Tax (GST). You set up a tax regime for both
GST and Harmonized Sales Tax (HST). One recovery type is created for
the fully recoverable status of the transaction.

In Canada, GST is a tax that applies to the supply
of most property and services in Canada. The provinces of British
Columbia, Ontario, New Brunswick, Nova Scotia, and Newfoundland and
Labrador, referred to as the participating provinces, combine their
provincial sales tax with GST to create HST. Generally, HST applies
to the same base of property and services as the GST. Every province
in Canada except Alberta has implemented either provincial sales tax
or the HST. In countries like Canada, some or all taxes on business
transactions for registered companies are recoverable taxes.

ABC Corporation is a business with a chain of bookstores
across Canada. It intends to implement the Oracle Fusion Tax solution
at its store in the province of Alberta. The GST rate of 5% is applicable
for sales in Alberta. Input Tax Credit is available for GST included
in purchases. ABC Corporation's primary ledger is CA Ledger, and the
business unit is CA Operations. The tax account 0001-1500-1100-1000
is reserved for the Tax Recoverable
or Liability account.

The tax implications in this scenario are:

Five percent (5%) GST is applicable
on the sale of goods in Alberta

Neither the HST nor provincial sales
tax applies in Alberta

Place of supply for GST tax is generally
based on the place of delivery or ship-to location.

To determine the GST tax in Alberta, perform the following
steps:

Define tax regime

Define transaction taxes

Create the direct tax rule defaults

Create the indirect tax rule defaults

Enable tax

Define Tax Regime

On the Create Tax Regime page, enter the tax regime
code for GST and HST in Canada.

Note

Use a coding convention to indicate both the country
and the type of tax that belongs to this regime. For example, CA GST
and HST.

Select the regime level to define the geographic
area of the tax treatment. The option selected must depict the need
for the tax regime. It should be set to Country for all federal taxes.

Specify Canada as the country for which this tax regime is being defined.

Enter a start date that will appear as a default
to all related tax setup within the tax regime.

Note

Consider your tax planning carefully before entering
the start date. This date must accommodate the oldest transaction
that you want to process within this tax regime. After you create
the tax regime, you can only update this date with an earlier date.
If you enter an end date, you cannot update this date after you save
the record.

Enter tax currency. Enter CAD, which is the three-letter ISO code for the Canadian
dollar.

Tax currency is the currency required by the tax authority.
Use the tax currency to pay the tax authority and to report on all
tax transactions.

Select the Allow cross regime
compounding option to set taxes within the tax regime
to be based on the calculation of, or compounded on, taxes in another
tax regime.

For example, in Quebec, the provincial sales tax is
applied to both the selling price and GST. Enter a value as the compounding
precedence to indicate the order of cross regime compounding. A lower
number indicates that the tax regime will be processed first. Allowing
gaps between numbers provide flexibility in the event that another
higher priority tax regime is introduced in the future.

On the Configuration Options tab, select the party
name that identifies either the legal entity or the business unit
or both for which you will define the configuration options.

For the Configuration of Taxes and Rules, select
the subscription that defines the configuration owner setup that will
be used for transactions of the specific legal entity and business
unit for this tax regime.

This selection also defines whether any shared content
can be overridden by the subscribing party to allow unique, separate
setup for certain tax content.

Enter the effective start date for this configuration
option. Enter a date range that is within the date range of both the
party tax profile and the tax regime.

Define Transaction Taxes

On the Create Tax page, enter the name of the tax
regime that you created in the Define Tax Regime step, such as CA
GST and HST.

Select the configuration owner for this tax. To
minimize configuration and maintenance costs, select Global Configuration Owner as the configuration
owner.

Enter the name of the tax you are defining, such
as CA GST.

Select Province as the geography type.

To minimize setup and maintenance costs, specify
the highest-level parent geography type (Country), unless the tax
is only applicable to a specific geography. Select Country from the list of values. For the
parent geography name, enter Canada.

Enter a value as the compounding precedence to reflect
the order of tax compounding. A lower number indicates that a tax
is processed first. Allowing gaps between numbers provide flexibility
in the event that another higher priority tax is introduced in the
future.

Assign Tax Accounts

Select CA Ledger as the primary ledger to use for
tax accounts and CA Operations as the business unit.

Enter 0001-1500-1100-1000 as the Tax Recoverable
or Liability account.

Create Direct Tax Rule Defaults

Navigate to the Tax Rule Defaults tab.

Select Ship to from the Place of Supply list of values, to specify the default.

Select Applicable from the Tax Applicability list
of values to specify the Tax Applicability default.

Select Ship-from party to specify the Tax Registration default.

Select STANDARD_TC as the Tax Calculation Formula default.

Select STANDARD_TB as the Taxable Basis Formula default.

Create Indirect Tax Rule Defaults

Select Tax Jurisdiction as your rule type and create the rule type default. In the Tax Jurisdiction Code field, enter a tax
jurisdiction code for the province of Alberta, such as CA Alberta.
Select Province as the geography
type. For the geography name, enter AB for Alberta. Set this tax jurisdiction
as your default, and specify your default start and end dates.

Select Tax Status as your rule type and create the rule type default. Enter a tax
status code for GST, such as CA GST STD. Set this tax status as your
default, and specify your default start and end dates.

Select Tax Recovery Rate as your rule type and create the rule type default. Enter a tax
recovery rate code for GST, such as CA GST STD REC RATE. For the recovery
type, select Standard. Enter a
rate percentage of 100 for a fully recoverable tax. Set this tax recovery
rate as your default, and specify your default start and end dates.

Select Tax Rate as your rule type and create the rule type default. In the Tax Status Code field, enter the name of
the tax status that you just created, CA GST STD. Enter a tax rate
code for GST, such as CA GST STD RATE. Enter a rate percentage of
5 for the current GST rate as of January 1, 2008, and specify your
default start and end dates.

Enable Tax

Click the Enable tax for
simulation option. This allows you to verify the tax configuration
using the Tax Simulator.

Once you have verified your tax configuration with
simulated transactions, click the Enable tax
for transactions option. This allows you to use this tax
in transaction processing.

Click Save and Close.

For ABC's transactions in the province of Alberta,
the following is determined by default:

GST tax is applicable and will be
calculated at a percentage rate of 5%.

100% of the GST can be recovered.

Tax Account
Configuration: Explained

Set up default tax accounts for the taxes
in a tax regime to post the tax amounts derived from your transactions.
The tax accounts you define for tax serve as default accounting information
for tax rates and tax jurisdictions. You can override the defaulted
accounts. Configure the tax recoverable or liability account for the
tax recovery rate. Accounts assigned to the tax rate and recovery
rate are used when the taxes are applicable to the transaction.

Set up tax accounts for a primary ledger or in combination
with a business unit. The calculated tax amounts are posted to the
accounts specified for a business unit. If those accounts are not
available, tax accounts defined for the primary ledger are used. These
are default accounts and the actual accounts that are used for accounting
depend on the subledger accounting configuration.

For a tax, either assign new tax accounts or use accounts
from an existing tax. This depends on the option selected in the Tax Accounts Creation Method attribute for
the tax. If you choose to use accounts from an existing tax, specify
another tax as the source tax. All the tax account details that you
set up at the source tax level are copied into the Tax Accounts region
as read only values. You cannot edit the details or create new records.

Tax Accounts

Tax Expense: A Payables tax account that records tax amounts from invoice distributions;
or a Receivables tax account that record net changes generated by
adjustments, earned and unearned discounts, and finance charges. Receivables
activities such as discounts and adjustments reduce the receivable
amount, and are therefore considered an expense. This occurs only
if the adjustment type has tax handling.

Tax Recoverable
or Liability: An account that records tax recovery amounts
or relieves tax liability amounts. If you set up recovery rates for
a tax that you also intend to self-assess, then define a tax recovery
account for the associated recovery rates and a tax liability account
for the associated tax rates.

Note

If you intend to use different accounts for tax recovery
and liability then set up the recovery account for the tax recovery
rate. This account is used to debit the recoverable tax amount while
the account on the tax rate is used to account for tax liability.

Interim Tax: An account that records interim tax recovery or liability before
the actual recovery or liability arises on a payment of an invoice.
You must set up an interim tax account for taxes and tax rates that
have a deferred recovery settlement.

Accounts for Receivables activities:

Finance Charge
Tax Liability: An account that records tax amounts on
finance charges that are used as a deduction against overall tax liability.

Nonrecoverable
Tax Accounts: Accounts that record tax amounts on earned
and unearned discounts and adjustments that you cannot claim as a
deduction against tax liability.

Expense and
Revenue Accounts: Accounts that record net changes generated
by adjustments, earned and unearned discounts, and finance charges.
Receivables activities such as discounts and adjustments reduce the
receivable amount, and are therefore considered an expense.

Manage Controls and Defaults

Tax Controls
and Defaults: Points to Consider

Set up details for the taxes of a tax regime. Each separate tax
in a tax regime includes records for the statuses, rate, and rules
that are used to calculate and report on the tax. Oracle Fusion Tax
derives defaults tax information from the tax regime to each tax that
you create under a regime. You can modify this information at the
tax level according to your needs, as well as add additional defaults
and overrides.

Defining Controls and Defaults

The following table describes the defaults
and controls available at the tax level.

Header Region

Field

Description

Default Derived from

Default Appears on

Controls

Enable tax for simulation

Controls whether this tax is available for computation
within the Tax Simulator functionality

None

None

If selected then this tax is available for calculation
in the Tax Simulator if the evaluate taxes is enabled for simulation.

Enable tax for transactions

Controls whether this tax is available for transactions
and selecting this option triggers integrity checks to validate that
the setup for this tax is accurate and complete

None

None

If selected then this tax is used by transactions
if applicable. If not selected then this tax is not processed as an
applicable tax at transaction time.

Tax Information Region

Field

Description

Default Derived from

Default Appears on

Controls

Tax Currency

The default currency of the taxes within a tax regime

Tax regime

None

Defines the tax currency for calculation and reporting
purposes

Minimal Accountable Unit

The minimal unit of currency that is reported to the
tax authority, for example, 0.05 GBP indicates that 5 pence is the
minimal unit

Tax regime

None

Defines the minimal accountable unit at transaction
time

Tax Precision

A one digit whole number to indicate the decimal place
for tax rounding

Tax regime

None

Defines the tax precision during tax calculation

Conversion Rate Type

The specific exchange rate table that is used to convert
one currency into another, for example, the Association of British
Travel Agents exchange rate used in the travel industry

Tax regime

None

Defines the exchange rate that is used as necessary
at transaction time

Rounding Rule

The rule that defines how rounding is performed on
a value, for example, up to the next highest value, down to the next
lower value, or to the nearest value

Tax regime

None

Can control rounding at transaction time

Compounding Precedence

Defines the order in which this tax is calculated
compared to other taxes that are compounded on or compounded by this
tax. The tax with the lowest precedence value is calculated first.

None

None

Controls the order in which applicable taxes are calculated
at transaction time

Reporting Tax Authority

The default tax authority to whom the tax reports
are sent

Tax regime

Tax registration

None

Collecting Tax Authority

The default tax authority to whom the tax is remitted

Tax regime

Tax registration

None

Applied Amount Handling

Controls whether tax is recalculated or prorated on
prepayment, with the default being Recalculated

Selecting this option disables the Controls region
and Tax Exceptions and Exemptions Controls region and clears any values
that were entered in these regions

Set tax for reporting purposes only

Defines whether this tax is set up for reporting purposes
only

None

None

Controls whether this tax is used for reporting only
and does not create any tax account entries

Controls and Defaults Tab, Controls Region

Field

Description

Default Derived from

Default Appears on

Controls

Default Settlement Option

Lookup code to indicate whether an input tax is recovered
when an invoice is recorded or only when the invoice is paid and whether
an output tax is due for settlement when the invoice is issued or
only when the payment is received against it

Tax regime

Tax status

None

Tax Inclusion Method

Defines whether the tax is:

Standard
noninclusive handling: This option calculates the taxes
as exclusive of the given transaction line amount

Standard
inclusive handling: This option calculates the taxes as
inclusive of the given transaction line amount

Special inclusive
handling: This option calculates the taxes as inclusive
of the given transaction line amount, but the calculation methodology
differs from the standard inclusive process

None

None

Use this option in conjunction with other setup on
tax, party tax profile, tax registration, and transaction details
to control the inclusiveness of a line amount at transaction time

Allow override and entry of inclusive tax lines

Controls whether you can override and enter inclusive
or exclusive line amounts

Tax regime

Tax rate

None

Allow tax rounding override

Allows the override of the rounding defined on the
tax registration records

Tax regime

None

When selected allows you to override tax rounding
setup on the tax registration records for registrations for this tax

Allow override of calculated tax lines

Allows you to override the calculated tax lines at
transaction time when the Transaction Tax Line Override profile option
is also set

None

None

Use this option in conjunction with the Transaction
Tax Line Override profile option and the Allow
override of calculated tax lines option for the configuration
owner tax options to allow you to update calculated tax lines at transaction
time. If any of these options are not set then update of calculated
tax lines is not allowed at transaction time.

Allow entry of manual tax lines

Allows you to enter manual tax lines at transaction
time

None

None

Use this option in conjunction with Allow entry of manual tax lines option for
the configuration owner tax options. When both fields are set you
can enter manual tax lines at transaction time.

Use legal registration number

Controls whether the tax registration number is the
same as the legal registration number of the party

None

None

If this option is selected you can choose an existing
legal entity registration number as the transaction tax registration
number

Allow duplicate registration numbers

Controls whether you can enter duplicate tax registration
numbers for different parties

None

None

If this option is selected you can enter duplicate
tax registrations for different parties

Allow multiple jurisdictions

Controls whether you can enter multiple concurrent
tax jurisdictions for this tax

None

None

If this option is selected you can create multiple
concurrent tax jurisdictions for this tax

Allow mass creation of jurisdictions

Controls whether mass creation of jurisdictions functionality
is allowed using the parent geography and geography setup for this
tax

None

None

If this option is selected you can use the mass creation
jurisdictions functionality for this tax

Tax Account Controls Region

Field

Description

Default Derived from

Default Appears on

Controls

Tax Accounts Creation Method

Controls whether the tax accounts used for this tax
are derived from setup associated with this tax or copied from another
tax defined by the Tax Accounts Source field

None

None

When the value is:

Create tax
accounts: Create tax accounts for this tax

Use tax accounts
from an existing tax: Enter the tax account source to
be used at transaction time

Tax Accounts Source

Defines the tax to use to derive the tax accounts
to use at transaction time

None

None

Use when the value in the Tax Accounts Creation Method field is Use tax accounts from an existing tax

Tax Exceptions and Exemptions Controls and Defaults
Region

Field

Description

Default Derived from

Default Appears on

Controls

Allow tax exceptions

Controls whether tax exceptions are allowed for this
tax

None

Tax status

None

Allow tax exemptions

Controls whether tax exemptions are allowed for this
tax

None

Tax status

None

Use tax exemptions from an existing tax

Controls whether tax exemptions are derived from this
tax or derived from another tax as specified by the value in the Tax Exemptions Source field for the same
transaction

None

None

Controls whether you can define tax exemptions for
this tax or if they are derived from those defined against another
tax related to the same tax line at transaction time

Tax Exemptions Source

Defines the tax to use as the source when the Use Tax Exemption from an existing tax option
is selected

None

None

Used in conjunction with the Use tax exemptions from an existing tax option and uses
tax exemptions already created for customers for this tax

Tax Recovery Controls and Defaults Region

Field

Description

Default Derived from

Default Appears on

Controls

Allow tax recovery

Controls whether this tax handles tax recovery

None

None

If this option is selected you can set up tax recovery
for this tax

Tax Settings
and Rules: How They Apply to Tax Line Operations

Enter and update detail and summary tax lines
according to the requirements of your transactions. Depending on your
security settings and options specified during tax setup, you can:

Enter manual tax lines

Enter tax only tax lines

Change existing tax line information

Cancel tax lines

Note

The Summary Tax Lines component is applicable only
to Oracle Fusion Payables.

Entering Manual Tax Lines

These requirements apply to entering a manual detail
or summary tax line:

Enable the Allow
entry of manual tax lines option for the:

Configuration owner and application
event class

Tax

Ensure that the Manual Tax Line Entry profile option is enabled. It is
enabled by default.

Enter a unique combination for a tax
regime and tax. You cannot enter a manual tax line for a tax that
already exists for the transaction line.

The tax calculation on a manual tax line is a standard
formula of Tax Amount = Taxable Basis * Tax Rate. The tax determination
process does not evaluate tax rules defined for the tax of any tax
rule type.

Entering Tax Only Tax Lines

You can enter a tax-only invoice in Payables to record
tax lines that are not linked to a transaction. A tax-only invoice
is used, for example, to record tax lines on purchases that are assessed
and invoiced separately or to enter tax-only invoices from tax authorities
or import agents that record import taxes.

These requirements apply to entering a tax only tax
line:

Enable the Allow
manual tax only lines option for the configuration owner
and application event class.

Select a tax regime from the tax regimes
belonging to the configuration option of the applicable legal entity
or business unit.

Select a tax, tax status, and tax
rate and enter a tax amount.

Editing Tax Line Information

These requirements apply to changing an existing detail
or summary tax line:

Enable the Allow
override for calculated tax lines option for the:

Configuration owner and application
event class

Tax

Ensure that the Manual Tax Line Entry profile option is enabled. It is
enabled by default.

Optionally, enable the following options
for the configuration owner and application event class:

Allow recalculation
for manual tax lines option. The tax determination process
recalculates the manual tax lines when there is an update to automatically
calculated tax lines.

Tax line override
impacts other tax lines option. The tax determination
process recalculates the taxes on all other tax lines on the same
transaction when there is an override of automatically calculated
tax lines on transactions.

Save any changes to summary tax lines
before you enter or change Payables summary tax lines.

Change the tax status if necessary.
These requirements apply to changing tax statuses:

You cannot update the tax status if
the tax on the detail tax line is enforced from the natural account.

If you edit a tax only tax line and
change the tax status, you must re-enter the tax rate code.

Change the tax rate if necessary. These
requirements apply to changing tax rates:

The Allow tax
rate override option is enabled for the applicable tax
status.

The Allow ad
hoc rate option is enabled for the applicable tax rate.

You may need to change the tax status
to change to the appropriate tax rate.

You can change the calculated tax rate
derived from the tax status by selecting another tax rate defined
for the same tax regime, tax, and tax status.

For tax calculation, a limited evaluation of tax rules
on certain updates to a tax line is performed.

Canceling Tax Lines

These requirements apply to canceling an existing detail
or summary tax line:

Cancel tax lines on Payables transactions
only.

Enter a new manual tax line to reverse
a canceled tax line if necessary.

Note

On canceling the invoice or invoice lines, tax lines
are automatically canceled.

When you cancel a tax line both the associated tax
line and any distributions that were previously accounted are reversed.
If the distributions were not accounted, then the amounts are set
to zero.

Tax Amount
Rounding: Explained

Taxes applicable on a transaction are generally
calculated as the taxable basis multiplied by the tax rate equals
the tax amount. This calculated amount can result in an odd value
or with a large number of decimal place. You can configure the tax
setup to adjust or round the tax calculation according to the specific
requirements of the transacting parties and tax authority or to the
accepted currency denominations.

Party tax profiles of the parties
or party sites as given in the rounding precedence of the configuration
owner tax options or in the derived registration party

Tax

Note

If you plan to use a third party service provider
then you must define tax rounding information that is at least as
detailed as the rounding information of the service provider.

Setting Up
Rounding Rules: Choices to Consider

Criteria for rounding the calculated tax amounts
comes from various parties involved in a transaction. For example,
for a purchase transaction, the rounding methodology is generally
specified by the supplier. Specify rounding details in your tax setup
to ensure that your entered invoice amount, including the calculated
tax, is the same as the actual invoice amount. For a Receivables invoice,
you can specify rounding details based on your organization's policy,
but for most countries the rounding criterion is directed by tax legislation.

Rounding requirements can originate from:

Third parties

First parties

Tax legislation

Rounding Requirements from Third Parties

If rounding is based on third party requirements,
particularly for purchase transactions, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the third party or third party. For purchase transactions it is
either the ship-from party or the bill-from party.

Define the party tax profile for
the third party and specify the rounding level and rounding rule on
the General tab as preferred by the third party.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the third
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party account site details
and party tax profile details for deriving the rounding rule.

Rounding Requirements from First Parties

If rounding is based on business unit or legal
entity requirements, particularly for sale transactions, and configuration
owner tax options are defined, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the first party. For sale transactions it is either the ship-from
party or the bill-from party.

Ensure that the party tax profile
details are available for the corresponding legal reporting unit.
Specify the rounding level and rounding rule on the General tab per
the first party requirement or your business policy.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the first
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party tax profile details
for deriving the rounding rule.

The rounding criteria applied if configuration owner
tax options are not defined and the criteria in the predefined event
class options are considered include:

For a purchase transaction, the predefined
event class options use the ship-from party site and ship-from party
within the rounding precedence with the default rounding level as
the header level. The supplier's rounding preferences are considered
first on the transaction. If there are no specific supplier preferences,
for example, the party tax profile record does not exist, then the
default rounding level of Header is considered and the corresponding rounding rule from each tax
setup detail is used.

For a sale transaction, the predefined
event class options do not include any rounding precedence details.
However, the default rounding level is set to Line so the rounding level is always taken as Line and the corresponding registration record
for the tax registration party is considered for the rounding rule.
The tax registration party is identified through the Determine Tax
Registration tax rule or tax rule defaults. If a registration record
does not exist for the tax registration party, the rounding rule defined
within each tax is considered.

Rounding Requirements from Tax Legislation

If rounding is based on tax legislation, the
following occurs:

If the configuration owner tax options
are defined for the combination of business unit and legal entity
for which the transaction is registered and for the event class, the
default rounding level is used from the configuration owner tax options.
Select Blank as the rounding precedence
for the event class.

If the rounding level is at the line
level for the configuration tax options, ensure that the registration
record defined for the tax registration party has the rounding rule
based on the tax requirements. The tax registration party is identified
through the Determine Tax Registration tax rule or tax rule defaults.

Rounding Precedence
Hierarchy: How It Is Determined

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving:

Settings That Affect Tax Rounding

Tax precision: The number of decimal
places to which to calculate the tax amount.

Minimum accountable unit: The smallest
currency unit that a tax amount can have.

Rounding level: The transaction level
at which the rounding is to be performed.

Rounding rule: The method that is
used to round off the calculated taxes to the minimum accountable
unit.

Options available for the rounding level are:

Header: Applies rounding to calculated tax amounts once for each tax rate
per invoice.

Line: Applies rounding to the calculated tax amount on each invoice line.

Options available for the rounding rule are:

Up: the amount is rounded to the next highest minimum accountable unit.

Down: The amount is rounded to the next lowest minimum accountable unit.

Nearest: The amount is rounded to the nearest minimum accountable unit.

How Tax Rounding Is Determined

If you did not define configuration owner tax option
settings for the combination of configuration owner and event class,
the rounding process uses the default rounding level of the event
class and the default rounding rule of the tax.

If you defined a rounding precedence hierarchy in
the configuration owner tax option settings for the combination of
configuration owner and event class, the rounding process looks for
a rounding level and rounding rule in this way:

Looks for rounding details in the
party tax profiles of the parties and party sites involved in the
transaction, according to the rounding precedence hierarchy.

If an applicable tax profile is found
then uses the rounding level and rounding rule of the tax profile.

If the rounding level is at the header
level then uses these values to perform the rounding. The process
ends.

If the rounding level is at the line level
then goes to step 6.

If an applicable tax profile is not
found then uses the rounding level setting of the configuration owner
tax option.

If the configuration owner tax option
rounding level is at the header level then uses the rounding rule
that is set at the tax level for each tax of the transaction to perform
the rounding. The process ends.

If the rounding
level is at the line level then goes to step 6.

If the rounding level is at the line
level then:

For each tax line, uses the rounding
rule belonging to the tax registration of the party type derived from
the Determine Tax Registration rule.

If a registration record does not
exist for the registration party type and if you did not define configuration
owner tax option settings for the combination of configuration owner
and event class, then the rounding process uses the rounding rule
that is set at the tax level to perform the rounding. The process
ends.

If a registration record does not
exist for the registration party type and if you defined a rounding
precedence hierarchy in the configuration owner tax option settings
for the combination of configuration owner and event class, then the
rounding process looks for a rounding rule in this way:

Refers to the party or party site
of the first party type defined in the rounding precedence hierarchy.

Uses the rounding rule of the party
or party site tax registration, if defined.

If a tax registration is not defined,
uses the rounding rule of the party or party site account site details,
if defined.

If a rounding rule is not defined,
uses the rounding rule of the party or party site tax profile, if
defined.

If a tax profile is not defined,
repeats the previous substeps for each rounding party in the rounding
precedence hierarchy.

If a rounding rule is found, uses
this rounding rule to perform the rounding. The process ends.

If a rounding rule is not found,
then uses the rounding rule that is set at the tax level to perform
the rounding. The process ends.

Tax Rounding: Examples

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving configuration
owner tax options, event classes, party tax profiles, and taxes. These
examples illustrate how the rounding process works.

Scenario

The following examples represent how the rounding
process determines the tax rounded amount based on transaction, tax
setup, and rounding details.

The transaction and tax setup details for the two
examples are:

Invoice header amount: 5579 USD

Invoice line 1 amount: 1333 USD

Invoice line 2 amount: 1679 USD

Invoice line 3 amount: 2567 USD

Applicable taxes:

State tax, rate percentages of 12.5%,
6.75%, and 3.33%

City tax, rate percentages of 7.5%

The rounding details for the two examples are:

Rounding level: Header

Rounding Rule:

State tax: Up

City tax: Nearest

Tax precision: 2

Minimum accountable unit: 0.01

Example 1 represents the rounding details applied
at the header level. Applying these factors, the rounding process
calculates the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Line amounts truncated per tax precision and
rounding criteria applied at the header level

Step 2: Difference between the header amount and the
sum of the line amounts

Step 3: Apply the difference amount to the maximum
tax line amount

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.81

418.43

0.01

0.02

395.81

418.43

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.62

99.97

166.62

99.97

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.91

125.92

55.91

125.92

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.52

0.01

0.02

173.28

192.54

Example 2 represents the rounding details applied
at the line level. Applying these factors, the rounding process calculates
the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Rounding criteria is applied at the line level

Step 2: Line amounts are added to obtain revised header
amounts

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.82

418.44

395.82

418.44

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.63

99.98

166.63

99.98

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.92

125.93

55.92

125.93

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.53

173.27

192.53

Self-Assessment
of Taxes: Explained

Taxes for purchase transactions are usually
calculated by the supplier and included in the invoice. The responsibility
of collecting and remitting these taxes to the authority lies with
the supplier. However, in certain cases the supplier does not have
presence (nexus) or is not registered in the customer location. Taxes
applicable in such cases, in the customer location, are self assessed
by the purchasing organization. Unlike supplier assessed taxes that
are paid to the supplier, self-assessed taxes are remitted by the
purchasing organization directly to the tax authority.

The key here is that these taxes are to be calculated
on the same invoice, but these should not impact the amount payable
to the supplier, instead it should be accounted for as a tax liability.

The core requirements remain the same, however, the
terminology used for self-assessed taxes vary by tax regime, such
as reverse charges, use taxes, and offset taxes. Reverse charge is
the terminology primarily used in the European Union, use taxes is
the terminology used in the United States, and offset taxes is a alternate
solution to handle self-assessment of taxes and is not used by any
regime.

Oracle Fusion Tax provides the following options to
configure and automate calculation of self-assessed taxes:

Self-assessment

Offset taxes

Reporting-only taxes

Use taxes

Self-Assessment

Taxes need to be self-assessed by the purchasing organization
when the supplier is not registered in the ship-to or bill-to location
of the transaction. This is the recommended approach for defining
and calculating self-assessed taxes. This is driven based on the registration
party used for the transaction.

Registration Party

In the context of a tax applicable to the transaction
it is the party whose registration needs to be considered. The tax
registration party type default is specified for the tax. As most
of the taxes are assessed by the supplier, the default is set to the
ship-from or the bill-from location.

Supplier Tax Registration

You can define tax registration for the supplier,
the supplier site, and for a particular tax regime. If the tax registration
varies by tax or tax jurisdiction, define the registration at a granular
level. If the supplier does not have presence in a specific jurisdiction,
there are two options for configuration. The first is to create a
tax registration record with the registration status as not registered.
The second option is not to define a registration record. If you follow
the second option, when you define the condition set, set the operator
for the Registration determining factor class to Is blank.

Registration Party of the First Party

Similar to the supplier registration, you can define
the tax registration records for a legal reporting unit tax profile.
For the tax registration of the first party select the Set as self-assessment (reverse charge) option.
This option triggers self-assessment of taxes when the registration
party selected for the tax line is that of the first party. Self-assessment
is only applicable for Payables transactions. The option on the first
party registration does not impact Receivables transactions. Create
a tax registration rule to conditionally use the first party registration
when the supplier is not registered. The condition to use for this
tax rule is as follows:

Tax Determining Factor Class

Class Qualifier

Tax Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Equal to

Not Registered

If the registration records are not created for the
suppliers without registration, create the condition set as follows:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Is blank

Offset Taxes

Offset taxes is a backward compatible approach that
is configured to self-assess taxes. Configure offset taxes in addition
to your regular taxes. Offset taxes carry a negative rate and are
calculated in the context of the regular tax. Where offset taxes are
applicable, the application creates two tax lines with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Reporting-Only Taxes

You can identify taxes for reporting purposes only.
When these taxes are applicable to the transactions, records are created
in the tax repository entities. However, invoice distributions are
not created for these taxes. Therefore, there is no impact to the
payable amount, payment amount, and invoice accounting.

Use Taxes

Assigning use taxes to invoices, you create a record
of the taxes you owe to tax authorities. Oracle Fusion Payables does
not create invoice distributions for these taxes. Therefore, there
is not any accounting impact due to these taxes. Payables provides
a Use Tax Liability Report to review and report use taxes.

Use the Use Tax Liability Report to review, report,
and remit use taxes. The report determines the use tax liability by
each use tax code by taking the tax rate you defined for each tax
code and applying it to the sum of each invoice line to which the
tax applies. The report lists in summary or detail the total amount
of tax you owe for each tax code on invoices you enter between two
dates you specify when you submit the report. Oracle Fusion Payables
displays the amount of use tax you owe in the currency in which you
entered an invoice.

Note

Use taxes are defined with the tax type of Use tax. The rest of the configuration is
the same as the other taxes. This feature is only supported for migrated
taxes. You cannot define a new tax with this tax type.

Offset Taxes: How They Are Processed

Offset taxes are a backward compatible approach
that you can configure to self-assess taxes. Configure offset taxes
in addition to the regular taxes. Offset taxes carry a negative rate
and are calculated in the context of the regular tax. Where offset
taxes are applicable, two tax lines are created with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Settings That Affect Offset Taxes

For the offset tax calculation to take effect, do
the following:

Set up offset taxes

Enable offset tax calculation

You must perform these tasks for setting up offset
taxes:

Set up the offset tax, tax status,
and tax rate. Define at least one recovery type lookup to use with
offset taxes.

Create the offset tax and perform
the following:

Use the tax currency of the original
tax.

Select the Set as offset tax option.

Enter a primary recovery type that
you defined for offset taxes.

Set up the tax status for the offset
tax. Do not select the Allow tax rate override option.

Set up a 100% tax recovery rate for
the offset tax using the recovery type that is defined for the offset
tax.

You cannot update the recovery rate on an
offset tax line. The recovery rate is always 100% in order to create
credit entries that match the original tax amounts. When you create
an offset tax, you enter a primary recovery type with a recoverable
rate of 100% and a 100% recovery rate.

Set up the offset tax rate and perform
the following:

Enter a negative rate amount.

Assign the tax recovery rate that
is defined for offset tax.

Do not select the Allow ad hoc tax rate option.

Set up the original tax with the
required configuration to enable the tax. For the tax rate of the
original tax (nonoffset tax), assign the offset tax rate code in the Offset Rate Code field.

Complete the following configuration steps to enable
calculation of offset taxes for a transaction:

Select the Allow offset taxes option on the party tax profile if
offset taxes are to be calculated for the transactions created for
the party. Select this option for the party type chosen in the Offset Tax Basis field for the configuration
owner tax options.

How Offset
Taxes Are Processed

Offset taxes applicable to an invoice are created
with two tax lines entries, one for the tax and one for the offset
tax. The line for the offset tax has the offset option enabled. This
line carries the reference to the original tax line. Two Invoice lines
are created for these taxes, one for each tax.

The amount for the regular tax line is always debited
to the tax expense or recovery account or both, depending on the recoverability
of the tax. The credit is posted to a payables account which is offset
by the negative amount credited to the payables account due to the
offset tax line. The debit of the offset tax line is posted to the
tax liability account and this indicates the liability that the first
party organization has towards the tax authority for the self-assessed
tax.

Tax Line Override

You cannot override offset tax lines. However, you
can update the tax line calculated for the original tax. When you
update the tax rate percentage or amount or when you cancel the tax
line, the corresponding tax line for the offset taxes is updated.

Reporting-Only
Taxes: How They Are Processed

You can identify taxes for reporting purposes
only. When these taxes are applicable to the transactions, records
are created in the tax repository entities. However, invoice distributions
are not created for these taxes. Therefore, this does not impact the
payable amount, payment amount, and invoice accounting.

Settings That Affect Reporting-Only Taxes

You set up reporting-only taxes by selecting the Set tax for reporting purposes only option
for the tax.

How Reporting-Only
Taxes Are Processed

Tax lines for reporting-only taxes have the Reporting Only option enabled. Tax distributions
are not created for these tax lines.

For Oracle Fusion Payables invoices, these lines are
not displayed on the invoice lines. The total of the reporting-only
taxes are displayed in the tax totals region of the invoice.

For Oracle Fusion Receivables transactions, reporting-only
taxes are handled as any other tax. These taxes are considered as
a part of the invoice and are accounted for accordingly.

Tax Line Override

You cannot update the Reporting
Only option on the detail tax lines.

FAQs for Define Taxes

What's the minimum
setup to enable a tax for transactions or simulation?

You can enable a tax for simulation or for
transactions only after you have completed all of the minimum setup.

Minimum setup for a country-level standard tax with
no recovery and always applicable includes:

Entering tax accounts for Tax Expense and Tax
Recoverable or Liability Account. Accounts
you specify at the tax level appear as defaults at the tax rate and
tax recovery rate level.

If you have tax recovery, minimum setup also includes:

Defining a tax recovery rate.

Entering an indirect tax rule default
for Tax Recovery Rate.

If the direct tax rule default for Tax Applicability
is set to Not Applicable, you
must define a determining factor set, condition set, and tax applicability
rule.

Manage Tax Determining Factor Sets and Tax Condition
Sets

Tax Determining
Factor Sets and Condition Sets: Explained

A tax determining factor is an attribute that contributes to the outcome of a tax determination
process, such as a geographical location, tax registration status,
or a fiscal classification. Determining factors are represented in
tax rules as the following concepts:

Determining factor class: Tax determining
factors are categorized into logical groupings called determining
factor classes, such as Accounting or Geography.

Tax class qualifier: Use a class
qualifier with a determining factor class when it is possible to associate
a determining factor class with more than one value on the transaction.
For example, you need to specify which location type, such as ship-to
party, a specific geography level, such as country, is associated
with.

Determining factor name: Each determining
factor class contains one or more determining factor names that constitute
the contents of the class.

The result of a determining factor class, and its
class qualifiers and determining factor names, is a list of available
factors for use with tax conditions. Each tax condition within a tax
condition set must result in a valid value or range of values for
tax determination.

Conceptually, determining factors fall into four groups:
party, product, process, and place. The following figure expands upon
the determining factors within each grouping.

The relationship between the determining factor and
condition sets and the party, product, process, and place is shown
in the following table. The relationship value is a concept to group
tax drivers and not an element in the tax rule definition. The determining
factor, determining factor class, tax class qualifier, determining
factor name, condition set operator, and condition set value are all
components of tax rule setup.

Relationship

Determining Factor

Determining Factor Class

Tax Class Qualifier

Determining Factor Name

Condition Set - Operator

Condition Set - Value

Process

Accounting

Accounting

Line Account

Equal to

Flexible with range of qualifiers and segment or account
values

Process

Document

Document

Document fiscal classification level (1-5) or blank

Document Fiscal Classification

Equal to

Not equal to

Is blank

Is not blank

Document fiscal classification codes of the class
qualifier level or all document fiscal classification codes if there
is not class qualifier

Place

Geography

Geography

Location type which can be one of the following:

Bill from

Bill to

Point of acceptance

Point of origin

Ship from

Ship to

Geography type from Oracle Fusion Trading Community
Model

Equal to

Equal to determining factor

Not equal to

Not equal to determining factor

Range

Is blank

Is not blank

Trading Community Model geography names of the geography
type belonging to the location identified by the class qualifier,
for example, country or state.

If the operator is Equal to determining factor or
Not equal to determining factor then the values are:

Bill from

Bill to

Point of acceptance

Point of origin

Ship from

Ship to

The available values do not include the tax class
qualifier value.

Party

Legal Party Classification

Legal party fiscal classification

First party

Legal activity codes for:

Chile

Colombia

Peru

United Kingdom

Venezuela

Equal to

Not equal to

Is blank

Is not blank

Legal classification codes of the legal classification
activity

Party

Party Fiscal Classification

Party fiscal classification

Location type which can be one of the following:

Bill-from party

Bill-to party

Point of acceptance party

Point of origin party

Ship-from party

Ship-to party

Party fiscal classification type

Equal to

Not equal to

Is blank

Is not blank

Fiscal classification codes of the party fiscal classification
type assigned to the party identified by the class qualifier

Product classification codes of the class qualifier
level or all product fiscal classification codes if there is no class
qualifier

Party

Registration Status

Registration

Location type which can be one of the following:

Bill-from party

Bill-to party

Ship-from party

Ship-to party

Registration Status

Equal to

Equal to determining factor

Not equal to

Not equal to determining factor

Is blank

Is not blank

The registration status defined in the registration
status lookup.

If the operator is Equal to determining factor or
Not equal to determining factor then the values are:

Bill-from party

Bill-to party

Ship-from party

Ship-to party

Process

Transaction Fiscal Classification

Transaction fiscal classification

Transaction fiscal classification type

Equal to

Not equal to

Is blank

Is not blank

Specific transaction fiscal classification code

Process

Transaction Business Category

Transaction generic classification

Classification level (1-5) or blank

Transaction Business Category

Equal to

Not equal to

Transaction business category fiscal classification
codes of the class qualifier level or all fiscal classification codes
if there is no class qualifier

Process

Transaction Type

Transaction generic classification

Classification level (1-5) or blank

Transaction Business Category

Equal to

Not equal to

Transaction business category fiscal classification
codes of the class qualifier level or all fiscal classification codes
if there is no class qualifier

Process

Intended Use

Transaction input factor

Intended Use

Equal to

Not equal to

Is blank

Is not blank

Product intended use fiscal classification codes

Product

Line Class

Transaction input factor

Line Class

Equal to

Not equal to

Is blank

Is not blank

Transaction event classes and activities

Code list of line transaction types such as:

Procure-to-pay

Credit memo order-to-cash

Miscellaneous cash

Process

Product Type

Transaction input factor

Product Type

Equal to

Not equal to

Is blank

Is not blank

Predefined goods or services

Process

Tax Classification Code

Transaction input factor

Tax Classification Code

Equal to

Not equal to

Is blank

Is not blank

Tax classification codes

Process

User-Defined Fiscal Classification

Transaction input factor

User-Defined Fiscal Classification

Equal to

Not equal to

Is blank

Is not blank

User-defined fiscal classification codes

Place

User-Defined Geography

User-defined geography

Location type which can be one of the following:

Bill from

Bill to

Point of acceptance

Point of origin

Ship from

Ship to

Tax zone types

Equal to

Equal to determining factor

Not equal to

Not equal to determining factor

Is blank

Is not blank

Tax zones of the tax zone type belonging to the location
identified by the class qualifier

Tip

Do not mix the interpretation of the party, product,
process, and place and the associated determining factors if possible.
For example, if the information you need to model concerns the geography
associated with the locations on the transaction do not use party
classifications to model this type of requirement.

Tip

Whenever possible, use automatically determined or
derived determining factors, such as party classifications, product
fiscal classifications, or geography instead of using those that are
reliant on information entered at transaction time, such as product
category, intended use, or user-defined fiscal classifications. Those
entering information at transaction time may not be familiar with
the impact this information has on tax determination.

You can use multiple party and product fiscal classifications
at the same time. However, only the primary product fiscal classification,
as defined in the country defaults is displayed on the transaction
line. When you override the product fiscal classification at transaction
time that value is used in preference to the default product fiscal
classification.

Party, Product,
Place, and Process as Determining Factors: Explained

Determining factors are
the key building blocks of the tax rules. They are the variables that are passed at transaction
time derived from information on the transaction or associated with
the transaction. They are used within tax rules logic to determine
the conditions under which specific tax rules are applicable to a
specific transaction.

Conceptually they fall into four groups as shown in
the following figure:

The four groups are described as:

Party: Information about the parties
on or associated with a transaction such as party fiscal classification, tax registration, and tax exemptions.

Product: Information of the types
and classifications of the goods and services on or associated to
items on a transaction.

Place: Information on the addresses
of the locations associated to the party and party locations on the
transaction.

Process: Information on the type
of tax services that are being requested such as purchase invoice
and debit memo.

How Tax Is Determined Using Party, Product, Place,
and Process Transaction Attributes

The following table describes how the party, product,
place, and process transaction attributes contribute to the outcome
of the tax determination process:

Group

Transaction Attributes

Process

Place

Ship from

Ship to

Bill from

Bill to

Point of acceptance

Point of origin

Restrict your tax rules based on the location where
the transaction took place. For example, you may only want to apply
this tax rule to goods that are delivered from an EC country into
the UK.

The tax determination process uses the countries associated
with the transaction to select the tax regimes associated with the
first parties defined for those countries.

The tax determination process also uses the location
on the transaction that corresponds to the location type derived from
the tax rule for the candidate tax or the rule default location type.
It then identifies the tax jurisdiction of the candidate tax to which
the location identified belongs. If the location does not belong to
any tax jurisdiction of this tax, then the tax does not apply to the
transaction.

Party

First party legal entities

Ship from or ship to parties and
bill from or bill to parties

Tax registration and registration
statuses of each party

Type or classification of a party

Restrict your tax rules based on the party of the
transactions. For example, the supplier must be registered in another
EC country for this tax rule to be applied.

The tax determination process determines the first
party of the transaction which is either the legal entity or business
unit. It uses the first party legal entity or business unit to identify
the tax regimes to consider for the transaction. It also identifies
other configuration options, if defined, to use in processing taxes
for the transaction.

The tax determination process also determines the
party whose tax registration is used for each tax on the transaction,
and, if available, derives the tax registration number. If the tax
registration or registrations are identified, the process stamps the
transaction with the tax registration numbers.

Product

Designation of physical goods or
services

Type or classification of a product

Restrict your tax rules to apply to a specific product
in the transaction. The tax determination process then applies these
rules to transactions with those specific attributes. For example,
the product type must be goods for this tax rule to apply.

For each tax, the tax determination process determines
if a product tax exception applies to the transaction. It looks for
an exception rate specific to the inventory item or fiscal classification
of the item and adjusts the rate appropriately.

Process

Procure-to-pay transactions, such
as purchases, prepayments, and requisitions

Order-to-cash transactions, such
as sales, credit memos, and debit memos.

Type of sale or purchase, such as
retail goods, manufactured goods, intellectual property, and resales.

Restrict your tax rules to apply to a specific type
of transaction. The tax determination process then applies these rules
to transactions with those specific attributes. For example, the tax
rule is limited to purchases.

For each tax, the tax determination process determines
if a customer tax exemption applies to an order-to-cash transaction
and updates the tax rate accordingly.

Setting Up
Determining Factor and Condition Sets: Examples

The following scenarios illustrate when you
set up tax determining factor sets and condition sets to meet your
tax requirements.

Scenario

There is a tax requirement for a state tax, Intrastate
A, to apply to any intrastate transactions for a specific product
category of items. When defining this tax the typical transaction
scenario is that this tax is not applicable. So when defining this
tax the tax applicability default value is Not Applicable. Create a tax rule for the exception scenario
when this particular product is sold in an intrastate transaction.

Create the determining factor set as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Geography

Ship from

State

Product noninventory linked

Level 2

Product Category

Create the condition set as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Geography

Ship from

State

Equal to determining factor

Ship to

Product noninventory linked

Level 2

Product Category

Equal to

Product A

Define the set with the result of Applicable. If the conditions defined match the respective
transaction values the tax rule evaluates to true and the tax is considered
applicable. When the conditions are not met and if there are no other
condition sets or tax rules to evaluate the determination process
looks to the default value of Not Applicable as the result and the tax is not calculated.

Scenario

Determining factors represent the and part of the evaluation process. The determination
process evaluates every element of the determining factor class unless
it is set to ignore in the condition set definition. This feature
allows for reusability of determining factor sets with some flexibility
not requiring the use of all determining factors in each tax rule
definition. The condition set is the or condition of a tax rule when there are multiple condition sets defined.

For example, a tax law may indicate that a specific
state tax is applicable to certain products or specific services from
specific vendor types that are considered to have environmental impacts.
Analysis determines there are two separate supplier party classifications
and one product category defined that meet the requirement for applicability.

Create the determining factor set as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Party fiscal classification

Ship from

Party Fiscal Classification Type Code

Product noninventory linked

Level 2

Product Category

Create the condition set 1 as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Party fiscal classification

Ship from

Party Fiscal Classification Type Code

Equal to

Category A

Product noninventory linked

Level 2

Product Category

Equal to

Product A

Create the condition set 2 as follows:

Determining Factor Class

Class Qualifier

Determining Factor Name

Operator

Value

Party fiscal classification

Ship from

Party Fiscal Classification Type Code

Equal to

Category B

Product noninventory linked

Level 2

Product Category

Equal to

Product A

The tax determination process evaluates all of the
determining factors in the determining factor set: party fiscal classification
and product noninventory linked. However, using multiple condition
sets offer an or evaluation to the tax rule. The tax determination
process evaluates either of the following:

Party fiscal classification type
code is equal to category A and product category is equal to product
A

Party fiscal classification type
code is equal to category B and product category is equal to product
A

You define a result for each condition set that is
applied if the condition evaluates to true. Condition sets are numerically
ordered to specify the sequence in which they would need to be evaluated
during rule processing. Optionally, you can disable them for processing
depending on a change in tax law.

Important

It is important to carefully evaluate condition set
order as a change in order can impact the result of a tax rule.

Also, numerically order tax rules defined for a rule
type to specify the sequence in which they are to be evaluated during
the rule processing. The rule order, along with the specific applicability
criteria like event class, defines the rule evaluation sequence for
a rule type.

FAQs for Manage Tax Determining Factor Sets and
Tax Condition Sets

Why are party,
product, place, and process important?

Party, product, place, and process are important
because they are a way of analyzing and identifying the determining
factors used within tax rules for a specific business transaction
tax situation. The tax determination process uses tax rules for handling
tax treatment for specific business situations. By viewing the requirements
of how the tax should be determined the party, product, place, and
process can provide to you a way of abstracting often complex business
requirements so that you can identify the setup to support those requirements.

Define Tax Recovery

Tax Recovery: Explained

Tax recovery, also known as
input tax credit, is the full or partial recovery of tax paid on purchases
by a registered establishment to offset the tax collected from sales
transactions. There are usually many regulations surrounding the details
of tax recovery. For example, in most European countries, tax is fully
recoverable on all purchases except for businesses that only sell
nontaxable supplies, such as financial institutions. In these cases, value-added tax (VAT) on their purchases is not recoverable. In certain countries like
Canada, more than one type of recovery is possible. Tax authorities
designate the tax recovery rates that indicate the extent of recovery
for a specific tax.

Tax recovery on a transaction is determined at the
line or item distribution level. If a tax is nonrecoverable, two tax
distributions are created for each item distribution, a nonrecoverable
tax distribution and a recoverable tax distribution (with zero tax
amount in this case). If a tax is recoverable, an additional recoverable
tax distribution may be created for each item distribution if a secondary
recovery type is applicable.

If the recovery rate on a tax varies based on one
or more transaction factors, set up recovery rate rules to determine
the appropriate recovery rate on the transaction. For example, most
VAT-type taxes allow full recovery of taxes paid on goods and services
that relate to taxable business supplies. In cases where an organization
makes purchases relating to both taxable and exempt supplies, the
tax authority can designate a partial recovery rate to reflect the
proportion that relates to the taxable supplies. For instance, in
the UK, Her Majesty's Revenue and Customs (HMRC) have two methods
to work out the tax recovery rate percentage:

Standard method: Taxable supplies
divided by the value of all supplies added together (both taxable
and exempt). This formula is based on a previous period with an adjustment
when the actual proportions are known.

Special method: A custom formula
approved by HMRC that reflect a business's unique circumstances that
must produce a fair and reasonable result. Approval to use this special
method is based on the business type, the types of supplies, and the
business's cost structure.

The Determine Recovery Rate process evaluates tax
recovery for applicable taxes. The Determine Recovery Rate process
determines the recovery rate to apply to each recovery type for each
applicable tax on the transaction.

Determine Recovery Rate

Tax rules use the tax configuration setup defined
within Oracle Fusion Tax and the details on the transaction to determine
which taxes apply to the transaction and how to calculate the tax
amount for each tax that applies to the transaction.

Tax rules let you create a tax determination model
to reflect the tax regulations of different tax regimes and the tax
requirements of your business. You can create a simple tax model or
a complex tax model. A simple tax model makes use of the default values
without extensive processing while a complex tax model considers each
tax requirement related to a transaction before making the final calculation.

The tax determination process evaluates, in order
of priority, the tax rules that are defined and the details on the
transaction. If the first rule is successfully evaluated, the result
associated with the rule is used. If not, the next rule is evaluated
until either a successful evaluation or default value is found.

The tax determination process is organized into rule
types. Each rule type identifies a particular step in the determination
and calculation of taxes on transactions. The rule type and related
process used for tax recovery determination is Determine Recovery
Rate. This is an optional setup that is applicable to taxes that have
tax recovery enabled.

This process determines the recovery rate to apply
to each recovery type for each applicable tax on the transaction that
allows for full, partial, or no recovery of the tax amount. In many
cases, the tax determination process uses either the recovery rate
associated with the tax rate or the default recovery rate defined
for the tax. However, if the tax recovery rate varies according to
determining factors, such as intended use, then create a Determine
Recovery Rate tax rule to derive the recovery rate.

You can only set up a Determine Recovery Rate tax
rule for taxes that have the tax recovery option enabled. For countries
with more than one type of recovery, use primary and secondary recovery
types to address this requirement. After the recovery rate is determined
for each recovery type, the tax determination process determines the
recoverable amounts against each recovery type for each tax line.
The remaining tax amount becomes the nonrecoverable tax amount for
the tax line.

The following outlines the process that results in
a recoverable tax amount for each recoverable tax distribution:

Allocate tax amount per item distributions.
While taxes are determined at the transaction line level, tax recovery
is determined at the transaction line distribution, or item distribution,
level.

Determine recovery types. The tax
determination process determines for each tax and item distribution,
whether the primary and, if defined, secondary recovery types apply.
The result of this process is a tax distribution for each recovery
type for each tax and item distribution. If recovery types are not
defined, go to step 5.

Determine recovery rates. For each
tax distribution, the tax determination process determines the recovery
rate based on the following:

Consider the Determine Recovery Rate
tax rule for the first recoverable tax distribution.

Use the tax recovery rate derived
from the tax rule.

If the tax determination process
cannot derive a tax rule based on the transaction values, use the
tax recovery rate associated with the tax rate for the tax line.

If there is no tax recovery rate
associated with the tax rate, use the default tax recovery rate for
the recovery type and tax. If there is no default tax recovery rate
for the recovery type and tax, use the default tax recovery rate defined
for the tax.

Repeat the above steps for each recoverable
tax distribution, if applicable.

Determine the recoverable amounts.
The tax determination process applies the recovery rates to the apportioned
tax amounts to determine the recoverable tax amounts. The result of
this process is a recoverable tax amount for each recoverable tax
distribution.

Determine the nonrecoverable amount.
Oracle Fusion Tax calculates the difference between the apportioned
tax amount of every tax line per item distribution and the sum of
the recoverable tax distribution to arrive at the nonrecoverable tax
amount, and then creates a nonrecoverable tax distribution for this
amount. If a primary recovery type was not defined for a tax, the
entire apportioned amount for the item distribution is designated
as the nonrecoverable tax amount.

Tax Recovery: Points to Consider

The tax determination process uses your tax
configuration setup and the details on the transaction to determine
which taxes are recoverable.

You need to decide when to:

Create Determine Recovery Rate rules

Specify separate ledger accounts

Manage tax distributions

Specify settlement options

When to Create Determine Recovery Rate Rules

Use recovery rate rules to determine the applicable
recovery rates when this determination is based on one or more transaction
factors, including the parties, locations, product or product purpose.

At transaction time, the tax determination process
uses the recovery rate derived from the recovery tax rules. If no
recovery rate rules are defined or if no existing recovery rate rule
applies to the transaction, the tax determination process uses the
default recovery rate that you define.

Commonly used factors that are used in tax recovery
rules include:

Intended use, such as resale or manufacturing

Party fiscal classification, such
as reseller or charitable organization

Location, such as British Columbia
or New Brunswick

When to Specify Separate Ledger Accounts

Recovery details are primarily captured and
tracked through invoice distributions. If there is a requirement to
capture the recovery details into separate general ledger accounts
for each tax, define the recovery account at the recovery rate level.
If the recovery and liability can be combined at the account level,
the common account for liability or recovery defined at the tax rate
level can be used.

While generating the invoice distributions, the application
first considers the recovery account defined at the recovery rate
level. If it is null, the liability or recovery account defined at
the tax rate level is used.

The nonrecoverable component of a tax gets registered
into the expense account defined at the tax rate level. If no specific
expense account is given, the item charge account available on the
transaction is used. There may be a need to apportion the nonrecoverable
component of the tax amount on the item cost. As such, you should
consider all of the costing requirements while setting up an expense
account.

When to Manage Tax Distributions

Use the Tax Distributions window to review
and update the tax recovery rate on tax distributions. Oracle Fusion
Tax creates recoverable distributions and calculates tax recovery
rates when you save the line distribution, according to the Determine
Recovery Rate tax rule process or the default recovery rate.

You can update the recovery rate code if the Allow tax recovery rate override option is
enabled for the tax.

You can update the recovery rate if the Allow ad hoc tax rate option is enabled for
the recovery rate. The update method differs according to the transaction
application:

Oracle Fusion Purchasing: You can
either enter a new recovery rate or select another recovery rate that
you previously defined from the list of values.

Oracle Fusion Payables: You can only
select another rate that you previously defined. If you update the
recovery rate on a tax distribution, Oracle Fusion Tax also updates
the related nonrecoverable rate and amount, and the distribution for
the tax line.

If there are tax rules defined based on the Accounting
determining factor class, then changing or creating a distribution
may affect tax calculation.

When to Specify Settlement Options

Tax authorities allow tax recovery at different
stages of a transaction life cycle. You can specify the settlement
options to indicate when tax recovery is possible:

Settlement Option

Purpose

Immediate

Tax recovery is settled after invoice validation.

Deferred

Tax recovery is settled only after the invoice is
paid.

If the recovery settlement is Deferred, you must set up an interim tax account for
this tax to record the tax recoveries or liabilities that accrue prior
to the payment. Though this is an interim account the balance in this
account represents a contingent asset. As such, management and other
reporting requirements need to be duly considered while setting up
or changing this account.

Tax Recovery
Rates Controls and Defaults: Points to Consider

Define tax recovery rates to claim
full or partial recovery of taxes paid. Set up tax recovery rate codes
for the recovery types identified on the taxes within a tax regime.
A tax recovery rate code identifies the percentage of recovery designated
by the tax authority for a specific transaction.

Defining Controls and Defaults for Tax Recovery
Rates

The following table describes the defaults
and controls available at the tax recovery rate level.

Recovery Rate Periods Region

Field

Description

Default Derived from

Default Appears on

Controls

Set as Default Rate

Controls whether this tax recovery rate is the default
recovery rate for this tax at transaction time

None

None

If selected then this recovery tax rate is the default
rate for the period specified. Where there are no tax recovery rate
rules applicable at transaction time then the tax determination process
selects this tax recovery rate.

Recoverable
Taxes: Worked Example

The following example illustrates the tax
setup and associated tax conditions that drive tax recovery. Set up
tax rules to assign specific recovery rates instead of using the default
recovery rates defined for the tax. Two recovery types are used to
show the primary and secondary recovery type options for a tax.

In Canada, the Goods and Services Tax (GST) is a tax
that applies to the supply of most property and services in Canada.
The provinces of British Columbia, Ontario, New Brunswick, Nova Scotia,
and Newfoundland and Labrador, referred to as the participating provinces,
combined their provincial sales tax with the GST to create the Harmonized
Sales Tax (HST). Generally, HST applies to the same base of property
and services as GST. In countries like Canada, some or all of the
taxes on business transactions for registered companies are recoverable
taxes.

ABC Corporation is a business located in the province
of British Columbia. The sales invoice indicates that ABC purchases
books for the purposes of resale. ABC has already created the following
setup:

HST is not recoverable on consumable
items, such as computers for use in ABC's store. Default zero recovery
rates apply in this case.

Perform the following steps:

Create tax recovery rates

Create an intended use fiscal classification

Create recovery rate rules

Create Tax Recovery Rates

For most participating provinces in Canada, the HST
is 13%, out of which 5% is the federal component and 8% is the provincial
component.

Create the tax recovery rates of 38.46% for the federal
component of HST, and 61.54% for the provincial component of HST for
these provinces.

On the Create Tax Recovery Rate page, enter the
name of the tax regime, CA GST and HST.

Select the configuration owner for this tax recovery
rate. To minimize configuration and maintenance costs, select Global
Configuration Owner as the configuration owner.

Select the HST tax, CA HST.

Enter the name of the tax recovery rate you are
defining, such as CA HST STD FED REC RATE.

Select PREC as the recovery type.

In the recovery rate periods table, enter 38.46
as the percentage recovery rate, and an effective start date.

Click Save and Close.

Repeat steps 1 to 7 to create the tax recovery rate
CA HST STD PROV REC RATE, with a recovery type of SREC, and a percentage
recovery rate of 61.54%.

For British Columbia, where the HST rate is 12%, you
need one federal recovery rate to address the 5% federal component
and one provincial recovery rate to address the 7% provincial component.
Create a tax recovery rate of 41.67% for the federal component of
HST, and a tax recovery rate of 58.33% for the provincial component
of HST for British Columbia.

On the Create Tax Recovery Rate page, enter the
name of the tax regime, CA GST and HST.

Select the configuration owner for this tax recovery
rate. To minimize configuration and maintenance costs, select Global
Configuration Owner as the configuration owner.

Select the HST tax, CA HST.

Enter the name of the tax recovery rate you are
creating, such as CA HST BC FED REC RATE.

Select PREC as the recovery type.

In the recovery rate periods table, enter 41.67
as the percentage recovery rate, and an effective start date.

Click Save and Close.

Repeat steps 1 to 7 to create the tax recovery rate
CA HST BC PROV REC RATE, with a recovery type of SREC, and a percentage
recovery rate of 58.33%.

Create Intended Use Fiscal Classification

Create an intended use fiscal classification for Resale.
An intended use fiscal classification is a tax classification based
on the purpose for which the product is used.

In the Create Fiscal Classification Code window
of the Manage Intended Use Classification page, enter a code for the
classification, such as CA INTENDED USE RESALE.

Enter a name for this classification, such as CA
Intended Use Resale.

Optionally, select Canada as the country and enter
a start date, such as 1/01/2001.

Click Save and Close.

Create Recovery Rate Rules

Create the recovery rate rules that apply for most
participating provinces when the conditions for HST recovery are met.
Recall that by default, tax recovery on HST is 0% at the federal and
provincial levels.

In the Create Determine Recovery Rate Rule page,
select Global Configuration Owner as the configuration owner, CA GST
and HST as the tax regime, and CA HST as the tax.

Enter the code and name of the tax recovery rate
rule you are creating, such CA HST FED RECOVERY RULE, the start date,
and a recovery type code of PREC.

Create or select a tax determining factor set and
an associated tax condition set whereby the intended use of the acquired
product is the intended use fiscal classification you defined earlier,
namely CA INTENDED USE RESALE.

When this condition is met, 100% recovery rate for
the federal component is applicable.

For the tax condition set, assign the result of
CA HST STD FED REC RATE.

Assign a rule order, such as 100.

Click Save and Close.

Repeat steps 1 to 6 to create CA HST PROV RECOVERY
RULE for the standard provincial recovery rule, with a recovery type
code of SREC, a result of CA HST STD PROV REC RATE, and a rule order
of 110.

Create the recovery rate rules that apply for British
Columbia when the conditions for HST recovery are met.

In the Create Determine Recovery Rate Rule page,
select Global Configuration Owner as the configuration owner, CA GST
and HST as the tax regime, and CA HST as the tax.

Enter the code and name of the tax recovery rate
rule you are creating, such CA HST BC FED RECOVERY RULE, the start
date, and a recovery type code of PREC.

Create or select a tax determining factor set and
an associated tax condition set whereby the ship-to location is British
Columbia and the intended use of the acquired product is the intended
use fiscal classification you defined earlier, CA INTENDED USE RESALE.

When this condition is met, 100% recovery rate for
the federal component is applicable.

For the tax condition set, assign the result of
CA HST BC FED REC RATE.

Assign a rule order, such as 50, that gives a higher
priority to this rule than the 2 rules you created previously.

Click Save and Close.

Repeat steps 1 to 6 to create CA HST BC PROV RECOVERY
RULE for British Columbia's provincial recovery rule, with a recovery
type code of SREC, a result of CA HST BC PROV REC RATE, and a rule
order of 55.

For ABC's transactions in Canada, the following is
determined by the previous setup:

HST tax is applicable and is calculated
at a percentage rate of 13% for most participating provinces, and
a percentage rate of 12% in British Columbia.

The intended resale of these books
makes these transactions eligible for 100% tax recovery.

For most participating provinces,
tax recovery is calculated at a federal percentage rate of 38.46%
and a provincial rate of 61.54%.

For British Columbia, tax recovery
is calculated at a federal percentage rate of 41.67% and a provincial
rate of 58.33%.

Tax Recovery
Distributions: Explained

A recoverable tax is a tax that allows full
or partial recovery of taxes paid on purchases, either as a recoverable
payment or as a balance against taxes owed. A tax recovery rate identifies
the percentage of recovery for a tax designated by the tax authority
for a specific transaction line. You can review Oracle Fusion Payables
tax distributions and, if applicable, update the tax recovery rate
on a tax distribution depending on your tax setup and security access.
The component in Oracle Fusion Purchasing is view-only.

Managing Tax Recovery Distributions

Oracle Fusion Tax creates recoverable distributions
and calculates tax recovery rates when you save the line distribution,
according to the Determine Recovery Rate tax rule process or the default
recovery rate. If self-assessment is enabled for the applicable party,
two distributions for each tax are created, one with a positive amount
and the other with a negative amount.

One recoverable distribution for the primary recovery
type and, if applicable, the secondary recovery type is created, for
each tax line for each of the item distributions into which the item
line or expense line is distributed. The tax distributions are displayed
in this way:

If the tax is nonrecoverable, one nonrecoverable
tax distribution line for the tax is created, with the nonrecoverable
amount equal to the tax amount. You cannot update a nonrecoverable
tax distribution nor create a manual recoverable distribution.

If the tax is recoverable, two or three
distribution lines are displayed, one for the primary recoverable
amount, one for the secondary recoverable amount, if applicable, and
another for the nonrecoverable amount.

If the tax
is fully recoverable, then the recoverable distribution amount is
equal to the tax amount and the nonrecoverable distribution amount
is equal to zero.

If the tax is recoverable and the recovery rate is
zero, then the nonrecoverable distribution amount is equal to the
tax amount and the recoverable distribution amount is equal to zero.

If self-assessment is enabled for
the applicable party, the application creates two distributions for
each tax, one with a positive amount and the other with a negative
amount.

If the tax applied on the transaction is
self-assessed, then the corresponding recoverable and nonrecoverable
tax distributions are not visible in the distributions window, but
the application does generate them at the time of accounting for the
invoice

If the tax applied on the transaction
is of the offset type, then the application creates two distributions
for the recovery and nonrecovery portions of the tax. Since they are
intended to offset each other, they are created for the same amount,
but one with a positive value and the other with a negative value.

In a Payables transaction you can update the recovery
rate code if the Allow tax recovery rate override option is enabled for the tax. You can update the recovery rate
if the Allow ad hoc tax rate option
is enabled for the recovery rate.

If you update the recovery rate on a tax distribution,
Oracle Fusion Tax also updates the related nonrecoverable rate and
amount, and the distribution for the tax line. If the distribution
status is frozen, you cannot update the tax distribution. In order
to change the distribution, you must reverse the tax distribution
and enter a new distribution.

If applicable, accounting-related setups may affect
tax calculation:

If there are tax rules defined based
on the Accounting determining factor class, then changing or creating
a distribution may affect tax calculation.

If the Enforce
tax from account option is enabled for the configuration
owner and event class, this may affect the tax calculation based on
the distribution.

Tax Recovery
Distributions: Example

Recoverable distributions are created and tax
recovery rates are calculated when you save the line distribution,
according to the Determine Recovery Rate tax rule process or the default
recovery rate. You can review tax distributions and, if applicable,
update the tax recovery rate on a tax distribution.

Note

The authorized user can update the tax recovery rate
on the distribution in Oracle Fusion Payables. The component in Oracle
Fusion Purchasing is view-only.

Scenario

Your company is located in a Canadian province that
has combined the provincial sales tax with the federal goods and services
tax (GST) into a harmonized sales tax (HST). They recently purchased
books to sell in their stores. They also purchased some computers
to use in kiosks within the stores for customers to use to locate
books.

Transaction Details

The transaction details are as follows:

Total cost of books is 10,000 CAD

The invoice indicates the intended use as Resale.

Total cost of computers is 5,000 CAD

The computers will be expensed as they do not meet
the capitalization threshold.

Tax rate applicable to each item is
13%

Analysis

In most tax regimes, a tax that is paid by a registered
establishment can claim back 100% of taxes due from the tax authority,
except for specific designated purchases. Depending upon the details
of a company's business purchases and tax authority regulations, a
number of exception regulations may accompany the details of tax recovery.
Tax implications are:

Cost of books to be sold in stores
is 100% recoverable. Therefore, 1,300 CAD is recoverable (10,000 CAD
* 13%).

Cost of the computers to be used in
kiosks within the stores is not recoverable. Therefore, 650 CAD is
nonrecoverable (5,000 CAD * 13%).

The HST tax configuration specifies that the recovery
tax rate for zero 0% recoverable is used as a default. A tax rule
is defined to apply a 100% recoverable rate for products with an intended
use of Resale.

Tax Recovery Distributions

Based on the analysis, the following distributions
are created for the transaction:

Accounting Class

Debit

Credit

Item Expense

10,000

Item Expense

5,000

Recoverable Tax

1,300

Nonrecoverable Tax

650

Liability

10,000

Liability

5,000

Liability

1,300

Liability

650

Define Tax Statuses

Tax Status
Controls and Defaults: Points to Consider

Set up tax statuses that you need for each
tax that you create for a combination of tax regime, tax, and configuration
owner. You define a tax status under a tax and a configuration owner,
and define all applicable tax rates and their effective periods under
the tax status. The tax status controls the defaulting of values to
its tax rates.

Defining Controls and Defaults

The following table describes the defaults
and controls available at the tax status level.

Header Region

Field

Description

Default Derived from

Default Appears on

Controls

Set as default tax status

Controls whether this tax status is defined as the
default tax status for this tax

None

None

If selected then this tax status is defined as the
default tax status for this tax. Where no tax status rules are applicable
then the tax determination process selects this tax status as the
applicable tax status for transactions in the date range defined.

Tax Information Region

Field

Description

Default Derived from

Default Appears on

Controls

Default Settlement Option

Lookup code to indicate whether an input tax is recovered
when an invoice is recorded or only when the invoice is paid and whether
an output tax is due for settlement when the invoice is issued or
only when the payment is received against it

Tax

Tax rate

None

Allow tax exceptions

Controls whether tax exceptions are allowed for this
tax

Tax

Tax rate

None

Allow tax exemptions

Controls whether tax exemptions are allowed for this
tax

Tax

Tax rate

None

Allow tax rate override

Controls whether you can override the tax rate at
transaction time

None

Tax rate

None

Define Tax Rates

Define Tax
Rates: Overview

The tax determination process identifies the
applicable tax rate when taxes are considered applicable to a transaction. Tax rates
can apply to a specific location or jurisdiction, for example, you
define state, county, and city jurisdiction-based rates for a US Sales
and Use Tax regime. Tax rates can change over time, for example when
a tax rate increase occurs, you end date one rate period definition
and create a new rate period with an effective start date. There can
be tax exceptions or exemptions to tax rates based on specific items, third parties, general ledger
accounts, or other factors. You must set up tax rates for tax statuses and optionally
for tax jurisdictions. For tax statuses, set up tax rate records for each applicable tax
rate that a tax status identifies. For tax jurisdictions, set up tax
rate records to identify the tax rate variations for a specified tax
and tax status within different tax jurisdictions. Set up your tax
rates in the Define Tax Rates activity.

The tax rate determination process can be viewed as
a two step process:

Item or product fiscal classification
exceptions using special rates, discounts, or surcharges

Third party and third party site
tax exemptions using special rates and full or partial exemptions

Tax Rate Setup: Explained

Consider the applicable tax statuses and optionally
tax jurisdictions when defining the tax rate setup to determine applicable
tax rates on a transaction.

Tax Statuses

A tax status is the taxable nature of a product in
the context of a transaction and a specific tax on the transaction.
You define a tax status to group one or more tax rates that are of
the same or similar nature. Each tax must have at least one status
defined and one status assigned as a default. Create tax rules to
set alternate values as required.

For example, one tax can have separate tax statuses
for standard and manually entered tax rates.

Tax Jurisdictions

A Tax jurisdiction is an incidence of a tax on a specific
geographical area. A tax jurisdiction is limited by a geographical
boundary that encloses a contiguous political or administrative area,
most commonly the borders of a country. Often this is represented
by a state, province, city, county, or even a tax zone. In Oracle
Fusion Tax, a tax jurisdiction can use the geography setup from your
Trading Community Architecture geography hierarchy to identify a tax
rate. Taxes such as Canada's Harmonize Sales Tax (HST) and Provincial
Sales Tax may require tax rates at the jurisdiction level.

For example, US Sales and Use Tax are applicable based
upon the jurisdictions you generally define for state, county, and
city geographies.

Tax Rates

You must set up at least one tax rate for each tax
status. You may need to set up additional tax rates at the tax jurisdiction
level if the tax rate applicable for the tax is unique for a particular
tax jurisdiction.

For example, in Canada, HST is applied at a 13% rate
in most provinces that have adopted HST except for British Columbia
where the tax rate is 12% and Nova Scotia where the tax rate is 15%.
To satisfy this requirement define a single tax rate of 13% with no
tax jurisdiction associated and define 12% and 15% tax rates and associate
them with the British Columbia and Nova Scotia jurisdictions respectively.
This minimizes setup by creating an exception-based setup and a default
option for the most commonly utilized tax rate percentage.

Tax Rate Types

You can express tax rates in terms of percentage or
quantity. A quantity-based tax rate is based upon the number of items
purchased or events that occur. For example, a taxing jurisdiction
passes a law that each package of cigarettes sold is subject to a
tax of 0.87 USD. This tax is considered a quantity-based tax as it
is assessed based upon the number of packages purchased not the price
of the product.

Tax Classification Code Set Assignments

When defining a tax rate select the tax classification
code set assignments of Order to cash, Procure to pay, and Expenses. These assignments determine if
the tax rate code you define is applicable within a specific product
and set assignment at transaction time. In addition the set assignment
of tax classification codes is derived based on the configuration
owner that is part of the tax rate code definition.

When you create a tax rate code where the:

Configuration owner is the global
configuration owner: The tax classification code is assigned to all
sets that have the determinant type of business unit and contain the
determinant value of the business units that have the subscription
of the legal entity. The tax classification code is also assigned
to the business units that do not have the subscription of the legal
entity but subscribe to the global configuration owner data for this
tax regime.

Configuration owner is the legal
entity: The tax classification code is assigned to all sets that have
the determinant type of business unit and contain the determinant
value of the business units that use the subscription of legal entity.
The tax classification code is also assigned to business units that
subscribe to this specific legal entity as party first party organization.

Configuration owner is the business
unit: The tax classification code is assigned to all sets that have
the determinant type of business unit and contain the determinant
value of the business unit for which the content is created.

Note

The application does not assign the tax classification
codes to the global set of COMMON for any of these scenarios.

You can use the tax classification codes created as
determining factors when defining tax rules. When you use the regime
determination method of standard tax classification code,
the tax classification based direct rate rules can be defined with
these codes as factors for direct rate determination. Maintain the
tax classification codes using the associated lookup types of Party Tax Profile Input Tax Classification, Party Tax Profile Output Tax Classification, and Party Tax Profile Web Expense Tax Classifications.

Rate Periods

You can define one or more rate periods for a tax
rate as long as the date ranges do not overlap. This allows for a
change in tax rates over time without requiring a new tax rate code
definition. You can define default effective periods for tax rate
periods. This effectivity must be unique across tax regime, configuration
owner, tax, and tax status. This allows flexibility if there is a
requirement to define a new tax rate code and identify the new rate
period as a default when existing rate periods exist on another tax
rate code. Define tax rules as exceptions to default tax rates.

Tax Recovery

When the associated tax allows tax recovery you can
define tax recovery or offset tax rates. Associate the offset tax
or the default tax recovery rate and tax rule defined for tax recovery
to the tax rate code. If the tax rule does not evaluate to true at
transaction time then the default tax recovery rate is applicable.
Ensure that the tax recovery rate and tax rate periods overlap or
the application does not calculate tax recovery.

Tax Accounts

Define tax accounting for the tax rate code either
as a default from the tax setup or an override of values at the tax
rate level. Tax accounts are defined for the legal entity and optionally
for the business unit. The accounts you define are tax expense accounts,
tax revenue accounts, tax finance charge accounts, and accounts specific
to tax recovery.

Setting Up
Tax Rates: Choices to Consider

Set up tax rates for your tax statuses and tax jurisdictions. For tax statuses,
set up a tax rate record for each applicable tax rate that a tax status
identifies. For tax jurisdictions, set up tax rate records to identify
the tax rate variations for a specific tax within different tax jurisdictions.
For example, a city sales tax for a state or province may contain
separate city tax jurisdictions, each with a specific rate for the
same tax.

At transaction time, you can override tax rates on
calculated tax lines depending on your setup.

Quantity-Based Tax Rates

You can define tax rates as a percentage or
as a value per unit of measure. The UOM field is optional in the tax setup. However, if you do enter the
UOM there is validation that must be passed in order for the tax rate
to be applied. This includes:

If the UOM exists on the tax rate,
the transaction must have a matching UOM or a blank UOM.

Only one active tax rate can exist
for any given tax rate period. You cannot create one tax rate for
each UOM that might be used within a single tax rate code.

You can define the quantity rate type for a tax rate
code with the UOM field left as
blank. At transaction time, the application multiplies the quantity
by the tax rate and the UOM is not taken into account.

Override of Tax Rates on Tax Lines

Part of the configuration options is to allow
you to override the calculated tax rate on a tax line. The following
controls should be considered during setup:

Allow override
of calculated tax lines: This option exists on the Create
Configuration Owner Tax Options page for the configuration owner and
event class. In order for you to manually override tax lines this
option must selected for the combination of configuration owner and
event class. If a configuration owner tax option does not exist the
value on the predefined event class setting is used.

Allow override
of calculated tax lines: You must select this option on
the associated tax record to be able to override values on a calculated
tax line.

Allow tax
rate override: You must select this option on the associated
tax status record to be able to override tax rates on a calculated
tax line.

Allow ad
hoc tax rate: You must select this option on the tax rate
record if you want to allow the flexibility of not being restricted
to predefined tax rates and allow user entered rates on calculated
tax lines.

If you allow ad hoc tax rates you must
indicate if the adjustment to a tax amount updates the taxable basis
or the tax rate.

Note

You can set the Transaction
Tax Line Override profile option to control which users
can make changes to the transaction line such as selecting a different
tax status or tax rate.

Tax Rates Controls and Defaults: Points to Consider

Set up tax rates for your tax statuses and optionally for tax jurisdictions.
For tax statuses, set up a tax rate record for each applicable tax
rate that a tax status identifies. For tax jurisdictions, optionally
set up tax rate records to identify the tax rate variations for a
specific tax within different tax jurisdictions.

Defining Controls and Defaults for Tax Rates

The following table describes the defaults
and controls available at the tax rate level.

Header Region

Field

Description

Default Derived from

Default Appears on

Controls

Tax Rate Type

Lookup code that controls the type of tax rate. Values
are:

Percentage: The tax rate is a percentage based on the line value

Quantity: The tax rate is based on the currency per UOM such as USD per kilo

None

None

Defines whether the tax rate is either percentage
or quantity based

Tax Classification Code Set Assignments

Order to cash

Procure to pay

Expenses

Controls where tax classification codes that are created
in parallel to the creation of the tax rate are available for use

None

None

If selected then the tax classification code associated
with this tax rate is available for use in order to cash, procure
to pay, and expenses transactions

Rate Periods Region

Field

Description

Default Derived from

Default Appears on

Controls

Set as Default Rate

Controls whether this tax rate is the default rate
for the defined tax status for the period specified

None

None

If selected then this tax rate is the default tax
rate for the defined tax status for the period specified. Where there
are no tax rate rules applicable at transaction time then the tax
determination process selects this tax rate where the associated tax
status is derived during the period specified.

Main Details Tab, Other Details Region

Field

Description

Default Derived from

Default Appears on

Controls

Tax Inclusion Method

Defines whether the tax is:

Standard
noninclusive handling: This option calculates the taxes
as exclusive of the given transaction line amount

Standard
inclusive handling: This option calculates the taxes as
inclusive of the given transaction line amount

Special inclusive
handling: This option calculates the taxes as inclusive
of the given transaction line amount, but the calculation methodology
differs from the standard inclusive process

None

None

Use this option in conjunction with other setup on
tax, party tax profile, tax registration, and transaction details
to control the inclusiveness of a line amount at transaction time

Allow override and entry of inclusive tax lines

Controls whether you can override and enter inclusive
or exclusive line amounts

Tax

None

Use this option in conjunction with the Transaction
Tax Line Override profile option as well as Allow override of calculated tax lines and Allow override and entry of inclusive tax lines options for the configuration owner tax options to allow you to
update the Inclusive option on tax line at transaction time

Allow tax exceptions

Controls whether tax exceptions are allowed for this
tax

Tax status

None

If this option is selected tax exceptions can be processed
at transaction time

Allow tax exemptions

Controls whether tax exemptions are allowed for this
tax

Tax status

None

Use this option in conjunction with the Allow exemptions option on the configuration
owner tax options and when both are selected allows tax exemptions
to be processed at transaction time

Allow ad hoc tax rate

Controls whether you can enter ad hoc tax rates at
transaction time

None

None

Use this option in conjunction with Transaction Tax
Line Override profile option and the Allow
override of calculated tax lines option for the configuration
owner tax options. If all are selected allows you to enter tax rates.

Adjustment for Ad Hoc Tax Amounts

Lookup code that is used when you select the Allow ad hoc tax rate option

None

None

When the Allow ad hoc tax
rate option is selected the lookup value in this field
controls how the application controls the change in tax value, either
as a change to the taxable basis or to the tax rate value used

Default Settlement Option

Lookup code to indicate whether an input tax is recovered
when an invoice is recorded or only when the invoice is paid and whether
an output tax is due for settlement when the invoice is issued or
only when the payment is received against it

Tax status

None

Defines whether the settlement is immediate, for example,
at invoice time, or deferred, for example, at payment time

Tax Rates for
a Canadian Tax Regime: Examples

The following scenarios illustrate when you
might want to use exceptions or tax rules to meet your Canadian tax
requirements.

Scenario

The first scenario includes tax calculation for a
Canadian tax regime. Purchases made in Ontario are generally taxed
for Provincial Sales Tax (PST) at a tax rate of 8%. Accommodation
purchases are generally taxed at 5% and food is generally exempt from
tax.

EDC Corporation's Ontario store has been invoiced
for employee accommodations, including hotel facilitates and food
for a conference they attended. The invoice is for a hotel room, use
of hotel office facilities, and food.

Set up tax rates to meet PST requirements for the
store in Ontario as follows:

Define a jurisdiction-based tax rate
of 8% which is applicable to the hotel facilities usage. This is the
standard tax calculation for the jurisdiction of Ontario.

Define a rate exception with a special
rate of 5% for the hotel room. This exception can be driven by a product
fiscal classification.

Define a Determine Tax Status rule
which points to the exempt status of 0% rate for food based on a product
fiscal classification. Use the tax rule over an exception since you
can use a specific tax status and the default rate of 0% for that
tax status.

Scenario

Another example of tax calculation for a Canadian
tax regime is purchases of some items made on First Nation reserves
have a First Nations Tax that is applicable at a tax rate of 5%.
Since the requirements drive the applicability of the tax as well
as the tax status and tax rate you can define a direct rate rule to
handle both the applicability and the tax rate.

Manage Tax Exceptions

Tax Exception on a Transaction Line: How
Tax Is Calculated

Set up tax exceptions to apply special tax
rates to products. At transaction time, Oracle Fusion Tax determines
whether the tax exception applies to the transaction line for the
product, and if so, uses the applicable exception rate.

Settings That Affect Tax Exceptions

A tax exception must belong to a combination of tax
regime, configuration owner, and tax. You can also assign tax exceptions
to a tax status or tax rate belonging to the tax or to a tax jurisdiction.

You can define Oracle Fusion Inventory organization
tax exceptions for items, or you can define tax exceptions for Inventory-based
product fiscal classifications or noninventory-based product categories.
If you are using Inventory-based product fiscal classifications then
generally, the application classifies the transaction line based on
the item. If you are using noninventory-based product category fiscal
classifications you enter the appropriate product category on all
applicable lines to influence the tax result. Product categories and
product fiscal classifications are defined in a hierarchical structure.
It is important that you select the appropriate level where the tax
exception is applicable. For product fiscal classifications to be
used in item exceptions, you must indicate that it is used in item
exceptions at the tax regime association to the product fiscal classification.
You can set up only one product fiscal classification for any specific
tax regime with the Used in Item Exceptions option selected.

When you set up configuration options for first party
legal entities and business units, you can set a separate configuration
option for the owning and sharing of product tax exceptions for a
combination of party and tax regime.

The Allow tax exceptions option is set at the tax regime level and you can override it at
the tax and tax status levels. However, the setup you define for the
tax rate is what is evaluated during tax rate determination.

At transaction time, the tax exception is used if
the details of the transaction and the tax match all of the entities
assigned to the tax exception. Only one tax exception can apply to
a transaction line for a specific tax.

Note

Tax exemptions are specific to the order-to-cash event
class while tax exceptions are applicable across event classes.

How Tax Exceptions Are Calculated

The tax determination process determines tax applicability,
tax status, and the tax rate for the transaction line. If tax exceptions
are allowed, the application looks at the item entered on the transaction
line to determine if an exception is defined at the tax, tax status,
tax rate, tax jurisdiction, Inventory organization, or Inventory level
and uses the exception at the most specific level.

If the application does not find any tax exception
for the item, it looks for a product fiscal classification associated
with the transaction line. If one exists, the application determines
if an exception is defined at the tax, tax status, tax rate, tax jurisdiction,
and product fiscal classification level and uses the exception at
the most specific level with the highest precedence.

The tax rate is then based on the exception type and
calculated as follows:

Discount: A reduction of the base tax
rate. For example, if the discount is 15% off the standard rate and
the standard rate is 10%, then the discount rate is 85% of the original
10%, or 8.5%.

Surcharge: An increase to the base
tax rate. For example, if the surcharge is 10% and the standard rate
is 10%, then the surcharge rate is 110% of the original 10%, or 11%.

Special Rate: A rate that replaces
the base tax rate. For example, if the special rate is 5% and the
standard rate is 10%, the tax rate is the special rate of 5%.

Finally, the new tax rate is applied to the taxable
basis and the tax amount is calculated.

For manual tax lines, no additional processing is
performed and exceptions are not considered. A manual tax lines suggests
that you have specific business requirements for a particular transaction
to apply a manual tax. No additional processing is performed for manual
tax lines to avoid any applying conflicting or inconsistent values
to the user-entered tax line. The tax calculation on a manual tax
line is the standard formula of: tax amount is equal to the taxable
basis multiplied by the tax rate.

Define Tax Rules

Tax Determination: Explained

Taxes are levied on transactions as per the
legislations in a country or region. They are seldom uniformly applied
on all transactions and tax legislation may seek differential levy,
treatment, and administration of taxes based on various transaction
attributes. Configure Oracle Fusion Tax to evaluate transactions based
on transaction attributes to determine which taxes apply to a transaction
and how to calculate tax amount for each tax that applies to the transaction.

The tax determination process evaluates transaction
header and line information to derive tax lines for taxes applicable
to the transactions. The evaluation process is subdivided into the
following processes:

Determine Applicable Tax Regimes
and Candidate Taxes

Determine Place of Supply and Tax
Jurisdiction

Determine Tax Applicability

Determine Tax Registration

Determine Tax Status

Determine Tax Rate

Determine Taxable Basis

Determine Tax Calculation

Determine Tax Recovery

The tax determination process utilizes the tax foundation
configuration in conjunction with configuration options and tax rules
to process transactions for tax applicability and calculation. Tax
configuration ranges from simple models that make use of default values
without extensive processing to complex models that consider each
tax requirement related to a transaction before making the final calculation.

When setting up a tax examine the regulations that
govern the determination of the tax amount, from identifying applicability
drivers to how the tax is calculated. Organize the regulations into
one or more rule types for each tax. When the regulations indicate
that more than one result is possible for a given rule type, then
you need to define rules within that rule type. Otherwise you can
defer to a default value for that rule type associated to the tax.

The complexity of setup can be classified as follows:

No tax rules required: Oracle Fusion
Tax uses the default tax status, tax rate, and tax recovery rate defined
for the tax. Tax rules are not required but tax rates can vary by
class of products set up using tax exceptions, location set up using
tax jurisdictions, and party set up using exemption definitions. In
addition, applicability can still be controlled without the use of
tax rules such as through the party tax profile that you define for
a supplier.

Simple tax rule regimes: The tax
authority levies tax on your transactions at the same rate, with a
simple set of identifiable exceptions. The exceptions either apply
to one part of the transaction only, such as to certain parties, or
to a combination of parties, products, and transaction processes that
you can summarize in a simple way. In such cases, use a simple set
of tax rules, for example, to identify place of supply and tax registration,
and use default values for other processes.

Complex tax regimes: Tax regimes
in certain countries require a complex logic to determine the applicable
taxes and rates on a transaction. Both tax applicability and tax rates
can vary, for example, by place of origin and place of destination,
party registration, status, service, or a combination of factors.
In some cases, the taxable amount of one tax may depend upon the amount
of another tax on the same transaction. And in rare cases, the tax
amount itself may depend on the tax amount of another tax. For all
of these and similar situations, you set up tax rules to define the
logic necessary to identify each step of the tax determination process.

Tax Determination Steps

The first step of the determination process is to
identify the first party of the transaction. The tax determination
process looks to the business unit on the transaction and identifies
whether it is pointing to the configuration owner of the business
unit or legal entity depending on the Use
subscription of the legal entity option on the party tax
profile definition of the business unit. The tax determination process
checks to determine if there are configuration owner tax options associated
to this party or if the predefined event class option should be used.

The Determine Applicable Tax Regimes process can be
the predefined TAXREGIME, STCC (standard tax classification code),
or another regime determination set that is user-defined. TAXREGIME
or user-defined regime determination sets derive the applicable tax
regimes or tax regime through country or zone of the location identified
in the processing of the regime determination determining factor set
location values. STCC determination is typically used for purposes
of migrated data and has a different processing logic driven by tax
classification code. A third option of determination is third party
integration.

Determine Applicable Tax Regimes and Candidate Taxes

Tax regimes are considered based on geography and
subscription. Either a country or zone associated to the tax regime
definition must be the same as the country or zone identified via
the location that evaluates to true on the regime determination set
of the first party of the transaction. In addition, the tax regime
must have a subscription to the applicable configuration owner. Once
the tax determination process identifies the tax regimes the list
of candidate taxes can be evaluated based on the configuration option
setting of the first party in the tax regime subscription definition:

Common Configuration: Consider all
taxes with the configuration owner of global configuration owner.

Party Specific Configuration: Consider
all taxes with the first party as configuration owner.

Common Configuration with Party Overrides:
Consider all taxes with the first party and the global configuration
owner as configuration owner. If a tax is defined by both the first
party and the global configuration owner, then the application only
uses the tax defined by the first party.

Parent First Party Configuration
with Party Overrides: Consider all taxes with the first party and
the parent first party as configuration owner. If a tax is defined
by the first party and the parent first party then the application
only uses the tax defined by the first party.

Determine Tax Applicability and Place of Supply and
Tax Jurisdiction

This process determines the tax applicability of each
candidate tax based on direct rate determination, place of supply,
tax applicability, and tax jurisdiction. The first step in tax applicability
is to process any direct rate rules defined for a tax regime, configuration
owner, and candidate taxes. If a direct rate rule evaluates to true
then place of supply is processed for this transaction tax. If successful
the tax is applicable and the tax status and tax rate defined for
the direct rate rule are used in the tax calculation. If a direct
rate rule does not evaluate to true for this tax regime, configuration
owner, and tax the tax applicability rules are processed next. After
a tax is found applicable based on an applicability rule or a default
value the process verifies the place of supply and associated tax
jurisdiction. This is required except in the cases of migrated taxes.

The place of supply process identifies the applicable
location type and associated tax jurisdiction where the supply of
goods or services is deemed to have taken place for a specific tax.
If the tax determination process cannot find a tax jurisdiction for
the location that corresponds to the place of supply location type,
then the tax does not apply and it is removed as a candidate tax for
the transaction.

For example, the place of supply for UK value-added tax (VAT) on goods is generally the ship-from country. Thus, the place of
supply of a sale or purchase within the UK is the UK itself. However,
if a UK legal entity supplies goods from its French warehouse to a
German customer, then the place of supply will not find a jurisdiction
for UK VAT in France, and therefore UK VAT does not apply.

Determine Tax Registration

This process determines the party whose tax registration
is used for each tax on the transaction, and, if available, derives
the tax registration number.

Determine Tax Status

This process determines the tax status of each applicable
tax on the transaction. If the process cannot find a tax status for
an applicable tax, then Tax raises an error.

Determine Tax Rate

This process determines the tax rate code for each
tax and tax status derived from the previous process. First the application
looks for a rate based on rate code and tax jurisdiction. If this
is not found then the application looks for a rate with no tax jurisdiction.
If applicable, the tax rate is then modified by any exception rate
or tax exemption that applies. The result of this process is a tax
rate code and tax rate for each applicable tax.

Determine Taxable Basis

This process determines the taxable base for each
tax rate code. Depending on the tax rate type the taxable basis is
amount based or quantity based. The tax determination process typically
determines the tax by applying the tax rate to the taxable base amount.
In some cases, the taxable basis either can include another tax or
is based on the tax amount of another tax. Define taxable basis formulas
to manage these requirements.

Determine Tax Calculation

This process calculates the tax amount on the transaction.
In most cases, the tax amount is computed by applying the derived
tax rate to the derived taxable basis. In some exceptional cases,
the tax amount is altered by adding or subtracting another tax. Define
tax calculation formulas to manage these requirements.

Determine Tax Recovery

This process determines the recovery rate to use on
procure-to-pay transactions when the tax allows for full or partial
recovery of the tax amount. For example, for UK manufacturing companies
VAT on normal purchases used for company business is 100% recoverable.
However, if you are a financial institution which only makes VAT exempt
on sales then you are not allowed to recover any taxes and your recovery
rate is zero percent on all purchases. The recovery process impacts
the distribution level, tax amounts, and inclusiveness of taxes. The
resulting distribution amounts are adjusted as a result of the recovery
process. The recovery type is defined on the tax and identifies whether
there are one or two recovery types; primary and secondary. For each
tax and recovery type the application determines the recovery rate
based on a tax rule or default value defined on the tax.

Tax Rules: Explained

Tax determination can be configured as a simple
process with all default values for the determination points and it
can be enhanced with the definition of tax rules to identify and process
any exceptions to the common treatment scenario.

The tax rules that are part of the tax determination
process are organized into rule types. Each rule type identifies a
particular step in the determination and calculation of taxes on transactions.
The tax determination process evaluates, in order of priority, the
tax rules that are defined against the tax configuration setup and
the details on the transaction. The application processes tax rules
in order of evaluation until one evaluates successfully, then the
process stops. If none of the rules defined evaluate successfully
the associated default value is used.

The tax line determination process uses the information
of the transaction header and the transaction line and any information
derived by the transaction attributes such as party fiscal classification
to determine the tax lines. The rule types and related processes are
used for tax line determination and tax calculation.

A rule type associates a tax rule to a particular
point in the determination process. The following are the possible
tax rules you can define:

Place of Supply Rules

Tax Applicability Rules

Tax Registration Determination Rules

Tax Status Determination Rules

Tax Rate Determination Rules

Taxable Basis Rules

Tax Calculation Rules

Tax Recovery Rate Determination Rules

Manage Direct Tax Rate Determination
Rules

Account Based Direct Tax Rate Determination
Rules

Tax Classification Based Direct Tax
Rate Determination Rules

Define a tax rule in the context of a tax regime,
configuration owner, tax. Define Tax Rate Determination Rules within
the context of a tax regime, configuration owner, tax, and tax status.
Define Tax Recovery Rate Determination Rules within the context of
a tax regime, configuration owner, tax, and recovery type. When processing
a transaction the transaction date must be within the effective date
of the rule.

Associate a tax rule with an event class or tax event
class on the tax rule header to identify the tax rule as only being
applicable to a specific event class. The tax determination process
evaluates event-specific rules and tax event-specific rules before
nonevent-specific rules for the same rule type, tax regime, configuration
owner, and tax. Set up more specific event classes to less specific
tax event classes to generic tax rules applicable to all event classes.
Include geography information on the tax rule header as well as within
the determining factor or condition set detail. Including geography
detail does not change evaluation order but improves the performance
of tax rule processing. Include reference information, such as tax
law or other text, in the definition of the tax rule.

Tip

Always try to minimize tax rules and setup for tax
regimes and taxes. Tax rules are specific to a tax regime and tax,
thus by minimizing the number of tax regimes and taxes, the number
and complexity of the tax rules can be minimized.

Tip

Move any complexity from the beginning to the end
of the rule types and supporting setup. For example, it is better
to use tax recovery rate rules in preference to setting up specific
tax rates with individual defaults associated with tax recovery rates.

Tax reporting requirements adds some level of complexity
to the pure tax setup needed to support the tax determination and
calculation processes, make every effort to minimize this additional
level of complexity. Write tax reports wherever possible to use tax
reporting codes or use the determination factors that identify your
reporting requirements. These reporting determination factors should
replace the need to create specific taxes, tax statuses, and tax rates
purely defined to allow tax reporting.

For extreme cases you may need to create a more complex
tax setup to meet your tax reporting needs. For example, currently
there are no determining factors that can easily identify asset purchases.
In many countries it is a requirement to report the tax associated
with asset purchases separately. In this case, create tax status and
tax rate rules based on asset account segments to uniquely allocate
a specific tax status and tax rate to these asset purchases. These
asset purchases can then be reported by searching for the specific
tax status and tax rate or specific tax reporting codes associated
with the specific tax status or tax rate.

The tax determination process uses direct tax rate
rules to determine tax applicability, tax status, and tax rate. The
tax determination process uses a tax rate rule to determine the tax
rate once the tax status is determined. A direct tax rate determination
rule is a good choice if there are specific requirements to drive
a specific tax, tax status, and tax rate and no variation in tax status
or tax rate is required.

Tip

If tax applicability is not impacted by a tax law
but the tax rate is you can set up a tax status rule to point to a
different tax status and utilize a default tax rate associated to
that tax status. If the tax status does not need to be unique a tax
rate rule can drive a specific tax rate but keep the tax applicability
and tax status based on existing rules.

Direct Tax Rate Determination

Use the Direct Tax Rate Determination rule type for
situations where you do not need to create separate tax rules for
tax applicability, tax status, and tax rate. The following must occur
for a Direct Tax Rate Determination rule to be applicable:

The Direct Tax Rate Determination
rule must evaluate to true

The tax rate code must be defined
for the product family

The place of supply must evaluate
successfully except in the case of migrated taxes when Allow multiple jurisdictions is selected

If a Direct Tax Rate Determination rule is not evaluated
successfully, then Determine Tax Applicability rules are processed
to determine if tax is applicable. If the tax is not applicable then
the determination process ends for tax.

Account-Based Direct Tax Rate Determination

Account-based rules are direct rate rules that are
driven by the line account of the transaction. A matching account
drives the applicability, tax status, and tax rate defined on the
tax rule. These tax rules are only applicable when the regime determination
method is Determine applicable regimes and the configuration owner tax option for the event class has the Enforce from account option selected. These
tax rules are evaluated after standard applicability rules. If a standard
applicability rule evaluated the tax to Not
applicable then it cannot be applicable through an Account-Based
Direct Tax Rate Determination rule.

Tax Classification-Based Direct Tax Rate Determination

Use the Tax Classification-Based Direct Tax Rate Determination
rule when the regime determination for the configuration owner tax
option is defined as STCC (standard tax classification code). This setup is primarily intended
for migrated tax classification codes, specifically tax classification
groups. The tax classification code populated on the transaction line
drives the tax determination and tax rate directly. A default tax
rate associated to a tax rate code is not applicable in this case.
Tax classification codes are created automatically as user-extensible
lookup codes when you save a tax rate definition. The Tax Classification-Based
Direct Tax Rate Determination rule is an extension to an existing
migrated configuration where the tax calculation was based on tax
classification codes.

Tax Setup Components
in the Tax Determination Process: How They Are Used

The tax determination process uses your tax
configuration setup and the details on the transactions to determine
which taxes apply to the transaction and how to calculate the tax
amount.

How Tax Is Calculated Using Tax Setup Components

Each step of the tax determination and tax calculation
processes requires the completion of a certain number of setup tasks.
The number and complexity of your setups depends upon the requirements
of the tax authorities where you do business.

This table describes the order of tax determination
processes that Oracle Fusion Tax uses to calculate taxes on transactions.
Use this table to review the details of each process and to identify
the setups that you need to complete for each step in the tax determination
and tax calculation process.

When no event-based qualifier, normal
event or tax event-based, is used, tax rule evaluation is used for
rule priority order.

When a geography qualifier is used,
it does not affect the tax rule evaluation order. That is, tax rules
are evaluated based on the above points regardless of whether a geography
qualifier is used or not.

The following table considers five tax rules, namely,
A, B, C, D, and E with or without event qualifiers and rule order
and the resulting evaluation sequence:

Tax Rule

Normal Event Qualified

Tax Event Qualified

Rule Order

Evaluation Sequence

A

Yes

No

100

2

B

Yes

No

50

1

C

No

No

10

5

D

No

Yes

20

3

E

No

Yes

30

4

Rule B is evaluated first because it is the highest
priority rule with a normal event rule qualifier. Rule A is identified
as second in evaluation sequence it is the only other tax rule with
a normal event rule qualifier. Rule D is third in evaluation sequence
as it is the highest priority rule with a tax event rule qualifier
followed by rule E as the only other tax rule with a tax event rule
qualifier. Finally, the application evaluates rule C as it does not
have any event rule qualifiers.

The use of normal event or tax event rule qualifiers
alters the way in which the tax determination process processes the
tax rules. For an event class qualified tax rule, normal event or
tax event-based, the tax rule is evaluated first in preference to
tax rules qualified by tax event qualifiers or a nonevent class qualified
tax rule of higher priority.

Consider that you have two rules: rule A and rule
C with rule priority 100 and 10 respectively. The rules are associated
with condition sets that match against the transaction line details.
Rule A has a normal event class qualifier which is satisfied while
rule C does not have an event class qualifier, rule A is processed
and used first regardless of the rule priority order, even though
rule A has a lower priority than rule C.

Tax rules qualified by tax event qualifiers are processed
after normal event qualified tax rules but before tax rules with no
event or tax event qualifiers. When there are two or more rules with
normal event class qualifiers that match the transaction line details,
the application uses rule priority to determine the order in which
the tax rules are processed.

Note

Geography qualifiers do not function in this way.
When a tax rule has a geography qualifier and no event class qualifier,
the tax determination process processes the tax rules based on the
rule priority against other tax rules that do not have any tax event
rule qualifiers.

Geography Qualifiers

Enable the Set as
geography specific rule option to use the geography qualifier.
Once you enable this option you can enter either a normal geography
or a tax zone geography.

When you use a normal geography, select the parent
geography type and parent geography to help restrict the list of geography
type and subsequently, the geography name fields. For example, when
you want to select counties for a specific state such as California,
define the:

Parent geography type as State

Parent geography name as CA (California)

Geography type as County

This limits the list of values for the geography name
field to the counties that are in the state of California instead
of listing all of the counties.

Tip

When selecting the normal geography qualifiers, use
the parent geography to ensure that the correct geography element
is selected, as there are many multiple geography elements with the
same name across the world. For example, Richmond is a city in Canada's
provinces of British Columbia, Ontario, and Quebec. Richmond is also
a city in the state of Virginia in the United States.

Order of Processing
Within a Rule Type: How Tax Rules Are Evaluated

During tax determination processing, Oracle
Fusion Tax considers the tax rules belonging to each rule type in
the order that you defined them.

How Tax Rules Are Evaluated

The sequence of tax rules evaluation is:

Generally, you define tax rules for
a configuration owner, tax regime, tax, and rule type. If a tax regime
is subscribed to an entity as Common configuration, all the tax rules you defined for the Global
configuration owner are considered for rule evaluation.
If it is subscribed as Party-specific configuration or Parent first party organization, then only the tax rules you defined for that entity or the reference
entity are considered. If it is Common configuration
with party overrides then all the tax rules you defined
for the entity as well as for the Global configuration
owner are combined and evaluated in the order specified.
If the effective dates of a tax rule does not cover the transaction
date or if it is disabled, then the tax rule is ignored during rule
evaluation.

From the previous listed rules, if
one or more tax rules belonging to a tax regime, tax, and rule type
are defined for a normal event class or tax event class, then such
rules are evaluated first by normal event class and then by tax event
class regardless of the overall rule order. If more than one event
class rule is listed for a rule type, then such set of rules are further
sequenced according to their corresponding rule orders

Further to the previous sequencing,
if one or more tax rules belonging to a tax regime, tax, and rule
type are defined for a tax event class, then such rules are next sequenced
for evaluation, regardless of the overall rule order. If more than
one tax event class rule is listed for a rule type, then the set of
rules are further sequenced according to their given rule order.

Finally, the tax rules belonging
to a tax regime, tax, and rule type are listed according to their
defined rule order for evaluation.

While processing each tax rule in the evaluation sequence,
the tax determination process evaluates the condition sets defined
within a tax rule according to the defined condition set order sequence.
If a condition set criteria does not match with the transaction details,
the tax determination process evaluates the next condition set. If
none of them match with the transaction details, the next rule within
the ordered rule set is considered. If a condition set criteria matches
with the transaction details, then the tax determination process considers
the rule result defined against that condition set and the tax rule
is marked as successfully evaluated. If none of the defined rule conditions
match the transaction details, then the tax determination process
considers the default result defined for that tax.

Example

The following is an example of a tax regime that is
subscribed to by a business unit with common configuration treatment.
To meet the tax law requirements to determine the tax rates, the following
tax rate rules are defined against the global configuration owner.
The details shown below are a summary of the rate rules including
rule order, geography specific details, associated conditions sets,
and the rate results associated to these condition sets:

Rule Order

Normal Event Class

Geography-Specific Rule

Condition Set

Condition Set Order

Result

10

Blank

Blank

CS-1

CS-2

CS-3

10

20

30

VAT10%

VAT12%

VAT15%

20

Purchase invoice

Location type: Bill from

Geography name: California

CS-4

10

VAT12.5%

30

Purchase invoice

Blank

CS-5

10

VAT13%

Scenario 1

If a Payables invoice is involved and Texas is the
bill-from party state, the tax rule processing sequence is as follows:

The tax rules are listed according
to the sequencing logic. For example, the tax determination process
evaluates tax rules involving normal event class qualifiers first
regardless of having a lower rule order.

The tax determination process further
evaluates condition sets listed within each tax rule.

The tax determination process is represented as follows:

Rule Order

Normal Event Class

Geography-Specific Rule

Condition Set

Condition Set Order

Result

Evaluation Status

Result

20

Purchase invoice

Location type: Bill from

Geography name: California

CS-4

10

VAT12.5%

Condition set: Not evaluated

Tax rule: Fail, because the bill-from
party state is Texas

Move to next tax rule

30

Purchase invoice

Blank

CS-5

10

VAT13%

Condition set: Evaluated and passed

Tax rule: Passed, because the condition
set values match with the transaction details

Condition set result considered and exit rule evaluation

10

Blank

Blank

CS-1

CS-2

CS-3

10

20

30

VAT10%

VAT12%

VAT15%

Scenario 2

If a Receivables invoice is involved, the tax rule
processing sequence is as follows:

The tax rules are listed according
to the sequencing logic. For example, the tax determination process
evaluates tax rules involving normal event class qualifiers first
regardless of having a lower rule order.

The tax determination process further
evaluates condition sets listed within each tax rule.

Rule Order

Normal Event Class

Geography-Specific Rule

Condition Set

Condition Set Order

Result

Evaluation Status

Result

20

Purchase invoice

Location type: Bill from

Geography name: California

CS-4

10

VAT12.5%

Condition set: Not evaluated

Tax rule: Fail, because the event
class criteria does not match

Move to next tax rule

30

Purchase invoice

Blank

CS-5

10

VAT13%

Condition set: Not evaluated

Tax rule: Fail, Passed, because the
event class criteria does not match

Move to next tax rule

10

Blank

Blank

CS-1

CS-2

CS-3

10

20

30

VAT10%

VAT12%

VAT15%

For CS-1:

Condition set: Fail

Tax rule: In process, because the
condition set values do not match with transaction details

For CS-2:

Condition set: Pass

Tax rule: Pass, because the condition
set values match with transaction details

For CS-1: Move to next condition set

For CS-2: Condition set result considered and exit
rule evaluation

Setting Up
Tax Rules: Points to Consider

The performance of the tax determination process
is in inverse proportion to the number of tax rules and conditions
that the process needs to evaluate in order to arrive at a specific
result.

Creating Tax Rules

Use these guidelines and examples to help
plan your tax rules implementation:

If the tax condition results and
rule results always equal the default values, then you do not need
a tax rule. You only need to define a tax rule for a result that is
different from the default value. For example, if more than one tax
rate is possible for a given tax and tax status, then you need to
create at least one tax rule.

These qualifications
apply to tax rules and default values:

If you require many different results
other than the default value for a given tax and rule type, it probably
means that the default value itself sometimes applies. In these cases,
you should also define a tax rule for the default value. Otherwise
the tax determination process must always process and eliminate the
tax rules defined for all other values before arriving at the default.

As an alternative to defining a tax
rule for the default value, you can assign the least frequent result
as the default value. The tax determination process processes the
maximum number of tax rules on the minimum number of occasions. In
this kind of an implementation, you must ensure that your tax rules
and conditions cover all of the more common results in order to prevent
the tax determination process from using an incorrect result as a
default.

If more than one tax rate is possible
for a given tax this may be a consideration for a tax rule.

If you define multiple tax rules
to derive distinct results for a process, assign the least frequent
result as the default value for the process. The most frequent value
should be the first tax rule. There are occasions for the default
to be the most frequent value so you may want to define tax rules
for exceptions, such as by item. In general, define tax rules for
exceptions, but if there are a lot of tax rules that you need to define,
then you may want to define a tax rule for the most common scenario
to avoid processing all of the exceptions.

When you define tax rules consider
the need to repeat tax conditions in multiple rule types if the condition
is part of the applicability evaluation. For example, if you define
a Determine Tax Applicability rule for UK VAT that only applies when
ship to is equal to United Kingdom, then you do not need to repeat
this condition in a tax rule for a subsequent tax determination process,
such as a Determine Tax Status rule.

Where possible, use the tax rule
header information instead of creating tax conditions that arrive
at the same result. For example, if tax rules apply to the Purchase
business process, set the tax event class to Purchase transaction rather than defining a tax condition
within the tax rule, such as tax event class is equal to Purchase
transaction.

When you order the tax condition
sets within a tax rule, assign the higher priority to the set of conditions
that occurs more frequently. Similarly, when you order the tax rules
within a rule type and tax, assign the higher priority to the tax
rule that gives the most frequently arrived at process result.

Use product tax exceptions for special
rates based on product fiscal classifications rather than defining
a Determine Tax Rate rule based on product fiscal classifications.
For example, if three out of five product fiscal classifications use
a special rate, define three product tax exceptions based on the three
product fiscal classifications that need a special rate, and set the
standard rate as the default rate.

Define the minimum number of tax
conditions necessary for a tax rule. For example, if a special rate
applies to goods shipped outside a state as opposed to within a state,
define one tax condition as ship from state is not equal to ship to
state, rather than defining two separate tax conditions for each ship
from and ship to location, such as ship from state is equal to Nevada
and ship to state is not equal to Nevada.

Consider the reusability of determining
factor sets during the creation process. Any determining factor not
set as required in the determining factor set definition can be set
to ignore in the condition set so you do not have to define the condition
and it is not evaluated. This allows flexibility in the condition
set definition not requiring a unique determining factor set for every
variation in condition set logic.

For tax rules that involve the shipping
to and from a tax zone, for example the European Union, define a tax
condition for all ship to countries within the tax zone rather than
separate tax conditions for each country, such as ship to is equal
to Great Britain, ship to is equal to France, and so on.

For tax rules that apply to a specific
geographic area, define tax rules with the additional context of the
geographic area rather than adding location-based equal to tax conditions.
For example, if you have a tax rule that only applies if the ship
to state is California, then define the tax rule such that it is only
evaluated when the ship to state is California. You can do this by
associating geography during the first step of the tax rule definition
at the tax rule header level.

Define tax rules that are common
across all legal entities or business units under the global configuration
owner, instead of creating the same tax rules for each legal entity
or business unit. If all tax rules are not commonly applicable to
all legal entities or business units, then:

Set the configuration option of the
legal entities or business units that require additional rules to Common configuration with party overrides

Define supplementary party-specific
rules under the applicable legal entities or business units. You can
set priority values for party-specific rules that complement the tax
rules of the global configuration owner, in accordance with the tax
requirements.

Turning Tax
Regulations into Tax Rules: Example

This example illustrates how to set up tax
rules based on tax regulation in the Her Majesty's Revenue and Customs
(HMRC) VAT guide. It provides the detailed business conditions under which
goods can be reverse charge (self-assessment) as part of the Intra-EU
Supply legislation.

Scenario

You are a UK business registered for VAT in the UK.
You purchase goods from other European Union (EU) countries and therefore
fall under the HMRC Tax Regulation Intra-EU Purchase of Goods legislation.

HMRC Tax Regulation

According to the HMRC VAT guide, if you purchase goods
from a VAT-registered business in another EU country, and the goods
are moved to the UK, then you may be required to account for VAT in
the UK on the acquisition of goods. This VAT can be recovered as input
tax on the same VAT return, subject to the normal rules for reclaiming
input tax.

Analysis

Analyze the text of the legislation and identify the
key phrases in the legislation.

The following figure shows an extract of the UK HMRC
VAT guide regarding the Intra-EU Supply legislation.

Break these phrases down into product, party, process,
and place determining factors that describe under what conditions
the legislation is applicable. Look at the legislation and identify
what is the outcome when the legislation is applicable and determine
which rule types are appropriate.

The following figure shows these determining factors
and rule types in detail and how you can turn them into expressions
that can be modeled in Oracle Fusion Tax.

This table describes the phrases identified in this
tax legislation as represented in the previous figure:

Legislation Phrase

Text

Requirement

1

If you purchase goods...

The tax rule is limited to purchase transactions.

2

...from a VAT-registered business
in another European Community country...

The tax rule requires that the supplier be registered
in another EU country.

3

...and the goods are removed...

The tax rule is limited to the Goods product type.

4

...are removed to the United
Kingdom...

The tax rule refers to goods delivered to the United
Kingdom from another country in the EU country.

5

...you may be required to
account for...

The party must reverse charge (self-assess) the tax.

6

...for VAT in the United Kingdom...

The tax is UK VAT.

Resulting Tax Rules

Legislation Phrase 1

Tax legislation phrase 1 indicates that the determining
factor that defines this specific tax rule is only applicable to purchase
transactions. This equates to a tax event class equal to purchase
transactions. Use a tax event class rather than an event class as
the tax event class covers other products in the procure-to-pay flow.
This covers Oracle Fusion Payables and Oracle Fusion Purchasing processing
with a single approach.

The following figure shows that the determining factor
that defines this specific tax rule is only applicable to purchase
transactions.

This table describes the contents of the tax condition
set as represented in the previous figure:

Legislation Phrase

Determining Factor Name

Operator

Value

1

Tax Event Class

Equal to

Purchase transaction

Tip

Always look for the most generic approaches that cover
more of the business requirements in a single tax rule. For example,
here the tax event class is used instead of a specific event class
for Payables transactions and another similar rule for Purchasing
transactions.

It is determining factors like this that allows you
to define tax rules that are only applicable to specific types of
transactions. The previous approach allows you a convenient way of
splitting order-to-cash and procure-to-pay transactions. By using
event class you can make a more detailed refinement so that tax rules
are only applicable to specific product transactions. This flexibility
drives the simplification of combining procure-to-pay tax setup with
order-to-cash tax setup into a single model. In the majority of cases
you do not need to distinguish between procure-to-pay or order-to-cash
transactions within the tax rules, however, where there is a need
create specific procure-to-pay or order-to-cash tax rules using this
key design concept.

Legislation Phrase 2

Tax legislation phrase 2 indicates that the determining
factor that defines the supplier is registered in another EU. There
are several ways of modeling this but the approach that is recommended
for you to take is to use a registration status on the tax registration
record set up for the GB tax regime. It is also recommended that a
business process is in place and documentary evidence retained to
show that the supplier is validated as a true supplier registered
in another EU country. Until you complete this manual business process
the supplier should not be marked with the registration status of
registered in another EU country.

The following figure shows the determining factor
that defines that the supplier is registered in another EU country.

This table describes the contents of the tax condition
set as represented in the previous figure:

Legislation Phrase

Determining Factor Name

Class Qualifier

Operator

Value

2

Registration Status

of supplier

Equal to

Registered in another EU country

Tip

Always look for approaches which coupled with business
procedures provide the necessary controls. In this case it is recommended
that you devise and implement a business procedure to ensure that
sufficient level of checking is done before the supplier or supplier
site tax registration record is created and that the correct registration
status entered. This business procedure ensures that the supplier
is a valid supplier and that their tax registration number is a valid
tax registration number.

Legislation Phrase 3

Tax legislation phrase 3 indicates that the determining
factor that defines the product type is goods. Another way of modeling
this is to use a product fiscal classification which can automatically
be derived from the item defined on the transaction. However, in this
case if an item is not specified on the transaction, for example in
an unmatched purchase invoice being processed, then there is no product
fiscal classification derived. You need to create additional tax rules
and setup to address this situation.

The following figure shows the determining factor
that defines that the product type is goods.

This table describes the contents of the tax condition
set as represented in the previous figure:

Legislation Phrase

Determining Factor Name

Operator

Value

3

Product Type

Equal to

Goods

Tip

Always look for an approach which provides an automated
process that covers as many transactions as possible. For example,
by using product type of Goods rather than a product fiscal classification then unmatched Purchase
invoice tax processing can also be covered by this one tax rule.

Legislation Phrase 4

Tax legislation phrase 4 indicates that the determining
factors that define the supply is from another EU country. This is
modeled by:

Goods are being shipped to UK

Goods are being shipped from an EU
country

The shipped from country is not UK

You can take items 2 and 3 to ensure that the goods
are being sent from another EU country outside the UK.

The following figure shows the determining factor
that defines the supply is from another EU country.

This table describes the contents of the tax condition
set as represented in the previous figure:

Legislation Phrase

Determining Factor Name

Class Qualifier

Operator

Value

4

Country

of ship to

Equal to

United Kingdom

4

Economic Region

of ship from

Equal to

European Economic Community

4

Country

of ship from

Not equal to

United Kingdom

Tip

Geography and tax zones are powerful features of Oracle
Fusion Tax and you should use them wherever possible to identify tax
jurisdictions and geography requirements in general. Use the geography
or tax zone information for tax reporting instead of trying to build
geography information into concepts such as tax rates. For example,
use tax jurisdictions, such as over sea tax territories based on tax
zone, to identify specific territories needed for tax reporting rather
than creating specific tax regimes, taxes, tax statuses, and tax rates.

Legislation Phrases 5 and 6

Tax legislation phrase 5 indicates how the determining
factors discussed previously are brought together as the basis for
the Tax Registration tax rule which identified that the bill-to party
registration be used in preference to the normal default bill-from
party registration. It is this bill-from party registration that triggers
the reverse charge (self-assessment) for the type of transaction.

Tax legislation phrase 6 indicates how the determining
factors discussed previously are brought together as the basis for
the Place of Supply tax rule. This tax rule changes the normal place
of supply to be the ship-to location, which in the context of this
setup means that at least for the reverse charge (self-assessment)
side of this transaction it is deemed to have occurred in the UK.

The following figure shows how you can bring together
the determining factors discussed previously as the basis for the
Tax Registration and Place of Supply tax rules.

This table describes the contents of the tax condition
set for the Tax Registration and Place of Supply tax rules as represented
in the previous figure:

Legislation Phrase

Determining Factor Name

Class Qualifier

Operator

Value

5 and 6

Tax Event Class

Equal to

Purchase transaction

5 and 6

Registration Status

of supplier

Equal to

Registered in another EU country

5 and 6

Product Type

Equal to

Goods

5 and 6

Country

of ship to

Equal to

United Kingdom

5 and 6

Economic Region

of ship from

Equal to

European Economic Community

5 and 6

Country

of ship from

Not equal to

United Kingdom

Tip

From this example you can see that a simple Tax Registration
tax rule and Place of Supply tax rule is all that is needed to define
what is a complex scenario for the purchasing of goods from a another
EU country, not the UK, from an EU registered supplier by a UK registered
business. The other tax rules that are used if these goods are purchased
in the UK, are the normal tax rules such as Tax Status, Tax Rate,
and Tax Recovery tax rules.

FAQs for Define Tax Rules

What's the difference between using tax exemptions or tax rules to modify the taxable
nature of a transaction?

You can modify the taxable nature of a transaction
using tax exemptions, but you can also accomplish this through the
use of tax rules. Use tax rules, such as the Determine Tax Applicability
rule, to exclude certain categories of transactions from
taxation. If you choose to implement tax rules to achieve your tax
exemption requirements, the impacted transactions do not appear on
many tax reports as they do not have any tax lines.

If you must report on a transaction then the
set up a tax exemption on the customer's party tax profile which results
in a tax line being created with the modified tax rate. Use tax exemptions
where certificates of exemption are issued for specific customers,
which is typical in tax regimes for US Sales and Use Tax.

You can create an exempt tax rate with a zero percentage
rate as a method of applying exemptions. This achieves many of the
intended reporting objectives as the application generates a tax line.
Reports that specifically refer to an item as exempt may exclude items
with a zero percentage rate from that portion of the report because
the exempt indicator is blank.

If you define an exempt tax with a zero tax rate,
the transaction shows as fully taxable on all reports. If you want
reports to show the full line amount as taxable you cannot add any
exemption details, such as exempt reason codes, as this results in
an exemption being created on the customer record and a zero taxable
amount on the reports.

Manage Tax Applicability and Place of Supply Rules

Tax Applicability: Explained

The tax determination process uses your tax
configuration setup and the details on the transaction to determine
which taxes apply to the transaction and how to calculate the tax
amount for each tax that applies to the transaction. Tax is applicable
to a transaction when nexus, or presence in the geographical scope
of the tax, exists. The criterion for nexus or presence differs by
governing tax authorities.

Examples for establishing nexus include:

A physical establishment in the location

Resident employees working in the
location

Property, including intangible property,
in the location

In addition to location, there are other factors that
can contribute to the applicability of a tax. Some examples are:

Telecommunications specific taxes

Sales tax holidays

Tax on sale of luxury items

The tax determination process is organized into rule
types. Each rule type identifies a particular step in the determination
and calculation of taxes on transactions. The rule types and related
processes used for tax applicability determination are:

Determine Place of Supply: Determines
the location where a transaction is considered to have taken place
for a specific tax.

Determine Tax Applicability: Determines
the taxes that apply to a given transaction.

A third rule type, Direct Tax Rate Determination,
is a special tax rule type that lets you specify the results of tax
applicability, tax status, and tax rate for a given tax. You use this
rule type for specific tax determination requirements. If available,
the Direct Tax Rate Determination rules are processed first. If it
is found to be applicable, then the Determine Tax Applicability rules
are processed, followed by the Determine Place of Supply rules. If
it is not found to be applicable, the Determine Place of Supply rules
are processed, followed by the Determine Tax Applicability rules.

Determine Place of Supply

The Determine Place of Supply step identifies the
applicable place of supply, which is the location type where the supply
of goods or services is deemed to have taken place for a specific
tax. If Oracle Fusion Tax cannot find a tax jurisdiction for the location
that corresponds to the place of supply location type, then the tax
does not apply and it is removed as a candidate tax for the transaction.
No jurisdiction is required if it is a migrated tax which has the
other jurisdictions indicator equal to No.

For example, the place of supply for UK VAT on goods
is generally the ship-from country. Thus, the place of supply of a
sale or purchase within the UK is the UK itself. However, if a UK
legal entity supplies goods from its French warehouse to a German
customer, then the place of supply will not find a jurisdiction for
UK VAT in France, and therefore UK VAT does not apply.

The following outlines the process that results in
a list of applicable taxes per transaction line:

Consider the Determine Place of Supply
tax rule of the first candidate tax in order of rule priority.

Use the location type derived from
the tax rule for the tax. The possible location types are:

Bill from

Bill to

Point of acceptance (Receivables
transactions only)

Point of origin (Receivables transactions
only)

Ship from

Ship to

Ship to, use bill to if ship to is
not found

Identify the location on the transaction
that corresponds to the location type derived from step 2. If no location
applies, then the default location type for the rule is used.

Identify the tax jurisdiction of
the candidate tax to which the location identified in step 3 belongs.
If the location does not belong to any tax jurisdiction of this tax,
then the tax does not apply to the transaction.

Repeat steps 1 to 4 for each candidate
tax.

Create refined list of candidate
taxes.

Determine Tax Applicability

The Determine Tax Applicability step determines the
tax applicability of each candidate tax derived from the Determine
Place of Supply step, and eliminates taxes that are found to be not
applicable.

The tax determination process first attempts to derive
the applicability of each candidate tax based on the rule conditions
of the Determine Tax Applicability rules for the tax. If no rule applies,
the process uses the default value of Applicable or Not Applicable that was assigned
to the rule type for the tax. If the tax does not apply, it is removed
from the list of candidate taxes.

The following outlines the process that results in
a final tax of list of taxes that apply to the transaction:

Consider the Determine Tax Applicability
tax rules of the first candidate tax in order of rule priority.

Use the Applicable or Not Applicable value derived
from the tax rule for the tax.

Use the default value for the rule
if no applicability rule evaluates successfully.

Repeat steps 1 to 3 for each candidate
tax.

Identify the final tax or list of
taxes by eliminating the taxes that have an applicability value of Not Applicable.

Tax Applicability
Options: Points to Consider

The tax determination process uses your tax
configuration setup and the details on the transaction to determine
which taxes are applicable to the transaction.

You need to decide when to:

Create tax rules

Set up tax zones

Use Allow
tax applicability option

Use Perform
additional applicability for imported documents option

Create Tax Rules

If the tax authority levies tax on all sales
and purchase transactions at the same rate, and neither tax applicability
nor the tax rates and recovery rates vary by any factors, you do not
have to set up tax rules. Oracle Fusion Tax can simply use the default
tax status, tax rate, and tax recovery rate defined for the tax. If,
however, the applicability of tax is dependent upon certain criteria,
you may need to use default values in combination with one or many
tax rules to define the logic necessary to derive the values in the
tax determination process.

The tax rules used for tax applicability determination
are:

Place of supply rules

Tax applicability rules

Place of Supply Rules

Use place of supply rules to determine the place where
the transaction is deemed to have taken place when this determination
is based on certain criteria.

For example, consider a German company supplying physical
services, such as work on goods. at a customer's site in the UK, where
the customer is registered for UK VAT. With a default value of Ship to for place of supply, the customer's
tax registration number is used on the transaction.

Next, consider the same German company supplying physical
services at a customer's site in the UK, where the customer is not
registered for UK VAT. The default value of Ship to for place of supply yields no tax registration
number since the customer is not registered for UK VAT. In this case,
you create a place of supply rule to deem the Ship from as the place of supply when the customer is
not registered.

At transaction time the application derives the place
of supply from the transaction as shown in the table below. It is
important to consider how place of supply translates for the event
classes being considered for tax calculation in a regime since this
can include and exclude candidate taxes.

Place of Supply

Order-to-Cash Transactions

Procure-to-Pay Transactions

Bill from

Legal entity address

Supplier site header level address

Ship from

Warehouse address

Supplier site header level address

Bill to

Customer site bill-to address

Business unit address on the associated party tax
profile

Ship to

Customer site ship-to address

Ship-to location at line level

Ship to, use bill to if ship to not found

Customer site bill-to or ship-to address

Ship-to location at line level

Tax Applicability Rules

Use tax applicability rules to apply a specific tax
to certain transaction lines, or conversely, exempt certain transaction
lines from a specific tax. For example, a given tax may not apply
to a domestic supply of goods to an exempt customer.

An important consideration in creating your tax applicability
rules is that when a tax is deemed not applicable, a tax line is not
created. However when a tax is deemed exempt based on an exemption
or special rate, the tax line is still created for reporting purposes.

Note

For migrated data using the Standard Tax Classification
Code approach, which uses a tax code to derive tax, tax status, and
tax rate, you can set the tax to be applicable or not applicable by
default or by using a tax applicability rule.

If a direct tax rate determination rule is evaluated
successfully, then the tax is applicable and the tax status and tax
rate defined for the rule are used in tax determination. If a direct
tax rate determination rule is not evaluated successfully, then the
tax determination process resumes with the tax applicability rules.

Create Tax Zones

Use tax zones to group existing geographical
regions that share the same tax requirement. You can use tax zones
with tax regimes, to identify tax requirements for a special geographic
area, and to create parent tax regimes that represent a related grouping
of geographic regions for tax reporting purposes. You can also use
tax zones with tax rules, to create tax rules that refer to a specific
geographic location. The use of tax zones is optional and depends
on your overall tax setup planning.

For example, if a separate economic community exists
in part of a country only, you can either set up a tax zone and corresponding
tax regime for the applicable geographic area, or set up a country
tax regime and use applicability rules to exclude the parts of the
country where the tax requirement does not apply.

Use Allow Tax Applicability Option

Use the Allow tax
applicability option to determine if Oracle Fusion Tax
calculates tax on transactions for a specific event class. This option
is available on the Configuration Owner Tax Options page, which enables
you to review the default tax settings for each application event
class. Oracle Fusion Tax uses these settings as the basis for determining
and calculating taxes on transactions belonging to each event class.

If the Allow tax applicability option is set for the Payables event class, you must also set this
option on the party tax profile of third parties and third party sites
acting as suppliers or supplier sites that are involved in transactions
belonging to this event class. You can set this option, for example,
for customers that also act as suppliers on transactions.

Use Perform Additional Applicability for Imported
Documents Options

Use the Perform additional
applicability for imported documents option to indicate
whether Oracle Fusion Tax runs the tax applicability process to identify
missing taxes on an imported document. This option is also available
on the Configuration Owner Tax Options page, and applicable to Payables
event classes only. Taxes not included in the imported document are
marked as Self-Assessed, if self-assessment applies to the transaction.

Setting Up
Tax Applicability Influencers: Example

This example illustrates the tax setup for
two taxes: one that is generally applicable, the other that is only
applicable by exception. The taxes are set to apply their general
applicability by default, however tax rules are used to switch applicability
for both taxes when certain criteria is met.

Scenario

In Canada, the First Nations Goods and Services Tax
(FNGST) is a tax that is applied by participating Aboriginal governments
on the consumption of goods and services within their reserves or
settlement lands. The 5% FNGST is administered in exactly the same
way as the federal Goods and Services Tax (GST), however, where it
applies, GST does not apply.

The tax implications are:

FNGST is generally not applicable
and would only apply on an exception basis

Place of supply for FNGST tax is
based on the place of delivery or ship-to location

If FNGST applies then GST would not
be applicable

Transaction Details

A customer who resides on lands where FNGST applies
buys supplies from ABC Corporation located in the province of Ontario.
This store is not located on lands where FNGST applies. The sales
invoice indicates that ABC Corporation delivers the furniture to the
customer's residence. The FNGST applies to the sale, and GST does
not apply.

As part of the setup, create a tax that is applicable
to any party that qualifies as First Nation. Due to the specificity
of the tax, set the default applicability to Not Applicable. In this example, you do not need to configure
a place of supply rule as a standard default of ship to would suffice.

There is more than one way to configure this rule
and applicability. They include:

Define an applicability rule and
use a default status and rate associated with the tax.

Analysis

For this scenario, the following setup is needed:

Create a tax regime for the tax that
is applicable to any First Nation party. The regime level is Country and the country of applicability
is Canada.

Create a tax with a default applicability
of Not Applicable since this tax
is only applicable in exception cases. Set the default Place of Supply
as Ship To. To make this tax applicable, you will need to create a
tax rule.

Create a standard tax status and
a standard tax rate. Create the default tax rate with a rate percentage
of 5%. You do not need to define a jurisdiction rate since the rate
is standard across Canada.

For FNGST, identify a driver to determine
applicability, such as a party fiscal classification. Create a party
fiscal classification for First Nation, and associate the tax regimes
affected by this tax. Note that CA FNGST is associated to trigger
applicability, but CA GST AND HST is also associated to avoid applicability
when CA FNGST applies.

Once you create a party fiscal classification
and associated the tax regimes, associate the classification to the
specific party. To do so, create or edit an existing third party tax
profile and associate it to the First Nation party fiscal classification.

For FNGST, create a tax applicability
rule that is Applicable when the
conditions for FNGST are met. Recall that by default, FNGST is Not Applicable since in most cases it only
applies as an exception. For this tax rule, you need a tax determining
factor set and associated tax condition set whereby the party fiscal
classification of the ship-to party corresponds to the First Nation
party fiscal classification you created.

For GST, create a tax applicability
rule that is Not Applicable when
the conditions for FNGST are met. By default, GST is Applicable since in most cases it applies
and FNGST is the exception.

Resulting Tax Applicability

FNGST, a tax that is not applicable by default, becomes
applicable on transactions to First Nation parties. The first Determine
Tax Applicability rule makes FNGST applicable when the ship-to party
on the transaction corresponds to the party fiscal classification
that identifies a First Nation party. Since GST does not apply when
FNGST is applicable, the second Determine Tax Applicability rule has
the opposite result, whereby GST becomes not applicable when the ship-to
party on the transaction is a First Nation party.

Manage Tax Formulas

Tax Formulas: Explained

Tax formulas are used in the tax calculation process to determine
the taxable basis of a transaction line and the calculation methodology
that must be applied to obtain the tax amount.

When the parameters available on a transaction do
not satisfy the rule conditions, the default tax formulas defined
for the tax are applicable.

There are two types of tax formulas:

Taxable basis tax formula

Tax calculation tax formula

Taxable Basis Tax Formula

The taxable basis tax formula is used in the
tax calculation process to determine the amount or quantity that should
be considered as the taxable basis of a transaction line. The tax
rate is applied on the taxable basis amount to derive the basic tax
amount on a transaction line.

The key factor that decides the characteristics of
the taxable basis amount is the taxable basis type that is defined
in the taxable basis formula. The various taxable basis types are:

Assessable
value

Line amount

Prior tax

Quantity

The following standard predefined taxable basis tax
formulas are available:

STANDARD_QUANTITY

STANDARD_TB

STANDARD_TB_DISCOUNT

Assessable Value

Use Assessable value when the transaction line amount does not reflect the correct taxable
basis, from the tax calculation perspective. The assessable value
given on the transaction line is considered as the taxable basis amount
for the purpose of tax calculation.

Line Amount

Use Line amount when the transaction line amount is to be treated as the taxable
basis for tax calculation purposes.

The transaction line amount is considered as the taxable
basis. This is done after deducting the associated discounts, or after
proportionately enhancing or reducing it by a certain percentage,
or after adding other applicable taxes available on the transaction
line. These adjustments on the line amount are controlled through
the following parameters that are defined on the tax formula:

Subtract cash discount: The cash
discount applicable on the transaction, derived through the attached
payment terms, is deducted from the transaction line amount. This
option is considered only for Receivable transactions.

Base rate modifier: The transaction
line amount is increased or decreased based on the percentage value
given.

Tax formula compounding: The tax
details specified in the tax formula compounding region are added
to the transaction line amount to determine the taxable basis amount.
These tax details are also enforced by selecting the Enforce Compounding option. If a compounded
tax is enforced and if it is not calculated on the transaction, the
tax to which this tax formula is associated with also does not become
applicable.

Prior Tax

Use Prior tax if the taxable basis is one or more than the other taxes calculated
on the transaction line. The option to compound the prior taxes that
are calculated on the transaction line are also available.

Quantity

Use Quantity if a tax on the transaction is to be calculated based on the number
of units or items that are involved in the transaction.

Tax Calculation Tax Formula

The tax calculation tax formula is used to
determine the calculation methodology that is applied to derive the
basic tax amount on a transaction line. The tax amount on a transaction
is generally calculated by multiplying the derived tax rate by the
taxable basis. However, in some cases the tax amount is required to
be altered by adding other taxes that are applicable on the same transaction
line. Use a tax calculation formula defined with compounding criteria
to address this requirement.

The tax details specified in the tax formula compounding
region are added to the calculated tax that is associated with the
tax formula. These compounded tax details can also be enforced when
you select the Enforce Compounding option. When the compounded tax is enforced and when it is not calculated
on the transaction, the tax to which this tax formula is associated
with also does not become applicable.

Taxable Basis
Tax Formula: Examples

The tax calculation process uses the taxable
basis tax formula to determine the amount or quantity that should
be considered as the taxable basis of a transaction line. The tax
rate is applied on the taxable basis amount to derive the basic tax
amount on a transaction line.

Taxable basis type that is defined in the taxable
basis formula is a key factor that decides the characteristics of
the taxable basis amount. The taxable basis types are:

Assessable
value

Line amount

Prior tax

Quantity

Taxable Basis Formula Based on Assessable Value

The tax
formula that is based on assessable value is used as the taxable
basis for calculating tax when the tax authority does not consider
the transaction amount to reflect the true sale consideration, from
the tax perspective.

Consider a sales transaction between two companies,
A and B. The item value on the invoice is 1000 USD. However, if they
are related companies, that is, within the same group, the tax authority
has the discretion to mark the item value as 5000 USD for the purpose
of tax based on the average market price. The tax authority can choose
to collect the tax based on that value instead of the actual sales
value of 1000 USD.

The tax amount is calculated from the transaction
details and tax setup as follows:

Invoice line amount: 1000 USD

Assessable value: 5000 USD

State tax rate: 10%

Taxable basis type: Assessable value

Taxable Basis: 5000 USD

The state tax is equal to the taxable basis multiplied
by the state tax rate (5000 USD * 10% = 500 USD).

Taxable Basis Formula Based on Line Amount

In this case, the amount given on the transaction
line is considered for deriving the taxable basis.

Consider a situation when two taxes, state tax and
county tax, are applicable on a transaction. In such a situation,
the transaction details and tax setup is as follows:

Invoice line amount: 1000 USD

Payment terms: 2/10, Net 30

State tax rate: 20%

County tax rate 10%

Taxable basis type: Line amount

Subtract cash discount: Yes

Base rate modifier: 50%

Compounding tax regime: Sale and
use tax

Compounding tax: State tax

The tax calculation is as follows:

The state tax is equal to the invoice
line amount multiplied by the state tax rate (1000 USD * 20% = 200
USD).

The taxable basis for the county
tax is equal to the line amount plus the base rate modifier less the
cash discount at 2% plus the state tax (1000 USD + 500 USD - 20 USD
+ 200 USD = 1680 USD).

The country tax is equal
to the taxable basis multiplied by the county tax rate (1680 USD *
10% = 168 USD).

Taxable Basis Formula Based on Prior Tax

In this case, the previous tax that is calculated
on a transaction is considered as the taxable basis.

Consider a situation when two taxes, state tax and
county tax, are applicable on a transaction. In such a situation,
the transaction details and tax setup is as follows:

Invoice line amount: 1000 USD

State tax rate: 20%

Country tax rate: 10%

Taxable basis type: Prior tax

Compounding regime: Sale and use
tax

Compounding tax: State tax

The tax calculation is as follows:

The state tax is equal to the invoice
line amount multiplied by the state tax rate (1000 USD * 20% = 200
USD).

The taxable basis for the county
tax is the tax calculated for the state tax (200 USD).

The country tax is equal to the taxable basis multiplied by the county
tax rate (200 USD * 10% = 20 USD).

Taxable Basis Formula Based on Quantity

In this case, the quantity of the goods or serviceable
units is considered as the taxable basis.

Consider a scenario in which liquor is transacted
between two organizations in Canada. In such situation, when excise
tax is levied on it, the transaction details and tax setup is as follows:

Line amount: 1000 CAD

Quantity: 50 liters

Price per liter: 20 CAD

Excise tax: 11.69 CAD per liter

Taxable basis type: Quantity

The tax calculation is as follows:

The taxable basis for the excise
tax is the quantity given on the invoice (50).

Tax Calculation
Tax Formula: Example

The tax calculation tax formula is used to
determine the calculation methodology that is applied to derive the
basic tax amount on a transaction line.

Scenario

Consider a situation when two taxes, state tax and
county tax, are applicable on a transaction. In such a situation,
the transaction details and tax setup is as follows:

Line amount: 1000 USD

State tax rate: 20%

County tax rate: 10%

Compounding regime: Sale and use
tax

Compounding tax: State tax

The tax calculation is as follows:

The state tax is equal to the invoice
line amount multiplied by the state tax rate (1000 USD * 20% = 200
USD).

The county tax is equal to the invoice
line amount multiplied by the county tax rate plus the state tax ((1000
USD * 10%) + 200 USD = 300 USD).

Manage Tax Calculation Rules

Tax Calculation
Influencers: Explained

Transactions using Oracle Fusion Tax services
pass key tax determinants relating to parties, products, places, and
processes captured on a transaction to the tax determination process.
Using these details, along with the other derived determinants, the
tax determination process performs a series of process steps and determines
various components of the applicable taxes. The basic tax amount applicable
on a transaction is calculated using the derived tax components and
applying the generic calculation logic of Taxable Basis * Tax Rate
= Tax Amount.

The key processes within the tax determination process
and the resulting tax components that influence tax calculation logic,
other than the determination of the tax rate, are:

Taxable basis formula: Influences
taxable basis.

Tax inclusiveness requirements: Influences
the taxable basis and the tax amount. It is part of the Determine
Taxable Basis process.

Tax calculation formula: Influences
the tax amount.

Tax rounding requirements: Influences
the tax amount. It is part of the Calculate Tax Amounts process.

The taxable basis formula determines the taxable basis
amount or quantity for each tax that is processed on the invoice line.

The tax calculation formula determines the calculation
process to be applied on the transaction line for arriving at the
tax amount.

The inclusiveness and rounding aspects determine the
need to calculate the tax amount as inclusive of the transaction line
amount and the rounding criteria to be used on the calculated tax
amount.

Define First Party Tax Profiles

Party Tax Profiles: Explained

A tax profile is the body of information that
relates to a party's transaction tax activities. A tax profile can
include main and default information, tax registration, tax exemptions,
party fiscal classifications, tax reporting codes, configuration options,
and service subscriptions.

Set up tax profiles for the following parties involved
in your transactions:

First parties: All legal entities,
legal reporting units, and business units in your organization that
have a transaction tax requirement.

Third parties: Your customers and
suppliers and their locations and banks.

Tax authorities: Parties that administer
tax rules and regulations.

First Parties

Set up tax profiles for your first party legal entities,
legal reporting units, and business units.

First party legal entities identify your organization
to the relevant legal authorities, for example, a national or international
headquarters. Legal entities let you more accurately model your external
relationships to legal authorities. The relationships between first
party legal entities and the relevant tax authorities normally control
the setup of the transaction taxes required by your business. Under
most circumstances the tax setup is used and maintained based on the
configuration of the legal entity. Enter the default information,
party fiscal classifications, tax reporting codes, and configuration
options for your legal entities. You can also specify if you are using
the tax services of an external service provider for tax calculation.

First party legal reporting units identify each office,
service center, warehouse and any other location within the organization
that has a tax requirement. A legal reporting unit tax profile is
automatically created for the headquarter legal entity. Set up additional
legal reporting unit tax profiles for those needed for tax purposes.
For legal reporting units, enter the default information, tax registrations,
party fiscal classifications, and tax reporting codes. Also, define
tax reporting details for your VAT and global tax reporting needs
for tax registrations of tax regimes that allow this setup.

Business units organize your company data according
to your internal accounting, financial monitoring, and reporting requirements.
To help you manage the tax needs of your business units, you can use
the business unit tax profile in either of two ways:

Indicate that business unit tax setup
is used and maintained based on the configuration of the associated
legal entity at transaction time. The tax setup of the associated
legal entity setup is either specific to the legal entity or shared
across legal entities using the Global Configuration Owner setup.

Indicate that tax setup is used and
maintained by a specific business unit. Create configuration options
for the business unit to indicate that the subscribed tax content
is used for the transactions created for the business unit.

For business units that maintain their own setup,
enter the default information, tax reporting codes, configuration
options, and service providers as required.

Third Parties

Set up third party tax profiles for parties with the
usage of customer, supplier, and their sites. Enter the default information,
tax registrations, party fiscal classifications, and reporting codes
required for your third parties or third party sites. You can set
up tax exemptions for your customers and customer sites.

Banks are also considered third parties. When a bank
is created, the tax registration number specified on the bank record
is added to the party tax profile record in Oracle Fusion Tax. You
can not modify the party tax profile for a bank as it is view only.
You can only modify the bank record itself.

Note

Setting up party tax profiles for third parties is
not required. Taxes are still calculated on transactions for third
parties that do not have tax profiles

Tax Authorities

Set up a tax authority party tax profile using the
Legal Authorities set up task. The tax authority party tax profile
identifies a tax authority party as a collecting authority or a reporting
authority or both. A collecting tax authority manages the administration
of tax remittances. A reporting tax authority receives and processes
all company transaction tax reports.

The collecting and reporting tax authorities appear
in the corresponding list of values on all applicable Oracle Fusion
Tax pages. All tax authorities are available in the list of values
as an issuing tax authority.

Specifying
First Party Tax Profile Options: Points to Consider

Set up first party tax profiles for all legal
entities, legal reporting units, and business units in your organization
that have a transaction tax requirements. How you set up your first
parties can impact the tax calculation on your transactions.

The first party tax profile consists of:

Defaults and controls: Applicable
to legal entities and legal reporting units. Business units that use
their own tax setup do not have defaults and controls.

Tax reporting codes: Applicable to
legal entities, legal reporting units, and business units who do not
use the tax setup of the legal entity.

Configuration options: Applicable
to legal entities and business units who do not use the tax setup
of the legal entity.

Service subscriptions: Applicable
to legal entities and business units who do not use the tax setup
of the legal entity.

Defaults and Controls

The following table describes the defaults
and controls available at the first party tax profile level:

Option

Description

Set as self-assessment (reverse
charge)

Automatically self-assess taxes on purchases.

Rounding Level

Perform rounding operations on the:

Header: Applies rounding to calculated tax amounts once for each tax rate
per invoice.

Line: Applies rounding to the calculated tax amount on each invoice line.

Rounding Rule

The rule that defines how the rounding should be performed
on a value involved in a taxable transaction. For example, up to the
next highest value, down to the next lowest value, or nearest.

Note

If you defined a rounding precedence hierarchy in
the configuration owner tax option settings for the combination of
configuration owner and event class, Oracle Fusion Tax considers the
rounding details in the applicable tax profile.

Set Invoice Values as Tax
Inclusive

This first party intends to send or receive invoices
with invoice line amount inclusive of the tax amount.

Note

This option overrides the tax inclusive handling setting
at the tax level, but not at the tax rate level.

Tax Registrations

You must set up a separate tax registration
to represent each distinct registration requirement for a first party
legal reporting unit. Oracle Fusion Tax uses tax registrations in
tax determination and tax reporting. If your first party has more
than one tax registration under the same tax regime, then the application
considers the tax registration in the order: tax jurisdiction; tax;
tax regime.

You must enable the Use tax
reporting configuration option on the first party tax
regime to allow entry of global tax reporting configuration details
during tax registration setup for legal reporting units for these
tax regimes.

Party Fiscal Classifications

If applicable, associate first party fiscal
classification codes with this party. The party fiscal classification
codes you enter become part of tax determination for invoices associated
with this party. Specify start and end dates to control when these
fiscal classifications are applicable for this party and transaction.

For legal entities, you can view the associated legal
classifications that were assigned to the tax regime defined for this
first party. The legal classifications are used in the tax determination
process, similarly to the party fiscal classifications.

Tax Reporting Codes

Set up tax reporting types to capture additional
tax information on transactions for your tax reports for your first
parties. Depending on the tax reporting type code, you either enter
or select a tax reporting code for this party. Specify start and end
dates to control when these tax reporting codes are applicable.

Configuration Options

The legal entities and business units in your
organization are each subject to specific sets of tax regulations
as designated by the tax authorities where you do business. Use configuration
options to associate legal entities and business units with their
applicable tax regimes. You can set up tax configuration options when
you create a tax regime or when you create a party tax profile. Both
setup flows display and maintain the same party and tax regime definitions.

Service Subscriptions

Oracle Fusion Tax lets you use the tax services
of external service providers for tax calculation of US Sales and
Use Tax on Receivables transactions. The setup for provider services
is called a service subscription. A service subscription applies to
the transactions of one configuration option setup for a combination
of tax regime and legal entity or business unit. Set up service subscriptions
when you create a tax regime or when you create a party tax profile
for a first party legal entity or business unit.

Manage Controls and Defaults

Inclusive Taxes: Explained

Calculating tax on a transaction as inclusive
of the line amount is generally a business decision. This decision
is based on the relationship between the transacting parties and the
items or taxes involved.

Taxes applicable on a transaction are made inclusive
of the item line amount either:

Manually

Automatically

Manual Approach

In the manual approach, you access the calculated
tax lines on a transaction and select the Inclusive option. This action includes the calculated
tax amount with the item value.

However, this option is controlled through two factors:

Privileges are assigned to the users
for accessing and editing the calculated tax lines.

Setup restrictions are applied to
edit the Inclusive option on the
calculated tax lines.

Automatic Approach

In the automatic approach, you can configure
the tax setup and calculate the tax on a transaction as inclusive
of the item line amount. Since this requirement is primarily driven
by the tax legislation and the business relationship between the transacting
parties, the option for configuring the inclusiveness is made available
on the tax and tax rate definition and the third party and legal reporting
unit tax profiles on the tax registration and general data tabs. The
tax determination process uses a hierarchy approach to evaluate the
defined setup and applies the inclusiveness option on the transaction.

In tax setup there are options to choose for applying
the inclusiveness on a transaction. They are:

Standard
noninclusive handling: This option calculates the taxes
as exclusive of the given transaction line amount.

Standard
inclusive handling: This option calculates the taxes as
inclusive of the given transaction line amount.

Special inclusive
handling: This option calculates the taxes as inclusive
of the given transaction line amount, but the calculation methodology
differs from the standard inclusive process.

The following table illustrates the calculation methodology
used with each of these options when a transaction line amount is
1000 USD and the applicable tax rate is 10% of the taxable basis amount,
for example, line amount:

Method

Calculation

Taxable Basis Amount

Tax Amount

Transaction Line Amount

Standard Noninclusive

1000 USD * 10/100

1000 USD

100 USD

1100 USD

Standard Inclusive

1000 USD * 10/110

909.09 USD

90.91 USD

1000 USD

Special Inclusive

1000 USD * 10/100

900 USD

100 USD

1000 USD

Configuring
Inclusive Taxes: Points to Consider

The requirement for calculating the taxes
as inclusive of the item line amount is primarily driven by the tax
legislation and the business relationship between the transacting
parties. Configure your tax setup accordingly to capture the inclusiveness
as per the taxes and the parties involved within a transaction.

The following table provides some of the key
inclusiveness requirements and the corresponding setup that can honor
them:

Tax Inclusiveness
Hierarchy: How It Is Determined

Configure your tax setup to include the calculated
tax amount with the item line amount. The option for configuring the
inclusiveness is available on the tax and tax rate definition and
the third party and legal reporting unit tax profiles on the tax registration
and general data tabs.

Settings That Affect Tax Inclusiveness

Set up the inclusive options in the following pages:

Create or Edit Tax page: Specify
the tax inclusion method on the Default and Controls tab. The handling
of this field is dependent on the value of the Allow override and entry of inclusive tax lines option
at the tax regime level. If the option is not selected at the tax
regime level, the Tax Inclusion Method field is display-only. The value displayed is set at the tax regime
level.

Create or Edit Tax Rate page: Specify
the tax inclusion method on the Main Details tab. The handling of
this field is dependent on the value of the Allow override and entry of inclusive tax lines option
at the tax level. If the option is not selected at the tax level,
the Tax Inclusion Method field
is display-only. The value displayed is set at the tax level.

Create or Edit Tax Registration page:
Select Set Invoice Values as Tax Inclusive option for the third party, third party site, and legal reporting
unit tax profiles.

Create or Edit Third Party Tax Profile
and Create or Edit Third Party Site Tax Profile pages: Select Set Invoice Values as Tax Inclusive option
on the General tab for the third party or third party site.

Create or Edit Legal Reporting Unit
page: Select Set Invoice Values as Tax Inclusive option on the General tab for the legal reporting unit.

How Tax Inclusiveness
Hierarchy Is Determined

The tax determination process uses a hierarchy approach
to evaluate the options selected in your tax configuration and applies
it on the taxes calculated on a transaction.

The hierarchy sequence for processing the inclusiveness
for a tax is:

If the transaction involved is a
Receivable transaction then check for the value in the Tax Amount Included field within the invoice
line details. The available values are:

No: All the taxes calculated on the invoice line are treated as exclusive
of the item line amount.

Yes: All the taxes calculated on the invoice line are treated as inclusive
of the item line amount.

Use tax rate
code: The tax setup defined is considered for analyzing
the inclusiveness.

If the transaction involved is not
a Receivable transaction or if the Receivable transaction uses the Use tax rate code option then check for the
value specified in the Tax Inclusion Method field for the processed tax rate code. The available values are:

Standard
noninclusive handling: The referred tax gets calculated
as exclusive of the transaction line amount.

Standard
inclusive handling: The referred tax gets calculated as
inclusive of the transaction line amount.

Special inclusive
handling: The referred tax gets calculated as inclusive
of the transaction line amount. However, the line amount is considered
the taxable basis rather than the adjusted line amount, which is considered
for the Standard inclusive handling value.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the tax registration record of the third party site tax profile
for the processed registration party. The available values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

If the processed registration party is the first party,
the registration record for the tax available within the legal reporting
unit tax profile is considered. If the value is set to blank then
step 7 is processed.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the tax registration record of the third party tax profile for
the processed registration party. The available values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the General tab of the third party site tax profile. The available
values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the General tab of the third party tax profile. The available values
are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check for the value specified in
the Tax Inclusion Method field
of the tax. The available values are:

Standard
noninclusive handling: The referred tax gets calculated
as exclusive of the transaction line amount.

Standard
inclusive handling: The referred tax gets calculated as
inclusive of the transaction line amount.

Special inclusive
handling: The referred tax gets calculated as inclusive
of the transaction line amount. However, the line amount is considered
the taxable basis rather than the adjusted line amount, which is considered
for the Standard inclusive handling value.

Tax Amount
Rounding: Explained

Taxes applicable on a transaction are generally
calculated as the taxable basis multiplied by the tax rate equals
the tax amount. This calculated amount can result in an odd value
or with a large number of decimal place. You can configure the tax
setup to adjust or round the tax calculation according to the specific
requirements of the transacting parties and tax authority or to the
accepted currency denominations.

Party tax profiles of the parties
or party sites as given in the rounding precedence of the configuration
owner tax options or in the derived registration party

Tax

Note

If you plan to use a third party service provider
then you must define tax rounding information that is at least as
detailed as the rounding information of the service provider.

Setting Up
Rounding Rules: Choices to Consider

Criteria for rounding the calculated tax amounts
comes from various parties involved in a transaction. For example,
for a purchase transaction, the rounding methodology is generally
specified by the supplier. Specify rounding details in your tax setup
to ensure that your entered invoice amount, including the calculated
tax, is the same as the actual invoice amount. For a Receivables invoice,
you can specify rounding details based on your organization's policy,
but for most countries the rounding criterion is directed by tax legislation.

Rounding requirements can originate from:

Third parties

First parties

Tax legislation

Rounding Requirements from Third Parties

If rounding is based on third party requirements,
particularly for purchase transactions, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the third party or third party. For purchase transactions it is
either the ship-from party or the bill-from party.

Define the party tax profile for
the third party and specify the rounding level and rounding rule on
the General tab as preferred by the third party.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the third
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party account site details
and party tax profile details for deriving the rounding rule.

Rounding Requirements from First Parties

If rounding is based on business unit or legal
entity requirements, particularly for sale transactions, and configuration
owner tax options are defined, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the first party. For sale transactions it is either the ship-from
party or the bill-from party.

Ensure that the party tax profile
details are available for the corresponding legal reporting unit.
Specify the rounding level and rounding rule on the General tab per
the first party requirement or your business policy.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the first
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party tax profile details
for deriving the rounding rule.

The rounding criteria applied if configuration owner
tax options are not defined and the criteria in the predefined event
class options are considered include:

For a purchase transaction, the predefined
event class options use the ship-from party site and ship-from party
within the rounding precedence with the default rounding level as
the header level. The supplier's rounding preferences are considered
first on the transaction. If there are no specific supplier preferences,
for example, the party tax profile record does not exist, then the
default rounding level of Header is considered and the corresponding rounding rule from each tax
setup detail is used.

For a sale transaction, the predefined
event class options do not include any rounding precedence details.
However, the default rounding level is set to Line so the rounding level is always taken as Line and the corresponding registration record
for the tax registration party is considered for the rounding rule.
The tax registration party is identified through the Determine Tax
Registration tax rule or tax rule defaults. If a registration record
does not exist for the tax registration party, the rounding rule defined
within each tax is considered.

Rounding Requirements from Tax Legislation

If rounding is based on tax legislation, the
following occurs:

If the configuration owner tax options
are defined for the combination of business unit and legal entity
for which the transaction is registered and for the event class, the
default rounding level is used from the configuration owner tax options.
Select Blank as the rounding precedence
for the event class.

If the rounding level is at the line
level for the configuration tax options, ensure that the registration
record defined for the tax registration party has the rounding rule
based on the tax requirements. The tax registration party is identified
through the Determine Tax Registration tax rule or tax rule defaults.

Rounding Precedence
Hierarchy: How It Is Determined

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving:

Settings That Affect Tax Rounding

Tax precision: The number of decimal
places to which to calculate the tax amount.

Minimum accountable unit: The smallest
currency unit that a tax amount can have.

Rounding level: The transaction level
at which the rounding is to be performed.

Rounding rule: The method that is
used to round off the calculated taxes to the minimum accountable
unit.

Options available for the rounding level are:

Header: Applies rounding to calculated tax amounts once for each tax rate
per invoice.

Line: Applies rounding to the calculated tax amount on each invoice line.

Options available for the rounding rule are:

Up: the amount is rounded to the next highest minimum accountable unit.

Down: The amount is rounded to the next lowest minimum accountable unit.

Nearest: The amount is rounded to the nearest minimum accountable unit.

How Tax Rounding Is Determined

If you did not define configuration owner tax option
settings for the combination of configuration owner and event class,
the rounding process uses the default rounding level of the event
class and the default rounding rule of the tax.

If you defined a rounding precedence hierarchy in
the configuration owner tax option settings for the combination of
configuration owner and event class, the rounding process looks for
a rounding level and rounding rule in this way:

Looks for rounding details in the
party tax profiles of the parties and party sites involved in the
transaction, according to the rounding precedence hierarchy.

If an applicable tax profile is found
then uses the rounding level and rounding rule of the tax profile.

If the rounding level is at the header
level then uses these values to perform the rounding. The process
ends.

If the rounding level is at the line level
then goes to step 6.

If an applicable tax profile is not
found then uses the rounding level setting of the configuration owner
tax option.

If the configuration owner tax option
rounding level is at the header level then uses the rounding rule
that is set at the tax level for each tax of the transaction to perform
the rounding. The process ends.

If the rounding
level is at the line level then goes to step 6.

If the rounding level is at the line
level then:

For each tax line, uses the rounding
rule belonging to the tax registration of the party type derived from
the Determine Tax Registration rule.

If a registration record does not
exist for the registration party type and if you did not define configuration
owner tax option settings for the combination of configuration owner
and event class, then the rounding process uses the rounding rule
that is set at the tax level to perform the rounding. The process
ends.

If a registration record does not
exist for the registration party type and if you defined a rounding
precedence hierarchy in the configuration owner tax option settings
for the combination of configuration owner and event class, then the
rounding process looks for a rounding rule in this way:

Refers to the party or party site
of the first party type defined in the rounding precedence hierarchy.

Uses the rounding rule of the party
or party site tax registration, if defined.

If a tax registration is not defined,
uses the rounding rule of the party or party site account site details,
if defined.

If a rounding rule is not defined,
uses the rounding rule of the party or party site tax profile, if
defined.

If a tax profile is not defined,
repeats the previous substeps for each rounding party in the rounding
precedence hierarchy.

If a rounding rule is found, uses
this rounding rule to perform the rounding. The process ends.

If a rounding rule is not found,
then uses the rounding rule that is set at the tax level to perform
the rounding. The process ends.

Tax Rounding: Examples

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving configuration
owner tax options, event classes, party tax profiles, and taxes. These
examples illustrate how the rounding process works.

Scenario

The following examples represent how the rounding
process determines the tax rounded amount based on transaction, tax
setup, and rounding details.

The transaction and tax setup details for the two
examples are:

Invoice header amount: 5579 USD

Invoice line 1 amount: 1333 USD

Invoice line 2 amount: 1679 USD

Invoice line 3 amount: 2567 USD

Applicable taxes:

State tax, rate percentages of 12.5%,
6.75%, and 3.33%

City tax, rate percentages of 7.5%

The rounding details for the two examples are:

Rounding level: Header

Rounding Rule:

State tax: Up

City tax: Nearest

Tax precision: 2

Minimum accountable unit: 0.01

Example 1 represents the rounding details applied
at the header level. Applying these factors, the rounding process
calculates the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Line amounts truncated per tax precision and
rounding criteria applied at the header level

Step 2: Difference between the header amount and the
sum of the line amounts

Step 3: Apply the difference amount to the maximum
tax line amount

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.81

418.43

0.01

0.02

395.81

418.43

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.62

99.97

166.62

99.97

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.91

125.92

55.91

125.92

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.52

0.01

0.02

173.28

192.54

Example 2 represents the rounding details applied
at the line level. Applying these factors, the rounding process calculates
the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Rounding criteria is applied at the line level

Step 2: Line amounts are added to obtain revised header
amounts

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.82

418.44

395.82

418.44

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.63

99.98

166.63

99.98

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.92

125.93

55.92

125.93

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.53

173.27

192.53

Self-Assessment
of Taxes: Explained

Taxes for purchase transactions are usually
calculated by the supplier and included in the invoice. The responsibility
of collecting and remitting these taxes to the authority lies with
the supplier. However, in certain cases the supplier does not have
presence (nexus) or is not registered in the customer location. Taxes
applicable in such cases, in the customer location, are self assessed
by the purchasing organization. Unlike supplier assessed taxes that
are paid to the supplier, self-assessed taxes are remitted by the
purchasing organization directly to the tax authority.

The key here is that these taxes are to be calculated
on the same invoice, but these should not impact the amount payable
to the supplier, instead it should be accounted for as a tax liability.

The core requirements remain the same, however, the
terminology used for self-assessed taxes vary by tax regime, such
as reverse charges, use taxes, and offset taxes. Reverse charge is
the terminology primarily used in the European Union, use taxes is
the terminology used in the United States, and offset taxes is a alternate
solution to handle self-assessment of taxes and is not used by any
regime.

Oracle Fusion Tax provides the following options to
configure and automate calculation of self-assessed taxes:

Self-assessment

Offset taxes

Reporting-only taxes

Use taxes

Self-Assessment

Taxes need to be self-assessed by the purchasing organization
when the supplier is not registered in the ship-to or bill-to location
of the transaction. This is the recommended approach for defining
and calculating self-assessed taxes. This is driven based on the registration
party used for the transaction.

Registration Party

In the context of a tax applicable to the transaction
it is the party whose registration needs to be considered. The tax
registration party type default is specified for the tax. As most
of the taxes are assessed by the supplier, the default is set to the
ship-from or the bill-from location.

Supplier Tax Registration

You can define tax registration for the supplier,
the supplier site, and for a particular tax regime. If the tax registration
varies by tax or tax jurisdiction, define the registration at a granular
level. If the supplier does not have presence in a specific jurisdiction,
there are two options for configuration. The first is to create a
tax registration record with the registration status as not registered.
The second option is not to define a registration record. If you follow
the second option, when you define the condition set, set the operator
for the Registration determining factor class to Is blank.

Registration Party of the First Party

Similar to the supplier registration, you can define
the tax registration records for a legal reporting unit tax profile.
For the tax registration of the first party select the Set as self-assessment (reverse charge) option.
This option triggers self-assessment of taxes when the registration
party selected for the tax line is that of the first party. Self-assessment
is only applicable for Payables transactions. The option on the first
party registration does not impact Receivables transactions. Create
a tax registration rule to conditionally use the first party registration
when the supplier is not registered. The condition to use for this
tax rule is as follows:

Tax Determining Factor Class

Class Qualifier

Tax Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Equal to

Not Registered

If the registration records are not created for the
suppliers without registration, create the condition set as follows:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Is blank

Offset Taxes

Offset taxes is a backward compatible approach that
is configured to self-assess taxes. Configure offset taxes in addition
to your regular taxes. Offset taxes carry a negative rate and are
calculated in the context of the regular tax. Where offset taxes are
applicable, the application creates two tax lines with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Reporting-Only Taxes

You can identify taxes for reporting purposes only.
When these taxes are applicable to the transactions, records are created
in the tax repository entities. However, invoice distributions are
not created for these taxes. Therefore, there is no impact to the
payable amount, payment amount, and invoice accounting.

Use Taxes

Assigning use taxes to invoices, you create a record
of the taxes you owe to tax authorities. Oracle Fusion Payables does
not create invoice distributions for these taxes. Therefore, there
is not any accounting impact due to these taxes. Payables provides
a Use Tax Liability Report to review and report use taxes.

Use the Use Tax Liability Report to review, report,
and remit use taxes. The report determines the use tax liability by
each use tax code by taking the tax rate you defined for each tax
code and applying it to the sum of each invoice line to which the
tax applies. The report lists in summary or detail the total amount
of tax you owe for each tax code on invoices you enter between two
dates you specify when you submit the report. Oracle Fusion Payables
displays the amount of use tax you owe in the currency in which you
entered an invoice.

Note

Use taxes are defined with the tax type of Use tax. The rest of the configuration is
the same as the other taxes. This feature is only supported for migrated
taxes. You cannot define a new tax with this tax type.

Self-Assessment
of Taxes: How It Is Processed

You can let a first party self-assess the
taxes calculated on the Payables invoices it receives. A self-assessed
tax is a tax calculated and remitted for a transaction, where tax
was not levied by the supplier but is deemed as due (and therefore
needs to be paid by the purchaser). Taxes need to be self-assessed
by the purchasing organization when the supplier is not registered
in the ship-to or bill-to location of the transaction.

Settings That Affect Self-Assessment of Taxes

Configure your tax setup to automate self-assessment
of regular taxes. The following is an overview of the configuration:

Default registration party: Set the
default values for the direct rule type of Tax Registration. For self-assessed taxes set the value
to Ship from or Bill from.

Supplier registration: The supplier
can be registered or not registered. Configure your set up as follows:

If the supplier is registered the
application creates a record with the registration status of registered.
The registration of the supplier is considered and the taxes are assessed
by supplier and included as a part of the invoice total.

If the supplier is not registered
then either you can create a registration record for the tax regime,
tax, or tax jurisdiction, with the registration status of not registered.
Or skip the step of defining tax registration and define the tax condition
set with the operator of Is blank.

Selecting first party registration
conditionally: Create a registration record for the first party legal
reporting unit. For this registration record select the Set as self-assessment (reverse charge) option.

If the supplier is not registered then the registration
of the first party legal reporting unit needs to be considered. To
trigger this, you need to define a tax registration rule with the
following conditions:

If the ship-from or bill-from party
registration status is not registered or is blank then the registration
party is either the ship-to party or bill-to party. The following
is the condition set for the Determine Tax Registration rule:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Equal to

Not Registered

Transaction Input Factor

Line Class

Equal to

Standard Invoice

If you choose the option of not defining
a supplier registration then the condition set is as follows:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Is blank

Transaction Input Factor

Line Class

Equal to

Standard Invoice

Set the rule result to bill-to party so that the registration
of the legal reporting unit is considered.

Tip

Instead of including the condition for the transaction
input factor, you can specify the event class constraint at the tax
rule header.

Self-assessing tax: For the first
party registration record you create for the tax regime, tax, and
tax jurisdiction, check the Set as self-assessment
(reverse charge) option. Once the application selects
this registration record for the tax, the tax line is stamped as self-assessed.

How Self-Assessed
Taxes Are Processed

Taxes created by the first party organization need
to be calculated in the context of the transaction. The application
creates both summary and detail tax lines for these taxes and the
self-assessed option is enabled for these lines. Invoice lines are
not created for taxes, therefore the payable to the supplier does
not include these taxes. Invoice distributions are created to account
for the tax expense or recovery and liability.

Self-assessed taxes are not included in the invoice
totals. Instead, the total of self-assessed taxes for the invoice
is displayed as a separate line in the tax charges region of the invoice.

Self-assessed taxes are created for imported payables
invoices. This happens when imported transactions have tax lines along
with transaction lines and if you enable the Perform additional applicability for imported documents option for the event class. For these transactions, additional taxes
that are found applicable are treated as self-assessed taxes.

These taxes are accounted along with the rest of the
invoice. The accounting treatment for expense and recovery remain
the same as any supplier-assessed taxes. The only variation is be
the liability account. The tax amount is credited to the tax liability
account instead of the payables account.

Self-assessed taxes are a part of the standard tax
reports. Apart from this, Oracle Fusion Subledger Accounting provides
reports for accounting activity that can be used to track self-assessed
tax liability. Use the Account Analysis Report and the Open Account
Balance Listing report to track this liability.

Tax Line Override

You can override the self-assessed flag for the tax
line. This impacts the invoice lines and distributions. If you update
the summary tax line, all corresponding detail tax lines are updated
to reflect this change. If the self-assessed option on some of the
detail tax lines is updated then a new summary tax line is created
to group the detail tax lines that are being self-assessed.

Offset Taxes: How They Are Processed

Offset taxes are a backward compatible approach
that you can configure to self-assess taxes. Configure offset taxes
in addition to the regular taxes. Offset taxes carry a negative rate
and are calculated in the context of the regular tax. Where offset
taxes are applicable, two tax lines are created with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Settings That Affect Offset Taxes

For the offset tax calculation to take effect, do
the following:

Set up offset taxes

Enable offset tax calculation

You must perform these tasks for setting up offset
taxes:

Set up the offset tax, tax status,
and tax rate. Define at least one recovery type lookup to use with
offset taxes.

Create the offset tax and perform
the following:

Use the tax currency of the original
tax.

Select the Set as offset tax option.

Enter a primary recovery type that
you defined for offset taxes.

Set up the tax status for the offset
tax. Do not select the Allow tax rate override option.

Set up a 100% tax recovery rate for
the offset tax using the recovery type that is defined for the offset
tax.

You cannot update the recovery rate on an
offset tax line. The recovery rate is always 100% in order to create
credit entries that match the original tax amounts. When you create
an offset tax, you enter a primary recovery type with a recoverable
rate of 100% and a 100% recovery rate.

Set up the offset tax rate and perform
the following:

Enter a negative rate amount.

Assign the tax recovery rate that
is defined for offset tax.

Do not select the Allow ad hoc tax rate option.

Set up the original tax with the
required configuration to enable the tax. For the tax rate of the
original tax (nonoffset tax), assign the offset tax rate code in the Offset Rate Code field.

Complete the following configuration steps to enable
calculation of offset taxes for a transaction:

Select the Allow offset taxes option on the party tax profile if
offset taxes are to be calculated for the transactions created for
the party. Select this option for the party type chosen in the Offset Tax Basis field for the configuration
owner tax options.

How Offset
Taxes Are Processed

Offset taxes applicable to an invoice are created
with two tax lines entries, one for the tax and one for the offset
tax. The line for the offset tax has the offset option enabled. This
line carries the reference to the original tax line. Two Invoice lines
are created for these taxes, one for each tax.

The amount for the regular tax line is always debited
to the tax expense or recovery account or both, depending on the recoverability
of the tax. The credit is posted to a payables account which is offset
by the negative amount credited to the payables account due to the
offset tax line. The debit of the offset tax line is posted to the
tax liability account and this indicates the liability that the first
party organization has towards the tax authority for the self-assessed
tax.

Tax Line Override

You cannot override offset tax lines. However, you
can update the tax line calculated for the original tax. When you
update the tax rate percentage or amount or when you cancel the tax
line, the corresponding tax line for the offset taxes is updated.

Reporting-Only
Taxes: How They Are Processed

You can identify taxes for reporting purposes
only. When these taxes are applicable to the transactions, records
are created in the tax repository entities. However, invoice distributions
are not created for these taxes. Therefore, this does not impact the
payable amount, payment amount, and invoice accounting.

Settings That Affect Reporting-Only Taxes

You set up reporting-only taxes by selecting the Set tax for reporting purposes only option
for the tax.

How Reporting-Only
Taxes Are Processed

Tax lines for reporting-only taxes have the Reporting Only option enabled. Tax distributions
are not created for these tax lines.

For Oracle Fusion Payables invoices, these lines are
not displayed on the invoice lines. The total of the reporting-only
taxes are displayed in the tax totals region of the invoice.

For Oracle Fusion Receivables transactions, reporting-only
taxes are handled as any other tax. These taxes are considered as
a part of the invoice and are accounted for accordingly.

Tax Line Override

You cannot update the Reporting
Only option on the detail tax lines.

Manage Configuration Options and Service Subscriptions

Configuration
Options: Explained

Set up configuration options to associate
tax regimes with the parties in your company that have a tax requirement
under these tax regimes.

There are two fundamentally different approaches to
tax configuration options namely:

Using tax configuration setup defined
within Oracle Fusion Tax.

Using an external tax service provider.

Using Tax Configuration Setup Defined Within Oracle
Fusion Tax

Use the tax configuration setup in Oracle Fusion Tax
to calculate, record, and account for transaction taxes on transaction
taxable transactions.

The following concepts control how this setup is managed,
used, and shared:

Tax configuration owner

Tax content subscription

Existing tax option

Tax Configuration Owner

The tax configuration owner is a business unit, legal
entity, or the global configuration owner that owns the data. The
global configuration owner is an abstract owner which is used to define
the owner of content that can be shared by any business units and
first party legal entities.

Identify a specific first party legal entity as a
parent first party organization to allow the configuration to be owned
by a specific first party and shared by other parties. You can then
share this setup with another first party legal entity or business
unit for their transactions. Use a parent first party organization
tax configuration to share among a group of first party organizations
but you still have the tax setup managed by a single first party organization.

In the case of global configuration owner, if you
are assigned the Create Tax Regime privilege, you have update rights
to all tax configuration data maintained by the global configuration
owner.

Tax Content Subscription

Use tax content subscriptions to define which configuration
owner's setup is used for transactions for a specific first party
legal entity or business unit for a specific tax regime. Also, use
tax content subscriptions to specify whether any shared content can
be overridden by the subscribing party to allow unique, separate setup
for certain tax content.

Party override is permitted for the following setup:

Tax

Tax status

Tax rate

Tax recovery rate

Tax rules

Do this
indirectly by adding higher priority rules specific to the subscribing
first party legal entity or business unit.

The content subscription options are:

Tax Content Subscription

Description

Common configuration

For tax processing, the tax determination process
uses the shared tax content defined and maintained by the global configuration
owner.

Party-specific configuration

The specified first party organization defines and
maintains its own tax content. For tax processing, the tax determination
process uses only the tax content owned by the specific first party
legal entity or business unit.

Common configuration with party overrides

This option is similar to the common configuration
in that it allows you to use tax content owned by the global configuration
owner. However, you can also maintain party-specific content which
is used in preference to the common configuration content. In the
absence of tax content owned by the specific first party organization,
the tax determination process uses the tax content owned by the global
configuration owner.

Parent first party organization with party overrides

This option is similar to the common configuration
with party override subscription except instead of the tax content
being owned by the global configuration owner it is owned by a specific
first party legal entity. You can override the specific first party
setup.

A similar concept is used to define where you use
tax exceptions for a specific tax configuration. The tax subscription
option available for product exceptions is dictated to some extent
by the main tax content subscription as follows:

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

Parent first party organization with party overrides

Party-specific configuration

The specified first party organization defines and
maintains its own tax exceptions. For tax processing, the tax determination
process uses only the tax exceptions owned by the specific first party
organization.

Set up tax configuration options when you create a
tax regime or when you create a party tax profile for a first party
legal entity or business unit. Both setup flows display and maintain
the same party or regime definitions. Specify effective start and
end dates to identify which configuration should be used based on
the transaction date. You can enable the business unit so that Oracle
Fusion Tax automatically uses the configuration of the legal entity.
Once you set this option the application records the date it occurred
as the start date. This date is used and compared to the transaction
dates to identify if the application uses the legal entity subscription
in preference to the subscription of the business unit. The specific
first party legal entity that is used is defined by the legal entity
associated with the transaction.

Existing Tax Option

Copy a tax from an existing tax in the Manage Taxes
page to share tax registrations and tax jurisdictions while maintaining
two versions of the same tax, owned by two different tax configuration
owners each with their own tax statuses, tax rates, and tax rules.
For example, this is useful when you set up US sales and use tax that
requires a significant number of tax registrations and tax jurisdictions.

Using External Tax Service Provider

Oracle Fusion Tax lets you use the tax services of
external service providers for tax calculation of US Sales and Use
Tax on Receivables transactions. Oracle Fusion Tax provides transparent
integration between the external provide tax service and Oracle Fusion
Receivables.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

The setup for provider services is called a service
subscription. A service subscription applies to the transactions of
one configuration option setup for a combination of tax regime and
legal entity or business unit. Set up service subscriptions when you
create a tax regime or when you create a party tax profile for a first
party legal entity or business unit. Specify effective start and end
dates to identify which configuration should be used based on the
transaction date.

Content Subscriptions: Critical Choices

Choose which of the following tax content
subscription options to use to optimize your tax setup:

Whether to use service subscriptions
versus Oracle Fusion tax content.

What type of tax configuration options
to use.

When to change from business unit
to using tax configuration at the first party legal entity.

When to use create from an existing
tax option.

Using a Service Subscription Versus Oracle Fusion
Tax Content

Use the tax services of external service providers
where tax content is required for Receivables transactions for a significant
number of tax jurisdictions. You should not use a service provider
if their use is not needed to support US Sales and Use Tax regimes
or you need to create and maintain tax regimes outside of the Unites
States.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

Using Tax Configuration Options

If you decide not to use an external service
provider or you need to create tax content for tax regimes outside
the US then create and maintain your tax content in Oracle Fusion
Tax.

Once the decision is made to use Oracle Fusion Tax
you need to choose the level of tax configuration options. Sharing
tax content prevents the need for duplicate maintenance with its inefficiencies
and potential inconsistencies. Consider these scenarios and options:

Scenario

Option

You have a single central corporate tax center responsible
for maintenance of tax setup for all legal entities and business units.

Use the common configuration with party override option.
This allows a single tax setup to be created and maintained by the
corporate tax center.

You need to have strict control of who can maintain
the tax content.

Use the common configuration option. By not allowing
party override you restrict the access to the global configuration
owner to an authorized user who can maintain all of the tax content.

You have regional centers responsible for tax content.

Use the parent first party configuration with party
override option. This permits a regional setup with an actual or logical
parent legal entity to be created and maintained by each regional
center.

Even if there is no obvious need to share tax configuration,
for example, there is only a single first party legal entity operating
in each tax regime, significant business events such as takeovers
or mergers may mean that there could be a future need to share content.
In this case the original first party legal entity can act as the
configuration owner and then any subsequent first party can subscribe
to the first party's content using the parent first party configuration
with party override. Alternatively, set up the original tax content
using global configuration owner in preparation for any future business
event that requires tax content to be shared.

Changing from Business Unit to Using Tax Configuration
at the First Party Legal Entity

If you can standardize your tax setup across
all business units for a given legal entity then consider moving to
configuring and using tax setup at the legal entity level. Set the Use subscription of the legal entity option
on the business unit tax profile. Oracle Fusion Tax records the date
this occurs and compares it to the transaction date to identify if
the legal entity subscription should be used in preference to the
subscription to the business unit.

Using Create from an Existing Tax Option

Create a tax from an existing tax when you
have a need to share tax jurisdictions and tax registrations. You
maintain the tax jurisdictions and tax registrations once for taxes
with the same name within the same tax regime owned by different configuration
owners.

Tax Configuration
Options in the Tax Determination
Process: How They Are Used

At transaction time the owner of the transaction
derives the configuration options that are used. When you enter a
transaction for a given first party organization, the tax data applied
to that transaction is determined by the configurations defined for
the combination of that first party organization (business unit or
first party legal entity) and the tax regime derived from the addresses
or from the tax classification codes used on the transaction.

Settings That Affect the Application of Tax Data on Transactions

Use tax content subscriptions to define which configuration
owner's setup is used for transactions for a specific first party
legal entity or business unit for a specific tax regime. Also, use
tax content subscriptions to specify whether any shared content can
be overridden by the subscribing party to allow unique, separate setup
for certain tax content.

Tax content subscription options are:

Common configuration

Party-specific configuration

Common configuration with party overrides

Parent first party organization with
party overrides

How Tax Data Is Determined

Based on the defaults and tax rules you have defined,
tax data is applied to transactions as follows:

Configuration for Taxes and Rules Option

Tax Content Available

Common configuration

The tax determination process uses
only the tax content owned by the global configuration owner.

If you manually override tax information
on the transaction only tax content owned by the global configuration
owner is displayed in the list of valid values available.

Party-specific configuration

The tax determination process uses
only the tax content owned by the first party organization, business
unit or fist party legal entity, for whom the transaction is being
entered.

If you manually override tax information
on the transaction only tax content owned by the first party organization
is displayed in the list of valid values available.

Note

For the first party organization it can be the business
unit owning the tax content or the first party legal entity-owned
setup depending on the specific subscription being used.

Common configuration with party overrides

The tax determination process uses
any tax content owned by the first party for whom the transaction
is being entered. In the absence of tax content owned by that first
party organization, the tax determination process uses tax content
owned by the global configuration owner.

If you manually override tax information
on the transaction both the override tax content owned by the specific
first party and the tax content owned by the global configuration
owner that you have not overridden are displayed in the list of valid
values available.

Parent first party organization with party overrides

The tax determination process uses
any tax content owned by the first party for whom the transaction
is being entered. In the absence of tax content owned by the first
party organization, the tax determination process uses tax content
owned by the parent first party organization.

If you manually override tax information
on the transaction both the override tax content owned by the specific
first party and the tax content owned by the designated parent first
party organization that you have not overridden are displayed in the
list of valid values available.

If you are using product exceptions, those exceptions
are applied to the transactions as shown in the following table:

Configuration for Product Exceptions

Tax Exceptions Available

Common configuration

The tax determination process uses only the tax exceptions
defined and maintained by the global configuration owner.

Party-specific configuration

The tax determination process uses only the tax exceptions
owned by the specific first party organization

Setting Up
Tax Configuration Options: Worked Example

This example demonstrates how you set up the
appropriate tax configuration options for your company that has three
regional centers. These centers are responsible for tax setup and
maintenance among other corporate activities. Each of these regional
corporate centers is associated with a first party legal entity and
business unit.

Your company has their regional centers in:

North America (NAM), based in Redwood
City, California, US

Asian and Pacific (APAC), based in
Melbourne, Australia

Europe, Middle East, and Africa (EMEA),
based in London, UK

Each country has a single first party legal entity
with a single business unit, except for:

Countries which have the regional
corporate centers have a first party legal entity and business unit
for each corporate center.

Sales, marketing, and manufacturing
organization has a first party legal entity and business unit.

Create tax regimes for each country and the appropriate
tax configuration options.

Prerequisites

To create the appropriate tax configurations, you
must set up the following:

The legal entities for:

First Party Legal Entity

Country

EMEA LE

UK

GB LE

UK

FR LE

FR

DE LE

DE

APAC LE

AU

AU LE

AU

SI LE

SI

NZ LE

NZ

NAM LE

US

US LE

US

CA LE

CA

The sales, marketing, and manufacturing organization's
business unit uses the tax configuration of the legal entity.

Manage Tax Registrations

Tax Registrations: Explained

A tax registration contains information related
to a party's transaction tax obligation with a tax authority for a
tax jurisdiction where it conducts business. In some cases a single
location may need to file multiple registrations. Set up tax registrations
for your first party legal reporting units and your third party customers
and customer sites and suppliers and supplier sites.

Registering the details of a business with the relevant
tax authorities is a key legal requirement in many countries. A unique
tax registration number is generally assigned to the parties registering
with the tax authorities and is used as a basis for referencing and
tracking the tax implications on that party. To enable this process,
the registration numbers of the parties involved in a transaction
are generally referred to in tax documents like invoices and tax returns.
In some cases, the tax determination and its administration is also
dependent on the nature of the registration of the parties involved
in a transaction, such as the requirements associated with intra-European
Union (EU) reverse charge.

Setting Up a Tax Registration

You must set up a separate tax registration to represent
each distinct registration requirement for a first party. You optionally
set up tax registrations for your third parties, as necessary, to
support specific tax regulations or reporting requirements.

You can define tax registrations at three different
levels of detail. At the:

Tax regime level: The tax registration
is used for all taxes and tax jurisdictions within the tax regime.

Tax level: The tax registration is
used for all tax jurisdictions where the tax regime and tax are applicable.

Tax jurisdiction level: The tax registration
is applicable for the locations covered under the tax jurisdictions
defined for the tax regime, tax, and tax jurisdiction.

For each tax that you create, you must define either
a default tax registration or a tax rule for the rule type Determine
Tax Registration. If a party has more than one tax registration under
the same tax regime, then the tax determination process considers
the tax registrations in the order: tax jurisdiction; tax; and tax
regime.

For some countries, the application performs a validation
of the registration number you enter per the country algorithm.

You can define tax registrations as implicit. For
example, the party is not formally registered with the tax authority,
but the party is considered to meet one or more requirements for reporting
taxes because of the level of business conducted, typically a minimum
presence in the country and a minimum revenue threshold. Also, you
can define the tax registration with a status of not registered if
the party is not registered for the applicable tax, but you want to
use it as a tax condition to process the tax rules. Similarly, you
can use user-defined values and statuses, such as registered in EU
but not UK, to facilitate certain tax conditions. Apart from the core
tax registration information, you define additional details to facilitate
tax processing. The invoice control attributes such as self-assessment
and tax inclusiveness play a key role in tax processing. At transaction
time, the values set at the tax registration level override the values
set at the party tax profile level.

Using Tax Registrations in the Tax Determination
Process

The Determine Tax Registration process determines
the party whose tax registration is used for each tax on the transaction,
and, if available, derives the tax registration number. Once the process
identifies the tax registration or registrations, it stamps the transaction
with the tax registration numbers.

You can use the registration status to define various
tax rules. For example, if the tax is applicable only if the supplier
is registered, define the tax applicability rule as follows:

Determining factor class = Registration

Tax class qualifier = Ship-from party

Determining factor name = Registration Status

Operator = Not equal to

Value = Registered

Result = Not applicable

On the detail tax lines, the tax determination process
stamps two registration numbers. One is for the headquarters, the
main legal reporting unit of the legal entity of the document. The
other is for the party or party site identified by the tax registration
rule. For example, if the registration rule has identified ship to
as a party, then the tax determination process stamps the registration
number of the ship-to party on the transaction.

The tax determination process also considers these
details of the derived tax registration for each tax:

Tax inclusive handling: The inclusive
option set at the tax registration level for the party identified
by the tax registration rule overrides the inclusive option set at
the tax or party tax profile level for the tax line.

Self-assessment (reverse charge)
setting: The tax determination process considers the tax line as self-assessed
if the Set as self-assessment (reverse charge) option is selected at the tax registration level for the party identified
by the tax registration rule.

Rounding rule: The rounding rule
set at the tax registration level for the party identified by the
tax registration rule overrides the rounding rule set at the tax or
party tax profile level for the tax line.

Setting Up
Tax Registrations: Points to Consider

You must set up a separate tax registration
to represent each distinct registration requirement for a first party.
Optionally, set up tax registrations for your customers and suppliers,
as necessary, to support specific tax regulations or reporting requirements.
Oracle Fusion Tax uses tax registrations in tax determination and
tax reporting.

Tax Registration Options

Setting options at the tax registration level
can override options set at different levels. The following table
describes selective options available and the impact of selecting
these options:

Option

Description

Impact

Tax Regime

Enter the tax regime for this registration. Optionally,
enter the tax and tax jurisdiction for this registration.

The tax regime and optionally, tax and tax jurisdiction
are used to determine the correct tax registration at transaction
and reporting time.

Registration Type

If applicable, select a classification of the tax
registration.

The predefined tax registration types are specified
by the tax authority. The tax registration types are for reporting
purposes only.

Registration Number

Enter the company tax registration number assigned
by the tax authority.

If you set the tax regime option to use the legal
registration number as the tax registration number, then select the
registration number from the legal registration numbers in the list
of values.

If you set the Allow duplicate
tax registration numbers option for the tax, then multiple
parties and party sites can use the same tax registration number for
this tax.

Where applicable, Oracle Fusion Tax validates the
number according to tax authority validation rules.

Agent: The party acts as a withholding agent for the tax authority for
the applicable tax.

Registered: The party is registered for the applicable tax.

Not registered: The party is not registered for the applicable tax.

Use the tax registration status as a determining factor
in tax rules.

Source

Identify if this party is:

Explicit: The party is registered with the local tax authority and has a
tax registration number. In this case, you know that the party is
registered and the details including the tax registration number.

Implicit: The party is not formally registered with the tax authority, but
the party is considered to meet one or more requirements for reporting
taxes because of the level of business conducted. In this case, you
determine that the party is registered but you do not know the tax
registration number.

If the source is Explicit the tax registration number is required. If the source is Implicit the tax registration number is not
required.

Rounding Rule

The rule that defines how the rounding should be performed
on a value involved in a taxable transaction. For example, up to the
next highest value, down to the next lowest value, or nearest.

At transaction time, the values set at the tax registration
level override the values set at the party tax profile level.

Set as self-assessment (reverse
charge)

Set to automatically self-assess taxes on procure-to-pay
transactions. A self-assessed tax is a tax calculated and remitted
for a transaction, where tax was not levied by the supplier but is
deemed as due and therefore, needs to be paid by the purchaser.

You can set the self-assessment option at the tax
profile level to default to the tax registrations that you create
for this party. You can also set it at the tax registration level
or on an individual tax line.

Oracle Fusion Tax applies self-assessment to Payable
invoices received by the first party according to the tax registration
setting. The specific tax registration record is derived either from
the Determine Tax Registration rules or from the default tax registration.

Set Invoice Values as Tax
Inclusive

Select if this party intends to send or receive invoices
with invoice line amount inclusive of the tax amount.

At transaction time, the values set at the tax registration
level override the values set at the party tax profile level. In addition,
this option at the tax registration level overrides the tax inclusive
handling setting at the tax level, but not at the tax rate level.

Reporting
Tax Authority: The tax authority responsible for receiving
and processing all company transaction tax reports.

If defined, the reporting and collecting tax authorities
appear as defaults from the tax jurisdiction associated with this
registration. If necessary, enter or update these fields with tax
authorities specific to this tax registration.

Manage Tax Reporting Configuration

Global Tax Reporting: Explained

The global tax report processing feature provides
a reporting solution for all countries to manage their tax reporting
requirements. For some Europe, Middle East, and Africa (EMEA) countries, Oracle Fusion Financials for EMEA provides predefined
reports, such as Italian VAT registers and Spanish
VAT journals. For other countries, you can use the tax data models
to create your required reports.

Use the global tax report processing feature to organize
tax report data according to the requirements of your company and
the tax authority. The EMEA reports make use of the Oracle Fusion
tax data models to retrieve tax transaction information based on your
tax configuration setup.

Processing Your Tax Reports

Set up prerequisite information for
tax reporting. This includes setting up the appropriate tax reporting
codes for the EMEA VAT tax reporting type and associating the tax
reporting type and tax reporting codes to the tax setup.

Set up tax configuration details such
as tax reporting entity and tax register.

Enter report processing details for
a transaction such as tax reporting date.

Run the Tax Selection Process that
selects all the transactions that are accounted, unaccounted, or both
to report within a tax period. You can run tax reports, general and
country-specific, for unaccounted, accounted, and both unaccounted
and accounted transactions. This helps you to run trial reports and
make any corrections before submitting the final report to tax authorities.
The selection is based on the tax registration number and tax reporting
date, if you have completed the tax setup in Oracle Fusion Tax.

Note

You must set up the tax reporting configuration prior
to running the Tax Selection Process.

To process value-added tax (VAT) reports, you must set
up the tax reporting entities for the tax registration number associated
with a legal entity and tax regime. When you run the selection process,
each selected transaction is stamped with the legal reporting entity
ID. You run VAT reports based on the tax reporting entity.

Note

Ensure that you define tax registrations for all legal
reporting units that have the applicable VAT tax requirement.

You can customize your VAT reporting process by specifying
the tax calendar for a tax reporting entity, threshold amounts, and
VAT registers. The setup includes:

Common Configuration: Associate the
calendar defined for tax reporting to the combination of tax registration
number, tax regime, and legal entity. Choose the tax registration
numbers that you defined in Oracle Fusion Tax against legal entities
and VAT tax regimes.

Tax Registers: Record register information
and associate it with a tax reporting entity to determine document
sequences. Assign one or more document sequence names for each VAT
register. The Italian VAT register reports use the VAT register information.

Common Configuration for VAT Reporting

Common configuration for VAT reporting helps
you to configure attributes which are common for all tax reporting
entities like tax calendar, tax reporting date, reporting threshold
amount, and reporting sequence. The tax calendar makes use of accounting
period types and calendars, and is maintained independently of the
accounting calendar to control tax periods for reporting transactions
based on a tax reporting date. Apply a single tax calendar to one,
more than one, or all tax reporting entities within your organization.
Set up a unified tax reporting period across a legal entity or single
legal reporting unit for the correct application of transactions against
their tax reporting dates. This provides a clear operational procedure
for identifying those transactions that should be declared in the
next tax return for the current open period as regular entries or
whether the transaction should be entered in the next tax return as
corrections.

The following table describes the common configuration
options for VAT reporting:

Name

Description

Tax Calendar

Select the calendar to be associated to the tax reporting
entity.

Threshold Amount

Enter the threshold amount specified for the legal
entity or tax regime that have tax transactions. If you leave this
field blank, then the application reports all tax transactions.

Some countries like Spain report transactions or make
declarations to the authorities if the amount is over a certain threshold
value.

Enable Reporting Sequence

Select to enable report level sequence number while
running the reports. For numbering transactions, you can print the
document sequence number for the transaction, or you can print the
report-specific sequence number.

Tax Reporting Date

Select the country's tax reporting date based on the
tax registration number. You can select one or more options depending
on your reporting requirements. For example, you could select the
accounting date and transaction date options to meet Spanish-specific
VAT reporting requirements.

Tax Registers for VAT Reporting

Define tax registers for a tax reporting entity
and assign a document sequence name to a combination of tax register
and tax reporting entity. The application selects transactions to
be reported on a tax register based on the document sequence name
assignment once you define a tax register and assign a document sequence
name. Use this setup for Italy only.

Setting Up VAT
Reporting: Worked Example

This example demonstrates how you set up the
appropriate tax registers for your organization located in Italy so
you can meet your tax reporting requirements.

Prerequisites

To process VAT reports, implementers and financials
personnel perform the following prerequisites:

Set up legal entities and legal reporting units using
the Legal Entity Configurator to
represent your company and its offices. For example, set up Vision
Italy as a legal entity.

Set up and maintain the first party tax profiles
and tax registrations in the context of tax regime for the legal reporting
units in your company using Oracle Fusion Tax.

Set up the tax regimes for the taxes in each country
and geographic region where you do business and where a separate tax
applies using Oracle Fusion Tax. For example, set up IT VAT as a tax
regime. Enable the Use tax reporting configuration option on the first party tax regime to allow entry of tax reporting
configuration details during tax registration setup for legal reporting
units for these tax regimes.

Set up the tax and tax rates in Oracle Fusion Tax.
You must define the tax with the reporting code enabled. EMEA lookup
tax reporting codes, such as VAT and Exempt, are available as
predefined tax reporting codes under the EMEA VAT Reporting Type.

Define tax reporting periods as accounting periods
in Oracle Fusion General Ledger. For example, set up Accounting as
an accounting period. The final reporting process maintains the tax
reporting periods. If you use the same calendar for accounting and
tax reporting, the application still maintains accounting periods
independently from tax periods.

Specify document sequencing for tax transactions
if you need to use different transaction sequencing that reporting
sequencing. Define document categories in General Ledger, Payables,
and Receivables. Define document sequence names in General Ledger
and assign them to document categories. For example, set up IT AX
Payables as a document sequence name.

Setting Up VAT Reporting

On the Manage Legal Reporting Unit Tax Profiles page
enter Vision Italy in the Legal Entity field and click Search.

From results table, select the row for the currently
active Vision Italy and click Edit .

FAQs for Define First Party Tax Profiles

When does a party
tax profile get created for a business unit?

The business unit party tax profile is automatically
created when a business unit record is created. If a business unit
party tax profile record is not created, for example, when a business
unit is created through a back-end process, a business unit party
tax profile is created upon saving a tax regime when a business unit
is subscribed to or upon saving the configuration owner tax options
when they are defined for the business unit. Otherwise, create a party
tax profile using the Create Business Unit Tax Profile page. You can
edit the tax profile that was automatically generated with the relevant
tax information, but it is not required.

What happens if I use the subscription from the legal entity?

Under most circumstances your business unit
uses the tax setup based on the configuration of the legal entity.
When you first access the Create Business Unit Party Tax Profile page
you can select the Use legal entity tax subscription option. If you select this option, you cannot update the business
unit tax profile or maintain separate tax content for this business
unit. If you do not select this option you enter the relevant tax
information for the business unit. This is an irreversible setting.

When does a party
tax profile get created for a legal entity?

The legal entity party tax profile is automatically
created when a legal entity record is created. If a legal entity party
tax profile record is not created, for example, when a legal entity
is created through a back-end process, a legal entity party tax profile
is created upon saving the tax regime when a legal entity is subscribed
to or upon saving the configuration owner tax options when they are
defined for the legal entity. Otherwise, create a party tax profile
using the Create Legal Entity Tax Profile page. You can edit the tax
profile that was automatically generated with the relevant tax information,
but it is not required.

When does a party
tax profile get created for a legal reporting unit?

The legal reporting unit party tax profile
is automatically created when a legal reporting unit is created. Otherwise,
create a party tax profile using the Create Legal Reporting Unit Tax
Profile page. You can edit the tax profile that was automatically
generated with the relevant tax information, but it is not required.

What's a service
subscription?

A service subscription is the setup for provider
services. It applies to the transactions of one configuration option
setup for a combination of tax regime and legal entity or business
unit. Oracle Fusion Tax lets you use the tax services of external
service providers for tax calculation of US Sales and Use Tax on Oracle
Fusion Receivables transactions.

You can use the tax services of these external service
providers:

Taxware, LP: a First Data Company

Vertex, Inc.

If you integrate with a tax service provider, these
actions are not required for Receivables transactions:

Tax service provider integration returns the calculated
tax lines to Oracle Fusion Tax. The tax lines for Receivables transactions
returned by tax service providers are stored in Oracle Fusion Tax
similar to the way tax lines calculated by the application itself
are stored.

Manage Intrastat Country Characteristics

Using Triangulation
Method: Examples

You can specify how triangular trade transactions
will be analyzed for the generation of Intrastat report of an individual
country.

You can report triangular trade transactions by:

Invoice- A triangular trade transaction
is reported in the Intrastat report based on the issue of an invoice.
A record is created based on the invoice and not the physical movement
of goods.

Shipment- A triangular trade transaction
is reported in the Intrastat report based on the physical movement
of goods. A record is created based on the physical movement of goods
and not the invoice.

You can also specify who declares the transaction
when the seller is the same country as the shipper and the customer
to avoid duplication of records in the Intrastat report.

Examples of the how triangular trade transactions
are reported are discussed for the following scenarios:

Shipment based triangular trade transactions

Your company based in Italy receives an order from
a German company. To fulfill the order, you order goods from your
supplier in the France. The goods are delivered from the French company
to the German company.

The following transactions are created as a result
of this triangular trade:

You send a sales order to your customer
in Germany

You invoice your customer in Germany

You create a purchase order to your
supplier in France

Your supplier in France sends you
an invoice

France creates a shipment to Germany,
fulfilling the sales order

If you have selected Shipment as your triangulation
method, then no record is generated for inclusion in the Intrastat
report since no physical movement of goods occurred in Italy. However,
Germany is required to declare the arrival of goods from France.

Invoice based triangular trade transactions

Considering the example of the triangular trade transaction
scenario given above, if you have selected Invoice as your triangulation
method, then:

A sales order or dispatch record
is generated from Italy to Germany with the following information:

Movement Amount: zero (no movement
of goods took place between these countries)

Movement Quantity: zero (no movement
of goods took place between these countries)

Movement Quantity: zero (no movement
of goods took place between these countries

Extended Value: is calculated as
the receipt quantity multiplied by unit price

Dispatch Country: France

Destination Country: Germany

Note

Germany is required to declare the arrival of goods
from France.

Required Attributes: Points to Consider

You can define the required set of attributes
that need to be reported in the Intrastat report for an individual
country. These attributes can be defined for both the Arrival and
Dispatch flow types.

Before selecting the required attributes, consider:

What is the required set of attributes
for the individual country for the Arrival flow?

What is the required set of attributes
for the individual country for the Dispatch flow?

Arrival

The Intrastat authority of an individual country
requires that a specific set of attributes should be included in the
Intrastat report for an Arrival flow. Before selecting the required
attributes for the Arrival flow type, you must consider:

Commodity description

Consider if a description of the commodities arriving in the country
should be provided in the Intrastat report.

Freight terms

Consider if the freight terms or Incoterms applicable for the arrival
transaction should be provided in the Intrastat report.

Mode of transport

Consider if the mode of transport for every arrival transaction is
provided in the Intrastat report.

Region of destination

Consider if the details of the region within the destination or
receiving country where the good will be finally consumed should be
provided in the Intrastat report.

Country of origin

Consider if the details of the dispatch country from where the goods
originated should be provided in the Intrastat report.

Nature of transaction code

Consider if the Nature of transaction code details of
the arrival transaction should be provided in the Intrastat report.
Nature of transaction codes is published by an individual country's
Intrastat authority and hence may vary based on country.

Fiscal regime

Consider if the Fiscal regime details for the arrival transaction
should be provided in addition to the Nature of transaction code details
in the Intrastat report.

Statistical procedure

Consider if the Statistical procedure code details for the arrival
transaction should be provided in addition to the Nature of transaction
code details in the Intrastat report.

Note

You can provide either the Fiscal regime attribute
or the Statistical procedure attribute.

Net Mass

Consider
if the net mass of the transaction, which is the quantity of items
multiplied by the unit weight of the item, should be provided in the
Intrastat report.

Invoice amount

Consider if the actual invoice amount that is already created for
the transaction should be provided in the Intrastat report.

Dispatch

The Intrastat authority of an individual country
requires that a specific set of attributes should be included in the
Intrastat report for a Dispatch flow. Before selecting the required
attributes for the Dispatch flow type, you must consider:

Freight terms

Consider if the freight terms or Incoterms applicable for
the dispatch transaction should be provided in the Intrastat report.

Mode of transport

Consider if the mode of transport for every dispatch transaction
is provided in the Intrastat report.

Region of origin

Consider if the details of the region within the dispatching country
from where the goods are dispatched should be provided in the Intrastat
report.

Country of origin

Consider if the details of the dispatch country from where the goods
originated should be provided in the Intrastat report.

Nature of transaction code

Consider if the Nature of transaction code details of
the dispatch transaction should be provided in the Intrastat report.
Nature of transaction codes is published by an individual country's
Intrastat authority and hence may vary based on country.

Fiscal regime

Consider if the Fiscal regime details for the dispatch transaction
should be provided in addition to the Nature of transaction code details
in the Intrastat report.

Statistical procedure

Consider if the Statistical procedure code details for the dispatch
transaction should be provided in addition to the Nature of transaction
code details in the Intrastat report.

Note

You can provide either the Fiscal regime attribute
or the Statistical procedure attribute.

Net Mass

Consider
if the net mass of the transaction, which is the quantity of items
multiplied by the unit weight of the item, should be provided in the
Intrastat report.

Invoice amount

Consider if the actual invoice amount that is already created for
the transaction should be provided in the Intrastat report.

Intrastat Rule
Types: Explained

Intrastat rules are used to configure Intrastat
reporting as per the requirement of an individual country. Intrastat
rules enable you to define the guidelines and validations that are
applicable for creating the Intrastat Declaration. These rules can
be shared across Legal Reporting Units or can be specific to one Legal
Reporting Unit.

The 7 Intrastat rule types that can be used to define
the reporting criteria for Intrastat transactions are:

Validation

Supplementary UOM

Nature of Transaction Code

Fiscal Regime

Statistical Procedure Code

Statistical Value Calculation

Exclusion

Validation Rules

Validation rules enable you to define the
criteria for validating the collected and manually entered Intrastat
transactions. Only those transactions that are validated successfully
as per the specified criteria can be reported in the Intrastat declaration.
Validation rules are defined for a combination of source transaction
and Intrastat reporting attribute.

Validation rules enable you to specify the following:

the required attribute to be reported
for a particular source transaction

the value set that should be used
for validating the values of the specific attributes

Note

If an attribute is defined as required for a source
transaction, then an exception is logged if the collected transaction
does not have that attribute.

Supplementary UOM

Supplementary UOM rules enable you to define
the requirement for reporting Intrastat transactions in a supplementary
UOM other than the weight UOM. The movement of goods or specific items
is reported in an UOM other than the weight UOM. For example, it specifies
that movement of commodity, Oil, should be reported in Barrels.

Supplementary UOM rules are defined for a category
code under the Intrastat catalog. And that category code in turn defines
the UOM in which the Intrastat transaction is reported. Whenever there
is an item in an Intrastat transaction that belongs to the specific
category code, then the supplementary UOM rule is applied. The quantity
of the item is thereby derived in supplementary UOM based on the UOM
conversion factor.

Nature of Transaction Code

Nature of Transaction Code is used to define
the category of the Intrastat transaction. The Nature of Transaction
Codes are published by the Intrastat authority of an individual country
and hence differ based on country. The codes can be either in single
digit or double digits.

The Nature of Transaction Code rules enable you to
define the Nature of Transaction Code applicable based on source transaction,
inventory organization, item, and trading partner attributes of the
base transaction. The rules defined at a specific or granular level
are given priority over rules defined at a higher level. For example,
there are two rules; one for a Source Transaction and other for a
Source Transaction and Item. In this case, the rule for Source Transaction
and Item is given higher priority wherever applicable.

Fiscal Regime Code

Fiscal Regime Code is used in some countries
in addition to Nature of Transaction Code in to categorize transactions.
Fiscal Regime rules define the Fiscal Regime Code applicable based
on source transaction, inventory organization, item, and trading partner
attributes of the base transaction. Similar to the Nature of Transaction
Code rules, the Fiscal Regime Code rules defined at a specific or
granular level are given priority over rules defined at a higher level.

Note

You can only define either a Fiscal Regime Code or
a Statistical Procedure Code for a particular transaction.

Statistical Procedure Code

Statistical Procedure Code is used in some
countries of the European Union in addition to Nature of Transaction
Code in to categorize transactions. Statistical Procedure Code enables
you to define the Statistical Code applicable for deriving the statistical
procedure of the collected transaction. This is based on source transaction,
inventory organization, item, and trading partner attributes of the
base transaction.

Note

You can only define either a Statistical Procedure
Code or a Fiscal Regime Code for a particular transaction.

Statistical Value Calculation

Statistical value calculation rules enable
you to specify the freight factor that is included in the statistical
value. Freight factor is defined in percentage and indicates the component
of freight charge that should be included in the statistical value.

You can define this rule based on country, organization,
item, freight terms, and mode of transport of the base transaction.
You can then specify the freight factor, which is a percentage of
the freight charge. This freight factor is included while calculating
the statistical value. For example, you need to only include the freight
charge up to the country's border for a dispatch transaction. You
can specify this by defining a freight factor that accounts for the
freight charge up to the country's border only.

Note

In cases where freight charges are applicable for
shipments across two countries within the European Union, you are
required to only include the freight charge for moving the goods from
the establishment to the border of the country.

Exclusion

Exclusion rules enable you to define the criteria
to exclude specific goods movement transactions from collections.
You can exclude a specific item that you do not want to be reported
in the Intrastat collections by defining the exclusion criteria in
the rule. For example, you don't require service items to be included
in the collection. You can define this rule based on source transaction,
organization, category code, item, and trading partner of the base
transaction. You can specify the exclusion criterion that includes
the source transaction, category code, and item details of the transaction
containing the service items. This ensures that the specified items
are not included in the collections.

FAQs for Manage Intrastat Country Characteristics

Can I define
Intrastat parameters for any legal reporting unit?

No, Intrastat parameters cannot be defined
for every legal reporting unit. They can be defined only for the legal
reporting units where the country characteristics are defined for
the country of the legal reporting unit. If the Intrastat parameters
are to be defined for a secondary legal reporting unit, then the secondary
legal reporting unit must be associated with an inventory organization.

Can I configure
Intrastat according to individual country guidelines?

Yes. Intrastat rules can be used to configure
Intrastat reporting as per the guidelines of an individual country
of the European Union. You can specify the validations that are applicable
for creating the Intrastat Declaration.

Can I identify
exceptions in the collected transactions?

Yes. Use an Exception
Validationrule to identify exceptions in the collected
transactions. The exception validation process uses validation rules
to identify if there are any exceptions in the transactions that might
cause noncompliance issues during submission of declarations.

Can I use the supplementary UOM reporting requirement for specific item
categories?

Yes. Supplementary UOM rules are used to define
reporting requirements for certain commodity codes or item categories
in alternate UOMs other than the weight UOM. For example, it may be
required to report liquids in Liters.

Can I use the
statistical value calculation for including freight values in the
statistical value?

Yes. Statistical value calculation can be
used to represent an approximate freight factor for a set of qualifiers
like mode of transport, item category, etc. For example, some countries
require including the freight cost incurred within the country of
reporting in the statistical value. In this case, you can use the
statistical value calculation to specify the freight values.

Manage Configuration Owner Tax Options

Tax Settings
and Rules: How They Apply to Tax Line Operations

Enter and update detail and summary tax lines
according to the requirements of your transactions. Depending on your
security settings and options specified during tax setup, you can:

Enter manual tax lines

Enter tax only tax lines

Change existing tax line information

Cancel tax lines

Note

The Summary Tax Lines component is applicable only
to Oracle Fusion Payables.

Entering Manual Tax Lines

These requirements apply to entering a manual detail
or summary tax line:

Enable the Allow
entry of manual tax lines option for the:

Configuration owner and application
event class

Tax

Ensure that the Manual Tax Line Entry profile option is enabled. It is
enabled by default.

Enter a unique combination for a tax
regime and tax. You cannot enter a manual tax line for a tax that
already exists for the transaction line.

The tax calculation on a manual tax line is a standard
formula of Tax Amount = Taxable Basis * Tax Rate. The tax determination
process does not evaluate tax rules defined for the tax of any tax
rule type.

Entering Tax Only Tax Lines

You can enter a tax-only invoice in Payables to record
tax lines that are not linked to a transaction. A tax-only invoice
is used, for example, to record tax lines on purchases that are assessed
and invoiced separately or to enter tax-only invoices from tax authorities
or import agents that record import taxes.

These requirements apply to entering a tax only tax
line:

Enable the Allow
manual tax only lines option for the configuration owner
and application event class.

Select a tax regime from the tax regimes
belonging to the configuration option of the applicable legal entity
or business unit.

Select a tax, tax status, and tax
rate and enter a tax amount.

Editing Tax Line Information

These requirements apply to changing an existing detail
or summary tax line:

Enable the Allow
override for calculated tax lines option for the:

Configuration owner and application
event class

Tax

Ensure that the Manual Tax Line Entry profile option is enabled. It is
enabled by default.

Optionally, enable the following options
for the configuration owner and application event class:

Allow recalculation
for manual tax lines option. The tax determination process
recalculates the manual tax lines when there is an update to automatically
calculated tax lines.

Tax line override
impacts other tax lines option. The tax determination
process recalculates the taxes on all other tax lines on the same
transaction when there is an override of automatically calculated
tax lines on transactions.

Save any changes to summary tax lines
before you enter or change Payables summary tax lines.

Change the tax status if necessary.
These requirements apply to changing tax statuses:

You cannot update the tax status if
the tax on the detail tax line is enforced from the natural account.

If you edit a tax only tax line and
change the tax status, you must re-enter the tax rate code.

Change the tax rate if necessary. These
requirements apply to changing tax rates:

The Allow tax
rate override option is enabled for the applicable tax
status.

The Allow ad
hoc rate option is enabled for the applicable tax rate.

You may need to change the tax status
to change to the appropriate tax rate.

You can change the calculated tax rate
derived from the tax status by selecting another tax rate defined
for the same tax regime, tax, and tax status.

If selected then it triggers tax calculation to determine
additional taxes on imported documents

Enforce tax from reference document

Controls whether tax calculated on another related
document is used as the basis of tax on a new document

None

None

If selected then it enforces that tax calculation
is based on the tax previously calculated on the reference document

Enforce tax from account

Controls whether tax rates are determined from account
information associated with the transaction line

None

None

If selected it enforces that tax calculation is based
on the tax account information associated with the transaction tax
line

Allow offset tax calculation

Controls whether offset tax calculation is used at
transaction time

None

None

If not selected it prevents offset tax calculation
at transaction time for this configuration owner, application, and
event class

Allow tax applicability

Controls whether tax is automatically calculated at
transaction time

None

None

If not selected it prevents automatic tax calculation
at transaction time for this configuration owner, application, and
event class

Allow entry of manual tax lines

Controls whether you can enter manual tax lines at
transaction time

None

None

Use this option in conjunction with Allow entry of manual tax lines option for
the tax. When both fields are set you can enter manual tax lines at
transaction time.

Allow recalculation of manual tax lines

Controls whether tax is recalculated when you enter
manual tax lines

None

None

If selected then tax is recalculated for manual tax
lines when you update transaction lines

Allow override of calculated tax lines

Controls whether you can override calculated tax lines
at transaction time

None

None

Use this option in conjunction with the Transaction
Tax Line Override profile option and the Allow
override of calculated tax lines option for the tax. When
all options are selected you can update the calculated tax line, excluding
the update of the Inclusive option
and the tax rate. To update the Inclusive option and tax rate at transaction
time you need to select additional options for the tax rate.

Tax line override impacts other tax lines

Controls whether other taxes are calculated if you
update the tax line at transaction time

None

None

Where transaction line tax can be changed this option
controls whether other related taxes may be impacted and therefore,
need to be recalculated

Allow override and entry of inclusive tax lines

Controls whether you can override and enter inclusive
or exclusive line amounts

None

None

Use this option in conjunction with the Transaction
Tax Line Override profile option, the Allow
override of calculated tax lines option for the configuration
owner tax options, and the Allow override
and entry of inclusive tax lines option for the tax rate
to allow you to update the Inclusive option on the tax line at transaction time

The following table describes the defaults and controls
available at the configuration owner tax options level for the following
applications and event classes:

Receivables: Credit Memo

Receivables: Debit Memo

Receivables: Invoice

Default Tax Options Region

Field

Description

Default Derived from

Default Appears on

Controls

Allow exemptions

Controls where tax exemptions are allowed

None

None

If not selected it prevents tax exemptions for this
application, event class, and configuration owner

Regime Determination Set

Controls which determination method is used

None

None

Controls whether the tax determination process uses
the migrated 11i approach using standard tax classification codes
where the value is STCC or full
regime determination using the predefined rule of TAXREGIME to determine applicable tax regimes or user-created
regime determination rules

Enforce tax from account

Controls whether tax rates are determined from account
information associated with the transaction line

None

None

If selected it enforces that tax calculation is based
on the tax account information associated with the transaction tax
line

Allow tax applicability

Controls whether tax is automatically calculated at
transaction time

None

None

If not selected it prevents automatic tax calculation
at transaction time for this configuration owner, application, and
event class

Allow entry of manual tax lines

Controls whether you can enter manual tax lines at
transaction time

None

None

Use this option in conjunction with Allow entry of manual tax lines option for
the tax. When both fields are set you can enter manual tax lines at
transaction time.

Allow recalculation of manual tax lines

Controls whether tax is recalculated when you enter
manual tax lines

None

None

If selected then tax is recalculated for manual tax
lines when you update transaction lines

Allow override of calculated tax lines

Controls whether you can override calculated tax lines
at transaction time

None

None

Use this option in conjunction with the Transaction
Tax Line Override profile option and the Allow
override of calculated tax lines option for the tax. When
all options are selected you can update the calculated tax line, excluding
the update of the Inclusive option
and the tax rate. To update the Inclusive option and tax rate at transaction
time you need to select additional options for the tax rate.

Tax line override impacts other tax lines

Controls whether other taxes are calculated if you
update the tax line at transaction time

None

None

Where transaction line tax can be changed this option
controls whether other related taxes may be impacted and therefore,
need to be recalculated

Allow override and entry of inclusive tax lines

Controls whether you can override and enter inclusive
or exclusive line amounts

None

None

Use this option in conjunction with the Transaction
Tax Line Override profile option, the Allow
override of calculated tax lines option for the configuration
owner tax options, and the Allow override
and entry of inclusive tax lines option for the tax rate
to allow you to update the Inclusive option on the tax line at transaction time

Define Italian Exemptions

Italian Exemptions: Explained

In Italy, export transactions are exempted
from value-added
tax (VAT), but companies that are classified as regular exporters
have more input VAT than output VAT. Italian law lets you claim an
exemption if you meet certain legal requirements.

These legal requirements are:

You have a regular exporter ratio
that is higher than 10 percent.

The value of goods and services that
you purchased without VAT charges last year is lower than your exemption
limit.

You declare all export activities
to your tax authorities.

The exemption limit is the total VAT exemption amount
that a regular exporter can claim to its suppliers. For each year,
the initial exemption limit is the sum of all reported export invoices
of the previous year. You can allocate your yearly exemption limit
among different suppliers. To each supplier, you send exemption letters
that indicate the exemption amounts and request that they do not charge
you tax when they send you the according invoices.

At the end of the year, if your total exempt purchases
of goods and services is higher than your exemption limit, you incur
administrative sanctions and penalties. Use the Italian Supplier Exemption
Limit Consumption report to help you keep track of your exemption
limit consumption. Use the Italian Exemption Limit Declaration report
to report exemption details to the tax authority.

To set up for the exemption process:

Manually calculate the initial exemption
limit for the current year by summing all reported invoices of the
previous year. The tax authority must agree upon the exemption limit.

Use the Create Exemption Limit page
from the Manage Italian Exemption Limits page to set up a new exemption
limit year for your legal entities. Optionally, use the Adjust Exemption
Limit page from the Manage Italian Exemption Limits page to adjust
the yearly exemption limit.

Use the Create Exemption Letters
page from the Manage Italian Exemption Letters page to allocate exemption
limits to your suppliers and set up the exemption letters to send
to your suppliers.

Use Oracle Fusion Tax to create tax
reporting types for each of your exemption limit groups. You can also
define tax reporting codes within these tax reporting types for further
tax reporting granularity.

FAQs for Define Italian Exemptions

How do I apply
exemption limits to invoices?

Create a tax reporting type and codes for
exemption letters and assign them to the Exemption
Limit Tax Tag for Italian Exemption Letters profile option.
At the distribution level of the invoice you associate appropriate
invoice lines with an exemption limit group. Enter a tax rate code
of a tax reporting type according to the value defined in your profile
option. When you run the Italian exemption reports, the report logic
determines the value of the profile option, and selects all invoices
with the related tax reporting codes.

Can I adjust
the monthly limits once they are created?

Use the Exemption Limit window to modify (add
or subtract) either the current month amount or adjust the current
month and future periods. For example, you want to reduce the current
month and future periods limit by 25,000 EUR. Enter -25,000 in the Monthly Adjustment field and select the Adjust selected and subsequent months radio
button. The application subtracts 25,000 from the current month amount
and from each of the remaining month amounts in the calendar year.

What are the letter types for Italian exemptions?

If you want to assign exemption limits to
the supplier, enter a letter type in the Letter
Type field.

Options include:

Exempted
Amount: Exemption letter with exemption limit printed.

Exempted
Period: Exemption letter with a date range.

Specific
Operation: Customs letter for a single transaction.

Note

The default is Exempted Amount, which is the only type that prints an exemption limit amount on
the letter.

Define Third Party Tax Profiles

Party Tax Profiles: Explained

A tax profile is the body of information that
relates to a party's transaction tax activities. A tax profile can
include main and default information, tax registration, tax exemptions,
party fiscal classifications, tax reporting codes, configuration options,
and service subscriptions.

Set up tax profiles for the following parties involved
in your transactions:

First parties: All legal entities,
legal reporting units, and business units in your organization that
have a transaction tax requirement.

Third parties: Your customers and
suppliers and their locations and banks.

Tax authorities: Parties that administer
tax rules and regulations.

First Parties

Set up tax profiles for your first party legal entities,
legal reporting units, and business units.

First party legal entities identify your organization
to the relevant legal authorities, for example, a national or international
headquarters. Legal entities let you more accurately model your external
relationships to legal authorities. The relationships between first
party legal entities and the relevant tax authorities normally control
the setup of the transaction taxes required by your business. Under
most circumstances the tax setup is used and maintained based on the
configuration of the legal entity. Enter the default information,
party fiscal classifications, tax reporting codes, and configuration
options for your legal entities. You can also specify if you are using
the tax services of an external service provider for tax calculation.

First party legal reporting units identify each office,
service center, warehouse and any other location within the organization
that has a tax requirement. A legal reporting unit tax profile is
automatically created for the headquarter legal entity. Set up additional
legal reporting unit tax profiles for those needed for tax purposes.
For legal reporting units, enter the default information, tax registrations,
party fiscal classifications, and tax reporting codes. Also, define
tax reporting details for your VAT and global tax reporting needs
for tax registrations of tax regimes that allow this setup.

Business units organize your company data according
to your internal accounting, financial monitoring, and reporting requirements.
To help you manage the tax needs of your business units, you can use
the business unit tax profile in either of two ways:

Indicate that business unit tax setup
is used and maintained based on the configuration of the associated
legal entity at transaction time. The tax setup of the associated
legal entity setup is either specific to the legal entity or shared
across legal entities using the Global Configuration Owner setup.

Indicate that tax setup is used and
maintained by a specific business unit. Create configuration options
for the business unit to indicate that the subscribed tax content
is used for the transactions created for the business unit.

For business units that maintain their own setup,
enter the default information, tax reporting codes, configuration
options, and service providers as required.

Third Parties

Set up third party tax profiles for parties with the
usage of customer, supplier, and their sites. Enter the default information,
tax registrations, party fiscal classifications, and reporting codes
required for your third parties or third party sites. You can set
up tax exemptions for your customers and customer sites.

Banks are also considered third parties. When a bank
is created, the tax registration number specified on the bank record
is added to the party tax profile record in Oracle Fusion Tax. You
can not modify the party tax profile for a bank as it is view only.
You can only modify the bank record itself.

Note

Setting up party tax profiles for third parties is
not required. Taxes are still calculated on transactions for third
parties that do not have tax profiles

Tax Authorities

Set up a tax authority party tax profile using the
Legal Authorities set up task. The tax authority party tax profile
identifies a tax authority party as a collecting authority or a reporting
authority or both. A collecting tax authority manages the administration
of tax remittances. A reporting tax authority receives and processes
all company transaction tax reports.

The collecting and reporting tax authorities appear
in the corresponding list of values on all applicable Oracle Fusion
Tax pages. All tax authorities are available in the list of values
as an issuing tax authority.

Specifying
Third Party Tax Profile Options: Points to Consider

Set up third party tax profiles for your customers
and customer sites and suppliers and supplier sites. How you set up
your third parties can impact the tax calculation on your transactions.

The third party tax profile consists of:

Defaults and controls

Tax registrations

Tax exemptions (for customers and
customer sites only)

Party fiscal classifications

Tax reporting codes

Banks are also considered third parties. When a bank
is created, the tax registration number specified on the bank record
is added to the party tax profile record in Oracle Fusion Tax. You
can not modify the party tax profile for a bank as it is view only.
You can only modify the bank record itself.

Defaults and Controls

The following table describes the defaults
and controls available at the third party tax profile level:

Option

Description

Allow tax applicability

Automatically calculate taxes for this party whenever
the party acts as a supplier. You can set this option, for example,
for customers that also act as suppliers on transactions.

Allow offset taxes

Calculate and record third party Payables tax liabilities
for reverse charges, self-assessments, and Consumer's Use tax (US).

You must also perform the related tasks for setting
up offset taxes for the taxes involved in transactions for this third
party or third party site. This includes enabling the Set as offset tax option at the tax level
and selecting the offset tax basis in the configuration owner tax
options.

Rounding Level

Perform rounding operations on the:

Header: Applies rounding to calculated tax amounts once for each tax rate
per invoice.

Line: Applies rounding to the calculated tax amount on each invoice line.

Rounding Rule

The rule that defines how the rounding should be performed
on a value involved in a taxable transaction. For example, up to the
next highest value, down to the next lowest value, or nearest.

Note

If you defined a rounding precedence hierarchy in
the configuration owner tax option settings for the combination of
configuration owner and event class, Oracle Fusion Tax considers the
rounding details in the applicable tax profile.

Set Invoice Values as Tax
Inclusive

This third party or third party site intends to send
or receive invoices with invoice line amount inclusive of the tax
amount.

Note

This option overrides the tax inclusive handling setting
at the tax level, but not at the tax rate level.

Country, Registration Number, and Tax Registration Type

Set defaults for all tax reporting for tax registrations
of this third party or third party site. You must complete the tax
registration setup.

Tax Registrations

Optionally, set up tax registrations for your
customers and suppliers, as necessary to support specific tax regulations
or reporting requirements. You must set up a separate tax registration
to represent each distinct registration requirement for a first party.
Oracle Fusion Tax uses tax registrations in tax determination and
tax reporting.

Tax Exemptions

Set up tax exemptions for your third party
customers and customer sites. To set up tax exemptions for a third
party, you must complete the appropriate tax exemption setup for the
tax regimes and taxes concerned. You can have more then one tax exemption
for the same customer and tax regime combination. You may need to
do this, for example, if one tax exemption applies to a specific tax,
while other tax exemptions apply to specific products for specific
tax rates and tax jurisdictions. At transaction time, Oracle Fusion
Tax applies the most specific tax exemption to the transaction.

Party Fiscal Classifications

If applicable, associate third party fiscal
classification codes with this party. The party fiscal classification
codes you enter become part of tax determination for invoices associated
with this party. Specify start and end dates to control when these
fiscal classifications are applicable for this party and transaction.

Tax Reporting Codes

Set up tax reporting types to capture additional
tax information on transactions for your tax reports for your third
parties. Depending on the tax reporting type code, you either enter
or select a tax reporting code for this party. Specify start and end
dates to control when these tax reporting codes are applicable.

Tax Exemptions: Explained

A tax exemption is a full or partial exclusion from taxes or
a surcharge, based on certain criteria given by the tax legislation.
Many countries allow tax exemptions when certain parties deal with
certain categories of goods and services. For example, most states
and localities imposing sales and use taxes in the United States provide
tax exemptions to resellers on goods held for sale and ultimately
sold. In addition, states and localities also provide tax exemptions
on goods used directly in the production of other goods, such as raw
materials.

Tax exemptions:

Reflect a specific tax rate levy.

Are taken as a percentage reduction
or an increase to the generally applied tax rate. Tax exemptions can
also be a specific tax rate in place of the generally applied tax
rate on a Receivables transaction.

Are registered against a customer
or customer site for a business relationship with a legal entity or
a business unit. Since tax exemptions are applicable to specific legal
entities or business units, you do not use the global configuration
owner option.

Are used for specific products or
available for all transactions for a legal entity or business unit.

In Oracle Fusion Tax, you define tax exemptions for
the combination of customer and customer site and items for a period
of time. Use rate modifiers, such as discount or surcharge percentage
or special rate percentage to map the preferential or special tax
rate applicability.

The tax exemption status influences the applicability
of the tax exemption on transactions. The possible values are: Primary, Manual, Rejected, Unapproved, and Discontinued. The tax exemptions with the status of Primary are applicable to all transactions. The tax determination process
considers Manual or Unapproved statuses only when the certificate
number and the exempt reason given on the transaction match with the
registered tax exemption values. The Discontinued or Rejected statuses are not
considered for tax exemption processing.

The tax handling option on a Receivable transaction
also influences the tax exemption processing. If you use the tax handling
option of Standard, the tax determination
process considers only tax exemptions with a status of Primary. If you use the tax handling option
of Exempt, the tax determination
process considers all Primary, Manual, and Unapproved tax exemptions with reference to the certificate number and exempt
reason given on the transaction. If you use the tax handling option
of Exempt, manual, the tax determination
process creates a new tax exemption along with the given certificate
number and exempt reason, with 100% discount and with a status of Unapproved if the matching condition does
not result in filtering any existing tax exemptions.

Tax Exemptions: Choices to Consider

A tax exemption applies to a specific customer
or to a combination of customer and specific product. For example,
in the United States the Federal Government acting as a customer is
exempt from tax on direct sales; and many states provide exemptions
on sales of necessities such as food and clothing.

To set up tax exemptions for a third party, you must
complete the appropriate tax exemption setup for the tax regimes and
taxes concerned. Create a separate record for each tax exemption that
applies to the third party customer or customer site. The tax determination
process applies the tax exemption to the transaction line based on
the tax exemption setup and tax handling specified on the transaction
line.

Tax Exemption Setup

Before you can create a tax exemption record,
you must enable the tax exemption options at the appropriate levels:

Set the Tax
Exemption Override Control profile option to control the
display of tax handling on the transaction line to apply and update
customer tax exemptions to transactions.

Set the Allow
tax exemptions option at the levels that correspond to
the tax exemption. For example, if the tax exemption refers to the
tax status of a particular tax, then you must set this option at the
tax regime, tax, and tax status levels.

Set the Allow
exemptions option in the configuration owner tax option
for each event class for which calculation based on tax exemption
is to be enabled. For the exemptions party basis select whether the
bill-to party tax exemption records are to be considered or the sold-to
party tax exemption records. In some cases the sold-to party could
be different from the bill to party.

Tax Exemption Record

A tax exemption record identifies the nature
of the tax exemption, the configuration owner, and tax regime, and,
where applicable, the related tax, tax status, tax rate, and tax jurisdictions
to which the tax exemption belongs.

During the life of a tax exemption, the tax exemption
status can often change. The possible statuses are: Primary, Manual, Unapproved, Discontinued, and Rejected. Because the status of the tax exemption affects
its applicability on the transaction line, you must update the tax
exemption record each time the status changes. These rules apply to
the status of the tax exemption:

Tax exemptions with a status of Primary apply to all transactions of the
customer or customer site.

Tax exemptions with a status of Manual or Unapproved apply to specific transactions of the customer or customer site.

Tax exemptions with a status of Discontinued or Rejected are not considered during tax calculation.

You also specify the method of calculating the tax
exemption percentage on the tax exemption record:

The Discount
or surcharge type decreases or increases the original
rate by the percentage you enter.

If the discount
is 15% off the standard rate and the standard rate is 10%, enter 85
as the tax exemption percentage. This defines a discount rate that
is 85% of the original 10%, or 8.5%.

If the surcharge is 10%, enter 110 as the tax exemption
percentage. This defines a surcharge rate that is 110% of the original
10%, or 11%.

The Special
rate type replaces the original rate with the percentage
you enter.

Enter the special rate percentage that
replaces the standard rate. If the original rate is 10%, and the special
rate is 5%, enter 5 as the tax exemption percentage.

Tax Exemption Applied to the Transaction Line

You use the Tax Handling field on the transaction line to select the applicable tax exemption
value. Tax exemptions are processed in different ways depending upon
the value you choose:

Require: The customer is required to pay the tax. Tax exemptions do not
apply to the transaction line, even if defined.

Exempt: Enter the tax exemption certificate number and the customer tax
exemption reason. Tax exemptions are processed in this way:

Consider tax exemptions with a status
of Primary, Manual, or Unapproved.

Verify that the transaction date is
within the tax exemption effective date range.

Verify that the transaction tax exemption
reason and tax exemption certificate number match the tax exemption
reason and certificate number. If you do not enter a certificate number,
the tax determination process still looks for a matching tax exemption.

If the tax determination process does
not find a tax exemption matching these conditions, it creates a tax
exemption with the status Unapproved and 100% discount.

Standard: This tax handling is for exemptions of the Primary status only.
You do not have to enter the tax exemption certificate number or customer
tax exemption reason.

The tax determination process
looks for a tax exemption with the Primary status and an effective
date range that includes the transaction date. If more than one tax
exemption applies, the most specific tax exemption is used, in this
order:

Exempt, manual: You manually enter a certificate number and exemption reason. The
application process creates a tax exemption with a status of Unapproved and a 100% discount is applied.

Note

The application first checks the customer site party
tax profile for the exemption records. If there is no exemption record
defined within the site, then it checks the customer party tax profile

After applying the tax exemption to the transaction
line, the tax determination process calculates the tax rate using
the tax exemption type defined in the tax exemption record. The sequence
of the tax rate value determination is:

Determine the basic tax rate through
the Determine Tax Rate rule type or by the default specified for the
tax.

Apply exception which is based on
the product.

Apply tax exemption which is based
on the party (customer) and its relationship with the transacting
organization (legal entity or business unit). Optionally, it can be
based on a specific product.

For example, the tax rate determined is 6%, the special
rate for a tax exception is 5%, and the tax exemption defined is a
2% discount. The tax exemption discount is applicable to the tax rate
after the tax exception, so the 5% tax rate is modified by a 2% discount
(5% * (100%-2%) = 4.9%). If the tax exemption defined is of the rate
type of Special rate then the
special rate is substituted and the applicable tax exception has no
impact.

For manual tax lines, no additional processing is
performed and tax exemptions are not considered. A manual tax lines
suggests that you have specific business requirements for a particular
transaction to apply a manual tax. No additional processing is performed
for manual tax lines to avoid any applying conflicting or inconsistent
values to the user-entered tax line. The tax calculation on a manual
tax line is the standard formula of tax amount is equal to the taxable
basis multiplied by the tax rate.

Exemption Types
and Percentages: Examples

The following scenarios illustrate how the
exemption rate type and exemption percentage apply to the tax rate.

Applying a Discount

Your company receives a discount of 20% because it
sells educational materials. You set the Exemption
Rate Type option as Discount or
surcharge and enter 20 in the Exemption Percentage field. As an example, the tax rate
for your transaction is 10%, but the application applies 8% due to
the 20% discount (10% - (10% * 20%)).

Applying a Surcharge

Your company is required to apply a surcharge to the
tax rate of 10% to a specific item it sells to a customer. For this
customer and item, you set the Exemption Rate
Type option as Discount or surcharge and enter 110 in the Exemption Percentage field. As an example,
the tax rate for your transaction is 10%, but the application applies
11% due to the 10% surcharge (10% + (10% * 10%)).

Applying a Special Rate

Your company is required to apply a special tax rate
of 5% for a specific customer. For this customer, you set the Exemption Rate Type option as Special rate and enter 5 in the Exemption
Percentage field. As an example, the tax rate for your transaction
is 10%, but the application applies 5% due to the 5% special rate
(it replaces the tax rate).

Manage Controls and Defaults

Inclusive Taxes: Explained

Calculating tax on a transaction as inclusive
of the line amount is generally a business decision. This decision
is based on the relationship between the transacting parties and the
items or taxes involved.

Taxes applicable on a transaction are made inclusive
of the item line amount either:

Manually

Automatically

Manual Approach

In the manual approach, you access the calculated
tax lines on a transaction and select the Inclusive option. This action includes the calculated
tax amount with the item value.

However, this option is controlled through two factors:

Privileges are assigned to the users
for accessing and editing the calculated tax lines.

Setup restrictions are applied to
edit the Inclusive option on the
calculated tax lines.

Automatic Approach

In the automatic approach, you can configure
the tax setup and calculate the tax on a transaction as inclusive
of the item line amount. Since this requirement is primarily driven
by the tax legislation and the business relationship between the transacting
parties, the option for configuring the inclusiveness is made available
on the tax and tax rate definition and the third party and legal reporting
unit tax profiles on the tax registration and general data tabs. The
tax determination process uses a hierarchy approach to evaluate the
defined setup and applies the inclusiveness option on the transaction.

In tax setup there are options to choose for applying
the inclusiveness on a transaction. They are:

Standard
noninclusive handling: This option calculates the taxes
as exclusive of the given transaction line amount.

Standard
inclusive handling: This option calculates the taxes as
inclusive of the given transaction line amount.

Special inclusive
handling: This option calculates the taxes as inclusive
of the given transaction line amount, but the calculation methodology
differs from the standard inclusive process.

The following table illustrates the calculation methodology
used with each of these options when a transaction line amount is
1000 USD and the applicable tax rate is 10% of the taxable basis amount,
for example, line amount:

Method

Calculation

Taxable Basis Amount

Tax Amount

Transaction Line Amount

Standard Noninclusive

1000 USD * 10/100

1000 USD

100 USD

1100 USD

Standard Inclusive

1000 USD * 10/110

909.09 USD

90.91 USD

1000 USD

Special Inclusive

1000 USD * 10/100

900 USD

100 USD

1000 USD

Configuring
Inclusive Taxes: Points to Consider

The requirement for calculating the taxes
as inclusive of the item line amount is primarily driven by the tax
legislation and the business relationship between the transacting
parties. Configure your tax setup accordingly to capture the inclusiveness
as per the taxes and the parties involved within a transaction.

The following table provides some of the key
inclusiveness requirements and the corresponding setup that can honor
them:

Tax Inclusiveness
Hierarchy: How It Is Determined

Configure your tax setup to include the calculated
tax amount with the item line amount. The option for configuring the
inclusiveness is available on the tax and tax rate definition and
the third party and legal reporting unit tax profiles on the tax registration
and general data tabs.

Settings That Affect Tax Inclusiveness

Set up the inclusive options in the following pages:

Create or Edit Tax page: Specify
the tax inclusion method on the Default and Controls tab. The handling
of this field is dependent on the value of the Allow override and entry of inclusive tax lines option
at the tax regime level. If the option is not selected at the tax
regime level, the Tax Inclusion Method field is display-only. The value displayed is set at the tax regime
level.

Create or Edit Tax Rate page: Specify
the tax inclusion method on the Main Details tab. The handling of
this field is dependent on the value of the Allow override and entry of inclusive tax lines option
at the tax level. If the option is not selected at the tax level,
the Tax Inclusion Method field
is display-only. The value displayed is set at the tax level.

Create or Edit Tax Registration page:
Select Set Invoice Values as Tax Inclusive option for the third party, third party site, and legal reporting
unit tax profiles.

Create or Edit Third Party Tax Profile
and Create or Edit Third Party Site Tax Profile pages: Select Set Invoice Values as Tax Inclusive option
on the General tab for the third party or third party site.

Create or Edit Legal Reporting Unit
page: Select Set Invoice Values as Tax Inclusive option on the General tab for the legal reporting unit.

How Tax Inclusiveness
Hierarchy Is Determined

The tax determination process uses a hierarchy approach
to evaluate the options selected in your tax configuration and applies
it on the taxes calculated on a transaction.

The hierarchy sequence for processing the inclusiveness
for a tax is:

If the transaction involved is a
Receivable transaction then check for the value in the Tax Amount Included field within the invoice
line details. The available values are:

No: All the taxes calculated on the invoice line are treated as exclusive
of the item line amount.

Yes: All the taxes calculated on the invoice line are treated as inclusive
of the item line amount.

Use tax rate
code: The tax setup defined is considered for analyzing
the inclusiveness.

If the transaction involved is not
a Receivable transaction or if the Receivable transaction uses the Use tax rate code option then check for the
value specified in the Tax Inclusion Method field for the processed tax rate code. The available values are:

Standard
noninclusive handling: The referred tax gets calculated
as exclusive of the transaction line amount.

Standard
inclusive handling: The referred tax gets calculated as
inclusive of the transaction line amount.

Special inclusive
handling: The referred tax gets calculated as inclusive
of the transaction line amount. However, the line amount is considered
the taxable basis rather than the adjusted line amount, which is considered
for the Standard inclusive handling value.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the tax registration record of the third party site tax profile
for the processed registration party. The available values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

If the processed registration party is the first party,
the registration record for the tax available within the legal reporting
unit tax profile is considered. If the value is set to blank then
step 7 is processed.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the tax registration record of the third party tax profile for
the processed registration party. The available values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the General tab of the third party site tax profile. The available
values are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check the value specified in the Set Invoice Values as Tax Inclusive field
on the General tab of the third party tax profile. The available values
are:

No: The referred tax gets calculated as exclusive of the transaction
line amount.

Yes: The referred tax gets calculated as inclusive of the transaction
line amount.

Blank: Process next step.

Check for the value specified in
the Tax Inclusion Method field
of the tax. The available values are:

Standard
noninclusive handling: The referred tax gets calculated
as exclusive of the transaction line amount.

Standard
inclusive handling: The referred tax gets calculated as
inclusive of the transaction line amount.

Special inclusive
handling: The referred tax gets calculated as inclusive
of the transaction line amount. However, the line amount is considered
the taxable basis rather than the adjusted line amount, which is considered
for the Standard inclusive handling value.

Tax Amount
Rounding: Explained

Taxes applicable on a transaction are generally
calculated as the taxable basis multiplied by the tax rate equals
the tax amount. This calculated amount can result in an odd value
or with a large number of decimal place. You can configure the tax
setup to adjust or round the tax calculation according to the specific
requirements of the transacting parties and tax authority or to the
accepted currency denominations.

Party tax profiles of the parties
or party sites as given in the rounding precedence of the configuration
owner tax options or in the derived registration party

Tax

Note

If you plan to use a third party service provider
then you must define tax rounding information that is at least as
detailed as the rounding information of the service provider.

Setting Up
Rounding Rules: Choices to Consider

Criteria for rounding the calculated tax amounts
comes from various parties involved in a transaction. For example,
for a purchase transaction, the rounding methodology is generally
specified by the supplier. Specify rounding details in your tax setup
to ensure that your entered invoice amount, including the calculated
tax, is the same as the actual invoice amount. For a Receivables invoice,
you can specify rounding details based on your organization's policy,
but for most countries the rounding criterion is directed by tax legislation.

Rounding requirements can originate from:

Third parties

First parties

Tax legislation

Rounding Requirements from Third Parties

If rounding is based on third party requirements,
particularly for purchase transactions, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the third party or third party. For purchase transactions it is
either the ship-from party or the bill-from party.

Define the party tax profile for
the third party and specify the rounding level and rounding rule on
the General tab as preferred by the third party.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the third
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party account site details
and party tax profile details for deriving the rounding rule.

Rounding Requirements from First Parties

If rounding is based on business unit or legal
entity requirements, particularly for sale transactions, and configuration
owner tax options are defined, you:

Define the configuration owner tax
options for the combination of business unit or legal entity for which
the transaction is registered and the event class. In the Rounding Precedence field enter the reference
of the first party. For sale transactions it is either the ship-from
party or the bill-from party.

Ensure that the party tax profile
details are available for the corresponding legal reporting unit.
Specify the rounding level and rounding rule on the General tab per
the first party requirement or your business policy.

If the rounding level is at the line
level in the party tax profile, create registration details for each
tax and specify the rounding rule. Also, define tax registration rules
for each tax so that the tax determination process uses the first
party registration.

If a registration record is not defined
for the tax registration party, select the Allow tax rounding override option on the Create or Edit
Tax page. The application then looks at the party tax profile details
for deriving the rounding rule.

The rounding criteria applied if configuration owner
tax options are not defined and the criteria in the predefined event
class options are considered include:

For a purchase transaction, the predefined
event class options use the ship-from party site and ship-from party
within the rounding precedence with the default rounding level as
the header level. The supplier's rounding preferences are considered
first on the transaction. If there are no specific supplier preferences,
for example, the party tax profile record does not exist, then the
default rounding level of Header is considered and the corresponding rounding rule from each tax
setup detail is used.

For a sale transaction, the predefined
event class options do not include any rounding precedence details.
However, the default rounding level is set to Line so the rounding level is always taken as Line and the corresponding registration record
for the tax registration party is considered for the rounding rule.
The tax registration party is identified through the Determine Tax
Registration tax rule or tax rule defaults. If a registration record
does not exist for the tax registration party, the rounding rule defined
within each tax is considered.

Rounding Requirements from Tax Legislation

If rounding is based on tax legislation, the
following occurs:

If the configuration owner tax options
are defined for the combination of business unit and legal entity
for which the transaction is registered and for the event class, the
default rounding level is used from the configuration owner tax options.
Select Blank as the rounding precedence
for the event class.

If the rounding level is at the line
level for the configuration tax options, ensure that the registration
record defined for the tax registration party has the rounding rule
based on the tax requirements. The tax registration party is identified
through the Determine Tax Registration tax rule or tax rule defaults.

Rounding Precedence
Hierarchy: How It Is Determined

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving:

Settings That Affect Tax Rounding

Tax precision: The number of decimal
places to which to calculate the tax amount.

Minimum accountable unit: The smallest
currency unit that a tax amount can have.

Rounding level: The transaction level
at which the rounding is to be performed.

Rounding rule: The method that is
used to round off the calculated taxes to the minimum accountable
unit.

Options available for the rounding level are:

Header: Applies rounding to calculated tax amounts once for each tax rate
per invoice.

Line: Applies rounding to the calculated tax amount on each invoice line.

Options available for the rounding rule are:

Up: the amount is rounded to the next highest minimum accountable unit.

Down: The amount is rounded to the next lowest minimum accountable unit.

Nearest: The amount is rounded to the nearest minimum accountable unit.

How Tax Rounding Is Determined

If you did not define configuration owner tax option
settings for the combination of configuration owner and event class,
the rounding process uses the default rounding level of the event
class and the default rounding rule of the tax.

If you defined a rounding precedence hierarchy in
the configuration owner tax option settings for the combination of
configuration owner and event class, the rounding process looks for
a rounding level and rounding rule in this way:

Looks for rounding details in the
party tax profiles of the parties and party sites involved in the
transaction, according to the rounding precedence hierarchy.

If an applicable tax profile is found
then uses the rounding level and rounding rule of the tax profile.

If the rounding level is at the header
level then uses these values to perform the rounding. The process
ends.

If the rounding level is at the line level
then goes to step 6.

If an applicable tax profile is not
found then uses the rounding level setting of the configuration owner
tax option.

If the configuration owner tax option
rounding level is at the header level then uses the rounding rule
that is set at the tax level for each tax of the transaction to perform
the rounding. The process ends.

If the rounding
level is at the line level then goes to step 6.

If the rounding level is at the line
level then:

For each tax line, uses the rounding
rule belonging to the tax registration of the party type derived from
the Determine Tax Registration rule.

If a registration record does not
exist for the registration party type and if you did not define configuration
owner tax option settings for the combination of configuration owner
and event class, then the rounding process uses the rounding rule
that is set at the tax level to perform the rounding. The process
ends.

If a registration record does not
exist for the registration party type and if you defined a rounding
precedence hierarchy in the configuration owner tax option settings
for the combination of configuration owner and event class, then the
rounding process looks for a rounding rule in this way:

Refers to the party or party site
of the first party type defined in the rounding precedence hierarchy.

Uses the rounding rule of the party
or party site tax registration, if defined.

If a tax registration is not defined,
uses the rounding rule of the party or party site account site details,
if defined.

If a rounding rule is not defined,
uses the rounding rule of the party or party site tax profile, if
defined.

If a tax profile is not defined,
repeats the previous substeps for each rounding party in the rounding
precedence hierarchy.

If a rounding rule is found, uses
this rounding rule to perform the rounding. The process ends.

If a rounding rule is not found,
then uses the rounding rule that is set at the tax level to perform
the rounding. The process ends.

Tax Rounding: Examples

During the rounding process, the tax precision
and minimum accountable unit details are derived from the tax setup.
The rounding process derives the rounding rule and rounding level
details through the predefined processing hierarchy involving configuration
owner tax options, event classes, party tax profiles, and taxes. These
examples illustrate how the rounding process works.

Scenario

The following examples represent how the rounding
process determines the tax rounded amount based on transaction, tax
setup, and rounding details.

The transaction and tax setup details for the two
examples are:

Invoice header amount: 5579 USD

Invoice line 1 amount: 1333 USD

Invoice line 2 amount: 1679 USD

Invoice line 3 amount: 2567 USD

Applicable taxes:

State tax, rate percentages of 12.5%,
6.75%, and 3.33%

City tax, rate percentages of 7.5%

The rounding details for the two examples are:

Rounding level: Header

Rounding Rule:

State tax: Up

City tax: Nearest

Tax precision: 2

Minimum accountable unit: 0.01

Example 1 represents the rounding details applied
at the header level. Applying these factors, the rounding process
calculates the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Line amounts truncated per tax precision and
rounding criteria applied at the header level

Step 2: Difference between the header amount and the
sum of the line amounts

Step 3: Apply the difference amount to the maximum
tax line amount

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.81

418.43

0.01

0.02

395.81

418.43

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.62

99.97

166.62

99.97

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.91

125.92

55.91

125.92

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.52

0.01

0.02

173.28

192.54

Example 2 represents the rounding details applied
at the line level. Applying these factors, the rounding process calculates
the invoice amounts, all in USD currency, as follows:

Document Level

Amount

Tax and Tax Rate

Tax Amount Not Rounded

Step 1: Rounding criteria is applied at the line level

Step 2: Line amounts are added to obtain revised header
amounts

Tax Amount Rounded

Header

5579

State tax

City tax

395.8082

418.425

395.82

418.44

395.82

418.44

Line 1

1333

State tax: 12.5%

City tax: 7.5%

166.625

99.975

166.63

99.98

166.63

99.98

Line 2

1679

State tax

City tax: 7.5%

55.9107

125.925

55.92

125.93

55.92

125.93

Line 3

2567

State tax

City tax: 7.5%

173.2725

192.525

173.27

192.53

173.27

192.53

Self-Assessment
of Taxes: Explained

Taxes for purchase transactions are usually
calculated by the supplier and included in the invoice. The responsibility
of collecting and remitting these taxes to the authority lies with
the supplier. However, in certain cases the supplier does not have
presence (nexus) or is not registered in the customer location. Taxes
applicable in such cases, in the customer location, are self assessed
by the purchasing organization. Unlike supplier assessed taxes that
are paid to the supplier, self-assessed taxes are remitted by the
purchasing organization directly to the tax authority.

The key here is that these taxes are to be calculated
on the same invoice, but these should not impact the amount payable
to the supplier, instead it should be accounted for as a tax liability.

The core requirements remain the same, however, the
terminology used for self-assessed taxes vary by tax regime, such
as reverse charges, use taxes, and offset taxes. Reverse charge is
the terminology primarily used in the European Union, use taxes is
the terminology used in the United States, and offset taxes is a alternate
solution to handle self-assessment of taxes and is not used by any
regime.

Oracle Fusion Tax provides the following options to
configure and automate calculation of self-assessed taxes:

Self-assessment

Offset taxes

Reporting-only taxes

Use taxes

Self-Assessment

Taxes need to be self-assessed by the purchasing organization
when the supplier is not registered in the ship-to or bill-to location
of the transaction. This is the recommended approach for defining
and calculating self-assessed taxes. This is driven based on the registration
party used for the transaction.

Registration Party

In the context of a tax applicable to the transaction
it is the party whose registration needs to be considered. The tax
registration party type default is specified for the tax. As most
of the taxes are assessed by the supplier, the default is set to the
ship-from or the bill-from location.

Supplier Tax Registration

You can define tax registration for the supplier,
the supplier site, and for a particular tax regime. If the tax registration
varies by tax or tax jurisdiction, define the registration at a granular
level. If the supplier does not have presence in a specific jurisdiction,
there are two options for configuration. The first is to create a
tax registration record with the registration status as not registered.
The second option is not to define a registration record. If you follow
the second option, when you define the condition set, set the operator
for the Registration determining factor class to Is blank.

Registration Party of the First Party

Similar to the supplier registration, you can define
the tax registration records for a legal reporting unit tax profile.
For the tax registration of the first party select the Set as self-assessment (reverse charge) option.
This option triggers self-assessment of taxes when the registration
party selected for the tax line is that of the first party. Self-assessment
is only applicable for Payables transactions. The option on the first
party registration does not impact Receivables transactions. Create
a tax registration rule to conditionally use the first party registration
when the supplier is not registered. The condition to use for this
tax rule is as follows:

Tax Determining Factor Class

Class Qualifier

Tax Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Equal to

Not Registered

If the registration records are not created for the
suppliers without registration, create the condition set as follows:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Is blank

Offset Taxes

Offset taxes is a backward compatible approach that
is configured to self-assess taxes. Configure offset taxes in addition
to your regular taxes. Offset taxes carry a negative rate and are
calculated in the context of the regular tax. Where offset taxes are
applicable, the application creates two tax lines with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Reporting-Only Taxes

You can identify taxes for reporting purposes only.
When these taxes are applicable to the transactions, records are created
in the tax repository entities. However, invoice distributions are
not created for these taxes. Therefore, there is no impact to the
payable amount, payment amount, and invoice accounting.

Use Taxes

Assigning use taxes to invoices, you create a record
of the taxes you owe to tax authorities. Oracle Fusion Payables does
not create invoice distributions for these taxes. Therefore, there
is not any accounting impact due to these taxes. Payables provides
a Use Tax Liability Report to review and report use taxes.

Use the Use Tax Liability Report to review, report,
and remit use taxes. The report determines the use tax liability by
each use tax code by taking the tax rate you defined for each tax
code and applying it to the sum of each invoice line to which the
tax applies. The report lists in summary or detail the total amount
of tax you owe for each tax code on invoices you enter between two
dates you specify when you submit the report. Oracle Fusion Payables
displays the amount of use tax you owe in the currency in which you
entered an invoice.

Note

Use taxes are defined with the tax type of Use tax. The rest of the configuration is
the same as the other taxes. This feature is only supported for migrated
taxes. You cannot define a new tax with this tax type.

Self-Assessment
of Taxes: How It Is Processed

You can let a first party self-assess the
taxes calculated on the Payables invoices it receives. A self-assessed
tax is a tax calculated and remitted for a transaction, where tax
was not levied by the supplier but is deemed as due (and therefore
needs to be paid by the purchaser). Taxes need to be self-assessed
by the purchasing organization when the supplier is not registered
in the ship-to or bill-to location of the transaction.

Settings That Affect Self-Assessment of Taxes

Configure your tax setup to automate self-assessment
of regular taxes. The following is an overview of the configuration:

Default registration party: Set the
default values for the direct rule type of Tax Registration. For self-assessed taxes set the value
to Ship from or Bill from.

Supplier registration: The supplier
can be registered or not registered. Configure your set up as follows:

If the supplier is registered the
application creates a record with the registration status of registered.
The registration of the supplier is considered and the taxes are assessed
by supplier and included as a part of the invoice total.

If the supplier is not registered
then either you can create a registration record for the tax regime,
tax, or tax jurisdiction, with the registration status of not registered.
Or skip the step of defining tax registration and define the tax condition
set with the operator of Is blank.

Selecting first party registration
conditionally: Create a registration record for the first party legal
reporting unit. For this registration record select the Set as self-assessment (reverse charge) option.

If the supplier is not registered then the registration
of the first party legal reporting unit needs to be considered. To
trigger this, you need to define a tax registration rule with the
following conditions:

If the ship-from or bill-from party
registration status is not registered or is blank then the registration
party is either the ship-to party or bill-to party. The following
is the condition set for the Determine Tax Registration rule:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Equal to

Not Registered

Transaction Input Factor

Line Class

Equal to

Standard Invoice

If you choose the option of not defining
a supplier registration then the condition set is as follows:

Determining Factor Type

Class Qualifier

Determining Factor Name

Operator

Condition Value

Registration

Bill-from party

Registration Status

Is blank

Transaction Input Factor

Line Class

Equal to

Standard Invoice

Set the rule result to bill-to party so that the registration
of the legal reporting unit is considered.

Tip

Instead of including the condition for the transaction
input factor, you can specify the event class constraint at the tax
rule header.

Self-assessing tax: For the first
party registration record you create for the tax regime, tax, and
tax jurisdiction, check the Set as self-assessment
(reverse charge) option. Once the application selects
this registration record for the tax, the tax line is stamped as self-assessed.

How Self-Assessed
Taxes Are Processed

Taxes created by the first party organization need
to be calculated in the context of the transaction. The application
creates both summary and detail tax lines for these taxes and the
self-assessed option is enabled for these lines. Invoice lines are
not created for taxes, therefore the payable to the supplier does
not include these taxes. Invoice distributions are created to account
for the tax expense or recovery and liability.

Self-assessed taxes are not included in the invoice
totals. Instead, the total of self-assessed taxes for the invoice
is displayed as a separate line in the tax charges region of the invoice.

Self-assessed taxes are created for imported payables
invoices. This happens when imported transactions have tax lines along
with transaction lines and if you enable the Perform additional applicability for imported documents option for the event class. For these transactions, additional taxes
that are found applicable are treated as self-assessed taxes.

These taxes are accounted along with the rest of the
invoice. The accounting treatment for expense and recovery remain
the same as any supplier-assessed taxes. The only variation is be
the liability account. The tax amount is credited to the tax liability
account instead of the payables account.

Self-assessed taxes are a part of the standard tax
reports. Apart from this, Oracle Fusion Subledger Accounting provides
reports for accounting activity that can be used to track self-assessed
tax liability. Use the Account Analysis Report and the Open Account
Balance Listing report to track this liability.

Tax Line Override

You can override the self-assessed flag for the tax
line. This impacts the invoice lines and distributions. If you update
the summary tax line, all corresponding detail tax lines are updated
to reflect this change. If the self-assessed option on some of the
detail tax lines is updated then a new summary tax line is created
to group the detail tax lines that are being self-assessed.

Offset Taxes: How They Are Processed

Offset taxes are a backward compatible approach
that you can configure to self-assess taxes. Configure offset taxes
in addition to the regular taxes. Offset taxes carry a negative rate
and are calculated in the context of the regular tax. Where offset
taxes are applicable, two tax lines are created with one positive
and one negative amount. An offset tax record is a matching, duplicate
record with negative amounts that reduces or completely offsets the
tax liability recorded in the tax transaction. Use offset taxes when
the tax requirement includes creating an offset general ledger posting.

Settings That Affect Offset Taxes

For the offset tax calculation to take effect, do
the following:

Set up offset taxes

Enable offset tax calculation

You must perform these tasks for setting up offset
taxes:

Set up the offset tax, tax status,
and tax rate. Define at least one recovery type lookup to use with
offset taxes.

Create the offset tax and perform
the following:

Use the tax currency of the original
tax.

Select the Set as offset tax option.

Enter a primary recovery type that
you defined for offset taxes.

Set up the tax status for the offset
tax. Do not select the Allow tax rate override option.

Set up a 100% tax recovery rate for
the offset tax using the recovery type that is defined for the offset
tax.

You cannot update the recovery rate on an
offset tax line. The recovery rate is always 100% in order to create
credit entries that match the original tax amounts. When you create
an offset tax, you enter a primary recovery type with a recoverable
rate of 100% and a 100% recovery rate.

Set up the offset tax rate and perform
the following:

Enter a negative rate amount.

Assign the tax recovery rate that
is defined for offset tax.

Do not select the Allow ad hoc tax rate option.

Set up the original tax with the
required configuration to enable the tax. For the tax rate of the
original tax (nonoffset tax), assign the offset tax rate code in the Offset Rate Code field.

Complete the following configuration steps to enable
calculation of offset taxes for a transaction:

Select the Allow offset taxes option on the party tax profile if
offset taxes are to be calculated for the transactions created for
the party. Select this option for the party type chosen in the Offset Tax Basis field for the configuration
owner tax options.

How Offset
Taxes Are Processed

Offset taxes applicable to an invoice are created
with two tax lines entries, one for the tax and one for the offset
tax. The line for the offset tax has the offset option enabled. This
line carries the reference to the original tax line. Two Invoice lines
are created for these taxes, one for each tax.

The amount for the regular tax line is always debited
to the tax expense or recovery account or both, depending on the recoverability
of the tax. The credit is posted to a payables account which is offset
by the negative amount credited to the payables account due to the
offset tax line. The debit of the offset tax line is posted to the
tax liability account and this indicates the liability that the first
party organization has towards the tax authority for the self-assessed
tax.

Tax Line Override

You cannot override offset tax lines. However, you
can update the tax line calculated for the original tax. When you
update the tax rate percentage or amount or when you cancel the tax
line, the corresponding tax line for the offset taxes is updated.

Reporting-Only
Taxes: How They Are Processed

You can identify taxes for reporting purposes
only. When these taxes are applicable to the transactions, records
are created in the tax repository entities. However, invoice distributions
are not created for these taxes. Therefore, this does not impact the
payable amount, payment amount, and invoice accounting.

Settings That Affect Reporting-Only Taxes

You set up reporting-only taxes by selecting the Set tax for reporting purposes only option
for the tax.

How Reporting-Only
Taxes Are Processed

Tax lines for reporting-only taxes have the Reporting Only option enabled. Tax distributions
are not created for these tax lines.

For Oracle Fusion Payables invoices, these lines are
not displayed on the invoice lines. The total of the reporting-only
taxes are displayed in the tax totals region of the invoice.

For Oracle Fusion Receivables transactions, reporting-only
taxes are handled as any other tax. These taxes are considered as
a part of the invoice and are accounted for accordingly.

Tax Line Override

You cannot update the Reporting
Only option on the detail tax lines.

FAQs for Define Third Party Tax Profiles

When does a party
tax profile get created for a third party?

The third party tax profile is automatically
created when a third party (customer or supplier) with tax configuration
is created. Edit the tax profile that was automatically generated
with the relevant tax information, but it is not required for tax
calculation. Otherwise, create a party tax profile using the Create
Third Party Tax Profile or Create Third Party Site Tax Profile pages.

What's the difference between using tax exemptions or tax rules to modify the taxable
nature of a transaction?

You can modify the taxable nature of a transaction
using tax exemptions, but you can also accomplish this through the
use of tax rules. Use tax rules, such as the Determine Tax Applicability
rule, to exclude certain categories of transactions from
taxation. If you choose to implement tax rules to achieve your tax
exemption requirements, the impacted transactions do not appear on
many tax reports as they do not have any tax lines.

If you must report on a transaction then the
set up a tax exemption on the customer's party tax profile which results
in a tax line being created with the modified tax rate. Use tax exemptions
where certificates of exemption are issued for specific customers,
which is typical in tax regimes for US Sales and Use Tax.

You can create an exempt tax rate with a zero percentage
rate as a method of applying exemptions. This achieves many of the
intended reporting objectives as the application generates a tax line.
Reports that specifically refer to an item as exempt may exclude items
with a zero percentage rate from that portion of the report because
the exempt indicator is blank.

If you define an exempt tax with a zero tax rate,
the transaction shows as fully taxable on all reports. If you want
reports to show the full line amount as taxable you cannot add any
exemption details, such as exempt reason codes, as this results in
an exemption being created on the customer record and a zero taxable
amount on the reports.

Define the validation for the tax
reporting type for tax reporting codes to be added in terms of data
type and a minimum and maximum length. Data types include Date, Numeric value, Text, and Yes or no indicator.

Use tax reporting codes you create
under one tax reporting type across various entities, such as tax,
tax status, tax rate, party tax profiles, and fiscal classifications.
To use a tax reporting type for a particular entity, associate that
entity to the tax reporting type in the Reporting Type Uses region
on the Create Tax Reporting Type page.

There is no impact of the tax reporting type on tax
calculation. The tax reporting codes are used in the tax reports.

Tax configuration facilitates the association between
various entities and tax reporting codes. The entity details are stored
as part of the tax repository. During tax report generation necessary
tax reporting codes are derived based on the entities associated with
the tax line. The functionality to include the reporting type code
is handled by the Tax Reporting Ledger.

Tax Reporting Type Uses

Some reporting type uses have a one to one relationship
of tax reporting type use to an entity, such as tax, tax jurisdiction,
tax rate, and tax status. For example, the tax reporting type use
of Tax defines tax reporting type codes for association to taxes you
define and the Tax Jurisdiction tax reporting type use defines tax
reporting type codes for association to the tax jurisdictions you
define.

The Fiscal Classification tax reporting type use defines
tax reporting type codes for association to the following classifications:

User-defined fiscal classifications

Product category fiscal classifications

Document fiscal classifications

Transaction fiscal classifications

The Party Tax Profile tax reporting type use defines
reporting type codes for association to the following party tax profiles:

Legal entity tax profiles

Legal reporting unit tax profiles

Business unit party tax profiles

Third party tax profiles

Third party site tax profiles

The Process Result tax reporting type use defines
reporting type codes for association to the following rule types:

Direct tax rate determination rules

Place of supply rules

Tax applicability rules

Tax registration rules

Tax status rules

Tax rate rules

Taxable basis rules

Tax calculation rules

Tax Reporting Types and Codes and Their Use in
Tax Reporting

The following table describes key predefined tax reporting
types and codes and their association and use in tax reporting:

Country

Reporting Type and Code

Associated to

Use

Italy and Spain

REPORTING_STATUS_TRACKING

Y

Tax

Used to track tax lines that are not yet finally reported

Italy and Spain

EMEA_VAT_REPORTING_TYPE

VAT

Tax

Used in the EMEA VAT selection
process

Italy

EMEA_VAT_REPORTING_TYPE

Custom bill

Tax rate code

Used in the Italian Purchase VAT Register definition program
to recognize customs invoices

Italy

EMEA_VAT_REPORTING_TYPE

Self invoice

Tax rate code

Used in the Italian Purchase VAT Register definition
program to recognize self invoices

Italy

EMEA_VAT_REPORTING_TYPE

Nontaxable

Tax rate code

Used in the Italian Purchase VAT Register definition
program to recognize nontaxable invoices

Italy

EMEA_VAT_REPORTING_TYPE

Exempt

Tax rate code

Used to identify invoice lines with exemption limit
groups

Spain

EMEA_VAT_REPORTING_TYPE

Services

Tax rate code

Used for VAT reporting

Legal Justification
Tax Reporting Types: Explained

Legal justification tax reporting types are
introduced as a feature to support European Union (EU) value-added
tax (VAT) changes for the year 2010. The changes are introduced to modernize
and simplify rules relating to cross-border supply of services and
recovery of input tax. These are the most far-reaching changes to
VAT law since the introduction of the Single European Market in 1993.
This impacts all businesses, which supply and purchase services across
EU countries. Companies must rethink their service flow, as well as,
their compliance and reporting obligations.

The new rule for place of supply of services, for
tax determination in a business-to-business transaction, is where
the customer is established and not where the supplier is established, as
is the case before January 1, 2010. Therefore, if services are supplied
in another EU member state, they are taxable in the recipient's country.
For business-to-customer supply of services, the general rule for
place of supply continues to be the place where the supplier is established.
There are exceptions to the new rule for certain types of services.
Examples include: services provided for immovable property, passenger
transport services, cultural, and educational events. It also includes
ancillary services, short term hiring of means of transport, and restaurant
and catering services carried out on board a ship, aircraft, or train
within the EU.

Legal Messages

A legal message specifying that the customer of such
services must self-assess the relevant tax, should be printed on Receivables
(intra-EU services) invoices. Create a Bill Presentment Architecture
template to print the legal justification message on the Receivables
invoice. The exact text of the message is defined by the country-specific
legislation. The reporting code is also a selection parameter to display
the intra-EU services invoice lines on the European Union Sales Listing
report.

Configure these messages using the Create Tax Reporting
Types page. Associate these messages to invoices through the association
to a tax rate definition and a tax rule result. When defining these
tax reporting codes the tax reporting purpose is the Legal justification message type and the
applicable reporting type uses are Process
Result and Tax Rate. Enter the legal justification text which should be as defined by
legislation.

Define Tax Override Controls

Profile Options
Controls and Defaults: Points to Consider

Set values for Oracle Fusion Tax profile options
to control the availability of certain tax options.

Defining Controls and Defaults

The following table describes the defaults
and controls available at the tax profile options level.

Field

Description

Default Derived from

Default Appears on

Controls

Transaction Tax Line Override

Controls whether you can update automatically calculated
tax lines at transaction time

None

None

Use this option in conjunction with the ALLOW_TAX_OVERRIDE_FLAG
for the tax to allow you to override tax lines at transaction time.
This excludes you from updating the Inclusive option and tax rate on the tax line.

Use this option in conjunction with the Allow override and entry of inclusive tax lines option on the tax record to allow you to override the Inclusive option on the tax line.

Tax Classification Code Override

Controls whether you can override the tax classification
on the tax line at transaction time

None

None

If this option is selected you can override the tax
classification code at transaction time

Tax Exemption Override Control

Controls whether you can override tax exemptions at
transaction time

None

None

If this option is selected you can override tax exemptions
at transaction time where tax exemptions are allowed

Verify Tax Configuration

Tax Simulator: Explained

The Tax Simulator is a tool for simulating
the tax determination process in your tax setup. The Tax Simulator
lets you preview the workings of your tax configuration before you
perform tax calculations on live transactions in a subledger application.
The Tax Simulator also allows you to test new tax configuration in
conjunction with existing tax configuration to preview the resulting
tax calculation. The Tax Simulator is a useful tool to identify the
root cause when tax calculation is not what is expected on live data.

Run taxes from all applicable tax regimes against a
sample transaction to verify that your tax configuration and tax rules
were created and applied according to your requirements. You can either
create a sample transaction within Tax Simulator or copy an existing
transaction. The simulated tax calculations do not affect live data.

Principle aspects of the Tax Simulator include:

Functions and verifications

Analysis tools

Restrictions

Tax Simulator Functions and Verifications

The Tax Simulator lets you simulate the tax determination
process on transactions without creating live data.

The Tax Simulator enables you to complete these functions:

Enter transactions to simulate tax
calculation based on various scenarios.

Simulate the characteristics of the
Payables, Purchasing, and Receivables transactions and create the
tax line for each type of operation.

View the detail tax lines generated
for each transaction line.

View the tax rules that were applied
to a tax calculation and the processed result for each rule type.

The Tax Simulator provides these verifications:

How the tax rules that you have defined
for one or more taxes work in conjunction with the defaults that you
have set for them.

Whether a tax rule that you expected
to have a successful evaluation for a given set of transaction conditions
achieved the desired result.

How the options that you have set at
various levels are reflected in the results of tax determination processing.
If a certain transaction does not process taxes as you predicted,
then you can use the simulated result to troubleshoot the cause. For
example:

You thought that there were product
tax exceptions, but they were not used on a transaction as expected.
You then discover that the Allow tax exceptions option was not enabled on the applicable tax rate record.

Your supplier record has the option
enabled to use offset taxes, but the offset taxes do not appear. You
then discover that the tax rate record does not have an offset tax
rate associated with it.

Tax Simulator Analysis Tools

The Tax Simulator provides these pages to analyze the
tax calculations on simulated transactions:

Simulator Transaction page: View the
details of the simulated transaction.

Tax Line Details page: View the calculated
tax lines for the simulated transaction. The page displays, for each
transaction line, the applicable tax and tax configuration details,
as well as if the result was determined by a tax rule or the default
value. If a tax rule was applied, the page also displays the associated
tax condition set.

Rule Type page: View details of all
enabled rules for a rule type. The page displays the processed result
for each rule. The page also displays the associated tax condition
sets and their processing details and results.

Tax Simulator Restrictions

The following restrictions apply when using the Tax
Simulator:

Payables tax recovery processing cannot
be simulated.

Application-specific actions on transactions
or transaction lines, such as canceling, deleting, and reversing,
are not tested.

User control settings are not tested
or verified.

Simulating Subledger
Transactions: What Is Copied

Copy transactions from Oracle Fusion Payables,
Oracle Fusion Purchasing, and Oracle Fusion Receivables and use them
to test the entire tax and related configuration. Once the Tax Simulator
copies data into the simulated transaction, you can update and delete
lines as needed.

Settings That Affect Subledger Transactions

Oracle Fusion Tax uses your search criteria defined
for the application, legal entity, and business unit to provide a
listing of subledger transactions. The Tax Simulator copies the attributes
of the selected transaction and populates them on the Create Simulator
Transaction page.

What Subledger
Data Is Copied

The Tax Simulator copies the following data from the
subledger transaction:

Calculated tax amount if you use an
external service provider for tax calculation

Line-level tax attributes

Discounts and exceptions for Receivables
transactions

Ship-to information for Receivables
transactions

The system does not copy:

Any referencing, applied, or adjusted
documents

Tax-only lines

Canceled lines

Changing Transaction Attributes

Update and delete lines and attributes as needed. The
only fields that you cannot update are the document event class and
source document number.

Simulating
Tax on Transaction Data: Explained

The Tax Simulator allows you to validate new
and existing tax setup for procure-to-pay and order-to-cash transactions.
The format of the Tax Simulator interface is a lightweight version
of the procure-to-pay and order-to-cash respective work areas allowing
ease of data entry and flow of item lines to tax calculation and tax
lines. In addition to the required transaction attributes the additional
tax attributes that drive tax calculation are highly visible and available
for your entry and update. Simulated transactions do not impact live
data and you can purge them from the application using a process request.

Use the Tax Simulator to create, duplicate, and simulate
transactions. The interface also supports associating adjusting, referencing,
and applied documents on applicable event classes. In addition to
simulating tax output for live transactions you can test the tax calculation
of taxes that are not yet active and see the standalone tax calculation
or the impact of this tax with taxes that are active. The Tax Simulator
provides comprehensive information and a view into the tax processing
logic to help you implement and troubleshoot tax setup. One of the
critical uses of the Tax Simulator is for you to be able to safely
trigger transactions without having a detailed knowledge of the core
transaction systems or having to create transactions in these applications
that impact the core applications.

Using the Tax Simulator

The Tax Simulator allows ease of data entry. The flow
of transaction entry is similar to the respective work area so you
are familiar with the flow. There is partial page rendering for procure-to-pay
and order-to-cash event classes to expose the appropriate attributes.
For example, when you enter a purchase order you are prompted for
a supplier. When you populate the supplier information, the Tax Simulator
populates the default ship to and bill to information. When you enter
a Receivables sales invoice event class you are able to enter customer
bill to and customer ship to details in a format similar to the Receivables
Invoice work area. Other attributes include warehouse, discounts,
and exemptions for Receivables event classes and line classes for
Payables event classes.

The data you enter in the Tax Simulator is not live
data, it is not accounted, reported, or visible from other product
interfaces. In addition to manual entry of transaction data, you can
copy live data to view or modify in the Tax Simulator. The Manage
Tax Simulator Transactions page allows you to choose a source of Payables,
Purchasing, Receivables, or Tax Simulator. Search on the source of
Tax Simulator for transactions entered or copied into the Tax Simulator.
The other product sources allow you to query and copy transactions
from the respective subledgers.

For example, you have a Payables invoice where the
tax calculation is not what you expect. Use the Tax Simulator to:

Search in the Manage Simulator Transactions
page for a source of Payables, an event class of Purchase invoice,
and respective business unit, document number, and date information.

View the applicable transaction in
the Search Results table. If needed there is Query by Example available in the table for you to further
identify the desired transaction.

Select the Purchase invoice and click Simulate Transaction to copy this transaction
into the Tax Simulator.

Review the information on the Create
Simulator Transaction page. The application populates the transaction
details.

Populate the document number with
the new number. The source document number is populated with the original
document number. You can update all attributes except the document
event class and source document number.

Save the document and click View Tax Lines to view the tax output.

If you want to test multiple variations of the same
transaction you can query the transaction with a source of Tax Simulator
in the Manage Tax Simulator Transactions page. Select the transaction
in the search results and click the Duplicate action to duplicate the transaction details into a new document
leaving the previous transaction details intact.

Using Additional Tax Attributes

In addition to the required fields for transaction
entry and tax calculation, such as Document
Event Class, Document Date, Legal Entity, Business Unit, Currency, Supplier, Customer, and Line Amount, the Tax Simulator gives you visibility into additional tax attributes
that are commonly used to drive tax calculation based on tax rules.
The Tax Simulator removes many of the attributes that do not impact
tax calculation to simplify the page and let you focus on the needed
elements.

At the header level the Taxation
Country is visible for entry and update. At the line level
you can enter and update attributes such as Line Class, Line Type, Item, and Product Type. Additional tax attributes, such as Tax Inclusive, Transaction
Business Category, Assessable
Value, Tax Classification, Product Category, Intended Use, Product
Fiscal Classification, User-Defined
Fiscal Classification, and Account, are organized in a tabbed region. All of these attributes can drive
tax determination or tax calculation directly based on tax rules and
tax formulas. Almost every additional tax attribute on the Tax Simulator
interface directly impacts tax determination and tax calculation in
a format that resembles the work areas so it is easy for you to understand
and navigate.

Using Reference, Adjusted, and Applied Documents

Reference, adjusted, and applied documents can have
tax calculation impacted by the documents they are associated with.
The Tax Simulator presents information on some of the impacts. Others,
such as variances in distributions, are not presented since accounting
is not part of the Tax Simulator functionality. Also, when a document
is simulated or copied in the Tax Simulator, the application does
not copy referencing, adjusted, and applied documents. You must copy
each document separately and associate them in the Tax Simulator.

The following is a list of the available event classes
and associations that can be made in the Tax Simulator:

Application

Header Level Document Event Class

Item Line Attribute Line Class

Reference, Adjusted, and Applied Tab: Document Event
Class

Reference, Adjusted, and Applied Tab: Document Number

Reference, Adjusted, and Applied Tab: Document Date

Reference, Adjusted, and Applied Tab: Document Line
Number

Payables

Standard Invoice

Invoice

Purchase Order (not required)

Select the purchase order document number.

Populated when the document number is selected and
it is read-only.

When you enter the document number of the purchase
order this list is available with the respective invoice lines.

Payables

Standard Invoice

Prepayment

Prepayment Invoice

Select the prepayment invoice number.

Populated when the document number is selected and
it is read-only.

When you enter the document number of the prepayment
invoice this list is available with the respective prepay invoice
lines.

Payables

Standard Invoice

Credit Memo

Standard Invoice

Select the credit memo document number.

Populated when the document number is selected and
it is read-only.

When you enter the document number of the invoice
this list is available with the respective invoice lines.

Payables

Prepayment Invoice

Column not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Purchasing

Purchase Order

Column not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Receivables

Invoice

Column not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Tab not displayed

Receivables

Credit Memo

Column not displayed

Invoice

Required

Populated when the document number is selected and
it is read-only

When you enter the document number of the invoice
this list is available with the respective invoice lines.

An example of an applied document that impacts tax
calculation is that of a Receivables credit memo that references an
invoice. In Receivables there can be standalone credit memos that
drive tax calculation based on the tax attributes entered on the credit
memo and there are applied credit memos that drive tax calculation
based on the referenced document; the invoice. If there is a credit
memo that is not calculating what you expected in Receivables, you
can:

Copy the transaction into the Tax
Simulator.

Simulate each document independently
and associate them in the user interface. The Tax Simulator does not
copy associated documents

Review the credit memo tax lines
independently before the transaction association and see that the
tax calculation is based on the attributes entered on the credit memo.

Associate the invoice in the Reference,
Adjusted, and Applied tab with the appropriate document number and
line and drill to the tax lines. See that the result type value for
the rule results is derived from the reference document. This is indicating
that the tax is not based on the credit memo attributes but those
of the invoice.

Enabling Taxes
for Transactions and Simulation: Explained

A feature of the Tax Simulator is the option
for you to choose the status of the taxes to consider for evaluation.
The transaction header region in the Tax Simulator includes an Evaluate Taxes attribute. The options are: Enabled for simulation, Enabled for transactions, and Enabled for transactions and simulation.

When you define a tax there are two different statuses
the tax can have when the setup is complete. When you select Enable tax for simulation the tax is available
only for processing on Tax Simulator transactions and is not calculated
on live transactions. When you select Enable
tax for simulation and Enable
tax for transactions then the tax is considered active
and is available for processing on both live transactions and Tax
Simulator transactions.

When you create a Tax simulator transaction and the
evaluate taxes status is set to:

Enabled
for simulation: Only taxes with the status Enable tax for simulation are selected for
processing.

Enabled for
transactions: Only taxes that are live or have both Enable tax for simulation and Enable tax for transactions selected on the
tax record are considered for processing.

This
mimics the behavior of the processing for active taxes in the subledgers
and is the default value when simulating or copying subledger transactions
in the Tax Simulator.

Enabled for
transactions and simulation: Both taxes that have a status
of Enable tax for simulation and
taxes that have a status of Enable tax for
simulation and Enable tax for
transactions selected are processed.

This allows you to see behavior of both active and not active taxes
on the same transaction. This is a useful tool when the calculation
of one tax can impact another such as in the case of compounding tax
formulas for tax calculation.

Example

You have two taxes defined that both evaluate to true
for a particular Purchase invoice.

The first tax, FUS_CA, is defined for the sales tax
for the state of California. The tax status is set to Enable tax for simulation and Enable tax for transactions. The second tax,
FUS_ENV, is defined for an environmental tax. The tax status is set
to Enable tax for simulation.

Simulate a live transaction in the Tax Simulator with
the Evaluate Taxes option set
to Enabled for transactions. In
this case only taxes enabled for transactions are processed so the
FUS_CA is the only tax calculated.

Next, update the Evaluate
Taxes option set to Enabled for
simulation. In this scenario only taxes that are enabled
for simulation are processed so FUS_ENV is the only tax calculated.

Finally, update the Evaluate
Taxes option set to Enabled for
transactions and simulation. In this scenario both taxes
enabled for simulation and enabled for both simulation and transactions
are selected so both FUS_CA and FUS_ENV are calculated.

Tax Rules Evaluation
in the Tax Simulator: Explained

Transactions pass key tax drivers relating
to parties, products, places, and processes captured on the transaction
to Oracle Fusion Tax for tax determination. Using these tax driver
values as input, the tax determination process performs a series of
process steps utilizing the defined tax configuration, including various
tax rules defined for each rule type and calculates the taxes that
are applicable on the transaction. Use the Tax Simulator to preview
the workings of your tax configuration before you perform tax calculations
on live transactions in a subledger application.

From the transaction tax details it might not be clearly
evident as to which tax rule from your defined tax setup got processed
or if the calculated tax is the result of the relevant rule condition.
Using the Tax Simulator you can verify the tax determination process
breakdown, the details of the tax rules that are evaluated for each
rule type, and other key factors that are analyzed and applied during
the tax determination process. The Tax Simulator is a tool that allows
you to replicate the transaction details directly or as a copy from
the source transaction. The Tax Simulator provides a detailed analysis
of the decision criteria applied in the tax determination process,
with reference to the defined tax configuration and displays the corresponding
results for each rule type.

The Tax Line Details page within the Tax Simulator
captures and lists out the following key process results that the
tax determination process considers for each tax applied on the transaction:

The types of taxes evaluated, for
example, those enabled for transactions or enabled for simulation

The rule evaluation details for each
rule type, such as:

Result type, default or rule-based

Rule result

Sequence of the rule evaluation,
the successful, unsuccessful and not evaluated tax rules and their
corresponding determining factor sets, condition sets, and detailed
condition elements

This abstract gives you a snapshot of the key results
returned from each tax determination process step and provides pointers
to validate it against the available tax setup. You can modify the
tax setup if the key result areas are not as per the requirements.

Details for
Simulated Transaction Lines: Explained

Use the Tax Line Details page to review the
transaction level details that influence all tax lines and view the
calculated tax lines for your simulated transaction. Each tax line
for each transaction line number is listed in the Tax Line Details
table with the corresponding tax configuration details.

Attributes in tax line details include:

Configuration owner, document event
class, and source

Allow tax applicability

Regime determination set

Default rounding level

Configuration Owner, Document Event Class, and
Source

The configuration owner identifies the business unit
or legal entity on the transaction that owns the tax configuration.
For example, if the business unit is subscribing to the legal entity's
data, the legal entity is identified, rather than the business unit.
In order for a tax regime to be applicable on the transaction the
configuration owner identified has to subscribe to the applicable
tax regime.

The source attribute can have a value of Event class or Configuration
owner tax options. This indicates if the application derives
the event class-specific tax options from a configuration owner tax
option that is defined for the combination of configuration owner,
event class, and date range or if the application derives the options
from the default predefined values for the event class. These tax
options include the option to calculate tax, the regime determination
set, options to allow manual entry and override, rounding defaults,
and details regarding tax calculation on referencing documents. If
the value is Event class then
there are no configuration owner tax options defined for this combination
of configuration owner, event class, and date and the predefined values
are used including the predefined value of TAXREGIME for the regime determination set.

Allow Tax Applicability

The two allow tax applicability attributes identify
whether the tax configuration setup provides for the calculation of
taxes on this transaction. Both attributes must be set to Yes to calculate tax.

The two occurrences indicate the following:

The first occurrence indicates if Allow Tax Applicability is selected on the
predefined event class or applicable configuration owner tax options
setup. If you do not set up configuration owner tax options, then
the default value is set to Yes based on the event class mapping. A value of No appears if configuration owner tax options are set
up and the Allow Tax Applicability option is not selected.

The second occurrence of Allow Tax Applicability validates the hierarchy
of tax applicability from the supplier and supplier site definitions
for procure-to-pay transactions, to the party tax profile, and finally
to the default option for the predefined event class. If the Allow Tax Applicability option is not selected
at any of the applicable levels then tax is not calculated. If the Allow Tax Applicability option is selected
at a lower level and not selected at a higher level then tax is not
applicable. If the Allow Tax Applicability option is set to No then you
can drill down on the link to see where this option is not selected.

Regime Determination Set

The regime determination set indicates how the application
determines the tax regimes to use for this transaction.

There are two values for this attribute:

When the regime determination set
is a value other than STCC (standard
tax classification code) it is a determining factor set of type regime
determination that includes transaction input factors of location
types to derive the owning country on the transaction for tax purposes.
Tax regimes that you defined for the derived country have taxes evaluated
for calculation. The predefined regime determination set is TAXREGIME and this value always populates
if the source is Event class.
Use the drill down to the regime determination set details to identify
the precedence of locations to determine the tax regime country.

When the regime determination set
is set to STCC, the additional
tax attribute of Tax Classification set at the Line Level Tax Attributes tab drives tax calculation
either directly or based on the Tax Classification Based Direct Rate
Rules.

For example, if your simulated transaction does not
have any tax lines, check the regime determination set value. If it
is set to STCC and the Tax Classification field on the Line Level
Tax Attributes tab is blank, tax is not calculated. Review your application
tax options to verify that the defaulting hierarchy that specifies
both the sources to use for tax classification codes and the order
in which the application searches these sources to find a valid tax
classification code at transaction time.

Default Rounding Level

The default rounding level shows in order of precedence,
the party type, source, and rounding level value. At a minimum, a
default value is set. The options are header level or line level rounding.
Header level rounding applies rounding to calculated tax amounts once
for each tax rate per invoice. Line level applies rounding to the
calculated tax amount on each invoice line. The rounding rule is the
method used to round off taxes to the minimum accountable unit. If
there is any concern as to how rounding is determined or if setup
needs to be modified you can use the dialog details in conjunction
with party information to determine where the setup needs to be modified.

For example, on the Rounding Level dialog box for
a purchase invoice you see the following:

Rounding Precedence

Party Type

Source

Rounding Level

1

Bill-from party

Supplier site

1

Bill-from party

Party tax profile

Header

2

Bill-to party

Supplier site

2

Bill-to party

Party tax profile

Line

3

Ship-from party

Supplier site

3

Ship-from party

Party tax profile

Line

4

Ship-to party

Supplier site

4

Ship-to party

Party tax profile

Header

Default

Header

The lowest level of 1 takes precedence over all
other levels. The application uses, the default precedence only if
none of the other levels are populated. If the value is blank then
there is no attribute set at this level. If the you determine that
in this example the bill-from party tax profile rounding level of Header is incorrect you can identify the
bill-from party from the Tax Line Details header information and query
the appropriate party tax profile to modify the setup. This example
is simple in that the header level is the level used for rounding.
If the value was Line there is
more derivation logic starting with the party type derived for the
Determine Tax Registration rule.

Line Level
Details for Simulated Transaction Lines: Explained

Use the Tax Line Details page to review the
calculated tax lines with the corresponding tax configuration details
for each transaction line.

Indicators such as: inclusive, self-assessed,
manually entered, and tax only line

Calculated tax amount and tax base
modifier rate

Legal justification text

Place of supply

For the tax lines associated with each transaction
line, you can review the attributes that are specific to each tax
line, such as:

Rounding rule

Inclusive

Minimum accountable unit and tax
precision

Tax rate modification

Rounding Rule

The Rounding Rule dialog box shows the rounding details
for the transaction line. The rounding rule is the method used to
round off taxes to the minimum accountable unit. The rounding rule
is derived based on the rounding level specified in the hierarchy
visible in the dialog box with level one taking precedence over level
2 and so on. If the rounding level is at the header level then rounding
is applied to calculated tax amounts once for each tax rate per invoice.
If the rounding level is at the line level then rounding is applied
to calculated tax amounts on each invoice line.

Inclusive

The Inclusive dialog box shows the setup related to
enforcing inclusiveness or exclusiveness of tax on a transaction line
by order of precedence. The level 0 precedence is the highest overriding
all other values with the level 5 precedence being the lowest or the
default if none others are populated. The values are Yes or blank with blank meaning an option
was not selected for inclusive handling.

In the scenario represented in the following table,
tax is calculated as inclusive based on the setting for the tax rate.
If you needed to modify this you can update the inclusive handling
on the appropriate tax rate. If the transaction input value tax inclusive
is set to Yes this means this
option was overridden directly on the transaction.

Precedence

Source

Inclusive

0

Transaction input value tax inclusive

1

Tax rate

Yes

2

Tax registration

3

Site party tax profile

4

Party tax profile

Yes

5

Tax

Minimum Accountable Unit and Tax Precision

The Minimum Accountable Unit and Tax Precision dialog
box shows the derivation of these values by precedence. The minimum
accountable unit is the smallest unit a tax amount can have. Tax precision
is a one-digit number that indicates the number of decimal places
to which to calculate a tax.

For example, a precision of 0 rounds to a whole currency.
To round off a calculated tax amount of 1.366 to 1.37, define a tax
precision of 2, a rounding rule
of Up or Nearest and a minimum accountable unit of .01. If the results are not what you expected
the dialog window gives you more information as to the source of the
definitions. The precedence of 1 is the highest with the definition
at the currency level superseding the definition at the tax level.

The following table illustrates this example:

Precedence

Source

Minimum Accountable Unit

Precision

1

Currency

2

2

Tax

.01

2

Tax Rate Modification

The Tax Rate Modification dialog box identifies if
any applicable rate exceptions have been applied, and, in the case
of Receivables, if any exemptions are applicable. The rates before
and after any modifications are also shown. The tax rate modification
value is Yes or No with a link for you to drill down to detail
information. If the tax rate modification value is Yes then there is a modification to the tax
rate either from an exception or an exemption. The dialog box detail
shows the tax rate name, the tax rate before modification, attributes
to identify if exemptions or exceptions or both are applied, and the
tax rate after each of these modifications.

In the following table the original tax rate was 5
percent with an exemption applied that reduced the tax rate to 2 percent.

Attribute

Value

Tax Rate Name

VAT 5%

Tax Rate Before Modification

5%

Exception Applied

No

Tax Rate after Exception

5%

Exemption Applied

Yes

Tax Rate after Exemption

2%

Tax Rule Details
for Simulated Transaction Lines: Explained

For the tax lines associated with each transaction
line, you can review the tax rule details that are specific to each
tax line, such as:

Rule results

Rule conditions

Tax rules process results

Rule Results

Use the Rule Results table to view the tax rules that
are applied to each tax line for each tax calculation process. For
each rule type, you can view the processed result and verify whether
the result was determined by a tax rule or the default value.

For example, the following table shows the attributes
displayed in the Rule Results table:

Rule Type

Result Type

Result

Rule Code

Rule Order

Determine Place of Supply

Default

Ship to

Determine Tax Applicability

Default

Applicable

Determine Tax Registration

Rule based

Ship-to party

REGRULE2

20

Where a tax rule is applied, you can determine the
associated tax rule from the Rule Results table. In the previous example,
the tax determination process uses defaults to determine the place
of supply and tax applicability. However, the tax determination process
determines the tax registration based on a tax rule. The applicable
tax rule code is REGRULE2.

Rule Conditions

By selecting the Determine Tax Registration row, you
can review the rule conditions that are successfully evaluated in
the Determine Tax Registration: Rule Conditions table. The following
table shows the attributes displayed:

Determining Factor Class

Class Qualifier

Tax Determining Factor Name

Operator

Value or From Range

To Range

Registration

Ship-from party

Registration Status

Equal to

Not Registered

For example, if your transaction is calculating tax
lines for a tax that should not be applicable, review the Determine
Tax Applicability rule values in the Rule Results table for that tax
line. If the Result Type is Default with a result of Applicable,
verify that you have a Determine Tax Applicability tax rule that evaluates
your transaction as not applicable.

Tax Rules Process Results

Use the Tax Rules Process Results table to view the
processing and evaluation of the rules associated with a rule type.
For each associated rule, the process result consists of one of the
following:

Failed

Successful

Not evaluated

For example, the Determine Tax Registration rule type
may have 3 associated tax rules as represented in the following table:

Rule Code

Process Result

Evaluation Order

Rule Order

REGRULE1

Failed

1

10

REGRULE2

Successful

2

20

REGRULE3

Not evaluated

3

30

In this example, the tax rule with the highest rule
order priority failed, while the rule with the next highest rule order
priority is successful. In this case of 3 associated tax rules, the
tax determination process does not evaluate the remaining tax rule.

For each rule in the Tax Rules Process Results table,
you can also review the following:

For each tax rule listed in the Tax Rules Process
Results table, you can drill down to the associated rule conditions
to review the condition details.

For example, if your transaction is correctly using
tax rules to calculate taxes but is applying an incorrect tax rule,
use the Tax Rules Process Results table to review the rule order and
the associated rule conditions for each tax rule.

Using the Tax
Simulator to Analyze Tax Not Calculating as Expected: Example

Use the Tax Simulator to create a simulated
transaction and analyze the tax calculations of your transaction before
you enable your setup for live data or to troubleshoot existing tax
setup. Use the header level details in the Tax Simulator to troubleshoot
issues where tax is not calculated as expected.

The following scenario illustrates when you might
want to use the Tax Simulator to evaluate a Payables invoice where
you expect tax to be calculated and it is not.

Scenario

If there is a transaction in the subledger work area
that is not calculating tax you can simulate this transaction in the
Tax Simulator.

Note

The transaction date in the Tax Simulator is updated
to the system date so modify the transaction date to the expected
date of tax calculation.

The following represents each of the attributes in
order to assist you in determining what information they can provide
to identify the issue:

Document
Date: Ensure that the document date is correct and that
the regime to rate setup and applicable tax rules are effective as
of this date?

Configuration
Owner: Determine if the configuration owner is the legal
entity or the business unit. Does the respective configuration owner
have a subscription definition to the tax regime where you are expecting
tax to calculate? Is the subscription effective on the document date?

Document
Event Class and Source: Determine if the source is accurately reflected. The source identifies
if the tax options are derived from the predefined event class or
if they are derived from the configuration owner tax options that
are defined. If they are derived from the configuration owner tax
options you can query the configuration owner tax option definition
by the configuration owner and document event class and view options
based on transaction date effectivity. Other attributes and options,
such as Allow Tax Applicability, Tax Regime Determination, and Enforce tax from reference document are included
in configuration owner tax options. Issues with tax calculation may
stem from the regime determination definition not being what is expected
either the standard tax classification code and not the TAXREGIME
determination or the reverse. If these are intercountry transactions
ensure that the precedence of regime determination points to the expected
country of taxation.

Allow Tax
Applicability: Ensure that this option is set to Yes for tax to calculate. This is the value
defined on the source value in the previous attribute. There is another Allow Tax Applicability attribute in
this region that checks the value from the applicable party.

Regime Determination
Set: Ensure that the regime determination set is accurately
specified. This attribute indicates if tax calculation is determined
by the standard tax classification code or if country of regime is
evaluated as in the case of the predefined TAXREGIME regime determination
set.

Default Rounding
Level: This does not impact tax calculation but identifies
the rounding derivation.

Third party location: Determine if
the third party locations are accurately reflected. These attributes
help identify locations on this transaction that may influence regime
determination and tax calculation based on location. There may be
other locations set at a line level that may impact tax calculation
as well.

Allow Tax
Applicability: Ensure that this option is set to Yes for tax to calculate. This option is
derived from the supplier, supplier site, third party, and third party
site tax profile depending on the event class. Tax applicability must
be set to Yes for all relevant
party tax profiles in order for tax to calculate. If tax applicability
is set to No for either attribute
then tax is not processed.

Evaluate
Taxes: Ensure the status of the tax you are expecting
to calculate. Is it Enabled for transactions, Enabled for simulation, or Enabled for transactions and simulation?
This identifies what status of taxes is evaluated for calculating
tax.

FAQs for Verify Tax Configuration

When do I create
a simulated transaction and when do I copy a subledger transaction in the Tax Simulator?

Create a simulated transaction when you want
to control the testing of specific transaction attributes or when
you do not have transaction data available, such as for a new tax
regime.

Copy a subledger transaction to examine either the
transaction itself or your tax configuration. For example, the tax
calculation on a transaction may have yielded correct but unexpected
results. Or you may want to evaluate variations of a transaction to
see the tax impact, or you may want to evaluate major changes to your
tax configuration.

What's the difference between taxes enabled for transactions and taxes enabled for simulation?

On a tax record, you specify whether the tax
is enabled for transactions, simulation, or both. During testing,
enable a tax for simulation to ensure the setup is correct. When setup
is complete and tested, enable the tax for actual transaction tax
processing.

When you create a simulator transaction, you
can select which types of taxes to evaluate for applicability: taxes
enabled for simulation only, taxes enabled for transactions only,
or both.