TMS Dynamic Fuel Surcharge for Relay Operations: Multi-Leg Linehaul Fuel Peg Allocation & Driver Split Settlements

Motor carriers operating split-dispatch relay networks face unique challenges in accurately allocating customer fuel surcharges across multiple legs, power units, and drivers. This technical guide details the database schemas, business rules, and TMS workflows required to automate pro-rata linehaul fuel peg calculations, regional index variance handling, and driver settlement splits without manual spreadsheets.

Enterprise TMS dashboard showing multi-leg relay fuel allocation

Strong Tower Consulting, LLC was founded in Minnesota in 2008 by Scott Elliott. In business for more than 18 years, we serve motor carriers, freight brokers, and private fleets with deep expertise in transportation management systems. Scott Elliott is founder and transportation systems architect of both Strong Tower Consulting, LLC and Exspeedite LLC, which are separately organized sister companies under common ownership (separate EINs; liability firewall).

The Operational Challenge of Relay Freight Movements

In a typical relay operation, a load moves from origin to destination using multiple drivers and tractors. Consider a Chicago-to-Denver load that relays at the Omaha terminal. The first driver operates Chicago to Omaha (approximately 470 miles). The second driver completes the Omaha-to-Denver leg (approximately 540 miles). The customer contract specifies a single fuel surcharge based on a national or regional fuel peg. The TMS must:

Calculate the total linehaul fuel surcharge revenue due from the customer
Prorate that revenue across the two legs based on actual miles driven
Apply the correct regional fuel index (PADD 2 Midwest for the first leg, PADD 4 Rocky Mountain for the second leg) when contractually required
Credit each driver with the appropriate fuel reimbursement or per-mile fuel component in their settlement
Maintain audit-ready records for both revenue recognition and driver pay

Without automated TMS logic, dispatchers resort to error-prone spreadsheets that quickly become unmanageable at scale.

Core Data Model Requirements

A robust TMS implementation for relay fuel allocation requires the following normalized schema components:

Fuel Index Master Table

fuel_index (
  index_id INT PRIMARY KEY,
  peg_name VARCHAR(50), -- e.g. "Diesel - PADD 2 Midwest", "National Average"
  source VARCHAR(30), -- "EIA", "OPIS", "DOE"
  effective_date DATE,
  price_per_gallon DECIMAL(6,4),
  region_code VARCHAR(10), -- PADD2, PADD4, NATL
  fuel_type ENUM('ULSD','DSL')
);

Contract Fuel Peg Rules

contract_fuel_rule (
  rule_id INT PRIMARY KEY,
  contract_id INT,
  peg_type ENUM('FIXED','INDEX','HYBRID'),
  base_peg_id INT,
  trigger_threshold DECIMAL(5,2), -- e.g. $0.10 increments
  mileage_method ENUM('ACTUAL','PRACTICAL','HOUSE'),
  regional_variance_allowed BOOLEAN DEFAULT FALSE,
  variance_calc_method ENUM('LEG_SPECIFIC','WEIGHTED_AVERAGE')
);

Load Movement Leg Table (Critical for Allocation)

load_leg (
  leg_id BIGINT PRIMARY KEY,
  load_id BIGINT,
  sequence INT,
  origin_location_id INT,
  destination_location_id INT,
  driver_id INT,
  tractor_id INT,
  actual_miles INT,
  billed_miles INT,
  start_odometer DECIMAL(10,1),
  end_odometer DECIMAL(10,1),
  fuel_gallons_used DECIMAL(8,2),
  fuel_reimbursement_rate DECIMAL(6,4),
  allocated_fuel_surcharge DECIMAL(10,2),
  regional_peg_id INT,
  leg_status ENUM('PLANNED','DISPATCHED','IN_TRANSIT','COMPLETED')
);

The load_leg table serves as the atomic unit for both revenue allocation and driver settlement. Every relay point creates a new leg record with its own driver, tractor, and mileage data.

Dynamic Fuel Surcharge Calculation Engine

The TMS fuel calculation service follows this deterministic workflow:

Customer Revenue Determination: At load tender acceptance, the TMS reads the active contract_fuel_rule and determines the total fuel surcharge using the primary peg and the total practical or actual miles for the entire move. This total fuel revenue is stored on the parent load record and remains fixed unless the contract allows post-billing adjustments.
Leg Mileage Capture: Upon leg completion (typically via ELD integration), actual miles are recorded. The system validates odometer readings against GPS breadcrumbs to prevent manipulation.
Pro-Rata Allocation: The total customer fuel surcharge is distributed across legs using the formula:
leg_fuel_revenue = total_fuel_revenue × (leg_actual_miles / total_actual_miles)
Regional Peg Variance (if enabled): When regional_variance_allowed = true, the system calculates a variance factor per leg:
variance_factor = (leg_regional_peg_price - base_peg_price) / base_peg_price
This factor is then applied to the leg's prorated revenue before driver crediting.
Driver Settlement Credit: Each driver's settlement receives the allocated fuel revenue (or a contract-specific per-mile fuel component) plus any fuel reimbursement for out-of-pocket purchases. The system supports both "fuel surcharge pass-through" and "fixed fuel per mile" settlement models.

Relay network operations center with TMS fuel allocation interface

Integration Points for Accurate Automation

High-fidelity fuel allocation depends on tight integration between several systems:

ELD / Telematics Integration

Real-time odometer, fuel purchase, and GPS data must flow into the load_leg table. See our guide to ELD and EDI Integration for implementation best practices that eliminate manual mileage entry.

Rate Matrix and Contract Management

Dynamic fuel rules must be maintained within the carrier rate matrix. Our Carrier Rate Matrix Optimization practice details how to structure fuel surcharge tables that support both national and PADD-specific indexing.

Transportation Accounting Integration

Allocated fuel revenue must post to the correct general ledger accounts and driver settlement batches. Strong Tower's Transportation Accounting Integration methodology ensures proper revenue recognition under ASC 606 while maintaining driver pay accuracy.

Maintenance Scheduling Considerations

Relay networks introduce additional complexity for equipment maintenance. Because tractors swap at relay points, the TMS must track fuel-related maintenance events (DEF refills, fuel filter changes) by individual power unit rather than by load. The system should generate preventive maintenance alerts based on cumulative miles across all legs a tractor has operated, regardless of which driver was behind the wheel.

Implementation Roadmap

Organizations seeking to eliminate spreadsheet-based fuel allocation should follow this sequence:

Normalize load movement data into a formal load_leg structure
Implement a fuel index ingestion service that updates daily EIA or OPIS prices by PADD region
Build the contract fuel rule engine with support for regional variance
Develop the pro-rata allocation service that runs on leg completion events
Integrate allocation results into both customer billing and driver settlement processes
Add audit reporting and exception dashboards for fuel variance greater than 3%

Our TMS Implementation and Business Process Optimization practices have helped numerous carriers replace manual processes with these automated workflows.

Reporting and Visibility Requirements

Effective relay fuel management requires specific reports:

Fuel Surcharge Realization Report (customer revenue vs. driver cost by lane)
Leg-Level Fuel Allocation Audit (showing proration percentages and regional adjustments)
Driver Fuel Settlement Reconciliation (per-driver fuel credit vs. actual fuel purchases)
Regional Peg Variance Impact Analysis (PADD 2 vs PADD 4 contribution to margin)

These reports should be available both in the TMS user interface and via scheduled delivery to accounting. See our enterprise reporting methodology for additional guidance.

Intermodal and truckload relay terminal fuel management

Industry Application

While this technical pattern is most common in truckload operations with established relay networks, similar logic applies to intermodal drayage moves involving multiple power units and to complex brokerage and 3PL networks that manage multi-carrier handoffs with fuel components.

Conclusion

Modern enterprise TMS platforms must treat fuel surcharge allocation as a first-class, automated business process rather than a post-hoc manual calculation. By designing the data model around the load_leg entity, integrating real-time ELD data, maintaining accurate regional fuel indices, and applying deterministic pro-rata and variance rules, carriers can achieve both accurate customer billing and precise driver settlements at scale.

Strong Tower Consulting, LLC brings more than 18 years of hands-on experience designing and implementing these exact capabilities for motor carriers running relay networks. Our systematic approach eliminates dispatcher spreadsheets, reduces revenue leakage, and ensures drivers are compensated correctly for every leg they operate.

Ready to eliminate manual fuel allocation spreadsheets?

Schedule a no-obligation technical assessment of your current TMS fuel handling capabilities.

Start TMS Assessment Speak with Scott Elliott at 763-244-1373

Author

Scott Elliott, Principal Transportation Systems Architect
Strong Tower Consulting, LLC - Founded 2008