A car rental management system, scoped around the handover

Most briefs for a rental system arrive describing a calendar. Show which cars are free, stop double bookings, take a reservation. That part matters and it is also the part least likely to go wrong, because availability is a well understood problem with well understood solutions.

The money in a rental operation leaks somewhere else: in the gap between handing a car over and closing the contract financially, which can be weeks later. A toll crossing posts against the vehicle. A fine arrives with a date and a plate. A deposit is sitting on a card and somebody has to decide what to release. If the system cannot attribute each of those to the right rental, the operator absorbs the difference, and they usually do not find out how much until an accountant asks.

The handover is the real transaction

A rental is not a booking, it is a custody transfer. Two records exist at the moment the keys change hands and both have to be captured properly or every later dispute is unwinnable.

• Who is driving. Licence details, expiry, and whether additional drivers are named. An unnamed driver is an insurance problem, not an admin detail.
• Vehicle condition, with timestamped photographs taken by the system rather than on somebody's phone.
• Odometer and fuel at out and in, because both feed charges that get argued about.
• The authorisation held on the card, its amount, and when it expires.

The design point is that the condition record has to be created at handover and be immutable afterwards. A system that lets a branch edit the out condition after the car comes back has no evidence, only assertions. This is the same requirement as any custody or chain-of-evidence record and it is cheap to build correctly at the start and expensive to retrofit.

Tolls: the structure differs by emirate

The two systems a UAE operator deals with do not work the same way, and the difference changes the data model rather than just the rates. The official UAE government portal page on roadways sets out both.

In Dubai, Salik is tag-based: a tag is affixed to the windscreen and all vehicles including taxis pay at the gates. The toll varies by time of passage. The portal lists violations for passing a gate without a tag, or with insufficient balance and no recharge within five days. And since 1 June 2026 a 5% VAT applies to all toll transactions, which means any rebilling logic written before that date is now producing the wrong number.

In Abu Dhabi, Darb is plate-based with no tag at all. The portal gives a toll of AED 4 on every vehicle passing the gate during peak hours, defined as 7 to 9 am and 3 to 7 pm, Saturday to Thursday, with no fees off-peak, on Fridays or on official holidays. Vehicles are identified by plate number, and vehicle owners must set up and activate an account.

So one system attaches cost to a physical tag on a car and the other attaches it to a plate, and the chargeable windows are different. A system that stores a single flat toll rate per crossing will be wrong on both. What it needs instead is a crossing record with a timestamp, a gate, a scheme and an amount, resolved against the rental contract that covered that vehicle at that moment.

Fines arrive late and against the wrong party

This is the hardest requirement in the whole system, and it is hard for a structural reason rather than a technical one. The official UAE road safety page describes fines as tied to a driving licence or a vehicle, and lists the platforms where they are checked and paid: the Ministry of Interior website, the MOI UAE app, Emirates Vehicle Gate, Abu Dhabi Police, Dubai Police, RTA Dubai, and Ras Al Khaimah eGovernment.

Read that list again from the point of view of a fleet. A fine recorded against your vehicle is discoverable across several separate emirate-level platforms, and it has to be matched to whichever customer had the car at that timestamp. The operator is the registered party. The customer is the liable one commercially. Nothing in the official channels makes that link for you, because it is a matter between the operator and its renter.

What that means for the build:

• Every rental needs an exact out and in timestamp, not a date, because a fine at 18:40 on a changeover day belongs to exactly one of two customers.
• A fine record needs a status of its own: discovered, attributed, charged, disputed, written off. Treating it as a line on an invoice loses the ones that arrive after the invoice closed.
• The deposit release decision has to be able to wait, or to be partially released, because fines surface after the car is back.
• Somebody has to own a recurring check against those platforms. Whether that is an integration or a person with a calendar reminder is a real decision and the honest answer depends on volume.

That last point is where these projects get mis-scoped. Automating a check against several government platforms is not one integration, it is several, each with its own access rules and failure modes. What that actually costs is the subject of what it really costs to connect two systems, and for a small fleet the correct first version is often a disciplined manual check with the system tracking the outcome.

What the availability engine still has to get right

Availability is the easy half, but it has two cases that catch naive implementations.

The first is that a car is not free the moment it is returned. Cleaning, refuelling, inspection and any damage work all consume time, and a system that releases the vehicle to the calendar on return will cheerfully double-book it. Statuses need to include the unavailable-but-not-rented states.

The second is the substitution. Customers book a category and receive a specific vehicle, and the assignment of car to contract often happens at the counter. If the data model binds a reservation to a VIN at booking time, every real-world substitution becomes a cancellation and a rebooking, and the history stops being readable. Bind the reservation to a class and the contract to a vehicle.

The general version of the availability problem, including the buffer logic, is in a custom booking system for services, and the asset-tracking half has more in common with an inventory system for a retail chain than with a hotel booking engine.

A sensible first version

If this is being built rather than bought, the order that tends to work:

• Fleet register with statuses, including off-road and preparation states.
• Contracts with exact out and in timestamps, named drivers, and immutable condition records with photographs.
• Charges and deposits, with partial release and an open-items list that can outlive the invoice.
• Toll and fine records as first-class objects with their own lifecycle, entered manually at first.
• Reporting on utilisation and on revenue leakage, meaning the charges that were incurred and never recovered.
• Only then any automated integration with external platforms.

The fifth line is the one that pays for the project, and it is the one most often left out of the brief. An operator who cannot measure what they failed to recharge cannot tell whether the system worked. Scoping that honestly before anything is built is the method in how to scope a software project before anyone writes code.

Honest limits

Three things worth saying plainly, and we are an agency, so the first one is against our interest.

Most small operators should buy rather than build. Rental management is a mature category with products that already handle tolls, fines and deposits for this region. A custom build earns its cost when you have an unusual operating model, a fleet large enough that a percentage of leakage is a real number, or an integration requirement no product covers. A ten-car fleet does not.

The toll and fine details above are the documented structure, not a rate card. The portal gives the Darb peak figure and the Salik VAT change, and it does not publish a full Salik tariff table on that page. Any system that hard-codes amounts will drift, which is itself the argument for storing the amount that actually posted rather than calculating it from a rate you believe is current.

And nothing here is legal or tax advice about what you may recharge to a customer, or how VAT applies to a rebilled toll. That is a question for an accountant who knows your contracts. What a system can do is record what was incurred, against which contract, with evidence attached. The policy decision about what to charge is yours.

One further decision that outlives the build: who owns the code and the data when the arrangement ends. That is who owns the source code when you hire a developer, and it is cheaper to settle in the contract than in a dispute.