Hajj and Umrah operations are not general travel with different place names. A single pilgrim booking touches a package, hotel allotments in two cities, transport legs, a visa stage sequence, a payment plan and often an agent’s wallet – and the accounting has to survive scrutiny afterwards.
We built and still operate a 44-module travel ERP running exactly this. What follows is what we would check if we were buying rather than building, in the order that matters.
The two things general travel software usually gets wrong
The ledger
Most booking systems produce financial reports by summing their own transaction tables. In a sector with instalment payments, multi-currency supplier settlement and agent balances, that breaks down precisely when someone needs it to hold – during an audit, or a dispute with an agent.
Ask to see a journal entry. Not a report. If the answer is a filtered transaction list, the system has a reporting layer rather than a ledger.
Allotment and inventory truth
Hotel allotments in Makkah and Madinah are contracted blocks, not live availability. A system that treats them as bookable inventory without modelling the contract – release dates, cut-offs, penalty terms – will oversell, and it will do so in the season when that is most expensive.
Nine questions
- Show me a journal entry for a booking taken with an instalment plan. This single question separates real accounting from reporting faster than anything else.
- How are Makkah and Madinah allotments modelled? Look for release dates and cut-off handling, not just a room count.
- What happens when a visa stage is rejected after payment? The refund, the allotment release and the ledger entry all have to happen, and in the right order.
- Can an agent book against a wallet or credit limit without phoning? And if so, can the balance and the booking ever disagree? If the balance check and the booking write are not one database transaction, they can.
- Which currency is the base, and how are exchange differences posted? If currency is a display setting rather than a property of the transaction, multi-currency will be a spreadsheet job forever.
- Show me the audit trail on a financial write. Who changed it, when, and against which entry.
- What does departure readiness look like? A cross-check across allotment, transport, flight and visa records, or four separate screens someone remembers to open.
- Who owns the data, and what does an export look like? Ask before you need it.
- What happens at peak? Hajj season is a load pattern, not an average. Ask what the system did last season and who was watching it.
The four categories of option
General travel ERP with configuration. Cheapest to start, and the fit depends entirely on whether allotments and visa stages can be modelled rather than approximated. Ask about both specifically before anything else.
Purpose-built Hajj and Umrah systems. Domain fit is usually good. Check the ledger and the ownership terms, which is where these are weakest.
Spreadsheets plus an accounting package. More viable than it sounds below a certain volume, and it fails on agent distribution and audit trail rather than on capability.
Custom build. Justified when agent distribution is a growth channel, or when the operation is large enough that a reconciliation gap costs more than a build. Not justified for a small operator with a standard process.
If you take one thing from this
Ask question one. Every serious system can answer it in thirty seconds and every weak one changes the subject to a dashboard.