Historically, data moving from one place to another is charged for. When you call around looking for EDI pricing you always include the cost for data transfer in your list of questions. Your question is something like: ‘and how much do you charge per kilobyte?’ You do this assuming the data you pay for is only what is transferred from one trading partner to another (Unless you are paying for archiving).
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.
The problem is most EDI companies tell you they charge “X” amount for data, period. If you don’t ask the question specifically, you may not get the real answer. - you may still not get a straight answer.
Some hosted 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. For example: some EDI providers translate using XSLT, whereby the X.12 is converted to XML. From there it is dropped into a database. One company I found actually drops the whole XML file into the clients account along with the raw data needed to populate the database. This particular company charges users for the data they are holding within the system for them. This grossly inflates the size of the data being charged for and certainly is not what was sent to or received from the trading partners.
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:
The data per document shown above is an example. Your EDI document sizes will obviously vary.
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 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:
- Most VANs and many hosted EDI providers, at the end of the month sum all documents down to the byte and round up to the nearest kilobyte. The result is multiplied times your contracted rate. On the other hand,
- Many EDI providers round each document to the nearest kilobyte and total those at the end of the month. This is multiplied times your contracted rate. You really think each document is exactly 2kb or 1kb or is a cleanly rounded piece of data e.g. not 1.2, or 1.257?
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. Your 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. But you shouldn’t charge for it. Wait. I just fell into the trap myself. 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. To do so would be less than honest.
So 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 you owe it to yourself and your company to 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. If you have found others, please share them in the comments area.
You can file this under: hoping for a little industry transparency or stopping the EDI Shell Game.
| < Prev | Next > |
|---|