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

An ERP implementation can be divided into eight phases, from requirements analysis to hypercare and handover after go-live, and no phase closes without a written deliverable signed off by whoever holds the decision. Its tax integration and record keeping are governed by the Unified Tax Procedures Law issued by Law No. 206 of 2020 (Official Gazette, issue 42 bis (C), 19 October 2020) and its executive regulations (the regulations) issued by Minister of Finance Decree No. 286 of 2021 (Al-Waqa'i al-Misriyya, issue 123 continued (C), 3 June 2021), and electronic receipts by Minister of Finance Decree No. 230 of 2022 (Al-Waqa'i al-Misriyya, issue 116 continued, 25 May 2022).

A business required to issue electronic invoices or receipts sends them to the system of the Egyptian Tax Authority (the ETA) in real time, and in our view go-live should not be decided before the integration with that system is tested on a test environment and then on production. Go-live does not retire the old system, because the law requires records, books and documents to be kept for a period after the tax period.

Phases and governance

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.

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 both sides' project managers. 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.

Analysis, configuration and testing

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. Configuration and a change of procedure come before customisation, because customisation is retested at every upgrade. The working rule is that a gap imposed by law or by a contractual obligation is closed in the system, and one that comes from habit by changing the procedure. No customisation starts before the steering committee has approved its cost.

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, tested on a test environment and then on the ETA's production environment. The main items tested (articles 35 and 36 of the regulations, and article 2 of Decree 230) are:

• Integration between the company's system and the ETA's, with its credentials and cryptographic keys.
• The electronic signature certificate that signs each invoice.
• Coding of goods and services under the unified coding system set by the head of the ETA for invoices and under GS1 or EGS for receipts, and the invoice's fields and basic data.
• Each document's status returned to the system once the ETA has validated it, including an approved invoice's unique number.
• For electronic receipt issuers, direct integration between the ETA's system and the points of sale.

Withholding tax data is tested against what Form 41 requires. The detail is in E-invoicing in Egypt, Egypt's electronic receipt and Withholding tax in Egypt. The acceptance certificate is not signed while a critical defect remains open.

Training, go-live and record retention

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 in-house.

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 not retired, since article 38 of Law 206 provides in its third paragraph (unofficial translation):

"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 taken into account before ending its licence.

Causes of failure

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 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 we recommend

• 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 costed for its effect on budget and timetable, 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 before the go-live decision, and 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, Founder Partner
Chartered Accountant, Ministry of Finance, Egypt

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.