EDI Protocol Comparison: AS2, SFTP, FTPS, AS4, FTP, OFTP2, and VAN

What is EDI?

EDI, or electronic data interchange, is how companies exchange business information and documents electronically with other organizations. That includes purchase orders, invoices, financial transactions, shipping notices, inventory updates, claims, supplier reports, and other files that move between business partners.

These exchanges usually happen across supply chains and business networks. A retailer may send purchase orders to suppliers. A manufacturer may share inventory or production data with distributors. A healthcare organization may exchange claims or eligibility files. A logistics provider may send shipping updates.

The goal is to keep business systems talking to each other without relying on manual uploads, email attachments, or someone retyping document data into another platform.

The EDI protocol shapes how secure, reliable, traceable, and manageable the exchange will be. It affects whether the file is encrypted in transit, how each partner authenticates, whether delivery can be confirmed, how failed transfers are handled, how easily the workflow can be automated, and how much infrastructure your team has to maintain.

So, when people compare EDI communication protocols like AS2, SFTP, FTPS, AS4, OFTP2, or VAN-based exchange, they’re comparing different ways to handle trust, delivery, partner access, operational overhead, and proof that the right business document reached the right system.

EDI standards vs. EDI protocols

EDI standards and EDI protocols are related, but they’re not the same thing.

EDI standards define the format and structure of the business information inside the document. They help systems understand an order, invoice, financial transaction, shipping notice, claim, or inventory update without a human translating it in the middle.

Common EDI standards include:

• ANSI X12, used heavily in North America
• UN/EDIFACT, used widely in international trade, transport, and commerce
• TRADACOMS, still seen in parts of UK retail

EDI protocols define how the file moves between companies, systems, and trading partners. They handle the transport side of the exchange: connection method, authentication, encryption, receipts, retries, partner access, and sometimes non-repudiation.

A simple way to separate them:

• EDI standards define what’s inside the file.
• EDI protocols define how the file gets delivered.

So, X12 or EDIFACT tells systems how to read the document. AS2, SFTP, FTPS, AS4, OFTP2, or a VAN helps get that document where it needs to go. Both are part of the same working chain. If the standard is wrong, the receiving system may not understand the file. If the protocol is wrong, the file may be exposed, delayed, rejected, hard to trace, or painful to automate.

What are EDI communication protocols?

EDI communication protocols are the methods used to transmit EDI data between companies, systems, and business partners. They don’t define the format of the order, invoice, payment file, or shipping notice itself. They define how that file is sent, received, protected, acknowledged, and processed.

The most common EDI protocol choices are:

• AS2: A widely used internet EDI protocol for secure business document exchange over HTTP.
• SFTP: An SSH-based file transfer protocol often used for secure, automated EDI file exchange.
• FTPS: FTP secured with TLS, often used when older FTP workflows need encrypted transport.
• AS4: A web services-based B2B messaging profile with support for receipts, security, and message pulling.
• AS3: A less common EDIINT protocol that uses FTP transport with S/MIME security.
• FTP: A legacy file transfer protocol that still appears in older workflows, but isn’t secure enough for sensitive EDI by itself.
• OFTP2: A protocol used heavily in automotive supply chains and large partner file exchange.
• VAN: A value-added network that acts as a managed intermediary for EDI connectivity, routing, translation, and partner onboarding.
• S3-backed file exchange: A cloud storage pattern that can support EDI workflows, although Amazon S3 itself is storage infrastructure, not an EDI protocol.

The right choice depends on the business relationship, not just the technology. A retailer may require AS2. A healthcare partner may prefer SFTP. An automotive supplier may expect OFTP2. A large trading network may already run through a VAN.

Why EDI protocols deserve careful selection

EDI protocols deserve careful selection because electronic document exchange has serious operational impacts.

A purchase order that arrives late can delay fulfillment. An invoice sent to the wrong place can slow payment. A healthcare claim that can’t be traced creates a support and compliance problem. A supplier file transferred over plain FTP may expose data that should never have crossed the network in clear text.

The protocol affects the controls around the exchange: authentication, encryption, receipts, retries, partner access, logging, and operational maintenance.

It affects:

• How suppliers, distributors, manufacturers, retailers, and other partners connect
• How sensitive business documents are protected in transit
• Whether orders, invoices, claims, payment files, and shipping notices can be acknowledged properly
• Whether delivery receipts or non-repudiation are built in
• How much infrastructure your team has to manage
• How easily EDI file transfers can be automated
• How well file activity can be tracked, reviewed, and audited
• How painful partner onboarding becomes as the business network grows

So this isn’t only a file transfer decision. It’s a decision about how recurring business document exchange will work day after day, across real partners, systems, and obligations. Those decisions are easier to make before the first partner connection goes live than after files are already moving through production workflows.

How to choose an EDI protocol

When choosing an EDI protocol, start with the business relationship.

Your trading partners may already decide the protocol for you. Large retailers often specify AS2. Automotive supply chains may require OFTP2. Some healthcare, finance, and logistics partners may accept SFTP or FTPS. A broad trading network may prefer VAN-based exchange because it already connects to many partners.

Then look at the documents you’re exchanging:

• Purchase orders
• Invoices
• Financial transactions
• Shipping notices
• Inventory updates
• Claims or eligibility files
• Supplier reports
• Manufacturing and logistics documents
• Large business files such as CAD files, batch exports, or partner reports

The document mix affects the protocol choice because not every workflow needs the same receipt model, file-size handling, automation pattern, or partner setup.

A recurring invoice workflow may work well over SFTP. A retail trading partner that requires signed receipts may push you toward AS2. A complex partner network may make a VAN more practical than direct one-to-one connections.

Before choosing, ask:

• Partner requirements: Which protocols do your customers, suppliers, retailers, payers, or logistics partners support?
• Security model: Does the protocol support encrypted transport, strong authentication, certificate-based trust, or key-based access?
• Receipts: Do you need MDNs, signed receipts, or formal proof that a message was received?
• Network complexity: Will the protocol work cleanly through firewalls, NAT, and partner networks?
• Automation: Can transfers be scripted, scheduled, triggered, monitored, and retried?
• Auditability: Can your team review logins, uploads, downloads, deletions, failures, and partner activity?
• Operational overhead: Will your team need to manage certificates, servers, firewall rules, patches, storage, backups, and user access?
• File size and volume: Are you sending small EDI files, large batch files, CAD files, or mixed business documents?

No protocol fixes weak governance by itself. A secure EDI workflow still needs access controls, retention rules, monitoring, partner onboarding, and a clear process for failed or disputed transfers.

EDI protocol comparison table

Comparing EDI protocols: Advantages, disadvantages & recommendations

Each EDI protocol solves a different operational problem.

• AS2 is useful when you need formal receipts, partner accountability, and proof that a message was received.
• SFTP is useful when you need secure, automated file exchange without AS2 certificate wrangling.
• FTPS helps when FTP-style workflows need transport security, but still have to work with FTP-based tools.
• AS4 fits web services-based B2B messaging, especially where a partner network or public-sector framework expects it.
• OFTP2 suits automotive supply chains and large partner file exchange.
• VANs support teams that want broader partner connectivity through a managed intermediary.

A poor protocol decision usually comes from looking only at the transport method and ignoring the workflow around it. You need the protocol, but you also need storage, permissions, automation, monitoring, partner access, and logs that show when files were uploaded, downloaded, deleted, or failed.

Now, let's check out the details:

AS2 for EDI

AS2, or Applicability Statement 2, is one of the best-known EDI communication protocols. It’s common in retail, consumer goods, healthcare, logistics, manufacturing, and other industries where companies exchange orders, invoices, shipping notices, payment information, claims, and other business-critical EDI documents with trading partners.

AS2 sends structured business data over HTTP. Its security model uses S/MIME for encryption and digital signatures. It also supports Message Disposition Notifications, or MDNs, which provide formal receipt confirmation.

That receipt model is the main reason AS2 remains widely used. The sender can prove that a specific business message was transmitted, received, and acknowledged by the receiving system.

AS2 is useful when trading partners need:

• Encrypted EDI message exchange
• Digital signatures
• Message integrity checks
• MDN receipt confirmation
• Non-repudiation support
• Clear accountability between sender and receiver

That proof is useful when the file represents an invoice, purchase order, claim, payment file, or shipping document tied to fulfillment, payment, reconciliation, or compliance review.

There's a tradeoff around setup and maintenance. AS2 usually requires partner agreement on certificates, identifiers, endpoint URLs, encryption settings, signing settings, compression choices, MDN behavior, firewall access, and partner-specific configuration.

Those settings aren't just first-day setup work. Certificates expire, partner endpoints change, and each trading relationship may need its own configuration. AS2 can be the right protocol, but it does ask for careful administration.

Use AS2 when your partner requires it, when signed receipts are central to the workflow, or when the business needs formal proof of delivery at the protocol level.

SFTP for EDI

SFTP, or SSH File Transfer Protocol, is one of the most practical options for file-based EDI. It’s widely used when companies need to send and receive orders, invoices, claims, inventory files, supplier reports, financial transaction files, or other structured business documents on a schedule.

SFTP fits the way many business systems already work. A system generates a file, places it in the right folder, another system collects it, processes it, and logs the result. That model is simple, familiar, and easy to automate.

SFTP runs over SSH, provides encrypted transport, and commonly supports password authentication or SSH public key authentication. It also uses a single port, which usually makes firewall and NAT handling simpler than FTP or FTPS.

SFTP is especially useful for:

• Batch EDI file exchange
• Scheduled imports and exports
• Partner uploads and downloads
• Secure file drops in regulated industries
• Automated polling
• Legacy system integration
• Mixed workflows involving EDI, CSV, XML, JSON, reports, and exports

A supplier can upload invoice files to one folder. A retailer can collect order responses from another. A healthcare partner can upload claims exports. Those file events can then trigger processing automatically down the line.

Compared with AS2, SFTP is often easier to explain, deploy, and maintain. It doesn't require AS2-specific MDN behavior, AS2 endpoint tuning, or the same certificate exchange process between every trading partner.

There is one limitation to be clear about. SFTP doesn't include AS2-style MDNs or signed business receipts as part of the protocol. If the workflow needs formal proof that a specific EDI message was received and accepted, that proof has to come from another layer.

An enterprise managed file transfer solution, for example, may include:

• Application-level acknowledgments
• Partner response files
• Audit logs
• Webhook events
• Transfer notifications
• File-level signatures

For many file-based EDI workflows, this is ideal. The business doesn’t always need an AS2 MDN. It may need secure partner access, reliable uploads, predictable folder structure, automated processing, and activity logs that show who did what.

This is where managed SFTP becomes far more practical than a DIY SFTP server. SFTP To Go supports SFTP with cloud-backed storage, credential-level permissions, chrooted home directories, SSH key authentication, audit logs, APIs, and webhooks.

That turns SFTP from a protocol endpoint into a more complete EDI file exchange system. The protocol moves files securely. The managed service adds storage, access control, audit history, and automation hooks around the workflow.

FTPS for EDI

FTPS is FTP secured with TLS. It keeps the familiar FTP model, but adds encryption so usernames, passwords, and file contents are not sent in clear text.

FTPS is useful when a partner or internal system already depends on FTP-style behavior, but the workflow needs TLS-secured transport. Its value is flexibility: it lets teams support FTP-compatible partner workflows without falling back to plain FTP, while still keeping SFTP as the simpler option for many new file-based EDI setups.

The main advantage is compatibility. FTPS can let older FTP-based processes continue with encrypted transport instead of forcing every partner and internal system to change at once.

FTPS is worth considering when:

• A partner already supports FTP-style workflows
• Existing tools expect FTP behavior
• Plain FTP is too risky
• The network path is controlled and understood
• The organization needs encrypted transport without redesigning the whole exchange

The downside is still the FTP architecture underneath. FTP and FTPS use a control connection and separate data connections. In passive mode, that usually means opening and managing a range of ports.

That can complicate firewall rules, NAT handling, partner access, and support. FTPS can work well, but the network setup needs to be handled carefully.

A managed setup changes that calculation. With SFTP To Go, FTPS can sit alongside SFTP and S3 access, so teams can support partners that need FTP compatibility while keeping transfer, storage, access control, and audit logging under the same managed model.

For new workflows, SFTP is usually simpler. For partners that need FTP compatibility, FTPS can still be the practical bridge. The important correction is simple: plain FTP should not be the target for sensitive EDI exchange.

AS4 for EDI

AS4 is a B2B messaging profile based on ebMS 3.0. It brings AS2-style ideas into a web services-based model, with support for receipts, message pulling, signing, encryption, and structured partner messaging.

AS4 tends to appear where the ecosystem expects it. That may include public-sector exchange, eDelivery-style networks, formal B2B messaging frameworks, or partner environments that have already standardized on AS4.

The strength of AS4 is richer messaging control. It is not just a basic file drop. It supports more formal message exchange patterns, including the option for message pulling, which can be useful in some partner-network designs.

AS4 can support:

• Secure business document exchange
• Signed and encrypted messages
• Receipt mechanisms
• Message pulling
• More structured B2B messaging flows
• Formal partner-network requirements

The tradeoff is complexity. AS4 is not usually the first choice for a team that only needs to move a few recurring EDI files between systems. It makes sense when a partner, network, regulator, or architecture already points in that direction.

For everyday file-based EDI, AS4 may be more formal than needed. If partners simply need to send and collect EDI files securely, SFTP or FTPS will usually be easier to deploy, explain, and operate.

Use AS4 when the network calls for AS4. Don’t choose it just to move files if SFTP or FTPS already meets the business requirement.

AS3 for EDI

AS3, or Applicability Statement 3, is an EDIINT protocol for secure business data exchange over FTP. It applies MIME packaging and S/MIME security to structured business data, including EDI files.

AS3 can make sense when an organization already has FTP-based infrastructure and wants an EDIINT-style security model. It can support signed and encrypted payloads, and it may fit partner workflows where AS3 has already been adopted.

The challenge is adoption. AS3 never became as common as AS2, and it now competes with simpler file transfer options such as SFTP and FTPS.

AS3 may fit when:

• A trading partner specifically requires AS3
• Existing FTP-based EDIINT infrastructure is already in place
• The organization wants FTP transport with S/MIME packaging
• There is a legacy reason to keep the current model

The drawback is inherited operational complexity. AS3 still depends on FTP transport, which means the same general network and firewall issues can appear. Lower adoption also means fewer partners are likely to ask for it.

If the actual requirement is secure file exchange rather than AS3 specifically, SFTP or FTPS will usually be easier to support. FTPS can preserve compatibility with FTP-style tooling. SFTP avoids much of FTP’s port complexity.

That makes AS3 a reasonable answer to a specific partner requirement, but not the first place most teams should look for modern file-based EDI.

FTP for EDI

FTP is one of the oldest file transfer protocols still found in business systems. It’s simple, widely supported, and still appears in legacy EDI workflows.

Its age and compatibility explain why it continues to appear. Many older business systems were built around FTP, and replacing those workflows can take time.

The security problem is direct. Plain FTP does not encrypt usernames, passwords, commands, or file contents. Anyone with access to the network path can potentially inspect traffic.

That makes FTP a poor fit for:

• Regulated data
• Confidential trading partner files
• Healthcare files
• Payment files
• Supplier records
• Financial transaction files
• Any EDI workflow where security or auditability is taken seriously

FTP also lacks native business receipts, signed acknowledgments, and EDI-specific delivery proof. It can move a file, but it does not prove much about the business exchange around that file.

That creates a gap because EDI files usually represent business commitments. Purchase orders, invoices, shipping notices, claims, and payment files can trigger fulfillment, payment, reporting, reconciliation, and compliance obligations.

FTP should usually be treated as a migration issue, not a target architecture. If a workflow still depends on FTP, the practical path is usually to move it to SFTP or FTPS first.

That preserves the file-based model while improving transport security. From there, teams can add proper access controls, cloud storage, audit logs, automation, and partner-level permissions around the workflow.

Keep the file exchange model if it still works, but you should replace the unsafe transport.

OFTP2 for EDI

OFTP2, or Odette File Transfer Protocol 2, is strongly associated with automotive supply chains. It is used for automated partner exchange of EDI files and larger business files such as engineering, logistics, and manufacturing data.

This is where OFTP2 has a clear identity. It was built for a world where large manufacturers and suppliers need reliable, secure partner exchange across a complex supply chain.

OFTP2 supports secure file transfer over the internet and is designed for high-volume partner exchange. Depending on implementation, it can support encryption, compression, signed receipts, restart capabilities, and certificate-based trust.

OFTP2 is ideal when:

• Automotive trading partners expect it
• Odette-aligned tooling is already in place
• Large partner files need secure exchange
• Signed receipts are part of the process
• The supply chain already operates around OFTP2

The drawback is adoption outside that ecosystem. If your partners are not already using OFTP2, choosing it may add software, certificate, onboarding, and support work without much practical benefit.

For general EDI file exchange, AS2, SFTP, FTPS, AS4, or a VAN will usually be more familiar to a broader set of trading partners.

Use OFTP2 when the automotive network expects it. Don’t choose it just because you need secure file transfer. If the workflow is ordinary file-based EDI and the partner accepts SFTP or FTPS, those options will usually be easier to onboard, automate, and support.

VANs for EDI

An EDI VAN, or value-added network, is a managed intermediary that helps companies exchange EDI documents across a wider business network.

Instead of building direct connections with every supplier, distributor, manufacturer, retailer, logistics provider, carrier, customer, or healthcare partner, the VAN handles routing, mailboxing, connectivity, and sometimes translation, monitoring, and onboarding.

VANs are still used because EDI is often a partner-management problem, not only a protocol problem. A company with many trading partners may not want to manage every connection, every protocol preference, and every routing rule directly.

A VAN may be a good fit when:

• You have many trading partners
• Partners use different protocols
• Routing and mailboxing need to be outsourced
• Translation is part of the requirement
• Partner onboarding takes too much internal time
• The business prefers a managed EDI network

The tradeoff is cost and dependency. VANs can be more expensive than direct protocol-based exchange, and the provider becomes part of the operational chain.

That is not automatically bad. For some businesses, outsourcing partner connectivity is exactly the sensible choice. The point is to know what you are paying for: less direct protocol management, but more reliance on the VAN provider.

If you have a smaller partner network, or if your partners can use SFTP or FTPS directly, a VAN may be more machinery than you need.

A managed SFTP/FTPS setup can give you controlled file exchange, partner folder separation, audit logs, cloud-backed storage, and automation without handing the whole partner network to an intermediary.

S3-backed file exchange for EDI workflows

S3 is not the EDI protocol. It is the storage layer that supports file-based EDI after transfer, especially when files need to be processed, retained, integrated, or reviewed.

That still gives it a useful role in file-based EDI architecture. It makes it part of the architecture rather than the transport protocol. In modern file-based EDI, storage is often where the wider workflow starts to take shape.

A partner may upload a file through SFTP or FTPS. That file may then land in S3-backed storage, trigger processing, move into an archive, feed a reporting workflow, or wait for another system to collect it.

That pattern is useful because EDI does not stop at delivery. Files often need to be:

• Stored
• Processed
• Retained
• Copied
• Archived
• Reviewed
• Replayed
• Used by downstream systems

This is why S3-backed storage belongs in the EDI conversation, even though S3 itself is not the EDI communication protocol. AS2, SFTP, FTPS, AS4, and OFTP2 describe how files are exchanged. S3 describes where files can live after they arrive and how other systems may access them.

S3 does not provide EDI-specific MDNs, partner receipts, or non-repudiation by itself. It also does not make a workflow compliant by default. Access policies, encryption, identity controls, logging, lifecycle rules, region selection, retention settings, and Object Lock all need to match the data and workflow.

This is where an SFTP-to-S3 pattern becomes useful. Partners can keep using familiar transfer methods like SFTP or FTPS, while files land in cloud-backed storage for processing, retention, or integration.

With SFTP To Go, S3 cloud storage is built in. Audit logs, APIs, webhooks, credentials, and folder permissions support the workflow around it.

Which EDI protocol should you choose?

Start with your trading partner. If they require AS2, AS4, OFTP2, or a VAN, that usually decides the first part of the answer. EDI is for partner exchange, so the protocol has to work for both sides.

After that, look at the workflow. Are you exchanging purchase orders, invoices, payment files, claims, shipping notices, inventory updates, or large partner files? Do you need formal receipt confirmation, or do you need reliable file exchange that’s easy to automate and support?

• Use AS2: when a trading partner requires signed MDNs, message receipts, and non-repudiation. It’s common in retail, consumer goods, healthcare, logistics, and other EDI networks where both sides need formal proof that a message was received.
• Use SFTP: when you need secure, scheduled file exchange for orders, invoices, claims, reports, exports, and partner uploads. It’s often the better option for file-based EDI because it’s easier to automate, easier to explain, and usually simpler to run than AS2.
• Use FTPS: when a partner still works with FTP-style tools, but plain FTP isn’t not secure enough. It gives older workflows encrypted transport, though firewall and passive port configuration still need proper handling.
• Use AS4: when your partner network, regulator, or public-sector framework expects web services-based B2B messaging. It’s useful for formal messaging patterns, but it’s usually more than you need for ordinary file-based EDI.
• Use OFTP2: when you’re working inside automotive supply chains where Odette tooling and OFTP2 are already expected. Outside that ecosystem, it can add avoidable setup and support work.
• Use a VAN: when the hard part is partner connectivity, not the protocol itself. If you need routing, mailboxing, translation, onboarding, and support across a large trading network, a VAN may make sense.
• Use S3-backed storage: as part of the workflow when files need to land in durable cloud storage, trigger processing, support retention, or feed downstream systems. S3 is not the EDI protocol. It’s the storage layer behind the exchange.

For many file-based EDI workflows, the decision comes down to AS2, SFTP, or FTPS:

• AS2 is the better choice when formal partner receipts are required.
• SFTP fits business and regulated workflows that prioritize secure file exchange, automation, partner folder separation, and lower maintenance are the main goals.
• FTPS is useful when you need flexibility for FTP-compatible partner workflows. FTPS adds TLS-secured transport while preserving FTP-style behavior, though firewall, NAT, and passive port setup still need proper handling.

How SFTP To Go supports file-based EDI workflows

File-based EDI doesn’t stop when a transfer finishes. The file still needs to land somewhere controlled, stay separated by partner or workflow, trigger the next step, and leave a record that can be reviewed later.

SFTP To Go supports that pattern with managed SFTP, FTPS, S3 access, and cloud-backed storage. Instead of maintaining your own transfer server, secure cloud storage, folder structure, user separation, firewall rules, and automation around file movement, you can give partners and systems controlled access to the folders they need.

For EDI workflows, SFTP To Go brings you:

• Secure SFTP and FTPS file exchange
• S3 access for cloud-centered file workflows
• HTTPS web portal access for browser-based file handling
• SSH public key authentication for SFTP users
• MFA for web portal access
• Credential-level permissions
• Chrooted home directories for partner and workflow separation
• Inbound network rules on eligible plans
• Static host endpoints for allowlisting
• Encryption in transit and encryption at rest
• Audit logs for login and file activity
• Webhooks for upload, download, and delete events
• API for automation and integration

Start a free trial or schedule a call to see how SFTP To Go can support secure, automated EDI file exchange.

Frequently asked questions