Back in the old days, a carrier’s data belonged to the carrier.  We’re talking about tracking equipment, primarily the truck.  Satellite tracking then, cell phones or on-board units using cell service today.  What has changed is access to the data.

With the advent of service companies like FourKites, MacroPoint, and 10-4 Systems, data regarding the truck’s location is made available to the owners of the shipments, the shipper.  How?  The carrier provides a skinny data file to the service company (say FourKites) with the shipper name, shipment ID, and truck number.  If necessary, the file will also include the drivers cell phone number.  With this skinny file, the service company will ping the on-board device database (i.e. Omnitracs, Rand McNally, etc.) to gather the location data, then report it to the shipping customer.  If no on-board device exists, then the driver’s cell phone will be pinged for the current location.  Either way, the service company can report the location of all shipments to the shipping customer in near real time (ok every 15 minutes, but not bad).

Some carriers will ask, why do the shippers have to know exactly where the truck is? To update a nice visual on a computer screen?   This may be round one.  Round two is focused on predicting a shipment’s arrival to its destination.  Not 100% as of this posting, but it’s in the works.

You may wonder, can’t carriers simply pass this data directly to their shipping customers?  Of course they can, and they do.  But that is a lot for a shipper to coordinate, especially if they work with lots of carriers.  Some shippers do exactly that, but others now have the option of using a service company as described above.  Makes for a one stop shopping, convenient approach.

But back to the carrier.  Will drivers submit to being tracked all the time?  Do they have a choice?  Given the current high turnover of truckload trucking, this latest trend will likely not help the situation.  But as with all process changes, people learn to adapt.

Are functional acknowledgements for EDI invoices a useful business process?

Whenever a company implements EDI invoicing, the question comes, “do I need 997’s for these?”   To this question, I almost always say yes.  While the 997, i.e. functional acknowledgement, is not perfect, it does provide some value.

First, a little background to set the context.   Every so often, as in once a year or once every two years, I’ll get a call from an irate customer suggesting we dropped the ball on their EDI.  I ask, “what is the problem, can you give me some details?”   Sometimes it comes right up or sometimes it only surfaces after some lengthy Q&A.   The issue is, “my customer is not paying their bills and it’s causing some serious cash flow issues around here.”   When this happens, we review processes, talk with the trading partner, and emphasize checking the 997s.

Here’s how it works.   When a company sends out EDI invoices, a response of acceptance comes back, ideally within a few minutes, but almost always within a day.  The response, the 997 functional acknowledgement, provides feedback at the invoice level, whether an invoices is accepted or rejected based on syntax.  This is very helpful as an indication of passing the first hurdle.  There is still an additional step to take if the invoices are accepted, but if they are rejected based on syntax, the issue is readily rectified.

While the 997 is of considerable value in determining the acceptance of syntax, it does not and cannot relate the acceptance of the charges within the invoice.  The 997 is a technical review, but there is still the business review that comes later.

To determine the acceptance of the charges on an invoice, the customer must be consulted.  Ideally this is through a vendor based web site.  Less optimal is simply receiving an e-mail stating the issues they see.   And of course, the worst case is no correspondence or visibility at all.   In this last case, the vendor only knows there is an issue based on an aging report.  Upon consulting, the issues come out, not an ideal situation.

But given that it’s a two-step process to confirm payment, the important take away is to address processes.   The 997 is easily checked internally via reporting from the EDI system, but once this is addressed, it’s a natural follow on check to confirm payment, something vendors have been dealing with for years, EDI or no EDI.  The EDI process simply speeds up the cycle which can be a good thing provided everything flows without issue.

One final point on this process that is worth mentioning is the role of third party paying agents in the flow of data.  Some of these companies are very reputable, engaging in good business practice as described above.  But this is not always the case.  At times some of these third parties lack good tools and then blame the vendor when slow payment or no payment results.  This is never a positive situation.  The vendor sending the EDI invoices to the third party usually has no say about the involvement of said third party.  But certainly documenting the flow of data step by step can help to reduce the no or slow payments.  Sharing this information with the customer (who has engaged the third party) is sometimes a necessary step.

EDI invoicing is more often than not, a very useful technology.   But engaging in good process to support the flow, including the 997, helps to ensure a successful implementation.