Which rate card applies when a shipment crosses a contract change?

A truck is booked on 29 June and picks up on 1 July. A revised rate card also takes effect on 1 July. The transporter invoices at the higher rate; the shipper’s purchase record still carries the old one. Both teams can point to a date, but the dates answer different questions.

The applicable rate comes from the agreement's charge-trigger event and scope. An invoice date should not select the rule merely because it is the easiest date for the system to find. Before configuring freight rate management, the commercial owner must translate the agreement into a decision that can be repeated for a historical trip.

Put the trigger into the rule

For each charge, record the trigger field, its source and the treatment of uncertain timestamps. “Effective from 1 July” is incomplete if the parties have not agreed whether it governs newly accepted bookings or pickups occurring from that date.

Different charges may use different triggers. Base freight could follow an accepted booking, while a separately agreed fuel adjustment follows a stated index period. The system should preserve that distinction instead of selecting a single convenient date for every line.

Use a rule register with at least the carrier, customer or contract scope, origin/destination definition, equipment/service, charging unit, effective interval, trigger and approval reference. If dates are interpreted in local time, state the timezone and boundary. A midnight event should not move between rate periods because two systems display it differently.

Compare the two possible answers

In this illustrative example, the old base rate is ₹10,000 through 30 June and the new rate is ₹10,800 from 1 July.

Under a booking-trigger agreement, the base charge is ₹10,000. Under a pickup-trigger agreement, it is ₹10,800. The ₹800 difference cannot be resolved by choosing whichever timestamp arrived last.

Now add an equipment change from the contracted vehicle to a different capacity. Even a correct trigger date may select the wrong rule if the equipment substitution changes the agreed charge. Record who authorised the change and whether it preserved the original rate or required a new commercial decision.

Define precedence before exceptions accumulate

Rate tables often develop general rules and special cases. A customer-specific lane amendment may override a general lane rate, but that precedence must be deliberate. Without it, two technically valid rows can produce two prices for the same shipment.

The record should distinguish a price calculated by a rule from a manually approved exception. Both may be legitimate. They should not look identical when a later audit asks why one shipment differed.

Oracle's 26C rate-record documentation describes effective and expiration dates and checks them against shipment start dates. That is a product-specific behaviour to compare with the contractual trigger; it is not evidence that every booking-date agreement will work without configuration or another supported mechanism. Oracle Transportation Management 26C — Rate Record.

Preserve the old calculation when the rule changes

Do not overwrite a rate row that already explains billed work. Create a new approved version or use the system’s supported effective-dating mechanism. Store the rule identifier, relevant inputs and calculated result on the priced transaction.

A retrospective amendment needs its own controlled workflow. First identify the affected population. Then compare original and revised calculations, separate already-invoiced from unbilled shipments, and let finance decide how approved changes enter the ledger. A mass recalculation should not erase the original price or automatically issue new charges.

The same principle applies to corrections in the lane master. Changing a postcode-zone mapping today must not silently alter how a historical shipment was priced. Preserve the mapping version or the resolved lane information used at calculation time.

Test the boundaries in the proposed system

A useful demonstration includes a trip immediately before and after the effective boundary, an overnight trip, an equipment substitution, an overlapping rule and a retrospective amendment. Give the evaluator independently approved expected answers.

Make the midnight test precise. For an illustrative pickup-trigger rule, define the new period as starting at 00:00 on 1 July at UTC+05:30. A pickup at 23:59 on 30 June uses ₹10,000; one at 00:00 on 1 July uses ₹10,800. The old period excludes that boundary instant and the new period includes it. This is a proposed test convention, not a claim about a product's date-field semantics. Repeat it with timestamps converted to UTC and require the same prices.

The decisive questions are whether each price can be reproduced, whether ambiguous cases stop visibly, and whether approved amendments leave a readable history. Rebooking also needs an explicit policy: changing a pickup appointment should not silently create a new commercial booking date.

Decision flow: identify the contractual trigger → confirm event evidence and scope → find the applicable approved version → calculate and retain the result. If the trigger, scope or version is unresolved, route the shipment to the commercial owner before treating its price as final.

Make a historical price reproducible

A reliable rate card explains the rule in force for a particular event and shipment, not simply the rate currently visible on a screen. Preserve that explanation through amendments, invoices and credits so finance can distinguish a calculation error from an authorised commercial change.

Next actions

1. Choose one recent rate change and trace a booking that crossed its effective date.
2. Obtain written agreement on the trigger, scope and precedence for that charge.
3. Test the boundary cases in the current rate engine or controlled register.
4. Preserve original calculations before approving any retrospective repricing.

To review rate-change controls, start with one disputed shipment, its trigger evidence and the competing rate versions.