TL;DR: Neither one, on its own. A noon report and a sensor feed measure different things over different windows, so the system worth having is the one that reconciles both against a modelled expectation of how the vessel should be performing, and flags what falls outside it. Judge vessel performance software on how it handles that disagreement.
A technical superintendent opens the monthly performance pack and finds two numbers for the same auxiliary engine. The noon report gives one figure for running hours. The sensor feed gives roughly double. Neither number is obviously wrong, and the first twenty minutes of the review go on arguing about which one to believe.
That argument is the real problem. Fleet performance reviews stall before they start because the data underneath them is contested, and nobody wants to commit to an efficiency target built on a figure they cannot defend. Data reliability has to be settled first. Only then is the performance conversation worth having.
So the question to put to any vessel performance software you are evaluating is not which data source it uses. It is what the system does when its sources disagree.
Why noon reports and sensor data disagree
They disagree because they measure different things over different windows, not because one of them is broken.
A noon report is a single human-entered observation that summarises the previous twenty four hours from deck and engine log entries. A sensor feed is continuous, producing thousands of readings across the same period. Even with both working perfectly, the two will describe the same day differently.
Definitions cause most of the rest. What counts as time at sea, what counts as running hours, and what counts as redundant machinery are all judgement calls that a human and a data pipeline will make differently. A vessel manoeuvring close to land or transiting a strait may be required by navigational practice to run a second auxiliary engine. By position those hours are at sea; by intent they are not redundant. A system that cannot tell the difference will classify them wrongly, and the discrepancy surfaces as an unexplained gap in the monthly pack.
Then there is the ordinary wear of a sensor estate: calibration drift, missing tags, gaps during maintenance. None of this makes sensor data untrustworthy, but it does mean raw sensor output is not automatically the more accurate of the two. For more on how high-frequency data behaves in practice, see our piece on sensor data in emissions reporting.
What vessel performance software has to do about it
Good vessel performance software does not pick a winner between the two feeds: it reconciles them against a modelled expectation and shows you which readings fall outside it.
That is the capability worth paying for. A modelled expectation gives you a third reference point, independent of both the crew's report and the sensor estate, against which either can be checked. When the noon report and the sensors diverge, the model tells you which one is behaving oddly rather than leaving the two to argue.
ZeroNorth vessel performance software is built around this. SMARTShip monitors machinery condition continuously, validates incoming reports automatically, flags readings that sit outside expected behaviour, and resolves the result into one dataset that technical and commercial teams read the same way. The value is not more data. It is fewer disputes about which number is real, which is also the foundation for integrated vessel performance analytics across both sides of the business.
One practical check when you evaluate: ask how the platform handles a fleet that reports through more than one route into the same vessel. If vessel identity is resolved at platform level, parallel reporting streams reconcile cleanly. If it is not, data lands against the wrong vessel or fails to load at all, and you inherit a reconciliation problem instead of solving one.
One baseline per fuel mode, not one per vessel
A dual-fuel vessel needs a separate baseline for every mode it actually operates in, otherwise the comparison is meaningless.
This is the most common modelling error in fleet performance reporting. A vessel is plotted against one consumption curve, usually the diesel-mode curve, while in practice it spends most of its time running on gas or in a combined mode. Every month the vessel is measured against behaviour it is not exhibiting, and the resulting variance is read as underperformance when it is really an artefact of the model.
The fix is not more sensors. It is more baselines. Ask any vendor how many baselines a single vessel can carry, whether they can be defined per fuel mode, and whether the system selects the right one automatically from the operating condition it observes. If the answer is one curve per vessel, the reporting will mislead you on any dual-fuel or LNG tonnage in the fleet.
Which approach fits your fleet
The right approach depends on what you need to defend commercially, not on how much data you can physically collect. The table below compares the three approaches most fleets choose between.
What verified fuel modelling actually proves
A verified fuel model turns an internal estimate into a figure a counterparty will accept.
This is the difference between performance data you use to manage a fleet and performance data you use in a commercial conversation. Independent verification is what lets a charterer, a financier or an auditor take the number at face value without re-deriving it themselves.
ZeroNorth's AI-enabled fuel model has been verified by DNV at 93.8% accuracy, set out in the DNV-verified fuel model announcement. Maersk Tankers worked with ZeroNorth on precisely this problem: read how Maersk Tankers optimised their data validation so that the figures reaching their teams could be relied on.
The bottom line
Choose vessel performance software on how it resolves disagreement, not on how much data it ingests.
Three questions separate the systems that settle the argument from the ones that add to it. Does it reconcile reported and sensed data against an independent modelled expectation? Can it hold a separate baseline for every mode a vessel actually operates in? And is the underlying model verified by someone outside your organisation, so the number survives contact with a counterparty?
If you are working through those questions now, see how SMARTShip handles them, review pricing, or book a demo and bring your own conflicting numbers to the call.
