Replacing a traditional TMS: what must still happen after the ERP sends an order?
Key Takeaways
- After the ERP creates the order, ten jobs still have to happen, from the quote request to invoice payment and, where in scope, the ERP update.
- Under a traditional TMS, several of those jobs were done by a person outside the system, so switching the TMS off does not remove them.
- A cutover checklist names, for each job, who did it before, what proves it was done and what to verify before that lane leaves the TMS.
- Wilson, by Cartage, replaces the TMS for freight execution and connects to the ERP or order data flow, so the jobs can move lane by lane.
- A lane is ready when every post-order job has an owner, a recorded proof and an approval rule.
What still has to happen after the ERP sends the order once the TMS is gone?
Every job that moved the load after the order still has to happen: requesting quotes, chasing carriers, selecting and booking, confirming the pickup, tracking, handling exceptions, collecting the POD, auditing and paying the invoice, and updating the ERP where that is in scope.
The risk in a cutover is rarely the work the TMS did. It is the work the TMS only recorded, or never touched. In many companies the TMS held the load, the rate table and the tender status, while a coordinator's inbox held the second quote request, the pickup confirmation and the late-ETA call, and accounts payable matched invoices in another system. A replacement plan built from a list of TMS screens drops those jobs, and they come back in the first week as a missed pickup or a carrier asking to be paid.
Whether an AI logistics agent can take over the TMS role at all is covered in can an AI logistics agent replace your TMS. The question here is narrower: on the lane being moved, who does each post-order job the morning after cutover, and how will anyone know it was done?
Sort every post-order job by where it lived under the old setup
Before deciding what moves, find out where each job actually happened, because a job that lived outside the TMS has no screen to migrate. Three buckets cover most operations.
- Inside the TMS: the shipment record, tender status and stored contract rates.
- Around the TMS: work a person did by email or phone, sometimes typed in afterward: follow-up on silent carriers, pickup confirmation, check calls, rebooking and the POD chase.
- Beside the TMS: work in another system or team: invoice matching and payment in payables, status retyped into the ERP for sales, and delivery notices sent by customer service.
Take last week's orders on the lane you plan to move and walk each one through the ten jobs, tagging every job with its bucket and the person who did it. "Around" and "beside" jobs are the ones cutover plans most often miss. The steps up to a booked load are laid out in from ERP order to booked load; this checklist starts at the same order but runs through payment and the ERP update, because switching off the TMS affects all of it.
What counts as proof that each job was done
For every job, agree on the record that proves it happened, because "the coordinator handled it" cannot be checked once the coordinator stops handling it.
Before pickup, proof is messages and documents: which approved carriers were asked, the second ask to silent ones, the chosen quote beside the rate target, the carrier's acceptance and a rate confirmation whose rate and accessorials match the agreement.
In transit, proof is a status with its source: a carrier API, GPS or ELD data where it exists, the carrier's website by PRO number, or an email or call when none answer. An exception record shows what failed, who was told and that any new carrier came from the approved list.
After delivery, proof is paper and money: the signed POD, the invoice compared against the booked rate, and the approval the payment ran under.
Illustrative example: a distributor preparing one LTL lane finds that pickup confirmation and POD collection never appeared in its TMS. Both lived in one coordinator's sent folder, so both need an owner and a recorded proof before the lane moves.
Decision rules for switching off the TMS on one lane
Move a lane only when each post-order job has a named owner and a defined proof; if any job lacks either, the lane waits.
- One load, one system. Loads booked in the TMS before cutover finish there or get a named owner who closes them.
- Write approval limits first for booking above target, rebooking, invoice variances and payment release, each with the person who approves above it.
- Confirm the approved carriers for the lane, with current contacts, tender order and who gets the escalation when none accepts.
- Check tracking by carrier, not by lane.
- Decide write-back explicitly. If ERP updates are out of scope at first, name who updates the ERP meanwhile.
- Hold the lane if proof lives only in someone's inbox.
- Treat reference access as a company decision. How long the old TMS stays available for past loads is the company's call.
Once one lane runs cleanly through payment, the next lane reuses the checklist with its own carriers and limits.
The post-ERP-order cutover checklist
Fill one row per job for the lane being moved, using last week's orders.
| Post-order job | Who did it under the old TMS | Evidence it was done | Verify before switching off the lane |
|---|---|---|---|
| Quote request | Coordinator by email | Request to named approved carriers, timed | Carriers and contacts are current |
| Carrier follow-up | Coordinator, from the inbox | Second ask and reply on the shipment | Who acts if a carrier never answers |
| Selection under rules and approvals | Coordinator or manager, by habit | Quote, rate target, approval if above limit | Written target and approval limit |
| Booking and rate confirmation | Coordinator; TMS held tender status | Acceptance and matching rate confirmation | Rate confirmation checked against agreed rate |
| Pickup confirmation | Coordinator by phone | Confirmed, reconfirmed pickup window | Dispatch contact per carrier |
| Tracking | TMS feed or check calls | Status with source and time | Best source per carrier |
| Exceptions and rebooking | Coordinator, ad hoc | Notices sent, rebooking from approved carriers | Rebooking limits and approver |
| POD | Coordinator chasing | Signed POD on the shipment | Who needs the POD and where |
| Invoice audit, reconciliation, payment | Accounts payable, another system | Invoice vs booking, variance explained, approval | Payment rules and variance reviewer |
| Write-back where in scope | Retyping, or nobody | Status or cost visible in the ERP | Method agreed, or a named person |
A row with an empty evidence or verify cell means the lane is not ready.
How Wilson, by Cartage runs the post-order jobs on a moved lane
Wilson replaces the TMS for freight execution on the lanes the company moves, and it does the post-order jobs instead of recording that a person did them. It picks up orders from the existing data flow: an ERP feed, a scheduled file drop, a spreadsheet, email or an API. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica, and other ERP environments, with the exact connection depending on the customer's data flow and scope.
Wilson requests quotes from approved carriers by email, API or EDI where supported, follows up on silence, with phone calls where configured, and negotiates against the company's rate targets under its rules and approval limits. It books, sends the rate confirmation and BOL, confirms the pickup and tracks each load from the best source available. On an exception, it notifies the team in Slack or Microsoft Teams and initiates rebooking from the approved carrier list, within the rules or with approval. It collects the POD, audits and reconciles the invoice against the booking, and pays from the Wilson Wallet under approval rules. Write-back to the ERP is optional and scoped.
Wilson starts with assisted execution, and its scope can expand step by step. Messages, confirmations and changes are recorded in the shipment history, which fills the evidence column above. Customers can configure Wilson themselves or with the Cartage team, and Cartage helps map the first workflow during discovery. For the wider category, see what is an AI logistics agent.
Bring an order your TMS handled last week to a demo with Cartage and see Wilson run each post-order job on it, from the quote request to the paid invoice.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai