ERP Implementation Consultant, USA

Where US ERP implementations usually go wrong

Troubled ERP projects rarely fail on technology. They tend to slip through a series of reasonable-looking shortcuts. In a US setting, the same patterns show up again and again:

• The tax engine is an afterthought. Sales tax calculation is left until late in the build, then the connector, product tax codes and exemption data all need attention at once, just when testing should be under way.
• QuickBooks habits are copied, not redesigned. Classes, locations and a sprawling item list are carried across as they are, so the new system inherits the reporting problems the company was trying to escape.
• Nobody owns the client side. The partner's project manager runs the plan, but decisions bounce between the controller, operations and the owner with no one empowered to close them.
• The SOW is read only after kickoff. Data migration, report building and integrations turn out to be client responsibilities, discovered when the partner asks for files.
• Go-live is set by the calendar. A date chosen at signing becomes immovable, and UAT is cut short to protect it.

A client-side lead does not remove these risks by magic. The role makes them visible early and puts a named owner and a decision date against each one. Where a rollout already shows a handful of these warning signs, ERP recovery may be the better starting point.

Overseeing the partner without slowing them down

Partners do better work when the client side is organized. My role is to make that happen, not to second-guess every configuration choice. In practice the oversight runs through a few simple routines.

A weekly working session reviews status, blockers and the decisions that are due. Each decision goes into a log with the option chosen, the rationale and the approver. Change requests arrive with a business reason and the partner's estimate, and I assess them against the requirements baseline before they reach the sponsor. A short steering meeting with your executives covers risks and anything that needs their authority.

I also read the partner's design documents line by line with your process owners. That is where gaps hide: an approval route that was simplified, an inventory costing method chosen without finance in the room, or an intercompany flow that only works for one direction of trade. Catching these on paper is far cheaper than catching them in UAT.

The partner keeps ownership of configuration, development and platform expertise. I keep ownership of the business view. That split avoids the common situation where the partner both builds the system and decides whether it is acceptable. The broader approach is described on my ERP implementation page.

Data migration from QuickBooks, Sage and legacy systems

US migrations often start from QuickBooks Online or Desktop, a Sage product, or a heavily patched on-premise package the business has run for years. Each brings its own clean-up work, and the partner's migration templates only help once the data is fit to load.

The first decision is how much history to bring across. Many companies move open transactions and balances, then keep the old system or an archive available for lookups. Others need detailed history for trend reporting or audit support. Either choice is valid, but it has to be made deliberately and agreed with your CPA.

Each trial load is then checked against the source, not just accepted because the import ran without errors:

• Trial balance by entity, agreed to the old ledger at the cutover point.
• Open customer invoices and vendor bills, by document, with due dates intact.
• Sales tax payable balances and customer exemption flags.
• Inventory quantities and values by location, reconciled to the general ledger.
• Fixed asset registers if depreciation moves into the ERP.
• Vendor records with the tax details needed for year-end contractor reporting.

Where QuickBooks classes or locations are being replaced by proper dimensions, I map old values to new ones with finance so that comparative reports still make sense. More on the method is on the ERP data migration page and in migrating from QuickBooks.

Testing, cutover and US-specific go-live timing

UAT for a US company has to cover the transactions that are expensive to get wrong. I build scripts from your actual customers, items and vendors: a multi-state invoice with mixed taxability, an exempt customer with a certificate on file, an ACH payment file accepted by your bank, a check run with positive pay, intercompany billing and a full month-end close. Business users run the scripts, and defects are triaged with the partner by severity, not by who shouts loudest.

Timing matters as much as testing. A few US-specific points usually shape the cutover plan:

• Fiscal year-end. Going live at the start of a fiscal year keeps reporting simpler, but year-end close and audit preparation compete for the same finance staff. Agree the trade-off with your controller and CPA.
• Sales tax filing periods. A clean break at a period boundary avoids returns built from two systems.
• Payroll. If payroll stays with a provider, the change is the journal integration and the new chart of accounts mapping. If payroll moves, a mid-year switch brings year-to-date balances and quarterly filings into scope, which needs the provider and your advisor involved early.

Go-live itself is a decision taken on evidence: signed UAT, reconciled data, trained users and a rollback position. The detail is on ERP testing and UAT and ERP go-live support.

Hypercare and remote delivery across US time zones

The weeks after go-live decide whether people trust the new system. During hypercare I run a daily issue review with the partner and your key users, separating true defects from training gaps and from requests that belong in a later phase. Issues are logged with an owner and a target, and a short daily summary goes to the sponsor.

Your first period-end in the new ledger shows whether the build really holds. I work alongside your controller to reconcile bank accounts, inventory, receivables and payables in the new system, confirm that sales tax reports agree with the ledger and check that management reports match what leadership expects. Problems found here feed a stabilization backlog that the partner prices and schedules properly.

All of this is delivered remotely. Calls are booked in the overlap window that fits your main office, whether that is on Eastern or Pacific time, and walkthroughs are recorded so warehouse or field teams in other states can review them later. On-site support around go-live can be agreed by arrangement where it genuinely helps.

Where the platform or partner is still undecided, my ERP selection consultant work for US companies comes first. For a wider view of the market, see the US ERP consultant page or the freelance engagement options.