The transport sector has a characteristic that few other sectors share: the largest part of CO2 emissions arises outside the office, spread across vehicles, trips and subcontractors that are not all in the same system. Where an office building is relatively easy to measure, a transport company's fleet consists of dozens to hundreds of individual moving sources, each with its own fuel consumption, load factor and route. The emissions are not contained in a building but in a sum of trips, and that sum has to come from multiple systems at once.
On top of that comes a second layer: a significant part of the kilometres is often not driven by the company's own fleet but by subcontractors, charter carriers or supply chain partners. In most cases those emissions fall under scope 3, and the data about them is rarely available as standard. A transport company that wants to have its sustainability data in order therefore has to search not only its own systems, but also have agreements about what subcontractors deliver and in what form.
Fuel consumption is usually the starting point and at the same time the most fragmented part. Fuel card data, on-board computers, telematics systems and manual fuel receipts often exist side by side, with different resolutions and different definitions of what counts as a 'trip'. An on-board computer registers per vehicle, a fuel card provider invoices per card, and those two do not automatically run in sync.
Planning and TMS software (transport management systems) contains data on load factor, return trips and empty kilometres, which are needed to allocate emissions per shipment or per customer. These systems are primarily built for operational planning, not for sustainability reporting, which means the required fields are sometimes present but not in the format that a CSRD report requires.
HR and personnel systems contain data on commuting and, at companies with their own workshops, on the energy consumption of business premises. Facilities departments often manage the energy contracts of offices, charging points and other real estate separately again. And then there is the folder of contracts and agreements with subcontractors, which sometimes does and sometimes does not state the fuel type or type of vehicle being used.
In many transport companies there is no single person who oversees all the sources mentioned above. The planning department knows the trips, the fleet manager knows the fuel consumption, procurement knows the subcontractors, and finance ultimately has to turn it into a reporting figure. Without clear ownership per data point, there is a risk that no one feels responsible for the accuracy of a figure, and that it only comes to light when the report is being drawn up that a source is missing or does not reconcile.
This is a recognisable pattern: in business services and in retail too, data is spread across departments that each hold part of the picture, without anyone overseeing the whole. In transport, there is the added complication that a substantial part of the sources are physically located outside the company, in vehicles and with partners.
It is tempting to want to solve this fragmentation with software that automatically merges telematics, fuel card data and TMS data. Such software can be useful, but only if it is clear in advance which data point should come from which source, who checks that data point, and which quality rule determines whether a value is credible. A tool laid on top of an unorganised process produces a neater report on the same unreliable figures. The order is therefore first the register of data points and their origin, and only then, if applicable, a system that automates that flow.
The Data Readiness Scan maps out for a transport company which data point comes from which system: fuel consumption per vehicle or per trip, load factor from the TMS, energy consumption of locations, and the data that subcontractors do or do not supply. For each data point it is recorded who owns it and which rule determines whether the value is plausible, so that during an audit it is clear where a figure comes from and who can be asked about it. This work is not about the report itself and not about answering questionnaires from customers or banks, but about the data layer that precedes it.
The scan is under construction. Anyone interested can sign up for the waiting list; nothing is being sold yet that is not finished.
Once it is clear which data points exist, who manages them and which system they come from, a follow-up question naturally arises: which part of collecting and checking those data points is manual work that remains with a planner or controller, and which part is repetitive enough to automate. The same question arises in sectors such as education and the agricultural sector, where operational data is just as scattered as in transport. FTE TO AI's work scan calculates per task which part of the work can be taken over by AI, and thereby connects with the moment when the Data Readiness Scan's data point register is complete: first know where the data is and who is responsible for it, only then look at which part of its maintenance can be automated.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.