Creating Value and Reducing Risk Through Enterprise Tax Management
Tax is an integral part of the corporate finance and accounting capability and, as such, must be addressed by finance and accounting system implementation projects from the beginning. The tax attributes of each transaction must be captured as part of the original processing within the ERP system. The data needs to be available to the tax function to perform one or more core activities: determination of taxability, calculation of tax, and tax reporting.
During an initial ERP implementation tax is often overlooked or deemphasized. Although tax is an area representing significant risk and value, few companies take a comprehensive approach in addressing both the quality of tax data gathered in transaction processing and the supply of tax data to reporting, planning, and audit activities. Organizations have generally followed one of three approaches: 1) expecting the ERP system to handle taxes with minimum configuration, 2) relying on a bolt-on or a return preparation system to manipulate data for filings, or 3) hoping that the existing tax data infrastructure will evolve with the change in systems.
All three of these approaches ignore a key information system axiom: garbage in, garbage out. The quality of tax data in tax filings will rarely be better than the tax data contained in the core transaction systems (i.e., if the ERP system does not contain the necessary tax attributes, it will be nearly impossible to cleanse the data for tax filings). Further, tax data does not occur naturally. There is no tax module in ERP systems and it must be proactively configured to produce and capture tax data.
This article discusses why tax should be included in all ERP designs, examines the reasons why ERP project teams often ignore tax, demonstrates the value of including tax requirements in the ERP implementation, and suggests a course of action for ERP implementations in various stages of completion.
Tax Process Dependence on ERP System Data
A high-level overview of the tax process, focused on the production and use of data, assists in understanding the importance of tax configuration of the ERP system. The tax process consists of two major components: generation of accounting and operational data within source systems and tax department processing of data to produce ultimate deliverables (Figure 1).
A high-level diagram does not adequately show the difficulty encountered by the tax department in retrieving tax data from the ERP system. First, one must understand that tax data does not reside in any one place in the system; tax professionals must retrieve information from many different modules within the ERP. Using a complex combination of automated interfaces, standard and custom reports, ad-hoc queries, and data collection packages, the tax organization often spends up to 60 percent of its time and effort collecting data that already exists somewhere else in the organization. When a new ERP system is implemented, this data collection infrastructure is disrupted – and often must be rebuilt from scratch. Properly addressing tax requirements, including both the source and supply of tax data in the ERP design, is the best way to reduce the effort the tax department spends on collecting and processing data and to ensure that key tax data remains available.
Addressing tax requirements in an ERP implementation requires design and configuration in three areas (Figure 1):
- Definition of the transaction data necessary to support the core tax process.
- Design of core tax processes (determination, calculation, and recording of transaction-based taxes and integrated direct tax processes, including the use of bolt-on packages if applicable).
- Creation of access to the subset of ERP data that is tax relevant (through reports and/or interfaces).
Each of these areas poses unique challenges to the implementation team.
Understanding and Resolving Tax Project Issues
A Traditional Project Organization
ERP implementations are traditionally organized around business processes (order-to-cash, purchase-to-pay) or enterprise system modules (asset management, general ledger). In most cases, a dedicated team of project resources and business users is formed to document the envisioned business process and to configure the ERP software to enable that process (through a combination of delivered functionality, custom programming, interfaces to external systems, and reports). It is important to note that the team generally limits its activities to those occurring within the boundaries of the enterprise system (ES); non-ES activities may involve data interfacing to or from the ES.
There Is No Tax Module
As noted earlier, no ERP vendor has a tax module. There are probably a number of reasons for this: 1) it would be difficult to decide on the scope – indirect (transaction-based) taxes versus direct (periodic) taxes and to choose among the hundreds of countries where taxes apply, 2) the constantly changing rules and rates would create an inordinate maintenance burden for vendors, and 3) depending on the type of tax, the determination, calculation, and reporting process can take place completely outside the ERP system. In these cases (most direct taxes), the ES merely supplies some of the data needed to enable the process, and an external system (or manual effort) is used. Only in rare cases have ERP systems been used for the full cycle: to determine, calculate, and report any particular tax.
Structuring an ERP Tax Team
Our experience indicates that a separate team dedicated to tax design should be formed. In most cases, this team is part of the financial workstream, which may also include general accounting, financial reporting, and inter-company accounting. The tax team serves as the central clearinghouse for tax requirements and design and works with all the major process teams (record-to-report, order-to-cash, purchase-to-pay, projects-to-assets, etc.) to ensure complete coverage. The tax team needs to be involved in five major activities: determination of the requirements, process and data design (including interfaces to external systems), integrated testing, reporting, and data archiving, with two goals:
- Integrate tax requirements into source accounting data.
- Ensure an efficient supply of tax data to key users to support both current data requirements as well as future audit data requirements.
Integrating With Other Process Teams
If possible, the tax team should begin work as soon as the project team is formed, as other teams will make design decisions as requirements are completed. Since tax does not own ERP modules or master data configurations, the impact of tax requirements on these items needs to be known earlier, rather than later. For example, indirect tax determination necessitates the inclusion of certain data fields in vendor, customer, and product masters. The specific field to be used will have to be identified. In addition, direct tax determination, which occurs outside the ERP system, requires entity and location hierarchies to be specifically configured to meet these requirements. Unless these needs are part of the decision process around these elements, rework will be required, which has a negative impact on project cost and schedule. Figure 2 illustrates some of the data used in tax processes and its source in various ERP modules.
Failure to properly address tax requirements results in the tax department being unable to access some or all of the data in Figure 2. Specific examples and potential financial impacts are discussed in the following section.
Value Proposition
Risk, Efficiency, and Value
Data is the lifeblood of any tax organization. Access to tax-sensitive data from the financial and operational systems is the principal differentiating factor between high performance tax departments and those performing at or below the average. As expected, the performance of the tax organization has a significant impact on organizational performance as a whole. Properly addressing tax requirements and including both the source and supply of tax data in the ERP design improves corporate performance in three distinct areas:
- Risk Mitigation – The tax organization will be able to meet statutory requirements and defend the filed returns, avoiding fines, penalties, and other legal consequences.
- Operational Efficiency – Tax activities can be performed at the minimum cost.
- Value Targeting – The tax function enables the company to minimize its total tax burden through current and forward planning and reduce tax-related variability in earnings and cash flow.
The following examples relate to these three benefit areas and illustrate the implications of ERP tax design on different transaction types, the benefits gained, and risks mitigated. Included are examples of data impacted by inclusion or exclusion of tax requirements.
Risk Mitigation
Taxing authorities have the legal right to respond in several ways when an organization does not accurately meet compliance requirements, including assessment of heavy fines/penalties – even imprisonment of corporate officials. Thus, the risk of noncompliance is often thought to exceed the cost of including tax design in the implementation.
Indirect Taxes: An area of significant concern for a number of clients is indirect (transaction-based) taxes.
Example: A global integrated oil and gas company estimates that on an annual basis it calculates at least $25 billion of indirect taxes – accuracy is important since a 1 percent error rate might result in an additional $250 million of tax liability, which can more than double due to interest and penalties if discovered three to five years later upon audit.
The solution involves configuring vendors, customers, products, and services and impacts both the purchasing and sales processes. If properly set up, transaction taxes are correctly calculated and remitted; the volume of transactions precludes manual review or workarounds.
Direct (Periodic) Tax Data for Audits: Direct taxes can carry equal or greater risk, particularly if sufficient data is not available to support previously filed returns.
Example: A technology client believes that the potential risk of noncompliance with Internal Revenue Service record retention requirements under Revenue Procedure 98-25 could total over $500 million, plus interest and penalties.
Often, the need to purge detailed transaction data to maintain system response time (known as performance archiving) leaves the tax department without the ability to access prior period transaction data for audits. This means that the character of income and expenses reported on filed returns may not be supported by transaction data. This could have a negative impact in the following areas:
- Tax-exempt income
- Meals and entertainment expenses
- Research and development expenses
- Nontaxable sales or purchases
- Gross receipts, payroll, and/or property apportionment
- Foreign source income and expenses
- Intercompany profit data (i.e., transfer pricing, cost allocations)
Tax must develop a data/record retention strategy, integrated with the ERP implementation, to ensure not only access to critical information, but to comply with statutory requirements around record retention.
Depreciation and Property Data
Tax depreciation expense is usually the largest single book-to-tax adjustment made when calculating taxable income. Asset management is an area that can be difficult to correctly configure. The taxing authority requires the corporation to calculate (regardless of cost) accurate tax-based depreciation expense, gain/loss, or property-based apportionment. If incorrect, they have the authority to completely disallow the deduction/apportionment.
Example: Another global integrated oil and gas company had not configured an ERP system for tax asset management and was using an external system to calculate tax depreciation. When some errors were discovered in the external system, the company moved to convert asset management data into the ERP system. With a net asset base of over $35 billion, the net impact of erroneous depreciation calculations could exceed $3 billion, if disallowed on audit. Since audits often run several years behind the original filing of the return, a 10 percent compounded interest/penalty adjustment can easily double the annual cost of improper tax implementation.
Data contained in the asset management module impacts a number of different tax areas and types of data, including:
- Financial and tax depreciation expense (tax depreciation may be calculated many different ways – four or more for U.S. jurisdictions; numerous others for non-U.S. locations)
- Physical location for property tax assessment
- Property apportionment for income tax
- Fixed asset inflation adjustments
- Tax basis for gain or loss
- Earnings and profits for dividend taxability
Operational Efficiency
The tax organization is a primary user of the data produced by the ES. When processes, data structures, and reports are designed to accommodate the tax organization as a user, time-consuming manual data requests and data manipulation tasks are reduced or eliminated. Data delivery is especially important because tax data gathering infrastructures built around legacy systems become obsolete as soon as the new ERP system goes live.
Asset Management Data
The large dollar value of asset management transactions is most often accompanied by a large number of transactions; at the minimum, depreciation expense must be calculated for assets still owned by the organization. The inefficiencies created by inadequate system configuration are not limited to the tax organization.
Example: An oil and gas company had not configured its ERP system for tax asset management, resulting in the following inefficiencies:
- Property Accounting – Some data items available within
the ES were not adequate for tax needs and included: asset classification,
asset transaction details (additions, transfers, disposals), and tax basis
reporting.
Information unavailable through the system was collected via conversations with property accounting and review of physical documents representing the asset transactions. - IT Organization – The ES was not configured to properly calculate
the following key tax data items such as tax depreciation and tax gain/loss.
As a result, a specialized tax depreciation solution was required. The add-on solution and mapping from the ES had to be maintained and detailed asset transactions had to be transported into the tax depreciation solution by the IT organization on an annual basis. In addition to the data management inefficiencies, this annual solution limited the ability of the tax department to estimate depreciation and property apportionment factors for estimated tax payments during the year. - Tax Organization – Tax personnel managed a second set of
asset records within the tax depreciation solution.
Any missing details regarding the nature of the asset transactions had to be discussed with property accounting, potentially resulting in reclassification after data had been imported into the tax system. In addition, detailed reconciliation had to be performed between the tax system and ERP systems had to be performed prior to filing the tax returns.
Expense Data
When the purchasing process is not effectively configured, the categorization of expenses is often left up to an accounts payable clerk. Further, the financial accounting structure (chart of accounts) may not be sufficiently detailed to determine the tax treatment of expenses.
Example: A global beverage distributors accounting processes did not capture tax relevant data, resulting in the need for detailed analysis of hundreds of accounts, including:
- Advertising and promotional spending
- Tax withheld at source
- Legal and professional fees
- Capital versus revenue expenditures
- Entertainment expenditures
This caused the return filing to be delayed by four months, while approximately 10 tax and accounting professionals completed the analysis.
Value Targeting
As tax operations become more efficient, the potential for value targeting grows. Tax personnel, armed with more accurate estimates of the companys current tax status, have more time to become involved in tax planning analysis and management decision support. This can lead to increased value in the compliance, audit, and planning processes.
Indirect Tax Audit Data
When indirect tax processes are not optimally configured, the data available for audits may be limited. This may include the following:
Data needed for tax determination (vendor, customer, product, service master)
- Product/service use
- Jurisdiction(s) of application
- Pricing and discounts
- Tax(es) applied
- Tax rates and bases
- Allocation of tax to invoice line item
Example: An oil and gas company did not have efficient access to key data for indirect tax audits, resulting in a cycle time of almost three years from the receipt of notice to the completion of the audit. By employing enterprise data management solutions, including tax data interfaces from multiple ERP systems, the company estimates a 60 percent decrease in audit cycle time and an annual savings of $4 million to $5 million in interest related to audit settlements.
Book-to-Tax Adjustment Data
Tax sensitive configuration of accounting processes can include not only tax-relevant accounts, but business rules that assist in the identification of specific data to be used in tax accounting, tax estimates, and return filings.
This data may include the following:
- Accruals and reserves
- Accounting method changes
- Acquisitions and dispositions
- Uniform capitalization
- Special classes of expenses (meals, entertainment, lobbying)
- Research and development
- Pension plans
- Stock options
Example: A transportation company generally used the last filed tax return as the basis-for-book to tax adjustments when estimating taxable income for quarterly estimated payments, extension payments, deferred tax reporting, and management decision support. By tax sensitizing the ERP implementation at the source transaction level, and enabling the efficient supply of current tax data, the company projects an annual savings in excess of $10 million related to the interest cost of estimated tax overpayments.
Timing of Tax Involvement
The nature of tax data and the structure of ERP teams usually results in the tax requirements being considered after the design basis for the system has been established, leaving the tax team struggling to catch up with the other project teams. The negative impact of changes to the established designs may lead to the perception that tax data requirements create unneeded complexities. Starting the tax team as early as possible in the project can mitigate this risk.
From the Beginning
The best-case scenario has tax included in the scoping and planning phase of the project, which allows for sufficient staffing from both a project team and business user perspective. Tax work is scheduled on a number of cycles of varying duration and significant lead-time is often required to schedule tax resources for design, configuration, and testing tasks. In addition, there are a number of legal and tax requirements that must be met in the initial system design – in many cases, legal approvals are required to change the format or the source system for tax and/or statutory reporting. Finally, tax is an integral part of many transaction documents (sales invoices, purchase orders, inventory movements) and is a part of the transaction processes owned by other teams. If the tax team is not participating in the base design of these processes, it is a virtual certainty that there will be costly rework or significant risk of noncompliance.
Stuck in the Middle
Once the project enters the detailed design phase, it is probably too late to comprehensively address both indirect and direct tax requirements. If system-build activities have commenced, this is certainly the case. In this case, the tax team should focus first on those data elements that drive the determination of indirect taxability. Thus, the transaction data and process design should be carefully analyzed to ensure that (at least) location, vendor, product, and customer attributes are correctly configured and data is stored in an accessible location in the ERP system. Depending on the complexity of the companys business model, and the number of jurisdictions in scope, the team may be able to bolt-on a third-party tax determination and calculation system. This will limit both the amount of custom programming and the disruption to the core transaction processes, resulting in an adequate solution. Next, the team should analyze data structures that impact direct tax, including account, location, and entity hierarchies. In our experience, direct tax requirements are more effectively mitigated later in the process because (by definition) direct tax is determined on a periodic basis, not on each transaction.
After the Fact
Once the build phase of the project is complete, it is time to consider damage control. It is likely that the business process teams have addressed some indirect tax requirements – companies that sell product or services to end consumers should have a method to charge transaction tax (sales tax, GST, VAT). Assuming this is the case, the team should review the current system configuration and perform a gap analysis, focusing first on indirect taxes, since they are the most difficult to correct. (Direct tax data are usually extracted from the system into a third-party application, where it is cleansed as necessary and aggregated for reporting.) The results of the gap analysis and the proposed solutions are reported to business and project leadership to determine what, if any, remedial action should be taken. In any case, record retention requirements should be considered, both prior to decommissioning of the legacy systems and before the start of performance archiving in the ERP system.
Summary
In our experience, most ERP implementations do not include a comprehensive treatment of tax requirements, leaving companies vulnerable to substantial risk related to inaccurate filings and an inability to defend filed returns. These companies also lose significant potential benefits around operational efficiencies and opportunities to generate value in the tax organization. While the benefits alone should be more than adequate to support integrating tax as part of a companys ERP implementation, the risk of not integrating tax may simply be too great to ignore.
