Electronic Bill Of Lading API (1.0.0-public-preview)

The NMFTA has partnered with leaders across the transportation industry to deliver a digitized method of transferring data between parties. By developing open-source API standards, the NMFTA and its partners will open the door to a more efficient method of data transfer, which today is still accomplished through a variety of more rudimentary processes. Digital API standards will reduce costs to onboard new business partners, improve visibility to shipment information, allow for real time notification on shipment changes, and drive out waste across the industry by eliminating manual processes. API standards will empower technological development, particularly when it comes to process automation.

The Bill of Lading (BOL) is a crucial document that communicates the details and expectations for a specific freight shipment. It is a legally binding document issued by the Carrier to the Shipper that defines the shipment (type, quantity, origin, etc.), and is the basis of the business transaction between a Shipper and a Carrier. The current BOL process consists of a physical document transported between parties that is frequently lost, stolen, or delayed in being documented for all parties to review. This council will create an electronic Bill of Lading API standard that will allow for a more efficient and streamlined BOL process that will reduce or eliminate some of the risks associated with the current BOL process.

Because the BOL sets the expectations for a shipment, it serves as the foundation for processes later in the shipment lifecycle. Similarly, the eBOL defined by the Digital Council will provide the foundation for the other APIs that will be defined to handle other business processes. An eBOL will act as a digital twin of a physical BOL document, containing the same crucial shipment information and carrying the same importance.

The eBOL API will allow a Shipper to more easily share the official details of a shipment, reducing opportunities for misunderstanding, human error, and theft. With existing BOL processes, particularly for a LTL shipment, a Shipper does not have visibility to the PRO number or shipment status until Pickup occurs. With the eBOL API, the Shipper will receive the PRO number pre-pickup, and in conjunction with other standard APIs, will be able to receive pre-pickup visibility on their loads.

Additionally, current processes leave open the possibility for theft when bad actors manipulate physical BOLs to hide evidence of theft, and makes it difficult for Shippers to prove otherwise. An electronic BOL process will reduce these opportunities and give Shippers peace of mind.

A Shipper will initiate the eBOL process by sending the details of their shipment to a Carrier using the standard API format. They will receive back from the Carrier a completed BOL and shipping label. The response will also include a unique shipment identifier (PRO in the case of an LTL shipment) that can be used to reference the shipment in future interactions with the Carrier, including tracking update requests.

The eBOL API will be especially beneficial to the Carrier community by outlining the standard communication protocol for sharing BOL information, greatly simplifying the connectivity required to do business with a large number of Shippers, customers, and third parties. Among other things this will improve billing accuracy, reduce opportunity for manual errors, and allow Carriers to provide better service to customers.

A Carrier will receive details of a shipment via the eBOL API from the Shipper, store the information in their system, and return the official BOL back to the Shipper. They will also return a shipping label that the Shipper can print and attach to their shipment. As part of this, they will also return a unique load identifier (in the case of an LTL shipment, it will be the PRO number) back to the Shipper that can be used to reference their load going forward.

The eBOL API will allow third parties of all kinds to receive and send the necessary shipment information to ensure a seamless flow through the life cycle of a shipment. Due to the nature of 3rd parties' business and having to interact with multiple parties in the transportation industry, 3rd parties stand much to gain by simplification of their business processes, which the eBOL will enable.

In the LTL industry, the BOL is a particularly valuable document due to the inherent complexities of an LTL shipment. Not only does an LTL BOL contain general shipment information (such as origin, destination, billing info), but it also contains very detailed information on the freight being shipped, down to the commodity information of each individual line item. Because of this, any eBOL solution for an LTL shipment must be very detailed, while still allowing for significant variations from shipment to shipment.

The NMFTA LTL Digital Council has already defined and released standards for eBOL in the LTL industry. Its usage is being adopted by Shippers, Carriers, and 3PLs, and is being put to use to drive efficiency and automation for LTL shipments.

The BOL for a Full Truckload shipment serves the same purpose and contains similar information to that of an LTL shipment. The main difference between a FTL and LTL is the level of detail is usually less for a FTL shipment. A FTL BOL may not include a PRO number, NMFC Codes, Classification, and often will not include pallet counts and reliable dimensions. The NMFTA FTL Digital Council will be coordinating with their LTL Council counterparts to look to find an opportunity for a single, combined eBOL standard that meets the needs of both the LTL and FTL use cases. The synergy between the two will help drive adoption throughout the transportation industry, where many organizations are involved in both FTL and LTL transportation.

The Product Requirements Document (PRD) for this API can be found here.

Standards for Carrier APIs