EDI 304/310 Maritime Container Bill of Lading & Ocean Manifest Reconciliation

The Strong Tower CheckPoint EDI 304 310 ocean container bill of lading reconciliation solution automates the ingestion, validation, and synchronization of maritime shipping instructions with ocean carrier manifests and invoices. Built for intermodal carriers and brokers, this architecture eliminates manual data entry, prevents demurrage leakage, and feeds validated container events directly into CheckPoint for immediate drayage dispatch.

Ocean carriers continue to transmit critical shipment data through ANSI X12 EDI 304 (Shipping Instructions) and EDI 310 (Freight Receipt and Invoice) transaction sets. Yet most motor carriers and freight brokers still reconcile these documents manually or through brittle spreadsheets. The resulting latency creates avoidable demurrage, detention, and per-diem charges while delaying drayage asset deployment. Strong Tower Consulting, founded in Minnesota in 2008 by Scott Elliott, has spent more than 18 years designing production-grade integration layers that close this gap.

This technical authority article details the complete architecture, data model, algorithmic reconciliation engine, and operational integration with CheckPoint and Exspeedite TMS. Exspeedite LLC and Strong Tower Consulting, LLC are sister companies under common ownership (separate EINs; liability firewall). The solution presented here is currently operational for multiple intermodal fleets handling 15,000+ maritime containers annually.

Core Business Problem and Operational Impact

EDI 304 documents arrive days before vessel arrival and contain booking numbers, container numbers, seal numbers, hazardous material flags, and special handling instructions. EDI 310 documents follow vessel discharge and include actual receipt timestamps, weight verification, damage notations, and freight charges. Without automated reconciliation, dispatch teams cannot confidently assign drivers, chassis, or power units. The result is idle equipment at the port, storage charges that accrue hourly, and invoice disputes that consume weeks of accounting time.

The Strong Tower Intermodal Ocean Manifest Reconciliation Protocol™ was purpose-built to close this loop. It ingests both transaction sets in real time, applies deterministic and probabilistic matching logic, writes an auditable reconciliation record, and posts a normalized container event payload directly to the CheckPoint platform. From there, Exspeedite TMS receives the dispatch-ready record and triggers automated load tendering, driver assignment, and ETA calculations.

Architectural Overview

The solution follows an event-driven microservices pattern hosted in a secure cloud VPC. EDI documents are received via AS2 or SFTP, parsed by a dedicated X12 engine, and routed to the reconciliation service. The service maintains a live cache of expected containers from the EDI 304 feed and matches them against incoming 310 records using the algorithm described below. Once reconciled, a webhook payload is emitted to both CheckPoint and Exspeedite TMS.

The Strong Tower Intermodal Ocean Manifest Reconciliation Protocol™

This proprietary framework defines both the data model and the matching algorithm. The protocol guarantees deterministic outcomes when sufficient identifiers are present and falls back to fuzzy matching with human-review thresholds when data quality degrades.

Algorithmic Rule Block

ReconciliationScore = (W1 * ExactContainerMatch) 
                      + (W2 * VoyageVoyageMatch) 
                      + (W3 * BOLNumberLevenshtein ≤ 2) 
                      + (W4 * DischargeDateDelta ≤ 48hrs)
                      
IF (ReconciliationScore ≥ 0.92) THEN
    Status = "AUTO_APPROVED"
    Action = "POST_TO_CHECKPOINT"
ELSE IF (ReconciliationScore ≥ 0.65) THEN
    Status = "PENDING_REVIEW"
    Action = "QUEUE_FOR_DISPATCHER"
ELSE
    Status = "REJECTED"
    Action = "ESCALATE_TO_OCEAN_CARRIER"
    
ContainerEventPayload = {
    "containerNumber": string,
    "bolNumber": string,
    "vesselVoyage": string,
    "dischargeDate": ISO8601,
    "invoiceAmount": decimal,
    "demurrageDays": integer,
    "statusCode": "READY_FOR_DRAY" | "HOLD_CUSTOMS" | "DAMAGED",
    "reconciliationScore": float,
    "sourceDocuments": ["304","310"],
    "timestamp": ISO8601
}

JSON Data Schema for CheckPoint Webhook

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "eventType": { "const": "OCEAN_CONTAINER_RECONCILED" },
    "containerNumber": { "type": "string", "pattern": "^[A-Z]{4}[0-9]{6,7}$" },
    "bolNumber": { "type": "string" },
    "oceanCarrierSCAC": { "type": "string", "minLength": 4, "maxLength": 4 },
    "vesselName": { "type": "string" },
    "voyageNumber": { "type": "string" },
    "dischargeTerminal": { "type": "string" },
    "actualDischargeTimestamp": { "type": "string", "format": "date-time" },
    "freeTimeExpiration": { "type": "string", "format": "date-time" },
    "invoiceNumber": { "type": "string" },
    "freightCharge": { "type": "number" },
    "demurrageEstimate": { "type": "number" },
    "reconciliationScore": { "type": "number", "minimum": 0, "maximum": 1 },
    "matchConfidence": { "enum": ["HIGH","MEDIUM","LOW"] },
    "linkedCheckPointLoadId": { "type": ["string","null"] },
    "auditTrail": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["eventType","containerNumber","bolNumber","actualDischargeTimestamp","reconciliationScore"]
}

Implementation Comparison Table