Tick & Tie Finance Blog

The 10 Cardinal Sins of ERP Implementation (and The 10 Rules to Avoid Them)

January 23, 2020

ERP Systems are notoriously complex and expensive. Survey’s of executives and analysts studies show failure rate of 50% - 75% and a “fail to meet expectations” rate of 80%. Not only do they tend to take longer than expected and cost more to implement, but the business results may not meet the high bar required to sell in and get executive buy-in. Read this guide to avert the 10 cardinal sins and give you a higher chance of ERP Implentation success!

Few F&A staff will experience an Enterprise Resource Planning (ERP) implementation during their career, let alone multiple implementations.  I have implemented at least 14 systems over my career, including several ERPs.  My roles ranged from coder/configurator to project manager to executive sponsor.  

The first-time we do something is often fraught with mistakes, simply because we don’t know any better.  A hedge against mistakes is taking advantage of the wisdom of others who have walked the path before us.  My hope is to share some of the wisdom I’ve developed to help those of you facing an ERP implementation make it successful.

Over the years, I’ve developed set of core principals whose violation constitutes cardinal sins.  Cardinal Sin implies there must be a corresponding Cardinal Rule.  In the spirit that positive is more motivating than the negative, the following are Cardinal Rules important to successful ERP implementations:

Guiding Rules to Combat the Cardinal Sins

Rule 1: Executive Sponsor Must Be a Strong and Engaged C-Level Executive

Rule 2: No Customization – Period.

Rule 3: Never (ever, ever, ever) Migrate Historical Transaction Data

Rule 4: One Common and Identical General Ledger Chart of Accounts (COA) For All Entities

Rule 5: Never Duplicate Cost Center/Department Numbers

Rule 6: Identical Definitions for Other Code Segments

Rule 7: Never Force Old Process on New Technology

Rule 8: Establish (Truly) Dedicated Intercompany Accounts

Rule 9: Make Transactional Numerical Sequences Unique Across the Enterprise

Rule 10: Always Include Alpha Characters (Prefix or Suffix) for Transactional Numerical Sequences

Now, for more detail…

Rule 1: Executive Sponsor Must Be a Strong and Engaged C-Level Executive

Successful ERP projects start with strong leadership.  Unlike more localized systems, ERPs span the entire organization.  The job of an executive sponsor is to support the project manager and team by acquiring resources, removing obstacles, enforcing project principals, protecting scope, and owning accountability and timeline.  Individuals below C-level executives simply lack sufficient power to drive these areas across the organization.  Poor choice of the executive sponsor is a cardinal sin.

Studies of poor or failed ERP implementations frequently identify a variety of tactical mistakes as culprits.  These are only symptoms.  Fundamentally, the source issue is either delegation of the Executive Sponsor role to someone below the C-Level, or the C-Level executive assigned is weak and un-engaged.  Ideally, organizations should tie some portion of the C-Level Executive Sponsor’s compensation to project success.

Key Insight :  My advice is if the organization is unwilling to identify a strong C-Level executive as Executive Sponsor for your ERP implementation, don’t bother to do the project.

Rule 2: No Customization – Period

Let’s distinguish between “customization” and “configuration”.  Customization occurs when the ERP application source code is modified.  Configuration occurs when the application allows your company to select or change available settings without affecting source code.  Simple examples might be to configure approval authority workflows or changing a setting to require two-factor authentication in order for users to logon.  

Customizing the application or database is a cardinal sin because this requires modifying the source code.

Choosing to modify source code means your company is also choosing to become an ERP software developer.  Whether you use internal resources or outside consultants, modifications require proper software development practices and testing, thereby increasing project risk and extending timelines.  More so, once source code is modified, the company loses its normal upgrade path, regardless of whether your software is a hosted in the cloud, hosted on premise, or a SaaS subscription.  Upgrades become far more difficult and costly, which cause companies to skip release cycles, which in a vicious cycle create further additional complexity and cost when the upgrade finally occurs.  SaaS ERP vendors keep releases up-to-date.  These forced upgrades occur regardless of whether your company is ready.  Customizations are likely to break at the point of upgrade unless you commit development resources to update the customizations to the new release during the testing period.

ProTip: If anyone suggests or demands changes that would result in (source code) customization – the answer is “no”.

Rule 3: Never (ever, ever, ever) Migrate Historical Transaction Data

Data migration is painful, costly, difficult, complex, and painful and costly.  Oh, did we mention data migration is painful and costly?  Minimize your pain and cost by minimizing what data is moved from the old system to the new.  With a thick dose of hyperbole, a rule of thumb could be, “Only migrate data that you are willing to personally re-key into the new system.”  While not practical in a literal sense, you get the idea.  

Metadata and master records are the primary data that should be migrated.  Customer and supplier master records, bill-of-materials (BOM), inventory master records, etc. and metadata such as product line codes, inventory starting balances, etc. should be migrated.  Try to minimize the number of open customer or supplier orders or invoices to be migrated.  If you have the cash to support it, one effective strategy is to flush all payables (i.e. pay all open payables) and drive accounts payable to zero.

Undoubtedly, there will be legions of people insisting historical transaction data must be migrated for research, reference, or other.  This data exists in your legacy system databases.  An effective strategy is to archive the data and database when deprecating your old application.  Let people know they can request a data-pull from IT for any historical transaction data request they may have.  I have found requests are made only rarely as the new system quickly develops a sufficient new history of transactions to be useful for planning or other.

Key Insight: Migrating transaction history is a cardinal sin – it is simply not worth the pain and cost.

Rule 4: One Common and Identical General Ledger Chart of Accounts (COA) For All Entities

All ERPs allow you to define code string segments for each entity.  This cardinal rule is focused on the General Ledger Account segment specifically.  We will address other segments (Geo, Cost Center, Product Line, etc.) separately.

It is absolutely critical to define a single GL COA and ensure every entity’s GL COA is identical across all entities.  Doing so results in consistency of use, improves workflow, reduces errors, enables easier consolidation, and tremendously helps analysis and research.  Establishing different GL COAs for each entity is a cardinal sin.

Common complaints regarding this Cardinal Rule are entities will see accounts they will simply never utilize or the additional unused accounts are clutter.  Many systems allow administrators to hide or set accounts to inactive.  Even if not, having the additional accounts visible is a far smaller sin than creating accounts with identical GL numbers but wholly different purposes and fighting endless error, consolidation, and analysis battles.

ProTip: Use the new ERP as an opportunity to get organized and have one common and identical General Ledger Chart of Accounts for All Entities.

Rule 5: Never Duplicate Cost Center/Department Numbers

Almost every company designates one code string segment for use as cost center or department numbers.  Unlike the GL account segment, we want to department numbers to exist once and only once across the enterprise, regardless of the number of entities within the enterprise.  For example, if your Mexico entity has department 331, that number should never be used anywhere else in the enterprise.  

It is tempting to “align” department numbers across entities.  It may seem logical, for example, to have your US, France, and Canada entities all use Department 410 for Marketing Marcom.  Wrong for several reasons.  When you discover a Marketing Marcom problem during consolidation (and you will), identification of which entity is the offending source becomes far more difficult.  Coding errors become common as shared service staff have several entities on their screens at once and tag a transaction for Department 410, but in the wrong entity.  Variance root cause analysis is more complex, etc.  

Unique department numbers solve these problems.  When you design the departmental structure, simply reserve the “410” series for Marcom: Department 411 can be the for US entity; 412 is for the Canada entity; 413 is for the France entity; and so forth.    

Key Insight: Duplicating cost center/department numbers is a cardinal sin.

Rule 6: Identical Definitions for Other Code Segments

Beyond GL Account and Department, many ERPs allow several additional code string segments to be used however the company chooses.  Other segments may include geography, business unit, product line, product family, site, or other.  In almost all cases, a single common taxonomy is important, and should result in an identical structure for a given segment.  Establishing different segment taxonomies for each entity is a cardinal sin.

Geography is a good example.  If one entity defined its geography code segment according to states and another according to metropolitan statistical areas (MSA), analysis by geography would quickly become meaningless, or require extensive analytical effort to align for comparative analysis.

Invest the effort at the beginning of the ERP project to carefully design code segments with common definitions and allowance in the structure to add new items (a new MSA for example).

ProTip:  Ideally design code string segments to be different lengths.  For example, let’s say you’ve determined the applicable code segments for your enterprise are: GL Account, Department, Product Line, and Geography.  Code segment lengths might be: GL Account (6); Department (3); Product Line (4); Geography (5).  Users will quickly recognize segments by the length of the code part.

Rule 7: Never Force Old Process on New Technology

During one of my ERP implementations, my AR module lead came to me in frustration.  “I’ve been working and working with our new ABC system.  It just doesn’t do it like our existing XYZ system.  It’s really frustrating.”

My response to my AR lead was, “If we get to the end of this implementation and the new ABC system does it like the existing XYZ system – then we have failed.”  My AR lead looked shocked.  I continued, “Explore and learn the new ABC system.  Understand its natural workflows.  Take advantage of those.  Take everything you know about the existing XYZ system and throw it out the window.”

Her eyes widened.  “I can do that?” she asked.  

“Of course.” I replied, “You own this.”

We went live globally on the new system.  At the first month-end close, my AR lead came to me bursting with excitement.  “You won’t believe it.” she exclaimed, “I just finished the AR close.  What used to take me eight hours, I just finished is less than 60 minutes!”

Many companies make the mistake of defining their requirements and processes based upon their current technology and processes.  In doing so, they contort or customize (remember this one?) the new technology to act in the same manner as the old.  You are going to a new technology for a reason.  Why in the world would you take a horrible painful process and graft it onto shiny new technology?  (And commit a cardinal sin along the way.)

Key Insight: A new system is an opportunity to get better, not just newer.

Rule 8: Establish (Truly) Dedicated Intercompany Accounts

Intercompany accounting is usually always a cesspool.  Use your new ERP implementation to start afresh and do it right.  The first step is by establishing truly dedicated intercompany P&L and B/S accounts.  Never co-mingle I/C and 3rd party transactions in the same accounts.  Never even co-mingle multiple I/C entities in the same accounts.  Keep everything separate and clean. Co-mingling I/C transactions is a cardinal sin.

The main I/C accounts usually needed are revenue, COGs, AR, and AP accounts.

For simplicity, let’s say you have four entities:

3130 (US - main)

3131 (Canada)

3132 (US – distribution entity)

3133 (Korea)

In addition to your normal 3rd party accounts, your GL COA should include the following I/C accounts:

Revenue I/C Accounts:

4xxx30 Revenue I/C Sold to 3130

4xxx31 Revenue I/C Sold to 3131

4xxx32 Revenue I/C Sold to 3132

4xxx33 Revenue I/C Sold to 3133

COGs I/C Accounts:

5xxx30 COGs I/C Purch From 3130

5xxx31 COGs I/C Purch From 3131

5xxx32 COGs I/C Purch From 3132

5xxx33 COGs I/C Purch From 3133

Accounts Receivable I/C Accounts:

1xxx30 I/C AR from 3130

1xxx31 I/C AR from 3131

1xxx32 I/C AR from 3132

1xxx33 I/C AR from 3133

Accounts Payable I/C Accounts:

2xxx30 I/C AP to 3130

2xxx31 I/C AP to 3131

2xxx32 I/C AP to 3132

2xxx33 I/C AP to 3133

Observing our earlier cardinal rule: One Common and Identical General Ledger Chart of Accounts (COA) For All Entities, these accounts exist in all the entities GL COAs regardless of whether I/C transactions are anticipated across all entities or not.  By definition, this account structure avoids co-mingling of transactions by any entity.

After the implementation, another key rule is: Never Net.  Issue invoices and make payments just like you would any other supplier or customer.

Key Insight: If you follow both the I/C GL COA and Never Net rules, your accounts will be clean, reconciliations will be simple, and you will avoid creating your own cesspool.      

Rule 9: Make Transactional Numerical Sequences Unique Across the Enterprise

We use transactional numerical sequences extensively in ERP systems: invoice numbers, journal entries, order numbers, customer numbers, disbursements, and so forth.  It is critical that transactional numerical sequences result in unique numbers that occur only once throughout the enterprise.  This coupled with the next cardinal rule regarding use of alpha characters as part of numerical sequences is powerful.  

Intelligent and unique numerical sequences reduce confusion, mistakes, and coding errors.  Anyone who has experienced two entities using duplicate numbering sequences can attest to the pain.   It’s fairly easy to design intelligent numerical sequences and avoid the problems.  For example, numerical sequences for entity 3130 may always start the numerical sequence with 3130xxxxxxxxx or simply 30xxxxxxxxx.  Another method may be to vary the length of the numerical sequence that entities use.

ProTip: Duplicating numerical sequences is a cardinal sin.

Rule 10: Always Include Alpha Characters (Prefix or Suffix) for Transactional Numerical Sequences

Let’s help staff involved in process and analysis as much as possible, while still keeping life simple.  A powerful method is to marry alpha characters with transactional numerical sequences. Establishing a prefix or suffix using alpha characters allows staff rapid understanding of the transaction and reduces the likelihood of errors.

Early in the ERP implementation, building an intelligent structured taxonomy of numerical sequences and associated prefix/suffix will improve overall controls and ensure stronger processes. Examples of alpha character prefix/suffix are:

QU- Quotation Number

SO – Sales Order Number

WO – Work Order Number

CU – Customer Number

INV – Invoice Number

CM – Credit Memo Number

AP – Journal Voucher for automated entries originating from Accounts Payable Subledger

AR - Journal Voucher for automated entries originating from Accounts Receivable Subledger

FA - Journal Voucher for automated entries originating from Fixed Assets Subledger

AJE – Adjusting Journal Voucher

MJE – Manual Journal Voucher

RJE – Journal Voucher intended to be reversed

REV – Reversing Journal Voucher

And Etc.

Through the examples above demonstrate, simply by viewing the prefix (or suffix) tells staff quite a bit about the transaction.  If an accounting manager sees a journal voucher with an RJE prefix, she knows to expect a reversing journal voucher in the next period.  It’s easy to confuse sales orders and invoices as they include similar information and format.  The prefix allows staff quick comprehension.  

Key Insight: Do the good work upfront – implement alpha characters for transactional numerical sequences in the planning process for the new system. Your team will thank you later.

Summary

You may review the cardinal rules and sins and feel several are obvious; yet if obvious why do so many project teams commit one or more cardinal sins, resulting in poor outcomes or failures?  ERP implementations are large high-risk complex projects, involving many staff across the organization.  As such, I will point you back to Rule 1: Executive Sponsor Must Be a Strong and Engaged C-Level Executive.  

Leadership is key.  A strong Executive Sponsor and Project Director is critical to enforce core project tenants- Cardinal Rules.  With their support and your expertise, you can successfully implement technology critically important to your company, and have a professionally rewarding experience along the way.

Remember, a new ERP system is an opportunity to atone for previous sins and get organized so don’t commit new sins in the process of implementation!

Related Posts & Resources

Reducing Time to Close through AI-driven Reconciliation

According to the APQC General Accounting Open Standards Benchmarking survey (2,300 companies participated) - Cycle Time for Monthly close ranges from 4.8 days or less for the top 25% of companies to 10 days or more for the bottom 25% of performers.

Learn How To Be a Top Performer
Cost Savings through AI-driven Account Reconciliation

According to a study by Robert Half & the Financial Executives Research Foundation (FERF), only 13% of F&A teams have utilized advancements in technology solutions, with the majority of CFO’s admitting they still struggle with painful aspects of account reconciliation.

Read About AI-Driven Cost Savings
Automating F&A and Operations through AI

It's time for finance and accounting operations to move beyond spreadsheets and fragile rules based systems. Next generation technology such as Machine Learning provide specific solutions to hard problems.

Read About F&A Automation with AI

Get the CFO Brief

Our newsletter is built for F&A professionals to deliver insight into new technologies, advice to advance your career and tools/tips to make your job easier so you get your evenings and weekends back.

Schedule a Demo

Click here to watch a short product video or set up time to see for yourself how simple account reconciliation can be.

Blog Categories

Blog Tags

Build Your Knowledge

Sign up for the Sigma IQ - CFO Brief and let us help you advance your knowledge and career by delivering articles, insights, and other resources geared towards Finance & Accounting teams.

© 2019 Sigma IQ. All Rights Reserved.
Privacy PolicyTerms of Service