Contact Info
Jordan
How do you rescue a failing ERP project in Jordan?
Start by stabilizing what customers and the tax department see, then establish the facts. For a Jordanian company that usually means clearing the backlog of unsubmitted e-invoices, keeping the sales tax period on track with your accountant and fixing batch or balance data that blocks daily work. Only then do I set out options to continue, re-scope or change course, working remotely with you and your implementer.
Last reviewed by Vikas Saroj
ERP trouble in Jordan rarely announces itself in one day. A go-live date slips once, then again. The e-invoicing connector works in testing but rejects real invoices. Batches migrate without expiry dates, the consultant who understood your design moves to another client, and management starts asking whether to keep paying.
I step in as an independent ERP rescue consultant on the client side. My first job is to protect daily operations, the second is to establish what is actually true about the project, and the third is to help you decide, on evidence, what to do next and with whom.
The work is remote and runs in English. Your accountant, tax advisor and lawyer keep their own roles, and Arabic material stays with your bilingual staff or the implementer.
What I Do
The order matters: keep the business running, learn the facts, then decide.
In the first days I list what blocks sales, purchasing, stock movements and collections, separate it from irritations and agree a short list of fixes with your implementer.
Unsent and rejected invoices are grouped by cause, an owner is named for each group and a daily routine is agreed so the queue is cleared and stays clear.
From the contract, scope, change log, test results and the system itself I build one written view of what was agreed, what was delivered and what is still open.
Wrong opening balances, lots without expiry dates and dollar items converted at a single rate are traced, corrected through controlled entries and reconciled with finance.
A phased plan with named owners, decision rights, a risk log and short written status notes, so management sees progress and problems early.
I assess whether the current implementer can finish, outline what a handover would involve and list contract questions for your lawyer, without taking sides in a dispute.
How I Work
Protect invoicing and the close
List blocking issues
Clear the e-invoice queue
Agree interim workarounds
Brief the accountant
Establish what is really true
Separate interviews per party
Review contract and changes
Test key flows in the system
Write the options paper
Run the agreed path
Reset scope and acceptance
Weekly risk review
Retest before each release
Close hypercare formally
Projects in Jordan get into trouble for the same broad reasons as elsewhere: thin requirements, a fixed date, too few people on the client side. A few local patterns make the situation more acute.
None of these means the platform was a mistake, and none is purely one party's fault. A rescue starts by naming which patterns apply to your project, with evidence. Where the software already runs reliably and merely disappoints, my ERP audit work for Jordan is the lighter starting point.
When an ERP is half-working, the risks that hurt fastest are the ones customers and the tax department see. Before any discussion of root causes, I agree with you which daily operations must keep running and what temporary arrangements are acceptable while the system is repaired.
For most Jordanian companies the first priority is the e-invoicing queue. I group outstanding documents by reason: missing customer data, wrong item tax category, credit notes without an original reference, connector errors. Each group gets an owner, either your finance team or the implementer, and a target for clearing it. A named person then checks the queue every day until the backlog is gone and new failures are rare.
The second priority is the sales tax period. I sit down remotely with your accountant to agree what figures the return will be prepared from, which corrections must be posted first and what reconciliation will prove that the ERP, the submission log and the return agree. How each line is taxed is for your accountant or advisor to decide; I make certain the system data can back up whatever they conclude.
Month-end follows the same logic: a short close checklist, agreed adjustments and a list of reports finance can trust for now.
By the time a rescue starts, everyone has a story. The implementer says requirements kept changing; your managers say the system never worked as demonstrated. Both may be partly right. Decisions need a factual base, so I build one.
I interview your sponsor, process owners, key users and the implementer's team separately, so each can speak openly. I read the proposal, statement of work, requirements, design papers, change requests, test results and the issue log. Then I check the system: which processes run end to end, which need workarounds and what remains unconfigured.
The output is a short written status with four parts:
The tone is deliberately neutral. A rescue usually needs the implementer's cooperation at least for a while, and a report that reads as an accusation makes that harder. Background on the method sits on my ERP recovery page and the independent second opinion page.
With the facts on paper, management can choose among realistic options instead of reacting to the latest crisis. Each one comes with its trade-offs and the factors that drive its cost, described in words.
Before you act on a change of implementer or a dispute over scope, your own lawyer should review the contract. I prepare a list of the clauses and facts that matter, such as acceptance criteria, payment milestones, ownership of custom code and exit assistance, but I do not give legal advice. Where a new implementer is needed, the ERP selection process for Jordan applies on a smaller scale.
A recovery plan only helps if it changes how the project runs each week. I set up the governance that is often missing the first time: a sponsor who can make decisions quickly, named owners for finance, sales, warehouse and purchasing, one integrated plan and a risk log reviewed weekly with the implementer.
Fixes are released in small batches. Each one is retested by your own staff on real scenarios before it reaches the live system, for example a credit note sent to the e-invoicing system, a dollar receipt against an old invoice or a pick that must choose the earliest expiry. Release notes say what changed, so users are not surprised.
Where data needs repair, corrections go through controlled journal entries or stock adjustments approved by finance, with a reconciliation before and after. Nothing is edited directly in the database without a record.
The rescue ends when agreed exit criteria are met: the e-invoicing queue is clear, a month has closed without major manual adjustments, critical issues are resolved and support has moved to a normal footing. My go-live support method applies here. For the wider picture, see the ERP implementation consultant page for Jordan and the Jordan 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
With the queue itself. I group rejected and unsent documents by cause, such as missing customer data, item tax categories or credit notes without a reference, then agree owners and a daily routine to clear them. Your tax advisor confirms any treatment questions. Root cause analysis of the wider project follows once invoicing is under control.
Not necessarily. Many rescues succeed with the same firm once scope, responsibilities and governance are reset. If the evidence shows they cannot finish, I outline what a controlled handover needs, such as code, documentation and credentials, and your lawyer reviews the contract position before anything is decided.
I do not prepare returns or advise on tax. I work with your accountant to agree which data the return will use, which corrections must be posted first and how the ERP, the submission log and the return will be reconciled. That gives them reliable figures to work from.
Occasionally. If the evidence shows the software cannot support core requirements such as e-invoicing, batch control or currency handling in a workable way, re-platforming may be the better choice. I set it out beside the other options with its trade-offs, and protect requirements and cleaned data so that work is not lost.
Yes. Triage, interviews, system checks, steering meetings and retesting all run remotely, with written decisions after each session. Jordan and India share enough working hours for daily calls during the stabilization period, and recorded walkthroughs help staff who miss a session. Any visit would be by arrangement only.
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.
