ERP Audit Consultant, Jordan

What an ERP audit is, and what it is not

The word audit causes confusion, so I define it at the start of every engagement. What I offer is a review of how your ERP is set up and used. It asks whether the software supports the way the company trades, whether its data is reliable and whether its controls work as management assumes.

It is not a financial audit. I do not give an opinion on your financial statements, I do not sign anything for the Income and Sales Tax Department, and I do not interpret tax law. Your external auditor and tax advisor keep those roles. In practice, the two kinds of work help each other: findings about access rights, missing approvals or unreconciled interfaces are exactly the kind of evidence an auditor asks about, and it is better to hear them from a reviewer you hired than in a management letter.

A Jordanian business might commission this review in situations such as these:

• A system went live recently and month-end still depends on manual adjustments.
• A new finance director or owner wants to know what they have inherited.
• The implementer says everything is configured correctly, but users disagree.
• A second entity, warehouse or product line is about to be added.

The general method sits on my ERP health check page. This page explains what changes when the system serves a Jordanian business.

Checking the e-invoicing and sales tax setup

Since Jordan introduced its national electronic invoicing system, many ERPs gained a connector quickly, sometimes built by the implementer under deadline pressure. Those connectors often work on ordinary invoices and struggle with the unusual ones. An audit is a good moment to find out which.

I start from your own records. For a sample period, I compare every posted sales invoice, credit note and cancellation in the ERP with what the submission log says happened. The gaps usually fall into a few groups: documents rejected and never corrected, documents corrected outside the system, credit notes not linked to their original invoice and invoices raised by a second entity that bypass the connector entirely. Each gap gets a count in words, an owner and a likely cause.

Tax configuration is reviewed in the same pass. I extract item tax categories, customer tax details, export and exempt treatments and numbering rules into a simple table. I do not judge whether a given treatment is correct; I hand the table to your tax advisor, who can confirm or correct it far faster than by browsing the system screen by screen. Their comments then become findings with clear fixes.

If the connector itself looks fragile, for example maintained by one developer with no documentation, that goes in the report as a continuity risk.

Stock, batch and expiry data in pharma and FMCG

Pharmaceutical suppliers, medical distributors and consumer goods traders in Jordan rely on batch and expiry information for more than accounting. Quality staff use it to release stock, sales teams promise short-dated goods to particular customers and a recall depends on tracing every lot. When that data drifts, the ERP stops being trusted and parallel lists appear.

The audit tests the data rather than the settings alone. Typical checks include:

• A small physical count of selected lots, compared with quantities and expiry dates in the system.
• A search for stock with past expiry dates that is still available to pick or sell.
• Whether picking rules actually choose the earliest expiry, or whether staff override them routinely.
• A mock recall: tracing one batch from receipt to every customer who received it.
• Quarantine and release steps, and who is allowed to move stock out of quarantine.

Where the system cannot answer a question your quality team needs answered, I note whether the cause is configuration, data entry habits or a genuine product limit. The pharmaceutical ERP page describes the target process this comparison is made against.

Access rights, approvals and the spreadsheets beside the system

Controls drift after go-live. A sales coordinator is given credit approval to cover a holiday and keeps it. An implementer's administrator account stays active. Two people share one login because licenses ran short. None of these is dramatic alone, but together they weaken the controls your management and external auditor assume are there.

I extract user lists, roles and approval limits and set them against a simple matrix of who should raise, approve and pay for each process: purchasing, supplier creation, bank detail changes, credit notes, price changes and manual journals. Conflicts are listed by name so they can be fixed, not described in general terms. Dormant accounts and shared logins are listed the same way.

Spreadsheets get the same attention. I ask each team which files they keep beside the ERP and why. An expiry list in the warehouse, a dollar receivables sheet in finance and a commission file in sales each point to a requirement the system does not meet, or to a feature nobody was trained on. Some of these can be retired quickly; others need configuration or a report. Approval design is covered in more depth on the approval workflows page.

The findings report and what happens after

The audit ends with a written report, prepared in English and designed so that management can act on it without reading every detail. Each finding states what was observed, the evidence, the business impact, the probable cause and a recommended fix. Findings are ranked by impact and urgency, so an e-invoicing gap that stops sales comes above a cosmetic report issue.

The report also includes a license and usage view: modules you pay for and do not use, users who rarely log in and features that could replace a spreadsheet. Arabic printouts are reviewed for layout and data problems, while the wording itself is checked by your bilingual staff.

Findings are phrased neutrally. Many problems trace back to requirements that were never written down rather than to poor work, and your implementer can usually fix most items once they are clearly described. Results are walked through in a remote readout, and you keep an action list you can run internally, with your implementer or with my help through ERP optimization.

If the review shows the project never really stabilized, the ERP rescue consultant page for Jordan covers the next step. Earlier stages are described on the Jordan ERP consultant page and the Jordan overview.