Use whichever one your trading partner specifies. When you genuinely get to choose, the deciding question is whether you need a signed receipt for every document. AS2 gives you one, produced by the partner’s own software. SFTP gives you a folder, and any acknowledgement comes back later as another file.
The short answer
- The partner or retailer mandates one. Use it. Their onboarding, testing and support are built around the protocol they named.
- You need proof of receipt per message. AS2. A signed receipt carrying a digest of what the partner received is the strongest delivery evidence either protocol offers. Over SFTP, acknowledgement happens only at the EDI layer.
- Volume and existing infrastructure. If either side already runs an SFTP server and an EDI acknowledgement is enough, SFTP is an account and a folder. AS2 is identifiers, URLs, certificates and a receipt mode per partner, which adds up across dozens of them.
- Who runs the server. SFTP needs one side to run a server. AS2 needs an endpoint wherever messages are received, and at the sender too for asynchronous receipts, plus certificates kept current on both sides.
How AS2 works
AS2 is RFC 4130, published in 2005. Each document is one HTTP or HTTPS POST to the partner’s AS2 URL, with an S/MIME body signed with your private key and encrypted with the partner’s certificate. AS2-From and AS2-To headers carry the identifiers the two sides agreed, which tell the receiver which partnership applies. Certificates are X.509 and may be self-signed; the RFC does not require a certificate authority.
The receipt is the MDN, the message disposition notification. The receiver verifies the message, computes a digest of what it received - the MIC, or message integrity check - and returns it in an MDN, signed if the sender asked for a signed receipt. It travels one of three ways:
- Synchronous - in the HTTP response to the same POST.
- Asynchronous - later, as a separate request to a return URL the sender named in a
Receipt-Delivery-Optionheader. - None - the RFC allows a transmission with or without a request for a receipt.
Non-repudiation of receipt, in the RFC’s terms, happens only when the sender has verified the signed receipt and confirmed that the returned MIC matches the value it recorded for the original message. Signing, encryption and receipts are each optional in the RFC, so the partnership settings decide how much of this you actually get.
How SFTP works
SFTP, the SSH File Transfer Protocol, never became an RFC. The version OpenSSH implements, version 3, is described in draft-ietf-secsh-filexfer-02, an Internet-Draft from 2001. It runs inside an SSH connection, which supplies encryption, integrity and server authentication (RFC 4253): the server proves itself with its host key, and the client should check that key against one it already trusts.
The model is a remote filesystem. One side runs the server; the other logs in with a password or an SSH key and pushes files into a folder or pulls them out. Each request gets exactly one status reply, and SSH_FX_OK on a write or a close means the server finished that operation - nothing more. There is no receipt, and no way for the server to tell the sender that anything downstream picked the file up.
So acknowledgement moves up to the EDI layer: an X12 997 Functional Acknowledgment or 999 Implementation Acknowledgment, or an EDIFACT CONTRL syntax and service report, which over SFTP arrives as one more file in a folder you poll. Know what those prove. X12’s descriptions of the 997 and 999 call them reports of syntactical analysis and say the standard “does not cover the semantic meaning” of the documents, and RFI 2099 confirms a 999 does not indicate business acceptance - for an order, that answer is the 855 Purchase Order Acknowledgment. The same layering holds over AS2: the MDN says the message arrived intact, the 997 says the EDI parsed, and neither says the order was accepted.
AS2 vs SFTP side by side
| AS2 | SFTP | |
|---|---|---|
| Standard | RFC 4130 (2005) | Version 3 is an Internet-Draft (filexfer-02, 2001); never an RFC |
| Transport | One HTTP or HTTPS POST per message | A file session inside an SSH connection, port 22 by default |
| Security | S/MIME signature and encryption on the message itself, using each partner’s X.509 certificate; each is optional per partnership | SSH encrypts and integrity-protects the connection; server host key; client logs in with a password or key. The file itself is not signed |
| Receipts | MDN - synchronous, asynchronous or none. A verified signed MDN with a matching MIC is non-repudiation of receipt | None. A status reply per operation; acknowledgement comes from EDI (997/999, CONTRL) |
| Who connects to whom | The receiver runs an AS2 endpoint the sender POSTs to; async receipts need the sender to be reachable too | One side runs the server; the other logs in and pushes or pulls |
| File names | Optional header; some senders put an id there, or nothing | The path and name are the protocol |
| Retries and duplicates | Resend under the same Message-ID; the receiver deduplicates on it | Nothing in the protocol; deduplicate on EDI control numbers |
| Typical users | Trading partners whose EDI guide specifies AS2 | Bank statement and payment files, student roster feeds, ERP exports, partners who already run a server |
| Setup effort | Per partner: AS2 IDs, URLs, certificates both ways, receipt mode and algorithms, then a test in each direction | A host, an account and a folder; verify the host key, perhaps an IP allowlist |
AS2 in production: what goes wrong
Certificates expire, and nothing warns you
A certificate is the whole trust basis of an AS2 partnership, and a lapsed one can break it without notice: the first symptom is failed deliveries. Track the expiry of every certificate, yours and each partner’s, and treat a rotation as a two-sided change - the partner has to load your new certificate before you sign with it.
The partner’s website certificate is not their AS2 certificate
Asked for the partner’s certificate, someone opens their AS2 URL in a browser and exports the certificate behind the padlock. That is the host’s HTTPS certificate - valid X.509, so nothing rejects it - but the partner’s AS2 software does not hold its key and cannot decrypt what you send. In the case we debugged, the partner answered HTTP 500 with no MDN, and the cause only surfaced when we inspected the certificate. The tell: DNS host names plus the TLS server-authentication usage, or host names plus a CA-issued validity of a year or less. Ask the partner’s EDI team for their AS2 certificate. And when a partner answers 500, read the response body first: a gateway’s reason for refusing a message is typically there and nowhere else.
Asynchronous receipts need a reachable return URL
An asynchronous MDN is a separate request from the partner to the URL in your Receipt-Delivery-Option header, so that URL must be reachable from their network, through your firewall and their outbound rules. When it is not, the failure is lopsided: the partner has the file and thinks it sent a receipt, while you have a message stuck at “awaiting” that must count as unconfirmed, not delivered. Asynchronous does not mean slow, either. In our interop testing against an independent open-source AS2 server, a meaningful share of receipts arrived before our own POST had returned, so a sender must record what it is waiting for before it sends, or it throws away valid receipts. We learned that one the hard way.
Duplicates: the Message-ID is the identity
A sender that loses the response retries. RFC 4130 says the resend carries the same Message-ID, that an id may be reused only when the content, including the original Date, is identical, and that receivers should expect repeats and send their original reply again. The Message-ID is therefore the receiver’s deduplication key, and a sender that rolls a fresh id for each retry - as one implementation did in our interop testing - can get the document processed twice. Do not patch that with content hashing: an identical EDI file sent twice can be a deliberate re-issue. The RFC recommends detecting duplicates by Message-ID or by business transaction identifiers - in EDI, the interchange control numbers - which is where your translator’s duplicate check belongs.
SFTP in production: what goes wrong
The poller can collect half a file
Neither SFTP nor FTP gives a client listing a folder a standard “finished” state, so a poller can collect a file mid-upload while every log reports success. The fixes - a temporary name and a rename on the writing side, a filename pattern and a minimum age on the reading side - are in Truncated files on SFTP and FTP.
No receipt means you poll - and watch for absence
Without an MDN, your evidence is the status reply on close, perhaps a re-list of the file on the server, then the 997 or 999 if it arrives. Something on your side has to match each acknowledgement to its interchange and notice the ones that never come, because a missing 997 raises no error anywhere. What that record needs is in File transfer audit trails.
A login that works is not a folder you can write to
Listing a folder and creating a file in it are different rights, and some servers report a missing write permission as “no such file”, so test with a real upload and delete. Verify the host key too: RFC 4253 notes that skipping the check leaves the connection insecure against active attacks. When a partner migrates servers and the key changes, a connection that stops until you confirm the new key is the check working.
How DocEvent handles both
DocEvent Channels route files between endpoints, and AS2 and SFTP are endpoints like any other, so you can receive over one and deliver over the other. As of October 2026:
- AS2 in both directions. A hosted AS2 receive endpoint has its own URL and is pinned to one partner; messages are decrypted and verified before they enter the channel. Send endpoints sign (SHA-256, SHA-384 or SHA-512) and encrypt (AES-256, AES-192, AES-128, or 3DES for older partner software). All three MDN modes - synchronous, asynchronous and none - work in both directions.
- Receipts that are checked. Signed receipts are verified, MIC included, and a message whose receipt never arrives parks in Stuck files instead of counting as delivered. Every resend of a file reuses its Message-ID, and inbound duplicates are detected by Message-ID.
- Certificates in one registry. Identities and partners live under Channels → Partners, with an expiry warning at 30 days and a critical alert inside 7, and a certificate that looks like a website certificate is flagged as you paste it. A refused POST reads plainly on the delivery lane, for example “partner answered HTTP 500”. Outbound messages, and the asynchronous receipts DocEvent posts back, come from published static IPs for partners who firewall their AS2 server.
- SFTP three ways. A hosted SFTP and FTPS upload server with per-sender password or SSH-key logins, where every completed upload enters the channel and an SFTP upload cut off mid-way is not routed. SFTP pull, with host-key verification, a filename pattern, a minimum age and a stable-size check. And SFTP push, with host-key verification and a Test connection that writes, lists and deletes a probe file, so a missing write permission shows up before the first delivery does.
- Bridges between them. AS2 to SFTP delivers partner EDI into an SFTP intake folder; SFTP upload to AS2 and SFTP pull to AS2 let a system that only speaks SFTP reach an AS2-only partner. AS2 file names are optional, so read how they are handled before an SFTP folder depends on them.
The honest limits. DocEvent moves EDI files; it does not parse them, generate 997s or match acknowledgements to interchanges - that stays with your translator. Outbound SFTP connections, pull and push, log in with a password today, not an SSH key, so a partner’s key-only server is not a fit for that leg yet. And nothing emails you when a delivery fails: the routing log and Stuck files are in the console, and checking them is on you. AS2 in Channels is free while in preview, then per user, with operations included in each plan.
References
- RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2), July 2005: optional signing, encryption and receipts (2.4.2), the definition of non-repudiation of receipt (2.3.2), Message-ID reuse on resend (5.5), AS2-From and AS2-To (6.2), synchronous and asynchronous MDNs (7.2, 7.3), certificates (8), duplicate detection (9.3).
- draft-ietf-secsh-filexfer-02 - SSH File Transfer Protocol, version 3, October 2001; the version OpenSSH implements, per its PROTOCOL file.
- RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol: encryption, integrity and server host-key authentication (section 8).
- X12 transaction sets - the 997 Functional Acknowledgment and 999 Implementation Acknowledgment report syntactical analysis, not semantic meaning; and X12 RFI 2099 - a 999 does not indicate business acceptance.
- UN/EDIFACT CONTRL - the syntax and service report message, ISO/TC 154 and UNECE Joint Working Group 1.