CMR XML, e-CMR and eFTI: different outputs, different requirements

Four different things, one document

A single CMR consignment note can exist in at least four forms, each with a different legal weight. Confusing them is common, because the underlying data — sender, consignee, goods, weight, signatures — looks the same in every form. What differs is the legal status attached to the form, and who is required to accept it.

Paper CMR

The baseline is the paper consignment note defined by the 1956 Convention on the Contract for the International Carriage of Goods by Road. It is signed by sender and carrier, and again by the consignee on delivery. It remains fully legal today; nothing in the eFTI Regulation or the e-CMR Protocol requires abandoning it.

e-CMR under the 2008 Protocol

The Additional Protocol to the CMR Convention concerning the electronic consignment note, from 2008, gives an electronic consignment note the same legal status as the paper original, in states that are party to the Protocol. The UN treaty depositary lists which states have ratified or acceded. Belgium has signed without ratifying. Croatia, Cyprus, Ireland, and Malta are not parties.

Legal equivalence is conditional, not automatic. The Protocol text requires that the electronic record maintain integrity throughout the operation, and that the method used allows authentication of the parties and the data. A file that merely holds the same information as a paper CMR, without those integrity and authentication guarantees, is not an e-CMR in the Protocol's sense.

eFTI submission

Regulation (EU) 2020/1056 addresses a different question again: how public authorities accept electronic regulatory and supervisory information. From 9 July 2027, authorities must accept such information when a business chooses to supply it through a certified eFTI platform (Commission timeline). The common data model and platform-certification approach are described in the eFTI4EU presentation. Certification requires conformity assessment by an accredited body and registration with a national competent authority — a process, not a file format.

Extraction XML

The fourth form is what a tool like eCMR Capture produces: an XML file generated by reading an existing paper or photographed CMR and structuring its contents. This is not a new legal instrument. It is a machine-readable representation of data that already exists on the source document.

What eCMR Capture's XML actually is

src/lib/extraction/efti-xml.ts in the eCMR Capture codebase serializes the 24-field extraction into XML using element names drawn from the UNECE eCMR Protocol vocabulary and the eFTI common data model conventions under Implementing Regulation (EU) 2024/2520. Each field carries a confidence and source attribute, reflecting how the value was obtained rather than asserting it as ground truth. A SchemaProfile metadata field in the document states plainly that the output is "pre-certification," and the file's own documentation comment lists what full conformance additionally requires: certification by an accredited conformity-assessment body, registration with the national competent authority, and the security, identification, and integrity guarantees set out in the implementing acts, such as electronic seals and an encrypted authority interface.

In practice, this XML is suitable for three things: a carrier-side preview of the data before eventual submission elsewhere, forwarding as input to a certified eFTI platform, and internal system-to-system handoff, such as TMS to accounting or to a customs broker. It is not suitable as a direct eFTI submission to an authority, and it is not, on its own, an e-CMR under the 2008 Protocol, because it carries no independent integrity or authentication guarantee beyond the confidence scores attached to each field.

Comparison table

Output	Legal status	Who accepts it	What else is needed
Paper CMR	Fully legal under the 1956 Convention	All parties, all authorities	Nothing; unconditional
e-CMR (2008 Protocol)	Equivalent to paper, where the Protocol is ratified	Parties in ratifying states	Integrity and authentication per the Protocol; not valid in non-party states
Certified eFTI submission	Regulatory acceptance channel under Reg. (EU) 2020/1056	Authorities, from 9 July 2027	A certified platform: conformity assessment and national registration
Extraction XML (e.g. eCMR Capture)	No independent legal status	Internal systems, or as input to a certified platform	Certification, or use strictly as internal/upstream data

How eCMR Capture fits

eCMR Capture extracts CMR data into JSON and an eFTI-vocabulary-shaped XML, explicitly marked not certified. It is useful as internal structured data or as input to a certified platform, not as a certified submission itself. Try it at /en/try; the API and XML output are documented at /docs.