ERP Advisory, Selection and Implementation Support

Engaging an ERP advisory and implementation consultant who is also a CPA and a former CFO changes which questions get asked before the contract is signed. Implementation partners are paid to configure what you specify. Almost nobody in the room is paid to tell you the specification is wrong.

That gap is where the money goes. The integrator delivers precisely what was requested, on time and within scope, and the result disappoints anyway, because the requirements were collected from people describing the system they already had instead of the decisions they need to make.

What an ERP advisory and implementation consultant does before selection

Companies typically start with vendor demonstrations. That is the wrong first step, because every demonstration is compelling and none of them are comparable until you know what you are comparing against.

What comes first:

• Requirements grounded in decisions, not in current reports. Asking what reports people receive today reproduces the current system's limitations in the new one.
• Chart of accounts and dimensional design. Determined before selection, because it dictates whether the system can produce the analysis you want. Detail on this is on the accounting and controller services page.
• An honest assessment of data quality. Migration effort is driven almost entirely by the state of the source data, and this is where implementation timelines slip.
• Integration inventory. Every system that currently exchanges data with the ledger, including the exchanges that happen through a person and a spreadsheet.
• Compliance and control requirements. If you have SOX obligations, a SOC 2 programme, or an audit, the control requirements are design inputs. Retrofitting them afterwards costs several times more.

Selection, honestly conducted

Most mid-market selections come down to a small field, and the differences that matter are rarely the ones that dominate the demonstrations.

The questions that actually predict satisfaction: does it handle your specific revenue recognition model natively or through workaround; can it produce the dimensional reporting you specified without a separate BI layer; what does the multi-entity consolidation genuinely look like if you have or will have more than one entity; how good is the implementation partner, which matters more than the product; and what is the five-year total cost including licensing, implementation, integration and the internal time nobody budgets for.

The advice given most often, and least welcomed: the company that has outgrown QuickBooks usually does not need a tier-one ERP. The gap between them is populated by systems that are substantially cheaper, faster to implement, and adequate for another five years of growth.

Data migration and reconciliation

Where implementations fail visibly. The pattern is consistent: master data migrates with duplicates and inconsistencies intact, opening balances do not tie, historical transactions are loaded at a summary level that makes prior-period analysis impossible, and the first close in the new system produces numbers nobody can reconcile to the old one.

What the work involves: cleansing master data before migration rather than after, duplicate customers, obsolete vendors, inconsistent naming; deciding how much transaction history to convert and at what level, which is a genuine trade-off rather than a technical question; reconciling opening balances line by line and documenting every difference; and running parallel for at least one full period so that a discrepancy is found before the old system is switched off rather than after.

The reconciliation documentation matters beyond the project. Your auditors will ask how you know the data transferred completely and accurately, and the answer needs to have been created at the time.

Oracle E-Business Suite and legacy migrations

Direct experience migrating legacy accounting systems to Oracle E-Business Suite across General Ledger, Accounts Receivable, Accounts Payable, Inventory and Fixed Assets, including the data reconciliation and cleansing that consumes most of the actual effort.

The recurring lessons from that work apply to any tier-one implementation: fixed assets are almost always worse than expected, with depreciation histories that do not recompute in the new system; inventory valuation methods differing between systems produce differences that must be explained rather than plugged; and sub-ledger to general ledger reconciliation in the first periods after cutover is where errors surface, which is why parallel running is not optional.

Controls and cutover assurance

An ERP implementation is a control environment redesign whether anyone acknowledges it or not. Segregation of duties has to be designed into the role structure, retrofitting it after go-live means telling people their access is being reduced, which is materially harder than granting it correctly at the start.

Also in scope: approval workflows and limits matching the delegation of authority matrix; audit trail configuration meeting evidence requirements; interface controls verifying completeness and accuracy of data moving between systems; and the ITGC design covering the new environment, which the IT audit page covers in detail.

Cutover assurance is a defined go/no-go with criteria agreed in advance, because the decision to go live is made under schedule pressure and needs to have been made objectively beforehand.