ERP Rescue Consultant, Egypt

Signs an Egyptian ERP project needs rescuing

A project does not need to be declared a failure to need help. In Egypt, the warning signs tend to be concrete and visible to management:

• Launch has been postponed repeatedly, and the remaining work list keeps growing instead of shrinking.
• E-invoices or e-receipts are rejected every day, and only one or two people can resolve them.
• Product costs or project margins in the new system are obviously wrong, so finance prepares its own figures.
• Plants, warehouses or branches have returned to paper or spreadsheets for daily work.
• The implementer's original consultants have left the project, and new faces are relearning the design.
• Invoices from the implementer are disputed, and the relationship is drifting toward formal letters.

Any one of these can be fixed. Several together usually mean the project needs a reset, not more effort along the same lines. The general shape of that reset appears on my ERP recovery page and on the fixing a failed ERP implementation page.

If the system is basically stable but underused, a lighter review is the better start; see the ERP audit consultant page for Egypt.

Keeping invoicing and tax filings moving during the rescue

While the project is being repaired, the company still has to invoice customers, issue receipts and meet its VAT obligations. Those come first.

I start with the document backlog. Every unsent or rejected e-invoice and e-receipt is grouped by cause: items without the code the authority expects, customer details missing, credit notes without a reference to the original, signing failures or connector errors. Some groups are fixed by your finance team through data corrections, others by the implementer through configuration or code. Each has an owner and a target, and someone checks the queue every working day.

Then I meet your accountant remotely to agree how the coming VAT period will be supported. We settle the source of the figures, the order in which pending corrections are entered, and the tie-out that proves the ledger, the authority's records and the filed return tell the same story. Tax treatment and the filing itself remain their responsibility; what I add is a ledger whose numbers hold up when they check them.

Where the system cannot yet support a process, I agree a documented interim routine, such as a controlled spreadsheet for a single plant, with a named owner and a date to retire it. Undocumented workarounds are how rescues become permanent.

Getting the facts straight with the implementer

Implementers in Egypt vary in size and depth, and a troubled project may simply involve a capable firm that was stretched thin rather than one acting in bad faith. A rescue needs a factual base that both sides can recognize.

I interview your sponsor, finance, production, warehouse and sales leads, then the implementer's project manager and consultants, each separately. The paper trail comes next: the original offer, the agreed scope, design notes, change approvals and testing evidence. After that I work in the system itself, running core flows from purchase to production to sale and invoice.

Continuity gets particular attention. I ask who on the implementer's side understands each customization and connector, whether that knowledge is documented and whether the code is held somewhere your company can access. A project that depends on one developer who has already moved on is a risk regardless of anything else.

The resulting status paper separates agreed scope, delivered and working items, partly working items, missing items and disputed items. Causes are described as requirements, data, configuration, governance or platform issues, not as personal failings. That tone matters, because most recoveries need the implementer's cooperation, at least through stabilization. The independent ERP second opinion page explains this assessment in general terms.

Repairing costing, item codes and opening data

Data problems sit behind many Egyptian rescues. Common ones include items created twice under slightly different names, products never mapped to the tax authority's coding, bills of materials that do not match what the factory consumes, opening stock loaded without its true landed cost and supplier balances converted at a single exchange rate.

Repairs follow a few strict rules:

• Every correction is approved by a named owner in finance or operations before it is posted.
• Changes go through journals, stock adjustments or controlled imports, not direct database edits.
• Balances are reconciled before and after each round of corrections, with the evidence kept for your auditor.
• Duplicate items are merged or blocked only after open documents referencing them are dealt with.

For manufacturers, I work with the cost accountant on a small set of representative products first. Once their costs look right from purchase through production to sale, the same corrections are applied more widely. That builds confidence step by step, instead of promising that everything will be fixed at once. Costing policy remains a decision for your accountant and auditor. The ERP data migration service covers the underlying methods.

Choosing the path forward, then running it

With the facts established and operations steadier, management chooses a path. I lay out each realistic option with its trade-offs and cost drivers:

• Continue with the same implementer, a reset scope and stronger governance.
• Re-scope so that accounting, selling, buying and inventory go live first, while production planning or project modules wait for a second wave.
• Change implementer on the same platform, which needs documentation, source code, credentials and data handed over cleanly.
• Re-platform, only where evidence shows the software cannot meet core needs, protecting requirements and cleaned data.

Before any contract dispute or change of implementer, your lawyer should review the agreement. I prepare a summary of relevant facts and clauses, for instance what counts as acceptance, when payments fall due, who owns bespoke development and what help the implementer owes on exit, but I do not give legal advice.

From there, an accountable sponsor and process owners drive the plan, risks are reviewed weekly and fixes ship in small batches your staff retest. The rescue closes when agreed criteria are met: the document queue is clear, a month closes without major manual adjustments and costs are accepted by finance. My go-live support approach applies at this stage, and the Egypt implementation consultant page and Egypt overview cover the wider context.