Data Quality in Fleet Software: Making Electric Fleet Data Reliable

Good data quality in fleet software means that data is complete, unambiguous, plausible and sufficiently current for a specific task. In electric fleets, this includes vehicle master data, odometer readings, charging sessions and their assignments. You improve quality through clear field rules, visible error lists and a responsible person for every data source.

The benchmark is the decision you want to make. For monthly charging billing, a session needs to be assigned to the correct period and vehicle. Short-notice operational planning may also require a current state of charge. A record can be suitable for one task and too old for another.

Define quality for each data field

The statement “Our fleet data is clean” is difficult to verify. Instead, describe what should be true of each field. An internal vehicle identifier must be unique and remain unchanged when the registration number changes. An energy quantity needs a unit. A timestamp needs an unambiguous time basis.

Define rules for required and optional fields separately. A missing piece of supplementary information should not automatically prevent an otherwise usable session from being processed. Conversely, missing required information must not be replaced with invented default values.

Distinguish missing, zero and unverified values

Zero energy consumption and a missing energy quantity describe different states. Likewise, an automatically suggested vehicle assignment is not yet a confirmed assignment. These distinctions must remain visible in the software and in exports.

Use understandable states such as “not supplied”, “provisional”, “confirmed” and “for review”. Keep the number small enough for the team to apply them consistently. Document who may change a status and what information justifies the change.

For data supplied later, distinguish the original receipt from the subsequent correction. A session added afterwards must not silently enter a report that has already been finalised. The rules for this belong in automated fleet reporting.

Practical example: Making an error list actionable

Illustrative working example: There are 180 charging sessions for a monthly close. Twelve do not have a confirmed vehicle assignment. For five of these, the vehicle master data has no card relationship valid at the charging time. Four sessions arrived late. For three sessions, the assignment is genuinely unresolved.

The blanket instruction “correct twelve errors” is of little help. The team creates three lists of causes: complete master data, check late submissions and investigate assignments. Each list has a responsible person. After processing, the changes made and the evidence supporting them remain visible.

In this example, unresolved assignments fall to three. That is traceable progress. A rate of 100 per cent would not be a success if the final three cases were simply assigned to an arbitrary vehicle. These cases retain a documented clarification status.

Check data as close to its origin as possible

If the software detects a problem during import, you can usually investigate the cause more precisely. Useful input checks cover required columns, valid units, unique identifiers and readable date values. Content checks follow, such as whether a cost-centre assignment is valid.

Keep problematic records in a list that can be worked through. An error message should include the affected identifier, field and an understandable reason. “Import failed” is too vague. Also check whether valid records can continue through processing without a later retry creating duplicates.

Well-maintained vehicle master data prevents many downstream problems. Define which system is authoritative for each field. If the same information is maintained in several places, you need a clear rule for conflicting changes.

Worksheet: A quality sheet for each data source

Create a sheet for every relevant source containing:

1. The purpose of the data and the decision it supports.

2. The responsible person and a colleague who can cover the role.

3. Expected fields, units and delivery intervals.

4. A unique identifier for the vehicle or session.

5. Rules for missing, late and duplicate data.

6. Responsibility and a deadline for handling errors.

7. Evidence of how corrected data is processed again.

Start with the errors that regularly cause the most rework. Record their causes as well as their number. Repeated incorrect assignments suggest a problem in the master-data process; a one-off missing file may only require a specific resubmission.

For charging organisation, discuss your current data flow and requirements for transparent billing with StromNow for fleets. Bring anonymised sample cases and your most common data problems.