Top 10 Reasons Why Your ERP Might Not Work Well For Tax Depreciation

Posted by Kelley LearcloseAuthor: Kelley Lear Name: Kelley Lear
Email: kelley.lear@redmoonsolutions.com
Site: http://blog.redmoonsolutions.com
About: Kelley is a member of the executive leadership team and leads our sales and marketing efforts at Red Moon Solutions. Kelley’s extensive experience in project management, product management, and consulting with Fortune 500 and Global 1000 clients is extremely important in this role.See Authors Posts (127) on Sep 27, 2011 | 4 comments

We have had a great number of tax professionals contacting us with specific questions about what SAP, Oracle, Peoplesoft, JD Edwards and other ERP systems can and can’t do with respect to taxes and reconciliation.   So, Traci and I thought we would help out those of you out there who have been struggling to understand whether or not their ERP system asset module might in fact provide the requirements that the tax department needs to calculate, track and comply with Federal and State filings. These top ten areas to consider have come from our clients, other Big Four consultants who customized ERP’s for tax depreciation, and years of talking to your colleagues out there.

1. They are built for Finance and Accounting needs.  They do not have tax professionals on the development team.  Therefore, the tax law coding is not built into these systems automatically.  Tax law must be coded in by consultants.  This requires your expertise working with IT and the consultants who will code your ERP.  This can be time consuming and costly…not to mention more error prone than third party tools that are focused on tax technical coding, testing and compliance!

2. When there are tax law changes, this will require a scheduled project by IT, your consultants and tax to get the changes scheduled, coded and tested.  There is often a long lag time for changes to be incorporated.  This is a mission critical application for the rest of the company and therefore, updates and changes take a long cycle to plan and test.

3. Books cannot usually handle different tax years, and placed in service dates. They also cannot handle different cost basis across books.

4. Tax does not usually have access to the ERP tax books to be able to update, modify and make adjustments to asset details.  This is typically not an easy process.

5. Not able to complete” life to date” calculations to see what your asset depreciation would be if you needed to make changes or if you assumed that assets were calculated correctly since the asset was originally placed in service.

6. Not able to do “what if scenarios” and to run projection reports into the future.

7. Not easy to merge structures or break them out into detailed entities.  Consolidated and subconsolidated reporting for tax entities is not usually easy or even possible.

8. Cannot see or report on prior year depreciation expense as well as all asset details for audit and other business reporting needs.  Once a year is rolled forward in the ERP, the prior depreciation expense becomes accumulated and prior is wiped clean.

9. Reconciling from book to tax is not easy or even possible in some cases.

10. Don’t have the reports that tax professionals need and want!  Reconciliation reports, roll forward reports, transaction reports, audit reports, etc.  Do not have the tax compliance forms required and cannot integrate or export data easily for importing into compliance software for the 4562, 4797, 4684, 6252.  It’s all about compliance!

Hope this helps!  Feel free to share additional questions, concerns, etc….