ERP implementation in Egypt: the phases from requirements to go-live

Executive summary

• An ERP implementation can be divided into eight phases, from requirements analysis to hypercare and handover. No phase closes without a written deliverable signed off by whoever holds the decision.
• The signed-off design document is the scope baseline. Anything added later is a change request, costed for its effect on budget and timetable and approved by the steering committee.
• A gap between the system and the way the business works is closed by configuration or a change of procedure before any customisation, because every customisation is retested at every upgrade.
• No go-live decision is taken before the integration with the electronic invoice and receipt systems is tested, each as it applies to the business, on the test environment provided by the Egyptian Tax Authority (the ETA) and then on production.
• Go-live does not retire the old system, because article 38 of Unified Tax Procedures Law No. 206 of 2020 requires records, books and documents to be kept for five years following the tax period for which the return is filed.

The phases and what closes each one

These phases begin once the system has been chosen and the implementer engaged, whatever the system. Two phases may overlap in execution, but no phase is signed off before the one preceding it.

Discovery and solution design

Discovery works from the documents actually in use, not from descriptions of procedures: the invoice, the purchase order, the stores issue note and the monthly reports. It also lists the reports management needs and the tax returns, because these decide the design of the chart of accounts and the analytic dimensions; adding them after go-live means redesigning.

In the fit-gap analysis every requirement is classified: met by the system as it stands, by configuration, by a change of procedure, or by customisation. The working rule is that a gap imposed by law or by a contractual obligation is closed in the system, and a gap that comes from habit is closed by changing the procedure. No customisation starts before the steering committee has approved its cost.

From configuration to user acceptance

Configuration is done on a test environment, not on production, and every setting is logged with its reason; the log is the reference for support and audit later. Each process is walked through with the key users on the company's own data.

In data migration, master data is cleaned before it is migrated, not after: customers, suppliers, items and fixed assets. Migrated opening balances are reconciled to the old system's trial balance and to its subsidiary detail: receivables and payables by party, inventory by item, fixed assets by asset.

User acceptance testing is run by the users, not the implementer, on complete processes through to the accounting entry and on the month-end close, with the exceptions: returns, credit notes, partial deliveries and foreign currency.

It includes the tax integration: the ETA provides a separate test environment (PreProd), with a registration portal, an invoicing portal and APIs apart from production. The following are tested there and then on production:

• Registration of the system on the company's digital profile, and the API access credentials.
• The e-signature or e-seal certificate that signs the documents.
• Item codes under GS1 or EGS, and the mapping of units of measure and tax types to the ETA's code tables.
• The return of each document's status to the system once the ETA has validated it.
• For issuers of electronic receipts, registration of the POS devices and their link to the company's tax registration number.

The rules on who must issue electronic invoices and receipts are set out in the e-invoicing guide, and withholding tax data is tested against what Form 41 requires. The acceptance certificate is not signed while a critical defect remains open.

Training, go-live and after

Training is built around roles, not modules: the storekeeper learns receipts, issues and counts; the accountant learns posting, reconciliation and the close. It is given on the test environment with the company's data, close to go-live, and the key users train their colleagues so that knowledge of the system stays inside the business.

Go-live is set at the start of an accounting period, so that no period is split between two systems. The cut-over plan is a checklist with dates and owners: posting stopped on the old system, a physical stock count, closing balances migrated and reconciled. The steering committee takes the go-live decision against criteria written in advance: acceptance certificate signed, tax integration tested on production, users trained, balances reconciled. If any one is missing, go-live is postponed.

Hypercare is defined by exit criteria, not by a number of weeks: the first month-end close completed on the new system, the first tax returns prepared from it, and no critical issue open. The system is then handed over with its documentation: the configuration log, the procedure manuals, and the list of users and their access rights.

The old system is closed to posting but not retired. Article 38 of Law No. 206 of 2020 provides, in its third paragraph:

"In all cases, the taxpayer or the person liable shall keep the records, books and documents, including copies of invoices, for five years following the tax period for which the return is filed."

The old system, or a readable archive of it, therefore stays available for at least that period, and this is provided for before its licence is ended.

Project governance

The sponsor is a member of senior management who controls the budget and settles disagreements between departments, and chairs the steering committee of the heads of the departments concerned and the project managers of both sides. The committee meets on fixed dates and at the end of every phase, and approves the design, change requests and the go-live decision.

The key users, at least one for each process, know the current work, can decide within their area, and are released for a defined share of their time to write and run the test scenarios.

The implementer's project manager is responsible for the plan, resources, the risk log and regular reporting, and has a counterpart on the company's side. The implementer proposes and the company decides on procedures and scope.

Where implementations go wrong

Causes that recur in practice:

• Scope drift. Requirements added after the design is signed off, without a change request; each is small, together they consume the timetable.
• Absent key users. Named on paper but never released, so the implementer designs on assumptions and tests alone, and the gaps surface after go-live.
• Customisation instead of process change. The old system or the spreadsheets are reproduced in the new system as they were, raising the cost and weighing on every later upgrade.
• Dirty data. Duplicate or uncoded customers and items, and unreconciled balances, migrated as they stand, distort the reports from the first day.
• Going live before the tax integration is tested. The first invoices are rejected by the ETA's system or never sent, and invoices may be issued outside the system to keep selling, opening a difference between the books and the ETA's system.

What this requires

• Appoint a sponsor and a key user for each process before starting, and release a defined share of their time.
• Write each phase's deliverables into the implementation contract, and tie payments to their acceptance.
• Adopt the signed-off design as the scope baseline, put every addition through a written change request, and confine customisation to what the law or a contractual obligation requires.
• Clean master data before migration, and have the finance manager sign the reconciliation of migrated balances.
• Test the integration with the electronic invoice and receipt systems on the test environment and then on production before the go-live decision.
• Keep the old system, or a readable archive of it, available for the retention period the law requires.

The firm's ERP Consulting Department prepares the requirements document, oversees the implementer on the company's behalf, reviews each phase's deliverables before they are signed off, and tests the accounting and tax configuration and the integration with the ETA's systems before go-live.

Mahmoud Nassef — Chartered Accountant (Egyptian Register), Founder Partner

Member, Egyptian Society of Accountants & Auditors
Member, Egyptian Tax Society
Member, Egyptian Society for Public Finance and Taxation

Partner profile · Book a consultation

Disclaimer: This bulletin is prepared for general information on the legislation in force at the date of its publication. It does not constitute a professional opinion or tax or legal advice on any particular matter, and it should not be relied upon in place of advice based on an examination of the circumstances of each case. Nassef & Partners International accepts no responsibility for any action taken, or refrained from, in reliance on its contents. The positions stated remain subject to subsequent legislation and decisions.