TMS Integration: What Syncs (Rates, Quotes, Bookings, Tracking + Docs)

Velocity’s TMS integration is designed to preserve your existing TMS investment while improving speed and accuracy upstream through centralized rate and quote management and bi-directional data exchange. This guide explains what can sync, how to set “system of record” rules, and how to keep execution data clean.

What Syncs To/From TMS (Rates, Quotes, Bookings, Tracking, Documents)

Most implementations sync TMS data across five object groups. The exact direction (push vs pull) depends on where your organization wants to manage each function.

1) Rates (Contract + Live + Surcharges)

Typical patterns

• Velocity → TMS: Push normalized, approved rates into TMS for downstream operations and billing logic.
• TMS → Velocity: Pull contract rates from TMS to power quoting and customer-facing experiences.

Common data elements

• Carrier/service (ocean/air, service level)
• Lane definition (origin/destination ports, ramp, zones)
• Equipment/container type (or air charge basis)
• Base rate + accessorials + surcharges
• Validity dates + version identifiers
• Currency and unit basis (per container, per kg, per shipment)
• Rules/notes (minimums, thresholds, exclusions)

2) Quotes (Commercial Offers)

Typical patterns

• Velocity → TMS: Push accepted/approved quote details for conversion into bookings and reference continuity.
• TMS → Velocity: Pull quote references (if the TMS is the quoting system) or enrich Velocity’s quote with operational constraints.

Common data elements

• Quote ID and reference links
• Quote line items (base + accessorials)
• Margin/markup fields (if allowed to sync)
• Validity/expiration
• Customer and incoterms/service preferences (optional)

3) Bookings (Execution Records)

Typical patterns

• Velocity → TMS: Create bookings in the TMS from customer portal actions or internal acceptance workflows.
• TMS → Velocity: Pull booking numbers, status changes, and operational details as they change.

Common data elements

• Booking ID / shipment reference
• Customer/account, payer/billing entity
• Mode, lane, dates (ETD/ETA), equipment, weight/volume
• Parties (shipper/consignee/notify)
• Operational instructions (cutoffs, handling notes)

4) Tracking Milestones and Exceptions

Typical patterns

• TMS → Velocity: TMS remains source of truth for tracking and exception workflows; Velocity consumes milestones for visibility.
• Velocity → TMS: Velocity pushes event triggers when customer actions should reflect in ops queues (e.g., “documents uploaded”).

Common data elements

• Milestones (picked up, departed, arrived, delivered)
• ETA updates
• Exceptions (customs hold, missing docs, rollovers) as flags or reason codes
• Last updated timestamp and data source

5) Documents (Shipment + Commercial)

Typical patterns

• Bi-directional: Documents generated or received in either system should be accessible from both.

Common document types

• Commercial invoice, packing list
• Bill of lading / AWB
• POD, customs forms
• Quote PDFs, booking confirmations

Centralized Rate & Quote Management: Feeding Data Into TMS

A core value of this integration is using Velocity as the “upstream engine” for pricing/quoting while allowing the TMS to remain your execution backbone.

Why “normalized rates” matter

Rates come from multiple sources (carrier sheets, APIs, contract PDFs, local tariffs). Normalization ensures:

• Consistent charge names (e.g., “THC” isn’t duplicated under five labels)
• Clean units and currencies (per container vs per shipment; USD vs EUR)
• Comparable lanes and services (aligned origin/destination keys)
• Reliable quoting outputs that can be transferred into TMS without manual rework

Practical outcomes

• Pricing teams maintain fewer “rate versions” in the TMS
• Ops receives clean, structured cost components
• Customers get faster quotes with fewer corrections later

Bi-Directional Exchange: Customer Profiles, Instructions, Documents

Bi-directional sync is most valuable when it prevents double-entry and keeps teams aligned across commercial and operational touchpoints.

Customer profiles

Recommended: Keep master customer identity in one system (usually CRM or TMS), then sync identifiers to Velocity.

• Customer ID / account code
• Billing entity and credit terms (if applicable)
• Addresses, contacts, preferred lanes/modes (optional)

Operational instructions

Examples that benefit from syncing both ways:

• Pickup/delivery instructions and cutoffs
• Packaging/handling notes
• Compliance notes (battery restrictions, HS code expectations, etc.)

Documents

Use document sync to ensure:

• Ops can see customer-submitted paperwork immediately
• Sales/customer success can reference execution docs without switching systems
• Customers receive timely updates if your portal surfaces documents

Booking Handoff: What Must Be Complete Before Pushing to TMS

The booking handoff is where integrations succeed or fail. The safest approach is to enforce a “booking-ready” gate so the TMS only receives records that meet your minimum execution standards.

Booking-ready checklist (recommended)

• Verified customer match (Customer ID/account code present)
• Lane complete (origin/destination keys match TMS schema)
• Mode and service level set (FCL/LCL/Air + service)
• Equipment / weight-volume complete
• Ship dates present (requested ETD/ready date; optional ETA)
• Parties complete (shipper/consignee/notify as required)
• Commercials locked (accepted quote reference + validity captured)
• Required documents attached (if mandated by workflow)

System-of-record rule (recommended)

• Velocity can initiate/prepare the booking,
• The TMS remains the system of record for execution once the booking is created (status updates, tasks, milestones, and final documentation).

Tracking Milestones & Exception Updates

To keep operational execution accurate, tracking data should be minimal, structured, and governed.

What to sync

• Milestone timestamps (standardized list)
• ETA changes (with source and timestamp)
• Exception flags + reason codes (limited controlled vocabulary)

Governance tips

• Don’t sync free-text exceptions unless you control formatting; use codes.
• Keep a single event source per milestone type where possible.
• Always sync last updated and data source to avoid “old overwriting new.”

Billing/Analytics Considerations (High-Level)

Most teams do not try to make Velocity a billing ledger. Instead, they use it to improve pricing consistency and feed clean data into the systems that drive invoicing and reporting.

Recommended approach

• Use the TMS (or ERP) as the billing system of record.




• Sync enough commercial detail to support analytics:

  • Quote totals, margin bands (if permitted), service level, lane, customer tier
  
  
  
  


• 
  

  Standardize charge codes so financial reporting is consistent across quotes and invoices.

  
  

Common analytics wins

• Quote-to-booking conversion by lane/mode
• Margin performance by carrier/service
• Exception rates by lane (to refine pricing assumptions)
• Cycle time: request → quote → booking → delivered

Recommended System-of-Record Model (Reference)

A simple, reliable baseline:

• Velocity: rate normalization, quote creation, quote approval/acceptance, booking initiation triggers
• TMS: bookings, execution workflow, milestone truth, operational documents, billing handoff
• CRM (if used): customer ownership, pipeline stages, commercial reporting