What solutions exist for automating document flows at a freight forwarder?
Freight forwarders work with at least three types of document flows, each requiring a different approach. First, the bill of lading (CMR): paper that physically changes hands at loading and unloading, with all the associated delays. Second, customs declarations: structured messages via AGS (export), NCTS (transit) and ICS2 (import safety), which require a direct connection to customs authorities. Third, orders and accompanying documents from shippers: packing lists, invoices, certificates of origin, arriving by email, PDF or portal. Each layer has its own systems and its own specialists. An all-in-one solution that handles all three does exist, but it is rare and expensive. Most companies start with the layer under the most pressure.
e-CMR: which vendors digitise the bill of lading?
For the digital bill of lading, the most widely used parties in the Netherlands and Belgium are Transfollow (market leader in the Benelux, integrated with on-board computers and TMS systems), EDITEL (EDI specialist with an eCMR module called FreightLogs) and Teleroute/TIMOCOM (platform side, more focused on spot freight). The Dutch government is running a pilot extended to 2027; Germany, France and Poland now also accept e-CMR as legally valid. A practical point: e-CMR only covers the bill of lading. It does not bring in orders or handle declarations. Companies that expect e-CMR to solve their document problem are typically addressing only a small part of the work.
Automating customs declarations: AGS, NCTS and ICS2
Customs documentation requires specialised declaration systems that are certified by customs authorities and connected to European systems. The best-known parties in the Dutch market are Descartes (broad compliance suite, including Entry Summary Declarations for ICS2), CargoWise (full suite for large forwarders, including customs), Softpak and Stratech (both focused on the Dutch market, typically mid-sized freight forwarders). The choice depends heavily on declaration volume and the number of countries involved. At one hundred declarations per month, a lighter solution with an API connection to your TMS is often sufficient. Above one thousand declarations per month, you want a system that automatically pulls data from your orders and prepares the declaration for the employee, so the declarant only needs to review and submit.
Processing orders and accompanying documents: EDI, API or document AI?
Order flows from shippers rarely arrive in a clean, structured format. Large shippers send EDI (EDIFACT or XML via AS2), mid-sized shippers send a PDF purchase order by email, and small shippers call or email in free text. For the EDI side, parties such as Descartes and EDITEL have been active as network and converter providers for decades. For the PDF and email side, document AI is the most practical approach: the system reads the document, extracts the relevant fields (shipper, consignee, weight, Incoterm, HS code) and places them ready in your TMS or forwarding system. EasyData and Simac offer this as a service for transport and logistics. Bonsai's own product Dottle does the same, but as a built-in module in the core system or as a worker on existing systems. The honest distinction: SaaS services like EasyData get you up and running quickly, but you remain dependent on their roadmap and pricing model. If you build it into your own system, you own the data and the logic.
Decision framework: which approach fits your situation?
Use this as a rough guideline. Fewer than fifty shipments per day and no TMS of your own? Start with a SaaS package such as Transfollow for CMR and a certified declaration system for customs. Do you have an existing TMS (CargoWise, Alpega, Transporeon or custom-built) and want to connect document processing to it? Then an API or EDI integration combined with document AI is the logical step, without replacing your core system. Do you want to replace the core system itself because it is too old or too costly to maintain? Then a custom-built system with AI built in is a serious option: faster than a standard ERP implementation, and you become the owner of the code. Bonsai fits the third situation: we rebuild the core system from scratch, AI-native, and we run it until it is live in production. We are not the right fit for the first two situations: if you are looking for an additional module or a SaaS integration, the SaaS vendors mentioned are faster and cheaper. That is the honest answer.
