[updated April 5th, 2019]
Historically, data moving from one place to another in the supply chain is charged for when using EDI. When you call around looking for EDI you always include the cost in your list of questions. Your question is something like: ‘and how much do you charge per kilobyte, and for new trading partners?’ You do this assuming the data you pay for is only what is transferred from one trading partner to another (Unless paying for additional services).
You didn’t ask if they only charge for the actual X.12 data sent to and received from your trading partners. Guess what: not all of them do.
Let’s not forget the EDI providers whose salespeople tout an “API-like” tool to download orders. When it’s time to set it up you’ll find it’s just CSV over HTTPS. I couldn’t believe it when I saw it. But let’s face it. They are there to translate your data to HTML (web EDI), and give you other value added tools. If you want REST, that’s another trading partner e.g. set of costs, maintenance fees, etc.
Technology costs money. Do a little research to find out what will work best for your company.
EDI companies tell you they charge “X” amount for data. If you don’t ask the questions specifically, you will probably not get the answers you need to plan and budget.
Traditionally, VANs carry the massive bulk EDI traffic directly to network customers. If your retail customer sent you an 850 PO, for example, you got everything in the message. As hosted EDI solutions came online (~ year 2000), the bundling of additional services could result in EDI documents broken to simplify operations with data. As a result the cost per document will be higher.
Some EDI companies charge for the data stored on their system rather than the actual EDI data traded between TPs. Look at what these SaaS companies do with that translated data. In most cases the X.12 (Raw EDI data) goes through several processes and is stored iteratively, plus logging. Many providers store/align the X12, XML, and JSON data files with the clients account (In a database). It’s reasonable for a provider to charge users for the data they are holding within the system for them.
Ironically, another process comes about from retailers employing multi-store orders and is the primary profit vehicle for several hosted EDI companies. Retailer’s commonly use the SDQ element (Ship Destination Quantity) within an EDI document to show the supplier exactly what is required for each individual store included within an order (Spreadsheet PO format). It’s a ‘concentration’ of Item and Store information which makes an EDI document much smaller and concise.
Many hosted EDI providers, however, post each SDQ as a separate order, complete with duplicated header info, store address, DC info and so on. In effect, exploding a single PO with multiple stores into one document for each store – some also include the original order as well. They charge for each of these documents as opposed to the document originally sent by the retailer. Take a look at my (Not so fancy) drawing below:
What if the supplier is receiving orders from a retailer with many stores? Maybe they have 1,000 or all of Target stores or are in all of Sephora or Nordstrom? Suddenly the cost to process this order (With ASN and INV) actually hits in some cases over 2-4% of order value. Even if you are only in one retail location and it’s a test order – you should still not be charged this way. If you are paying $0.50 per kilobyte and are in all of the Nordstrom stores chances are this particular order cycle (In terms of EDI) just hit $500.00 or more. Keep this in mind as you read on.
For years, particularly in the retail industry, we have battled the apples to oranges comparison of kilobyte vs. document. One EDI provider charges based on document volume and another based on document size. It is a leftover from the service bureau days at QRS and was adopted by some SaaS companies to help them differentiate their offering from VANs and other hosted EDI providers. The companies charging by document look at rounded averages and use this to determine price. Everyone else should be charging based on actual data sent/received. Simple, right? There is more to it than that. Compare the two pricing methods below and tell me which is most attractive:
Of course there are likely to be service charges, maintenance fees, etc. for both groups.
See the difference between the two? Now consider also what happens when each retailer PO is converted to individual orders by store and the second pricing model is applied. EDI just became a real expense.
You can argue that it may be helpful to “break” the SDQs out in order to create a proper ASN, store level invoices or other documents. The question is how it’s charged for.
If you do plan to charge for it, you should NOT tell or in any way imply to prospective clients that the retailer sends the data this way or that it is anything other than your system’s requirement or business policy.
Now that you have heard it, what should you do about it? If you are a Retailer, should you have a very frank conversation with the EDI providers you refer business to? Since the conversation an EDI provider has with a vendor is very different from the one they have with you, maybe do so with several of your vendors present (Vendors using the same EDI provider). If you are a manufacturer, you should look very closely at the system you are using and come to terms with what you are paying for. Have you done some integration work? Been with that provider a long time?
It’s important to note that not all hosted edi providers fall into this category. People for years have moved to hosted systems to prevent having to bring EDI software, hardware and dedicated personnel in-house. We are past the point where there are only a few choices out there. If you want to really take advantage of hosted edi platforms look for the best system and part of that involves the cost/billing method of the system. I have pointed out three different ways where EDI providers can vary in their pricing methods, but that is the short list.
You can file this under: hoping for a little industry transparency or stopping the EDI Shell Game.