ERP Requirements Consultant, Egypt

How an Egyptian specification is organized

A specification that implementers can price consistently needs a predictable shape. I agree the outline with your sponsor before any lines are written, so finance, operations and IT all contribute to the same document.

• Scope: each legal entity, including any in a free zone or special economic zone with different treatment, plus plants, warehouses, sites and branches, and what is deferred.
• Functional lines: sales and collections, installment contracts where relevant, purchasing and imports, inventory, production or project costing, and finance and the close.
• Statutory lines: grouped so your advisor can review them together.
• Non-functional lines: hosting, signing, access, audit and availability.
• Integrations, data migration and reports.
• Glossary: the Arabic and English names for documents and statuses, so bidders and staff mean the same thing.

Each line carries an identifier, an owner, a reason and acceptance wording. One requirement per line is a firm rule; sentences joined with "and" are where proposals meet half a requirement and claim all of it. If processes are still unmapped, the Egypt ERP business analysis comes first. The wider document structure is described on the ERP BRD consulting page.

E-invoice, e-receipt and check lines a tester can run

The tax authority section is where vague wording costs most. I draft it from your advisor's guidance, mark each line confirmed, and keep the interpretation of the rules with them. Example lines:

• Each business-to-business invoice, credit note and debit note within scope is signed and submitted to the Egyptian Tax Authority, and its submission identifier and status are stored on the document.
• Retail sales within scope are issued as e-receipts from the point of sale, using the method your advisor and implementer confirm.
• Every item carries the code your advisor specifies, and an invoice cannot be submitted with an uncoded item.
• A rejected document is routed to a named role with the reason, can be corrected and resubmitted, and its history is kept.
• VAT and any withholding on purchases are calculated using the treatments your advisor lists.

Installment sales and post-dated checks get equally precise lines:

• A contract generates its payment schedule, and each check is linked to its installment with due date and bank.
• A check moves through the statuses your finance team uses and affects the bank balance only when cleared.
• A returned or rescheduled check updates the schedule and the customer balance without manual journals.

Each line is something a vendor can demonstrate and a tester can later mark as met or not.

Non-functional conditions bidders must answer

Non-functional lines risk being reduced to "secure and scalable" in a specification. I write them as conditions that each bidder answers in writing, which is far harder to gloss over.

Signing and submission. Who holds the signing credentials, where the signing happens, what occurs if the credential or the connection is unavailable, and whether documents queue for later submission without blocking dispatch.

Hosting and data. The data center or cloud region holding live records and backup copies, vendor personnel with access, evidence of restore drills, and the format in which a full extract of records and attachments would be handed over. Personal data handling is framed for your advisor to relate to Egypt's data protection law.

Access and audit. Roles separating price setting, discount approval, invoicing and posting; an audit trail on item codes, prices, credit limits and check statuses.

Performance and availability. Tied to real pressure points, for instance branches invoicing together on the last trading days or a production shift posting consumption, not to abstract figures.

Language. Which screens and printouts must work in Arabic, listed by document. The engagement runs in English; Arabic sample wording is prepared or reviewed by bilingual staff or a local partner.

The answers become evidence in the Egypt ERP selection scoring.

Integrations, migration and priority setting

Every interface gets a line naming where data comes from and goes to, how often it runs, who owns it and how errors surface. For Egyptian companies these often include the tax authority connection itself, point-of-sale systems issuing e-receipts, bank statements, payroll results from a provider or payroll package, and reporting feeds to a foreign parent.

Migration lines specify what moves and how: open customer and supplier balances, installment contracts with remaining schedules, uncleared checks with due dates, item master data with codes already assigned, stock by location and the cost basis your accountant accepts. A migration scope that covers only master data is a gap bidders rarely point out on their own.

Owners sort their lines into Must have at go-live, Should, Could and Won't for this phase. Tax authority lines that apply to you will normally sit in Must, but I still push owners to keep the Must group short elsewhere, because a long one hides the requirements that truly decide fit. The Won't list is recorded so nothing is later claimed as implied.

Delivery of these lines is described on the ERP integration and ERP data migration pages.

From tender to contract, and gaps to check

For a tender, the annex asks every bidder to classify each line as met in the standard product, met through setup, needing development, needing a separate product, or not met. Explanations are welcome but cannot replace the code. If you already hold proposals, I can send the annex to those implementers and normalize their answers before scoring. The ERP RFP consulting page sets out the wider tender process.

Identifiers then carry forward into demo scripts, the fit-gap matrix and UAT cases, so every line has a visible fate. Once process owners and the sponsor have reviewed their sections, the document is frozen as a signed baseline. Your contract cites that version, and anything altered afterward is logged with its reason and the person who approved it.

Gaps that weaken Egyptian specifications, whoever writes them:

• E-invoicing covered, but e-receipts for retail outlets forgotten.
• No owner named for signing credentials.
• Item coding treated as a go-live task rather than a requirement.
• Installment checks handled as ordinary receipts.
• No data export requirement for a future change of provider.

The engagement is remote and free of vendor commissions. Wider context sits on the Egypt ERP consultant page and the Egypt overview.