Maritime Emissions Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does building one calculation per regime go wrong so often?

The brief arrives as three deliverables: an EU ETS report, a FuelEU compliance balance, and a CII rating. So three workstreams start, each with its own extract, its own assumptions about which fuel figure to trust, and its own idea of what a voyage is. Each one demos well in isolation. Then someone lays the three outputs side by side and the underlying consumption totals do not match, because they were pulled on different dates from data that was still being corrected.

Shipping makes this worse than it would be elsewhere, because the three regimes draw their boundaries differently on purpose. The EU ETS counts intra European Economic Area (EEA) voyages in full, voyages into and out of the EEA at a proportion, and time at berth, phasing to full coverage from 2026. FuelEU Maritime measures greenhouse gas intensity on a well to wake basis, which pulls the fuel's upstream emission factor and its certification into scope. CII is an annual efficiency ratio producing an A to E rating, where three consecutive D ratings or a single E requires a corrective action plan. The same voyage legitimately produces different numbers, and only a shared dataset makes that defensible rather than embarrassing.

The fix is one voyage and fuel event store first, then each regime as a calculation layer on top with its boundary expressed as a rule. In Digital Heroes delivery experience the first release covering the data model, ingestion from noon reports and flow meter logs, reconciliation, and EU monitoring, reporting and verification (MRV) plus ETS calculation runs $70,000 to $160,000 and ships in 12 to 18 weeks. Adding FuelEU intensity and pooling, CII trending, charter splits, allowance position management and verifier packs takes it to $200,000 to $500,000 phased over 6 to 12 months. Regimes will keep multiplying, so the layer is the investment, not the report.

What goes wrong when historic noon reports and bunker records are migrated?

Verifiers expect consistency across reporting periods, so somebody decides to backfill three years of history. The old data is in a different shape: masters used their own noon report templates, fuel grades were recorded inconsistently, bunker delivery note quantities were entered at delivered temperature on some ships and corrected on others, and the analyst who normalised it all left in March without documenting a single rule she applied.

Backfill is unusually dangerous in emissions reporting because the output is a financial obligation rather than a dashboard. An imported figure that carries no record of how it was derived becomes indistinguishable from a measured one within six months, and it is exactly the figure a verifier will pick.

The fix is to carry provenance on every migrated quantity: which source produced it, which measurement method, which assumptions were applied, and by whom. Import at the event level rather than as monthly totals, so reconciliation can be rerun later when a rule changes. Then accept that some periods are simply weaker than others and mark them, because a documented gap is something a verifier can work with and an undocumented estimate is not. Budget the backfill explicitly. In this category it is the most common cause of schedule slip, and it is nobody's favourite work, so it gets deferred until it becomes the critical path.

Why do flow meter and onboard data logger integrations break after launch?

Ingestion is tested against two ships with the same logger vendor and it works. Then the rest of the fleet arrives: a second logger vendor with a different file layout, one ship whose engineer exports a slightly different report because he changed a setting, and a meter that fails on day six of a fourteen day voyage and starts returning plausible looking values that are wrong.

Fleet heterogeneity is the defining cost driver here. Every additional onboard data logger vendor is another ingestion adapter, and the ships that need the most validation are the ones with the least instrumentation. Applying one set of rules across both ends of the fleet fails in two directions at once: it flags good data on the instrumented ships as noisy, and it waves through implausible data on the manual ships.

The fix is a per vessel data quality profile. Which sources exist on this ship, which is authoritative for which fuel type, what plausibility bounds apply given the engine's specific fuel oil consumption curve and reported power, and what the documented fallback is when a meter drops out mid voyage. Plausibility checks against speed, weather and draft catch the classic cases: a consumption figure implying eighteen knots at slow steaming settings, or a noon report copied forward unchanged for four days. Define the fallback before it is needed, flag the affected period, and carry that flag through to the verifier pack. A system that silently substitutes an estimate is worse than one that raises a gap.

What happens when charter party splits and off hire are not covered?

The platform computes fleet emissions correctly and the office still rebuilds the owner and charterer split in Excel, because the software models the common cases and your fixtures are not the common cases. Under a time charter the charterer buys the bunkers and typically bears the allowance cost, which is why BIMCO published standard emissions clauses, but the fixture that actually matters is the one with a negotiated cap, or the agreed apportionment for slow steaming instructions, or the sublet chain with a disponent owner in the middle.

The consequence is not a reporting inconvenience. The statement you send the charterer is a manual calculation with no audit trail, and the charterer's analyst will challenge it. Every challenge is a negotiation you enter without evidence, and the settlement lands wherever the commercial relationship pushes it rather than where the data says.

The fix is to treat 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, with off hire and ballast legs handled explicitly rather than by exception. Then the allowance statement is generated from voyage data with every line traceable to the underlying fuel events. Disputes stop being negotiations and become lookups, which is a different conversation with a charterer entirely.

Should you build custom or configure what you already own?

Buy if you manage under about ten vessels on similar charter terms. ZeroNorth, DNV Emissions Connect and StormGeo are competent products and the criticism should be about fit, not quality. ZeroNorth is strong where voyage and commercial optimisation with emissions attached is the job. DNV Emissions Connect is strong on verification and allowance accounting, 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. At that fleet size, buy one and spend the difference getting your bunker delivery notes into a consistent format, which will improve your numbers more than any software will.

Build when two or more of these are true. You operate more than roughly fifteen vessels. Your fleet mixes flow meter equipped ships with noon report only ships. Your charter parties split liability in ways no product expresses, so the last mile of every calculation happens in a workbook. You are optimising pooling under FuelEU across owned and managed tonnage. Or you need the planned maintenance system and the accounting ledger joined to this data rather than exported alongside it.

The honest signal is where the money is. If the spreadsheet stage sits between the platform output and the invoice, the platform is not doing the part with money in it.

How do hidden costs get into the quote?

Four places specific to this category.

• Fleet heterogeneity. A quote priced against your two newest ships is not a fleet quote. Ask for ingestion to be priced per data source vendor, with the noon report formats of three or four of your actual masters parsed during the proposal stage rather than promised as a future standard template.
• Historic backfill. Almost always quoted thin because it is unglamorous. It belongs on its own line with a stated number of periods and a stated provenance standard.
• Ownership structure. Sublets, pools and multiple owning companies each complicate every calculation and every report. If the quote does not mention your structure, the developer has not modelled it.
• The onboard app. Capture that works over a poor satellite link, with local validation and queued sync, is real engineering. A quote assuming a browser and a connection has priced something your crews will fill in later from memory, which reproduces the exact data quality problem you are paying to remove.

What separates an emissions build that works from one that fails?

Four things, and you can test for all of them in a first conversation.

Every quantity carries its source, method, timestamp and uncertainty, and the event store is immutable. Reconciliation then runs continuously rather than as a year end exercise: opening remaining on board plus deliveries less consumption should equal closing remaining on board, and where it does not the variance is raised against a specific vessel and period while the people who created it are still aboard. Chasing an August discrepancy in March is how fleets end up submitting a number nobody can explain.

Failure has a defined path. Ask a developer what happens when a mass flow meter 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 carried into the verifier pack, they are building a dashboard rather than a compliance system.

Regulatory literacy is real. Ask them to explain the difference between the EU ETS scope boundary and the FuelEU boundary in their own words. It takes five minutes and separates teams who have read the regulations from teams who have read a vendor's marketing page, and you should not be funding the second group's education.

You own it, 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. This matters more here than usual, because the underlying data has to stay auditable and reproducible for years after the project team has moved on, and a supplier holding the source is holding your audit trail.