| This article is part of our series on Custom Freight Brokerage TMS Development for US Freight Brokers and 3PLs: Building a Load Carrier Vetting and Settlement Platform |
Introduction — Four Connections Four Different Kinds of Work
Each of the four connections in this article is a unique type of work, and lumping all four together into one integration project is the best way to make sure the estimates are wrong. From a custom software development perspective, each connection needs to be scoped according to the relationship, workflow, and external dependencies involved. The shipper connection is based on an established standard, with license-based specifications and partner onboarding outside the scope of the integration project. Load boards are commercial API connections, with terms and usage restrictions. Telematics and visibility connections go through the consent layer to carrier-owned systems, not the brokerage. Factoring is simply about routing payments, and getting it wrong costs you dollars, not time.
Of the four relationships mentioned in this article, only one is mostly an engineering problem. The other three are relationships with technology, and it changes how the project should be scoped.
This article takes a closer look at each of these freight TMS integrations, from partner onboarding to reconciliation, the discipline necessary in a multi-partner system. To understand the workflow behind the connections, read our sister article on freight brokerage TMS features.
Shipper EDI — Tenders Status and Invoices
The Transaction Set and What It Costs to Implement
The primary exchange sequence goes like this. The shipper sends the load tender as an EDI 204 transaction. The reply is normally an EDI 990 accepting or rejecting it. The status messages go in EDI 214 as the load progresses. The sequence ends with an EDI 210 bill issued to the shipper for the shipment of the cargo. The functional acknowledgements, EDI 997, are sent to ensure all the messages were delivered to the other party. These transaction sets all belong to ANSI ASC X12 standards and are relatively stable, but the latest version and partner requirements should be verified before designing around them.
What most cost estimations don’t take into account is that the precise formats of these transactions are licensed products from X12, not open standards. Take that into account, together with the extra guidelines provided by individual shippers on top of the standard.
Status Messages Are Where Shippers Judge You
The 214 carries defined status and reason codes, and shippers judge a brokerage on whether the right code arrives at the right time, not on whether the load actually moved correctly. Mapping internal load states to the codes each shipper expects is more of the real work here than the transport layer itself, and shippers don’t all interpret the codes the same way. A picked up event that satisfies one shipper’s scorecard might need a different code for another shipper watching the exact same milestone. Getting this wrong shows up as a compliance scorecard problem long before anyone mentions an integration issue.
Transport and the API Alternative
Exchange typically runs over secure transfer protocols like AS2, value-added networks, or managed EDI connections, each carrying its own setup and monitoring overhead. Increasingly, shippers offer web-based interfaces alongside or instead of traditional EDI, particularly for mid-market accounts that never built out full EDI capability. This is where web application development becomes relevant for shipper and carrier portal workflows that need to operate alongside the integration layer. A platform serving a mixed customer base needs to support both, and the cleaner architecture treats them as two transport methods sitting over one internal load model rather than two separate systems that happen to move similar data.
Load Board Feeds
DAT and Truckstop each grant programmatic access to their services under a partnership scheme, not a self-service API. This type of access usually presupposes a business relationship with the provider, since a representative of the board has to review and approve the request for API credentials. A typical need of a brokerage includes three functions from the feed.
The first is posting loads to extend capacity beyond the network. The freshness of these postings, updated or removed as coverage changes, plays an important role here. An outdated posting wastes the time of carriers and damages the reputation of the brokerage on the board. The second is searching for available capacity, which should work alongside the brokerage’s internal carrier network rather than as a separate search. The third is using rate and market information to price loads accurately.
Two considerations matter when designing around board access. First, programmatic access carries fees and data usage limitations that depend on the business relationship. Second, carrier information returned by a load board search does not substitute for validating that carrier’s authority, insurance and identification.
Check API availability and pricing with each provider individually.
Carrier Telematics and Visibility
The tracking data comes from systems owned by the carrier itself, and it impacts every design decision covered in this section.
Two options are available here. Direct connectivity to telematics and ELD providers delivers the deepest and most accurate data, but it requires a separate connection to each provider and does not scale well once a brokerage is working with thousands of carriers running hundreds of different telematics and ELD systems. Visibility aggregators connect to multiple providers at once, including driver-facing mobile applications, trading some data depth for breadth of connections. An aggregator is the more practical choice for a brokerage working with thousands of carriers running different telematics and ELD solutions.
Consent is going to be the key here. Consent to share the visibility data is the choice of the carrier, and it is the consent that needs to be stored along with other data on the carrier and be instantly removed on revocation of this consent. The location data is personally identifying information of the driver and not shipment metadata.
Account for partial coverage. It is common for pings to be irregular even for compliant carriers, and a shipment lacking automatic tracking still requires some way to verify its status. Instead of treating a phone call as a fallback option, it is better to treat an automatic telematics ping and a manual verification call as two equally valuable pieces of input, coming from two different sources and each one carrying its own timestamp.
Build for that gap deliberately, because loads without reliable automatic tracking tend to be exactly the ones that need the closest attention. A purpose-built mobile app for driver-side document capture and consent handling is the logical answer here, and this is where custom mobile app development is more appropriate than a scaled-down version of a desktop tool.
Factoring and Payment Integration
Carriers assign their receivables and as such, the party the broker pays in almost all cases is not the carrier of the load but another entity. This is a common practice in the industry and the platform design should take into consideration the fact that the process is standard and not an exception.
As far as the legal process goes, assignment of receivables is governed by Article 9 of the UCC, with the notice of assignment serving as the instrument that invokes it. The factor provides the notice of assignment to the brokerage informing the latter about the assignment of receivables of the carrier and instructing the broker to pay the factor and not the carrier. Paying the carrier after a valid notice of assignment has been filed does not discharge the brokerage’s obligation to the factor, which means the brokerage risks paying twice for the same load. Consult counsel as to exact obligations in this regard, since these may differ from place to place.
These obligations show directly how the process should be handled within the platform. All notices of assignments should be recorded against the carrier on file, including dates of issuance and automatic payment routing.
Verification matters here too, because fraudulent notices of assignment do circulate. A notice arriving by email should be confirmed with the factor through a known, independently verified channel before payment routing changes, not accepted at face value because it looks official.
Alongside NOA handling sits the brokerage’s own payment execution, whether by check, ACH, or a payment platform, plus quick pay and advance programs that typically carry their own separate terms and triggers. Accounting integration closes the loop, so settled amounts flow through to the general ledger without a second manual entry.
This section describes common industry practice, not legal advice. Confirm current requirements and jurisdiction-specific rules with counsel before finalizing how the platform handles NOA compliance.
Trading Partner Onboarding — The Schedule Item
Every EDI connection to a shipper carries its own requirements like mapping to that shipper’s specific interpretation of the standard, connectivity setup, testing within their environment, and their own timeline for acceptance, not the brokerage’s.
For a brokerage that just landed an enterprise client, this is often the longest outstanding item standing between the contract win and the first shipment moving, and it’s largely outside the brokerage’s control. The shipper’s IT department works through its own queue at its own pace.
The system needs to manage onboarding as trackable work per partner, what’s mapped, what’s tested, what’s still open, and what’s blocking go-live. The technical answer is to build each trading partner as an adapter over a stable internal load model, so the tenth connection becomes mostly a matter of configuration and mapping rather than new development. Any estimate that treats connectivity as a single line item doesn’t reflect how this actually goes.
Connectivity breadth and onboarding volume are one of the dominant variables in overall project cost, covered in more depth in our guide to custom freight brokerage TMS development cost.
Reconciliation and Failure Handling
Each of these connections fails quietly, and each fails in its own way. A tender that arrived but never became a load in the system. A status message a shipper’s system silently rejected. An invoice sent but never acknowledged. A board post that never actually cleared because coverage was never achieved. A tracking feed that simply stopped for a carrier without raising any alarm.
Each of these needs to land on a queue with an age and an owner attached, rather than being assumed to have succeeded.
Two checks matter enough to belong in any first release. The first is a daily reconciliation of tenders received against loads created in the system, since a tender that went silent and disappeared is also a load the customer believes is covered. The second is confirming that every delivered load has an invoice that was both sent and acknowledged. An unacknowledged invoice is a cash flow problem for the brokerage that surfaces as a receivable months down the line.
Final Thoughts
Teams that estimate each connection for what it actually is, licensed standards with per-partner onboarding outside their control, commercial board relationships with real usage terms, consent-governed access to systems the carrier owns, and payment routing where errors cost money directly, tend to produce plans that hold up under real conditions. The reconciliation layer on top is what stops tenders, invoices, and payments from quietly disappearing between systems while everyone assumes the integration is working.
If connectivity is central to your platform, scoping it per trading partner rather than as one integration, and treating onboarding timelines as a schedule dependency you don’t control, is what keeps the connectivity work from setting the project’s date. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
