The legal problem with electronic bills of lading was solved in 2023. The hard part — making a document that carries title behave correctly inside charter, cargo and ERP systems that were built for paper — is still sitting on most firms’ desks, unstarted.
For most of the container era, an electronic bill of lading was legally awkward under English law. A bill of lading is a document of title: whoever holds the original controls the goods and can transfer that control by endorsing and handing it over. Possession is the whole point, and the common law struggled to accept that you could “possess” a data record the way you possess a piece of paper. That is what the Electronic Trade Documents Act 2023 fixed. It came into force on 20 September 2023 and gives a qualifying electronic trade document the same legal status, effect and functionality as its paper equivalent — provided a reliable system secures it. The instrument is now viable. What it is not is a PDF.
What the law actually requires of the system
The Act is deliberately technology-neutral, but it is not requirement-neutral. Section 2 sets out gateway criteria that the underlying system has to satisfy before an electronic document counts as a trade document at all. In substance, the system must reliably identify the document, protect it against unauthorised alteration, and — this is the load-bearing part — secure that only one person can exercise control of it at any time, let that person demonstrate they have control, and ensure that transferring control divests the transferor. That last cluster is what practitioners call exclusive control: the digital equivalent of there being one original that changes hands, rather than a file that can be copied.
Free · 4 minutes
If your most senior engineer left tomorrow, would anyone still understand the system?
Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.
These principles are not a UK invention. They track the UNCITRAL Model Law on Electronic Transferable Records (MLETR), adopted in 2017, which frames the same idea as functional equivalence plus a reliability standard and a singularity-of-control requirement. The practical consequence for a technology function is straightforward and often overlooked: your obligation is not to store an eBL, it is to be able to prove, at any moment, who holds exclusive control and that nobody else does. “We have it in the system” is not the test. “We can evidence single, transferable control” is.
Why this is an interoperability build, not a format change
Nobody issues and holds an eBL in isolation. A bill of lading moves through a chain — carrier, shipper, forwarder, bank, consignee — and each party runs its own systems. Exclusive control has to survive being passed between them, which is why the market has settled on a small number of eBL platforms (the likes of WaveBL, Bolero, edoxOnline, IQAX and the systems run through GSBN) rather than a universal file format. Each platform is, in effect, a registry that guarantees singularity within its own walls. The awkward reality is that your counterparties will not all be on the platform you chose.
This is the same lesson finance functions are learning from the shift to structured electronic invoicing, where the format is the easy part and the system-to-system plumbing is the project — a pattern I have written about in the context of VAT in the Digital Age’s e-invoicing mandate. The Digital Container Shipping Association has been pushing standardisation precisely to make platforms interoperable; its member carriers committed in 2023 to 100% eBL adoption by 2030, with an interim target along the way. That target only means anything if a bill issued on one platform can be surrendered on another. Betting your integration on a single provider, with no plan for cross-platform transfer, is the dependency that will hurt.
The system touchpoints that decide whether it works
Treated seriously, an eBL touches more of the estate than teams expect. The ones that matter:
- Charter and voyage systems. The bill has to reconcile with the fixture, the cargo booked and the terms agreed. If your chartering platform cannot reference the eBL’s identity and status, you have digitised the document and left the commercial context on paper.
- Cargo and terminal operations. Release of goods at the discharge port is triggered by surrender of the original. That surrender is now an API event, not a physical hand-over, and the operational workflow at the terminal has to recognise it.
- ERP and finance. Trade finance, letters of credit and payment release hinge on the bank holding the document. The eBL has to flow into the ERP as a controlled object with a verifiable holder, not as an attachment on a record.
- P&I cover. The International Group of P&I Clubs approves specific electronic trading systems for the purposes of members’ cover. Use an unapproved system for a title document and you may find a liability sits outside the club’s standard cover. This is a governance check, not an IT one, and it belongs in the selection criteria from the start.
None of those integrations is exotic. All of them fail quietly if the eBL is treated as a replacement for the paper artefact rather than as a controlled, transferable record with its own lifecycle. The failure mode is not a system crash; it is a bill that cannot be surrendered on time, a payment that stalls, or a cargo held at the quay because the release event never reached the terminal system.
Where to start before your counterparties force it
The sequencing matters. Map the document’s journey through your own estate first — every system that today reads, references or acts on a paper bill of lading is a system that has to understand an eBL event tomorrow. Then decide the platform question with cross-platform transfer and P&I approval as hard constraints, not preferences. This is the same discipline as building the data backbone behind any regulated maritime obligation, which is why the reporting and integration lessons from CII and vessel performance data transfer directly: the value is in the wiring, not the document.
Adoption is being pulled forward by carriers and banks, not pushed by regulators, which means the deadline that matters is not a statutory one — it is the day a major counterparty tells you they will only transact by eBL. Firms that treated it as a PDF swap will discover, at that point, that they have bought a legally valid document their own systems cannot hold.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.