eFTI data mapping: why your TMS should keep its own canonical model

The eFTI common data set is a regulatory exchange model

Delegated Regulation (EU) 2024/2024 establishes the eFTI common data set and data subsets used for regulatory information requirements. That model is designed to harmonise electronic exchange across legal requirements and transport modes.

A TMS, however, also contains planning, commercial and operational data that exists for entirely different reasons.

Do not redesign the TMS around the external schema

If every internal table and field is renamed or restructured to mirror an external regulatory model, specification changes become core product migrations.

A better pattern is a canonical internal model plus a versioned mapping layer that can produce the current eFTI representation.

• Identify the internal source of truth for each mapped data element.
• Record transformation and defaulting rules explicitly.
• Validate mandatory data before exposure.
• Version mappings independently from the TMS core.
• Keep regulatory identifiers separate from internal primary keys.

Data quality problems become visible early

Mapping work often reveals that the required information exists but is incomplete, free-form or owned by a different actor. That is valuable to discover before production integration.

The readiness project can then distinguish technical mapping gaps from business-process gaps such as missing shipper data or inconsistent location identifiers.

Subsets should be generated from context

Not every authority request needs every field in the common model. eFTI data subsets correspond to specific regulatory information requirements.

An adapter should therefore know which subset is relevant to the interaction and generate only the required representation rather than exporting a giant all-purpose payload.