Where freight brokers lose money

A West Bengal freight broker lost ₹85 lakhs to internal fraud over twelve months. Nobody noticed until the year was over. There was no single theft, no dramatic discovery, no one moment where an obviously wrong thing happened. There were dozens of small gaps between steps that each looked like normal business.

We built the system that replaced that operation, which meant first mapping precisely where the money had gone. What follows is that map. It generalises — the same six gaps appear in almost every brokerage running on Excel, WhatsApp and trust, in roughly this order.

None of these require a dishonest employee. They all get worse when one is present, but the structure leaks on its own.

Gap 1 — The rate that was never written down once

A trip is quoted to the customer over a phone call. A rate is agreed with the vehicle owner in a separate call. Both are recorded, if at all, in whichever place the person making the call prefers — a diary, a WhatsApp thread, a cell in a sheet.

The spread between those two numbers is the entire business. When the two halves live in different places and neither is authoritative, three things follow. Margin per trip cannot be computed reliably. Nobody can tell whether a specific trip was priced badly or priced normally. And anyone in the middle of both conversations can adjust one side without contradicting any record.

What closes it: both rates as fields on the same trip row, entered before dispatch, with changes versioned and attributed. Not a rate card — a rate card is a policy. The requirement is that the actual agreed numbers exist in one place, at the same time, tied to one identifier.

Gap 2 — Advances that exist in two systems and no ledger

The owner needs money at dispatch. Cash goes out, or fuel is authorised at a pump on credit, or both. In a spreadsheet operation these are recorded — somewhere. Usually in a cash book maintained by one person and a fuel register maintained by another.

The failure is not that advances go unrecorded. It is that nothing ties the advance to the trip at the moment it is given. Reconciliation happens later, from memory and paper, at settlement. And the gap between the giving and the tying is where an advance can be paid twice, or paid for a trip that never ran, or paid at one figure and settled at another.

What closes it: the advance posts automatically when the trip is dispatched. Not as a separate act of data entry that somebody may forget under pressure, but as a consequence of the state change. If dispatching a trip does not move money in your system, your system is not modelling your business.

Gap 3 — Pump credit, reconciled by hand

This one is specific to the industry and it is where a lot of money quietly sits. Fuel is drawn on credit at partner pumps. The pump sends a statement. Somebody matches slips to statement to trips, monthly, by hand.

At a few dozen trips that works. At several hundred it becomes a job that can only be done approximately, and approximation in a three-way match is indistinguishable from leakage. Slips go missing. Quantities get transposed. A slip gets matched to the wrong trip, and the rest of the month reconciles to a plausible-looking total anyway.

What closes it: a three-tier knock-off between slip, bill and payment, with manual allocation where the match is genuinely ambiguous, and no implicit rollovers. That last clause does most of the work. The moment a system is permitted to carry an unexplained difference forward as an opening balance, it has stopped being a record and become a story.

Gap 4 — Proof of delivery that lives on a phone

The delivery challan comes back signed. It is photographed. The photograph is in the WhatsApp history of whoever was on that trip.

Two costs follow, and the second is larger. The immediate cost is the time spent hunting for a challan when a customer disputes a delivery — commonly the difference between a dispute resolved in a day and one resolved in three weeks, which is three weeks of a payment not made.

The larger cost is that billing can run ahead of proof. If the invoice does not require the challan to exist in the system, invoices get raised for trips whose proof cannot be produced. Every one of those is a payment that can be legitimately withheld, and you will not find out which ones until the customer does.

What closes it: the challan is captured into the trip record at delivery, read field by field, and billing is blocked until it is there. On the system we built, extraction flags any field it is not confident about — typically nine of forty per document — for an operator to confirm before the trip can move on. We wrote separately about why that flagging matters more than the accuracy figure.

Gap 5 — Billing in the customer’s format, by retyping

Enterprise customers impose their own formats. A large steel customer wants their reference numbers, their line structure, their supporting annexures. So somebody retypes trip data into a customer-shaped template every billing cycle.

Retyping introduces errors, and errors in enterprise billing do not bounce — they sit in the customer’s system as a mismatch that delays the whole invoice, sometimes for a cycle. The cost is not the typo. It is the working capital.

There is a subtler version too. When formats are produced by hand, the mapping between your fields and the customer’s lives in a person’s head. We have seen an invoice number, an internal order number and a delivery-order number all present on the same customer document under labels that do not match their prefixes — a thing you learn once, painfully, and which is unrecoverable when that person leaves.

What closes it: bills generated from the trip record in the customer’s format, including the legacy paper layouts, so they can be printed and signed without retraining the counterparty. Match their format exactly — a “better” invoice layout is a change-management project you did not intend to run.

Gap 6 — Settlement as a monthly argument

At month end, owners come to settle. What was agreed, what was advanced, what was drawn in fuel, what deductions apply. Each of those lives in a different place, and the owner has their own record.

When both sides reconstruct the month from memory and partial paper, the settlement is decided by whoever argues better or has the better-kept notebook. It is not theft. It is a negotiation where the correct answer was available to nobody.

And this is where scale turns a nuisance into an impossibility. The operation we worked with had 181 owners behind 322 vehicles. Below about fifty counterparties, settlement is solvable from memory by a good operator. Above roughly a hundred and fifty it is structurally impossible, and the only open question is the size of the difference.

What closes it: a running per-owner ledger that posts as events happen — advance at dispatch, fuel at draw, deduction at delivery — so settlement is a statement to be reviewed rather than a month to be reconstructed.

The thing that ties all six together

Every gap above is the same gap, wearing different clothes: an event that moves money does not write a record at the moment it happens. The record gets written later, from memory, by somebody reconstructing. Reconstruction is where discretion enters, and discretion at scale is indistinguishable from leakage even when everyone is honest.

Which is why the system that replaced it is built around state changes rather than screens. A trip moves DRAFT → DISPATCHED → DELIVERED → COMPLETED, and each transition posts its own financial consequences automatically, with a database-level audit entry capturing who did it, from where, and what the values were before. There is no path where money moves and no row appears.

It took twenty days to build and imported 322 vehicles and 181 owners from the operator’s spreadsheet in one pass. The ₹85 lakhs was not recovered — that money is gone. What changed is that the same year, run again, would be visible by default.

If more than two of the five diagnostic questions above made you uncomfortable, the number is worth establishing before it is worth discussing software. That is what an audit is for.