Inside Delivery & Stairs Accessorial Rating: Dynamic TMS Architecture

Technical Practice & Implementation Guide — TMS Dynamic Rating & Operations

Motor carriers and 3PLs that routinely handle specialized high-value or commercial inside delivery operations frequently lose millions in unbilled accessorial revenue. Inside delivery, stair carries, multi-man crew requirements, elevator delays, and white-glove services are often captured inconsistently on the delivery manifest yet fail to reach the billing system. Strong Tower Consulting has spent more than 18 years designing enterprise-grade dynamic rating engines that close this gap.

This guide presents the authoritative technical architecture for a dynamic, multi-carrier rate matrix that automatically solves for inside delivery, stair-carry, and white-glove accessorial charges at the point of rate confirmation, load planning, and final invoice reconciliation.

The Revenue Leakage Problem

Traditional static rate tables and carrier-specific accessorial schedules create three critical failure modes:

The result is either revenue leakage or customer disputes that damage carrier relationships. A properly designed dynamic TMS accessorial solver eliminates both problems.

Reference Architecture: The Dynamic Accessorial Solver

The recommended pattern is a centralized, carrier-agnostic microservice (the Accessorial Solver) that sits between the TMS order entry / load planning layer and all contracted carrier rate engines. This service normalizes every carrier's accessorial rules into a unified decision matrix, evaluates delivery constraints in real time, and returns precise charges that can be locked at time of tender.

Figure 1: High-Level Dynamic Accessorial Solver Architecture
Order Management / TMS
          │
          ▼
  Delivery Constraint Detector
  (Address + Notes + Geofence + Shipment Flags)
          │
          ▼
   Accessorial Solver Service
   ├── Carrier Rate Matrix Repository (normalized)
   ├── Location Constraint Engine
   ├── Stair / Floor / Crew Calculator
   ├── White-Glove / Inside Delivery Rule Engine
   └── Billing Reconciliation Lock
          │
          ▼
Carrier-Specific Rating API (real-time or batch)
          │
          ▼
   Final Rated Load + Accessorial Detail
   (stored immutably for invoice generation)

Core Data Model & Rate Matrix Design

The foundation is a normalized, version-controlled rate matrix stored in a relational or document database. Each carrier maintains its own matrix, but all matrices conform to the same schema.

Table 1: Normalized Accessorial Rate Matrix Schema (simplified)
Column Type Description Example
carrier_id varchar Unique carrier identifier CAR-7842
accessorial_type enum INSIDE_DELIVERY, STAIR_CARRY, WHITE_GLOVE, ELEVATOR_WAIT, MULTI_MAN STAIR_CARRY
condition_field varchar Field the rule evaluates stair_count
condition_operator enum GT, GTE, LT, LTE, EQ, RANGE GTE
condition_value varchar Value or range to match 3
charge_type enum FLAT, PER_FLOOR, PER_MAN_HOUR, PER_STOP PER_FLOOR
charge_amount decimal Monetary value 45.00
min_charge decimal Minimum charge floor 125.00
effective_date date Matrix version start 2025-01-01
expiration_date date Matrix version end (null = indefinite) null

Real-Time Delivery Constraint Detection

The solver begins with a multi-signal constraint detector that runs before any rate is returned. Strong Tower recommends the following layered approach:

  1. Address Classification: Geocode the delivery address and cross-reference against commercial/residential tax databases, USPS CASS, and proprietary commercial delivery indexes.
  2. Shipment Metadata Flags: Parse order notes, special instructions, and commodity codes for keywords such as "inside", "stairs", "elevator", "white glove", "assembly", "carry up".
  3. Consignee Profile: Maintain a master consignee database that records historical delivery requirements (e.g., "ABC Hospital - 4th floor, elevator required").
  4. Carrier Stop Data: When available, ingest the carrier's own stop-level accessorial codes returned via EDI 214 or API.

Each signal is assigned a confidence score. When confidence exceeds a configurable threshold, the constraint is locked into the shipment record and cannot be overridden without supervisor approval.

Accessorial Solver Decision Engine

The solver implements a rules engine that evaluates constraints against the normalized carrier matrix. A simplified decision flow for stair-carry inside delivery is shown below:

function solveAccessorials(shipment, carrierId):
    constraints = detectConstraints(shipment)
    matrix = fetchNormalizedMatrix(carrierId, effectiveDate=shipment.loadDate)
    
    charges = []
    
    if constraints.hasInsideDelivery:
        insideRule = matrix.find("INSIDE_DELIVERY", constraints.deliveryType)
        charges.append(calculateCharge(insideRule, constraints))
    
    if constraints.stairCount > 0:
        stairRule = matrix.find("STAIR_CARRY", constraints.stairCount)
        charges.append(calculateCharge(stairRule, constraints))
    
    if constraints.requiresMultiMan or constraints.crewSize > 2:
        crewRule = matrix.find("MULTI_MAN", constraints.crewSize)
        charges.append(calculateCharge(crewRule, constraints))
    
    if constraints.whiteGloveRequested:
        wgRule = matrix.find("WHITE_GLOVE")
        charges.append(calculateCharge(wgRule, constraints))
    
    totalAccessorial = sum(charges)
    return {
        baseLinehaul: getBaseRate(shipment, carrierId),
        accessorials: charges,
        total: baseLinehaul + totalAccessorial,
        locked: true,
        auditTrail: constraints
    }

Implementation Workflow in Enterprise TMS

Strong Tower Consulting recommends the following phased rollout for motor carriers and 3PLs:

  1. Phase 1 - Matrix Ingestion: Build automated ETL pipelines that ingest each carrier's accessorial tariff (PDF, spreadsheet, or API) and normalize it into the unified schema. Version every matrix with effective dates.
  2. Phase 2 - Constraint Detector: Deploy address classification and natural-language note parsing services. Integrate with existing TMS order entry screens to surface probable accessorials before dispatch.
  3. Phase 3 - Real-Time Solver API: Expose the solver as a REST/GraphQL endpoint consumed by rate shopping, load planning, and carrier tender modules. Cache frequent carrier-matrix combinations.
  4. Phase 4 - Billing Reconciliation Engine: At invoice creation time, compare actual delivery events (from carrier EDI 214 or proof-of-delivery images) against the locked solver output. Flag variances greater than 5% for review.
  5. Phase 5 - Continuous Improvement: Implement feedback loops that allow billing analysts to correct solver decisions. Use these corrections to retrain classification models and refine matrix rules.

Key Integration Points

Table 2: TMS Integration Points for Dynamic Accessorial Solver
System Module Integration Type Data Exchanged Frequency
Order Entry Real-time API call Delivery address, notes, commodity Per order
Rate Shopping / Quoting Synchronous request/response Origin, destination, constraints → rated total Per quote
Load Planning & Dispatch Event-driven Locked accessorial detail to carrier tender Per load creation
EDI 214 / POD Processing Batch + real-time Actual vs. expected accessorial events Daily + on receipt
Invoice Generation Query at render Immutable solver snapshot Per invoice
Carrier Rate Maintenance Scheduled ETL New tariff files → normalized matrix Weekly or on tariff change

Enterprise Best Practices & Governance

Enterprise Systems Advisory

Ready to modernize your transportation management software, eliminate manual spreadsheets, or optimize telematics and recruiting workflows? Contact Strong Tower Consulting for direct architect guidance.

Schedule Architecture Consultation