Why a TMS isn't enough

The freight software category that most operators encounter first is the Transportation Management System. A TMS is for planning and executing shipments — rating, routing, booking, visibility. Good TMS products do these things well.

A freight forwarder's day is not mostly planning and executing shipments.

A freight forwarder's day is reading 400 inbound emails, typing booking details into a spreadsheet, reconciling a carrier invoice against a quote, drafting an arrival notice at 11pm, chasing a customs broker for a filing status, arguing about a demurrage charge with a terminal, writing a House B/L with the correct Incoterm, running a sanctions screen, generating a packing list in the customer's format, and then doing planning and executing the shipment.

The TMS covers 20% of the workload. The other 80% still happens in Outlook, Excel, WhatsApp and the accounting package.

What a TMS is good at

• Rate management. Loading carrier contracts, calculating rates for a given origin/destination/commodity, comparing quotes across carriers.
• Booking. Sending rate requests to carrier APIs, receiving confirmations, generating shipment records in the system.
• Routing. Picking the best vessel, the best consolidation, the best handoff.
• Visibility. Pulling vessel positions, ETAs, and status milestones from carriers and AIS feeds.

If that's the whole job — if you're a 3PL running point-to-point container moves on a handful of lanes — a TMS might be enough.

What a TMS doesn't do

Intake. The TMS assumes the booking data is already structured. It doesn't read inbound email, parse a shipper's booking request PDF, or extract HS codes from a commodity description.

Documents. Most TMS products don't generate House B/Ls, customs records, packing lists, or invoices to customer-specific templates. That's a document management module (sometimes called eDoc or doc control) that's usually sold separately.

Compliance. HS classification, denied-party screening, and country-specific rules are usually a separate compliance suite — Descartes, E2Open, and a handful of region-specific tools.

Finance. Per-shipment P&L, customer invoicing, multi-branch accounting, and ERP reconciliation are usually done in SAP, QuickBooks, Xero or a standalone accounting tool. The TMS hands off to finance; it doesn't close the loop.

Exceptions. Most TMS exception handling is a flag on a shipment card. "Delay: yes/no." The workflow that decides who gets notified, who responds, what gets re-booked, what the customer sees lives outside the TMS — in ops chat, phone calls, and ad-hoc scripts.

The integration tax

Some forwarders solve this by buying a TMS, a doc tool, a compliance tool, and an accounting tool, then integrating them. This works, expensively. The integration layer becomes its own product: its own bugs, its own outages, its own team.

And the biggest problem is that the source of truth fractures. The shipment record in the TMS doesn't match the record in the doc tool, which doesn't match the record in finance. Every reconciliation becomes a five-system investigation.

What one record looks like

CargoGen starts from one record. Every module reads and writes the same shipment. A change in booking data propagates to the house bill, the invoice and the customs entry, and the documents that arrive are read into that record by AI instead of typed into three systems.

This is not a TMS with more modules. It's a different decomposition. The units aren't "rate / book / route / track." They're "operate / document / comply / settle." They share a single shipment record.

The question to ask about any freight software isn't "does it have a TMS module?" It's "when shipment data changes, where does that propagate, and what breaks?"