Freight forwarding automation: documents and status updates

An order number is not always sufficient. An order may contain several consignments, transport legs or deliveries. A document may also concern several items. Before processing starts, define the level of reference the TMS needs for the particular workflow.

The following table shows five kinds of transport information, what to check before transferring each into the TMS and the typical mistake.

AI can suggest information extracted from emails and attachments. Field checks govern its transfer into the operating system. Where several orders plausibly match, a visible clarification task is better than filing against the first result. Preserve the information's origin so that dispatch can verify a number against the document.

Standards. Transport partners may exchange structured data or continue sending PDFs and free text. UNECE describes UN/EDIFACT standards for structured data exchange. The current UN/CEFACT Web Vocabulary provides shared terminology for trade, transport and other domains. Sources checked on 26 September 2026.

Shared meaning. In a practical project, use available structured fields before extracting the same information again from a rendered document. Also agree what a status or unit means on each side. A technically readable field does not prove that sender and recipient use the same meaning.

TMS operations. Confirm the required operations with the TMS provider: read an existing case, link a document, create a task and receive acknowledgement. A general statement about TMS integration establishes neither write permissions nor supported document types in your installation.

Synthetic example: A photograph of a delivery record arrives for a transport with two delivery locations. The internal reference is legible. A quantity appears for the first location, while the section covering the second delivery has been cropped off. At the same time, the customer asks whether everything has been delivered.

The workflow in this synthetic example then handles the incomplete delivery record in three steps: processing, review and handling any resubmission.

1. Processing. The workflow connects the image to the transport and flags the missing page or incomplete section. It records “document received” and the extracted information, but does not mark the entire order as fully delivered. A prepared dispatch task identifies the affected transport leg and links to the original image.
2. Review. The responsible person checks other available reports and requests the missing evidence if necessary. A customer reply can explain the state actually confirmed. It must not confirm the second delivery simply because the first is documented or the planned arrival time has passed.
3. If another scan arrives. If a complete scan arrives later, it is linked as additional evidence. The earlier handling state remains traceable, and the open task closes only after review. Receiving the same photograph again should not create a second transport case or another identical request for missing information.

This example illustrates the division of work: automation finds, matches and flags information; the professionally responsible process determines which confirmation the available evidence supports. The workflow does not establish the legal validity of the document merely by reading it successfully.

Three times. Separate reporting time, event time and planned time. An email received at 14:00 may describe something that happened at 11:00. Recording only receipt time can allow a delayed message to overwrite a more recent operational state incorrectly.

Source and confirmation. Each status response should have an identifiable source and confirmation time. A forecast remains a forecast. If the last update is too old to support a useful answer, create a dispatch question instead of presenting apparently current certainty.

Recipients. Also define which recipients may receive which information. The customer needs a status update about the commissioned transport. Another participant may need only the loading time and reference, without the full pricing discussion or customer correspondence. Checking the recipient is therefore part of checking every outgoing message.

Changes, not new orders. A revised unloading location, additional packages or a new time window may concern an existing order. Such messages should not silently create another order. Identify them as changes and show which previous information is affected.

Decision. The responsible process decides whether a change can be accepted and what it means for capacity, price and execution. AI can assemble the differences, but cannot replace missing agreement. A prepared status reply needs review again when a material order change occurs.

Special requirements. Refer customs, dangerous-goods and other special requirements to the designated specialist. This administrative workflow makes neither legal assessments of document validity nor professional decisions about transport clearance. Unknown fields remain visibly unknown rather than being filled with plausible-looking information.

Languages. This matters across languages as well. A translated place name or abbreviation should not replace the confirmed reference used by the operational system. Keep the original value available whenever interpretation could change routing or meaning.

Named exceptions. “Processing failed” provides little help. The work queue should distinguish an ambiguous order, unreadable document, missing required field, change awaiting a decision and an unconfirmed destination update. Include the original source, recognised reference and specific next step.

Priority. Prioritise by operational significance. An unresolved match shortly before a loading window may be more urgent than an incomplete document for an otherwise completed case. Dispatch defines those rules; the model should not infer priority from a single exclamation mark.

Manual resolution. Record manual resolution when staff handle a case themselves. After a TMS outage, reconcile those cases before replaying outstanding actions. This avoids creating a second task for a question that has already been answered by telephone or through another channel.

An initial pilot can cover one incoming channel, one document type and one defined TMS action. Test ordinary documents alongside cropped scans, multiple delivery points, incorrect units, repeated references, delayed status reports and an outage after successful record creation.

Measure correct matches, active review time, outstanding requests for evidence and inaccurate customer confirmations. Counting automatically extracted pages is insufficient. The relevant question is whether dispatch searches less while still seeing clearly what has not been established.

For planning, bring an anonymised transport case containing at least one deliberate gap. It allows the proposed automation to demonstrate that it makes missing information visible and routes it to the right team for clarification.