Connect Google Cloud to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between Google Cloud and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with Google Cloud EDI
XEDI exchanges trading files through Google Cloud Storage, with identity handled the way GCP expects, so EDI is added to a project your teams already operate.
One managed platform, no custom code
XEDI maps Google Cloud to your trading partners and validates every document, so data flows straight into the systems your teams already use.
Identity is the part worth getting right in GCP
Google Cloud is opinionated about identity in a way that helps here. Access is granted to a service account rather than through a key somebody pastes into a configuration, permissions are inherited through the project hierarchy, and what an identity can do is inspectable.
That matters for an exchange that has to run unattended for years. A named identity with bucket-scoped permissions is far easier to reason about at audit than a credential nobody can account for, and it does not quietly expire the way time-limited alternatives do.
Data teams are usually downstream, and that shapes the design
GCP estates frequently exist because of what happens after the data lands: analytics, warehousing, reporting built on top. Trading documents are not only an operational concern in that environment, they are an input to how the business measures itself.
So it is worth deciding early whether the exchange writes purely for operational collection, or in a form your data platform can also consume. Doing both from the start is cheap; retrofitting a second representation once dashboards depend on the first is not.
What your team sees day to day
You get an EDI mailbox and a portal that behaves like an inbox, showing collection state without anyone inspecting a bucket.
Demand lands, the despatch advice is built from what genuinely left the building rather than what was ordered, SSCC labels included where required, and the invoice follows with delivery confirmed.
Your project carries on exactly as it does. The EDI capability is bolted onto Cloud Storage you already use, with the partner requirements staying ours.
Documents you can exchange
- Order files written to a bucket for your systems
- Despatch and quantity files collected from a bucket
- Invoice data written out for downstream processing
- Stock and catalogue files exchanged with partners
- Failed documents written for correction
Built for Google Cloud teams
Whoever owns Google Cloud in your business, XEDI keeps EDI accurate and hands-off.
- GCP platform and data teams
- Businesses running workloads on Google Cloud
- Analytics teams consuming trading data
- Engineering teams maintaining exports
- Organisations standardised on Google
Google Cloud EDI document types
A bucket carries objects; these are the exchanges they usually serve.
| Document | What it carries | Direction |
|---|---|---|
| Order files | Retailer demand written to a bucket path your systems already read. | XEDI to Cloud Storage |
| Despatch files | What is shipping, collected and validated before it becomes a despatch advice. | Cloud Storage to XEDI |
| Invoice data | Invoice detail written for finance or for a data platform to consume. | XEDI to Cloud Storage |
| Catalogue and stock files | Product and availability figures exchanged with partners on an agreed cycle. | Either direction |
| Processed objects | Handled files moved aside so nothing is collected a second time. | Within the bucket |
| Exception objects | Documents failing validation, written with the reason attached. | XEDI to Cloud Storage |
How to connect Google Cloud with EDI using XEDI
Identity and downstream consumption are the decisions worth making deliberately. The sequence below is what onboarding looks like from your side.
-
01
We agree the project, buckets and paths carrying exchange traffic.
-
02
We set up a service identity scoped to those buckets rather than the project.
-
03
We fix object naming so collection and duplicate detection are reliable.
-
04
We prove the flows, including how notifications or scheduling should drive collection.
-
05
You get EDI running against Cloud Storage your systems already write to.
Ready to connect Google Cloud?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about Google Cloud EDI
Common requirements
- Project and buckets in scope
- How service identity should be granted
- Object naming convention
- Whether collection is scheduled or notified
- The trading partners the files relate to
What we need from you to build it
Only what we cannot decide for you. Partner requirements stay ours; project and identity conventions are yours.
- Project and buckets
- Which project and buckets carry exchange traffic, so permissions are scoped to them.
- Service identity
- How access should be granted, since a named service account is easier to account for at audit than a pasted credential.
- Object naming
- How objects are named, because collection and duplicate detection rely on it.
- Downstream consumption
- Whether a data platform will also read these files, since writing for both from the start is far cheaper than retrofitting.
- The partners the files relate to
- Which relationships this serves. Their requirements are already held by us.
Why suppliers choose XEDI for Google Cloud
- Partners are usually connected already, so identity and downstream consumption are what actually take time.
- Access runs through a named service identity that can be inspected rather than a credential nobody can account for.
- Whether your data platform also consumes the files is decided before dashboards depend on one representation.
- Permissions are scoped to the buckets involved rather than the project.
- Your systems keep writing to Cloud Storage exactly as they do now.
- Partner requirements and validation remain ours whatever happens downstream.
How is access granted?
Through a service account scoped to the buckets carrying exchange traffic. That is easier to reason about at audit than a long-lived key, and it does not expire unexpectedly.
Can our data warehouse consume the same files?
Yes, and it is worth deciding at the start. Writing in a form both operations and analytics can use costs little up front and a great deal to retrofit once reporting depends on the original shape.
Scheduled or event-driven collection?
Either. Notifications suit time-sensitive documents where a retailer cut-off is tight; a schedule is simpler and adequate for most catalogue and stock exchanges.
Plan your Google Cloud EDI setup
Everything you need to scope, map and go live with Google Cloud, in one place.