Best Practices. Two words that raise the hair on the back of your neck, and sometimes your blood pressure.
Everyone wants to talk about “best practices.” But sometimes there really is a method to the madness. And when it comes to electronic data interchange (EDI), best practices are more important than with most integration technologies.
EDI is the exchange of business information using a standardized format. It is a process which allows one company to send information to another company electronically rather than with paper. That’s a good thing.
EDI, initially created in the the 1940s, has proven to be a surprisingly durable technology and has grown to become the standard for B2B data communications. If you need to exchange data with your business partners (often referred to as “trading partners”), you almost certainly need to use EDI.
Perhaps more than any aspect of enterprise integration — whether that’s core integration tasks with SaaS systems such as Salesforce or NetSuite, API management, master data management (MDM) implementations, or workflow automation —EDI is perhaps the most daunting and esoteric flavor of integration.
To help you sort through EDI and understand how you can best put it to work for your organization, we will be walking through key technical aspects of EDI as part of our “Tech Talk” blog series.
What Is Functional Acknowledgement Processing?
One of the most important aspects of EDI is functional acknowledgement processing, often referred to just as FA processing.
So what is FA processing, and why is it so important?
A functional acknowledgement is a special EDI document that lets the sender of EDI business documents know that the recipient received the documents sent to them. It lets you know that your information successfully made it thru the recipient’s EDI translator’s syntax checking.
Functional acknowledgements are important because they can greatly reduce the overall risk to an organization. Ultimately, they can save an organization a significant amount of money by reducing fines and charge-backs.
The concept is very similar to a signature on a certified letter through the postal service. When the delivery person hands you the letter, they ask for your signature. Your signature proves to the sender that you received the letter. It doesn’t say what you did with it, just that you successfully got it.
In legal terms, this is called “non-repudiation of receipt.” An EDI functional acknowledgement is a proof of receipt (PoR) document.
In the EDI world, the sender is always responsible for making sure that the intended recipient successfully received the business documents. This can be quite important when you’re dealing with invoices and payment terms, advance ship notices, or healthcare claims processing.
The sender needs to know very quickly if a recipient rejected a document, or worse, never received it at all. There can be significant fines and charge-backs associated with missed or failed documents, depending on the nature of the information being transmitted.
Putting Functional Acknowledgements to Work
So, how should an organization use functional acknowledgements?
First, you should always return a functional acknowledgement for every business document your trading partners sends you. You may have a trading partner tell you they don’t require them or don’t want them. However, I strongly encourage you to take the position you always create and send functional acknowledgements. Your trading partner can chose to ignore them, but you should always send them. Remember, it is their responsibility to track receipts.
Second, you should always request that your trading partners return functional acknowledgements for every document they receive from you. This is very important. Unless your trading partners return functional acknowledgements to you, you will have no way to ensure they received the documents you sent them.
Third, you should check every functional acknowledgement you receive in response to documents you sent, to determine if they were accepted or rejected. (For EDI wonks: In an ANSI X12 997 or 999, this is the AK9. In an EDIFACT CONTRL, this is the UCI4).
If a received functional acknowledgement indicates a rejection at the recipient, a notification should be created by your EDI processes. Someone will need to research the issue and determine the reason for the failure and take the appropriate corrective actions.
Fourth, you must be able to identify documents you have sent and be able to know if you have received a functional acknowledgement for each of them.
If you didn’t receive a functional acknowledgement for a specific document you sent, you have to assume it never made it to the recipient and take appropriate corrective actions (resending or perhaps calling your partner and verifying if they did or did not receive it).
Critically, you need to ensure your EDI system is capable of detecting a missing functional acknowledgement in a reasonable amount of time and that it can notify the appropriate people to investigate.