The four hard problems
Every ship management system eventually meets an accounting system, and the meeting rarely goes well. Operations think in vessels, voyages and equipment. Finance thinks in entities, cost centres and periods. The integration between them determines whether an owner's monthly report can be trusted — and whether a manager can explain a variance without a week of reconstruction.
1. Cost head mapping
Operations raise a requisition against a piece of equipment. Finance needs it in a cost head. The mapping between the two is neither obvious nor stable.
| Operational event | Finance treatment | Common failure |
|---|---|---|
| Spare part for main engine | Repairs & maintenance – machinery | Booked to stores, distorting both |
| Lube oil delivery | Lubricants | Split across stores and R&M |
| Superintendent travel | Management / owner's expense | Charged to vessel, inflating OPEX |
| Dry dock steel renewal | Capitalised or expensed | Inconsistent between ships |
| Crew travel for relief | Crew costs – travel | Mixed with owner's travel |
| EU ETS allowance purchase | Voyage cost or regulatory cost | Frequently unmapped entirely |
Fix this once, centrally, with a governed mapping table that operations cannot edit ad hoc. Every fleet that skips this step spends the next three years explaining why sister ships have different cost profiles.
2. Accruals
A ship consumes services long before the invoice arrives. Bunkers, port disbursements, spares in transit, repair work in progress — all of it must be accrued to give a true monthly OPEX picture. The ship management system knows the commitment; the ERP knows the ledger. If commitments do not flow across, the monthly report is a cash statement dressed as a management account.
Rule: every purchase order and every service order should create an accrual on issue and release it on invoice match.
3. Three-way matching
Purchase order, goods receipt, invoice. All three must agree before payment. Two-way matching (PO and invoice) misses short deliveries and damaged goods, and it is disturbingly common.
4. Multi-entity structures
Ships are frequently owned in single-purpose vehicles, managed by an entity in another jurisdiction, crewed by a third, with a technical manager in a fourth. Intercompany flows, currency translation and consolidated reporting all sit on top of that.
The integration architecture that works
One master data source per identity. The vessel register lives in one place. The supplier master lives in one place. The chart of accounts lives in the ERP. Nothing is maintained twice.
Event-driven flow, not nightly batch. A purchase order should reach finance when it is issued, not at 02:00. Batch integration is why variance conversations happen six weeks late.
Idempotent interfaces. Re-sending a message must not double-post. This sounds obvious and is the source of most integration incidents.
A reconciliation report that nobody has to build. Commitments in operations vs accruals in finance, by vessel, by cost head, monthly, automatic. If the two systems disagree, you want to know on the third of the month, not at year end.
What to integrate, in priority order
| Priority | Interface | Value |
|---|---|---|
| 1 | Purchase orders → accruals | Truthful monthly OPEX |
| 2 | Goods receipt → three-way match | Payment control |
| 3 | Invoices → ledger with vessel/cost head | Variance analysis |
| 4 | Crew payroll → ledger | Largest single cost head |
| 5 | Budgets ← finance → operations | Shared version of the plan |
| 6 | Port disbursements → ledger | DA control |
| 7 | Bunker deliveries → inventory and ledger | Fuel cost accuracy |
| 8 | Emissions cost (ETS/FuelEU) → voyage and ledger | New in 2026 |
Priority 8 is genuinely new. Allowance purchases, FuelEU penalty provisions and pooling settlements need a home in the chart of accounts and a link to the voyage that generated them. Fleets that leave this unmapped will find their 2026 emissions costs sitting in a suspense account.
Ownership and governance
Integration projects fail on ownership more often than on technology. Name:
- A master data owner for vessels, suppliers and equipment
- A mapping owner for the cost head table, with a change process
- A reconciliation owner who reviews the operations-to-finance variance monthly
- An interface owner who is paged when a message fails
Four names. Most fleets have none of them written down.
general architectural guidance, vendor-neutral. Emissions accounting references Directive (EU) 2023/959 and Regulation (EU) 2023/1805. Reviewed by the Zeaclub Editorial Team, 24 August 2026.
Frequently asked questions
Do we need a maritime-specific ERP?
Not necessarily. General ERPs handle the ledger perfectly well. What matters is that vessel, voyage and cost head dimensions exist and that the ship management system can post to them cleanly.
Should the manager's system post directly into our ledger?
It can, with controls. More common and safer is a structured file or API feed the owner's finance team reviews before posting.
How do we handle multiple currencies?
Fix the functional currency per entity, translate at a documented rate policy, and keep the transaction currency visible on every line. Losing transaction currency makes supplier price comparison impossible.
What is the most common integration mistake?
Mapping cost heads late, per vessel, by whoever is implementing that ship. It produces a fleet whose cost data cannot be compared, which defeats the purpose of having a fleet.