Port and Terminal Software: Fixing the Gate, Yard and Billing Leaks

Why terminal operating software makes or breaks a port operator

A terminal is a queue with a very expensive tail. Every minute a truck sits at the in-gate, every reshuffle to dig out a box buried three high, every hour a crane waits on a chassis that never arrived, all of it prices out. Most operators we work with can tell you their average truck turn time to the minute. Almost none can tell you which moves are causing the reshuffles, because that data lives in three systems that do not talk.

The usual stack: Navis N4 or SPARCS as the terminal operating system, Tideworks Mainsail or TOS Plus at smaller facilities, a separate appointment product bolted on top, an EDI translator handling 322s and 315s, and then the workarounds. A shared Google Sheet where the yard planner tracks reefer plug assignments because the TOS reefer module was never configured. A WhatsApp group where the gate supervisor and the yard boss reconcile mismatched container numbers in real time. A Windows box in the maintenance shop running an Access database of equipment PM schedules that one guy built in 2016 and nobody else can modify. Vessel stow plans emailed as BAPLIE files and hand-checked against the yard because the auto-load logic keeps proposing moves the stevedores refuse.

Here is the concrete scene. It is 06:40. A drayman arrives with a booking number for an export. The in-gate clerk keys it, N4 rejects it because the booking was amended by the line at 23:15 and the amendment came through a 315 that failed validation and landed in an error queue nobody watches overnight. The truck gets waved to the problem-resolution lane. Twenty-two minutes later, someone in the office calls the line, confirms verbally, and manually overrides. That truck now costs the drayage company an hour of driver time, and your terminal ate a slot. Multiply by the dozens of exceptions a day a mid-size terminal generates. Whatever an hour of truck and driver time costs the drayage company, they are billing it back to someone, and the detention disputes that follow land on your desk. This is six figures a year in goodwill and chargebacks, and it is the reason your customers rate you against the terminal two berths over.

Problem: the appointment system and the yard do not know about each other

You sell appointment slots by hour and by move type. The yard has no idea what is coming. So at 09:00 you get eleven trucks all wanting imports from the same block, and your top handler spends the hour digging the same stack instead of working three blocks in parallel. Meanwhile 14:00 to 15:00 is dead because the slot logic capped it by a static number set two years ago.

Off-the-shelf appointment products (the Advent eModal style tools, or whatever the port community system offers) sell capacity as a flat count per hour. They cannot see stack position, they cannot see equipment availability, and they cannot see that the reefer gen-set tech is on lunch. The TOS knows the yard but does not own the appointment. Nobody owns the join.

A custom build owns the join. The core is a slot engine that reads live yard position from the TOS via its API or the N4 XML services, scores each candidate appointment by the actual work it will create (a box on top of a stack is a one-move pick, a buried box is three), and prices or gates slots accordingly. You publish tighter capacity in high-dig hours and open more slots when the yard is clean. You expose it to draymen through a simple portal and an API that PortPro and Profit Tools can hit directly, so the big drayage accounts book programmatically at 04:00 instead of calling your dispatcher. On one deployment, the win was not average turn time. It was the standard deviation. Predictable is what draymen pay for.

Problem: your equipment tells you nothing until it breaks

A reach stacker goes down at 11:00 on a Tuesday. You find out because the operator radios in. Nobody knows the hours since last service, because service is tracked in that Access database, and hours are read off the dash manually when someone remembers. The rented replacement takes four hours to arrive and bills at a day rate nobody budgeted for.

Off-the-shelf CMMS tools (Fiix, UpKeep, Limble) will happily hold a PM schedule. They do not ingest CANbus telemetry from your Kalmar and Konecranes fleet, they do not know which move a machine was executing when the fault fired, and they cannot tell the yard planner to route work away from a machine that is 40 hours past due on a hydraulic service. The data model is asset-centric. Yours needs to be asset-and-move centric.

The build: a telemetry ingest pipeline off the OEM feeds (Kalmar Insight, Konecranes TRUCONNECT) or an aftermarket gateway on older iron, normalized into your own equipment event store, joined to the move log from the TOS. Now you can say, in plain numbers, that machine 214 throws hydraulic temperature warnings specifically during long reefer-block runs in July, and you schedule around it. Forecasting does real work here: a model trained on your own two years of fault codes plus hour meters plus move types predicts failure windows well enough to move a service from reactive to a scheduled overnight. In our deployments it converts roughly a third of unplanned downtime into planned downtime, and between rental day rates and the cascade into vessel delay, a third is a lot.

Problem: documents arrive as PDFs and email, and a human retypes them

Delivery orders, dock receipts, VGM declarations, hazmat DGDs, customs releases. Some come through EDI properly. A meaningful share arrive as an email attachment from a smaller forwarder who never onboarded to your EDI spec, and a clerk retypes the container numbers, the seal numbers, the UN numbers. A typo in a UN number on a hazmat declaration becomes a Coast Guard problem.

Off-the-shelf OCR products handle invoices well because invoices are a solved layout. They fall apart on a DGD from a Turkish forwarder that has been faxed, scanned and rotated. Generic document tools have no idea what a valid ISO 6346 check digit looks like, so they cannot self-correct.

This is the single clearest AI win in the category, and the reason is validation, not extraction. Run the document through a vision model to pull fields, then immediately validate against things only you know: check digit math on every container number, the number against your actual expected inventory, the UN number against the IMDG table and against what the booking said, the VGM against a plausible range for that box type. When all checks pass, and in our deployments that is roughly three quarters of documents, it posts straight through with no human. When anything fails, it routes to a clerk with the specific field flagged and the source image cropped to that field. Your documentation team stops being typists and becomes exception handlers. The same pipeline gives you an audit trail with the source image attached to every field, which is exactly what you want when CBP asks how a number got into your system.

Problem: multi-terminal means you have no consolidated truth

Two terminals, maybe three, possibly one on a different TOS because you acquired it. Corporate wants throughput, yard utilization and gate performance across all of them. Someone builds it in Excel every Monday. The numbers never quite tie because Terminal B counts a move differently than Terminal A, and nobody wrote the definition down.

The TOS vendors will sell you a reporting module. It reports on their instance. It will not span a Navis site and a Tideworks site, and it will not reconcile the definitional drift. BI (Business Intelligence) tools (Power BI, Tableau) will happily connect to both databases and produce two charts that disagree.

What a build does: a canonical event model that both terminals write into. A move is a move, with an agreed definition, a timestamp source you trust, and a terminal identifier. Change data capture off each TOS database, or the vendor's event feed where one exists, landed in your warehouse, transformed into that canonical shape. Then the executive dashboard is a query, not a ritual. More usefully, so is the customer-facing one. Your top ten BCO accounts get a live portal showing their boxes across all your facilities, which is a thing the TOS vendor cannot sell them and your competitor down the coast does not have.

Problem: billing leaks and nobody can prove it

Storage, demurrage, reefer plug-in hours, hazmat handling, chassis flips, exam fees. The TOS calculates some of this. The tariff has 60 line items and the TOS is configured for 30. So the rest is invoiced from a spreadsheet the billing clerk maintains, and the free-time clock start is argued by email with the line's agent every single month.

Generic accounting integrations do not fix this because the problem is upstream: the events that trigger a charge are not being captured with enough fidelity to defend the charge. Reefer plug hours are the classic. If you are not logging plug and unplug events with a timestamp and an operator ID, you are billing an estimate and you will lose the dispute.

The build is a rating engine that sits on the canonical event stream. Every billable event carries its evidence: the gate camera OCR read, the plug event, the operator who executed it, the timestamp. Tariff rules are configuration, not code, so your commercial team can change a rate without a dev cycle. When an agent disputes, you send them the evidence trail, and the dispute closes in one email instead of three weeks. In every billing project we have delivered in this space, the recovered revenue from previously unbilled or under-defended charges was the line item that paid for the whole build, and it is almost always reefer hours and chassis handling that were leaking.

What this costs and how long it takes

These are Digital Heroes numbers from our own delivery record across 2,000-plus projects, not an industry survey.

A focused first release runs $60,000 to $130,000 and ships in 12 to 16 weeks. Focused means one thing done properly: the appointment-plus-yard slot engine with a drayage portal, or the document intake pipeline with validation, or the multi-terminal event warehouse with executive and customer dashboards. Not all three.

A full platform runs $150,000 to $400,000, phased across 6 to 12 months, and that is the realistic band when you need gate, yard visibility, equipment, document intake and billing all reading from one event model with EDI and customs wired in.

What pushes you toward the top of the band in this category, specifically: the number and stubbornness of your TOS integrations (a modern N4 with licensed API services is straightforward, a 15-year-old Tideworks instance where you are reading the database directly is not); EDI coverage depth, since every additional transaction set (322, 315, 300, 301, 304) is real work and every trading partner has their own dialect of it; customs integration, because ACE and AMS filing paths carry compliance burden and a mistake has teeth; OCR and camera hardware at the gate if you do not already have it; TWIC and physical access control integration if it is in scope; and 24/7 uptime requirements, which change your architecture and your on-call cost from day one. A terminal that never closes cannot take a maintenance window, and designing for that is not free.

Build or buy, honestly

Buy when you run one facility, your annual volume sits below roughly 150,000 TEU, your stack rules are simple, and your customer mix is stable. Navis N4 or Tideworks will do the job and you should spend your money configuring it properly rather than rewriting it. Most terminals that think they need a custom TOS actually need a consultant to finish the configuration they abandoned three years ago. Be honest about which one you are.

Build when these show up, and they are concrete: you run two or more facilities on different systems and reconcile by spreadsheet; you have a person whose actual job is retyping documents; your reefer or chassis billing is estimated rather than evidenced; your appointment capacity is a static number somebody guessed; your drayage customers are asking for API access and you are telling them no; or you have a spreadsheet or Access database that would take down operations if its author quit.

Our position: do not replace the TOS. That is a multi-year, multi-million-dollar project with a bad success rate, and the TOS is good at the thing it is good at, which is core inventory and move execution. Build the layer above it, and the layers around it. The appointment intelligence, the document intake, the equipment telemetry, the cross-terminal warehouse, the rating engine, the customer portal. That is where the money is leaking and where off-the-shelf has nothing to sell you. The TOS becomes a system of record you integrate with, not a system you are hostage to.

How to choose a developer for terminal operating software

Ask them to explain a BAPLIE and a COPRAR without looking it up. Not a trivia test. If they have never touched EDIFACT or the X12 motor transaction sets, they will underestimate the integration work by a factor of three, and integration is most of this project.

Make them draw your data model on a whiteboard before you sign anything. Container, booking, move, unit, equipment, visit, yard position. If they model a container as the primary entity rather than the move or the unit visit, they have not built this before and you will pay for their education. The subtlety is that a container is a physical object with a life across many visits, and a unit is what your yard actually manages.

Ask what happens when the TOS goes down at 02:00 during a vessel operation. The answer you want involves queued writes, an offline gate mode, and a reconciliation path when it comes back. The answer you do not want is a shrug or a promise about uptime. Terminals do not stop.

Check that they have shipped something touching customs or hazmat, and ask specifically who owns the code and the IP. In this category you will be handing a vendor access to filing paths and to data that regulators can subpoena. Get the ownership answer in writing, get the source in your own repository from week one, and get a named person who understands that a wrong UN number is a different class of bug than a wrong shipping address.