The single point that decides whether an electronic Oil Record Book is lawful is not the software. It is the flag Administration’s approval. The MARPOL amendments in IMO resolution MEPC.314(74), in force since 1 October 2020, allow an electronic record book in place of paper, but only one the ship’s Administration has approved. A type-approved product is the precondition; the flag state’s acceptance is the act that makes it legal on a particular ship. Buyers who treat the purchase as the finish line discover the gap at the first Port State Control inspection.
This article sets out what flag-state acceptance actually involves: the role MARPOL gives the Administration, the declaration the ship carries on board, and the steps an operator takes to move from a chosen system to an accepted one.
Why the flag state, and not the vendor, decides
MARPOL is enforced through flag states. A ship flies the flag of its Administration, and that Administration is responsible for ensuring the ship meets the convention, including the record-keeping duties in Annex I. When MEPC.314(74) added the electronic record book as an option, it kept that structure: the electronic system is approved by the Administration, so the authority to accept a digital ORB sits with the flag state, not with the company that built the software.
This is why no vendor can issue a binding declaration that its system is MARPOL-compliant for a given ship. A vendor can hold a type approval and supply the evidence a flag state asks for, but the approval that counts is the flag state’s. The practical effect is that the same product can be in use on one operator’s fleet and still need a separate acceptance step for another operator under a different flag.
The declaration the ship carries
MEPC.312(74) does not leave the on-board evidence to chance. The guidelines include a model Declaration of MARPOL Electronic Record Book, a statement issued under the Administration’s authority that records the ship is authorized to keep the relevant record book electronically and identifies the system in use. The ship carries that declaration on board, and it is what a Port State Control officer asks to see to confirm the electronic book is accepted rather than improvised.
So the document trail has two layers. The type approval, for example DNV Type Approval Programme No. 1-433.20, shows the product meets the technical framework. The flag-state declaration shows this ship is authorized to use it. An inspector who finds an electronic ORB with no declaration is entitled to treat the record-keeping as non-compliant, regardless of how good the software is, because the authorization is the thing MARPOL requires.
Type approval is the precondition, not the approval
It helps to keep the two apart. Type approval is a class society or recognized body confirming that a product meets the requirements that flow from MEPC.312(74): protection against undetected change, identification and signing of entries, inspection access, backup, retention. It is issued once for the product, not per ship.
New tonnage adds a second technical layer. The IACS unified requirements UR E26 on cyber resilience of ships and UR E27 on cyber resilience of onboard systems apply to vessels contracted for construction on or after 1 July 2024, and they reach onboard software like an e-ORB. So for a newbuilding the system’s cyber posture is part of the picture the flag state and class society consider. None of this replaces the flag-state acceptance; it is the evidence that supports it.
The operator’s path to acceptance
For an operator the path has a clear order. Start by confirming the system holds a current type approval against the MEPC.312(74) framework from a recognized body, and that it meets the IACS UR E26 and E27 requirements where the fleet includes vessels contracted on or after 1 July 2024. That settles the product question before any flag-state paperwork begins.
Then approach the flag Administration for each ship, or for the fleet under that flag, with the type approval and whatever the Administration’s own procedure requires. Some flags publish a procedure for electronic record book approval; others handle it through the ship’s normal survey and certification channel. The output is the declaration the ship carries. The last step is operational: the crew has to know that the declaration is part of the documents a PSC officer will ask for, kept with the certificates, and that the paper fallback procedure still applies if the system is ever unavailable.
What this means for a fleet on several flags
A fleet spread across flag states does not get one acceptance. Each Administration approves for its own ships, so the operator runs the acceptance step per flag, even with a single product across the fleet. This is worth planning for, because it is the part of an e-ORB rollout that depends on bodies outside the operator’s control and outside the vendor’s, and its timing varies by flag.
The system can make the rest of the rollout uniform even when the approvals are not. ShipORB runs the same way on every vessel regardless of flag, so once a ship’s declaration is in hand the operation is identical across the fleet: the same offline entry workflow, the same hash-chained integrity, the same Master signing rule, the same inspection and export. The variation lives in the approval paperwork, not in how the book is kept.
The order that avoids the gap
The mistake that catches operators is treating acceptance as a formality to handle after deployment. The lawful order is the reverse: confirm the type approval, secure the flag-state declaration for each ship, then run the electronic book as the book of record, with paper as the fallback. A vessel keeping an electronic ORB without the declaration on board is keeping a record a PSC officer can reject, no matter how sound the integrity controls are.
Handled in the right order, the approval is a one-time gate per ship, not a recurring cost, and it is the step that turns a capable system into a compliant one. The compliance page sets out how ShipORB meets the MEPC.312(74) framework that the type approval rests on, and the contact team can help map the acceptance path for a specific flag.