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.