ERP Implementation Consultant, Lebanon

Where Lebanese ERP implementations go wrong

The failure points in Lebanon are specific enough that they can be listed before a project starts. Most of them come back to currency, cash and continuity.

• Exchange-rate logic configured by assumption. The implementer sets one rate type for everything, and finance spends the first month correcting entries by hand.
• Cash managed outside the system. Outlets and branches keep cash in two currencies, but the ERP only sees a daily total, so differences cannot be traced.
• Opening balances without rates. Open invoices are migrated as converted totals, losing the original currency and making revaluation and customer statements unreliable.
• A single point of failure in the implementer. One consultant understands the configuration, nothing is documented, and every question waits for them.
• Go-live planned as if power and internet were constant. A generator switch or line outage on cutover day stops data loading halfway.

None of these are exotic. They are predictable, which means they can be designed out with clear ownership on your side. The general implementation method is on my ERP implementation page, and if a project has already stalled, fixing a failed ERP implementation is the better starting point.

Keeping the implementer aligned with the currency rule register

The single most useful document on a Lebanese ERP project is the currency rule register: a short, approved list stating the functional and reporting currency of each company, which rate type applies to each kind of transaction, where rates come from, who updates them and how open balances are revalued. If you completed business analysis, it already exists. If not, I write it with your finance team and accountant before configuration goes further.

From then on, every design document from the implementer is checked against the register. I ask them to demonstrate, on your own data, a sale quoted in dollars and paid in pounds, a supplier payment in cash dollars, a payroll journal and a month-end revaluation, and I compare the results with what your accountant expects. Differences go into the issue log with an owner and a date.

The same discipline applies to change requests. A new rate type or a special pricing rule can affect reports across the system, so each request is assessed for its impact on currency logic before your sponsor approves it.

I also make sure the implementer documents every customization and that your company holds its own administrator and hosting credentials. If the lead consultant becomes unavailable, the project should slow down, not stop.

Cash, checks and petty cash in more than one currency

Many Lebanese businesses handle significant volumes of cash, often in both pounds and dollars, across outlets, branches or delivery staff. A system that records only a daily sales total cannot show where a difference arose. I treat cash as a process to design and test, not as a single bank account.

Typical design points include:

• Separate cash desks or journals per currency at each location, with opening and closing counts recorded by the responsible person.
• Transfers between cash boxes, deposits to the bank and cash moved to head office, each with its own document.
• Petty cash per location and currency, with approval limits and receipts attached.
• Post-dated checks received and issued, where your business uses them, tracked until they clear or bounce.
• Customer payments that mix currencies, applied to invoices according to the register.

Each point becomes a UAT script run by the people who actually handle the cash, with your finance team checking the resulting ledger entries. I track defects to closure and do not recommend go-live while a cash control that matters to finance still fails. The ERP testing and UAT page describes the testing method generally.

Opening balances where every figure has a currency and a rate

Lebanese companies usually migrate from a local accounting package, spreadsheets, or both, and the source data often mixes currencies within the same column. Migration therefore starts early, led by someone in finance who knows the history of the accounts, using load templates the implementer and your team both accept, and repeated rehearsal loads.

The rules I insist on:

• Open customer and supplier invoices are loaded one by one, each carrying its source currency and the conversion rate your accountant sets, never as a converted total.
• Bank and cash balances are loaded per account and per currency, matched to statements and counts.
• Stock is counted and valued according to the method finance confirms, with any currency effect documented.
• The trial balance in the new system is agreed with the old one, in each reporting currency, before anyone signs.

Each trial load is reconciled and the differences explained before the next. The switch date falls on a month boundary, letting the old ledger close fully first. Payroll usually stays with your provider; I agree how its journals arrive by company, cost center and currency, and how the cutover month is handled. For method, see ERP data migration; for a template, the migration checklist.

A go-live that survives outages, then hypercare

Go-live in Lebanon needs a resilience plan as well as a cutover plan. Before the date is confirmed, I check with your IT lead and the implementer that servers or routers are on protected power, that backups were taken and restored successfully during testing, and that each site knows what to do if the connection drops. For outlets, that may mean a tested offline point of sale procedure; for offices, a short paper or spreadsheet fallback with a rule for entering the data afterwards.

The go or no-go review then looks at UAT sign-off, reconciled opening balances, trained users, the currency register applied in practice and support arrangements. An unresolved critical item postpones the switch.

Hypercare follows the switch. Issues are logged in one place and reviewed daily with the implementer and key users, prioritized by business impact. Early problems tend to be habits: a cashier using the wrong currency desk, a rate not updated, an invoice printed from an old French template. I stay involved through the first month-end close and the first VAT data extract, then hand over with documented support routines.

All of it runs remotely. Not yet decided on a platform? Read about ERP selection in Lebanon; broader context sits on the Lebanon ERP consultant page and the Lebanon hub, and ERP go-live support describes this stage generally.