Multipurpose Terminals — A Terminal Operating System for general cargo and breakbulk

01

Part A — Framing

Which terminals this is about

Terminals handling cargo that does not fit a single standard — through the same gate, the same yard and the same invoice.

These flows share one defining characteristic: the unit of cargo is not interchangeable. A coil is not a coil. A bundle of long steel is identified by the marks chalked onto it during discharge. A transformer has its own lifting plan.

If your terminal handles more than one of these flows on one site, this is written for you.

Container terminal systems solve a real problem, and solve it well: identical units, known events, and value created by minimising and sequencing moves. Planning algorithms are the right evaluation criterion there.

Multipurpose terminals are run on that software, or on something adapted from it. The result is familiar. The TOS handles part of the operation. Spreadsheets handle what it cannot. A separate warehouse system handles the sheds. Billing is reconstructed after the fact from operational records that were never designed to support it. Nobody can answer, per shipment, what it cost and what it earned.

This is a systems problem, not a discipline problem. No amount of process rigour closes a gap the software was never designed to cover.

One of the largest breakbulk terminals in Europe

In production. Steel, project and heavy-lift cargo, forest products, general breakbulk and containers within mixed operations. Seaside, yard, warehouse and billing on one platform. A second multipurpose terminal implementation, covering RoRo, warehousing and complex billing, is in preparation.

The logistics arm of one of Europe's largest steel producers

Profit and loss per logistic unit. Selected locally on operational merit, subsequently validated at group level.

A European intermodal operator with a large owned equipment fleet

Equipment and spare-parts management in production, integrated with operational execution and cost accounting.

A European heavy-lift and machinery logistics operator

After the initial implementation, this customer's own IT organisation deployed the platform at a new site in the United States independently.

Alongside these, the platform runs at shipping lines, intermodal carriers, freight forwarders and shippers. Section 09 names them and sets out what each one proves.

02

Part A — Framing

The problem, stated precisely

Five structural conditions of the trade. Each one breaks a specific assumption that standard terminal software is built on.

Cargo that resists identification

A container has a number that is unique, standardised worldwide and printed on four sides. A bundle of reinforcing bar does not. Neither does one coil in a shipment of four hundred nominally identical coils.

Marks and numbers. The identification written on the cargo itself, chalked on during discharge, matching the bill of lading. For long steel this is often the only workable method — printed labels do not survive weeks of open storage in the rain.
Terminal-applied labelling. For cargo that will be stored under cover and moved by scanner, the terminal generates and applies its own identification at receipt.
List-based tally. An expected cargo list printed from the system, one barcode per line, ticked on the quay and scanned back afterwards.

A system that supports only barcode scanning cannot run a breakbulk quay. A system that supports only manual entry cannot run a warehouse efficiently. Both are needed, selectable per cargo type.

No standard for what is coming

Container terminals receive a structured stowage message. Multipurpose terminals receive whatever the agent sends: EDI from one line, a spreadsheet from another, a PDF manifest from a third, sometimes a phone call followed by paperwork.

This is not a temporary state of affairs awaiting standardisation. It is the structural condition of a fragmented trade with thousands of counterparties and no dominant standard-setter. A system that requires structured EDI to function will be bypassed within a month.

Every shipment carries its own paperwork

Warehouse and terminal receipts. Delivery orders. Release notes. Gate passes. Hatch lists. Heavy-lift lists. Long-length lists. Measurement certificates. Loading permits. Pre-stowage plans. Stuffing instructions. Shift reports. Damage reports. Customs declarations. Dangerous goods documentation.

Each has a specific recipient, a specific moment, and legal or commercial consequences if it is wrong or late. In many terminals a significant share of administrative headcount exists to produce these documents from data the operational system already holds but cannot format.

Pricing that no standard billing engine survives

Handling per tonne, per unit, per operation, per lift above a weight threshold. Storage per day, per week, per month, with free periods that differ per customer and pro-rata calculation on the day of departure.

Add surcharges for out-of-gauge, for heavy lift, for weekend shifts, for dangerous goods. Value-added services priced per activity. Contracts renegotiated annually, with different effective dates per customer.

Terminals that cannot compute this inside their operational system compute it outside it — in spreadsheets, from exported movement data, weeks after the fact. Revenue leakage in these environments is not an anomaly. It is the expected outcome.

The operation splits into islands

Most multipurpose terminals run four to six systems: a TOS for the quay and yard, a warehouse system for the sheds, a separate tool for RoRo, spreadsheets for value-added services, a financial system that receives operational data as a monthly file, and a maintenance system for equipment — if there is one at all.

Each system holds a partial truth. None holds the shipment.

03

Part A — Framing

What the gap costs

It is rarely visible as a line item. It appears in five places, none of which show up in a software comparison.

Administrative headcount that scales with volume

In a well-designed system, doubling throughput does not double the administrative team. Where documentation is produced by hand from data held elsewhere, it does.

Revenue that is never invoiced

Every operation executed but not captured, every surcharge that applies but is not applied, every storage day counted from the wrong date. Individually small, collectively material.

Decisions made without cost visibility

If the operational system does not know the tariff and the financial system does not know the operation, nobody knows the margin on a shipment until long after it has left.

Integration and maintenance of the estate itself

Four to six systems means interfaces to build, maintain and repair whenever any one of them is upgraded. This cost is permanent and grows with each addition.

Dependence on individuals

Where a system does not hold the process, people do. In a market with structural shortages of experienced terminal administrators, this is the risk that keeps operations directors awake.

Terminals that migrate handling and storage billing into their operational system routinely find a recoverable percentage they had not budgeted for. It is the fastest of the five to quantify, because it can be tested against last year's own movement data.

None of these appear in a software comparison. All of them appear in the P&L.

04

Part B — The rules of the game

Twelve criteria for a multipurpose TOS

Written to be usable whichever vendor you select, and to be filled in against your own operation rather than against a vendor's answer sheet. Open any criterion for what it means in practice.

Before evaluating vendors, it is worth being explicit about what problem you are buying a solution to. In container handling, the binding constraint is movement optimisation: units are identical and interchangeable, so value is created by minimising and sequencing moves.

In multipurpose operations, the binding constraint is identification and administration, not optimisation. Every unit is different. There is no standard message telling you what is arriving. The margin is lost between the quay and the invoice — in cargo that cannot be matched, allocations that must be made by hand, documents that must be retyped, and operations that are executed but never billed.

A system that optimises brilliantly but registers poorly is solving the wrong problem. The criteria below follow from that.

Multiple identification methods, selectable per cargo type: marks and numbers, terminal-applied labelling, list-based tally, barcode scanning.
Multiple units of measure per shipment — pieces, bundles, coils, lots, tonnes, cubic metres, running metres — with the billing unit potentially different from the tally unit.
Multiple capture channels for the same operation: handheld scanner, tablet on the quay, desk entry after the shift.
Structured capture of short-landed, over-landed and damaged units, with photographic evidence, at the moment of discovery.

Manifest intake through structured EDI where the counterparty supports it, and through spreadsheet import where it does not — as a first-class path, not a workaround.
Import mapping configurable per counterparty without development work.
The ability to begin operations on incomplete cargo data and reconcile afterwards.

This is where most systems built for standardised cargo fail outright

Matching outbound instructions against available stock on attributes rather than identifiers: marks and numbers, dimensions, weights, grades, mill order, batch.
Automatic allocation where the criteria resolve; manual search and assignment where they do not.
Reallocation and deallocation without unwinding the operation.

One data model covering rolling cargo, containers and non-standardised piece cargo — not three systems with interfaces between them.
Sea, road, rail and inland waterway on the same shipment structure.
Direct transfer flows — vessel to barge, vessel to truck, without intermediate storage — as a supported workflow rather than an exception handled manually.

Open yard, covered warehouse and specialised storage in one location hierarchy.
Segregation rules — import versus export, customer, customs status, dangerous goods classification — enforced by the system.
Block and undefined-area locations for cargo that cannot be assigned a discrete slot.

Repacking, lashing and securing, stenciling and labelling, container stuffing and stripping, cutting, repair, inspection, kitting and pre-assembly.

Ordered, planned, executed and billed inside the same system.
Inventory transformation: the ability for goods to change form or identity through processing while retaining traceability.

Gate in and out with document verification, position assignment and pass generation.
Camera and weighbridge integration.
Blocking on customs status, agent release, or outstanding documentation.

Terminal-specific documents generated from operational data at a single action: hatch lists, heavy-lift lists, long-length lists, measurement certificates, loading permits, warehouse receipts, delivery orders, gate passes.
Direct distribution to counterparties, not merely to a printer.
Inbound documents attachable to the shipment and forwardable as evidence with the invoice.

Contract and tariff structures capable of expressing per-customer, per-commodity, per-terminal rules with annual versioning.
Every operation captured as a billable transaction at the moment it occurs.
Storage computed from daily inventory positions, with per-customer free periods and pro-rata rules.
Billing cycles that differ per customer and per service type.
Margin visible per shipment, per customer, per flow.

Rarely evaluated, consistently painful

Equipment register with maintenance history and availability status.
Spare-parts inventory, purchasing, and issue against work orders.
Cost attribution per asset.

Cargo types, tally methods, documents, workflows, pricing rules and screen layouts configurable per terminal, per customer, per commodity.
Configuration that survives version upgrades.

Multi-terminal, multi-entity, multi-currency, multi-language on one instance.
Deployment options including in-region hosting where data residency requires it.
Rollout model that does not require the vendor's presence at every site.

05

Part C — The platform

The architecture, in one picture

Three layers on one data model. The financial backbone is not a module bolted on top — it is the layer the operational engines sit on.

Configuration across all three layers · Integration around all three · One record from vessel to gate

Three flows run through a terminal simultaneously: the goods, the information about the goods, and the money the goods generate. In most terminal landscapes these three live in different systems, and the work of reconciling them is done by people.

When a coil is discharged, that single event is an operational fact, a documentary obligation and a billable transaction at the same time. A platform in which all three are the same record does not need reconciliation. That is the whole architectural argument, and everything on this page follows from it.

The financial backbone

Customers, contracts, tariffs, transactions, invoices and cost. Not a billing module bolted onto an operational system; the layer the operational layers sit on. Every operation registered anywhere in the platform resolves against it.

The operational engines

Terminal operations, warehouse management and transport management. Not separate products with interfaces between them, but engines running on the same cargo, the same locations, the same parties and the same contracts — which is why a shipment can move from a vessel, through a shed, through a value-added service, onto a truck, and stay one record throughout.

The execution applications

Scanners on the quay, tablets in the yard, mobile screens in a tugmaster cab, desk screens in the office, and portals for your customers. Each writes into the same model as it happens.

Configuration across all three

Cargo types, workflows, screens, documents, pricing rules and integration mappings are configuration rather than code. Section 11 sets out what this means in practice.

Integration around all three

Counterparty messaging in whatever form it arrives, enterprise systems, operational hardware, customs and port community systems. Section 08 sets out the mechanics.

06

Part C — The platform

Ten operational domains

Open a domain for the operational reality and what it delivers. Open it further for the mechanism, and further still for statement-level scope.

The operational reality

On a long steel discharge, identification is chalked onto the bundles during the operation and matched against the marks and numbers on the bill of lading. Tally happens differently per commodity and per customer: scanned on the quay for labelled goods, ticked against a printed list for others, entered at a desk after the shift for the rest.

Discrepancies are normal, not exceptional. Units are short-landed, over-landed or damaged, and each must be recorded with evidence at the moment it is found, because the claim is settled months later on the strength of that record. And the entire operation is billable: hours per gang, per hatch, per shift; tonnages; operations performed.

What it delivers

One record of the vessel call, from cargo list to loading confirmation, without parallel spreadsheets.
Discrepancy and damage evidence captured at the moment of discovery, defensible months later.
Documentation produced from operational data rather than retyped from it.
Handling revenue captured as the operation happens, including gang hours and activities, and billed without reconstruction.
Export allocation on cargo attributes, automatic where the data allows and manual where it does not.

Voyage and cargo intake

Each vessel call is registered as a voyage with its stops, its schedule and its cargo. The cargo list is taken in through structured EDI where the counterparty supports it, and through spreadsheet import where it does not — mapping configured per counterparty. Both paths are standard; neither is a workaround.

Identification per cargo type

Marks and numbers for cargo that cannot carry a durable label. Terminal-generated labels applied at receipt for goods moving into covered storage. Printed expected-cargo lists with one barcode per line, ticked on the quay and scanned back. Which method applies is configuration, set per commodity and per customer.

Tally on the device that suits the operation

Handheld scanner, tablet at the quayside, or desk entry after the shift. Facts, figures and damages are captured through the same structures regardless of channel. Short-landed, over-landed and damaged units are recorded with their evidence at the point of discovery.

Execution registered per hatch and per gang

What was performed, by which gang, in which shift, against which hatch — the operational truth of the call, in the structure the terminal actually works in.

Gangs, shifts and hours

Gangs and shifts are created in the system and hours worked are recorded against them, producing the shift report — who worked, on what, for how long, at what productivity, on which commodities. The same data flows through to billing without re-entry.

Export allocation on cargo attributes

Loading permits are received, frequently electronically, and imported. Stock is allocated against them automatically by matching on marks and numbers, lengths and weights. Where the criteria do not resolve, the operator searches the stock manually. This dynamic, multi-criteria allocation is the single capability most often absent from systems designed for containers.

Direct transfers as a workflow

Barge to vessel, vessel to truck and comparable movements without intermediate storage are supported as defined workflows rather than as manual exceptions.

Documents at one action

Hatch lists, heavy-lift lists, long-length lists and measurement certificates are generated from operational data at a single action and sent directly to the relevant parties. Inbound documents attach to the shipment by drag and drop and can be forwarded as evidence with the invoice.

Dimensions and weights where the operation allows

Capture points for measurement and weighing are configurable — quay, warehouse or gate — because terminals differ in where this can practically be done.

A vessel call is registered as a voyage carrying its stops, schedule and cargo, and remains the reference for everything that happens against it.
Expected cargo is taken in through structured electronic messaging where the counterparty supports it, and through spreadsheet import where it does not, with each counterparty's format held as configuration.
Cargo is identified by the method the cargo permits — marks and numbers, terminal-generated labels, a printed expected-cargo list with one barcode per line, or direct scanning — applied per commodity and per customer.
Tally is captured on handheld scanner, quayside tablet or desk entry, through the same structures regardless of channel.
Short-landed, over-landed and damaged units are recorded with supporting evidence at the moment of discovery, in a form that supports a claim settled months later.
Execution is registered per hatch and per gang.
Gangs and shifts are created in the platform and hours worked recorded against them, producing a shift report covering who worked, on what, for how long, at what productivity and on which commodities.
Loading permits are received and imported, and stock is allocated against them by matching on cargo attributes, with manual search where criteria do not resolve.
Direct transfer flows, including barge to vessel and vessel to truck without intermediate storage, are supported as defined workflows.
Terminal documents are generated from operational data at a single action and sent directly to the parties concerned.
The points at which dimensions and weights are captured are configurable.

The operational reality

A coil park, a laydown area for project cargo, a covered shed for forest products and an open area for long steel are four different storage logics on one terminal.

Segregation is not optional. Import must stay separate from export. Customs-controlled cargo must stay separate from cleared cargo. Some customers require their cargo physically apart from everyone else's. Getting this wrong is a compliance failure, not an inefficiency.

And the yard drifts. Units get moved without registration, positions become wrong, and the difference between what the system says and what is on the ground grows quietly until someone cannot find a shipment on the day it must load.

What it delivers

One storage record covering shed and open yard, without a separate warehouse system for the covered part.
Segregation rules that hold because the system enforces them.
A yard position record that stays accurate through structured verification rather than periodic full inventories.
Space utilisation that can be measured and acted on.

One location hierarchy across all storage types

Open yard, covered warehouse, specialised and customs-controlled areas sit in the same structure, with capacity, availability status and storage rules defined per location.

Block and undefined-area locations

Cargo that cannot be assigned a discrete slot — long steel in a stacking area, project cargo on a laydown — is registered to a block rather than forced into a location model that does not fit it.

Segregation enforced by the system

Import and export separation, customer segregation, customs status and dangerous goods classification are enforced as location rules rather than left to operator memory.

Position registration on the device doing the work

Positions are recorded at the moment of the move, from the scanner or tablet carried by the operator performing it.

Daily position verification

A structured stock check compares registered positions against physical reality, identifies discrepancies and drives correction. This is the mechanism that stops yard drift, and in practice it is the difference between a yard record that is trusted and one that is not.

Internal relocations and consolidation

Relocation tasks are created, dispatched and executed against a work instruction — whether for space recovery, consolidating a customer's cargo, or making a shipment accessible for loading.

Real-time yard view

A live visual representation of occupation, availability and cargo in position.

Open yard, covered warehouse, specialised and customs-controlled storage sit in one location hierarchy with capacity, availability and storage rules per location.
Cargo that cannot be assigned a discrete slot is registered against a block or an undefined area.
Segregation is enforced by the system: import against export, customer against customer, customs status, and dangerous goods classification.
Positions are registered at the moment of the move, from the device carried by the operator performing it.
A structured daily position verification compares registered positions against physical reality, identifies discrepancies and drives their correction.
Relocation and consolidation movements are created, dispatched and executed as tasks.
Occupation, availability and cargo in position are visible in a live view.
Storage utilisation is measurable per area, per customer and per period.

The operational reality

A trailer arrives on its own wheels or on a cassette. It has a destination, a weight class, and a deck it can or cannot go on. It may carry a container, and that container has its own identity and its own onward journey.

The equipment used to move it — tugmasters, cassettes, MAFI trailers, trestles — is itself tracked, because a cassette in the wrong place is a unit that cannot be loaded. Discharge and load happen fast, in a marshalling area, with drivers working from a screen in a cab rather than a desk. If the system is not on that screen, it is not in the operation.

What it delivers

Rolling cargo, containers and piece cargo in one system rather than a separate RoRo tool alongside the TOS.
Terminal equipment — cassettes, MAFIs, trestles — visible and locatable.
Instructions on the device in the cab, and confirmations back from it.
Handling of rolling cargo captured as billable transactions like every other operation.

Unit-level registration across rolling cargo types

Trailers, cassettes, MAFI trailers, containers on cassettes and self-propelled units are registered as units with their attributes, destination and status.

Deck assignment and load planning

Units are assigned to decks with weight distribution taken into account, and the loading sequence is planned and released for execution.

Unit type segregation

Discharge planning segregates by unit type and destination, with yard positions pre-assigned before the vessel arrives.

Container-to-cassette and container-to-MAFI operations

The relationship between a container and the equipment carrying it is maintained as a tracked association, not inferred.

Equipment tracking

Cassettes, MAFI trailers and trestles are tracked as identified assets with location and status. Trestle indication is available to the operator on the device at the point of use.

Tugmaster mobile interface

Drivers receive and confirm tasks on a mobile device in the cab, including login with safety procedures, task assignment, position recording and real-time communication with the control room.

Shunting as a managed task

Repositioning moves are created, dispatched and confirmed rather than executed informally.

Vehicle registration

Individual vehicles are registered by chassis number where the terminal handles automotive cargo, with scanning support at the gate and in the yard.

Multi-destination handling

Units bound for different destinations within the same operation are assigned and filtered accordingly, including on the driver's device.

Trailers, cassettes, MAFI trailers, containers carried on equipment and self-propelled units are registered as units with their attributes, destination and status.
Units are assigned to decks with weight distribution taken into account, and the loading sequence is planned and released for execution.
Discharge planning segregates by unit type and destination, with yard positions pre-assigned ahead of arrival.
The association between a container and the cassette or MAFI carrying it is maintained as a tracked relationship.
Cassettes, MAFI trailers and trestles are tracked as identified equipment with location and status, and trestle information is available at the point of use.
Drivers receive, execute and confirm tasks on a mobile device in the cab, including login with safety procedures, position recording and communication with the control room.
Repositioning and shunting movements are managed as dispatched tasks.
Individual vehicles are registered by chassis number where the terminal handles automotive cargo.
Units bound for different destinations within one operation are assigned and filtered accordingly, including on the driver's device.

The operational reality

Goods arrive against a pre-advice that may be incomplete, and leave against an instruction that arrives days or weeks later. Quality status matters commercially: a unit under inspection, on hold for the customer, or blocked for dispatch cannot be allocated, and the reason must be traceable.

And every movement inside the warehouse is either billable or a cost — which means it has to be registered whether or not the operator sees the point.

What it delivers

Warehouse and yard on one platform, one stock record, one set of customer reporting.
Stock visible from announcement rather than from arrival.
Every warehouse movement registered as a billable transaction at the moment it happens.
Holds and quality status that actually prevent the wrong unit from leaving.

Pre-advice and virtual stock

Expected goods are registered from the counterparty's announcement — structured message or spreadsheet — creating virtual stock that is visible, allocatable and reportable before the goods physically arrive, then converted to physical stock at receipt.

Receiving against expectation

Goods are received by scanner, tablet or desk entry, matched against the pre-advice, with discrepancies flagged at the point of receipt.

Putaway logic driven by configuration

Location assignment follows configured rules — grouping by order or batch, first available location, or operator decision — with manual override always available.

Unit-level inventory

Stock is tracked at the level the cargo requires: individual unit, batch, order or lot, with attributes rather than only identifiers.

Quality and dispatch status

Units carry quality status, and holds — inspection, customer evaluation, dispatch block — prevent allocation until resolved.

Internal relocation and consolidation

Movements for space recovery or consolidating a customer's stock are created and executed as tasks, and captured as billable transactions where the contract provides for it.

Allocation and picking

Outbound instructions are allocated against available stock on cargo attributes, and pick tasks are executed on device with validation and exception handling.

Substitution

Where an equivalent unit is more accessible than the allocated one, controlled substitution is supported with compatibility checking and a full audit trail — a small function that removes a large amount of daily friction.

Reversal flows

Unpicking, unshipping and reallocation are supported as defined operations, because in terminal warehousing plans change after execution has started more often than not.

Cross-dock

Direct transfer from inbound to outbound without putaway, with staging area management.

Inventory reconciliation

Daily inventory positions are captured, forming both the operational stock record and the basis for storage billing.

Expected goods are registered from the counterparty's announcement, creating stock that is visible, allocatable and reportable before physical arrival, and converted at receipt.
Goods are received by scanner, tablet or desk entry, matched against the announcement, with discrepancies flagged at the point of receipt.
Location assignment on putaway follows configured rules, with manual override available throughout.
Stock is tracked at the level the cargo requires: individual unit, batch, order or lot, carrying attributes rather than only identifiers.
Units carry quality and dispatch status, and holds prevent allocation until they are resolved.
Internal relocations and consolidation are executed as tasks and captured as billable transactions where the contract provides for it.
Outbound instructions are allocated against available stock on cargo attributes, and pick tasks are executed on device with validation and exception handling.
Controlled substitution of an equivalent, more accessible unit is supported with compatibility checking and a full audit trail.
Unpicking, unshipping and reallocation are supported as defined operations after execution has begun.
Cross-dock from inbound to outbound without putaway is supported, including staging area management.
Daily inventory positions are captured, forming both the operational stock record and the basis for storage billing.

The operational reality

Between discharge and load, a terminal repacks, lashes, secures, stencils, labels, cuts, repairs, inspects, kits and pre-assembles. It stuffs containers and strips them. It surveys cargo and documents damage. For project cargo it may hold components for weeks while a customer assembles a shipment, then release them against an engineering schedule.

Each of these is an ordered service, performed on identified goods, at an agreed price.

What it delivers

Value-added revenue billed in full, because it is captured where it is performed.
Traceability through processing, which is the prerequisite for handling forest products, steel and project cargo credibly.
The commercial ability to sell services confidently, because their cost and margin are visible.
Project cargo held, processed and released against a customer's schedule rather than a terminal's storage clock.

Service orders against stock

A value-added service is created as an order referencing specific units in specific locations, with the activity, the instruction and the agreed price attached.

Execution registered on device

The operator confirms performance against the order, at the point of work, with time and quantity captured.

Inventory transformation

Where processing changes the goods — cutting a reel, splitting a lot, repacking, kitting several units into one — the system records the transformation, retiring the input and creating the output while retaining traceability to origin. This distinguishes a system that supports processing from one that merely records that processing happened.

Container stuffing and stripping

Stuffing is executed against the stock allocated to it, with weight and capacity control, and the resulting container becomes a tracked unit in its own right.

Repair and quality workflows

Damaged units are flagged, routed to repair, and returned to available stock or written off, with the record supporting the claim.

Documentation and evidence

Service documentation, inspection records and photographic evidence attach to the goods and are available to send to the customer or with the invoice.

Billing without a hand-off

Every service performed generates its billable transaction at the moment of execution, priced from the customer's contract. There is no separate list, and no month-end reconstruction.

A value-added service is created as an order referencing specific units in specific locations, carrying the activity, the instruction and the agreed price.
Execution is confirmed at the point of work, with time and quantity captured.
Where processing changes the goods, the transformation is recorded, retiring the input and creating the output while retaining traceability to origin.
Container stuffing and stripping are executed against allocated stock with weight and capacity control, and the resulting container becomes a tracked unit in its own right.
Damaged units are flagged, routed to repair, and returned to available stock or written off, with a record that supports the claim.
Service documentation, inspection records and photographic evidence attach to the goods and can be sent to the customer or with the invoice.
Every service performed generates its billable transaction at execution, priced from the customer's contract.

The operational reality

Drivers arrive with the wrong paperwork, for cargo that is not released, at times that do not match the plan. Rail wagons and barges arrive on their own logic.

Every one of those arrivals is a decision: is this cargo released, is customs satisfied, is the document present, where does this vehicle go, and what has to be printed before it leaves.

What it delivers

Cargo that cannot leave without authorisation, enforced by the system rather than by the person at the window.
One consignment structure across road, rail and inland waterway.
Gate throughput that can be measured, and waiting time that can be charged where the contract allows.
Landside operations captured as billable transactions in the same stream as everything else.

Gate in and gate out with verification

Arrivals are registered and checked against the expected consignment, the release status and the documentation requirement before a position is assigned.

Blocking that holds

Customs blocks, agent release blocks, outstanding documentation and dangerous goods limitations prevent gate-out until resolved. The block is a system state, not a note.

Position assignment and dock pass

The driver receives an assigned position and a printed or electronic pass directing them where to go.

Camera and weighbridge integration

Registration plate and identification capture and weighing integrate into the gate transaction rather than running alongside it.

Time slot booking

Where the terminal operates appointments, slots are booked, matched at arrival, and deviations recorded.

Waiting time measurement

Time between arrival and departure is measured, supporting both operational improvement and, where contracts provide for it, demurrage.

Rail and barge as first-class modes

Wagon and barge loading and discharge follow the same consignment structure as road, with their own document flows. Direct transfer between modes without intermediate storage is a supported workflow.

Documents at the gate

Gate passes, delivery notes, consignment notes and loading lists are generated from the transaction.

Arrivals are registered and checked against the expected consignment, its release status and its documentation requirement before a position is assigned.
Customs blocks, agent release blocks, outstanding documentation and dangerous goods limitations prevent gate-out until resolved, as enforced system states.
Drivers receive an assigned position and a printed or electronic pass directing them.
Registration plate capture, identification and weighing integrate into the gate transaction.
Where the terminal operates appointments, slots are booked, matched at arrival, and deviations recorded.
Time between arrival and departure is measured, supporting operational improvement and, where the contract provides for it, charging.
Wagon and barge loading and discharge follow the same consignment structure as road, with their own document flows.
Transfer between modes without intermediate storage is supported as a workflow.
Gate passes, delivery notes, consignment notes and loading lists are generated from the transaction.

The operational reality

A terminal receipt establishes custody. A delivery order authorises release. A release note and gate pass govern who may take the cargo. Customs status determines whether it may move at all. Dangerous goods classification determines where it may be stored and what must be declared. A missing original document can be the reason an invoice cannot be sent.

What it delivers

Documentation produced from operational data rather than retyped from it.
Release that cannot happen without the required authorisation.
An audit trail that stands up in a claim, months later.
Compliance rules configured per terminal rather than assumed to be universal.

One consignment as the spine

Every shipment is a consignment carrying its type — import, export, direct transfer, stuffing, return, administrative — its parties, its commercial references, its contract, its documents and its cargo. Everything else attaches to it.

Document requirements as a state

A consignment carries which documents are required and whether the original is needed. Missing documentation can block billing automatically — a small mechanism that removes a large category of dispute.

Generation and distribution

Terminal receipts, delivery orders, release notes, gate passes, hatch lists, heavy-lift lists, long-length lists, measurement certificates and loading permits are generated from operational data at a single action and sent directly to the parties concerned.

Inbound documents attached

Documents received from counterparties are attached to the consignment by drag and drop and can be forwarded as supporting evidence with the invoice.

Customs status as a control

Customs-controlled cargo is segregated in storage and blocked from release until status permits, with integration to national systems and port community systems where these exist.

Dangerous goods

Cargo classification is registered and drives storage restrictions, segregation rules, quantity limitations and documentation. The rule set is configurable per terminal, since the applicable restrictions are set by local authority as much as by international convention.

Weight verification

Verified gross mass is captured and carried where the flow requires it.

Audit trail

Who did what, when, on which unit, on which device.

Every shipment is a consignment carrying its type, its parties, its commercial references, its contract, its documents and its cargo; everything else attaches to it.
A consignment carries which documents are required and whether an original is needed, and missing documentation can block billing automatically.
Terminal receipts, delivery orders, release notes, gate passes and terminal-specific operational documents are generated from operational data at a single action and sent directly to the parties concerned.
Documents received from counterparties are attached to the consignment and can be forwarded as supporting evidence with the invoice.
Customs-controlled cargo is segregated in storage and blocked from release until its status permits, with integration to national and port community systems where these exist.
Dangerous goods classification is registered and drives storage restrictions, segregation, quantity limitations and documentation, with the rule set configurable per terminal.
Verified gross mass is captured and carried where the flow requires it.
Operational and administrative actions are logged with user, time, device and record.

The operational reality

Handling is priced per tonne, per unit, per operation, per lift above a weight threshold. Storage is priced per day, per week or per month, with free periods that differ per customer and pro-rata rules on the day of departure. Value-added services are priced per activity. Surcharges apply for out-of-gauge, heavy lift, weekend shifts, dangerous goods. Some customers are billed weekly, some monthly, some differently per service type. Tariffs change annually, on dates that differ per contract.

What it delivers

Handling, storage and services billed completely, because every operation carries its price at the moment it occurs.
Annual tariff changes applied by configuration rather than by project.
Invoices with operational evidence attached, which shortens disputes.
The commercial visibility to know which flows earn and which do not.

Contracts with structure

Contracts are held at multiple levels, with rules that can vary per customer, per commodity, per terminal and per service, and with versioning so that annual changes take effect on the correct date without rewriting the contract.

Transaction capture at the point of operation

Every scan, every move, every pick, every service, every gate transaction generates its billable transaction when it happens. Nothing is reconstructed afterwards.

A rule engine rather than a rate table

Transactions are grouped and priced through configurable processing rules, including parent and sub-rule structures, weight-based calculation, threshold pricing and supplement rules for additional charges.

Storage computed from daily positions

Daily inventory positions form the basis for storage billing, with per-customer rates, free periods, pro-rata calculation on departure, and the distinction between physical and announced stock respected.

Billing cycles that follow the customer

Weekly and monthly cycles, differing per customer and per service type, with configurable cut-off and automated billing runs.

Invoice generation and delivery

Invoices are generated in the platform with supporting evidence attached and delivered through the customer's preferred channel — or handed to your existing financial system as a priced, structured transaction set, if that is where invoicing belongs in your landscape.

Margin visibility

Because the operation and the tariff are in the same system, cost and revenue can be reported per shipment, per customer and per flow.

Contracts are held at multiple levels with rules varying per customer, per commodity, per terminal and per service, and versioned so annual changes take effect on their own date.
Every operation registered anywhere in the platform generates its billable transaction, priced from the applicable contract, at the moment it occurs.
Transactions are grouped and priced through configurable rules, including parent and sub-rule structures, weight-based calculation, threshold pricing and supplement rules.
Storage is computed from daily inventory positions, with per-customer rates and free periods, pro-rata calculation on departure, and the distinction between announced and physical stock respected.
Billing cycles differ per customer and per service type, with configurable cut-off and automated billing runs.
Invoices are generated with supporting evidence attached and delivered through the customer's preferred channel, or handed to an external financial system as priced, structured transactions.
Cost — subcontracted handling, transport, labour hours from the shift record, materials and equipment — attaches to the same shipment as the revenue.
Revenue and margin are reportable per shipment, per cargo type, per customer, per service and per terminal.

The operational reality

A multipurpose terminal runs on mobile harbour cranes, heavy forklifts, reach stackers, terminal tractors, coil grabs, spreaders and rigging gear. Spare parts are ordered when someone notices they are missing, which is usually the moment they are needed.

This is the same inventory, purchasing and cost problem the terminal solves professionally for its customers — applied to its own assets, and usually solved much worse.

What it delivers

Spare-parts availability managed rather than discovered.
Equipment availability visible to the people planning the operation.
A defensible cost per asset, which is the basis for replacement and charge-out decisions.
One system for inventory, purchasing and cost, applied to your own assets as well as your customers' goods.

Equipment register

Assets are registered with their attributes, status, availability and history.

Maintenance and status

Maintenance activities are recorded against the asset, and status changes — available, under maintenance, out of service — are visible to operations.

Spare parts as managed stock

Spare-parts inventory is held in the same warehouse structures as customer goods, with locations, stock levels and reorder points.

Purchasing

Spare parts are purchased against requirements, received into stock, and matched to supplier invoices.

Issue against work

Parts are issued from stock against a work order or an asset, so consumption is registered where it occurs rather than written off in aggregate.

Cost per asset

Parts, labour and maintenance accumulate against the equipment, producing a cost per asset that can be set against its utilisation.

Registration at the point of work

Operators record equipment status and maintenance observations from the device they already carry.

Equipment is registered with its attributes, status, availability and history.
Maintenance activities are recorded against the asset, and status changes are visible to the people planning the operation.
Spare parts are held as managed stock in the same warehouse structures as customer goods, with locations, stock levels and reorder points.
Spare parts are purchased against requirements, received into stock and matched to supplier invoices.
Parts are issued from stock against a work order or an asset, so consumption is registered where it occurs.
Parts, labour and maintenance accumulate against the equipment, producing a cost per asset.
Equipment status and maintenance observations are recorded from the device the operator already carries.

The operational reality

The TOS knows the quay, the warehouse system knows the sheds, the spreadsheet knows the services, and the financial system knows last month. Assembling a picture takes a person and a morning.

What it delivers

One answer to what is happening, available without assembly.
Problems visible while they can still be fixed.
Customer enquiries answered by the customer.
Volume and margin reporting from the same data the operation runs on, which is the only way the two ever agree.

One operational picture

Vessel calls in progress, yard occupation, warehouse stock, open tasks, gate activity and outstanding services in one view, because they are in one system.

Exception-driven working

Discrepancies, blocks, missing documents, failed allocations and overdue tasks surface as work to be resolved rather than as reports to be read.

Shift reporting

Who worked, on what, for how long, at what productivity, on which commodities and which activities — generated from the operation rather than compiled afterwards.

Stock and position reconciliation

Daily verification results, discrepancies and their resolution.

Customer-facing visibility

Stock, status and movement information available to your customers directly, which removes a substantial share of inbound enquiry traffic.

Commercial reporting

Volumes, revenue and margin by customer, commodity, flow and terminal.

Data available to your own tools

Operational and financial data is accessible to your reporting and analytics environment rather than locked in the application.

Vessel calls in progress, yard occupation, warehouse stock, open tasks, gate activity and outstanding services are visible in one operational picture.
Discrepancies, blocks, missing documents, failed allocations and overdue tasks surface as work to be resolved rather than as reports to be read.
Shift reporting is generated from the operation rather than compiled afterwards.
Daily verification results, discrepancies and their resolution are reportable.
Stock, status and movement information can be made available to your customers directly.
Volumes, revenue and margin are reportable by customer, commodity, flow and terminal.
Operational and financial data is accessible to your own reporting and analytics environment.

Domains 1 to 6 follow the cargo through the terminal. Domains 7 to 10 run underneath all of it. The scope statements are written to be discussed, not ticked: whether a capability fits your operation depends on how your operation works.

07

Part C — The platform

The financial backbone

This has its own section because it is where multipurpose terminals lose the most money, and where terminal software helps least.

In most terminals that chain is broken in at least two places. The quotation lives in a sales folder. The contract lives in a filing system and, partially, in someone's memory. The tariff lives in a spreadsheet updated annually by hand. The operation lives in the TOS. The invoice is built at month end from an export. The cost of subcontracted handling, transport and labour arrives separately, weeks later, and is never matched to the shipment that incurred it.

The result is that a terminal can know its total revenue and its total cost, and still not know which cargo, which customer or which service earns money.

What it delivers

Handling, storage and services billed in full, because pricing happens where the work happens.
Tariff changes applied by configuration rather than by project.
Disputes shortened, because the operational evidence is attached to the invoice.
Margin per shipment, which is the number that changes commercial behaviour.
One chain from quotation to margin, rather than six systems and a reconciliation.

Contracts and tariffs as operational master data

A contract is not a document filed against a customer. It is a structure the operational system reads at the moment work is performed: rates per commodity, per operation, per unit, per weight band; free storage periods; surcharge rules; validity dates. Terminal-specific and customer-specific rules coexist. Annual changes are versioned and take effect on the contract's own date, without rewriting anything.

Every operation prices itself

A scan on the quay, a relocation in the shed, a service performed, a gate transaction — each produces its billable transaction, priced from the applicable contract, at the moment it occurs. This is the single mechanism that closes revenue leakage, and it works because the operational system and the commercial system are the same system.

Storage computed from what was actually there

Daily inventory positions form the basis for storage billing, with per-customer rates and free periods, pro-rata calculation on the day of departure, and the distinction between announced and physical stock respected.

The cost side, on the same shipment

Subcontracted handling, inland transport, labour hours from the shift record, equipment and materials consumed. These attach to the same cargo the revenue attaches to. Self-billing to subcontractors is supported where that is how you work.

Profit and loss per logistic unit

Because revenue and cost meet on the shipment rather than in the ledger, margin can be reported per shipment, per cargo type, per customer, per service and per terminal. This is in production at the logistics arm of one of Europe's largest steel producers, and it is the capability that customer selected the platform for.

Invoicing, or handing off

Invoices can be generated, evidenced and delivered from the platform. Where invoicing belongs in your financial system, the platform delivers priced, structured transactions to it instead. Both are normal.

08

Part C — The platform

Interfaces and integration

Built on the assumption that it is not alone in your landscape, and that the systems around it are not going to change to accommodate it.

Counterparty messaging

This is where terminal integration actually breaks, and it deserves stating first. Multipurpose terminals exchange cargo data with hundreds of counterparties who have not agreed on a format and are not going to.

The platform therefore treats structured EDI and spreadsheet import as equally valid inbound paths, with the mapping configured per counterparty rather than developed per counterparty. A new agent sending a new spreadsheet layout is a configuration task, not a change request.

Where industry standards do apply — including sector-specific standards for forest products and the container message set — they are supported directly.

Enterprise systems

Documented APIs and message-based exchange for the systems that matter to a group: financial systems and ERP, master data and identity management, group reporting and analytics environments.

Integration with SAP alongside an existing landscape is in production.

Operational hardware

Handheld scanners, tablets and vehicle-mounted devices. Weighbridges. Cameras and identification capture at the gate. Label printers. Document output to printer, email or portal.

Regulatory and community systems

Customs systems and port community systems where these exist in the port. Where they do not — which is the case in many of the ports a global operator runs — the platform holds the control internally rather than assuming an external system will provide it.

Wherever an interface can be configuration, it is configuration. Where it requires development, it is developed once and becomes part of the product rather than part of your version. That is what keeps a portfolio of terminals on one product rather than on ten variants of it.

A full interface catalogue is available on request, with each entry marked as standard product, configuration of a standard mechanism, or built for a specific customer. We publish that distinction deliberately: a vendor who presents every interface as standard is describing a roadmap, not a product.

09

Part D — Credibility and risk

References, and what each one proves

Named implementations, with the scope stated as it actually runs. For each one we say what it demonstrates, so you can judge how far it carries to your own operation.

PSA Antwerp Breakbulk

In production

Steel, project and heavy-lift cargo, forest products, general breakbulk and containers within mixed operations. Seaside, yard, warehouse and billing on one platform, across two terminal locations, at industrial volume.

What it proves

That the platform runs a real multipurpose terminal, not a pilot — including the parts that are hardest to fake: marks-and-numbers identification of non-standardised cargo, tally across several methods, terminal document generation, and handling and storage billing computed from operational transactions.

PSA Zeebrugge

In implementation

Terminal operations, RoRo including cassettes and MAFI trailers, warehouse management across six warehouses, yard, gate access control, full intermodal, and a billing model covering storage, handling, RoRo, yard use, and container stuffing and stripping.

What it proves

That the scope described on this page generalises to a second, differently-shaped terminal — the point at which a product either travels or turns out to have been built for one customer. RoRo at volume sits here rather than in Antwerp.

ArcelorMittal Logistics

In production

The logistics arm of one of Europe's largest steel producers. Profit and loss per logistic unit across a multi-country industrial logistics operation, with plant-level exceptions consolidated into one standard process set reachable through direct electronic coupling, a portal, or manual entry.

What it proves

The financial depth of the platform — that operational events and commercial terms live closely enough together to produce a margin per unit of cargo rather than a margin per month. It was selected locally on operational merit and subsequently validated at group level, which is the sequence most enterprise selections actually follow.

Ewals Cargo Care

In production, multi-country

Contract and rate management across Europe, order management, customer invoicing across all countries, subcontractor purchase invoices with matching, and integrated document management. Execution data from trucks and on-board computers is received through an enterprise service bus. Planning runs in a dedicated system alongside it.

What it proves

That the financial backbone described in section 07 carries a multi-country operation on its own, next to a separate planning system — the clearest evidence for the coexistence argument in section 10.

A second European intermodal operator, container-based

In production

Equipment and spare-parts management, integrated with operational execution and cost accounting, with the platform holding the golden record alongside a separate planning system. Substantial reefer and temperature-controlled volumes.

What it proves

That the equipment, spare-parts, purchasing and cost functionality in domain 9 is in productive use rather than on a roadmap. It is a carrier's own fleet rather than cranes on a quay — the functionality is the same, the setting is not.

Aertssen Logistics

In production, including a site the customer implemented themselves

Machine and heavy-lift logistics, value-added services and serial number tracking. After the initial European implementation, Aertssen's own IT organisation deployed the platform at a new site in the United States, without our consultants on site.

What it proves

That the platform is configured rather than customised. That is not a claim you can verify from a slide, but it is very hard to fake once a customer has done it — and it is the practical test of whether your own organisation could run the rollout after the first site.

Neovia Logistics

In production across multiple sites

Transport management for a shipper, replacing existing transport systems while SAP retains warehouse management and ERP. A third site is in rollout, with knowledge transfer to the customer's own IT team.

What it proves

Coexistence. This is the most common architectural question we are asked, and this implementation is the answer to it: the platform slots into an existing enterprise landscape rather than requiring it to be cleared first.

A maritime shipping line in North America

In final implementation

Vessel, voyage and cargo management for a shipping line operating its own services, with voyages carrying their stops and the consignments per stop.

What it proves

That the voyage and cargo model in domain 1 holds from the carrier's side of the quay as well as the terminal's — relevant if your group operates services as well as terminals.

10

Part D — Credibility and risk

Coexistence: you do not have to replace anything

The most expensive assumption in enterprise software selection is that a new system must displace an old one.

For a group operating a portfolio of terminals, that assumption makes any multipurpose platform look like a strategic decision requiring years of consensus. It does not have to be.

Alongside your container platform

Your container terminals keep the system built for them. The multipurpose terminals run a system built for them. The two do not compete for the same operations, because they do not perform the same operations.

Alongside your ERP

The platform captures operational reality and prices it. Where invoicing, general ledger and consolidation belong in your financial system, the platform delivers priced, structured transactions to it rather than duplicating it. This is how Neovia Logistics operates alongside SAP.

Alongside your existing planning tools

The platform does not do stowage planning, berth optimisation or labour capacity planning. Where you have those, they stay.

Alongside your group standards

Master data, identity management, reporting and integration standards are yours. The platform integrates into them.

A first implementation can be scoped to one terminal, bounded, and reversible — which is a materially different decision from a group platform migration.

11

Part D — Credibility and risk

Enterprise fit, security and configuration

A group operating multiple terminals asks a different set of questions from a single-site operator. These are the answers, in the three areas where they are usually asked.

One instance, many terminals

Multi-terminal, multi-entity, multi-currency and multi-language on one instance. Terminals share a platform and a data model while retaining their own configuration: their own cargo types, tariffs, documents, workflows and screens. Group-level reporting is possible because the model is shared; local operating differences are possible because the configuration is not.

Roles and authorisation

User groups, roles and registration are managed centrally, with authorisation resolving to the terminal, entity and function level.

Rollout across a portfolio

Because configuration rather than development carries per-site difference, the second implementation is substantially faster than the first, and need not be performed by us at all. For a group with many sites, this is the difference between a rollout paced by your capacity and one paced by ours.

Release model

Regular releases with configuration preserved across upgrades. Terminals are not held back on old versions by their own customisation, because their difference is configuration, not code.

Support

Named support with defined response commitments, agreed contractually per deployment.

Certification

The platform and its development and operational processes are ISO 27001 certified.

Hosting models

Cloud as standard on AWS. In-region deployment in a specified jurisdiction, including the Gulf region, where data residency requires it. Deployment in your own environment under your own administration is supported.

Data residency as a contractual matter

Where you require it, data location is a contractual term with defined boundaries rather than a best-effort statement, and it is auditable.

Access control

Role-based authorisation resolving to terminal, entity and function. Integration with your identity provider.

Audit trail

Operational and administrative actions are logged with user, time, device and record. This exists first for commercial reasons — cargo claims are settled on evidence — and serves security review as a consequence.

Continuity

Backup, recovery and continuity arrangements are defined per deployment, since these differ materially between cloud and customer-managed environments. A security factsheet with the detail your information security organisation will want is available on request.

Every terminal believes it is different. In our experience every terminal is right — and that belief is the reason most terminal software projects become development projects.

There are two ways a vendor can accommodate difference. One is to modify the software for each customer. This works once, and then the customer is on their own version, upgrades become projects, and the vendor's capacity becomes the customer's constraint permanently. The other is to build the difference into the product as configuration. That is the approach here.

What is configurable. Cargo types and their handling rules. Identification and tally methods per commodity. Location structures and segregation rules. Workflows and their status models. Screens, fields and the data model itself. Documents and their layouts. Pricing rules, contract structures and billing cycles. Integration mappings per counterparty.

By whom. By us during implementation, and by your own organisation afterwards once trained. Aertssen Logistics deployed their own site in the United States with this toolset.

What it means for upgrades. Configuration is carried across releases. A terminal's specific setup is not a barrier to taking new versions, which is the mechanism that prevents the estate fragmenting over time.

Customise your service, without customising your software.

12

Part D — Credibility and risk

Implementation, and how to start

Start with one terminal. Not a portfolio decision, not a group platform migration — one terminal, a bounded scope, a defined timeline, and a result you can evaluate before committing further.

Choose the terminal for evidence, not for ease. The most useful first implementation is one with enough complexity to prove the point — more than one cargo type, real billing complexity — and small enough to complete.

Design

Your operation is documented at process level, and the configuration follows from it. This phase is where the difference between your terminal and any other is captured — deliberately, and in the product rather than in code.

Configuration and validation

The configured system is validated against your own scenarios, using your own data, with your own people. Not a demonstration environment.

Integration

Connections to your existing landscape are built and tested against the systems that will actually be connected.

Migration and cutover

Master data and open positions are migrated, with a cutover plan agreed and rehearsed.

Go-live and stabilisation

On site, with our people present, until the operation is running without them.

Capability transfer as an explicit deliverable

Where you intend to run your own subsequent rollouts, training your team to configure and deploy is part of the first implementation rather than an afterthought — and it changes the shape and the cost of every implementation after it.

What we need from you

A named operational owner with authority to decide, access to the people who actually run the operation, and honesty about the processes that do not currently work. The third matters most: implementing a new system on top of a broken process produces a faster broken process.

One platform for every cargo your terminal handles.

Which terminals this is about

The problem, stated precisely

What the gap costs

Twelve criteria for a multipurpose TOS

The architecture, in one picture

Ten operational domains

The financial backbone

Interfaces and integration

Counterparty messaging

Enterprise systems

Operational hardware

Regulatory and community systems

References, and what each one proves

PSA Antwerp Breakbulk

PSA Zeebrugge

ArcelorMittal Logistics

Ewals Cargo Care

A second European intermodal operator, container-based

Aertssen Logistics

Neovia Logistics

A maritime shipping line in North America

Coexistence: you do not have to replace anything

Enterprise fit, security and configuration

Implementation, and how to start

What we need from you

Who this comes from.