ERP Rescue Consultant, Italy

Stalled before go-live or struggling after it

The starting point depends on where the project is. If it has not gone live, the main risk is spending more money on a plan nobody believes. I pause new change requests, read the contract and the partner's offer against the analysis documents, and look at what has really been configured and tested. The question is simple: what stands between the company and a safe go-live, and is it a matter of weeks of focused work or a deeper problem?

If the system is already live and causing pain, the order changes. Invoices, collections and supplier payments come first, because customers, banks and the tax agency do not wait for an analysis. I spend the first days with the head of administration, sales support and the partner's lead consultant agreeing which problems block cash and compliance and which are irritating but survivable.

In both cases I build a written account of what happened: requirements that were thin or changed, decisions the company took late, assumptions in the offer that did not hold, data that turned out worse than expected. It is shared with owners and partner alike. The general method behind this work is on my ERP recovery page, and the failed implementation page describes the symptoms from the business side.

Clearing the e-invoice backlog without breaking numbering

After a difficult go-live, the electronic invoice channel is often where pressure builds fastest. Typical items in the backlog are invoices rejected by the exchange system because of missing or malformed data, invoices that were never transmitted because the connector stalled, invoices accepted but not delivered to the customer directly, and supplier files waiting in the intermediary's portal without being registered.

I treat the backlog as a list, not a fire. Each item gets a cause, a customer or supplier, an amount and a status. Then the work goes in a fixed order:

1. Fix the cause in the system or the master data, so new invoices stop failing.
2. Agree with your commercialista how each group of rejected invoices should be handled, whether corrected and resent or treated another way, so numbering and dates stay defensible.
3. Resend in batches, starting with the customers and amounts that matter most for cash.
4. Register the waiting supplier files and match them to orders and receipts.
5. Name one person who watches notifications every day until the channel is quiet.

Preservation gets a separate check once the flow is stable: any invoices or receipts missing from the archive during the troubled weeks are listed and handed to the provider and your commercialista to complete. I do not decide how tax rules apply; I make sure the decisions are taken and carried out in the system.

Collections, supplier payments and the VAT settlement

Cash is what makes a troubled ERP an emergency. In many Italian companies a large share of customer receipts depends on bank receipt collections, so if the new system fails to present them, money simply stops arriving. I check that due collections are generated and sent, that the bank's outcome is recorded and that unpaid returns come back as open items with their charges. If the flow cannot be fixed quickly, we agree a temporary manual route with an owner and an end date.

On the payables side, suppliers chase when their invoices are not registered. Once the backlog of incoming files is cleared, a payment proposal can be produced from the system again instead of from a spreadsheet.

The VAT settlement needs its own plan. I prepare, with your administration team, a clear picture for the commercialista: which registers are complete for each period, which documents are missing or duplicated, and which corrections have been made in the ledger. They decide how to settle and report; I make sure the evidence is organized and that corrections are traceable. Payroll postings from the labor consultant are reconciled in the same pass, so the first clean month-end includes every cost.

Fixes are made at the source, in master data or configuration, rather than by editing posted documents, so the same error does not reappear the following month.

Facts, the partner and the contract

Italian ERP projects often depend on a long relationship with a software house or partner, and a rescue should not destroy it without reason. In most troubled projects both sides contributed: the company gave late or partial answers, key people were busy running the business, and the partner accepted changes without resetting the plan.

So the reset is structured. Every open item is classified as essential for operations, deferrable, no longer needed or disputed. Disputed items are settled against what the offer, the analysis document and the signed decisions actually say. The outcome is a revised plan with named people on both sides and acceptance criteria per item.

Where the evidence shows the partner cannot complete the work, I help organize a handover: configuration documentation, custom code and its ownership, connector and intermediary contracts, administrator access, open defects and test material, collected before a new firm takes over.

Contract questions, such as acceptance, withheld payments, termination and rights to custom developments, belong to your lawyer. Contracts are frequently in Italian, so they review the legal text while I provide a neutral timeline and a comparison between agreed scope and delivered scope. I do not give legal advice. If a new partner is needed, the requirements are reused from the rescue work, as described on my Italian ERP selection page.

Choosing the way forward and rebuilding confidence

Once operations are steady and the facts are written down, the owners need to choose. I set out the realistic options in a short paper:

• Continue with the same partner, once the plan is rebuilt, if the software suits the company and the trouble came from scope, data or slow decisions.
• Reduce the scope to administration, sales and stock, leaving production planning or the web shop for a later phase.
• Change partner while keeping the platform, when the software fits but delivery has broken down.
• Change platform, when even a well-run project could not support how the company works, for example complex outside processing or variants.

Each option lists what can be reused, such as cleaned customer data, process maps and test scripts, and the main cost drivers, without invented figures. Changing platform is rarely the first answer, but I say so clearly when the evidence points there.

Confidence returns through visible progress: a weekly checkpoint with the owners, one log of decisions and risks, and fresh testing before any new go-live, as covered under ERP go-live support. I work remotely in the Italian morning. Once things are stable, an ERP audit in Italy confirms what remains. For projects that are not yet in trouble, see my implementation oversight, and the Italy hub for everything else.