Almost every planned maintenance to finance integration is built to move the wrong number. The usual specification is that completed work orders and their costs flow to the general ledger, which produces accurate accounts and changes nobody's behaviour, because it moves money that has already been spent. The number that changes a decision is the commitment. Consider how it works when it is done properly: an annual operating budget is approved for a vessel, the ship requisitions twenty-five thousand dollars of spare parts, the superintendent approves the purchase order, and that twenty-five thousand appears immediately as a committed cost against the vessel's spares and maintenance budget code with the remaining budget updated in real time. The superintendent approving the next repair therefore knows what is left before deciding, rather than three weeks later when an invoice posts. Established maritime procurement systems track budget consumption per cost account and cost centre based on issued purchase orders as well as actual invoices, for exactly this reason. If your integration only carries invoices, you have built an accounting feed rather than a control. Start a free trial of Marine Inspection and specify the commitment before specifying the ledger entry.
1
A defect is raised against equipment
On the vessel, at the machine, by whoever found it — with the component identified rather than described. Everything downstream inherits that link, and if it is missing here it cannot be recovered later.
2
A work order and a requisition follow
The requisition carries the vessel, the component that triggered it, the planned maintenance window it belongs to, and a priority that distinguishes a critical spare from routine stores — because maritime procurement priority rules differ between those two cases.
3
The budget moves before the money does
On approval, the value appears as a committed cost against that vessel's budget code and the remaining figure updates immediately. This is the step most integrations omit, and it is the only one in the sequence that affects a decision rather than recording one.
4
Goods are received on the ship
A crew member records receipt against the purchase order in a port, possibly with no connectivity, frequently for a partial delivery. Stock updates, and the situation where something is received but not accounted for is avoided.
5
The invoice matches, or it does not
Order, receipt and invoice compared automatically. Clean matches proceed to payment without human review; discrepancies route to a named person showing exactly what does not match and why.
Five steps, three systems, and one number that has to survive all of them: which piece of equipment caused this spend. If that link breaks anywhere in the chain, you end up with accurate accounts that cannot answer the only question a technical director actually asks — what is this vessel's machinery costing us, and which parts of it.
Committed Cost Is the Useful Number
The distinction between what has been spent and what has been promised is the difference between a report and a control, and it determines whether the integration changes anybody's behaviour. Book a Marine Inspection demo and specify which of the two your integration will actually carry.
Actual cost
What has been invoiced and posted. Accurate, auditable, and typically weeks behind the decision that caused it. Essential for accounts and close to useless for a superintendent deciding whether to approve a repair this afternoon.
Committed cost
What has been ordered but not yet invoiced. Appears the moment a purchase order is approved, consumes budget immediately, and gives the person about to spend more a real picture of what remains. Maritime procurement platforms track consumption per cost account and cost centre from issued purchase orders as well as from actual invoices precisely because the first number is the one that governs behaviour.
What most integrations carry
Only the first. Which produces a general ledger that reconciles perfectly and a technical department that discovers it has overspent a budget code some weeks after it happened. If you specify one thing in the integration brief, specify that commitments post as well as actuals.
The Three-Way Match Has a Weak Leg at Sea
Matching order, receipt and invoice is standard finance practice everywhere. Shipping has one structural complication that no other industry carries, and it sits in the middle of the three. Sign up for Marine Inspection and check how the middle leg gets captured on your vessels.
Leg 1
The purchase order
Raised ashore after approval, monitored against expected delivery dates aligned to the vessel's port schedule rather than to a warehouse calendar. Sits in the procurement or finance system and is rarely the problem.
Leg 2
The goods receipt — recorded on a ship
Captured by a crew member during a port call, frequently under time pressure, often for a partial delivery because the full quantity did not arrive in time for sailing, and possibly with no connectivity at the moment of receipt. If this record does not reach the systems that need it, the match cannot complete and the invoice is either paid unmatched or sits blocked while somebody investigates.
Leg 3
The supplier invoice
Arrives in accounts payable and is compared against the other two. Where all three align the invoice can proceed to payment without human review; where they do not, the exception should route to a named person showing precisely what does not match.
The failure
What happens when leg two is missing
The classic case outside shipping: a supplier ships four hundred and twenty units against an order for five hundred and invoices for the full amount. Without a receipt record, accounts payable does not know eighty units are missing and pays in full, with the discrepancy surfacing months later during a vendor reconciliation if it surfaces at all. In shipping that scenario is more likely rather than less, because the receipt happens at sea and partial deliveries are routine rather than exceptional.
Two requirements follow, and both should be in the specification rather than discovered later. Partial receipt handling is not an edge case in maritime procurement — port timing makes it normal — so a matching process that only handles complete deliveries will throw exceptions on a large share of orders. And goods receipt has to be capturable offline on the vessel and synced afterwards, because the alternative is a crew member remembering to record it once the ship has connectivity, which is the same reconstruction problem that undermines every other maritime record.
The link that has to survive all three systems
A defect raised against a specific component, becoming a work order, becoming a requisition that still carries the component reference, becoming a purchase order, becoming a receipt on the vessel, becoming an invoice line in the ledger. Every hand-off is a chance to drop the equipment link — and once it is gone, you have accurate financial totals and no ability to answer which machinery is consuming the money. Specify that link as a mandatory field at every stage, and test it end to end before go-live rather than discovering at year end that maintenance spend is only analysable by vessel.
Cost Centre Mapping Is Where It Actually Breaks
The two systems categorise the world differently, and reconciling those categorisations is the part of the project that has no technical solution. Schedule a walkthrough and settle the mapping before anybody writes a connector.
The mismatch
A maintenance system organises the world by equipment. A finance system organises it by account code. Neither structure derives from the other, and somebody has to decide how they correspond.
Maritime accounting platforms typically use standardised codes across the major operating expenditure categories — crew wages, maintenance, insurance, port costs — customisable to match a company's own chart of accounts. That customisation is where the mapping decision lives, and it is a business decision rather than a configuration task.
Decide the granularity first
Does maintenance spend post at vessel level, at system level, or at component level? Component-level costing is what makes lifecycle analysis possible and it multiplies the number of codes considerably. Choose deliberately, because changing it later means remapping historic data.
Decide who owns the mapping
One named person on the finance side and one on the technical side, because the mapping needs maintaining every time a code is added, a vessel joins or the chart of accounts changes. Unowned mappings drift and the drift is invisible until a report looks wrong.
Decide what happens to an unmapped item
A new equipment type or a new code with no corresponding entry on the other side. Does it fail loudly, or does it post to a suspense account nobody reviews? Failing loudly is the right answer and it needs somebody named to receive the failure.
The Translation Layer Nobody Mentions Until It Bites
Between a chief engineer's free-text request and a supplier's catalogue sits a coding problem, and maritime has a specific answer to it. Start a free trial and check how requisition text becomes something a supplier can quote against.
The problem
A requisition from a vessel is written by an engineer who knows what they need and does not know how a supplier catalogues it. The resulting free text is unambiguous to the person who wrote it and unquotable by anybody else, which is why so much marine procurement runs on email clarification rather than on structured ordering.
The maritime answer
Industry coding standards for marine stores and spares. Buying guidance is emphatic on this point: the strongest tools match free-text requisitions to those codes automatically, so that a vaguely worded request from a vessel becomes a clean codified line suppliers can quote against — and a product that cannot handle those codes fluently should be treated as disqualifying for marine procurement.
Why it belongs in this conversation
Because coding is what makes procurement data analysable after the fact. Without it, spend analysis is a text-matching exercise across years of differently worded requests for the same item, and the reporting that was supposed to justify the whole integration cannot be produced.
Specify three things
Commitments post as well as actuals. The equipment link is mandatory at every stage and tested end to end. Goods receipt is capturable offline on the vessel with partial deliveries handled as normal rather than as exceptions. Get those three into the specification and most of what goes wrong with these integrations has already been prevented.
Integrated or Interfaced: The Honest Trade-Off
There is a real argument that this should not be an integration at all, and it deserves stating properly rather than dismissing. Book a walkthrough and decide which of these two shapes suits your operation before evaluating either.
One system, no interface
The argument is straightforward: keeping maintenance in a separate tool from finance forces reconciliation and delays cost visibility, whereas combining them lets a work order reserve parts, raise a requisition, capture labour and accrue cost to the vessel automatically
The probing question this camp asks in demos is a fair one — does a work order do all of that in one system, without an overnight interface
Genuine advantages: no mapping to maintain, no reconciliation, real-time cost visibility, one version of the equipment link
Genuine costs: a much larger platform decision, longer implementation, and a single vendor across functions with very different requirements
Best of breed, connected
Maintenance and inspection where crews actually work, on a mobile-first tool with offline capture, connected outward to whatever procurement and finance systems already exist
Genuine advantages: each function served by something built for it, faster deployment, and the ability to change one component without replacing everything
Genuine costs: the mapping, the reconciliation, the connector maintenance and the latency between systems
The deciding question is usually whether your finance and procurement systems are working well — replacing systems that work in order to avoid an interface is an expensive way to solve a mapping problem
Worth being direct about where we sit, since this page is published by a maintenance and inspection platform rather than by a full marine ERP. Marine Inspection is the maintenance and inspection layer — equipment registers, work orders, defects, parts and inventory, certificates — designed to feed procurement and finance rather than to replace them. If your requirement is one system covering technical, commercial, crewing and financial management on a single data model, that is a marine ERP decision and a different evaluation. If your finance and procurement systems are adequate and the gap is that crews cannot capture work properly at the machine, that is this shape.
What to Specify Before Anybody Builds
Each of these has a right answer specific to your operation, and each is expensive to change once a connector exists. Start a free trial and settle them in the specification rather than in testing.
Table 1: The Integration Specification
| Decision | The options | What to choose | Cost of getting it wrong |
|---|---|---|---|
| Commitment or actual | Invoices only, or purchase orders as well | Both, with commitments posting on approval | Budget overruns discovered weeks after the decision that caused them |
| Costing granularity | Vessel, system or component level | The deepest level you will genuinely analyse, chosen deliberately | Remapping historic data to change it later |
| Equipment link | Carried through every stage, or dropped after the requisition | Mandatory at every stage and tested end to end | Accurate totals that cannot answer which machinery costs what |
| Goods receipt capture | Ashore from paperwork, or on the vessel at delivery | On the vessel, offline-capable, synced afterwards | A broken middle leg, unmatched invoices and received-but-unaccounted stock |
| Partial deliveries | Exception, or normal case | Normal case, handled without manual intervention | A large share of orders throwing exceptions somebody has to clear |
| Match triggering | Automatic, or run manually | Automatic, with exceptions routed rather than parked | Matching becoming a weekly manual task and overpayments slipping through |
| Exception routing | A queue, or a named person with the discrepancy shown | Named, with what does not match and why displayed | Minutes of work becoming an hour of document archaeology |
| Unmapped items | Fail loudly, or post to a suspense account | Fail loudly, to somebody named | A suspense account nobody reviews and a mapping that silently drifts |
| Direction | One way out, one way in, or both | One way out first; add the return only where somebody has asked twice | A conflict rule you did not agree, discovered by a reverted value |
| Reconciliation | Periodic comparison, or trust | A scheduled check proving both systems still agree | Divergence accumulating invisibly until an audit finds it |
Questions for Both Vendors
Ask these of the maintenance platform and of the finance or procurement system, because an integration is only as good as the weaker of the two. Schedule a demo and put them in writing before a statement of work is drafted.
Table 2: Questions Before Signing
| Area | The question | A real answer | What should worry you |
|---|---|---|---|
| Commitments | Can an approved purchase order consume budget before any invoice exists? | Yes, demonstrated live against a budget code | Only invoiced spend, which makes the integration a reporting feed |
| Real-time visibility | Does a superintendent see remaining budget at the moment of approval? | Shown on the approval screen, not in a monthly report | Budget information available somewhere else entirely |
| Offline receipt | Can a crew member record a goods receipt with no connectivity? | Airplane mode demonstration, including a partial quantity | Receipt possible only ashore, from paperwork, later |
| Equipment traceability | Can I trace a ledger entry back to the component that caused it? | Demonstrated end to end on real data, both directions | Traceable to vessel only, which loses the analysis |
| Coding | How does free-text vessel wording become a codified, quotable line? | Automatic matching to marine stores and spares coding standards | Manual coding by somebody ashore, or none at all |
| Latency | How long between an event and it appearing on the other side? | A stated interval, with the mechanism named | An overnight batch, which defeats the point of commitment tracking |
| Chart of accounts | Can the coding be customised to our existing chart of accounts? | Yes, with the mapping owned and documented on both sides | A fixed scheme you have to adopt, or an unmaintained mapping |
| Failure behaviour | What happens to a transaction when the connection is down? | Queued, replayed, and alerted to a named person | Silence, which is how two systems diverge for months |
| Precedent | Which fleet exactly like ours runs this pairing today? | A contactable reference with comparable systems on both sides | A logo, an integration page, and nobody to speak to |
INTEGRATION REALITY
This page is published by a maintenance and inspection platform, not a marine ERP. Marine Inspection covers equipment registers, work orders, defects, inspections, parts and inventory, and certificate management, and is designed to feed procurement and finance systems rather than replace them. The case for a single integrated platform covering technical, commercial and financial management on one data model is real and is argued fairly in the relevant section above; which shape suits you depends on whether your existing finance and procurement systems are adequate. Capabilities vary considerably between systems on both sides. Whether commitments can post on approval, whether goods receipt is capturable offline, and whether coding standards are supported are questions for the specific products involved and should be answered in writing before scoping. The worked budget example is illustrative and drawn from published maritime accounting material rather than describing any particular deployment. Nothing here is accounting advice; treatment of commitments, accruals and cost allocation should be confirmed with your finance function.
Frequently Asked Questions
What is the single most important thing to specify?
That commitments post as well as actuals. Most integrations move invoiced spend to the ledger, which produces accurate accounts and changes nobody's behaviour because the money is already gone. The number that affects a decision is the commitment: when a vessel requisitions spares and a superintendent approves the purchase order, that value should appear immediately as a committed cost against the vessel's budget code with the remaining budget updated in real time. Maritime procurement platforms track consumption per cost account and cost centre from issued purchase orders as well as invoices precisely because the earlier number is the one that governs the next approval.
Why is the three-way match harder in shipping?
Because the middle leg happens on a ship. Matching a purchase order, a goods receipt and a supplier invoice is standard practice, and the order and invoice are unproblematic. The receipt is recorded by a crew member during a port call, under time pressure, frequently for a partial delivery because the full quantity did not arrive before sailing, and possibly with no connectivity at that moment. If that record does not reach the systems that need it, the match cannot complete and the invoice is paid unmatched or blocked. The standard failure case — a supplier shipping four hundred and twenty units against an order for five hundred and invoicing for five hundred — is more likely at sea, not less.
Where do these integrations usually break?
Cost centre mapping, because the two systems categorise the world differently and the reconciliation is a business decision rather than a technical one. A maintenance system organises by equipment; a finance system organises by account code, typically using standardised codes across major operating expenditure categories customised to the company's own chart of accounts. Three decisions have to be made before anybody builds anything: the costing granularity, which determines whether you can analyse spend by component or only by vessel; who owns the mapping on each side, since it needs maintaining whenever codes or vessels change; and what happens to an unmapped item, which should fail loudly to a named person rather than post to a suspense account.
What is the equipment link and why does it matter?
It is the reference to the specific component that caused the spend, carried from the original defect through the work order, requisition, purchase order, goods receipt and finally the ledger entry. Every hand-off between systems is an opportunity to drop it, and once dropped it cannot be recovered afterwards. Without it you end up with financially accurate reporting that cannot answer the question a technical director actually asks — which machinery is consuming the maintenance budget. Make it mandatory at every stage and test it end to end before go-live, rather than discovering at year end that spend is only analysable by vessel.
Should we buy one integrated system instead?
It is a legitimate option and the argument is fair. Keeping maintenance in a separate tool from finance forces reconciliation and delays cost visibility, whereas a combined system lets a work order reserve parts, raise a requisition, capture labour and accrue cost to the vessel automatically without an overnight interface. Against that, it is a much larger platform decision with a longer implementation and one vendor spanning functions with very different requirements. The practical test is whether your existing finance and procurement systems are working — replacing systems that work in order to avoid a mapping exercise is an expensive way to solve a mapping problem, and the reverse is also true.
Why does requisition coding come up in a finance integration?
Because coding is what makes the resulting data analysable, and without it the reporting that justified the integration cannot be produced. A requisition written by an engineer who knows what they need but not how a supplier catalogues it is unquotable by anyone else, which is why much marine procurement still runs on email clarification. Buying guidance for maritime procurement is blunt: the strongest tools match free-text requisitions to marine stores and spares coding standards automatically so a vaguely worded vessel request becomes a clean codified line, and a product that cannot handle those codes fluently should be treated as disqualifying. Without codes, spend analysis becomes text-matching across years of differently worded requests for the same item.
Specify these three
Commitments post on approval, not just invoices
The equipment link is mandatory at every stage
Goods receipt works offline, with partial deliveries as normal
Build the Control, Not the Accounting Feed
An integration that moves invoiced spend to the ledger produces tidy accounts and changes nothing. One that moves the commitment the moment a purchase order is approved changes what a superintendent decides that afternoon. Add an equipment reference that survives every hand-off and a goods receipt that a crew member can record at the quayside with no signal, and you have an integration worth maintaining. Leave any of the three out and you have built a monthly report with extra steps.
.png)
