Maritime Emissions and Fuel Reporting Software: When Your Noon Report and Your Flow Meter Disagree by Four Tonnes

Why the reporting problem is a data problem, and why it costs real money

A Panamax finishes a laden leg from Rotterdam to Santos. The chief engineer's noon reports total 412 tonnes of very low sulphur fuel oil for the voyage. The mass flow meter on the main engine says 408. The bunker delivery note from the previous stem said 1,150 tonnes delivered, the ROB figures imply 1,143, and the surveyor's report notes a temperature difference the office never picked up. Four tonnes of fuel is roughly thirteen tonnes of carbon dioxide, and under the EU Emissions Trading System that is allowances someone has to buy. The question of who is a charter party question, not a technical one, and the office is trying to answer it from a spreadsheet built by an analyst who left in March.

This is the whole job. Emissions reporting for shipping is not an environmental exercise, it is a fuel accounting exercise with a financial settlement attached. EU MRV made you measure. The extension of the EU ETS to maritime transport turned that measurement into a purchase obligation, phased in from forty percent of 2024 emissions through to full coverage from 2026. FuelEU Maritime added a well to wake greenhouse gas intensity limit with its own compliance balance, pooling and banking mechanics. The IMO carbon intensity indicator has been rating ships from A to E since 2023, with a corrective action plan required after three consecutive D ratings or a single E. Each regime draws its boundary differently, and none of them accepts your best guess.

The operational reality on most fleets is that the numbers arrive by email, in Excel, in whatever format each master has used for a decade, and someone in the technical department normalises them by hand. That person is now sitting between the fleet and a purchase decision measured in six figures.

Problem 1: the same voyage produces three fuel numbers and you must defend one

Noon reports are self reported by a crew with other jobs. Flow meters are accurate if they are calibrated and if someone accounts for return lines and boiler consumption. Bunker delivery notes reflect what a supplier says was delivered, and the disputes around that are as old as bunkering. Tank soundings give you a stock position, not a consumption rate. Verifiers will accept a method, but they will reject inconsistency, and they will reject a fleet where the reported quantities never reconcile against the stock movements.

What a build has to do is stop treating one source as the truth. Every fuel event, whether a bunker stem, a consumption report, a sounding or a debunkering, becomes a record with its source, its measurement method, its timestamp and its uncertainty. Reconciliation runs as a continuous process rather than a year end panic: opening ROB plus deliveries less consumption should equal closing ROB, and where it does not, the system raises a variance against a specific vessel and a specific period while the crew who created it are still aboard. Chasing a discrepancy in March for a voyage in August is how fleets end up submitting a number they cannot explain.

Problem 2: sensor quality varies per ship, and averaging hides the liars

On a mixed fleet you will have modern ships with mass flow meters on main engine, auxiliaries and boilers feeding an onboard data logger, and older ships where the only instrument is a sounding tape and a chief engineer's judgement. Treating both with the same validation rules produces two failures at once: it flags good data on the instrumented ships as noisy, and it waves through implausible data on the manual ships.

The build needs a per vessel data quality profile. Which sources exist, which one is authoritative for which fuel type, what plausibility bounds apply given the engine's specific fuel oil consumption curve and the reported power, and what the fallback is when a meter drops out mid voyage. Plausibility checking against speed, weather and draft catches the classic problems: a consumption figure that implies the ship was making eighteen knots at slow steaming settings, or a noon report copied forward unchanged for four days because nothing changed on the bridge. This is where the value sits, because a verifier finding these before you submit is expensive, and a verifier finding them after you have bought allowances is worse.

Problem 3: the owner and charterer split follows the charter party, not the software

Under a time charter the charterer buys the bunkers and typically bears the allowance cost, and BIMCO's emissions clauses exist precisely because the parties needed standard language. Under a voyage charter the position differs. Then you have off hire periods, where liability usually reverts, ballast legs, waiting time at anchorage, and the awkward voyages that begin outside the EEA and end inside it, where the EU scheme counts a proportion rather than the whole thing.

Commercial products model the common cases. What they cannot model is your specific fixture: a clause negotiated with one charterer that caps their exposure, an agreed apportionment for slow steaming instructions, or a sublet chain where the disponent owner sits in the middle. So the office rebuilds the split in Excel, which means the invoice to the charterer is a manual calculation with no audit trail, and the charterer's own analyst will challenge it.

A custom build treats the charter party as a configurable rule set attached to the fixture: who bears which regime, over which periods, with which scope percentage, subject to which cap. Then the allowance statement to the charterer is generated from voyage data with every line traceable to the underlying fuel events. Disputes stop being negotiations and start being lookups.

Problem 4: three regimes, three boundaries, one dataset

The EU ETS counts voyages into and out of the EEA at a proportion and intra EEA voyages in full, plus time at berth. FuelEU Maritime measures greenhouse gas intensity on a well to wake basis, which brings the fuel's upstream emission factor into scope and makes the fuel type and its certification matter in a way the ETS does not. The IMO carbon intensity indicator is an annual efficiency ratio across the whole year's operation, which means a ship can be compliant on allowances and still trending toward a D rating. The UK has confirmed its own scheme will extend to shipping, and further global measures remain under negotiation, so the boundaries will keep multiplying.

The design consequence is that you build one voyage and fuel data model, and you compute each regime as a separate calculation layer on top. Fleets that instead build a spreadsheet per regime end up with three answers derived from three snapshots of the same data taken on different days, and no way to explain the difference to a verifier.

Where ZeroNorth, DNV Emissions Connect and StormGeo actually stop

These are competent products and the criticism should be about fit, not quality. ZeroNorth is strong at voyage and commercial optimisation with emissions attached, which suits an operator making routing and speed decisions. DNV Emissions Connect is strong on the verification and allowance accounting side, unsurprisingly given the verifier heritage. StormGeo comes at it from weather routing and vessel performance, which is genuinely useful for the CII trend rather than the allowance bill.

Where all of them get uncomfortable is at the edges that define a specific fleet: heterogeneous instrumentation across an old and new fleet, non standard charter party splits, sublet chains, pooling decisions under FuelEU where you are optimising across owned and managed tonnage, and integration with the planned maintenance system and the accounting ledger you already run. You end up exporting to Excel for the last mile, and the last mile is the part with money in it.

What a custom build must include

An immutable fuel and voyage event store with source, method and provenance on every quantity. Per vessel data quality profiles with plausibility rules. Continuous reconciliation against ROB with variance workflow assigned to a named person. A regime calculation layer covering EU MRV and ETS, FuelEU intensity and compliance balance, and IMO DCS plus CII rating with an attained trend so the technical team sees a D coming in June and not in February. A fixture layer holding the charter party split rules. Allowance position and surrender planning, because when you buy matters commercially. Verifier export packs that produce exactly what your verifier asks for without a manual assembly step. And an onboard capture path that works with a poor satellite link, because a reporting app that requires connectivity will be filled in later from memory, which is the exact behaviour you are trying to eliminate.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the fuel and voyage data model, ingestion from noon reports and flow meter logs, reconciliation, and EU MRV and ETS calculation runs $70,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding FuelEU intensity and pooling, CII trending, charter party splits, allowance position management, verifier packs and an onboard reporting app runs $200,000 to $500,000 phased over 6 to 12 months.

What drives the cost up in shipping specifically: fleet heterogeneity, because every additional onboard data logger vendor is another ingestion adapter. Sublet and pool structures, since the ownership chain complicates every calculation. Historic data backfill, because verifiers want consistency across periods and your old data is in a different shape. And multi entity accounting if the fleet sits under several owning companies with different reporting obligations.

How to choose a developer for maritime emissions software

Ask how they would handle a mass flow meter that fails on day six of a fourteen day voyage. If the answer does not include a documented fallback method, a flag on the affected period and a note that carries through to the verifier pack, they are building a dashboard rather than a compliance system.

Ask them to explain the difference between the EU ETS scope boundary and the FuelEU boundary in their own words. This is a five minute question that separates teams who have read the regulations from teams who have read a vendor's marketing page, and you do not want to fund the second group's education.

Ask what they will do with your existing noon report formats. A serious answer involves parsing the actual files from three or four of your masters during the proposal stage, not a promise to define a standard template that crews will ignore. Then get ownership in writing before kickoff: the repository, the cloud accounts and the right to appoint anyone else. At Digital Heroes the client owns it from the first commit, which matters more here than usual because this data has to survive audits years after the project ends.