Connect Google Sheets to EDI instantly
Join thousands of businesses moving EDI orders, invoices and fulfilment updates between Google Sheets and their trading partners on XEDI, no manual re-keying.
No credit card needed ✦ Free EDI mailbox included
Getting started with Google Sheets EDI
XEDI can write your trading data into Google Sheets and pick up instructions from one, which suits teams who genuinely work in spreadsheets, with the caveats that come from a document people can edit.
One managed platform, no custom code
XEDI maps Google Sheets to your trading partners and validates every document, so data flows straight into the systems your teams already use.
A spreadsheet is an interface people can edit, which cuts both ways
Plenty of businesses run real operations from a sheet, and there is nothing wrong with that. It is visible, everyone understands it, and changing it does not require anybody technical.
That last property is also the risk. A column inserted to help with something unrelated, a row sorted, a quantity typed as text: all normal spreadsheet behaviour, and all capable of breaking an automated read. So the structure is agreed and validated rather than assumed, and a sheet that no longer matches raises an exception instead of sending something wrong to a retailer.
Useful for instructing, better than most people expect for visibility
The two sensible uses are opposite ends of the flow. Writing into a sheet gives a team the current position of orders and deliveries in a form they can filter, colour and share without asking anyone for a report.
Reading from one lets a team give an instruction: these are the quantities actually going, this is what we are short. That is a legitimate way to run despatch for a small operation, and everything read is validated against the retailer's requirements before it becomes a document.
What your team sees day to day
You get an EDI mailbox and a portal that behaves like an inbox, with the sheet as a working surface alongside rather than instead of it.
Orders arrive and can be reflected into the sheet. What you confirm becomes the despatch advice, adjusted where the delivery differs, carrying SSCC pallet labels where the retailer requires them, and then the invoice once delivered, with its delivery confirmed in the dashboard.
This is generally a stepping stone. Businesses that outgrow it move to an integration with a system that holds stock properly, and the retailer sees no change at all. Nothing about the spreadsheet changes; EDI is bolted onto the way your team already works.
Documents you can exchange
- Order data written into a sheet for your team to work from
- Despatch and quantity instructions read back from a sheet
- Stock or price data maintained in a sheet and published to partners
- Document status written for visibility
- Exception lists for someone to action
Built for Google Sheets teams
Whoever owns Google Sheets in your business, XEDI keeps EDI accurate and hands-off.
- Small operations teams
- Businesses without a warehouse or order system
- Category and planning teams
- Finance teams doing reconciliation by hand
- Anyone whose process genuinely lives in a spreadsheet
Google Sheets EDI document types
A sheet carries data rather than documents; these are the things it usefully holds.
| Document | What it carries | Direction |
|---|---|---|
| Order lines | What a retailer has ordered, written into a sheet so a team can plan against it without a system. | XEDI to sheet |
| Despatch instructions | What is actually being sent, entered by your team and validated before it becomes a despatch advice. | Sheet to XEDI |
| Stock or price data | Figures maintained by hand and published to partners that expect a catalogue or availability. | Sheet to partner |
| Document status | Where each document has got to, written back so nobody has to ask. | XEDI to sheet |
| Exceptions | Anything that failed validation, listed for somebody to correct. | XEDI to sheet |
| Reconciliation data | Invoices raised against deliveries confirmed, for finance to work through. | XEDI to sheet |
How to connect Google Sheets with EDI using XEDI
The work is mostly agreeing a structure that survives contact with the people using it. The sequence below is what onboarding looks like from your side.
-
01
We establish what the sheet is actually for: reading, instructing, or both.
-
02
We agree the structure, because a sheet that people reshape stops being an interface.
-
03
We connect the sheet with access scoped to what is needed.
-
04
We prove the flows, including what should happen when the sheet contains something unexpected.
-
05
You get trading data where your team already works, with validation before anything reaches a partner.
Ready to connect Google Sheets?
Talk through documents, mapping, testing and go-live with XEDI.
Everything about Google Sheets EDI
Common requirements
- The sheet and access to it
- Who edits it and how often
- The structure and which columns are meaningful
- What should happen when a value is wrong
- The trading partners the data relates to
What we need from you to build it
Only what we cannot decide for you. Retailer requirements are ours; the sheet's shape is a joint decision.
- The sheet itself
- Access to it, and confirmation of whether it is read from, written to, or both.
- Who edits it
- How many people change it and how often, because a widely edited sheet needs stricter validation.
- Structure that will hold
- Which columns are meaningful and what happens if somebody adds one, since an inserted column is normal spreadsheet behaviour.
- Handling bad values
- What should happen when a quantity is text or a date is ambiguous, rather than guessing at the point it matters.
- The partners the data relates to
- Which relationships this covers. What each of them requires is already held by us.
Why suppliers choose XEDI for Google Sheets
- The retailer is very likely connected already, so a spreadsheet-based operation can be trading in days.
- Your team keeps working where they already work rather than learning a system for one retailer.
- Everything read from the sheet is validated against the retailer's requirements before it becomes a document.
- A sheet that has been reshaped raises an exception instead of quietly sending something wrong.
- It is an honest stepping stone, and we will say when you have outgrown it.
- Moving to a proper system later changes our side, not what the retailer receives.
Is running EDI from a spreadsheet sensible?
For a small operation it can be, provided what comes out of the sheet is validated before it reaches a retailer. The risk is not the spreadsheet, it is that spreadsheets get reshaped, so the structure is agreed and checked rather than assumed.
What happens if someone breaks the sheet?
Validation fails and an exception is raised rather than a malformed document being sent. That is the whole reason not to read a sheet naively.
Can we start here and move to something better?
Yes, and many do. The retailer-facing side does not change when you move to a system that holds stock properly, because it never depended on the sheet.
Plan your Google Sheets EDI setup
Everything you need to scope, map and go live with Google Sheets, in one place.