Vehicle condition report: what to record and a reusable template

For this guide, a vehicle condition report is a structured record of what was observed about a vehicle at a named point in a workflow, such as handover or return. A useful report anchors the observations to a vehicle and stage, then keeps readings, photographs, notes, gaps and later review easy to distinguish.

Think of the report as a record, not a verdict. It can give a reviewer organized information, but it cannot establish on its own when or why a change occurred, whether the vehicle is roadworthy or who is liable.

The five-part structure below can be adapted for paper, a spreadsheet or an audit workflow. It is practical guidance rather than a universal legal or safety checklist.

Start with the purpose and stage

Write down what the record is for before choosing fields. “Vehicle condition” is too broad on its own.

A record might capture:

• one pre-delivery observation;
• the condition when a vehicle is handed over;
• the condition when it is returned;
• a fleet reassignment; or
• a separate incident or damage observation.

Then decide whether the job needs one stage or two. A one-time record should not invent an “after” visit. A true before-and-after comparison needs two separately submitted stages using the same structure. AuditIt calls those modes record_only and before_after; they are distinct workflows.

Name the stage in the report. “Return — 18 September, 16:20” is more useful than an undifferentiated set of images. Keep the recorder identifiable. When a field cannot be completed, preserve the reason instead of copying an earlier value into the later stage.

Copyable vehicle condition report template

Use the structure below as a starting point, then adapt it to your vehicle type, contract, organization policy and jurisdiction. A field appearing here does not make it a legal, mechanical or safety requirement.

1. Record context

Begin with four prompts:

• Report purpose: handover, return, pre-delivery, reassignment or another defined event.
• Vehicle identity: registration number or another stable fleet reference used by your operation.
• Stage, date and time: the point in the workflow and the time associated with this submission.
• Recorder: the name or role required by your organization's policy.

Together, these details tell a later reader which vehicle and workflow point the observations belong to. A typed time is still a submitted value, and context alone cannot validate the observation.

2. Readings and rental context

Capture the reading and its context together:

• Odometer: record the displayed digits and state miles or kilometres.
• Fuel or charge: choose a defined scale and use it consistently. “Half” is a category, not an exact volume, and a fuel scale should be adapted before it is used for battery charge.
• Keys and accessories: name each item and give it an explicit state such as issued, present, absent, not issued or not checked.
• Exceptions: say when a display is unreadable, a view is obscured or a category is uncertain instead of guessing.

The UK's BVRLA member code provides a scoped example: it describes documenting fuel levels and mileage at the start and end of a rental, recording portable accessories, and using dated condition records in its pre- and post-rental procedures. That is a code for BVRLA members, not a global requirement.

The US Federal Trade Commission's consumer guide discusses fuel-return arrangements, mileage limits and optional equipment as rental terms. Keep those terms separate from the condition you observed; interpreting an agreement or calculating a charge is outside this guide.

For a more detailed field method, see the vehicle handover record for odometer, fuel and accessories.

3. Exterior views

Use a repeatable order that gives both orientation and detail:

1. front;
2. rear;
3. driver side;
4. passenger side;
5. a wider view locating each observation; and
6. a closer view showing the visible detail.

This is a practical sequence, not a required photo count. Some vehicles or observations need different views. If a view cannot be captured, record that gap and the reason rather than silently omitting it.

Describe what can be seen: “Scrape on lower passenger-side door; wider side view and close-up submitted.” Keep a reported account separate: “Driver reported noticing the mark after parking.” Do not convert either sentence into “new damage caused by the driver” unless an authorized reviewer has other evidence and responsibility to make that decision.

If the job is a one-off damage event rather than routine condition capture, use the rental vehicle damage record template instead of burying the event inside a generic handover report.

4. Interior and supplied items

Choose prompts that match what your operation actually issues and reviews. They might include:

• dashboard in context;
• cabin and load area;
• visible cleanliness observations;
• documents, keys and named accessories;
• charging cable or other vehicle-specific equipment; and
• free-text notes for an observation that does not fit a fixed option.

Use explicit states. “Charging cable: present,” “Spare wheel: not issued,” and “Tool kit: not checked” mean different things. Avoid treating a blank checkbox as an observation.

AuditIt's current Vehicle Hire-Out & Return starter includes a dashboard view, cabin photographs, a cleanliness choice, named accessory options and interior notes. Those are customizable defaults for one template, not a universal inspection list.

5. Review and exceptions

Finish the report by separating four kinds of information:

• Observed: “Left rear wheel trim has a visible scuff.” This describes what can be seen, not the cause or a repair diagnosis.
• Reported: “Renter says the scuff was present at collection.” Attribute the account; it is not independent confirmation.
• Unknown: “Collection-side close-up was not submitted.” The missing view should remain visible as a gap.
• Reviewer decision: “Send to the authorized fleet reviewer.” This is a later action, not an automatic result from the report.

Record who owns any follow-up. Keep the later decision distinct from the original submission so a reader can see what was observed first and what was decided afterwards.

Use the same structure at handover and return

Imagine a van being collected on Monday and returned on Friday. At handover, the recorder uses its registration as the stable reference, states kilometres for the odometer, chooses one fuel scale, lists the keys and charging cable separately, and follows the named photo order. At return, the recorder opens a second stage instead of editing the first one, then repeats those field names, units, options and views.

If rain obscures the passenger-side return image, the recorder marks that view as unclear rather than treating it as unchanged. The reviewer now has a comparable pair and a visible gap. A difference may be visible, but these two stages cannot explain why it appears; they organize what was submitted for review.

For the full two-stage method, read vehicle hire-out and return: a comparable condition record. That page owns the paired rental workflow; this page owns the broader report structure.

A condition report is not a daily safety check

The purpose matters. In Great Britain, DVSA's van guidance tells drivers to carry out a walkaround before a journey to make sure the van is safe and, for businesses with an operator licence, to record and report defects. That is a scoped safety-check workflow for vans in England, Scotland and Wales. It should not be replaced by a rental handover condition report.

Likewise, a condition report should not be described as a mechanical inspection, roadworthiness certificate or maintenance decision. If your process needs those outcomes, use the applicable local requirements and qualified people. Keep their conclusions separate from the submitted condition observations.

Where AuditIt fits

AuditIt's current Vehicle Hire-Out & Return starter uses a before_after workflow. Its default structure includes registration, odometer, fuel level, front, rear, driver-side and passenger-side views, damage close-ups, tyres and wheels, dashboard, cabin, cleanliness, accessories and interior notes. Teams can copy a starter into their own template library and adapt it to their process.

The repeated fields help a human review two submitted stages together. That comparison alone cannot show that a visible difference happened during the rental or establish who is responsible.

NIST defines tamper-evident in terms of making data alterations detectable. AuditIt uses the term in that detection sense: changes can become detectable, not impossible. AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability.

Get started with AuditIt and adapt a vehicle workflow to your operation.

• vehicle condition report
• vehicle rental
• fleet operations
• condition evidence
• handover