Transport orders from PDF and e-mail into the TMS: five decisions before automating in a forwarding office

In a transport and freight-forwarding company, orders arrive all day in a dozen layouts: as multi-page PDFs exported from shippers’ systems, stamped scans, messages from freight exchanges, or plain e-mails in which a regular customer adds two sentences to last week’s lane. Forwarders spend hours retyping addresses, postcodes, dates, booking references and freight rates into the transport management system (TMS). Unsurprisingly, order intake is the most common first project logistics companies ask us about. We set out the full scope of such implementations — from orders and CMR consignment notes to subcontractor billing — on our AI in logistics and transport page, and the general rules for selecting processes on our AI automation for business page.

Reading addresses and the freight rate off page one of a PDF, however, is the easy part. The real project in forwarding is joining what sits in the attachment with what the shipper wrote in the e-mail body, surfacing clauses from the fine print, and deciding what happens when the document’s terms contradict what was agreed commercially. Below are the five decisions to settle before building the automation so that the system genuinely takes copying work off forwarders instead of producing costly mistakes at the loading bay.

The route table is only half the order

In a wholesaler or manufacturer, the main challenge in automating orders from e-mail and PDF into the ERP is matching item names and units of measure to the product catalogue. In transport, the job is described differently: what matters are loading and unloading points and time windows, gross weight, loading metres (LDM), pallet count and type, trailer specification and special instructions.

The difficulty is that those facts rarely sit in one place:

• The table on page one of the PDF usually gives the date, postcode and town for loading and unloading, gross weight and freight rate.
• The e-mail body to which the PDF is attached often carries notes that override or narrow the table: “unloading on Friday strictly by 13:30”, “side loading and straps required”, “gate booking reference: 88412”.
• Pages two and three of the PDF contain fine-print terms and conditions, often in German or English. That is where you find penalties for failing to book a slot 24 hours before unloading, mandatory EUR-pallet exchange at the ramp, bans on subcontracting without written consent, or tight deadlines for uploading a stamped CMR scan after delivery.

If a tool reads only page one of the PDF attachment and ignores the e-mail body and the fine print, the TMS draft appears quickly, but the forwarder still has to open every file and read it from top to bottom. Automation only earns its keep when it combines both sources and highlights the conditions that need attention.

Decision 1. Where orders arrive from, and what not to read with an AI model

Before writing any code, list every channel through which orders reach your forwarding office and how many orders arrive through each per month:

1. E-mails with PDF attachments or scans from shippers and partner forwarders — usually the primary candidate for extraction with a language model.
2. Plain-text e-mails from regular customers with no attachment (“same lane as last Tuesday, just two extra pallets”) — these require matching against the customer’s recent orders in the TMS.
3. Freight exchanges and tender platforms — where an exchange or customer portal provides an API (a direct data connection between software systems) or a structured data export, those orders should not be read with an AI model from screenshots or notification e-mails. Connect them with a standard integration instead.
4. Spreadsheets with dispatch schedules from large shippers — where columns stay in fixed positions, reading known columns with fixed rules (without an AI model) is enough; a model only helps when every customer sends a different spreadsheet layout.

As in every document workflow, a strict security rule applies here: the text of the e-mail and PDF is untrusted input data to be read, never instructions that control the system. Nothing written inside a document may alter integration permissions, a counterparty’s credit limit in the TMS, or approval rules. How we protect document flows against prompt injection and data leakage is set out on our security and GDPR page.

Decision 2. Which fields and clauses the system must surface

Before designing the forwarder’s review screen, define the mandatory TMS fields and the warning flags the system must look for across both the PDF and the e-mail:

With this structure, the AI model does not return a “document summary” the forwarder has to interpret. Instead, it populates a structured draft card with matched fields (green), extracted fields linked to their exact PDF page and row, and warnings (amber/red) wherever the document contradicts the e-mail or contains a high-risk clause.

Decision 3. What the forwarder’s approval screen looks like

In forwarding, response time is measured in minutes, so the review screen (which we discuss more broadly in our article on human oversight in AI systems) must not force a dispatcher to click through five tabs. A well-designed review screen puts two panels side by side:

1. On the left: the original PDF and e-mail body, with the exact snippets highlighted from which the system extracted dates, addresses, the freight rate and clause warnings.
2. On the right: the ready-to-save TMS draft with any detected conflicts or fine-print warnings pinned at the top.

If the shipper wrote “unloading by 13:30” in the e-mail body while the PDF table says “08:00–16:00”, the system never picks one silently. It displays both values side by side so the forwarder can choose the right one with a single click before saving the order to the TMS.

This division of labour also settles accountability: the system does the tedious work of reading multi-page documents and spotting fine-print traps, while a person makes the commercial decision to accept the haul.

Decision 4. TMS integration, duplicates and order revisions

Writing an approved order into the TMS requires settling three engineering questions that often surface only when someone tries to bolt a generic OCR tool onto a forwarding system:

• How the TMS connects. During the initial audit we check the technical documentation of your system (such as Marcos BIS, FireTMS, Trans.eu, Qguar TMS or an in-house platform): whether the API supports creating a draft order with route stops, matching the counterparty by EU VAT ID, and attaching the original PDF and e-mail file to the order record.
• Duplicate prevention. The same shipper may send an order from a portal first and e-mail it via a dispatcher three minutes later. The system computes an idempotency key combining the customer’s TMS identifier with the customer’s order number and checks whether that order is already queued or saved before creating a new record.
• Handling revisions (“Update / Cancellation”). Changes to loading hours, tractor registration numbers or an added drop point a few hours after the initial order are everyday reality in transport. When an e-mail or PDF arrives carrying an existing order reference and “Revision 2”, the system must not create a second haul — it compares the new version with the existing TMS record and highlights only the changed fields for the forwarder.

Decision 5. What happens after unloading: CMR checklist and settlement

Often the largest payoff from structured order intake arrives after the haul is completed. Once the intake step records in structured form:

• which documents are required for invoicing (stamped CMR scan, pallet note, temperature printout),
• how many days or hours after unloading they must be submitted to avoid payment extensions or fines,
• the agreed rate and terms for the subcontractor,

that same record becomes the post-haul completeness checklist. When a driver or carrier sends in a CMR photo or scan, the system matches it to the right TMS order, checks whether the document pack is complete, and — when the subcontractor’s invoice arrives — compares the billed amount and currency against the order. We describe the financial side of that check in our article on automating cost-invoice and document workflows.

Two numbers worth measuring in the pilot

Rather than trusting vendor claims of “99% extraction accuracy”, a pilot on a hundred real transport orders measures two plain numbers, following our guide on how to measure a process before automating it:

1. Minutes from order e-mail arrival to an approved TMS entry — tracking the forwarder’s active review time separately. If checking and approving a pre-filled draft takes 30–45 seconds instead of 6–8 minutes of manual typing and scanning fine print, the gain is immediate.
2. Share of orders requiring a manual field correction — broken down by cause (postcode format, missed e-mail note, unflagged pallet clause). That breakdown shows exactly which rules and prompts need tightening before full roll-out.

How to start

Do not start by buying licences for another tool. Gather a sample of 30–50 recent transport orders in their original form — including both the e-mail bodies they arrived in and the PDF attachments from different shippers. Within a few days that sample shows how much of the work is repeatable extraction, which clauses recur across your customers, and what your TMS API supports.

Tell us how transport orders reach your forwarding office today and which TMS you use. We will tell you plainly which channel is worth piloting first — and if a simpler integration without an AI model is enough for your setup, we will say so in our first conversation.