What Is an EDI VAN? A Plain Explanation

What an EDI VAN is, how it routes documents between trading partners, and when it beats direct AS2 or API connections.

Share

What is an EDI VAN?

An EDI VAN (value-added network) is a secure third-party network that routes electronic business documents between trading partners, acting as a shared mailbox system so a company connects once instead of building a separate connection for every supplier or customer. The term is interchangeable with "value-added network" or "EDI network provider," and it's one of the oldest pieces of infrastructure in B2B integration. The "value-added" part isn't marketing fluff, even if it sounds like it. A B2B/EDI VAN carries B2B EDI traffic through one secure connection instead of many direct links, letting businesses send communications to and from a central virtual mailbox hosted by the VAN provider, with encryption keeping transfers safe. If you've ever heard someone call it a "digital post office," that's not far off. A VAN functions much like a mailbox, acting as a private business network that enables the secure exchange and delivery of electronic data between business partners.

How a document actually moves through a VAN (hop by hop)

The mechanics are simpler than most new EDI hires expect, once you strip away the vendor jargon. Your ERP or EDI translator generates the X12 or EDIFACT file, wraps it in an interchange envelope (ISA/GS/ST for X12), and pushes it to your VAN using whatever protocol your contract specifies, commonly AS2, SFTP, or HTTPS these days, though older setups still use dial-up-derived protocols. A company sends an EDI transaction to a receiver's VAN mailbox via a proprietary protocol, originally through dial-up.

The VAN validates the envelope structure, deposits the document into the recipient's virtual mailbox, and the recipient polls that mailbox or receives a push notification depending on their setup. A response to the EDI transaction is sent back if needed, which in practice usually means a 997 or 999 functional acknowledgment confirming the file was received and syntactically valid, not that the business process behind it was accepted.

Here's the part that trips people up: not every trading partner sits on the same VAN. When your company's traffic runs through TrueCommerce but your customer's mailbox lives on SPS Commerce, the two networks hand the document off to each other automatically. Not every company uses the same VAN. Established VANs maintain interconnect agreements with each other, so a document sent through your VAN can reach a partner on a different one, much like email moving between providers. You never see this handoff happen. It's invisible by design, which is exactly the point of paying for a managed network instead of building bilateral connections yourself.

VAN vs AS2 vs API: what actually gets confused

These three terms get used interchangeably in meetings, which causes real confusion because they operate at different layers. A VAN is not a document standard like X12 or EDIFACT, and it's not a replacement for either. It's the transport and routing layer underneath them.

AS2 is a point-to-point protocol: your system connects directly to your partner's system, no intermediary mailbox involved. Through an HTTPS connection, an encrypted document is sent straight to the trading partner, using a direct, point-to-point communication route in contrast to a VAN. A VAN, by contrast, is hub-and-spoke: you connect once to the network, and the network manages delivery to everyone else on it. The four primary differences between EDI VAN and AS2 are delivery method, with a VAN using a mailbox intermediary versus AS2's direct peer-to-peer model, simultaneous connectivity requirement, protocol flexibility, and delivery confirmation. API is a newer, separate idea entirely: instead of exchanging flat-file EDI documents at all, systems call each other's endpoints directly to exchange structured data in near real time. It solves a similar connectivity problem to AS2 but usually bypasses the EDI document format altogether.

FactorEDI VANAS2API
Connection modelHub-and-spoke, mailbox-basedDirect point-to-pointDirect point-to-point
Partner onboardingConfigure once, reach any VAN-connected partnerNegotiate and test certificates per partnerNegotiate and test per partner
Typical cost structureUsage-based, often per kilocharacterFixed infrastructure cost, low marginal costDevelopment and maintenance cost per integration
Best suited forLarge, fragmented partner networksHigh-volume partners who mandate it (Walmart)Modern partners open to real-time data exchange

In practice, most mid-size shippers run a hybrid. VAN is best suited for businesses managing a large network of trading partners because it simplifies routing, monitoring, and partner connectivity, so you'll often see direct AS2 with a handful of large retailers who mandate it, and VAN connectivity for the long tail of smaller suppliers who don't have the infrastructure or appetite for per-partner certificate management.

You'll find the same "one connection versus dozens" problem on the transport execution side. Platforms like Cargoson, MercuryGate, Transporeon, and Alpega sit between a shipper and dozens of carrier APIs and EDI feeds the same way a VAN sits between a shipper and dozens of trading partner mailboxes. Different domain, identical architectural logic.

What "value-added" actually costs

The services bundled into a VAN subscription typically include:

  • Protocol and format translation between different communication standards
  • Mailboxing and asynchronous delivery so partners don't need to be online simultaneously
  • Delivery confirmation, audit trails, and retransmission of failed sends
  • Compliance validation against individual trading partner specifications

Pricing is where VANs get a reputation for being opaque. Traditional VAN pricing is usage-based, and the unit is usually the kilocharacter, a thousand characters of data transmitted, which surprises people used to per-document pricing but is the industry's historical billing standard. Traditional VAN providers use kilo-character pricing based on file size where one KC equals 1,000 characters, so a 250,000-character transmission equals 250 KCs, and at a rate of $0.20 per KC the fee works out to $50. Flat-fee challengers have emerged specifically to compete with this model, which is worth its own comparison post, but it's the reason finance teams often ask why the EDI line item fluctuates month to month even when transaction volume looks flat.

FAQ

What does VAN stand for in EDI?
Value-Added Network. The "value-added" refers to services layered on top of basic document transport, like mailboxing, translation, and tracking.

Is a VAN the same as EDI software?
No. A VAN is network infrastructure for moving documents. EDI software, like a translator or mapping engine, is what generates and parses those documents before and after the VAN handles transport.

Do I still need a VAN if I use AS2?
Not for partners you connect to directly via AS2. Most businesses don't choose between EDI VAN and AS2 outright; their trading partners choose for them, which is why most companies end up running both simultaneously rather than picking one.

Can a VAN handle non-EDI file formats like CSV or JSON?
Many modern VAN providers support additional file types and protocols alongside traditional EDI standards, but this varies by provider and should be confirmed in your contract rather than assumed.

Who are the major EDI VAN providers?
SPS Commerce, TrueCommerce, Cleo, and IBM Sterling are among the most widely used in supply chain EDI, alongside Axway, which also offers API-enabled VAN connectivity for companies managing hybrid environments.

Is EDI becoming obsolete because VANs are fading out?
No. VANs remain embedded in retail, automotive, and healthcare EDI compliance programs. The shift happening industry-wide is toward hybrid models, direct AS2 or API for high-volume partners, VAN for everyone else, rather than a wholesale replacement of one by the other.