The Return Vehicle Process: Why You Need KM and Date Validation

"When did this car come back?" — the question your software must answer

If you can't tell me — to the minute — when each vehicle was returned, your rental software is leaving money on the table.

The modern vehicle return process captures three things, none of which can be optional:

1. Return date and time — picker pre-filled to "now", bounded by start_datetime and not allowed in the future.
2. KM In — required field, server-side validation that km_in >= km_out.
3. Return inspection — exterior, interior, fuel, damage triggered straight after.

Why date/time matters more than KM

KM is what shows up on the invoice — but the return date/time is what drives every downstream calculation:

• Late return detection (return_datetime vs end_datetime)
• Early return detection (more than 2 hours early)
• Daily proration for late charges
• Closure email "actual return" line
• GPS reconciliation against the last known position

A "close enough" date breaks all of these.

Validate at the database, not the form

Every rental software has a return form. Few have server-side rules that prevent km_in < km_out from ever landing in the database. The form is where users live; the database is where disputes are won. Enforce the rule in both.

What this enables next

Once return_datetime is reliable, you unlock:

• Late and early return charges
• Accurate settlement automation
• Reliable closure emails
• Per-vehicle utilisation reports

It is the keystone of a clean rental pipeline. Get it right and the rest follows.