In transport and forwarding, the work is often eaten not by the haul itself but by everything around it. An order comes in by email, confirmation returns as a PDF, the CMR note travels with the driver, and the rate sits in one person’s spreadsheet. For a transport or settlement director that adds up to one thing: information about an order scatters across dozens of places, and none of them is the source of truth. A well-designed TMS software platform pulls that flow together, from order intake to invoicing.
In our experience, the hard part is not drawing an “order list” screen but closing the full chain of documents and money so that it reconciles - what matters here is data consistency, auditability and integrations, not a flashy interface. We do not pretend to own a box that fits every forwarding business; instead, we staff the project with people who design and maintain such systems, in a team-augmentation or dedicated-team model.
Why does freight drown in paperwork and email?
Paper and an inbox work fine while volume is low. Trouble starts with scale: every route change, rate correction and missing document calls for manual copy-paste, and settlement is done “from memory”. We usually see a few recurring sources of friction:
- orders in many channels at once (email, phone, customer portal, EDI), with no single registry,
- loose documents in PDFs and scans, detached from a specific shipment,
- rates in spreadsheets that never keep up with annexes and fuel surcharges,
- settlement at month-end, when half the details are already forgotten.
How do we organise order and shipment records?
The foundation of a TMS is a consistent registry where the order, the shipment and the documents are one connected record, not three separate worlds. We design it around the forwarder’s real workflow: the layer carries an order through its statuses, from intake, through carrier and vehicle assignment, to delivery and closing, and every change leaves a trace. We describe each shipment with the attributes used in settlement and reporting (dimensions, weight, pallet count, Incoterms, route, carrier), and the same data then drives rating and the invoice.
What is e-CMR, and how do we digitise transport documents?
The classic CMR consignment note is paper with signatures, easy to lose and hard to search. e-CMR is its electronic equivalent, based on the additional protocol to the CMR convention, with a digital signature and a timestamp instead of a pen. For settlement that changes the rules: the document is available right after delivery, not a week later when the driver’s folder comes back.
On document projects we wire the flow so that every document is pinned to a specific shipment and status. We digitise not only the e-CMR itself but the whole family of transport papers: proof of delivery (POD), orders, warehouse documents, packing lists. Where a client still needs paper, we keep a printout consistent with the digital version.
How do you prepare data for customs clearance?
On international moves, customs clearance needs data that is complete and consistent, or the shipment stops at the border. A TMS can prepare that data once, at the source, and hand it on rather than forcing a re-entry into yet another system.
We add the fields needed for declarations to the registry: customs tariff codes (HS/CN), country of origin, goods value, weight, shipper and consignee data. Since we do not pretend to be a customs agency, we design a clean export and integration with customs systems or a broker: the data leaves in an agreed format, ready to declare.
How does the rate and tariff engine work?
A freight rate is rarely a single number. It is usually a tariff that depends on the lane, weight, volume, zones, fuel surcharges and individual annexes with the client, and when all of that lives in a spreadsheet, every change is a risk. That is why the heart of a TMS is a rating engine that computes the rate from rules, not from a salesperson’s memory.
We assemble such an engine from a few elements that have to play together:
- price lists and tariffs per client, lane, zone and cargo type,
- surcharge rules (fuel, customs, ADR, booking) applied automatically,
- versioned price lists with validity dates, so an old rate never lands on a new order,
- simulation and comparison of variants before an order is confirmed.
The same logic prices an order on the way in and settles it on the way out, so the quote and the invoice finally match.
How do we automate invoicing and settlement?
Settlement exposes every earlier gap. If order data, documents and rates sit in one place, the invoice and the carrier settlement almost write themselves. We build a settlement layer that compares what was agreed with what was actually done and catches the differences before they reach accounting.
This layer does several things at once: it calculates the customer charge and the carrier cost, collects surcharges and corrections, checks that the full set of documents (POD, e-CMR) is in place, and prepares data for the finance and accounting system. Carrier settlement runs on the same logic, so the margin is visible on every order, not only in the monthly report.
How do you connect a TMS with EDI and ERP?
A TMS does not live alone. On one side there are clients and their orders over EDI; on the other, ERP, accounting, telematics and carrier portals. The system’s value grows where it stops being an island.
We connect a TMS to its surroundings so data circulates without manual re-keying:
- EDI (e.g. EDIFACT, IFTMIN/IFTSTA messages) to exchange orders and statuses with clients,
- ERP and the accounting system for invoices, costs and partner records,
- telematics and GPS for delivery statuses and times on the route,
- APIs and webhooks to customer portals and freight exchanges.
We treat each integration as a contract: an agreed format, error handling, retries and monitoring, so one bad message does not stall the whole flow.
Which skills do we provide for a TMS project?
On this topic we do not sell an off-the-shelf rollout; we provide the people who can design, build and maintain such a system. We shape the team around the specific scope, not just in case, and usually staff the roles that actually push a TMS project forward:
- an analyst / architect who understands forwarding processes and maps them onto a data model,
- a backend developer building the rating engine, settlement and the integration layer,
- a frontend developer owning a readable forwarder and settlement panel,
- an integration / EDI specialist linking the TMS to ERP, customs and telematics,
- optionally a DevOps specialist who sets up environments, the CI/CD pipeline and monitoring.
We verify skills before the start and plug the team into the client’s rhythm.
How do we do it at RITS?
We do it as a nearshore partner from Poland, with experience in projects of high data and integration complexity. We do not pretend to have a TMS rollout for a specific forwarder in a drawer; instead we deliver the competencies that close such a project, from analysis to maintenance.
First we understand the process, and only then do we pick the technology and the team. We work in a close time zone, so the team joins without a long ramp-up and gradually takes ownership of the order, document and settlement flow. Most often we operate as custom software built by our team, or as team augmentation when missing skills need topping up fast.
Where to start building a TMS?
Start from the single most painful stretch, usually the path from order to invoice. It reveals which data is missing, which documents need digitising, and where the tariff drifts from the settlement. The rest of the modules then stack onto the same foundation. We covered the differences between engagement models in our article on IT engagement models.
Sorting out freight, documents and settlement? Let’s talk - we’ll match a team and an architecture to your TMS.