ERP Business Analyst in Jordan

Making sales tax and e-invoicing part of the requirements

Jordan applies a general sales tax, while the Income and Sales Tax Department operates the country's electronic invoicing platform. For a business analyst, both translate into data questions long before they become configuration tasks. Which customers and items carry which tax treatment? Which fields does an electronic invoice need, and where do they come from? What happens when a submission is refused?

I build an invoice scenario catalog with the finance team. Each row describes one real situation the company faces, for example a sale to a local distributor, a service delivered to a client abroad, a partial credit note or an invoice raised by a second legal entity. Your tax advisor confirms how each scenario is treated, and only then is it written up as a requirement, given an owner and paired with a test.

Master data gets the same attention. Customer tax numbers, item tax categories and document numbering rules are written as requirements, with a named person responsible for keeping each one accurate. I do not interpret tax law, and current obligations should always be checked with your advisor. The configuration side, once a platform is chosen, sits on my ERP consultant page for Jordan, and the method behind the catalog is explained under ERP requirements gathering.

Process maps for pharma suppliers, distributors and service exporters

Generic ERP templates assume a simple buy, store and sell cycle. Jordanian companies that look for business analysis rarely fit that picture, so the process maps have to show where they differ.

• Pharmaceutical and medical suppliers. I map the path from goods receipt to quarantine, quality release, picking by expiry and dispatch, then trace how a recall would locate every affected customer. Requirements state which steps need approval and which records must be kept.
• Distributors. The maps cover price lists by channel, credit checks before release, van or route sales where they exist, and returns with reason codes, because returns are often the least documented flow in the business.
• IT and professional services exporters. Here the map follows a contract from proposal to timesheet, milestone approval, invoice in US dollars and collection, with margin reported per client and per team.

Each map uses swimlanes so that handovers between departments are visible. Bottlenecks, duplicate entry and manual workarounds are marked directly on the diagram, and every marked issue links to a requirement that addresses it. You can read more about the technique on the ERP process mapping page.

Arabic outputs in an English BRD

The analysis, workshops and documents are all in English. Many outputs of a Jordanian ERP, though, will be read in Arabic: customer invoices, delivery notes, some statutory reports and the screens used by warehouse or sales staff. Leaving those needs out of the BRD is a common reason why a system passes vendor demos and then fails in the first week of live use.

So the requirements include a document register. For each printed or emailed output it records the language or languages required, whether text runs right to left, which fields come from the system and which are fixed text, and who on your staff will approve the final layout. The same register notes which user groups will need Arabic interface labels or training material.

Review of Arabic wording is done by a bilingual member of your team or by the implementer. I make sure the review happens, is recorded and is tied to a requirement number, and the Arabic text itself is checked by your bilingual staff. During fit-gap, each vendor shows one Arabic invoice and one bilingual report, and the result is scored like any other requirement. My ERP BRD consulting page shows how the register fits into the wider document.

Hosting, connectivity and access requirements

Technical requirements are often left to the implementer, yet they shape both cost and risk. I capture them in business language so they can be compared across proposals.

The questions I document include where the system and its backups will be hosted and whether any customer or employee data has location or access constraints that your counsel wants respected, given Jordan's personal data protection legislation. I also record how branches, warehouses and remote sales staff connect, whether any site needs to keep working through a short internet outage, and what response time the business expects from support.

Access rules get their own section. Who can approve a credit note, change a price list or edit a customer tax number? Which reports should regional managers see for their own entity only? These become role definitions that the implementer configures and that UAT later proves.

Integration points are listed with their direction and frequency: bank statement imports, the e-invoicing connection, any ordering portal and the payroll provider's journal file. Platform-specific hosting choices are discussed on the Odoo, Zoho, ERPNext and Dynamics 365 pages written for Jordanian companies.

How the analysis runs remotely

Requirements work suits remote delivery because most of it is conversation and writing. Amman runs a few hours behind Indian time, which places live sessions comfortably in your morning and the afternoon remains free for your staff to answer follow-up questions.

I keep each session narrow: one process, one group of users, real documents on screen. Afterward, the notes, draft requirements and open questions go into a shared tracker with a named owner for every item. Staff who cannot join live, such as storekeepers or field sales, answer a short questionnaire or record a quick screen walkthrough of how they work today.

Sign-off happens area by area. Finance approves its section, operations approves theirs, and the full BRD is frozen only when every owner has agreed. From there the fit-gap analysis begins, with vendors running scripted scenarios drawn straight from the document. For wider context on the market, see the Jordan overview.