Our mission is to establish simple integrations that enable brokers to digitally exchange information with OTR Solutions and make day-to-day business exchanges more efficient. In digitizing this exchange, we are reducing excess staff phone time, enhancing the carrier experience with faster setup and increased load coverage, and streamlining document exchange and rate/payment verification. This digitization leads to an exchange that is more secure, cost-effective, and scalable.

Key Processes

Overview

OTR Solutions has developed an integration pattern to share key entities and attributes frequently requested by Factors and Brokers as part of their day-to-day business. Our APIs support the following key processes:

• Onboarding Carriers
• Completing Rate Verifications
• Sharing Documents
• Inquiring on an invoice receivable’s status

We are proposing a standard process flow for sharing load information between OTR and a Broker. The flow enables the exchange of desired data to be shared in either direction in order streamline implementation efforts for both parties. APIs can either be exposed from the Broker to allow OTR Solutions to request information or OTR can expose APIs to allow Broker to send information to OTR. The following this is a detailed breakdown of each step within this cycle:

• Blue boxes denote API integration points between Brokers and OTR.

Establishing Carrier Relationships

Establishing the carrier relationship between the factor and the broker is a critical step required to facilitate seamless transactions between factor and broker.

The Carrier API addresses the following use cases:

• A carrier signs a factoring agreement.
• Carrier completes carrier setup package with Broker.
• Factor needs to establish NOA.
• Factor authorizes Carrier to take Quick Pay

Completing Rate Verification

Today, verification of the load information is accomplished either by confirming paperwork via email or making a phone call to the broker. The process can be incredibly time-consuming and inefficient, not only for the carrier, but also the broker. Sharing load data via API would facilitate a more accurate and consistent confirmation of rates, reduce manual tasks for both the carrier and the broker, and ensure timely and transparent acceptance of the load.

The Rate Verification API addresses the following use cases:

• A Carrier books a load with a Broker.
• A Carrier has completed delivery of a load.
• A Carrier takes an advance is taken on a load
• An issue arises with the load (e.g. Claim, TONU, etc)

Data Entities Exchanged

• Load Information (Rate Confirmation)
• Advance Information
• Load Status

Exchanging Paperwork

For a load to be purchased and paid, there is an exhaustive exchange of paperwork between all parties involved, most of which is duplicative. The carrier shares paperwork with the Factor and the Broker, who then shares with the Shipper to get paid, and then the same paperwork is shared back to the Broker by the Factor to get paid. By utilizing OTR’s proposed APIs, we could eliminate or streamline all of those exchanges.

The Document API handles the following use-cases:

• Broker needs to paperwork from the carrier.
• Broker needs to update the existing paperwork.
• The Carrier needs to share lumper receipts.
• The Factor needs to share paperwork for completed load.
• The Carrier needs to upload lumper receipts.

Data Entities Exchanged

• Rate Confirmation
• Bill of Lading
• Proof of Delivery
• Lumper Receipts

Processing Invoices and Payables

Settling the invoice is the final step in the factor/broker relationship; it is also the most prolonged. Once a receivable has been purchased from a carrier, an invoice is created to track payment from the broker. Over the course of the receivable terms, many things can happen that impact timely payment of the invoice. Creating an API to track the continued status of the invoice is a crucial step to closing the factoring circuit.

The Invoice API addresses the following use-cases:

• A carrier invoice is purchased by factor
• An invoice is scheduled for payment
• An Invoice is paid
• A claim is made on an invoice

Data Entities Exchanged

• Invoice
• Payment Status
• Payment Date