A freight brokerage is a simple business described by three systems that disagree with each other. A customer tenders a load. A carrier moves it. The brokerage invoices the customer, pays the carrier and keeps the difference. That is the whole model, and it produces three records of the same load: one in the transportation management system, one in the CRM, and one in the accounting system. Each record is right about the part it owns and wrong, or silent, about the rest.
Most brokerages do not notice this until the load reaches the invoice. That is the moment the three records are forced to agree, and the moment somebody in the office finds out that they do not. This post is about why that happens, what it costs, and why the fix is not a fourth system.
The TMS owns the load. It holds the lane, the pickup and delivery windows, the carrier assignment, the rate confirmation, the tracking updates and the proof of delivery. It is the system your dispatchers live in and it is usually the one that is most correct about the physical movement.
The CRM owns the customer. It holds the shipper's contacts, the quoted rates, the volume commitments, the accessorial terms agreed on a call in March, the credit limit and the history of who promised what. A brokerage that wants to grow needs this record, because the next load comes from the relationship, not from the load board. Most of the search traffic for a freight broker CRM comes from operators who have just realised the TMS cannot hold this.
The accounting system owns the money. It holds the customer invoice, the carrier bill, the factoring arrangement if there is one, the fuel surcharge as it was actually calculated, the payment terms and the ageing. It is the record the bank and the auditor believe.
None of these three is wrong to exist. The trouble is that the load moves through all three, and nothing carries it. A dispatcher builds the load in the TMS from a rate that lives in the CRM, by looking at one screen and typing into another. The accounting clerk builds the invoice from the TMS by doing the same thing in the other direction. Every hand-off is a re-key, and every re-key is a place where the three records drift apart.
Until the invoice, the drift is invisible. The load moved. The carrier was paid. Nobody compares the CRM's quoted rate with the TMS's billed rate with the accounting system's invoiced rate, because there is no report that shows all three, because they are in three systems.
The invoice changes that, because the customer compares them for you. Their accounts payable team has the rate confirmation and the quote and the invoice, and if any two disagree, the invoice goes into dispute. Here is what a disputed invoice actually costs a brokerage.
Days sales outstanding. A disputed invoice does not age from the invoice date. It ages from the day the dispute is resolved, which is the day somebody found the email from March. Brokerages we have looked at carry twenty to forty days of extra DSO on disputed lanes, on a business that is already financing carrier payments ahead of customer receipts.
Written-off accessorials. Detention, layover, lumper fees and truck-order-not-used charges are agreed with the customer in the CRM, incurred in the TMS, and billed from accounting. When the three do not connect, the easiest resolution to a dispute is to drop the accessorial. It is the margin on the load, and it goes quietly.
Margin nobody can see. The gross margin per load is the customer invoice minus the carrier bill. The customer invoice is in accounting. The carrier bill is in the TMS or in accounting depending on who set it up. The customer's target margin is in the CRM. Ask a brokerage owner for margin by lane for last quarter and watch how many spreadsheets it takes.
Office headcount that scales with loads. When each load needs a person to re-key it twice, the office grows with volume. The margin per load in a brokerage is thin enough that this is the difference between a business that scales and one that does not.
We have written before about what it costs a 3PL to leave billing to a warehouse system that was never built to bill. The brokerage problem is the same shape with no warehouse in it. The load never sits anywhere; it just crosses three systems on its way to an invoice.
The reflex, when the invoice disputes start, is to shop. Somebody suggests a TMS that has a CRM built in, or a CRM with a load module, or an all-in-one brokerage platform. These exist, and for a small brokerage with one or two dispatchers and a bookkeeper they can be the right answer.
For a brokerage past a certain size they usually are not, for a reason that has nothing to do with the software. Each of the three records has a different owner in your business, a different rhythm and a different definition of done. Dispatch closes a load when it delivers. Sales closes a customer when the volume commitment is signed. Accounting closes an invoice when it is paid. A single system that tries to be all three tends to be good at one, tolerable at another and a spreadsheet's worth of workarounds at the third. The brokerages that adopt an all-in-one most often end up running the all-in-one plus the system it was supposed to replace, which is four records instead of three.
The problem was never the count of systems. The problem is that the load is not carried between them. Fix the carrying and the three systems can stay.
The fix is a set of joins with a decision behind each one. We described the general principle in system of record versus source of truth, and for a brokerage it comes down to four decisions.
The quoted rate is agreed with the customer, so it belongs in the CRM, and the TMS should read it from there when the load is built, not have it typed in. If your dispatchers negotiate spot rates on the phone, the TMS is where the rate is born and the CRM should receive it. Either answer works. Having no answer is what produces two rates.
Accessorial terms are contractual and belong with the customer record. Accessorial events are operational and belong with the load. The invoice needs both, so the join has to carry the agreed terms to the load when it is built and the incurred events back to the invoice when it closes. This is the single join that recovers the most written-off margin, and almost nobody builds it.
Proof of delivery in the TMS should create the draft invoice in accounting, with the rate, the fuel surcharge and the incurred accessorials already on it, and the clerk's job becomes checking rather than building. The carrier bill should arrive the same way. When this join exists, margin per load exists as a number on the day the load delivers, not at month end.
If you run a customer portal, it should show the load from the TMS, the terms from the CRM and the invoice from accounting, and it can only do that if the joins above exist. A portal built on one system shows the customer one third of the truth, which is how portals end up generating support calls instead of reducing them.
We build this as an integration, not a replacement. The TMS stays. The accounting system stays. The CRM, which for the brokerages we work with is usually Zoho CRM because it holds the customer record well and connects to the rest without a licence fight, becomes the place where the customer and the terms live. The joins between the three are built to the four decisions above, and each one is written down before it is built so that the owner of each record agreed to it.
The order matters. The rate join comes first, because it stops the drift at the source. The invoice join comes second, because it is where the money is. The accessorials join comes third, because it needs both of the others. The portal, if you want one, comes last, because it is a view of work that is already correct.
We start with a no-risk discovery: a few days in which we map the three records, find where each load is being re-keyed, and put a number on what the disputes and the written-off accessorials are costing. At the end you get a written plan and a guaranteed estimate for the joins. If the numbers say an all-in-one platform is the better answer for your size, the plan says that, and you have lost nothing. If you are still deciding whether the answer is a new system at all, this piece on whether you need an ERP or just need your systems to talk is the place to start.
A brokerage runs three systems because the load, the customer and the money are genuinely three things with three owners. The cost is not the three systems; it is the re-keying between them, and it lands on the invoice as disputes, lost accessorials, long DSO and an office that grows with volume. The fix is four joins with a decision behind each, built in the order that stops the bleeding first. Buy the joins, not a fourth system.
In a no-risk discovery we follow an order from sale to shipment to invoice across your systems and show where it breaks and what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Commission Reconstruction: Why a Brokerage Runs on Four Systems, and What the Fourth One Costs. (article)
What It Costs to Run a Marketing Function as a System: Our All-In Numbers. (article)
The CRM holds the relationship: shipper contacts and their roles, quoted and contracted rates by lane, volume commitments, accessorial terms, credit limits, payment terms and the history of calls and promises. The TMS holds the movement: pickup and delivery windows, the carrier, the rate confirmation, tracking and proof of delivery. The test is simple. If the information exists before a load is tendered or after it is delivered, it belongs in the CRM.
Accessorials are charges beyond the line-haul rate for extra services or delays: detention when a truck waits at a dock, layover when a driver is held overnight, lumper fees for loading and unloading labour, truck ordered not used, and liftgate or residential delivery. The terms are agreed with the customer in advance, the events happen during the load, and both have to reach the invoice. When they do not, the charge is usually dropped.
Usually the TMS, because carrier records are operational: authority, insurance, compliance status, equipment and lane history all drive dispatch decisions. Carrier sales teams sometimes want carriers in the CRM to manage outreach, and that is fine as long as one system is named as the owner and the other reads from it. Two independent carrier lists are the carrier-side version of the three-record problem described above.
A brokerage pays carriers before customers pay it, so every extra day an invoice stays open is financed by the brokerage or by a factoring company at a fee. Days sales outstanding, or DSO, measures that gap. Disputed invoices extend it because the clock effectively restarts when the dispute is resolved. Reducing disputes at the source, by making the quote, the rate confirmation and the invoice agree, is one of the few ways to cut DSO without pressuring customers.
In a connected setup the system that owns the rate is updated once and the change flows to the other two, with a record of who changed it and why. The load in the TMS picks up the new rate, and the draft invoice in accounting reflects it. In a disconnected setup the change is typed into one system and the other two keep the old number, which is exactly the disagreement the customer finds at invoice time.
Not always. A brokerage with one or two dispatchers and a bookkeeper can often run on a TMS with a customer module and an accounting system, as the post notes. The CRM question becomes real when sales outreach, contracted rates and accessorial terms outgrow what the TMS holds, or when the business wants to grow through relationships rather than load boards. At that point the decision is not whether to add a CRM but how it connects.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
