EDI Network Invoicing Opacity

VAN Invoicing Opacity –

What mama never told you

The Universal Complaint, if one was nominated in the EDI messaging sector, must be regarding Service Plan accounting, or what I call, “invoicing opacity”; it occurs when one attempts to reconcile a VAN bill with what you thought was your service plan / tier / stated rates. How did these extras get slipped in? They charge for interconnect traffic? and so on.

Things get particularly fraught when dealing with the madness with corporations selling VAN services via several aliases.  These corporations are amalgams of several businesses bought, sold, and reconstituted under a PE umbrella. With no founders or engineers left from the founding teams, these run down shells are denuded of essential institutional memory. We can instantly see why invoicing opacity has been routinely adopted by the PE managers and their C-Suite robot warriors at VAN HQ, or what’s left of it.

This  brief monograph lays an easy goal for the author – answering why most VAN invoicing is so opaque, especially as practiced by companies that should know better. These remnants of the declining VAN era should also be called upon to do better for the industry – laying bare an obvious question: “where is the VAN sector going”? And, “where will VAN clients go to once they are sufficiently fed up by the Value Subtracted Network model of the 201X EDI era?”

However, for the moment limiting ourselves to the advanced math of VAN invoice accounting, let’s at least throw down the primary reasons for confusion. After we accept that the situation is far from ideal, then the revolution may commence.

The Opacity Factors

The following factors have been contributing to VAN invoice opacity for as long as anyone can recall:

  • KC / KB differential

    a KC is 1000 characters, a Kilobyte is 1024 bytes. People get caught on this all the time.

  • Rounding –

    The devil his grande self once told the author (in a personal interview) that there is a special place in hell for VAN executives that allow rounding up of the KC Count.

  • Interconnect traffic treated as a special class of messages.

    In intensive beer and Q&A sessions amongst the VAN insiders, this particular question has never had a satisfactory answer. First of all, in the post Internet era, data is carried over interconnects via IP, and the costs are negligible as far as interconnect traffic is concerned.

    In the second logical instance – whoa! What is there besides interconnect traffic? Yes, there is the native data traffic, but then what are we saying – that offsets are placed on interconnect traffic to what effect? To influence customers to bully their vendors onto the home VAN?

  • Support fees that are not clearly delineated as such

    The maturation of the EDI end-user population has transformed the sector. Where it all began, once upon a time, as a user population biased towards the very large Enterprise, has now truly become a far more complex mix.

    This maturation curve gave birth to the service providers led by SPS commerce, and the Technology forward VANs (Loren Data Corp) that grew with these service providers, allowing the market to diversify….amid some bad acts and actors.

    Now, some end-users are also quasi service providers in their own right, providing services to their vendor population that would have been considered unheard of 15 years ago.

    Therefore the support mix being offered has been growing in diversity with the sector’s maturity. The downside in billing opacity has been an emerging tendency to bury some support items in the data billing. Not cool.

    If you catch this in your VAN invoice, and then discover the fine print, it is time to start planning your migration to more honest providers.

Would the above potential distortions and exploitations pass muster in other connected markets – in telecom, internet,GMDSS?

No.

Hell no.

All VAN traffic is now Internet traffic. So…..you do the math (!). If the math for your VAN invoice requires trigonometry, start looking for a new EDI Network.

The opinions expressed are the author’s own.