Every EDI project has two budgets. The first is the one everyone plans for: software, mapping, testing, project management. The second one shows up in the first trading-partner invoice and never really goes away — the cost of moving the bytes.
That second budget is the connection layer: how your EDI documents physically travel between you and your trading partners. For forty years there have been exactly two ways to do it, and the choice still quietly shapes what your EDI costs, how fast you onboard partners, and how much your team trusts the pipeline at 2 a.m.
The mailbox model
A Value-Added Network — a VAN — is a private mailbox network for EDI traffic. You send documents to your VAN, the VAN stores them, and your trading partner picks them up from its own mailbox, either on the same VAN or through an interconnect to a different one.
The appeal was never technical elegance. It was auditability. A VAN gives you non-repudiation of receipt at the network layer: the document arrived in the partner's mailbox at a provable time, independent of whether their ERP ever read it. For a chargeback dispute, that timestamp can be the difference between "we shipped it" and "prove it."
The costs are just as predictable. VANs historically bill per kilo-character — per thousand characters transmitted — with minimums, interconnect surcharges when your partner is on a different network, and retrieval fees that survive long after the business relationship ends. Kilo-character billing made a certain sense when documents were expensive to move. In 2026, when the same 850 purchase order is a few kilobytes of text, it is mostly an artifact of a pricing model that predates the public internet, persisting because contracts auto-renew.
The direct model
The alternative is a direct connection: AS2, SFTP, or an API endpoint pointed straight at the trading partner, no mailbox in the middle. AS2 in particular put the guarantees the VAN sold — encryption, signing, and a signed Message Disposition Notification (MDN) back as proof of receipt — directly into the protocol. Your MDN is your non-repudiation receipt; you hold it yourself.
The economics invert. There is no per-character toll, so your cost curve is roughly flat regardless of volume. The cost moves into engineering and operations: digital certificates that expire on a schedule nobody owns until the night they lapse, firewall allowlists to coordinate with a partner's IT team, transfer windows, and the pager when a partner's SFTP drop silently fills up. Direct rewards teams that treat connections as a portfolio to operate, not a set of one-off IT tickets.
What actually breaks in production
In practice, VAN failures are quiet and commercial: a sender/receiver ID mismatch that routes production documents to a test mailbox, an interconnect agreement lapse that parks your invoices in a network-to-network no-man's-land, or a sudden "out-of-band" notice that your traffic is being throttled under a fair-use clause you never read. Because the network is someone else's computer, your debugging surface ends at their status page.
Direct failures are loud and technical: the expired AS2 certificate at quarter-end close, the partner whose SFTP host key rotated without notice, the signed MDN that comes back unverifiable because of a canonicalization mismatch. The difference is that every one of these is fixable by your team, on your clock. The question is never which model fails — both do — it's whose dashboard you're refreshing when they fail.
The decision that actually matters
Strip away the history and most teams end up choosing on three questions.
First: how many partners, how much volume? Per-character pricing punishes scale; direct connections punish breadth. Forty partners at high volume is an argument for direct. Five partners at low volume is an argument for whoever answers the phone.
Second: who owns the on-call? A mailbox you can't see into is still better than a connection your team can't staff. If nobody on your team can explain how an MDN is validated, a managed connection — VAN or otherwise — buys you an operator, not just a network.
Third: what's your evidence standard? Retail compliance disputes are fought on delivery proof. When a retailer claims an ASN never arrived, both an interconnect receipt and a signed MDN answer the question — but only if someone retained the artifact and can produce it months later. Proof of delivery is a record-keeping discipline, not a network feature.
Whether you go direct or stay on a VAN, the unbudgeted cost is always the same: somebody has to care about the last mile after the project plan ends. This is the problem we built SignalEDI to take off small teams — flat monthly pricing, AI-assisted mapping, and managed connections so the certificate expiry and the mailbox gotcha are our pager problem, not yours.
If your EDI budget has a line item nobody can explain, it's probably the last mile. It deserves the same scrutiny as the mapping it carries.
— Chris, founder of SignalEDI
Top comments (0)