AS2 vs SFTP for Partner Exchange: When the Heavyweight Earns Its Keep
Sooner or later every trading relationship reaches the transport question. A new partner's onboarding form offers both options and asks you to pick. Or the finance director, reading the renewal quote for your AS2 software, asks the question admins dread precisely because it is fair: "The Hendersons just exchange files over SFTP with their partners. Why are we paying for all this?" You need an answer that is neither a sales pitch for the heavyweight nor a naive "simpler is always better."
This article is that answer. It compares AS2 and SFTP as partner-exchange transports the way a practitioner actually experiences them — what each guarantees, what each costs to operate, what different partner ecosystems expect — and ends with an honest decision line you can defend in front of both the security team and the finance director. It is part of our AS2 & B2B Exchange series; the mechanics behind each claim live in AS2 explained and our SFTP series.
The Two Contenders, One Paragraph Each
AS2 (Applicability Statement 2) is a business-to-business exchange specification built for documents that carry commercial weight — purchase orders, invoices, and the other EDI (Electronic Data Interchange) documents trading partners exchange. Every message is fingerprinted with a MIC (message integrity check — a cryptographic hash), signed with the sender's private key, encrypted with the receiver's public certificate, and pushed over HTTP or HTTPS (web transport, plain or wrapped in TLS — Transport Layer Security) to the partner's always-on receiving endpoint, which answers with an MDN (Message Disposition Notification) — a signed receipt proving exactly what arrived. Both companies run AS2-capable software, exchange certificates during onboarding, and hold each other's public certificates for the life of the relationship.
SFTP (the SSH File Transfer Protocol) is a general-purpose secure file transfer protocol: one side hosts a server, the other connects as an authenticated client over a single encrypted SSH connection and uploads or downloads files in agreed folders. In partner exchange it is used as a scheduled push-and-pull arrangement: your job drops the day's invoices in an outbound folder at the agreed times, their job collects them, and vice versa. There are no built-in signatures on files, no built-in receipts — just a well-encrypted pipe, accounts, folders, and schedules. (SFTP is unrelated to FTPS despite the similar name; if that distinction is fuzzy, our SFTP vs FTPS vs FTP series untangles it.)
What Operating Each One Feels Like
Before the feature lists, a texture check, because the daily experience is half the decision. The AS2 morning routine: open the station console and read the overnight exchange like a ledger — every outbound message paired with its receipt, anything un-receipted flagged for chase, any processed/error dispositions decoded, certificate expiry warnings reviewed. When it works, it is beautifully self-accounting; every exchange settles itself with evidence attached. When it breaks, the failure is cryptographic and bilateral — you are reading error dispositions, comparing certificate fingerprints, and getting a partner's admin on the phone, because half the moving parts live in someone else's building.
The SFTP morning routine: confirm the scheduled jobs fired, the outbound folders drained, the inbound folders received what the business expected, and the logs show the partner's pickups. When it breaks, the failure is ordinary — a job that did not run, a changed password, a full disk, a firewall change — and you can usually fix it alone, without waiting for anyone else's change window. The tradeoff in one line: AS2 gives you proof and takes coordination; SFTP gives you autonomy and takes discipline, because nobody is generating evidence or chasing receipts unless you build that behavior yourself.
What AS2 Gives You That SFTP Doesn't
- A receipt the partner cannot disown. The signed MDN, quoting the MIC of exactly the bytes received, is the partner's own cryptographic attestation of delivery. In a dispute — "we never got that invoice," "the file was corrupt," "it arrived late" — you produce their signature, not your logs. This property, non-repudiation, is the single largest gap between the two protocols, and nothing bolted onto SFTP fully closes it. The dispute scenarios are walked through in MDNs and proof of delivery.
- Per-message sender authenticity. Every AS2 message carries the sender's digital signature. On SFTP, authenticity is an account login — strong evidence that someone with the credentials connected, but a shared secret is not a signature on each file.
- Payload encryption that outlives the connection. SFTP encrypts the pipe; the file lands in clear text on the server. AS2 encrypts the package itself, which stays sealed until the receiving station decrypts it — a meaningful difference when files rest on intermediate servers or wait in queues.
- Push with immediate settlement. An AS2 exchange is delivered and receipted in one motion, in seconds. Scheduled SFTP flows settle on the next pickup cycle, and "did they take the file yet?" is a question you answer by checking.
- A shared ecosystem convention. In AS2-standardized industries, every partner's onboarding form asks the same questions in the same vocabulary. Being AS2-capable means fitting a socket that hundreds of partners already present.
What SFTP Gives You That AS2 Doesn't
- Radical operational simplicity. One server, per-partner accounts, folders, and schedules — concepts every administrator already holds. AS2 requires capable software and a configured partner profile on both sides, and a station that is down cannot receive; there is no mailbox waiting.
- A lighter key lifecycle. SFTP authentication rests on the server's host key and per-account credentials or SSH keys — mostly one-sided to manage, and rotating a client key is a small, local event. AS2's bilateral certificate exchange demands the coordinated renewal choreography (and carries the expired-certificate outage risk) documented in certificate lifecycles.
- One-sided infrastructure. Only the hosting side needs an internet-facing endpoint and firewall openings; the connecting side just makes outbound connections. In AS2, any partner you receive from must be able to reach your endpoint — and asynchronous receipts require even the sender to be reachable.
- Ubiquitous tooling and skills. Every operating system, scripting language, and scheduler speaks SFTP; every admin you will ever hire has used it. AS2 expertise is a specialty.
- Lower software cost. SFTP servers and clients are commodity software; AS2 capability means dedicated B2B software or a hosted service, licensed and maintained.
SFTP's gaps can be narrowed — and in fair comparisons, should be. File-level encryption with OpenPGP (a widely supported standard for encrypting and signing individual files) gives SFTP-carried payloads the same encrypted-at-rest property as AS2 packages: the sender encrypts the file to the receiver's OpenPGP key before upload, and it stays sealed until the receiver decrypts it. Checksums exchanged alongside files approximate integrity verification, and disciplined server logs build a delivery narrative. What remains un-closable is the receipt: no combination of SFTP-side measures produces the partner's signed attestation of what they received.
Side by Side
The full comparison in one table — the honest version, including the rows where the heavyweight loses:
| Question | AS2 | SFTP |
|---|---|---|
| Encryption in transit | Yes — payload encryption, usually plus TLS | Yes — SSH channel |
| Payload sealed at rest | Yes, until the station decrypts | Only if you add OpenPGP |
| Proof of sender, per file | Digital signature on every message | Account login only (OpenPGP signing can help) |
| Proof of delivery | Signed MDN with MIC — non-repudiation | None standard — logs and conventions |
| Infrastructure required | Capable station both sides, reachable endpoints | One hosted server; clients connect outbound |
| Key/certificate lifecycle | Bilateral exchange + coordinated renewals | Mostly one-sided; lighter choreography |
| Software cost | Dedicated B2B software or hosted service | Commodity servers, clients, schedulers |
| Skills availability | Specialty knowledge | Universal admin skill |
| Ecosystem fit | The convention in retail-style EDI networks | The convention nearly everywhere else |
What Partners Expect, by Ecosystem
In practice, the decision is rarely made on technical merits in a vacuum — it is made by the ecosystem you trade in, because the larger party dictates and networks converge on conventions:
- Retail and consumer goods: AS2 is deeply entrenched. Large retailers standardized on it for supplier document flows, and their onboarding packets assume it. A supplier refusing AS2 here is refusing the customer.
- Logistics and transportation: genuinely mixed — AS2 with the retail-adjacent giants, SFTP with carriers and brokers, and VANs (value-added networks: third-party mailbox services that store and forward documents between partners for a fee) bridging the long tail.
- Healthcare: both appear, driven by strict privacy obligations; clearinghouses and payers publish their supported transports and you comply.
- Finance and payroll: scheduled SFTP with file-level encryption is the entrenched convention for batch files; AS2 is rare.
- Small and mid-size partnerships generally: SFTP dominates, simply because both sides can stand it up in an afternoon with staff they already have.
The practical reading: your protocol portfolio is mostly chosen for you by who you trade with. The real decision points are the relationships where you are the larger party, or where a peer genuinely offers both — and those are exactly the cases the decision line below is for.
Finding out what a specific partner expects takes one email to their onboarding team: "Which transports do you support for document exchange, and which do you prefer?" Most sizable companies answer with a menu, and the menu tells you more than the marketing — a partner whose form leads with AS2 and treats SFTP as the exception has a receipt-driven compliance culture, and you should expect deadlines and chargebacks to come with it. A partner who says "whatever works, we usually just do SFTP" is telling you the relationship will run on logs and goodwill, and that the heavyweight would be wasted on it.
The Operating Cost of Each, Honestly
Purchase price is the visible cost; the operating tax is the real one. AS2's ongoing costs: software licensing or hosted-service fees, the certificate register and renewal choreography across every partnership, receipt monitoring (an un-receipted message is an incident), a reachable hardened endpoint, and the scarcity premium on AS2-literate staff — when the one person who understands the station leaves, the estate becomes fragile. None of this is an argument against AS2; it is the keep the heavyweight has to earn.
SFTP's costs are lower but not zero, and pretending otherwise sets the comparison up dishonestly. A partner-facing SFTP estate needs per-partner accounts with least-privilege folders, host-key and client-key hygiene, schedules that actually fire, retry and alerting behavior, and — because there are no MDNs — deliberately built delivery evidence: activity logs retained, checksums exchanged, naming conventions enforced. The pieces are commodity, which is the point: a Windows server such as Sysax Multi Server hosts the partner-facing SFTP and FTPS endpoints with per-partner accounts and activity logging, and a scheduler like Sysax FTP Automation runs the exchange legs — folder monitoring, timed pushes and pulls, retries, and OpenPGP encryption of payloads before they leave your network for partners who require sealed files at rest. (To be plain about scope: these are SFTP/FTPS-side tools, not AS2 software — the AS2 station itself is a separate, dedicated purchase.)
Remember: the expensive mismatch is running the wrong weight class, in either direction. AS2 maintained for a handful of low-stakes partners is pure overhead; SFTP stretched with homemade receipt conventions across a dispute-prone, chargeback-enforcing ecosystem is a liability. Fit the transport to the relationship, not to habit.
The Honest Decision Line
One framing note before the rules: this is a business-risk decision that IT informs, not an IT decision that the business rubber-stamps. Your job is to price each option honestly — what it guarantees, what it costs to run, what the partner ecosystem expects — and let the people who own the commercial risk choose the weight class. With that said, here is the line, drawn as plainly as we can draw it:
- If a significant partner mandates AS2, the decision is made. Comply. The relationship is worth more than the transport argument, and their onboarding machine will make AS2 the path of least resistance anyway.
- Choose AS2 when disputes are expensive and receipts must be evidence. High document values, chargeback-enforcing partners, regulated flows, or any relationship where "prove we delivered it" will someday be asked in a formal setting — the signed MDN is the feature you are buying, and it is worth the operating tax.
- Choose SFTP when the relationship runs on workable trust and modest stakes. Two mid-size companies exchanging batch files, with sensible logs, checksums, OpenPGP where confidentiality at rest matters, and a written convention for resends — that is a right-sized, defensible setup, not a corner cut.
- If you need AS2 but cannot staff it, buy it as a service. Hosted AS2 providers run the station and hand you files over — frequently — SFTP. You inherit the receipts without the station operations; you pay for it and add a third party to every exchange.
- Revisit when stakes change. A partnership that starts as friendly SFTP can grow into volumes and values that justify AS2. The trigger is business weight, not technology fashion.
For the runbook, the same line compressed to a card you can paste into a decision ticket:
TRANSPORT DECISION CARD - AS2 or SFTP for this partner? 1. Does any significant partner in this flow mandate AS2? -> AS2 2. Would a delivery dispute here be expensive (chargebacks, regulation, high document value)? -> AS2 3. Are stakes modest and is log-based trust workable? -> SFTP (+ OpenPGP if files must stay sealed at rest) 4. Need receipts but can't staff a station? -> hosted AS2 5. Record the choice + reasoning in the partner runbook, and revisit when volumes or stakes change.
And a corollary worth saying aloud: running both is not indecision — it is the normal end state. Most estates settle into AS2 with the ecosystem that demands it and SFTP with everyone else, managed under one discipline: one partner register, one onboarding checklist, one runbook format. That uniformity, not protocol purity, is what makes a mixed estate operable — it is the whole argument of the onboarding checklist article.
Answering the Finance Director
So, back to the question that started this: "Why are we paying for all this?" The defensible answer has three sentences. "Our retail partners require AS2, so for them it is a cost of doing business. For those partners, the receipts have also saved us in disputes — here are two examples from the archive. Everyone else runs on SFTP, which is why the AS2 estate is only as big as it has to be." If you cannot fill in the middle sentence — if no partner mandates it and no dispute has ever needed the receipts — then the finance director may be right, and shrinking the heavyweight's footprint is the honest recommendation. For the mechanics you would keep either way, see how receipts prove delivery and what certificate upkeep really involves.
Frequently Asked Questions
Can we send EDI documents over SFTP?
Is SFTP less secure than AS2?
Does adding OpenPGP to SFTP make it equivalent to AS2?
A big partner demands AS2 and we have no AS2 capability. What are our options?
Where does FTPS fit in this decision?
Can a relationship switch transports later without starting over?
From the Sysax team: we build secure file transfer software for Windows — Sysax Multi Server, an FTP, FTPS, SFTP, and HTTPS server, and Sysax FTP Automation for scheduled, scripted transfers. Free trials are on the download page.
