Does Every Trading Partner Need Full EDI?

No. Full EDI integration only earns its keep once a partner crosses a predictable volume and complexity line. Below that line, a web EDI portal is cheaper, faster to deploy, and honestly less to maintain. Running both models inside the same trading partner community isn't a compromise — it's how every EDI program with more than a handful of partners actually operates.

If you're managing 100+ suppliers or carriers, this isn't the "should my small business get EDI" question you'll find on most provider blogs. You're not deciding whether EDI makes sense at all — you're deciding, partner by partner, which ones justify an AS2 or X12 integration against your ERP and which ones are fine logging into a browser. Get that segmentation wrong in either direction and you pay for it, just in different currencies.

What volume signals it's time to move a partner off a web portal?

The clearest number comes from EDI providers who manage both models side by side: according to BOLD VAN, the volume threshold is clear: under 50 orders per week, a web portal handles the load fine, while for most manufacturers and distributors processing more than 50–100 documents per week, the portal becomes the very thing slowing them down.

A separate retail-side benchmark lands in a similar place but measures by month, not week. Retailerhub.ai's vendor guide notes that at 50–200 orders per month, an integrated EDI solution that connects to your ERP or inventory system eliminates manual data entry and reduces errors, and above 200 orders per month, you need full-service EDI with dedicated support.

Notice the unit mismatch. One source measures weekly volume, the other monthly. If you try to copy either number verbatim into a policy document, you'll either over-integrate your mid-tier partners or leave genuinely high-volume ones stuck on a portal for an extra year. Build your own threshold using your own document counts — POs, ASNs, and invoices combined, not just POs — and treat the 50-100 weekly / 50-200 monthly range as a zone that needs a complexity check (how many SKUs per order, how many ship-to locations, whether the partner also requires 856s and 810s) rather than a straight volume cutoff.

Can you run web EDI and full EDI in the same trading partner community?

Yes, and it's the normal pattern rather than a fallback. Not every supplier or carrier in your network has the same order volume or technical capability, so most enterprise EDI programs end up running a mix deliberately rather than by accident.

Cleo frames the choice as three tiers, not two. Web EDI fits when you need a fast, affordable way to meet trading-partner EDI requirements with limited IT resources, integrated EDI software fits when you need automation between EDI and internal systems like ERP, WMS, TMS, accounting, or shipping tools, and managed EDI fits when you want an expert team to handle onboarding, mapping, monitoring, issue resolution, and ongoing trading partner changes. Map your partner list against those three buckets and you'll usually find you already have all three running — you just haven't written down why.

Most EDI directors inherit this mix by accident. Whoever onboarded a given partner five years ago picked whatever tool was fastest at the time, and nobody has revisited it since. The fix isn't exotic: build a documented tier policy with the volume thresholds above, review it annually against actual transaction counts, and assign an owner for moving partners between tiers when they cross a line.

What does it actually cost to leave a partner on manual web EDI too long?

The hidden cost shows up in labor and chargebacks, not in your subscription invoice. Industry benchmarks for manual order processing put the number at between $8 and $15 per manually processed order, depending on labor cost, error rate, and overhead. Multiply that by weekly order count on any partner you're still rekeying by hand, and the break-even point against a full integration arrives faster than most IT budgets assume. That math matches what happens when a high-volume account stays on a portal past its expiration date. BOLD VAN's Costco case notes that manual re-entry errors on a growing vendor's account generate compliance errors that generate chargebacks of $25–$100 per incident and the labor costs that exceed a full EDI integration's monthly fee. A national account pushing thousands of orders a year through a mature procurement system is exactly the kind of partner EDI was built for. Leave that partner on a portal and you're not saving money, you're postponing a chargeback.

Should a new trading partner always start on a portal?

Generally, yes — treat web EDI as a staging ground rather than a permanent home. Orderful's guidance for growing trading relationships describes the pattern directly: start with web EDI for simple browser-based document exchange that requires no ERP changes, then scale to fully integrated EDI with direct API connections as transaction volume increases.

The caveat for enterprise buyers is the one piece competitors skip: this only works if your platform actually supports both models without forcing a re-platform later. Some legacy VAN-based portals were built as standalone products with no upgrade path into ERP-connected EDI, which means "starting on a portal" quietly becomes "stuck on a portal" the day volume justifies something better. When you're evaluating a new EDI provider, ask explicitly how a partner moves from portal to integration — same contract, same mapping work reused, or a fresh onboarding from scratch.

Where does this segmentation logic apply beyond purchase orders?

The same logic applies to carrier-facing documents — tenders, status updates, invoices — just measured in a different direction. Large carriers can usually support full EDI integration for 204s, 214s, and 210s. Small and regional carriers often can't run an AS2 connection at all and need a portal or API bridge instead, which is the gap that dedicated carrier-connectivity layers exist to close.

Cargoson sits in this category alongside platforms like MercuryGate, Descartes, Alpega, and Transporeon — built this way, alongside enterprise TMS players to run EDI and API-only carriers under one execution layer instead of forcing every carrier onto the same protocol. For a shipper managing a mixed carrier base, that's the transport-side version of the exact same question you're asking about suppliers: which carriers justify the integration overhead, and which ones are fine on a lighter connection.

What are the warning signs a trading partner is on the wrong tier?

Run this check quarterly against your partner list rather than waiting for a crisis to force the review:

• Recurring manual-entry chargebacks on a high-volume account — this partner should have moved to full integration months ago.
• A low-volume partner sitting on a full AS2 or VAN connection that barely gets used — wasted mapping and maintenance cost, and a candidate for down-tiering to a portal.
• Rising support tickets from a partner's own staff logging into a portal that's clearly outgrown their current order volume.
• Document volume that's crept past your internal threshold without anyone re-running the complexity assessment.

None of these show up on a dashboard by default — they show up when someone actually pulls partner-level transaction counts and compares them against the tier each partner is sitting in. That's a half-day exercise once a quarter. Skip it for a year and you'll find the mis-segmentation costs — chargebacks on one end, wasted integration spend on the other — add up to more than the review would have cost.