Freight Broker Automated Fuel Advances: Comchek/EFS API Push, Fee Structure & Payables Sync

Core Operational Requirements for Automated Fuel Advances

A production-grade automated fuel advance system must satisfy four non-negotiable conditions before funds are released:

1. Driver and equipment must be physically present at the shipper location (geofence or macro-tracking confirmation).
2. A loaded bill of lading must be uploaded and validated (OCR or manual review with timestamp).
3. The carrier must be in good standing with current authority, insurance, and safety metrics.
4. The calculated advance must fall within brokerage policy limits (typically 30-40% of linehaul revenue).

These checks are executed in a deterministic rules engine that runs inside the TMS workflow immediately after the load status transitions to “loaded.”

Advance Calculation Logic and Fee Structure

The calculation follows a transparent formula executed in the TMS accounting engine:

AdvanceAmount = ROUND((LinehaulRevenue * AdvancePct) - TransactionFee, 2)
TransactionFee = ROUND((LinehaulRevenue * AdvancePct) * FeeRate, 2)

Typical configuration values used by brokerages we support:

• AdvancePct: 0.30 to 0.40 (30-40% of linehaul only; accessorials excluded)
• FeeRate: 0.03 to 0.05 (3-5% of the advanced amount)

The resulting advance amount and fee are stored as separate line items on the carrier payable record. The fee is recognized as brokerage revenue at the time of advance issuance, while the advance principal is recorded as a reduction in future carrier payable liability.

Real-Time Comchek and EFS Digital Card Issuance via REST API

Both Comchek (now under EFS) and direct EFS platforms expose RESTful endpoints that accept JSON payloads containing the 16-digit express code, amount, and optional memo. The integration pattern we implement uses a secure outbound service bus inside the TMS:

1. TMS rules engine approves advance request.
2. Payload is constructed with carrier identifier, load number, amount, and expiration parameters.
3. Authenticated HTTPS POST is sent to the Comchek/EFS issuance endpoint.
4. Response containing the 16-digit code and reference number is captured and stored against the load and carrier payable.
5. Digital card details are pushed to the carrier via SMS, mobile app notification, or EDI 214 update.

Strong Tower Consulting works with both the legacy Comchek express code format and the modern EFS digital card load API. The same TMS service layer abstracts the vendor-specific request format so brokerages can switch providers without changing business logic.

All API calls are logged with full request/response payloads (sensitive fields masked) for audit and reconciliation purposes.

Fraud Prevention and Verification Controls

Automated issuance increases speed but also risk. The verification layer we design includes:

• Geofence radius check (typically 0.25 mile) using ELD pings or macro-tracking data from the carrier’s telematics provider.
• Timestamped BOL upload with hash validation to prevent reuse of previous documents.
• Carrier performance scoring filter (minimum safety rating and no recent claims).
• Velocity rules that limit the number of advances per carrier per week.
• Exception workflow that routes suspicious requests to a brokerage fuel desk for manual review.

These controls are implemented as atomic database transactions so that an advance cannot be issued unless every prerequisite record exists and passes validation.

TMS Accounting Engine: Liability Creation and Settlement Deduction

Upon successful API issuance of the Comchek or EFS advance, the TMS accounting engine performs the following atomic operations:

1. Creates a carrier payable record with negative balance equal to the advance amount (liability).
2. Records a separate revenue line for the transaction fee.
3. Links both entries to the load number and carrier identifier.
4. Posts corresponding journal entries to the general ledger (Debit: Carrier Advances, Credit: Accounts Payable).

When the load reaches final settlement, the payables reconciliation process automatically:

• Calculates total carrier earnings (linehaul + accessorials).
• Subtracts the outstanding advance principal.
• Subtracts the previously recorded transaction fee if not already collected.
• Produces a net settlement amount.
• Marks the advance as “cleared” and updates the ledger (Debit: Accounts Payable, Credit: Carrier Advances).

This closed-loop process eliminates manual reconciliation spreadsheets and ensures the brokerage balance sheet accurately reflects outstanding carrier advances at all times.

Real-Time Ledger Synchronization with Accounting Platforms

Strong Tower Consulting maintains bidirectional integration patterns with major accounting systems used by brokerages. When the TMS accounting engine records an advance or settlement transaction, a normalized payload is published to a message queue. An integration adapter then creates or updates the corresponding records in the financial system.

This synchronization occurs in near real-time, typically within 15 seconds of the TMS transaction commit. The design ensures that even during high-volume periods the accounting platform remains the system of record for financial reporting while the TMS remains the system of record for operational transportation data.

See our practice on Transportation Accounting Integration for detailed mapping specifications and error handling patterns.

Recommended Database Schema Patterns

A minimal yet complete schema supporting this capability includes the following key tables and relationships:

• loads - core load record with status, linehaul_rate, carrier_id, etc.
• carrier_advances - one row per advance with columns: advance_id, load_id, carrier_id, amount, fee_amount, issuance_method (comchek|efs), reference_number, status, created_at, cleared_at.
• carrier_payables - final settlement lines that reference carrier_advances via foreign key for automatic deduction.
• api_transactions - immutable log of every outbound call to Comchek/EFS including request, response, success flag, and timestamp.
• geofence_events - ELD or tracking events used to satisfy the location verification business rule.

All writes related to advance creation and settlement deduction are wrapped in a single database transaction to guarantee atomicity.

Implementation Best Practices and Maintenance

Organizations that successfully deploy this capability typically follow these practices:

• Start with a pilot group of 10-15 trusted carriers before expanding to the full network.
• Configure business rules in a declarative rules engine rather than hard-coded application logic to allow rapid policy changes.
• Implement comprehensive audit trails and retain API payloads for a minimum of 7 years to support financial and regulatory audits.
• Schedule quarterly reviews of advance utilization, fee revenue, and exception rates with operations and finance leadership.
• Maintain a failover process that allows manual Comchek/EFS issuance when the API is unavailable.