Port Community System Development: Why a Container Cleared on Wednesday Is Still Sitting on Friday

Why a container that cleared customs on Wednesday is still on the terminal on Friday

A reefer discharges Tuesday afternoon. Customs releases it Wednesday morning. The consignee books a truck slot, the haulier arrives Thursday at 06:00, and the gate turns him away because the terminal operating system still shows the unit blocked. Somewhere between the customs authority, the line agent, the terminal and the forwarder, a release either never arrived or arrived quoting a reference nobody could match to the container number on the chassis. The box sits. Demurrage and detention run against the consignee. A person in an office fixes it by phone at 11:00, and the truck has already left for another job.

That phone call is the entire reason a port community system exists. Every party in the chain holds one true fragment of the picture and none of them holds the whole thing. The terminal knows the yard position and whether the unit is available. The line agent knows whether freight has been paid and the delivery order issued. Customs knows the declaration status. The forwarder knows who the actual receiver is. The haulier knows which truck is thirty minutes away. Today those fragments move as email, as PDF delivery orders, as portal logins, and as a handful of UN/EDIFACT messages that only two of the five parties can produce.

The cost is not abstract. It shows up as truck turn time at the gate, as reefer plug hours nobody scheduled, as demurrage disputes that a clerk settles with screenshots, and as a terminal planning a yard shift for a container that was never going to move that day. Ports that fix this do not fix it by buying visibility. They fix it by making one status authoritative and making every participant read from and write to it.

Problem 1: there is no shared identity for a single container movement

The hardest engineering problem in a port community system is not messaging, it is identity resolution. The same physical movement is known as a booking number to the carrier, a bill of lading number to the forwarder, a container number plus ISO type to the terminal, a customs declaration reference to the authority, and a job number to the haulier. None of these is unique on its own. Container numbers get reused within a year. A bill of lading covers forty containers. A declaration covers a partial consignment.

A build that gets this right models a movement as a durable entity with many aliases, and every inbound message attaches to it through a resolver that scores candidate matches and quarantines the ambiguous ones for a human. Every party writes events, never states. The current status is a projection over an append only event stream, which means when the customs release and the terminal block contradict each other, you can show exactly which message arrived when and from whom. Ports that skip this and build a table of containers with a status column end up with a system that is wrong in a way nobody can audit, which is worse than the telephone.

Problem 2: authorisation is the product, not a feature you bolt on later

Who is allowed to see that a container has been released? Not everyone. The visibility chain follows the transport document: the carrier releases to the named consignee or the holder of the bill of lading, who nominates a forwarder, who nominates a haulier for one specific job on one specific day. A haulier should see a release, a gate reference and a slot, and nothing about the commercial party or the cargo value. A terminal should not see the forwarder's rates.

Off the shelf logistics visibility tools model permissions as company level roles, which is not what a port needs. You need delegation that is per movement, time bounded and revocable, so that when a consignee switches hauliers at 22:00 the previous carrier loses sight of the job at 22:01. Getting that wrong is not a usability complaint, it is a commercial leak that will cost you the trust of the forwarding community, and once forwarders decide the platform exposes their customers to carriers they will never come back.

Problem 3: customs is national, and that is exactly why products stop short

Portbase is genuinely excellent inside the Dutch ports, and DAKOSY is excellent against German customs and the Hamburg community, because both were built by and for those communities over decades. That is also the limit. Their message sets, their release logic and their customs adapters encode one national regulator's process. Kale Logistics has done real work productising cargo community modules across several countries, and NxtPort built a strong data sharing layer with clean APIs. What none of them can hand you is your own regulator's declaration lifecycle, your own port's terminal mix, and the specific way your inspection agencies raise and lift holds.

So the question is not whether these products are good. It is how much of your port's operating reality survives their model. If your customs authority runs its own national declaration platform with a bespoke web service, if you have veterinary and phytosanitary inspection bodies that issue holds outside customs, and if two of your terminals still run different legacy systems, you are buying a framework and then funding a custom project inside it, without owning the result. At that point a build is usually cheaper and always more controllable.

What a port community system actually has to include

The non negotiable core is a message gateway that speaks UN/EDIFACT COPRAR, CODECO, COARRI and BAPLIE to terminals and carriers, modern REST and event APIs for anyone who will use them, and file drop plus email parsing for the members who will not. Every port has a long tail of small forwarders and hauliers who will never integrate, and pretending otherwise is how adoption dies. Give them a plain web screen and a mobile view that shows one thing: is my box ready, and when can I pick it up.

Then the release workflow: an electronic delivery order that the carrier issues, the forwarder endorses and the haulier presents at the gate as a token, not a PDF. Then truck appointments tied to actual availability rather than to a fixed hourly quota, because a slot booked against a container that is buried five high is a slot that produces a gate queue. Then hold management, so that customs, veterinary and port state holds are first class objects with an owner, a reason code and a lift event. Then the reporting obligations, including the EU Maritime Single Window Environment, which applies from August 2025 for ship reporting formalities in EU member states and which most ports will front through the community platform rather than making every agent file separately. Then dangerous goods declarations, because IMDG documentation and segregation checks belong where the terminal and the authority both see them.

Two things to build early that teams routinely defer: a full audit and replay capability, because your first serious dispute will be about who knew what at what minute, and a sandbox with realistic test data that members can integrate against without a project manager holding their hand. The second one is worth more to adoption than any feature.

What it costs, how long it takes, and what drives the number

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering identity resolution, the message gateway for two or three terminals, electronic release, haulier web access and one customs interface runs $180,000 to $400,000 and ships in five to eight months. The full community platform adding appointments, hold management, dangerous goods, reporting formalities, billing and a member self service integration portal runs $600,000 to $2,000,000 phased over 18 to 30 months.

What drives the price up in ports specifically: the number of terminal operating systems you must integrate, because each one is its own dialect even when it claims EDIFACT compliance. The number of customs and inspection agencies, since each has a different message format and a different escalation path. Whether the port handles roll on roll off and breakbulk as well as containers, because those are separate data models and people underestimate this every time. Twenty four seven operational support, which is a real running cost and not a line item to discover later. And the biggest driver of all, which is not technical: how many stakeholders must agree before a decision is made.

What keeps it down: launch with the two largest terminals and the top twenty forwarders by volume, cover import release only, and leave export and transhipment to phase two. That covers most of the pain and all of the political proof you need.

Governance decides whether this succeeds, and it is not a software question

The technically excellent port community systems that failed all failed the same way: nobody was obliged to use them, so the phone kept working and adoption stalled at thirty percent, which is worse than zero because now there are two sources of truth. Decide before a line of code is written who operates the platform, whether the port authority mandates it through terminal concession terms or tariff, how it is funded, and what the pricing unit is. Per container is legible and scales with the value delivered. Per message punishes the members who integrate properly, which is precisely backwards.

Neutrality matters as much as the mandate. If one terminal or one carrier is perceived to control the platform, competitors will withhold data and you will be back to bilateral integrations. A community interest company or a port authority subsidiary with a member steering group is the structure that tends to hold.

How to choose a developer for a port community system

Ask them to explain container identity resolution on a whiteboard before you discuss price. If they do not immediately raise the booking number to bill of lading to container number to declaration reference problem and how they will handle unmatched messages, they have never done this. Ask what happens when a CODECO arrives for a container the system has never heard of, because it will, daily.

Ask specifically which terminal operating systems they have integrated and which customs platform, by name. Integration with Navis is not the same job as integration with a bespoke terminal system written in the 1990s, and both will appear in your port. Ask how they handle message replay and reconciliation after an outage, because a port community system that loses four hours of gate events during a failover has caused an operational incident, not an IT one.

Ask about the member onboarding kit, not just the platform. Sandbox, documented schemas, sample payloads, and a self service certification flow are what let fifty companies integrate without fifty consultants. Finally, get code and data ownership in writing before kickoff. The port must own the repository, the infrastructure accounts and the right to appoint any other supplier. At Digital Heroes the client owns it from the first commit, and for shared public infrastructure that principle should be non negotiable no matter who you hire.