Why a Freight Brokerage Runs Three Systems for One Load, and What It Costs at Invoice Time.
Updated: 2 days ago
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.
Three systems, one load.
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.
The invoice is where the drift becomes money.
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.
Why a fourth system does not fix it.
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.
What carrying the load actually means.
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.
Which system owns the rate.
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.
Which system owns the accessorials.
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.
When the load becomes an invoice.
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.
Which record the customer sees.
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.
What this looks like as a project.
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.
The short version.
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.
Find out where your orders, inventory and invoices stop agreeing.
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:
Comments