What Is an EDI VAN? A Plain Explainer
What an EDI VAN is, how it differs from AS2 and API connections, and when supply chain teams still need one in 2026.
What is an EDI VAN?
An EDI VAN (Value Added Network) is a third-party managed network that acts as a secure intermediary between trading partners, so a company connects once to the VAN instead of building a separate connection to every supplier, customer, or carrier it works with. A value-added network is a hosted service that routes, stores, and secures EDI documents between trading partners, simplifying data exchange. The "value-added" part of the name refers to what the network does beyond raw transmission. A VAN in B2B EDI is a trusted intermediary, a secure virtual "post office" for business documents that provides each trading partner with a virtual mailbox, accepts EDI documents, sorts and delivers them, handles encryption, validation, and notifications, and allows flexible protocol conversion between formats like SFTP and AS2. That translation and mailboxing layer is the "value added" over just moving bytes from A to B.
How a VAN actually moves a document
Picture a supplier sending a purchase order response or an ASN into a retailer's system. Your trading partner's EDI software connects to the VAN, translates the EDI document into their preferred format, and prepares it for processing in their order management system. The mailbox model matters because it doesn't require both sides to be online at the same moment. That's the key structural difference from a direct connection: a mailbox holds the message until the recipient checks in, rather than requiring a live session between two systems. One of its standout features is mailboxing: each partner has a secure inbox and outbox within the VAN, and messages are delivered regardless of whether the recipient is online or ready. That's genuinely useful when you're dealing with hundreds of partners, some running modern cloud ERPs and others still running batch jobs overnight.
VAN vs AS2 vs API: what's the actual difference
The confusion here is common enough that it's worth stating plainly: a VAN is a service model (an intermediary business), while AS2 is a transmission protocol (a way of moving a file securely over the internet). A VAN can use AS2 internally to connect to you, and you can also use AS2 directly with a trading partner without any VAN involved at all. A VAN is a private network provider offering a hosted service to facilitate secure data sharing by acting as an intermediary, whereas AS2 is a protocol that enables secure, direct transfer of EDI documents over the internet without relying on a third-party network. That's why "VAN vs AS2" is a slightly misleading framing. You're really comparing "should a third party sit in the middle" against "should we connect point-to-point."
| Approach | Connection model | Best fit | Main tradeoff |
|---|---|---|---|
| VAN | Hub-and-spoke, store-and-forward mailbox | Many partners, mixed technical capability, low IT overhead desired | Cost model is per kilo-character, document, or connection, which can grow expensive at scale, plus dependency on a third party for routing and delivery performance |
| AS2 | Direct, point-to-point, encrypted over HTTP/HTTPS | A handful of high-volume partners, especially retailers that mandate it | Both parties must be online during an AS2 exchange, as undelivered messages can't be stored on a server or digital mailbox |
| API | Real-time request/response, not a batch document model | ERP/TMS/WMS systems that need live status, not periodic file drops | Using APIs for B2B data exchange can become difficult as partner count grows, since there is little standardisation and each partner may request pulling, pushing, or a mix of both |
Walmart is the case study people usually reach for on the AS2 side. AS2 rose in popularity drastically after Walmart required its suppliers to use it, and many other large retailers followed suit, meaning AS2 quickly became the most popular EDI protocol across many industries for point-to-point connections. If you supply a retailer of that scale, you may not get a choice between VAN and AS2. The retailer's compliance guide makes the decision for you.
Where VANs still fit in transport and carrier EDI
Carrier and 3PL EDI (204 load tenders, 210 invoices, 214 status updates, 990 responses) still runs through VANs in a lot of freight networks, mainly because carrier fleets range from large asset-based operators with full API stacks down to small regional carriers running whatever their TMS vendor gave them a decade ago. A VAN absorbs that variance without you having to build a custom connection for each one. VANs operate similarly to a digital post office, each business receives a virtual mailbox where documents are delivered and managed, and the primary function is to simplify electronic trading so businesses use one connection into a network that reaches all their partners. That's exactly the pattern that keeps VANs relevant in freight, where you might have 40 carriers and only 5 of them can support a modern API. That said, the direction of travel for carrier connectivity is API-first where the carrier can support it. Freight visibility and TMS platforms like MercuryGate, Descartes, project44, and Transporeon increasingly offer native API integrations that skip VAN mailbox fees entirely for carriers with the technical capability, and multi-carrier platforms such as Cargoson and nShift take a similar approach on the parcel and transport side, blending API connections with EDI/VAN fallback for partners who aren't there yet. The realistic setup for most shippers in 2026 is hybrid: API where you can get it, AS2 for the retailers who demand it, VAN for everyone else.
What a VAN costs
VAN pricing is usually built around a few components stacked together: a per-kilocharacter or per-document transmission fee, a mailbox fee per trading partner, and sometimes onboarding charges. VANs typically charge per kilo-character, document, or connection, which can grow expensive at scale, and switching providers later isn't free either. Vendor lock-in concerns exist when extensive customizations or integrations are built specifically for a particular VAN provider, and migrating to alternative solutions can require significant effort and investment. That's the trade you're making for not having to build and monitor dozens of direct connections yourself.
FAQ
Is a VAN required for EDI? No. AS2 is a protocol that enables the secure and direct transfer of EDI documents over the Internet, and unlike VANs, it does not rely on a third-party network provider, so you can trade directly with partners who support it.
What's the difference between a VAN and a B2B integration platform or iPaaS? A classic VAN is primarily a network and mailbox service. Integration platforms combine the best of all worlds, supporting VAN-like mailboxing, handling AS2/SFTP connections, and increasingly offering API connectivity all from one unified platform, which is why the line between "VAN" and "iPaaS" has blurred.
Do VANs still matter in an API-first world? Yes, for the segment of partners who can't or won't support direct connections. The realistic pattern most companies land on is hybrid rather than picking one method for everything.
What's a mailbox in EDI terms? Each partner has a secure inbox and outbox within the VAN, and messages are delivered regardless of whether the recipient is online or ready. It's the store-and-forward buffer that lets asynchronous partners still trade reliably.
Can a company use multiple VANs? Yes, and many do, especially after acquisitions or when different divisions inherited different providers. If your trading partner is using another VAN, you should either ask them to subscribe to your VAN or subscribe to theirs, which is one reason interconnect agreements between VAN providers exist in the first place.
