Ship Agency and Port Call Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why do agency builds start with the port call workflow and stall before disbursements work?

Operations feels like the urgent problem, so the first specification describes the call: appointments, task lists, notifications, a status board, a message thread with the master. Six months later the agency has a competent coordination tool and is still arguing about final accounts in email, because the money side was scheduled for phase two and phase two got deferred.

This ordering happens because the coordination pain is visible daily and the variance pain is invisible annually. Nobody logs an unrecovered disbursement line. It just becomes a slightly worse month.

The fix is to build the disbursement object first and let the workflow attach to it. Model the call as a single object whose lines move from estimate, to commitment when the service is ordered, to actual when the supplier invoice is matched, each carrying a variance and a reason code. Once that exists, the operational tasks become events against the same object rather than a parallel system, and the status board is a byproduct instead of a build. Agencies that sequence it the other way end up with two systems and reconcile between them, which is the situation they were paying to escape.

If budget is genuinely constrained, build the tariff and disbursement layer only. For many agencies that alone resolves most of the pain at the lower end of the first release band, and the coordination side can wait a year without anything breaking.

What goes wrong when tariffs and historical disbursements are migrated?

Port charges are formulas: tonnage dues on a scale, pilotage by length overall and draught with night and weekend factors, towage by bollard pull and duration with a minimum, berth dues per metre per period. That logic currently lives in an experienced agent's head and in a spreadsheet nobody else opens. Modelling it is the real work of the project, and it is routinely quoted as data entry.

Two specific failures follow. The first is tariffs modelled as flat rate tables because a rate table imports quickly. Within a year the port revises its tariff, and because there is no effective date on the rule, every historical reconciliation silently changes. Variance analysis becomes meaningless and nobody notices for months.

The second is historical disbursements imported as totals. A closed call arrives as a single figure with no line structure, so it cannot be compared with anything, and the comparative reporting the agency actually wanted is not available on any historical call.

Model tariffs as versioned calculation rules with an effective date, and record on every proforma line which rule version and which inputs produced it. A call three weeks out then uses the tariff that will be in force, and a call being reconciled uses the one that applied at the time. For history, import only what has line structure, accept that older calls come across as reference documents, and be honest in the plan about which year your comparative reporting actually starts. Start with your top three ports by call volume, which usually covers most of your traffic and lets the modelling approach prove itself before you commit to the whole network.

Why do supplier invoice capture and accounting integrations break after launch?

Supplier invoices are where the operational time goes, and they are the integration everyone underestimates. They arrive as PDFs in dozens of layouts, from a national towage company with a structured format and from a launch boat operator at a small port whose invoice is a scan of a typed page. Document extraction proposes a match against commitments and a human confirms it, which works well. What breaks is the assumption that the proposal rate stays constant. A supplier changes their template, or a new supplier joins, and matching quality drops without anyone measuring it.

Accounting integration breaks for a different reason. Client money must reconcile exactly, so the interface is not a nightly summary post. Every receipt, disbursement, exchange difference and return has to land against the right call and the right principal, and any drift is a reconciliation problem rather than a reporting inconvenience. Chart of accounts changes made by the finance team without telling anyone are a common trigger.

Statutory filing is the third. Reporting has moved substantially towards electronic single window systems, including the European maritime single window environment consolidating reporting formalities for calls at member state ports. Each implementation has its own interface and its own validation rules, and those rules change. A filing that was accepted last quarter can be rejected this quarter on a field nobody has touched.

Treat all three as monitored surfaces. Track match rate per supplier and alert on a drop. Reconcile the ledger daily rather than monthly. And make filing rejections a visible queue with an owner, because a silent rejection becomes a berthing problem.

What happens when client money accounting and approval records are not covered?

Funds in advance sit in the agent's account and belong to the principal. Agencies that run this inside a general accounting package can produce a company position and cannot easily produce the position per principal per call, which is the only view that matters operationally.

The failure is not usually fraud or even error. It is timing. Nobody knows a call is underfunded until the vessel arrives and a supplier who has not been paid does not attend. The vessel is then delayed for a reason that has nothing to do with shipping, and the agency absorbs both the cost and the relationship damage. Multi currency makes it worse, because a receipt and a settlement weeks apart at different rates leave a difference that belongs to a specific party and is frequently absorbed by the agent because nobody tracked it.

Approval records fail the same way. A principal approves an overspend by email, the person who sent it leaves, and six months later the approval cannot be produced during a query. The disbursement is then argued from memory.

Hold funds as a ledger per principal per call, recording receipts, disbursements, exchange differences and returns against that call, and surface underfunded calls before arrival rather than after. Capture approvals in the system against the specific line and threshold, with the named approver, so the record survives the email account. Configure thresholds and approvers per principal, because they genuinely differ and re-keying into each principal's format is a cost most agencies have stopped noticing.

Should you build custom or configure what you already own?

Do not build if you are a single port agency handling a couple of hundred calls a year with a handful of principals. A disciplined proforma template, a good accounting package and one experienced agent will outperform anything you could afford, and we would tell you to put the money into staff. This is a genuinely small business and software will not change that.

ShipNet and Softship are serious agency and liner systems with real depth, and if your requirements sit close to how they already work, configuring one is a shorter road than a build. On the principal side, Marcura DA-Desk does a useful job auditing disbursement accounts at scale, and a shipping line whose only problem is inconsistent challenge across many agents should evaluate that before commissioning anything.

Build when you operate across several ports with different tariff regimes, when you handle enough principals that re-keying into their formats is a measurable cost, or when client money is large enough that your funds position needs to be knowable rather than reconstructable. Lines with an internal port cost function have a related case: their build is about recomputing expectations from tariffs so disbursements can be challenged consistently. Either way the trigger is identical, which is that the gap between what should have been charged and what was charged is currently invisible.

How do hidden costs get into the quote?

Ports are priced per port and quoted as a network. A tariff for a straightforward port is hours. A complex one with scales, night factors, extended stay charges and local exceptions is days, and it needs an agent's time as well as a developer's. Get the port list named in scope with a per port price and a defined process for adding one later.

Supplier invoice capture is the second. A quote covering invoice matching without naming an expected match rate, an exception queue and a rework path has priced the good invoices only.

Statutory filing is the third, and it is quoted as an integration when it is a specification exercise per jurisdiction. Each single window has its own fields and validations.

Then the ones that show up late. Accounting integration testing, which is heavier than expected because client money must reconcile to the currency unit. Principal onboarding, since every new principal format is configuration somebody has to do. Parallel running through a full month end so the funds position can be proven against the old process. And the ongoing cost of tariff maintenance, which is nobody's job until it is, and which quietly determines whether the system is still accurate in year three.

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

Ask a prospective developer to model a disbursement on a whiteboard before you sign anything. A team that has done this draws one object whose lines move through estimate, commitment and actual with a variance and a reason on each, and asks within the first two minutes whether the funds are client money. A team that draws quotes and invoices has built an accounting tool and has not understood that the proforma and the final account are the same thing at different times.

Give them a real tariff, one with a scale and a night factor, and watch what they do with it. If it becomes a rate table with one amount per service, the system will be wrong within a year of the next revision and every historical comparison will move underneath you.

Ask how supplier invoices get matched and listen for extraction proposing a match against commitments with human confirmation, plus a named exception queue. Anything claiming full automation has not seen a launch boat invoice from a small port.

Settle ownership of the code, the cloud accounts and the tariff library in writing before kickoff. At Digital Heroes the client owns the code and the data from the first commit. The tariff models are your accumulated local port knowledge and are the most valuable thing in the system. A developer who wants to keep them as their platform content is taking the one asset that makes your agency worth appointing.