The fuel policy is the formal document that defines who fuels up, with which payment method, under what conditions and with what consequences if it is not followed. Without that document written, communicated and signed, any consequence the company wants to apply for misuse is open to dispute, even when the data that proves it is flawless. The policy does not detect anything: it is what turns a finding into a defensible action.
It is an internal governance document, not a system setting. Its legal value comes from being written, communicated and accepted by the driver, not from being loaded into any software.
That distinction gets lost all the time and creates two symmetrical problems. The first is writing a policy full of restrictions that nobody checks afterwards. The second is assuming that if the system does not control something on its own, that thing cannot be part of the policy. Neither holds up: the policy defines what should happen, and for each clause you have to decide separately how it is verified.
Before writing a clause, answer one question: with what data, reviewed by whom and how often will I know whether this was complied with? If you have no answer, the clause will not be in force: the day you want to apply it you will discover it has been breached for two years without consequences, which makes it unenforceable.
This does not mean writing a short policy, but making sure each point has, next to it, even in an internal appendix, who reviews it and how often. There are three categories: those the system verifies fueling by fueling, which are few; those verified with a manual routine on data that does exist; and those that cannot be verified with the available data, which are written anyway if they are needed for legal or contractual reasons, but knowing that their effect is declarative and not a control.
Among the controls the Fuel module applies to each recorded fueling, these four are the ones that do the most to support a policy:
Geolocation. Cross-checks the station’s location with the vehicle’s position. Detects a fueling recorded where the vehicle was not.
Tank capacity. Compares the liters fueled against the model’s capacity. Detects a fueling that could not physically fit in that tank.
Expected fuel efficiency. Compares actual consumption against the model’s expected consumption, in liters per 100 km.
Fuel card. Verifies that the card used is the one registered for that vehicle. It exists specifically to detect drivers swapping cards.
Based on those controls, each fueling is flagged as NORMAL or under REVIEW. There is also a data point that comes along but is not a control: price per liter is shown as a visual indicator —an arrow up or down compared with the previous fueling— for the manager to look at, without changing the fueling’s status.
Everything else you want to control depends on someone reviewing the records at a defined frequency. A thirty-minute monthly review of the period’s fuelings covers much more than most companies think, but only if it is on the calendar of a specific, named person.
Scope. Which vehicles, which drivers, which hiring arrangements. The most often forgotten are outsourced staff and third-party vehicles: if they are not named, they are left out.
Authorized fueling methods. Corporate card, voucher, reimbursement against a receipt. If you work with one card per vehicle, this is where you write that the card is non-transferable, which is what gives grounds to the fourth control.
Recording obligation. Every fueling must be recorded with liters, amount, station and odometer reading. It is the most important clause and it almost never appears: without a complete record, the controls do not work.
Fueling conditions. Where, when and within what limits. These are clauses the system does not verify on its own, so each one needs its associated review routine or it becomes a dead letter.
Exceptions process. How a fueling outside the usual conditions is authorized —a long trip, an emergency— and who authorizes it. Without this process, exceptions are handled through informal messages, and on review day there is no way to tell an authorized exception from a breach.
Consequences for non-compliance. Graduated, written and tied to specific types of non-compliance. The gradation is applied by a person case by case, within the framework of the document.
Document review cadence. Annual, or sooner if the operation, the fleet or the fuel provider changes.
The policy is signed through the human resources process, together with the onboarding paperwork, and filed in the driver’s personnel record. It is an employment act with its own formalities: HR administers it based on the criteria of its legal advisor, not the fleet management system.
Do not confuse this signature with the Signature attribute in the Checklist module, which lets the driver record a specific vehicle inspection. Mixing them up leads to assuming that acceptance of the policy is recorded in the system when it is not.
Three conditions for the signature to be useful: the document is handed over as a copy, it is renewed when the policy changes, and every change is communicated in writing. A modified policy without re-acceptance remains in force in its old version.
Writing it as generic text. Copied from a template, without the names of bases, actual payment methods or specific owners, it does not describe this company. In an employment dispute, that shows.
Defining restrictions without defining who reviews them. The most expensive mistake. It creates the illusion of control and, when a serious case comes up, a precedent of years of tolerance.
Having no exceptions process. It forces everyone to break the rules in good faith, which destroys the distinction between tolerated and sanctionable non-compliance.
Writing consequences the company is not willing to apply. A consequence that is stated and never enforced weakens the entire document.
Communicating it only once. If the only mention was on the first day of work, the reference fades. A formal annual reminder and explicit communication of every change are the minimum.
The order determines whether the policy is followed or just filed away. The common mistake is to start with the drafting and end with the verification, when the useful sequence is almost the reverse.
First, look at what is happening today. Review three months of fuelings: where people fuel up, how often, what share ends up under REVIEW and because of which control. A policy written without that diagnosis regulates imaginary problems and leaves out the real ones. If you have never done the exercise, the warning signs of fuel fraud give you a framework for reading the data.
Second, clean up the master data. Tank capacity and expected fuel efficiency by model, and the card registered to the correct vehicle. If they are incomplete, the policy will be backed by controls that throw false positives, and you will lose the first dispute with a driver.
Third, only then draft it, clause by clause, with its verification method next to it. If you cannot write down who reviews it and how often, you have two honest options: create that routine or remove the clause. The third —leaving it unverified— is the one that empties the document.
Fourth, have it validated legally before communicating it. Employment rules vary between countries and between hiring arrangements, and a poorly framed consequence becomes unenforceable exactly when you need it.
Fifth, communicate, train and only then start applying consequences. An explicit initial adjustment period, in which breaches are pointed out without sanctions, improves later compliance and leaves a record that the rule was communicated. Sanctioning in the first week, for behavior that was normal until yesterday, is the shortest path to the policy being perceived as a trap.
