It starts well, but the TMS integration breaks down
The first obstacle is the integration between the digital waybill and the existing TMS. Every TMS stores shipment data slightly differently: different field names, different codes for goods descriptions, different logic for identifying the sender in a subcontract. When the e-CMR needs to be populated automatically from the TMS, it becomes clear there is no uniform data structure. Field X in the TMS does not map one-to-one to the CMR field. The immediate response is to build a mapping table. That works, until a new client comes along with a non-standard delivery address format, or a subcontractor who codes their runs differently. The mapping grows and becomes fragile. What is actually needed is an agreed data model at the shipment level, before the waybill is even created. That is not a technical problem; it is a configuration issue that should have been resolved much earlier in the project.
Why drivers keep bypassing the portal
Even when the integration works, the e-CMR is not in use everywhere. Some drivers complete the digital waybill correctly. Others print it out, have it signed on paper, and scan it back in afterwards. Sometimes that is habit; sometimes the recipient is unfamiliar with the portal or has no access to it. Shippers on the other side of the chain sometimes use their own system and send a PDF. The result: the digital waybill exists alongside the paper version, and no one knows exactly which one takes precedence in a dispute. This is the point at which many companies build a temporary workaround that becomes permanent: a staff member manually processing the scan. The lesson is not that digitisation should wait. The lesson is that you map out the exceptions in advance and make a deliberate choice about which ones to include in the first phase and which to address later. Fully paperless from day one is not realistic for most operations.
Digital signature on receipt: where eFTI requirements create friction
The third breaking point is the verification step on receipt. The eFTI regulation requires that authorities be able to check digital freight information electronically, and from July 2027 member states are obliged to accept it. But what companies are already experiencing is that the way they record signatures and timestamps does not always align with those requirements. A signature on a tablet saved as a PNG in the TMS is not the same as a qualified electronic signature that is legally equivalent to a handwritten one. Timestamps must be traceable, not only within the company's own system but also for an external party carrying out a check. In practice, the timestamp exists but the time zone is incorrect, or the format is not machine-readable. These are details you only discover when you encounter your first inspection or claim. It is better to ask at the design stage: what exactly must an enforcement officer or insurer be able to see, and in what format? Most projects ask that question too late.
When is fully digitising the waybill still the wrong step?
There are situations where it is more honest to say: not yet. If the TMS has no stable API and the shipment data structure changes every month due to growth or mergers, building a solid eCMR integration is building on shifting ground. If a large proportion of recipients have no digital acceptance process, a well-designed driver app only solves your side of the chain. And if the legal team has not yet determined which signature standard to use, you are building something that will not hold up at the first claim. Digitising the waybill is not a checkbox on an eFTI checklist. It is a chain-wide problem that you only solve when all links participate, or when you make a deliberate choice about which links to include in the first phase and which to leave for later.
What does work as a starting point
The successful projects we see start small: one partner, one corridor, one type of shipment. Within that scope you build the TMS integration, work through the exceptions, and validate the verification step with the recipient. Only then do you scale up. That sounds slow, but it is faster than a broadly rolled-out solution that, after three months, still has paper running alongside it on half of all runs. An AI Worker that recognises incoming documents, separates exceptions from standard cases, and populates the correct fields in the TMS helps during the transition. But that Worker does not replace a sound data model. You need both.