About
Retailer EDI, built by the people who had to live with it
FTP EDI exists so that suppliers can trade with the UK multiples without an EDI project, a consultant or a mailbox someone has to check. We know the problem because it was ours first.
Mission
Make retailer EDI something a supplier never has to think about
Every UK food and consumer goods supplier who wins a listing with Tesco, Sainsbury's, Lidl or Amazon gets the same welcome pack: message guides, pallet standards, connectivity forms and a go-live date. It is the price of admission, and it has nothing to do with making a good product.
The tools built for this were designed for large enterprises with integration teams. Suppliers with twenty people end up with a mapping project, a monthly bill that scales with pain, and a spreadsheet of SSCCs.
We think the retailer's requirements should be encoded once, by us, and enforced automatically for everyone. The ASN should come from the warehouse, the label from the ASN and the invoice from the receipt. Acknowledgements should be chased by software, and a person should only hear about it when there is something to decide.
That is the whole platform. Everything on the product tour is there because a supplier or a warehouse needed it on a live delivery.
Why we built it
Born inside a UK 3PL
FTP EDI started as internal tooling inside a UK third-party logistics business running Clarus WMS for food suppliers. Dozens of brands, all shipping to the same handful of retailers, all with the same problems: ASNs that did not match the pallets, labels printed from the wrong spreadsheet, CONTRLs nobody looked at until a lorry was turned away.
The first version did three things. It pulled the despatch confirmation out of Clarus and built the DESADV from it. It printed the pallet label from the same record. And it watched the mailbox for the acknowledgement and shouted when one was late. Refusals dropped to almost nothing within a quarter.
Suppliers started asking whether they could use it for the retailers the 3PL did not handle. Then for their own warehouses. FTP EDI is that tool, rebuilt as a platform for any supplier and any warehouse, still with the same three jobs at its heart.
What that history gives you
- A native Clarus WMS connector that has run live loads for years
- Retailer templates written from real rejections, not just the spec
- Multi-company from day one, because a 3PL has many customers
- Support staff who have chased a Tesco CONTRL at 7am
Values
Three things we will not compromise on
The despatch desk is the customer
EDI is judged at 5pm on a Friday when a pallet label is wrong. We build for the person who has to fix it, not for the consultant who set it up.
Plain English or it is not finished
A rejection that says UNB segment invalid helps nobody. Every rule, alert and error on the platform is written so that a non-technical colleague can act on it.
Own the outcome, not the message
Sending a document is not the job. The job is the delivery being booked in and the invoice being paid. We track until that happens.
How we work
UK-based, plain English, no lock-in
UK-based
Built and supported in the UK, for UK retailers, by people who have stood in a chilled depot at 6am. Support is on UK hours and knows what a TRN is.
Plain English
Contracts, pricing and the platform itself. If a page of ours needs a glossary, we rewrite it.
No lock-in
Monthly plans, your data exportable at any time in raw EDI and in structured form, and help moving off if you ever need to. We keep customers by being useful.
Questions about the company, partnerships or press: hello@ftpedi.com.
Want to talk to the people who built it?
Tell us who you trade with and what you ship. We'll come back with a plan, a price and a go-live date within one working day.
No software to install. Live in days. UK-based support.