Tank Terminal Management Software: Why Your Book Inventory and Your Gauge Never Agree

Why the tank gauge and the book inventory never agree, and why that costs you money

It is month end at an independent liquid bulk terminal. The inventory clerk is reconciling tank 14, a 5,000 cubic metre tank holding gasoil for two different storage customers. Automatic tank gauging says one figure. The sum of receipts less rack loadings from the terminal automation says another, roughly forty cubic metres apart. Somewhere in that gap sit a temperature correction that was applied at the wrong observed density, a line displacement from a product change that nobody journaled, a meter that drifted since its last proving, and a manual dip taken by a shift operator at 03:00 who rounded to the nearest centimetre. The clerk picks a number, books a loss, and allocates it across both customers pro rata. One of them will query it.

That query is the business risk. Third party storage is a custody business: the product in the tank is not yours, and every discrepancy is either a claim against you or a gift to a customer. Meanwhile the same terminal is billing throughput, storage, heating, blending, additive injection, minimum guaranteed throughput and demurrage on a tariff that was negotiated per customer and lives in a spreadsheet next to a copy of the contract. The person who understands both the reconciliation and the tariff is usually one commercial analyst, and they are the single point of failure in a business with tens of millions of litres moving through it.

Liquid bulk terminals do not break on features. They break on the fact that the physical layer, the measurement layer and the commercial layer are three different systems that only reconcile in a human head at month end.

Problem 1: nominations and tank allocation are a puzzle nobody wrote down

A customer nominates 8,000 tonnes of jet arriving on a vessel next Tuesday. Which tanks can take it? The answer depends on current heel, on the last product stored and whether that is a compatible predecessor, on whether the tank has a floating roof appropriate for the vapour pressure, on heating coils if the product needs them, on the customer's contracted capacity versus what they are actually using, and on whether the tank is due for internal inspection. Your scheduler holds most of that. The rest is on a laminated tank card in the control room.

Generic inventory software cannot represent this because it treats a tank as a bin with a quantity. A tank is a resource with a service history, a compatibility graph, a customer allocation that changes monthly, and a physical connection topology that determines which manifold and which pump can move product where. Off the shelf packages give you a tank master with attributes. What they do not give you is a nomination that fails validation on Thursday because the only compatible tank is being cleaned, before the vessel is already alongside.

Problem 2: custody transfer is measurement, not arithmetic, and generic software fakes it

Custody transfer is where terminals get sued. Volume at observed temperature is not the number anyone is billed on. You correct to standard conditions using the API Manual of Petroleum Measurement Standards volume correction factors, you decide by contract whether the transaction settles on gross standard volume, net standard volume or mass in air, you handle sediment and water, and you apply the right density source, which may be a lab certificate, an inline densitometer or a contractual fixed value. Get the wrong correction table for the product group and you are wrong by an amount that matters on a 30,000 tonne parcel.

Implico OpenTAS, Toptech and Honeywell Enraf all handle this properly, and it is exactly why they exist. The honest criticism is not that they measure badly, it is that their commercial and workflow layers assume a terminal shaped roughly like the ones they were built for. Terminals with unusual tariff structures, joint venture ownership splits, complex blending, or an in house scheduling practice end up configuring around the product and then maintaining that configuration forever. And the integration surface to your specific automation, meters and provers is a project either way.

What a custom build must include here: correction calculations implemented against the published standards with the table selection driven by product group, not hardcoded. Every quantity stored with its full provenance, meaning observed volume, temperature, density, density source, correction table used and the resulting standard volume, all immutable. A meter proving register with validity dates, so a transaction measured on an out of proof meter is flagged at the time and not discovered in an audit. And a reconciliation engine that shows the gap between gauge and book with each contributing component named, instead of one unexplained loss line.

Problem 3: the loading rack automates or it does not, there is no halfway

A truck arrives at the rack at 02:00. Driver badges in, the system checks the carrier is authorised, the driver's dangerous goods qualification is current, the vehicle compartment plan matches the order, the product is allocated to that customer's stock, and the additive recipe for that destination is loaded. Then it authorises the preset, watches the batch controller, captures the meter ticket, applies the correction, decrements the right customer's inventory and prints or emails a bill of lading before the truck leaves the gate.

Halfway automation is where terminals bleed. If the driver takes a paper order to a control room operator who keys the preset, you have a manual step in the middle of a custody transfer, at night, under time pressure, and you will find keying errors in the monthly reconciliation. The build has to reach all the way down to the terminal automation system and the batch controllers, which means real protocol work against equipment on a hazardous area site, plus a genuine offline mode. When the network drops, trucks still load. The rack cannot wait for your API.

Problem 4: throughput billing is where the margin quietly leaks

Storage terminals invoice on a tariff with more moving parts than most people outside the business 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 fees, nitrogen blanketing, line displacement, vessel and barge handling, and demurrage where the berth is contested. Each customer's contract varies these. Most terminals compute the invoice in a spreadsheet from an inventory report, which means every ambiguity is resolved in favour of whoever is quickest to argue.

A custom build models the tariff as data, not as code: rate cards versioned by effective date, tied to the contract, applied automatically to the movement events the terminal already captured. The invoice then becomes a report over facts rather than a monthly project. The direct payoff is boring and large: shortfall charges actually get raised, heating days get counted, and disputes get answered with the underlying movement records in minutes instead of days.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape for liquid bulk terminals. A first release covering nominations, tank allocation, inventory by product and customer, custody transfer calculation and reconciliation runs $120,000 to $250,000 and ships in 16 to 24 weeks. A full platform adding rack automation integration, driver and carrier management, blending, throughput and storage billing, laboratory results and regulatory reporting runs $350,000 to $900,000 phased over 9 to 18 months.

What drives the price up specifically at terminals: the number and vintage of automation systems, because integrating a modern Honeywell or Emerson setup is not the same job as integrating a twenty year old PLC with a serial link. Marine interface, since vessel and barge operations with ship and shore figure reconciliation are a distinct module from truck and rail. Rail loading, which brings its own weighbridge and car sequencing problems. Multiple terminals under one roof, because tariffs and product slates diverge per site. And hazardous area constraints, which turn what would be a simple driver tablet into a certified device conversation.

What keeps it down: start with one terminal, the truck rack, and the top ten customers by throughput. Marine and rail can wait for phase two, and by then you will know what your own data model actually needs.

Build versus buy, honestly

Buy if you are a single product terminal with a handful of tanks, one or two customers, and a rack that already works. Implico OpenTAS, Toptech and Honeywell Enraf are proven and you would be rebuilding measurement logic that is already correct in them. Buy also if you are part of a major with a group standard, because fighting that is not a software decision.

Build when at least two of these are true. You store for third parties across multiple products and the allocation and reconciliation is a person rather than a system. Your tariff has terms the packaged products cannot represent without custom code, which is common with minimum guaranteed throughput and blending arrangements. You run more than one site and want a single commercial view. You have a joint venture ownership split on tanks or throughput that must appear in reporting. Or your automation vendor has quoted you an integration project that costs more than the terminal system itself, which happens more often than vendors like to admit.

How to choose a developer for a tank terminal system

Ask them to explain, without prompting, how they would store a receipt quantity. If the answer is a number and a unit, walk. The answer you want is observed volume with temperature, observed density with its source, the correction standard applied, and the resulting standard volume and mass, all immutable with an audit trail. That single question separates people who have done custody transfer from people who have done inventory.

Ask what they have actually integrated at the automation layer, by vendor and protocol. Reading tank levels over Modbus from a gauging system is a different problem from driving a batch controller preset at a rack, and only one of them is safety adjacent. Ask how the rack behaves when their software is unavailable, and if they have not thought about offline loading and later reconciliation, they have not worked on a terminal.

Ask how they will handle a meter that fails proving retrospectively, because the commercial question of which transactions to restate is a design decision, not an afterthought. Then get ownership in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in any other supplier. At Digital Heroes the client owns the code from the first commit, and on a system that computes the numbers you invoice on, owning it is not optional.