As a provider of multi-carrier shipping software, I am often explaining why there are geographic pockets where FedEx, UPS, DHL, TNT, or some other carrier cannot be supported with the carriers’ standard software. The reason is often due to the carrier expanding their footprint through an acquisition. Often the first thing the acquiring entity does is “paint the trucks,” and it can be many years before the acquired company moves onto the same technology platform as the parent company. This results in a software provider having to implement a separate set of compliance (rates, labels, manifests, etc.) for that region of the world. 

As just one example, FedEx has had six acquisitions in the last four years, in Hungary, China, India, Mexico, Poland, and France. The biggest recent news in the area of acquisitions is UPS’s 6.5 billion dollar bid for TNT. As of this writing UPS has extended the offer through to November 9th in response to the European Commission’s investigation taking longer than originally anticipated. More than likely, the investigation will result in UPS having to divest certain holdings in some EU countries in order to maintain a competitive landscape. 

Back in March, UPS’s CFO Kurt Kuehn told analysts that the integration of the two companies would take four years and an additional one billion dollars. That can buy a lot of brown paint. What’s interesting is that TNT itself grew through acquisitions in Spain, China, Brazil, and Chile. So, while all of this provides for greater infrastructure, in order for the shipper to utilize the full footprint, they are actually adding the equivalent of multiple carriers on their software platform. How easy is that to do with your current software? What if it’s a carrier that is not ‘out of the box’ software? If your company wants to be able to ship globally, your software system needs to be able to provide tools that allow you, the customer (not necessarily the software provider) with the ability to on-board new carriers quickly. The shipping software should enable bringing on new geographies (or new products or new customers) that require new carriers, in a quick and efficient manner.

The reason that carriers do not quickly convert the technology platform to the parent company is due to the high cost of re-tooling. Often the labels are based on scanners and other devices used both in the field and the hubs. Manifests are often linked to other software used for planning and tracking shipment status. As we all know, software evolves as capacity increases, as the physical structures involved change and either increase or condense. There’s an old saying, “What’s the definition of a legacy system?” Answer: “One that works.” For all of these reasons, a carrier is reluctant to go into an acquisition and completely remove the legacy systems. 

Many shipping software providers, in the configuration of a parcel carrier, will allow the customer to give the carrier entity a “friendly name,” which is the one used when interacting with the software. These are often the carrier codes that are used in other parts of the operation (an upstream WMS passing UPSGND43, for example, to indicate a particular UPS Ground account). As the name of an acquired company changes, it can often be a simple enough act to perform the software equivalent of painting the truck by changing the friendly name of the carrier in the configuration screens, if you are already using a carrier that is acquired. A recent example of this is last year’s selling of DHL Canada’s ground division to TransForce; TransForce will certainly drop the DHL branding (it’s going to market as Loomis Express). Anyone that had been shipping with DHL Ground in Canada should be able to go into their software and paint the truck (figuratively).

Bottom Line: Make sure your shipping software has the ability to allow you to on-board new carriers quickly. Taking advantage of the fact that one of your carriers just expanded their footprint shouldn’t cause you to wait four years before the technology converges.

Follow