An AS2 integration connects internal business applications to trading partners that exchange documents through the AS2 protocol. The integration has two distinct responsibilities: the ERP or EDI layer creates and consumes business documents, while the AS2 layer packages, secures, sends and acknowledges them.
Keeping that boundary clear produces a more reliable architecture. An ERP should not need partner-specific certificate logic, and an AS2 gateway should not decide whether an invoice satisfies a customer’s business rules. The integration between them must preserve identity, state and evidence across both layers.
A reference AS2 integration architecture
A typical outbound flow is:
- ERP creates an order, invoice, ASN or other business event.
- An EDI translator or mapping service converts it to the partner’s required format.
- The integration layer submits the resulting payload and partner identifier to the AS2 service.
- AS2 applies the correct ID, endpoint, certificates, algorithms and MDN policy.
- The partner returns an MDN.
- A later EDI acknowledgment or application response reports business processing.
- Status and exceptions return to the integration layer and, where useful, the ERP.
Inbound processing reverses the path: AS2 validates and decrypts the package, the translator checks the EDI syntax and maps it, and the ERP applies business validation.
The architecture should retain one correlation chain from the ERP document number to the AS2 Message-ID, MDN and business acknowledgment.
Four integration patterns
REST API
The ERP, iPaaS or middleware uploads an outbound payload to an API with a partner or connection ID. It later retrieves status through the API or receives events through a webhook.
An API is a strong fit for near-real-time workflows, structured error handling and teams that already operate application integrations. It should be idempotent: retrying a request after a timeout must not create an unintended duplicate business transmission.
Webhooks
The AS2 service posts events such as message received, MDN verified or delivery failed to your integration endpoint. Webhooks reduce polling latency, but the receiver must authenticate events, return quickly and process them idempotently. Queue the event before doing slow ERP work so a temporary downstream outage does not cause lost notifications.
Watched folders or shared storage
The ERP or translator writes outbound files into a controlled folder and reads inbound files from another. This is simple and works with legacy applications, but naming, atomic writes, permissions, retention and duplicate detection must be designed carefully.
Write to a temporary name and rename only after the file is complete. Archive processed files outside the active pickup folder and pair each payload with machine-readable status metadata.
Internal SFTP
An organization may use SFTP between its internal systems and a gateway, while the gateway uses AS2 with external partners. This is a valid hybrid design. SFTP is the internal handoff; AS2 remains the partner-facing protocol and generates the MDN.
Choose the system of record for each state
Do not collapse the whole lifecycle into sent or failed. A useful state model includes:
| State | Owning layer | Meaning |
|---|---|---|
| Created | ERP | Business document exists |
| Translated | EDI/integration | Partner-format payload was produced |
| Submitted | Integration | Payload was accepted by AS2 service |
| Transmitted | AS2 | HTTP exchange was attempted |
| MDN verified | AS2 | Protocol receipt matched and validated |
| EDI accepted/rejected | EDI layer | 997, 999, CONTRL or equivalent was processed |
| Applied | ERP | Business transaction completed |
The AS2 service should be authoritative for transport evidence. The ERP should be authoritative for business posting. The integration layer correlates them and presents a consolidated operational view.
Map partners, not endpoints, in the ERP
Avoid embedding endpoint URLs, AS2 IDs or certificate aliases in ERP code. Give the ERP a stable connection key such as retailer-eu-prod. The AS2 platform maps that key to the current partner profile.
This indirection lets operations rotate a certificate or change an endpoint without deploying ERP code. It also reduces the risk that a test document is sent to production because a URL was hard-coded in a job.
Design the outbound interface
An outbound submission should include:
- stable partner or connection ID;
- payload or secure object reference;
- business document type;
- business correlation ID;
- filename and content type where required;
- idempotency key;
- optional priority or routing metadata.
The response should return an immutable submission ID. Store it beside the ERP document record, then map it to the AS2 Message-ID when transmission begins.
Never make the ERP wait synchronously for a complete partner workflow. It may take seconds to receive an MDN and hours to receive a business acknowledgment. Submit the work, persist the identifier and update status asynchronously.
Design the inbound interface
For inbound documents, validate AS2 security before exposing a payload to downstream systems. Then quarantine or reject files that fail content validation rather than placing them in the normal ERP queue.
Include verified partner identity, AS2 Message-ID, received timestamp, payload checksum, document type and validation status in the downstream handoff. Do not infer the trading partner only from the filename.
If the same Message-ID or business control number arrives again, apply the agreed duplicate policy. Technical retries must not create duplicate invoices or shipments.
MDNs and business acknowledgments
An MDN confirms an AS2 disposition. It can prove that the packaged message reached the partner’s AS2 system intact, especially when the MDN is signed and the MIC matches. It does not prove that the partner’s translator accepted the EDI syntax or that its ERP posted the transaction.
Model the later 997, 999, CONTRL or application acknowledgment separately. Link both events to the original business document so support can answer three different questions:
- Did we transmit the message?
- Did the partner’s AS2 system receive it?
- Did the partner accept and process the business document?
The MDN versus EDI acknowledgment guide defines these layers in detail.
Retry and idempotency design
Retries are necessary, but an uncontrolled retry can duplicate a business transaction. Use an idempotency key at the API boundary and retain the original Message-ID when the protocol’s retry semantics require it. Do not generate a new business document simply because the transport response was uncertain.
Classify errors before retrying:
- transient network timeout: retry with controlled backoff;
- HTTP or service throttling: follow the stated retry policy;
- unknown AS2 ID: configuration issue, do not retry indefinitely;
- certificate or decryption failure: stop and correct the security profile;
- negative MDN: inspect the disposition and partner evidence;
- EDI rejection: route to business or mapping resolution, not transport retry.
Security boundary
Keep AS2 private keys in the AS2 service or a suitable key-management boundary. The ERP normally does not need access. Restrict integration credentials to specific operations and partner profiles, rotate them independently of AS2 certificates and audit administrative changes.
For webhooks, verify a signature or strong authentication, reject stale events and protect against replay. For folders and SFTP, use least privilege and prevent users from modifying archived evidence.
Monitoring and reconciliation
Monitor both individual messages and aggregate behavior. Useful controls include:
- missing MDN threshold by partner;
- negative disposition and signature failures;
- queue age and oldest unprocessed message;
- EDI acknowledgments overdue by document type;
- mismatch between ERP submissions and AS2 records;
- webhook delivery failures;
- repeated duplicates or manual reprocessing;
- certificates approaching expiry.
Run a scheduled reconciliation that compares ERP business records, integration submissions and AS2 outcomes. Event-driven updates are fast; reconciliation catches events lost during outages or deployment mistakes.
Implementation sequence
- Define partner and document scope.
- Choose API, webhook, folder or SFTP boundaries.
- Define canonical identifiers and state ownership.
- Implement outbound idempotency and inbound duplicate controls.
- Map AS2 transport events and business acknowledgments separately.
- Test valid, invalid, duplicate and delayed scenarios.
- Add dashboards, alerts and reconciliation before production.
- Document replay, rollback and manual recovery procedures.
Use the AS2 setup tutorial for the partner profile and the EDI automation guide for operational workflow design.
Build or use a managed AS2 layer?
Operating AS2 internally gives direct control but makes your team responsible for endpoint availability, protocol updates, private keys, certificates, message retention, monitoring and partner support. A managed gateway keeps the internal integration interface stable while outsourcing those partner-specific transport duties.
AS2Connection provides a cloud AS2 gateway with REST API, webhooks and managed partner profiles, allowing the ERP integration to focus on business documents instead of protocol infrastructure.
Use the AS2 gateway selection guide to evaluate security, evidence, availability, certificate operations and internal interface requirements before choosing a platform.
