B2B Integration with Salesforce: EDI, AS2, and Enterprise Patterns

B2B Integration Is Not Regular Integration

Internal system integration — connecting Salesforce to your ERP, your data warehouse, your marketing automation platform — happens within a controlled environment where all parties can negotiate protocols, modify schemas, and align on timelines. B2B integration is fundamentally different: your trading partners dictate the protocol, the message format, and often the timeline. You adapt to them, not the other way around.

In manufacturing, retail, and distribution, B2B integration typically means EDI (Electronic Data Interchange) — a set of data standards for business documents (purchase orders, invoices, shipment notices, inventory feeds) that has been in use since the 1970s. EDI is not modern, it is not elegant, and it is not going away. Major retailers (Walmart, Target, Amazon Vendor Central) and manufacturers require EDI compliance as a condition of doing business. Salesforce implementations at companies in these sectors must either interface with EDI infrastructure or operate entirely outside the commercial transaction flow — which is rarely acceptable.

The architectural implication is that Salesforce typically does not speak EDI natively. There is a translation layer — either a specialist B2B integration platform, a middleware solution, or a VAN (Value-Added Network) — that converts between EDI format and the REST/SOAP APIs Salesforce understands. Designing this architecture correctly determines whether Salesforce becomes the system of record for commercial transactions or a downstream consumer of data from a legacy EDI system.

EDI Standards: X12, EDIFACT, and Salesforce Data Mapping

The two dominant EDI standards are ANSI X12 (used primarily in North America) and UN/EDIFACT (used primarily in Europe and internationally). Each standard defines transaction sets — numbered message types for specific business documents. In X12: 850 is a Purchase Order, 855 is a Purchase Order Acknowledgment, 856 is an Advance Ship Notice (ASN), 810 is an Invoice, 820 is a Payment Order/Remittance Advice. Each transaction set has a defined segment structure with required, optional, and conditional elements.

Mapping EDI transaction sets to Salesforce objects is the core translation challenge. An X12 850 Purchase Order maps to a Salesforce Order with Order Products — but the mapping is never clean. EDI fields like the Buyer's Party Identifier, the allowances and charges segments, the carrier routing instructions, and the packaging details have no direct equivalents in standard Salesforce objects. The mapping requires custom fields on Order and OrderItem, plus potentially custom objects for packaging, routing, and party identifiers.

The translation process introduces data quality risk at every step. EDI messages arrive as flat, positional text files — a single wrong character in the ISA (Interchange Control Header) segment will cause the entire message to fail validation. The EDI translator parses the raw file, validates it against the standard and the trading partner's specific implementation guide (which often deviates from the standard), and generates a functional acknowledgment (997/999 in X12) confirming receipt. Only after successful acknowledgment is the translated data passed to Salesforce for order creation.

-- Simplified X12 850 Purchase Order (illustrative structure)
ISA*00*          *00*          *ZZ*BUYERID        *ZZ*SUPPLIERID     *260515*1430*^*00501*000000001*0*P*:~
GS*PO*BUYERID*SUPPLIERID*20260515*1430*1*X*005010~
ST*850*0001~
BEG*00*SA*PO-2026-00812**20260515~   -- PO Number: PO-2026-00812
REF*DP*DEPT-42~                       -- Department number
DTM*002*20260522~                     -- Required delivery date
N1*BY*ACME RETAIL*92*ACME001~         -- Buyer identification
N1*ST*ACME DC CHICAGO*92*DC-CHI~      -- Ship-to location
PO1*1*100*EA*24.50**VP*SKU-98765~    -- 100 units @ $24.50 each
CTT*1~                                -- Transaction totals: 1 line
SE*9*0001~
GE*1*1~
IEA*1*000000001~

-- This maps to Salesforce as:
-- Order: PO-2026-00812, Ship By: 2026-05-22, Bill-To: ACME001
-- OrderItem: Product SKU-98765, Qty 100, Unit Price $24.50

AS2 Protocol: Trading Partner Authentication and Message Signing

AS2 (Applicability Statement 2) is the transport protocol used to exchange EDI messages over the internet. It replaced the older VAN-based leased-line model for many trading relationships, allowing direct machine-to-machine EDI exchange over HTTPS. AS2 adds message signing (using digital certificates to prove the message came from the claimed sender and was not tampered with) and optional encryption (using the receiver's public key) on top of standard HTTPS transport.

Each AS2 trading relationship requires certificate exchange. Your organisation and your trading partner each have an AS2 certificate — a private key you hold and a public key you share with your partner. Messages you send are signed with your private key; your partner verifies the signature using your public key. Messages you receive are signed with your partner's private key; you verify using their public key. Certificate management — generating, distributing, renewing, and revoking these certificates — is an operational overhead that is easy to underestimate. A certificate expiry in a live trading relationship causes immediate message rejection, which means order processing stops until the certificate is renewed and both sides are updated.

Salesforce does not have a native AS2 endpoint. The AS2 gateway — the component that handles certificate management, message signing and verification, acknowledgment generation, and protocol-level retries — is always an external component. MuleSoft, Sterling B2B Integrator, TrueCommerce, DiCentral, and SPS Commerce are common choices. The gateway sits in front of Salesforce: inbound EDI messages arrive at the AS2 gateway, are translated to JSON or XML, and are then sent to Salesforce via REST API. Outbound messages are pulled from Salesforce, translated to EDI, signed, and sent to the partner's AS2 endpoint.

Order-to-Cash Integration Patterns

In a Salesforce-centred order-to-cash flow for B2B commerce, the integration touchpoints span the full transaction lifecycle. A typical pattern for a manufacturer using Salesforce as the order management system looks like this: the retailer sends an X12 850 Purchase Order via AS2; the EDI gateway translates it and creates a Salesforce Order with Products; Salesforce triggers an order acknowledgment workflow that sends back an X12 855 via the same gateway; the warehouse management system (WMS) receives the fulfillment pick ticket from Salesforce; the WMS sends the shipment confirmation back to Salesforce; Salesforce triggers the outbound X12 856 ASN to the retailer; the retailer's receiving dock scans the ASN against the physical delivery; and finally the X12 810 Invoice is sent once goods are accepted.

Each step in this chain is a potential synchronization point failure. The 855 acknowledgment must be sent within the retailer's SLA window (often 24 hours from PO receipt). The ASN must be sent before the physical delivery arrives — a retailer that receives goods without an ASN may refuse the shipment or impose a chargeback. These are not soft business rules; they are contractual obligations with financial penalties for non-compliance. Salesforce workflow automation that generates these outbound messages must be reliable, monitored, and able to handle re-processing of failures without creating duplicates.

The critical architectural question in order-to-cash integration is: which system is the authoritative source for order status? If the ERP drives shipment confirmation and updates Salesforce, Salesforce must handle out-of-order updates gracefully (a shipment update arriving before the order line is fully processed). If Salesforce drives the process, the ERP must poll or subscribe to Salesforce order status changes. Mixed authority — where both systems can update order status — creates conflict resolution problems that are expensive to debug in production.

Partner Portal vs Direct API: Two Models for External Integration

Not all B2B integration is EDI. For technology sector, professional services, and distribution companies where trading partners are more technically sophisticated, two distinct integration models compete: the partner portal model and the direct API model.

The partner portal model uses Salesforce Experience Cloud to expose a branded self-service portal where partners log in, create orders, check inventory, submit service requests, and download documents. The partner's users interact directly with Salesforce data through the portal UI. Integration is human-mediated — the partner's staff do the data entry. This model is simpler to implement, provides good UX for casual users, and requires no technical integration capability on the partner side. Its limitation is scale and accuracy: manual data entry is slow and error-prone at volume.

The direct API model exposes Salesforce REST or SOAP APIs to partner systems for machine-to-machine integration. The partner's ERP or order management system places orders directly via API call. This scales well and eliminates manual entry errors. Its complications are partner technical capability (many partners cannot build API integrations), authentication management (each partner needs OAuth credentials or certificates), and versioning (the Salesforce API version in use by a partner may lag years behind the current release). Large enterprises with many trading partners may operate both models simultaneously — API integration for sophisticated partners, portal for smaller ones.

Governance for High-Stakes B2B Data Exchange

B2B integration carries operational and financial risk that justifies governance overhead that would be disproportionate for internal integrations. Chargebacks from EDI non-compliance can be 1-5% of invoice value per incident. A missed ASN for a large shipment to a major retailer can cost tens of thousands of dollars in a single transaction. This risk profile demands monitoring, audit trails, and operational runbooks that go beyond what most Salesforce implementations apply to internal integrations.

At minimum, every B2B message exchange should be logged: timestamp, partner identifier, message type, message ID (ISA control number for EDI), processing status (acknowledged, failed, re-queued), and the Salesforce record created or updated. This log is the evidence trail for chargeback disputes — "we sent the ASN at 14:32 on May 15th; here is the MDN confirming receipt" is the difference between absorbing a chargeback and disputing it successfully. Salesforce Big Objects or an external log store are appropriate for long-term retention of this audit trail.

Trading partner onboarding — the process of setting up a new B2B integration relationship — should have a formal runbook covering: certificate exchange and testing for AS2 relationships, test transaction exchange in a staging environment against the partner's test systems, functional acknowledgment testing, and production cutover with parallel processing for the first week. Partners that are onboarded quickly and informally are the ones that create operational incidents during peak trading periods. Budget three to six weeks for each new AS2 trading partner relationship in project plans.