Bunker Fuel Procurement Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as procurement and stop before the claim?

Because procurement is the visible half. Enquiries, offers, stems and prices are what the office sees, they map onto a purchasing workflow everyone recognises, and they are what the packaged tools demonstrate well. The aftermath is invisible from a desk: a delivery note photographed at two in the morning, samples with seal numbers, a letter of protest that may or may not have been issued, laboratory results arriving after the vessel has sailed, an invoice on its own schedule.

So the money goes into the buying side and the claims side stays in spreadsheets and email. Operators expect the value to be in procurement and usually find it is in the claims they stop losing.

The order that works is the reverse of the intuitive one. Build the shipboard delivery capture and the claims workflow first, then the buying side. The delivery evidence file is the product: delivery note, soundings before and after, quantity with temperature and density, sample seal numbers, photographs of the note and seals, letters of protest and correspondence, all timestamped and written to an append only record so nobody can tidy it later. That immutability is what makes the file worth something when a supplier's lawyer reads it, and it costs no more at the start than a retrofit after the first lost claim.

What goes wrong with quantity data and vessel reporting formats?

Fuel is bought in mass, delivered from tanks measured by volume, and converted using temperature and density. The difference between an honest delivery and a dishonest one frequently sits inside that conversion rather than in the headline figure. A system that stores one quantity number has already thrown away the fields the dispute will turn on, and no amount of workflow design recovers them afterwards.

Store volume, temperature, density and corrected mass separately, with the correction reproducible from the stored inputs. Then a disagreement about the delivered figure becomes a disagreement you can actually examine rather than two parties asserting different totals. Ask any prospective developer how they store quantity before you ask anything else, because a single field tells you they have not worked in this domain.

The second data problem is remaining on board, which comes from your own fleet reporting in whatever noon report format your operations team uses. Fleet size matters far less here than format count: managed tonnage, chartered tonnage and vessels on a technical manager's reporting standard each arrive differently, and each is its own parser with its own validation. Teams budget by number of ships and then discover the cost driver was the number of reporting formats.

The third is consumption modelling. A requirement is a function of the voyage: port rotation, remaining on board, consumption at ordered speed, safety margin, grade constraints ahead and tank capacity. Buying without that is buying to a number somebody typed, and that number is usually conservative, which costs money on every stem.

Why do the laboratory and vessel reporting integrations break after launch?

Laboratory results are the first failure point, because every testing house reports differently and the report is the trigger for the whole claims clock. If results land in an inbox rather than in the system, the countdown starts when a person notices rather than when the result exists, and that gap is where windows are lost. Ingest results directly where the testing house supports it, and where it does not, build a structured intake with the parameters extracted and checked against the ordered specification rather than filed as a document. The system should open a claim automatically when a parameter falls outside specification, attach the evidence file and start counting down the contractual window.

Vessel reporting breaks on silence. A noon report format changes, a vessel changes technical manager, or a ship simply stops reporting for a week, and the requirement engine keeps producing numbers from the last figures it received. Stamp every imported value with the time it arrived, show that timestamp on the requirement screen, and refuse to generate a stem recommendation from data older than a threshold you set. A stale remaining on board figure produces a confident recommendation that is wrong in the expensive direction.

The third is the mobile capture itself, and the failure is connectivity. A chief engineer in a tank top at two in the morning has no signal, so capture has to work fully offline and synchronise later, with photographs. That is real engineering rather than a form. If the design assumes connectivity, evidence gets entered the next day from memory and is worth correspondingly less.

What happens when credit exposure and charter party terms are not covered?

Credit is not a report in this business, it is a control. You cannot buy from a supplier you have no line with, or beyond the exposure that supplier will carry, and a stem confirmed but not yet invoiced is already exposure even though nothing has hit payables. When the system treats the credit line as information rather than as a block, a stem gets fixed that finance then has to unpick, usually while the vessel is already inbound.

The exposure also runs the other way. A prepayment or a confirmed stem with a supplier under financial stress is a risk position your treasury team will want visible, and standard purchasing software has no concept of it. Build available line per supplier, current exposure including unbilled stems, a hard block on anything that would breach it, and counterparty exposure reporting alongside.

Charter party terms are the other uncovered gap. They decide who pays for what, who owns the fuel at redelivery and what evidence standard applies to a claim. That logic is contractual and yours, so no packaged product holds it, which means it stays in one superintendent's memory. When that person is on leave during a disputed delivery, the operator concedes ground it did not need to. Encode the bunkering terms per charter at fixture rather than at dispute, while the person who negotiated them can still explain what they meant.

Should you build custom or configure what you already own?

If you run a small fleet on regular routes, buy spot from a short list of suppliers you trust and rarely raise claims, do not build. ClearLynx covers the procurement cycle, market prices and the workflow around enquiries and stems, and BunkerMetric is strong on the optimisation question of how much to buy where given the voyage plan and price differentials between ports. Either beats email, and the optimisation gain at that scale exceeds anything a build returns.

Both are worth taking seriously, and their limit is a boundary rather than a feature gap. What they leave with you is everything touching your own vessels and contracts: remaining on board from fleet reporting, charter party terms, your claim procedure and evidence standard, your credit lines and hedging exposure. Many operators build the claims and evidence side and keep a packaged tool for buying, which is a sensible split rather than a compromise.

Build when you are stemming across many ports and suppliers, when credit lines constrain who you can buy from, when you have lost a claim in the past year because evidence arrived late, or when nobody can tell you which suppliers have historically delivered at the low end of tolerance. That last one is the clearest tell: if the answer lives in one superintendent's memory, it is not a commercial asset.

How do hidden costs get into the quote?

Offline mobile capture, first. A proposal treating the shipboard form as a screen has mispriced the project, because offline synchronisation with photographs, conflict handling and reliable timestamps is genuine engineering. Ask how the app behaves with no signal for six hours and what happens when two devices sync the same delivery.

Second, vessel reporting formats, priced per format rather than per ship. Get the count from operations before anyone quotes.

Third, laboratory integration, since each testing house reports differently and each is its own intake path. Fourth, treasury and hedging integration, a separate discipline that should carry its own budget line. Fifth, emission cost calculation, which belongs in the landed cost comparison at enquiry and in invoice reconciliation afterwards, built as configurable data with effective dates because the rules continue to develop.

The item most often missing entirely is invoice reconciliation. Recomputing what the invoice should say from delivered quantity at the corrected basis, agreed price and barging fees, then routing the difference to a dispute rather than to payables, is where much of the recovery happens, and it is assumed to be accounting's job.

What separates a build that works from one that fails here?

Design for the person on the barge, not the desk. The chief engineer has minutes, gloves, poor light and no signal, and every extra field will be left blank or guessed. Watch a real capture on a real delivery before acceptance and cut anything that is not evidence.

Second, put the clock in the system. The most common cause of an abandoned claim is nobody realising the deadline was running, so the window has to be a tracked countdown attached to the case, visible to more than one person, with escalation before it expires. If deadline tracking is not in a developer's first sketch, they have designed a document store rather than a claims system.

Third, make the evidence defensible rather than merely stored. Append only records, timestamps that cannot be back dated, photographs kept with their metadata intact, and a clear chain of custody for sample seal numbers. Those four properties are what a supplier cannot argue with, and they are cheap to build in and expensive to add later.

Fourth, capture supplier performance from day one. After a year of recorded deliveries you can see which suppliers sit at the low end of tolerance and which ports generate the most letters of protest. That history only exists if capture was structured from the first delivery.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit. This system holds the evidence base behind claims against suppliers, and that evidence may need to be produced and explained long after the original build relationship has ended.