Integrations are the step where TMS implementations either stay on schedule or quietly die. Here is the honest math: a prebuilt TMS integration goes live in days, while a custom build takes six weeks to six months and can cost more than the software itself. That one difference explains most of the gap between four-week implementations and eighteen-month ones. This guide maps every system a shipper typically connects, prices prebuilt connectors against custom builds, and gives you a script for auditing vendor connector claims, because "we integrate with that" is doing a lot of work in most sales decks.

What Is a TMS Integration?

A TMS integration is a live data connection between your transportation management system and another system it needs to exchange information with: orders in from the ERP, tenders out to carriers, status updates back, invoices over to finance. Integrations come in two flavors. A prebuilt connector is one the vendor has already built, productized, and maintains for every customer; your project just configures it. A custom integration is written for your project specifically, by someone's developers, on someone's schedule. Nearly everything else in this article is about that difference.

The Integration Map: Every System Your TMS Has to Talk To

A mid-market shipper typically needs five categories of connection. Before you evaluate any vendor, write down your version of this table. It becomes your integration inventory, and it belongs in your prep work before kickoff.

1. ERP (SAP, NetSuite, Oracle, Dynamics)

Usually the anchor integration. Orders, items, and customers flow into the TMS, and freight costs flow back for allocation to the GL. Connection is typically API or middleware. What to verify: a prebuilt connector for your specific ERP and version, since "we support SAP" can hide a lot of variation.

2. WMS / OMS

Sends shipment-ready orders, pick and pack status, and dock appointment data. Often an API connection. What to verify: whether it syncs in real time or on a batch schedule, and which one your operation actually needs.

3. Carriers

Tenders, rates, tracking, and shipping documents. Parcel and modern carriers connect by API; much of FTL and LTL still runs on EDI documents like the 204 load tender and 214 status update. What to verify: how many of your carriers are already live, not the total logo count.

4. Visibility and ELD platforms

Real-time location and predictive ETAs, connected by API to visibility networks or directly to ELD providers. What to verify: coverage across your actual carrier base, not the logos on the slide.

5. Finance and accounting

Invoices, freight audit results, GL coding, and payment status, connected by API, EDI, or flat file. What to verify: whether audit exceptions flow in both directions, so a disputed invoice doesn't get paid anyway.

Two notes on the carrier category, because that is where the volume lives. First, carrier integration is a numbers game: being connected to "carriers" means little, while being connected to your forty carriers means everything. Second, EDI is not legacy trivia. It is still the most common integration method for truckload tendering still runs on it, so a TMS that only speaks modern APIs leaves you building translations for half your carrier base.

What Does a TMS Integration Actually Cost?

The gap between the two paths is not subtle, which is why this is the first place to press any vendor for specifics.

A prebuilt connector goes live in days to two weeks, including testing, and is typically included in the subscription. The vendor configures it; your side of the work is granting credentials and system access. Maintenance is the vendor's problem, solved once for every customer. Schedule risk is low because the same connector is already running in production somewhere else.

A custom build runs six weeks to six months and roughly $15,000 to $100,000+ per integration depending on complexity. Someone's developers do the work: yours, the vendor's services team, or a paid third party. Maintenance is yours, permanently. Every break, version change, and API deprecation lands on your ticket queue, and the build sits in a development pipeline you don't control.

Now the part that decides timelines. The rest of a modern implementation (configuration, testing, training) is measured in days per phase. A custom integration is measured in months, and it sits on the critical path. It does not add to your timeline; it becomes your timeline. If you genuinely need one, the right plan runs everything else in parallel and phases go-live around the build. And the cost does not stop at launch: every ERP upgrade and every carrier API change afterward is a bill with your name on it.

How Do You Audit a Vendor's Connector Claims?

Every vendor says they integrate with everything. Three moves separate the claim from the reality.

Ask for the actual connector list, in writing. Then find your systems on it, down to the ERP version and the specific carriers you tender to.

Ask for a live reference. A current customer running the exact connector you need, at roughly your shipment volume. "Yes" is a scheduling question; anything else is an answer.

Learn the vocabulary. The same sentence can describe three very different realities:

• "We have a prebuilt connector for that." Possibly true, but verify it is productized, not a one-time past build. Ask to see it running, and ask to speak with a customer using it today.
• "We've integrated with that system before." Does it mean a custom build, once, for one customer's configuration? Ask: would I get that same connector, or a new build on my invoice?
• "It's on the roadmap." It does not exist. Ask for the committed date, and what happens to your price and timeline if it slips.
• "Our open API can connect to anything." True, and you or a paid partner do the connecting. Ask who writes, tests, and maintains that code, and at whose cost.

Run this audit before contracting, not during kickoff. It fits inside a broader set of implementation questions worth asking every vendor on your shortlist [link: vendor questions post].

The Best Single Predictor of Implementation Speed

If you can only evaluate one thing, evaluate the breadth and depth of the vendor's connector library. Not because it is a nice feature, but because of arithmetic: an implementation is a sequence of steps, and integration is the only step that swings from days to months. A vendor with hundreds of live, maintained connectors has effectively pre-run most of your project before you arrived. That is the structural reason modern implementations finish in weeks, and it is why platforms like Owlery invest in hundreds of prebuilt carrier and ERP connectors and use AI to migrate existing rates and workflows. The fastest integration project is the one that was finished before you showed up.

What If the Connector You Need Doesn't Exist?

It happens: a homegrown ERP, a niche regional carrier, a warehouse system from 2006. The absence of a connector is not the red flag. How the vendor responds is. A good vendor does four things:

• Says so plainly, and scopes the build with a fixed timeline and cost in the contract, not as a discovery-phase surprise
• Proposes an interim bridge, such as a scheduled flat-file exchange or middleware, so go-live does not wait on the build
• Phases the rollout so everything else launches on schedule and the custom connection joins when ready
• Builds it as a productized connector they maintain for future customers, rather than a one-off you inherit

If a vendor treats a missing connector as open-ended billable work with no committed date, you have just previewed the entire relationship.