Rate Grid vs Rate Engine: The Data and the Code That Prices It

The two words are used interchangeably in freight software marketing, and they describe completely different things. A rate grid (also called a rate card, rate table or tariff) is a set of numbers that belongs to one carrier and one contract period: a zone map, a size axis, a price in every cell, a minimum charge. You do not author it — you receive it, usually as an Excel attachment.

A rate engine is code. It has no rates of its own. Its job is to take a shipment description and a grid and return a number, by executing a sequence of rules that are nowhere written in the grid: which weight is chargeable, how it is rounded, whether the next bracket up is cheaper, when the minimum charge bites, what the fuel surcharge applies to, which options are priced, and what margin is added on the sell side.

The practical consequence: rebuilding a tariff correctly is necessary and not sufficient. Two brokers holding the identical carrier grid will quote different prices for the identical shipment if their engines round differently, apply the fuel surcharge to a different base, or skip the paying-for check. Cargavo, a TMS for road freight brokers and transport commissionaires, treats the grid as data and the engine as one shared component — see the rate grids and pricing category for the surrounding topics, and the four types of road freight rate grids for the data side.

Every price a broker sends is the output of the same short pipeline. Written out, it makes obvious how little of the work the grid itself does.

Steps 2, 3, 5, 7 and 9 are the ones nobody writes on the tariff and everybody implements differently. They are also the ones that decide whether a quote is profitable. A spreadsheet can do step 4. It cannot reliably do step 5 across every bracket, or keep step 7 current every month, or guarantee step 9 was never skipped by a rep in a hurry.

Cargavo, a TMS for freight brokers of 2 to 25 people, runs these nine steps server-side on every quote, so the price shown in the customer portal and the price stored on the quote record are produced by the same execution. For the definition of the input to step 2, see chargeable weight in the glossary; for step 7, see fuel surcharge.

Most digitisation projects fail at this classification, not at the rebuild. A number is put in the wrong place, and from then on it is either impossible to update or updated in the wrong scope — a fuel index stored inside a rate cell, a margin baked into a “sell grid”, a volumetric ratio hard-coded for one carrier.

Read the right-hand column as an update calendar. Grid rows move once a year and move together — that is a re-import. Engine settings are configured once per grid and almost never touched. The fuel index moves monthly, alone, and must therefore be a field, never a number multiplied into the cells. Margin rows move for commercial reasons that have nothing to do with the carrier, which is why a margin can never live inside a grid: one grid serves every customer, and each customer has a different margin.

Cargavo, a TMS for freight brokers, enforces that separation structurally — margins sit on the customer record, not on the tariff. The consequences for pricing policy are covered in percentage vs fixed margin rules, and the rebuild mechanics in turning an Excel rate sheet into instant quotes.

Take a Zone 4 groupage tariff with a €78.00 minimum charge and these brackets: 500–999 kg at €19.80 per 100 kg, 1,000–1,999 kg at €15.20 per 100 kg, 2,000–2,999 kg at €12.60 per 100 kg. The shipment: 2 non-stackable pallets of 1.2 × 0.8 m, 1.7 m high, 820 kg gross, tail lift required at delivery. The customer’s margin rule is 18 % percent-type.

What the engine computes, line by line

• Gross weight: 820 kg.
• Volumetric weight: 2 × (1.2 × 0.8 × 1.7) = 3.264 m³ × 333 kg = 1,086.91 kg.
• LDM floor: 2 × 0.4 LDM = 0.8 LDM × 1,850 kg = 1,480 kg.
• Taxable weight: the highest of the three = 1,480 kg, already a multiple of 10 kg.
• Bracket lookup: 1,480 kg sits in 1,000–1,999 kg → 14.80 × €15.20 = €224.96.
• Paying-for test: declaring 2,000 kg would cost 20 × €12.60 = €252.00, so the engine keeps €224.96.
• Minimum charge: €78.00, not binding.
• Fuel surcharge: 14.5 % of the €224.96 linehaul = €32.62.
• Tail lift: €28.00, outside the fuel surcharge base.
• Buy price: 224.96 + 32.62 + 28.00 = €285.58.
• Sell price: 285.58 / (1 − 0.18) = €348.27, retaining €62.69 of margin.

Note what the grid contributed: €15.20, €12.60 and €78.00. Everything else — 333 kg per m³, 1,850 kg per LDM, the 10 kg rounding, the paying-for comparison, 14.5 %, and p/(1−m) — came from the engine. The tariff was three numbers; the price was nine decisions.

One trap worth pricing out: multiplying by 1.18 instead of dividing by 0.82 gives €336.98 and a real margin of 15.3 %, not 18 %. That is the markup-versus-margin confusion, quantified in margin-safe freight quoting; you can test your own numbers with the freight margin calculator and the chargeable weight calculator. Cargavo, a TMS for freight brokers, exposes only the €348.27 line to the customer — the €285.58 buy price and the €62.69 margin stay on the broker side.

The order in which the nine steps run is part of the engine’s definition, not a stylistic choice. Same grid, same shipment as above, three defensible-sounding orderings, three different answers.

The middle row is the one that hurts, because it looks reasonable. Marking up the €224.96 linehaul by 18 % gives €274.34, adding 14.5 % fuel on that gives €39.78, plus the €28.00 tail lift is €342.12. The cost is unchanged at €285.58, so the margin actually retained is €56.54 — 16.5 % of the sell price. Nobody made an arithmetic mistake; the engine simply ran the steps in a different order, and 1.5 margin points left the building on every shipment quoted that way.

The third row shows the same effect on the cost side: rounding 1,480 kg up to 1,500 kg makes the linehaul 15.00 × €15.20 = €228.00 and the buy price €288.62. That is legitimate if the carrier contract says so and expensive if it does not — the rounding rule is a contractual term you configure, not a default you inherit.

This is why “which engine” is a commercial question and not only a technical one. Cargavo, a TMS for road freight brokers, fixes one order — taxable weight, rounding, bracket, paying-for, minimum charge, fuel surcharge, options, then margin — and applies it identically to every grid type, whether weight_zone, pallet, mpl_bracket or hybrid_weight. The engine is documented so a broker can reproduce any quote by hand.

The usual architecture, arrived at accidentally, is two implementations: one that prices the sell side for quotes, and one that prices the buy side for cost reports, carrier invoice checks or margin dashboards. They start identical. They never stay identical, for three structural reasons.

• Fixes are applied once. A paying-for bug is found on the quote screen and fixed there. The cost report keeps the old behaviour, so reported margin stops matching real margin.
• Data sources drift. One path reads the fuel index from the grid, the other from a cached copy or a settings screen. The two are equal until the day someone updates only one.
• Rounding is never specified twice the same way. Round-half-up in one path, round-up in the other, on a value multiplied by a per-100 kg rate — small per shipment, systematic across a year.

What the divergence costs, in numbers

Keep the worked example. The carrier’s fuel index moves from 14.5 % to 17.2 %. The buy-side code picks it up: 224.96 × 17.2 % = €38.69, so the real cost becomes 224.96 + 38.69 + 28.00 = €291.65. The sell-side code still holds 14.5 %, so it keeps quoting €348.27. Margin retained: €56.62, or 16.3 % instead of the 18.0 % the customer record says. On 300 shipments that is €1,821 of margin that no report flags, because every report agrees with the code that produced the error.

The failure mode is not that prices are wrong. It is that they are plausibly wrong: within a few percent, in the right direction, on every quote. That is invisible until an annual reconciliation, and by then the quotes are sent and the loads are delivered.

Cargavo, a TMS for freight brokers, was built to make this class of bug unavailable: there is exactly one pricing implementation, and it is covered by tests that assert buy and sell agree on the same inputs. See carrier rate grid management for how tariff updates flow through it.

“One engine” is a precise claim, and it is testable. It means the buy price and the sell price are not two calculations that ought to agree — they are the same calculation, called twice, differing only by whether the margin step is enabled. Steps 1 to 8 of the pipeline are byte-for-byte the same execution. Only step 9 changes.

Three properties follow, and they are worth checking in any vendor demo.

Parity by construction

If a paying-for rule is corrected, both sides change in the same release, because there is only one place to change. The question “does your cost report match your quote screen?” stops being a question.

Server authority on money

The browser can run the engine to show an instant simulated price, but the price that is stored, sent and honoured is recomputed server-side. A price arriving from a client is never trusted. That is what makes a public-facing quote simulator safe to expose at all: a customer can open the developer console and still not move their own price.

Buy price never crosses the boundary

Because the margin step is the only difference between the two runs, the buy price and the margin can be kept in a separate record that the customer role cannot read — not hidden in the interface, but absent from the response. Cargavo, a TMS for freight brokers, stores quote financials in a private sub-record, which is the mechanism described in showing a price without revealing your buy rate.

The counterexample is a “sell grid”: a second table generated by applying margins to the buy grid, then stored. It looks efficient and it is a trap — margins become frozen at generation time, per-customer pricing multiplies the tables, and the day a tariff is re-imported the derived grids are stale until someone regenerates them. Margins are a step in the engine, not a table on disk.

Vendors use four or five names for overlapping components, which makes evaluation harder than it needs to be. The distinctions that matter are these.

How to test whether a product has a real engine

Ask for one shipment to be priced live and for the arithmetic to be shown: taxable weight, the bracket used, the paying-for comparison, the fuel base, then the margin. A product with a real engine can produce that breakdown in seconds. A product that is a lookup table with a margin field will show you a total and a spinner.

Two further checks. Ask what happens at 1,940 kg on a tariff where 2,000 kg is cheaper — a real engine tests every higher bracket, not just the next one. And ask whether the cost report and the quote screen share code; if the answer is a description of two modules, expect the divergence documented above.

Cargavo, a TMS for road freight brokers and transport commissionaires, is an engine plus a quoting workflow over grids you build yourself from your carriers’ Excel or CSV sheets. It is deliberately not a carrier API or EDI integration layer, not a load board, not a tendering marketplace and not a fleet dispatch system — the prices come from your own negotiated tariffs, from €49/month, with EUR, USD, GBP, CHF, CAD, MAD and PLN from the Growth plan with a 14-day free trial and no credit card. Plan details are on the pricing page.