Tank Terminal Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the custody transfer scope failure happen so often?

Because inventory software is a solved category and terminals look like inventory. A developer with warehouse or enterprise resource planning (ERP) experience models a tank as a bin with a quantity, receipts as increments, loadings as decrements, and produces something that demonstrates beautifully. It is wrong in a way that only shows up commercially.

Volume at observed temperature is not the number anyone is billed on. You correct to standard conditions using the volume correction factors in the American Petroleum Institute Manual of Petroleum Measurement Standards, the contract decides whether settlement is on gross standard volume, net standard volume or mass in air, sediment and water get handled accordingly, and the density source may be a laboratory certificate, an inline densitometer or a contractual fixed value depending on the arrangement. Select the wrong correction table for the product group and you are wrong by an amount that matters on a thirty thousand tonne parcel.

The fix is a single question you can ask on the first call. Ask the developer to explain, without prompting, how they would store a receipt quantity. If the answer is a number and a unit, walk. If the answer is observed volume, temperature, density with its source, the standard applied and the derived results, all immutable with an audit trail, they have done custody transfer rather than inventory. Then insist that table selection is driven by product group as configuration rather than hardcoded, because your product slate will change and a code release should not be the mechanism.

What goes wrong when you migrate tank, meter and movement history?

The tank master is the easy part. What breaks the plan is that the operational knowledge which makes a tank usable is not in any system.

Which tanks can take a nominated parcel depends on the current heel, on the last product stored and whether it is a compatible predecessor, on roof type against vapour pressure, on heating coils where the product needs them, on the customer's contracted capacity against what they are actually using, and on whether the tank is due for internal inspection. Most of that lives on a laminated card in the control room and in the scheduler's head. Migration surfaces it for the first time, and reconciling the card against the tank master is a genuine discovery exercise rather than a data load.

Meter history is the second trap. Proving records commonly sit in a maintenance system as documents rather than as validity periods, so there is no structured record of which transactions were measured on an in proof meter. Import movements without that and you have a history you cannot defend.

The fix is to model the tank as a resource with a service history, a compatibility relationship and a connection topology that determines which manifold and which pump can move product where, and to model the meter with a proving register carrying validity dates. Then migrate the operational attributes deliberately, with the scheduler and the terminal manager in the room, because they are the only two people who know what the laminated card actually means.

Why do the automation and metering integrations break after launch?

Because reading and driving are different jobs, and only one of them is safety adjacent.

Pulling tank levels from a gauging system over a serial or network protocol is a read. Driving a batch controller preset at a loading rack is a command issued to equipment that moves hazardous product, and the failure behaviours you have to design for are entirely different. Quotes routinely price both as integration. Ask specifically which vendors, which models and which transports the team has driven on a live site, and treat a vague answer as a no.

The vintage problem is the second one. A terminal assembled over decades carries a modern setup alongside a twenty year old programmable logic controller on a serial link, and the second one is not the same job as the first. Register maps as documented by the vendor and register maps as implemented in a specific firmware version are not always the same document, which is why a lab unit and a site validation belong in the plan rather than in the optimism.

The third is availability. If the rack depends on your software being reachable, you have built a system that stops trucks at 02:00 when a network link drops. That is not a support incident, it is a design failure.

The fix is to require offline loading with later reconciliation as a stated requirement, to budget a lab unit and a commissioning window per controller family, and to accept that site access and commissioning windows around a terminal that never stops are usually the real schedule risk rather than the code.

What happens when proving, tariff terms and ownership splits are not covered?

Three separate exposures, and each one arrives as a dispute rather than as a bug report.

Proving first. When a meter fails proving, the commercial question is which already billed transactions to restate, and that is a design decision rather than a support incident. Without a proving register with validity periods, out of proof transactions are not flagged as they happen, they are discovered during an audit after the affected volumes have been invoiced and consumed. Decide the restatement policy and the approval path for credits and rebills before go live.

Tariff terms second. Storage terminals invoice on more moving parts than outsiders expect: storage per cubic metre per month on contracted capacity, throughput per tonne with tiered rates, minimum guaranteed throughput with a shortfall charge, heating charges by day and temperature band, blending and additisation, nitrogen blanketing, line displacement, vessel and barge handling, and demurrage where the berth is contested. When these are computed in a spreadsheet from an inventory report, every ambiguity resolves in favour of whoever argues fastest, shortfall charges quietly go unraised and heating days go uncounted.

Ownership splits third. If tanks or throughput carry a joint venture ownership arrangement, that has to appear in reporting from the data model outward. It cannot be added as a reporting layer later without recomputing history.

The fix is to model the tariff as versioned data tied to the contract, with effective dated rate cards applied automatically to movement events the terminal already captured, so the invoice becomes a report over facts rather than a monthly project. Then disputes get answered from underlying records in minutes.

Should you build custom or configure what you already own?

Buying is the right answer more often than vendors of custom software like to admit, and this is one of the categories where it is clearest.

If you run a single product terminal with a handful of tanks, one or two customers and a rack that already works, buy. Implico OpenTAS, Toptech and Honeywell Enraf implement custody transfer measurement properly, which is exactly why they exist, and rebuilding correction logic that is already correct in a proven product is wasted capital. If you are part of a major with a group standard, that is not a software decision and fighting it is not a good use of your year.

Configuring properly is also underused. Many terminals have never structured their tariffs inside the product they own, never converted the laminated tank card into tank master attributes, and never turned proving records into validity periods. Those three pieces of work sit inside your existing licence and would remove a large share of the pain described above.

Build when at least two hold. You store for third parties across multiple products and the allocation and reconciliation is a person rather than a system, which makes that person a single point of failure in a business moving tens of millions of litres. Your tariff has terms the packaged products can only represent through custom configuration, which is common with minimum guaranteed throughput and blending arrangements. You run more than one site and want one commercial view. A joint venture ownership split has to appear in reporting. Or your automation vendor has quoted an integration project costing more than the terminal system itself, which happens more often than vendors like to admit.

How do hidden costs get into the quote?

Five places, all of them physical rather than logical.

First, the number and vintage of automation systems. Integrating a modern setup is not the same job as integrating a twenty year old controller on a serial link, and "integrate with your automation" as one line has priced the easy one.

Second, marine interface. Vessel and barge operations with ship and shore figure reconciliation are a distinct module from truck and rail, with their own documentation and their own disputes, and they get folded into scope by assumption.

Third, rail loading, which brings weighbridge integration and car sequencing problems that share very little with the truck rack.

Fourth, hazardous area constraints. What looks like a driver tablet becomes a certified device conversation the moment it has to operate in a classified zone, and that changes both hardware cost and the options available.

Fifth, multiple terminals under one roof, where tariffs and product slates diverge per site so the configuration surface multiplies rather than adds. Then budget the commissioning windows honestly, because factory acceptance testing against equipment you cannot take out of service for convenience is a schedule cost even when it is not an invoice line.

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

Scope discipline at the start. In Digital Heroes delivery experience the builds that work take one terminal, the truck rack and the top ten customers by throughput, deliver nominations, tank allocation, inventory by product and customer, custody transfer calculation and reconciliation in 16 to 24 weeks, and leave marine and rail for phase two. By the time phase two starts you know what your own data model actually needs, which you do not know on day one no matter how thorough the workshops were.

The second differentiator is whether reconciliation decomposes the gap. A system that reports a single unexplained loss line has not helped anyone. A system that names the contributors, meaning line displacement from a product change, temperature effects, meter uncertainty since last proving, and an unjournaled movement, tells you whether you have a measurement problem or a product problem, and those have completely different remedies.

The third is a question worth asking before you sign: what happens if a meter fails proving retrospectively. If the answer is that support would investigate, the restatement policy does not exist and you will be inventing it under commercial pressure.

Last, settle ownership in writing before kickoff. You should hold the repository, the cloud and on premise infrastructure accounts, and the right to bring in any other supplier. On a system that computes the quantities you invoice on and sits against safety adjacent automation, a supplier holding the source is an operational risk rather than a commercial inconvenience.