Dealers · Finance

Commission and data scope in an agency working with dealers

A dealer should see the passengers they brought in and no one else's. Where that boundary is enforced matters more than how commission is calculated.

Published · 2 min read

Most Hajj and Umrah agencies work through dealers: branches, representatives, local businesses bringing in passengers. That structure raises two questions, and both need a concrete answer in the software — how much the dealer earns, and what the dealer can see.

Where commission is defined

Commission can be defined in two places, and which one wins must be unambiguous: a general amount on the dealer record, or a specific amount on the programme.

The correct behaviour is for the programme's own amount to take precedence. A dealer may normally take a fixed amount per passenger, but a higher figure may have been agreed for a premium programme; the programme definition should override the dealer definition.

If neither is defined the row should still be listed, at zero. "This dealer has ten passengers and no commission entered" is far more useful than not showing the row at all.

When commission is earned

This is a commercial decision rather than a software question, but its consequences land in the software. Three common practices: on confirmed registration, on collection, or after departure.

Earning it at registration motivates the dealer but requires clawback when a passenger cancels. Tying it to collection protects the agency's cash flow, but the dealer objects that chasing payment is not their job.

Whichever is chosen, one thing is constant: a cancelled passenger should not generate commission. That has to be automatic — tracked by hand, a few rows slip through every season.

Data scope: the real issue

It is natural for a dealer to see their own passengers. Not seeing another dealer's is commercially critical: if dealers can see each other's customers, the agency ends up in the middle of a competition between them.

Where that boundary sits matters. Built as a screen filter, typing another record's id into the address bar is enough to get past it, and an export-capable report can bypass it too.

In a correct setup the boundary sits in the data itself rather than on the screen. If a record outside the dealer's scope never reaches them by any route, that is a real boundary.

What a dealer should see

A dealer's needs are narrower than the agency's dashboard: how many passengers I brought, how many confirmed, how much commission accrued, how many I have on each departure.

Opening the full panel to a dealer creates two problems. First, information overload — the dealer gets lost among screens that do not concern them. Second, commercial: departure costing, profit and loss, and other dealers' performance are not a dealer's business.

A separate, narrow dealer screen makes the dealer's work easier and protects the agency's commercial position at the same time.

Related modules

  • Administration and security — Multi-user, multi-branch and auditable. Data isolation is enforced in the database, not in application code.
  • Collections and accounting — Multi-currency ledgers, instalment plans, cash and bank, and per-tour profitability. Exchange rates freeze at entry.

Terms mentioned

  • Account ledger — The running debit and credit record of a pilgrim, agent or supplier.

Let's set it up together

Tell us how your tours, pricing and team are structured; we will show the demo on a setup that resembles your own data.