Connect Salesforce Commerce Cloud to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between Salesforce Commerce Cloud and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with Salesforce Commerce Cloud EDI
XEDI connects Salesforce Commerce Cloud with retailer and wholesale EDI, fitting alongside the order management and ERP systems a Commerce Cloud estate usually runs rather than pretending the storefront is the system of record.
One managed platform, no custom code
XEDI maps Salesforce Commerce Cloud to your trading partners and validates every document, so data flows straight into the systems your teams already use.
Commerce Cloud is usually one system among several
A Commerce Cloud estate almost never stands alone. There is typically an order management system behind it, an ERP behind that, sometimes a separate inventory service, and the storefront is the consumer-facing part of a larger landscape.
That matters because a wholesale order does not belong on the storefront. It belongs wherever fulfilment and billing actually happen, and the first job is establishing where that is rather than assuming the commerce platform is the answer.
Headless architecture helps, provided the boundary is deliberate
Commerce Cloud estates are frequently headless or partially so, with catalogue, pricing and inventory served through APIs to several consumers. That is a good position to integrate into, because the boundaries already exist and are documented internally.
What goes wrong is when a trading connection is attached to whichever service was easiest to reach rather than the one that owns the data. It works until that service is refactored, which in an enterprise estate is a matter of when.
What your team sees day to day
Your trading partners reach an EDI mailbox and a portal that works like an inbox, independent of whichever internal systems are being changed that quarter.
The order becomes the despatch advice raised by whichever system fulfils it, amended where the delivery differs, with SSCC labels for the pallets, and becomes the invoice on delivery, whose arrival is confirmed in the dashboard.
The integration connects to the systems that own each step rather than to the storefront. Enterprise estates commonly take our API as well, for the finer granularity their own services need.
Documents you can exchange
- Wholesale orders reaching the systems that fulfil them
- Order acknowledgements returned to the trading partner
- Despatch advice and ASN messages from the fulfilling system
- Invoices raised against the despatch
- Catalogue and availability data shared with partners
Built for Salesforce Commerce Cloud teams
Whoever owns Salesforce Commerce Cloud in your business, XEDI keeps EDI accurate and hands-off.
- Enterprise ecommerce and integration teams
- Solution architects
- Order management and fulfilment teams
- Finance teams handling wholesale billing
- Brands running Commerce Cloud alongside an ERP
Salesforce Commerce Cloud EDI document types
Where each of these attaches depends on how your estate divides responsibility, which is settled before anything is built.
| Document | What it carries | Direction |
|---|---|---|
| Purchase orders | Partner demand routed to whichever system owns order management in your estate. | Partner to your estate |
| Order acknowledgements | Confirmation of what will be supplied, raised once availability is resolved against the owning service. | Your estate to partner |
| Advanced shipping notices | Pallet and carton detail from the fulfilling system, with SSCC labels for the partner's goods-in. | Your estate to partner |
| Invoices | Raised by whichever system bills, referenced to the order and delivery for automatic matching. | Your estate to partner |
| Catalogue data | Product and pack data published to partners maintaining a catalogue against your range. | Your estate to partner |
| Availability | Stock position from whichever service is authoritative, rather than from the storefront's cached view. | Your estate to partner |
How to connect Salesforce Commerce Cloud with EDI using XEDI
The first decision is architectural rather than technical: which system owns what. The sequence below is what onboarding looks like from your side.
-
01
We establish which system in your estate actually owns fulfilment and billing, since Commerce Cloud rarely does both.
-
02
We build the mapping between each partner's documents and the records those systems hold.
-
03
We configure validation so a document is checked against the partner's rules before it enters the estate.
-
04
We prove each flow against what the partner requires and against how your estate divides responsibility.
-
05
You get trading that fits the architecture you already have, and we keep it right as that architecture evolves.
Ready to connect Salesforce Commerce Cloud?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about Salesforce Commerce Cloud EDI
Common requirements
- Which systems own order management and fulfilment
- Commerce Cloud realm and site structure
- Product and catalogue identifiers
- Availability and inventory source
- Trading partners in scope
What we need from you to build it
Only what we cannot hold for you. Partner requirements are already ours; what we need is an accurate map of your estate.
- System ownership
- Which system owns order management, fulfilment, billing and inventory, because documents attach to those rather than to the storefront.
- Commerce Cloud structure
- Realm, sites and catalogues in scope, where Commerce Cloud is genuinely part of the trading flow.
- Product identity across services
- How a product is identified in each system, since enterprise estates frequently disagree with themselves.
- Authoritative inventory
- Which service holds the stock position a partner commitment should be made against.
- Trading partners in scope
- The wholesale relationships to connect, now and next. Their requirements are already ours.
Why suppliers choose XEDI for Salesforce Commerce Cloud
- Partners are typically connected already, which matters when mapping an enterprise estate takes time.
- Documents attach to the systems that own them rather than to whichever service was easiest to reach.
- Partners are insulated from internal refactoring, so a service being replaced does not become a trading incident.
- Onboarding a wholesale partner does not compete for time on your commerce roadmap.
- Our API gives your own services the finer-grained access enterprise estates usually need.
- If a partner raises a problem, it comes to us rather than becoming a ticket in your queue.
Should wholesale orders land in Commerce Cloud?
Usually not. Commerce Cloud is the consumer-facing part of a larger estate, and a wholesale order belongs wherever fulfilment and billing actually happen. Establishing that is the first step rather than an assumption.
Does this work with a headless setup?
Yes, and headless estates are often easier to integrate because the boundaries already exist. The important thing is connecting to the service that owns the data rather than the one that is most convenient.
What happens when we replace an internal system?
Partner-facing arrangements do not move, because they never depended on your internal architecture. The change is on our side and your partners see no difference.
Plan your Salesforce Commerce Cloud EDI setup
Everything you need to scope, map and go live with Salesforce Commerce Cloud, in one place.