Contact Info
Requirements Specification
What makes an ERP requirements specification work for a Lebanese business?
Precision about money. The specification must state, line by line, which currency each transaction is recorded in, which rate source applies, which currency each report and tax return uses, and how revaluation is posted. Add VAT lines your advisor has confirmed, Arabic, French and English printouts, tolerance for power and connectivity loss, and priorities with traceability into demos and tests. I write and maintain it remotely.
Last reviewed by Vikas Saroj
Many ERP specifications contain a line such as "multi-currency support required". In Lebanon that line is close to meaningless. Almost any system can hold two currencies; the real questions are which rate applies to which transaction, who sets it, and what each report shows.
I write ERP requirements specifications for Lebanese companies in which those answers are explicit and testable. The business decisions on rates belong to your finance team and advisor, as covered in the Lebanon ERP business analysis. My job is to express them as lines a vendor must meet and a tester can check.
Everything happens remotely: video reviews plus a requirements register your team edits alongside me. The document then becomes the reference for tenders, the implementation contract and acceptance testing.
What I Do
These services produce or protect the requirements document. Process discovery and rate policy decisions sit with your team and the business analysis work.
Transaction currency, rate source by document type, rate stamped on each record, reporting currencies, revaluation and rounding, written as separate lines that a demo can prove or disprove.
VAT calculation, invoice content, the currency a return must use and how long records are kept, drafted with your advisor and tagged with who confirmed each statement.
Each printed or emailed output named, with its language, the fields it shows and the currency amounts it prints, so a bidder cannot answer with a generic Arabic support claim.
What users must still be able to do during a power cut or internet loss, how data syncs afterward, backup and restore expectations, and the hosting questions every bidder answers in writing.
Feeds to and from sister companies abroad, consolidation inputs, bank statement handling, payroll imports and point-of-sale or e-commerce links, each with an owner and a definition of done.
An RFP annex with fixed response codes, a traceability register into demos and tests, and a signed, versioned baseline your implementation contract can name as its scope reference.
How I Work
Write decisions as requirement lines
Agree document sections
Translate currency rules into lines
Draft tax and print lines
Set priorities with owners
Close the gaps bidders exploit
Split compound or vague lines
Add resilience and hosting questions
Link lines to demo scripts
Prepare the tender annex
Sign, freeze and track changes
Run section sign-off reviews
Issue the baseline version
Maintain the change log
Pass identifiers to testers
Once your finance team and advisor have agreed the currency rules, often during the Lebanon ERP business analysis, the specification has to carry them without ambiguity. I break them into single, testable lines rather than one paragraph about multi-currency.
Lines like these let two bidders be compared fairly. A vendor that needs custom development to stamp a rate on every document will have to say so in the response, instead of discovering it during the build. The same lines later become test cases.
Tax lines are drafted with your advisor and marked as confirmed before any vendor sees them. I keep them in one section so the review is quick. Typical lines cover how VAT is calculated per line, which documents must show it, how credit notes reverse it, which currency the return data must be presented in and how long transaction records and attachments must remain retrievable.
Printouts get their own list rather than a single language line. For each document, such as the tax invoice, delivery note, customer statement, payment voucher and payslip summary, the specification states:
Payroll usually sits with a provider or a separate package, so the specification describes the interface: what results come into the ERP, how they post, and which files for the social security fund are produced and by whom. The calculation rules stay outside the document.
The engagement runs in English; sample wording in Arabic and French comes from bilingual employees or a local partner, who also signs it off.
In a Lebanese specification, non-functional requirements are not boilerplate. They decide whether the system is usable on a difficult day. I write them as conditions vendors must answer, not as assumptions.
Outages. Which tasks must continue during a power or internet loss: point-of-sale sales, warehouse receipts, cash collection? How are transactions captured offline and synced, and how are conflicts resolved? What does a user see when the connection returns?
Hosting. Where production data and backups are kept, which vendor staff can access them, how quickly a restore can be done and how a full export of records and attachments works. Whether hosting is local, regional or with a cloud provider is a decision the specification informs rather than presumes.
Data protection. How personal data of staff and customers is handled, framed so your advisor can relate it to Lebanon's electronic transactions and personal data rules.
Access and audit. Roles that separate rate entry, document approval and posting; an audit trail on rate changes, price changes and voided documents.
Availability. Described by business moment, such as a trading day at a busy outlet or the month-end close, rather than by numbers a bidder can satisfy on paper.
Many Lebanese businesses have sister companies in the Gulf, Africa or Europe, and the specification must say what flows between them. Integration lines name the source, the destination, the frequency, the owner and how failures are reported: group consolidation inputs, intercompany invoices, bank statements, payroll results, and sales feeds from outlets or an online store.
Migration lines state what moves and how it is valued. Open customer and supplier balances need their original currency and rate, not only a converted figure. Uncleared checks need their due dates. Inventory needs quantities and the cost basis your accountant accepts. Without these lines, a bidder may quote a migration of master data only.
Every requirement then gets a priority from its owner: Must before go-live, Should, Could, or Won't for now. For Lebanese operations there is a strong case for keeping currency and resilience lines in the Must group and being stricter elsewhere, because those two areas decide whether people abandon the system for spreadsheets. The Won't list is written down too, so bidders know what is out.
Delivery of these lines is covered on the ERP integration and ERP data migration pages.
Requirement identifiers are the thread: the same reference is quoted in demo scripts, in the fit-gap matrix and in UAT cases. A single register shows where every line stands, so a currency requirement cannot be quietly dropped in the build. The ERP gap analysis page explains the fit-gap step.
For a tender, bidders answer each line with a fixed code: available as standard, achieved by setup, needing development, met by an add-on, or unavailable. Free text is welcome as explanation but never replaces the code. Those answers feed the Lebanon ERP selection. Once a partner is chosen, the signed baseline is named in the contract and every later change is logged with its reason and approver.
Gaps that put Lebanese specifications at risk, whoever drafts them:
No vendor pays me a commission or referral fee, and the whole engagement is remote. For a wider view see the Lebanon ERP consultant page and the Lebanon overview.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
FAQ
No. That is a business and accounting decision for your finance team and advisor. My role is to write the agreed rules as requirement lines that a system must meet: rate source by document, rate stamped on records, reporting currency and revaluation. That makes the decision visible and testable in every vendor demo.
The business analysis discovers how your company works today and helps agree the currency rules, VAT scenarios and group structure. This service turns that understanding into the specification document: individually testable lines, priorities, non-functional conditions, a tender annex, traceability and a signed baseline. The two fit together, analysis first.
For outlets, warehouses and collection points, often yes, because a system that stops during an outage invites paper workarounds that never get entered. The owner of each process decides the priority, and the specification states exactly which tasks must continue, how data syncs afterward and how conflicts are handled.
Yes, if they are in scope. Each entity gets its own scope statement and statutory lines confirmed by its own advisor, while shared processes are written once. Intercompany and consolidation requirements are stated explicitly so a bidder cannot assume a simpler group structure than you have.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Insights
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.
