The TMS is fine. The rekeying is what costs.
A TMS can only process what has been entered into it. Yet the documents that keep a carrier or a freight forwarder running come from outside, in the layout chosen by each customer, each shipper, each subcontractor. Between the document and the TMS, there is a person who reads and rekeys.
They arrive by email, as PDFs, as Excel files, sometimes as a photo on a messaging app. Each order is read, then rekeyed into the TMS field by field: shipper, consignee, dates, references, goods lines.
Signed documents come back at the end of the run, sometimes creased or photographed. Delivery statuses are updated by hand, half a day or a night late.
Every charter or subcontractor invoice has to be matched against the corresponding order. For lack of time, checks are done by sampling, and discrepancies slip through.
Document volume follows truck volume. Data entry errors propagate all the way to invoicing, and knowledge of each customer’s layouts rests on one or two people.
Switching TMS does not solve the data entry problem.
It is tempting to assume the rekeying will disappear with a newer TMS. The experience of transport companies shows the opposite: replacing a TMS is a twelve- to eighteen-month project, with data migration, team retraining and a period where both systems run side by side. And the new TMS receives the same emails, the same PDFs and the same creased CMRs as the old one.
AIR.TEK’s AI layer replaces nothing. It sits on top of what you already have: your TMS remains the system of record, your dispatchers keep their screens and their habits. What changes is what lands in the TMS — data that is already read, already structured, already checked.
From the document received to the write into the TMS.
The order received by email or dropped as a PDF is recognized, numbered and dated out of the box; once the model is fine-tuned on your orders, its fields are extracted and the order is created in your TMS with the right references. The dispatcher only steps in on flagged cases.
The signed delivery note or CMR, scanned or photographed, updates the shipment status and is attached as proof of delivery to the corresponding order.
Every carrier or charter invoice is matched against the order and the delivery note. What matches is validated; only amount, quantity or reference discrepancies are shown to you.
The day’s shipments are grouped by carrier and the pre-alerts prepared automatically from TMS data.
Automated delivery note data entry: the use case →
Five integration routes, depending on what your TMS accepts.
No two TMS are alike, and none has to be modified. We pick the simplest route your tool allows; the mapping between extracted fields and your TMS fields is defined during setup, on your real files, then checked before the flow is opened.
If your TMS exposes an API, the AI writes to it directly: order creation, status update, document attachment. It is the most direct route.
Your TMS notifies the AI when an event occurs — an order created, a run closed — and the AI reacts with no intervention: reads the expected document, checks it, updates the record.
Documents are dropped in a folder; the AI reads them and drops back a file in a format your TMS can import. No development on the TMS side.
A dedicated address receives orders and documents from your customers and carriers. The AI reads the attachments and the message body, then feeds the TMS through one of the routes above.
For TMS or ERP systems with no API, the AI produces structured files that your tool imports on its own cycle. Simple, robust, reversible.
Never a blind write into your TMS.
Every extracted field comes with a confidence score. What is certain goes through; what is not — an ambiguous date, a consignee unknown to your database, an amount that does not match the order — is queued for validation with the reason for the doubt. A person decides in a few clicks.
The dispatcher no longer rereads everything, but never loses control: they see the exceptions and why they are there, and nothing is written into the TMS without a rule or a person having validated it.
A model specialized in transport documents.
Behind the automation is an extraction engine that combines character recognition with language-model reasoning. It runs in production at one customer on 195,000 real delivery notes and 2,365 layouts: 99.3% of documents validated (97.9% with no human touch), and, against human-verified ground truth, the issuer correct on 99.4% and the date on 98.9% of the documents validated automatically. It recognizes 36 transport document types, in 14 families — scanned, photographed or digital-native — and extracts the type, number, date and issuer out of the box; on delivery notes the extraction is complete, and for your transport orders, CMRs, proofs of delivery and invoices, it is fine-tuned on your own documents during the pilot.
The transport document engine →
On your server, with no page meter.
The engine is installed on your server, on your premises or in your hosting. Your orders, your rates, your customers and your volumes never pass through a third-party service, and the flow keeps running if the internet connection drops.
The license is annual, with unlimited volume within your server’s capacity: no per-page billing, no credits to top up. At several thousand documents a day, per-page billing no longer makes sense.
Sovereignty & GDPR: where your data lives →
Three ways to get rid of rekeying.
| Switching TMS | Generic per-page OCR | AIR.TEK AI layer on your TMS | |
|---|---|---|---|
| Time to set up | Several months to over a year | Fast, but templates need constant tuning | A few weeks for a first flow, measured during a pilot |
| Migration risk | High: data migration, retraining the teams | None | None: your TMS stays in place |
| Cost at high volume | Licenses per user and per module | Climbs with every page processed | Annual license, unlimited volume within your server’s capacity |
| Fit with your documents | Depends on the integrated vendors | One template per layout, to maintain | Specialized transport model, more than 10,000 layouts and issuers |
| Where your data goes | To the vendor, often in the cloud | To the OCR provider | On your server, on your premises |
TMS order entry automation: your questions.
Which TMS is it compatible with?
With your TMS, whichever it is. The AI does not replace your tool: it reads the documents and feeds the TMS through whichever route it accepts — API, webhooks, file drop, mailbox or CSV/JSON import. The route is chosen at kickoff, according to what your TMS and your IT team allow.
Does our TMS need an API?
No. An API makes the integration more direct, but an SFTP drop, a shared folder or a CSV/JSON import is enough to automate order entry.
Who does the mapping to our TMS fields?
AIR.TEK, during setup, with your dispatcher and, if needed, your vendor or your IT team. We list the fields of your TMS, define for each one where it is fed from in the document, and check the result on your real files before opening the flow.
What happens if a document is unreadable?
The AI does not guess. Every extracted field comes with a confidence score; if a field is unreadable or inconsistent, the document is queued for validation with the reason. A person completes it in a few clicks, and nothing is written into the TMS without that validation.
Where does our data go?
Nowhere. The engine is installed on your server, on your premises or in your hosting. Orders, delivery notes, CMRs and invoices never pass through a third-party service, and the automation keeps running if the internet connection drops.
How long does it take to get started?
A few weeks for a first flow — for example transport orders received by email — measured during a pilot on your real documents. The next flows (delivery notes, CMRs, invoices) are then added on the same installation.
What does it cost?
An annual license, unlimited volume within your server’s capacity, with no per-page billing or credits. It is quoted after a free 30-minute first call.