Audit-Proof IFTA Reporting: The Strong Tower State Mileage Telematics Engine

The Strong Tower IFTA Jurisdiction Telematics Engine™

Founded in Minnesota in 2008 by Scott Elliott, Strong Tower Consulting, LLC has spent more than 18 years designing, implementing, and stress-testing transportation technology stacks for private fleets, for-hire carriers, and freight brokers. The Strong Tower IFTA Jurisdiction Telematics Engine™ represents the current state-of-the-art in automated IFTA mileage reporting. It is not a simple mileage tracker; it is a production-grade, audit-defensible jurisdiction engine that ingests, validates, and apportions every mile a vehicle travels.

The engine is deliberately architected to remain independent of any single TMS or ELD vendor. It accepts data from CheckPoint (https://exspeeditecheckpoint.com/login.php) and can emit validated state-mileage records to Exspeedite TMS (https://exspeedite.com/tms-software) or any third-party IFTA filing system via REST API or secure file drop.

Core Data Source: CheckPoint App-Less GPS Breadcrumbs

CheckPoint was purpose-built to eliminate driver distraction and installation complexity. Unlike traditional ELDs that require constant driver interaction, CheckPoint devices transmit breadcrumb pings at configurable intervals (typically every 60 to 180 seconds while moving). Each ping contains:

• Device serial number
• UTC timestamp (millisecond precision)
• WGS84 latitude and longitude
• Instantaneous speed (km/h or mph)
• Heading (true north)
• Optional ignition status and odometer pulse count when available

Because the platform does not rely on an in-cab app, compliance risk from driver non-participation is eliminated. The Strong Tower engine treats these pings as immutable source-of-truth data.

The Strong Tower CheckPoint IFTA State Mileage Calculation Algorithm

for each vehicle v in fleet:
    sorted_pings = sort(CheckPoint.pings[v], by: timestamp)
    state_path = []
    current_state = null
    last_ping = null
    
    for each ping in sorted_pings:
        if last_ping is null:
            last_ping = ping
            current_state = point_in_polygon(ping.lat, ping.lon, state_polygons)
            continue
        
        crossing = detect_boundary_crossing(last_ping, ping, state_polygons)
        
        if crossing.detected:
            interpolated_distance = haversine(last_ping, crossing.point)
            state_path.append({
                jurisdiction: current_state,
                miles: calculate_miles(last_ping, crossing.point),
                start_ts: last_ping.ts,
                end_ts: crossing.ts
            })
            current_state = crossing.new_state
            last_ping = crossing.point
        else:
            last_ping = ping
    
    // Final leg
    state_path.append({
        jurisdiction: current_state,
        miles: calculate_miles(last_ping, ping),
        start_ts: last_ping.ts,
        end_ts: ping.ts
    })
    
    persist_to_audit_store(v, state_path, raw_pings)

The algorithm performs three critical functions in sequence:

1. Continuous Path Reconstruction - Raw pings are sorted chronologically and gaps larger than 15 minutes are flagged for manual review or supplemented with auxiliary data when available.
2. GIS State Boundary Crossing Detection - For every consecutive pair of pings, the engine executes a line-segment-to-polygon intersection test against high-resolution state boundary vectors. When a crossing is mathematically confirmed, the exact crossing location and timestamp are interpolated using linear distance weighting.
3. Mileage Apportionment - Total distance between pings is split at the interpolated boundary point. Miles are attributed to the correct IFTA jurisdiction using the Haversine formula with WGS84 ellipsoid correction.

JSON Data Schema - Audit Store Record

{
  "schema_version": "2025.1",
  "record_id": "uuid-v4",
  "vehicle_id": "string",
  "carrier_id": "string",
  "reporting_quarter": "YYYY-QN",
  "generated_at": "ISO-8601",
  "source_system": "CheckPoint",
  "total_miles": 12487.3,
  "jurisdictions": [
    {
      "state": "MN",
      "miles": 3421.6,
      "fuel_gallons": 421.8,
      "taxable_miles": 3421.6,
      "crossing_events": 17
    },
    {
      "state": "WI",
      "miles": 2894.2,
      "fuel_gallons": 357.1,
      "taxable_miles": 2894.2,
      "crossing_events": 23
    }
  ],
  "raw_ping_count": 18492,
  "flagged_gaps": 0,
  "audit_hash": "sha256:0x...",
  "signed_by": "Strong Tower IFTA Jurisdiction Telematics Engine v2025",
  "export_formats": ["IFTA-100", "XML", "API"]
}

This schema is the canonical output format consumed by Exspeedite TMS for automated quarterly IFTA filing.

Architectural Diagram Description

CheckPoint Devices
        ↓ (HTTPS Webhook / SFTP batch every 5 min)
Raw GPS Breadcrumb Store (immutable append-only log)
        ↓
Strong Tower IFTA Jurisdiction Telematics Engine™
   ├── Ingestion & Validation Layer
   ├── GIS Engine (PostGIS + state boundary vectors)
   ├── Crossing Detection & Interpolation Service
   ├── Mileage Apportionment & Odometer Reconstruction
   ├── Audit Evidence Store (signed, timestamped JSONL)
        ↓
Exspeedite TMS (or any compliant IFTA system)
        ↓
Automated Quarterly IFTA-100 Filing + Fuel Tax Returns
        ↓
Immutable Audit Archive (retained 7+ years)

Implementation Comparison Table