Whereas EAI refers to communication between IT systems within a single company, EDI refers to the exchange of data between multiple companies. Here too, the IT systems “talk” to each other directly – humans should ideally play only a monitoring role.

Individual companies often deploy software developed by different manufacturers – and when that’s the case, things get a lot more complicated when different companies do business with each other. Not only are there many different standard software systems rattling through the processors, but entire in-house applications too – many of which were written when IT was still in its infancy. As you doubtless already know, nothing lasts longer than a temporary solution.

So how can we get cobbled-together software solutions used by different companies to work together effectively? Each program has its own data format. Often, the closest thing there is to a ‘communications interface’ is the text files that are generated and inputted. This results in linguistic confusion of near-Babylonian proportions.

To remedy this, there are certain data formats developed as standards by major organisations (including departments of the UN), as well as software that is capable of converting data from one format into another. You might even call them ‘interpreters’, capable of translating between all the many different languages and dialects. And bear in mind that interpreters at the UN generally don’t translate directly from Afrikaans into Thai, but work into one of the standard languages (such as English or French), and then from that into the target language. In the world of EDI, those standard languages are EDIFACT, Fortras and BMEcat. The equivalents to the regional languages are generally CSV files or texts in fixed record format, all of which generally fall under the category of ‘in-house’. In other words, this is the format

used within a given company – and possibly nowhere else on earth.

If both of the companies involved in the communication have access to ‘interpreter’ software of this kind, they can convert data from their in-house format to one of the standard formats before sending them to their partner via any electronic pathway. The partner then converts the standard into their own in-house format before feeding the data into their systems. This makes communication only the third stage that rounds off the EDI process.

Example 1 – Quick query:

In the more complex EAI example, we had to ask a supplier how long it would take them to deliver a particular item to us, since that item appeared in a customer order and we no longer had it in stock. Tasks like this would be covered by the EDI software (although we have already established that it is rather impractical to separate EAI and EDI so strictly – after all, this is just a quick external query in the middle of the EAI process).


Therefore, the EDI software is given the task – possibly in the form a SOAP request (here via a web service) – of asking the supplier ‘Hardware Provider’ how quickly they can deliver two copies of the item numbered ‘A08/15’ to us. That item number is the one used by the supplier – in our system, the item is registered under the number ‘4711’.


A web service offers the optimum solution for short requests of this kind. Web services are called up via HTTP, by means of a predefined method. The key point here is that the request is sent to the web service as an XML file, and the answer comes back in the same format. The request/answer itself is packaged inside something called an SOAP envelope, which contains some extra information – and that’s it. The answer comes back very quickly, in any case – after all, speed is what we’re aiming for.


Below, you can see the example of how our EDI software receives the request from the EAI system:


<?xml version=“1.0“ encoding=“UTF-8“?>





<soapenv:Header />



<supplier>Hardware Provider</supplier>








The EDI system now needs to find out how it can contact the company ‘Hardware Provider’. This information might come from a database or from an SAP system (and yes, strictly speaking that would take us back to EAI territory), or it might be stored directly in the EDI system somehow. Whatever the case, it turns out that we can also contact the supplier via a web service. As we have already said, this is ideal for requests of this kind because it works very quickly.


To spare you another XML example, let’s just say that the supplier has guaranteed us a delivery in three days’ time. Or more accurately, its IT systems have made the guarantee. This is because an answer received via an HTTP connection certainly won’t come from an employee, but will be generated completely automatically by the supplier’s IT landscape. After all, EDI and EAI processes are involved on the supplier’s side too. Our EDI system now reports the three-day delivery period back to our EAI software, allowing the latter to continue processing the order.

Example 2 – Customer order:

Customer orders of the kind that we discussed in the EAI example should no longer really be placed by an employee. That would be – well, almost medieval. Orders nowadays should come in electronically – e.g. as an email or via a website order form. Or (to stay with the B2B sector) in the form of an EDIFACT file delivered directly from our customer’s EDI system.

So let’s say that an email has come in with an attachment in EDIFACT format. The message type is called – you’ll never guess! – ORDERS. You can find a more detailed description of what something like this would look like in the section on EDIFACT.

The EDI software gets to work on the email and retrieves the attachment containing the order. It recognises what is going on based on the file name, or perhaps the subject line. If need be, it will also look at the contents if it can’t make sense of the other identifying features. Then it reads the data and inputs them into the order entry system (OES). At this point, our EAI software takes over, since we are making a clear distinction here between EAI and EDI for the purpose of defining both terms. Eventually, the EAI system finishes its processing, leaving the order in the OES along with all information regarding delivery times, predicted delivery times for the customer, any special conditions, etc. An order confirmation with all the trimmings can now be sent to the customer. Then the EDI system takes over again.

One possibility would be for the EAI software to take all the data for the order confirmation from the OES and store them in a directory as a small CSV file, from which the EDI system can once again read the data in order to build them into an EDIFACT document. In that case, the relevant message type would be ORDRSP (all message type names in EDIFACT have six characters, and this one stands for Order Response). Once the ORDRSP has been issued, the customer receives an email from us containing the EDIFACT message as an attachment, which will probably be instantly processed by their own EDI system in turn. Long live modern technology!

Let’s just take a quick look at the situation in B2C – i.e. communications and trade between companies and end customers (including private individuals).

In this case, there definitely wouldn’t be any EDIFACT files flying back and forth. The customer would be more likely to place their order via a web form – e.g. in a web shop with a basket, checkout and all the usual bells and whistles. Yet they too will receive an order confirmation, which would tend to be along the following lines:

Dear Ms. Bloggs,

Thank you very much for your order. Please find your confirmation below.

Item number Name Quantity Price per unit Total price

4711 Pleasant surprise 2 € 9.99 € 19.98

Total: € 19.98

plus VAT: € 2.76

Predicted delivery date: 30/02/2099

With best wishes,

Your Webshop Team

This external communication is very different. To start with, we might have a CSV file that supplies us with a PHP script from the web shop via FTP, while the response email will contain running text instead of an EDIFACT attachment. Yet the process behind it all is still the same.

As such, it makes sense for the different aspects of that process to be built in a modular fashion, as far as possible:

  • Communication via different channels
  • Reading data from different formats
  • Processing in conjunction with internal systems
  • Output of response data in various formats
  • External communication of the results via various paths

The entire procedure is set out in a diagram below:

On the one hand, viewed in this light, it makes a lot of sense to separate the processes that fall under EDI and EAI, as the EAI system isn’t remotely interested in how the orders reach the OES and how the confirmations leave it. Yet on the other hand, we often have the same technical processes on both sides – as seen just now in the example of

communication with the OES, or with databases too. To make matters worse, we find ourselves sending a web service query from the EAI to the EDI system – which the EDI system then forwards to our supplier – simply in order to keep everything separate. It would be far better to have one system that can handle everything, and to establish

any modularity within the processes of that system instead.


EDI stands for all processes relating to automated communication between the company’s own IT systems and the outside world. This involves not just pure data transfer (email, FTP, web service, AS2, etc.), but also converting between different data formats (often via standard formats as an intermediate step), enriching data with additional information, reconciling data and inputting it into or reading it from internal systems. Ideally, humans should play only a supervisory role here, intervening in the event of faults (e.g. unclean data or network problems) and then relaunching the processing once the problems have been remedied. Both EDI and EAI systems should therefore offer comprehensive monitoring, as well as extensive opportunities to respond to errors quickly and efficiently

Operational Variants
While EAI and ETL generally only make sense as in-house installations, the situation is far from clear-cut when it comes to EDI. After all, a great deal of communication goes on with the outside world in this area. And unlike EAI, internal systems don’t necessarily need to be directly accessible for EDI. It’s often enough that files can be exported and imported (data management). That means we have a whole host of options when it comes to configuring our EDI:


Here, there are two ways in which the configuration can take place. We can distinguish between self-managed in-house, and in-house with service provision.

SaaS – Software as a Service

SaaS is also known as cloud computing. Here, the installation itself is outsourced. That means a provider makes hardware and infrastructure available, and takes care of maintenance matters such as the installation of updates. You can then control everything and set up your own processes via the Internet.


In principle, it is possible to outsource not only the system operation and administration, but all the work too. A service provider runs the software in their own data centre, connects your business partners to it, and sets up conversions and other processes. All you have to do is send the data for your partners to the provider’s system, and the provider then sends your partners’ data back to you.

Open Internet vs. VAN

Communication also forms part of EDI – and here we have two alternatives. You can send data either via the standard Internet, or via a VAN (value-added network). The latter comes with a few additional features beyond pure data transfer, such as secure transfers. Let’s take a closer look at the alternatives:

The word ‘in-house’ simply means that the EDI system runs on your premises, on your network, and on hardware provided by you (whether real or virtual). This comes with several pros and cons:

Pros & Cons:


  • All your systems – such as databases, SAP, and everything else besides – are directly accessible, allowing the EDI system to make use of its full capacity.
  • If the program is able to, it can also carry out EAI tasks at the same time, since the previous point is of course an essential prerequisite to this.
  • Everything is fully under your control – nothing leaves your network beyond the data that were intended for the outside world anyway.
  • You only need to make a single investment when buying the system, followed at most by a manageable and unchanging support fee. That fee won’t go up even if your data volumes increase exponentially.


    • You need to supply your own hardware and infrastructure, and of course there are certain administrative costs involved too – although those costs will depend on which additional service you decide to purchase.
    • The initial investment is somewhat more substantial.

    Deciding where to install the software is only half the challenge, however. You also need to think about who will then work with the system and implement your processes. We can split that decision into two general alternatives (although the boundaries between them are somewhat fluid, of course).

1. Self-managed in-house

This gives you full control over everything. The installation will probably still be carried out by the manufacturer or a service provider, but the day-to-day work will be done by your employees. That means your IT unit (and most larger companies generally have a dedicated EDI team too) will configure the communication with your partners, establish all the processes, conversions, workflows and so on, and of course connect your internal systems too. The manufacturer’s support team would naturally stand ready to assist you with this, but it would largely be up to you.

That sounds like a lot of work – and it is – but it’s also worthwhile, since everything you do yourself will also be fully understandable to you afterwards. If any changes need to be made, this can be done quickly without having to provide complex explanations of what you need to a service provider, and without having to wait until the provider has time for your project.

Of course, changes to processes (such as switching to a newer version of an EDIFACT message) generally involve a certain lead time, which means this might not be so important. But what if your supplier calls on Friday afternoon and tells you that the IP and name of their FTP server to which you send all of your orders will be changing in two hours? Someone from your IT unit will need to be able to stay on-site to make the changes, since a service provider might close early on Friday or be so busy that they can only get round to it halfway through the following week.

You can also manage extensions to your software in-house, insofar as this is technically possible. And provided you have the right people for the job, of course. But a word of caution here: Even if the manufacturer provides you with the interfaces (or APIs), they will absolve themselves of responsibility for any lines of code that you have written or introduced into the system yourself. On the other hand, that would still be true if you had written everything for yourself without using any standard software.

In any case, this scenario calls for comprehensive training for your employees. That should start with administration, data backup and logging, but it should also include day-to-day operation, set-up of processes and communication, as well as using the API for in-house extensions (if this is available and relevant to you). Yet because training can generally only cover the fundamentals and just a small proportion of the countless functions found in a complex system of this kind – and because your employees will only retain a small part of the training anyway – quick, reliable and helpful support from the manufacturer is absolutely essential in cases like this. You should therefore research the company in advance and look carefully at its reputation for support. There should also be comprehensive documentation available, as it’s generally quicker to look at the manual than to send an email to the support team.

And make sure you don’t reinvent the wheel in the process. Connections to standard communication paths (from AS2 to X.400) and the use of standard data formats (EDIFACT, Fortras, VDA, etc.) should be supported by the system through simple templates and preset structure definitions.

Pros of this solution (in addition to the general ‘in-house’ component):

  • You know exactly what is going on in your system as you’ve set it all up yourself.
  • That means you can make changes quickly.
  • You can respond instantly to errors and problems.
  • Updates can be installed over the weekend when the system can be put out of action temporarily (and a service provider would only be available for a higher fee than usual).
  • Your internal data will never fall into the hands of third parties. This is particularly important in the healthcare sector with its strictly confidential patient data, as well as among banks and insurance companies.
  • If extensions are permitted by the system, they can be implemented quickly.
  • Your employees know how everything works. You understand the processes in your business, which means you don’t need to provide lengthy explanations to a service provider.


  • Your employees will need comprehensive training in order to be able to operate and administer the system properly. It will also take them a while to gain enough experience to properly get to grips with it.
  • That means you’re dependent on quick and effective support.
  • Your need human resources to administer and operate the system.

2. In-house with service provision

  • Was kann man denn so alles von einem Dienstleister machen lassen?
    • Administration mit Einspielen von Updates und Bugfixes
    • Einrichten der Kommunikation mit den Partnern
    • Anbinden der anderen Systeme (ERP, DB, …) im Haus
    • Aufsetzen von Konvertierungen zwischen Datenformaten
    • Abbilden der gesamten EDI-Prozesse
    • Monitoring des laufenden Betriebs und Reaktion auf Fehler

    Wie viel Dienstleistung Sie  in Anspruch nehmen und was Sie doch lieber selbst in der Hand behalten, können Sie natürlich im Einzelnen entscheiden. Hier schildern wir mal das Extrem, dass alles ausgelagert wird. Wobei das spätestens beim Monitoring an eine kritische Grenze stößt, denn zumindest das sollte bei einem Inhouse-System in Ihrer Hand bleiben. Auch für einen Dienstleister dürfte es schwierig werden, X Kundensysteme ständig zu überwachen, die womöglich über die halbe Welt verstreut sind.

    Was Sie sich hier ganz klar sparen können, ist eine ausführliche Schulung. Sie sollten zwar trotz Allem über die grundsätzliche Funktionsweise Ihres Systems Bescheid wissen, da man seine geschäftskritischen Daten wohl nur ungern einer Black Box anvertraut, aber detailliertes Wissen über Konfiguration, Administration und Abbildung der Prozesse ist in diesem Fall nicht nötig. Wenn Sie etwas brauchen, einen neuen Partner anbinden wollen, mit einem neuen Datenformat konfrontiert werden oder ähnliches, dann beauftragen Sie den Dienstleister damit. Der hat Spezialisten, die den ganzen Tag nichts anders machen und sich in allen Ecken der Software bestens auskennen.

    Womit er sich allerdings nicht auskennt, ist exakt Ihr Betrieb. EDI ist kein Feld für 08/15-Lösungen, selbst zwei oberflächlich betrachtet identische Prozesse können bei verschiedenen Unternehmen vollkommen unterschiedlich aussehen. Als Beispiel nehmen wir eine simple Datenkonvertierung von Lieferabruf-Daten aus dem Format VDA 4905 in ein EDIfact DELFOR. Schon das VDA-Datenformat bietet so einige Freiheitsgrade, da nicht alle im Format möglichen Angaben auch tatsächlich verpflichtend gemacht werden müssen. Das EDIfact-Format ist da noch „einen Tick“ umfangreicher. Im Bild unten sehen Sie nur einen Teil dieser Struktur:

    VDA4905_Quellstruktur_2 DELFOR_D12B_Zielstruktur
    Struktur des Formats VDA4905 in Lobster_data Struktur des EDIfact DELFOR (Version D 12 B) in Lobster_data


    Sie sehen rechts zum Beispiel in der Segmentgruppe 2 (SG2) ein NAD-Segment, NAD steht für „Name and address“. Ein weiteres solches Segment sehen Sie in der SG7, die unterhalb der SG6 liegt, in der es um Vorgehensanweisungen (Processing instructions) geht. Und was man hier nicht sieht: Noch weiter in den Tiefen der Struktur kommt das NAD noch einmal vor, auf Ebene der einzelnen Positionen. Es gibt also nicht die Umsetzung schlechthin von VDA4905 in DELFOR, sondern eine ganze Palette von Möglichkeiten.

    Genau hier haben Sie dem Dienstleister gegenüber einen gewaltigen Wissensvorsprung: Sie wissen, welches der vielen, im DELFOR vorkommenden, NAD-Segmente in diesem speziellen Fall genutzt werden soll. Oder Sie können diese Information zumindest direkt bei Ihrem Partner, für den die Daten bestimmt sind, erfragen. Hinzu kommt: Im VDA-Format gibt es gerade ein mal die Kundennummern von Lieferant und Kunde, detaillierte Adressinformationen kommen hier gar nicht vor. Sie wissen aber dann, ob es reicht, einfach ebenfalls Kunden- und Lieferantennummer einzutragen, wie sie im VDA stehen, ob man sie von einem Nummernkreis auf einen anderen (ILN) umsetzen muss oder ob auch die gesamten Adressangaben benötigt werden. Und noch viel wichtiger: Sie wissen, aus welchem Ihrer Systeme Sie diese Informationen bekommen können und auf welchem Wege.

    Das alles können Sie natürlich dem Dienstleister, der für Sie die Konvertierung aufsetzt, mitteilen. Es verursacht aber zusätzlichen Kommunikationsaufwand, der erfahrungsgemäß in ein ausgiebiges Frage-Antwort-Spiel ausartet. Bei komplexen Prozessen, die die Gegebenheiten in Ihrem Unternehmen berücksichtigen müssen, wird das Ganze noch viel spaßiger.

    Was Administration, Anbindung von Systemen und Kommunikation angeht, sieht es ähnlich zweigeteilt aus. Einerseits hat natürlich der Hersteller der Software oder ein spezialisierter Dienstleister die größte Erfahrung nicht nur mit seinem System, sondern auch bezüglich des Zusammenspiels bestimmter Fremdsystemen (z.B. Datenbanken). Andererseits sind doch wieder Sie es, die erst die nötigen Informationen zusammenstellen und ihm weiterreichen müssen, damit er das Ganze dann umsetzt. Mal salopp gesagt: Bis dahin haben Sie’s auch schon selbst erledigt.


    • Sie müssen nicht im eigenen Hause tiefergehendes Wissen über die Funktionsweise des Systems aufbauen.
    • Konvertierungen und andere Prozesse profitieren von der Erfahrung des Dienstleisters im Umgang mit der Software.
    • Sie sparen sich personellen Aufwand.


    • Hoher Kommunikationsaufwand für jede neue Anbindung, jeden neuen Prozess und jede Änderung
    • Sie müssen immer noch einen Teil der Arbeit machen, um den Dienstleister mit den nötigen Informationen zu versorgen.
    • Der Dienstleister kann nicht immer sofort reagieren, Sie sind auf seine Resourcen angewiesen.
    • Evtl. müssen Sie dem Dienstleister Informationen geben, die Sie eigentlich lieber im Hause behalten möchten.

    Wenn das System schon bei Ihnen im Hause steht, sollten Sie es nutzen, indem Sie volle Kontrolle über alles behalten. Sicher können Sie einige Arbeiten an einen Dienstleister auslagern, was den anfänglichen Schulungsaufwand reduziert und schneller zu guten Ergebnissen führen kann. Erwarten Sie aber nicht, dem Dienstleister nur ein paar Stichworte zu geben und dann entspannt auf das Ergebnis warten können. Sie können Arbeitszeit ihrer Mitarbeiter einsparen, aber ganz ohne geht es nicht.

SaaS stands for ‘software as a service’ – the service being that you can use software that is installed on the provider’s premises rather than your own. You will always hear the latest buzzword ‘cloud’ spoken in this context – though it’s completely meaningless, since the meaning remains the same.

So what does this look like in reality?

The EDI system is installed somewhere in a data centre – theoretically on the other side of the world. The data centre operator ensures that the system is highly available, takes care of data backups, installs updates and bug fixes, and – of course – provides the entire communications infrastructure. You make use of all this from your business premises via

the Internet, a browser or a special client. You can set up communications channels from the data centre to both your partners and yourself, since the data need to be able to travel back and forth between your systems and the EDI system in the data centre. You can also map out data conversions and process chains exactly as you need to – this is fully under your control. And of course, you can keep an eye on whether everything is running smoothly. So far, so good. It means you save money on hardware and infrastructure, and the entire system administration is also left up to the operator.

And because the system isn’t installed on your premises, you just pay for usage rather than for an entire system up-front. There are various tariff models available, so you can be charged per active interface, by the number of messages/conversions, by volume of data, and much more besides. This naturally saves you having to make substantial initial investments.

Yet the concept quickly reaches its limits once your requirements go beyond simple format conversions and communication. For instance, things get complicated when you also need to enrich data – e.g. by obtaining name and address data to go with a customer number. This is because data of this kind are stored in databases and in other systems on your own network, and not in the data centre. Of course, you can build a VPN link to allow the data centre to access your network, but that will have a big impact on performance – not to mention the accompanying security issues. It’s also an additional point of weakness, since while the data centre might be able to guarantee high availability, the VPN link can quickly collapse under the weight of DSL problems (for example).

If all you have are simply designed EDI processes – just data transport and conversion – then SaaS can be a very good option. It may also be possible to tack on simple enrichment and implementation tasks (e.g. country codes) relating to small files. Yet if a closer connection to the rest of your IT landscape is needed, SaaS will quickly get you into difficulties. If you need a single system that can also carry out EAI or ETL tasks, then you will have to turn to an in-house solution.

Pros & Cons:


  • No need for either hardware or infrastructure (aside from an Internet connection).
  • A data centre can guarantee you a whole other level of availability.
  • You don’t need to worry about purely administrative tasks, such as updates.
  • There are no major initial investments involved.



  • You are dependent on the reliability of the operator.
  • The rest of your IT landscape is inaccessible, or accessible only by making special arrangements.
  • This means there is no chance of using the same system to also handle EAI or ETL matters.
  • Business-critical data and processes are stored with a third-party.
  • The running costs can quickly mount up to become more expensive than an in-house solution would have been, depending on the intensity of use and the tariff model.


If you are currently only looking into EDI because your business partners have asked you to, and you don’t have more than a handful of simple connections to make, then SaaS can look very enticing. However, if you can foresee that this whole area will grow for you over the next few years (and there is a very good chance that it will), then you should look for a provider who will let you adopt both options. You could start with SaaS (or even EDIaaS), and then simply move the interfaces to your own premises when the time comes for an in-house installation. If you are using the same software then a transfer of this kind shouldn’t prove too difficult.

When you use EDIaaS, you have very, very little to do with the entire EDI process, since EDI as a Service means that everything is handled by a service provider – from operating the hardware the configuring the communication paths and data conversions, and even monitoring, too.

Of course, that all sounds amazingly convenient, as your work then essentially consists of passing data intended for your partners to the service provider, who will then supply them to the recipients in the right format and subsequently accept delivery of the processed data back from your partners. All your systems need to do is generate the right data and read it back in.

Yet in practice, your work doesn’t quite stop there. Your service provider might fine-tune your communications with your partners for you, and may even take charge of finding out how accurate their data need to be – yet you will still need to explain to the provider how your own data are structured and exactly how you want them to process your partners’

data for you. That said, of all the available solutions, this is definitely the one that involves the least amount of effort on your part.

What’s more, EDIaaS also leaves you with virtually no control over what happens to your business-critical data. At best, you will be able to check whether your provider thinks everything is running smoothly, or if any processes have crashed. In the worst case scenario, you will only find out about any problems when your partners start complaining

about unclean data or data that fails to arrive altogether, or when you find data going missing yourself.

On top of that, every time you want to make a new connection or even the smallest change, you will need to submit an order to your service provider, make an additional payment for the service, and wait until the provider has enough available manpower to fulfil your order.

And last but not least, there is the disadvantage we encountered with SaaS that your systems are inaccessible, or accessible only under very restricted conditions. What if you just want to quickly retrieve the address data for a particular customer number from your database? No can do.

Pro & Cons


  • No in-house hardware or infrastructure required – instead, you get the reliability of a data centre.
  • Service providers generally offer a wide range of possible communication paths.
  • The service provider has a lot of experience in dealing with software and data formats, as they work with these on a daily basis.
  • There are no major initial investments involved.
  • Relatively little work required on your part.





  • No control whatsoever over business-critical data and processes.
  • Complete dependence on the service provider (trustworthiness, human resources, etc.).
  • The rest of your IT landscape is inaccessible, or accessible only by making special arrangements.
  • That means there is no chance of using the same system to handle EAI or ETL matters.
  • Depending on the usage intensity and the tariff model, the running costs can quickly mount up to be more expensive than if you were using an in-house solution.


Even more so than SaaS, EDIaaS is suitable only for a handful of very simple EDI scenarios. When things get significantly more complex, this solution becomes ineffective. And it also leaves you with less control over your own data and business-critical processes than was the case with SaaS. The same advice applies here: If you want to use this method as a starting point for EDI, you should choose your provider intelligently so as to give yourself the option of switching to a more flexible alternative at a later date without having to completely reconfigure everything.

Open Internet vs. VAN
EDI communication is the alpha and omega – quite literally! After all, the beginning and the ending – the alpha and omega – of every EDI process consists of communication. Both your data and the customers somehow need to get into the EDI system, and then come back to the customer or to you afterwards. Whereas this was previously done by fax, through the post or over the phone, nowadays the Internet offers a whole host of protocols for communication and remote data transmission. And new ones are being developed all the time. Here is a short list of the most common:

  • FTP(S): File Transfer Protocol (with optional SSL encryption).
  • SMTP/POP3/IMAP: Classic email.
  • SFTP and SCP: Secure FTP und Secure Copy – both methods of transfer involving SSH tunnels.
  • HTTP(S): The well-known Hypertext Transfer Protocol (with optional SSL encryption).
  • OFTP: Odette File Transfer Protocol. Only its name has anything to do with the widely used FTP. This was actually originally a temporary solution that has remained with us, and is already in its second version.
  • AS2: Applicability Statement 2. The actual data transfer itself takes place via HTTP(S), but comes with a wide range of security layers, including multiple options for encrypting and signing the data. The sender also receives an immediate notification to tell them whether their data were received cleanly.
  • WebDAV: Web-based Distributed Authoring and Versioning – an extension of HTTP that offers more possibilities for data transfer (entire directories), as well as user rights and versioning.


We will describe all of these communication paths in more detail later on.

There are also other ways to exchange data with partners beyond the general Internet, in combination with these (and a few other) EDI communication options. For example, OFTP initially only worked via direct ISDN connections between the partners in the communication, which is naturally more secure than a normal FTP transfer, and especially more so than simply sending emails over the Internet. A type of service that provides (mostly) secure transfers – often coupled with a few additional services – is the Value

Added Network, or VAN for short.

This concept comes from the pre-Internet era, when it was used to achieve two key


  • VAN customers didn’t need to negotiate their own communications with every single business partner, and if their partners were connected to the same VAN, they could use the VAN to hand the data over directly along with instructions for where the data needed to go. In the ideal scenario (i.e. every partner using the same VAN), only one connection was needed to get through to everybody.
  • And because a VAN of this kind wasn’t publicly accessible (unlike the Internet today), the operator could also make sure that nobody was secretly listening in or disrupting traffic. In other words, they could guarantee secure transfers.

In certain respects, these points are still valid today – although nowadays, the “value” is added through processes such as data conversion, which means that VANs tend to behave a little like EDIaaS services. The question here is: What should you use when you want to set up an EDI system? Should you connect to a VAN, or simply use the Internet, since you have access it to anyway? Of course, this question only comes up if you want to operate an EDI system of your own (including one that is hosted under SaaS) instead of just using EDIaaS. Let’s take another look at the two main advantages of the VAN:

One connection for everybody

This might sound fantastic at first, but it’s only an ideal scenario. For it to happen in practice, every single communication partner needs to be connected to the same VAN, which is rather an unlikely proposition. Of course, it’s possible that the VAN might offer you communication with “the outside world” – but then you’re back on the normal Internet, where advantage 2 no longer applies. Configuring the various communication channels shouldn’t prove too difficult with decent EDI software, since we’ve come a long way in that regard over the last few years.

Closed user group & secure transfer

Leaving aside the fact that there is no such thing as an unhackable network, a huge range of widely available standards have now been developed especially for secure transfers. Whether HTTPS, FTPS, SFTP/SCP or AS2, encryption is used everywhere. With AS2, there are many different ways for you to work with encryption and data signatures, and receipt confirmations are mandatory here too. So if you use modern transfer methods, you’ll find that this benefit has long since been matched online.

In other words, the advantages that VANs used to enjoy have been largely caught up on during the evolution of the Internet. The disadvantage remains unchanged, however: it costs more money. Whether you’re charged a monthly or annual fee or an additional fee for each file you send or receive, you will be paying extra for a service that you could just

as well obtain via another method.

As mentioned above, we are discussing a situation where the extra work involved in EDI (e.g. conversion, reconciliation, enrichment, and so on) is already covered by a specialist system. If all you need is simple EDIaaS, the offer of a suitable VAN may be sufficient for your needs (although in this day and age, it is barely imaginable that anyone would willingly restrict themselves solely to communication partners who are connected to the same system…).