Product
Everything between you and your retailers
Orders arrive, get checked, land in your warehouse. Despatches turn into ASNs and labels. Invoices match what shipped. Every acknowledgement is chased. One platform, one login, no mapping projects.
EDI translation
Any retailer format in, your format out
Retailers send EDIFACT, Tradacoms or X12, each with their own version and quirks. FTP EDI parses every message into one canonical document, so an order from Tesco looks the same to your systems as an order from Amazon.
Outbound, the same document becomes whichever message the retailer expects, with segment order, qualifiers and envelopes generated from the template we maintain.
- EDIFACT EANCOM D96A, D01B and later
- Tradacoms ORDHDR, DELHDR, INVHDR and ACKHDR
- X12 850, 855, 856, 810, 997 and 864
- Flat file, CSV, JSON and XML for your side
A retailer order in EDIFACT, Tradacoms or X12 is read segment by segment and translated into one canonical JSON order with the document number, buyer, ship-to, requested delivery date and lines with GTIN and quantity.
Retailer rule checks
Caught before it leaves, not after it is refused
Every retailer publishes rules that are not in the EDI spec: PO number patterns, best-before on every line, pallet heights, delivery note formats. Most rejections come from these, not from syntax.
FTP EDI runs each outbound document through the retailer's rule set before it is sent. Problems are explained in plain English with the field that caused them, so the fix takes seconds.
- Over thirty checks shipped per retailer template
- Blocking rules stop the send; warnings let you decide
- Custom rules per depot or product range
- Rule history kept for every document
A Lidl despatch advice is checked against five retailer rules. SSCC per pallet, GTIN and depot GLN pass. The best-before check finds line 2 missing a date, FTP EDI applies the fix, the check passes, the delivery note length is confirmed and the document is ready to send.
Lidl GB · DESADV rules
Ready to sendDN751715062601
1 pallet · 2 lines · 270 cases
- SSCC per pallet
- GTIN valid
- Best-before on every line
- Depot GLN known
- Delivery note ≤16 chars
ASNs and GS1-128 labels
The ASN and the label come from the same data
An ASN that does not match the pallets on the vehicle is the most expensive mistake in retail supply. FTP EDI builds the despatch advice from the warehouse confirmation, allocates SSCCs and prints labels from the same record.
Mixed pallets, multi-drop loads, best-before per line and retailer-specific label layouts are handled by the template, not by the person on the despatch desk.
- SSCC allocation from your GS1 company prefix
- Tesco, Sainsbury's, Lidl, Amazon and generic GS1 label layouts
- PDF or ZPL output straight to the warehouse printer
- Delivery notes in the retailer's layout
GS1-128 · Tesco pallet label
ApprovedShip to
Tesco Daventry Ambient
Site 5028
From
Fenland Foods Ltd
GLN 5060123400010
GTIN (02)
05060123400027
Count (37)
48
Best before (15)
2026-11-02
Batch (10)
L26089A
(00) 3 5060123 400000012 7
Warehouse connections
Orders in your WMS in minutes, despatches back without retyping
FTP EDI grew up inside a 3PL running Clarus WMS, so the Clarus connector is native: orders drop straight into the warehouse queue and despatch confirmations flow back to build the ASN.
Any other WMS or ERP that can drop a file on SFTP or call an API connects the same way. We map your export once and keep it stable when retailers change their specs.
- Native Clarus WMS connector
- SFTP, REST API and email intake for anything else
- Field-level mapping with test fixtures you can replay
- Stock, order status and despatch events in both directions
- Tesco ORDERS 4471082 Received 09:12:04
- Rule checks 27 passed 09:12:05
- Clarus WMS Order 00448812 created 09:12:09
- Despatch confirmed 6 pallets, 288 cases 14:40:31
- DESADV 3352019 Sent via AS2 14:40:33
- CONTRL Waiting (due 18:40)
Acknowledgement chasing
Every document has a clock on it
Sending is half the job. Retailers acknowledge at the transport layer (AS2 MDN), the syntax layer (CONTRL, 997) and sometimes the application layer (RECADV, 855). If any of those goes missing you find out from a refused delivery or a short-paid invoice.
FTP EDI knows which acknowledgements each retailer sends and how long they take. It matches them to the original document, marks it complete and raises an alert when the window closes with nothing back.
- MDN, CONTRL, 997, APERAK, RECADV and 855 matched automatically
- Per-retailer windows, from one hour to next day
- Outbound 997s and CONTRLs generated for inbound documents
- Escalation to a second contact if nothing is done
A despatch advice is sent to Lidl, delivered with an AS2 MDN, acknowledged with a CONTRL and accepted. In a second run the CONTRL does not arrive, FTP EDI raises an overdue acknowledgement alert by email after four hours, and the acknowledgement then arrives and the document is accepted.
Acknowledgement tracking
DESADV DN751715062601 → Lidl GB
Run 1
09:41:00
- Sent —
- Delivered (MDN) —
- CONTRL received —
- Accepted —
Overdue acknowledgement
alerts@ftpedi.com → ops@yourcompany.co.uk
Lidl DESADV 2026-09-25 — 4h without CONTRL. We have re-requested the acknowledgement from Schwarz IT.
Alerts that reach the right person
A rejected ASN at 16:00 on a Friday needs a person, not a dashboard. Alerts go by email, SMS or webhook to the people who can act, with the document, the reason and a link to fix it.
Routing is per company and per retailer, so the despatch team hears about labels, finance hears about invoice queries and IT hears about connection failures.
- Email, SMS and webhook channels
- Quiet hours and escalation
- Daily digest of anything still open
- Alert history on every document
A portal your team will actually use
Every document has a timeline: received, checked, delivered to the warehouse, despatched, sent, acknowledged. Anyone in the business can see where an order is without asking IT.
Upload a spreadsheet or PDF order when a retailer sends one by email. Resend, hold or release documents. Print labels and delivery notes. Search seven years of history by PO, SSCC or invoice number.
- Upload orders, ASNs and invoices manually
- Hold and release outbound documents
- One-click resend after a fix
- Role-based access per company
API and webhooks
Built for your developers as much as your despatch desk
Everything the portal can do, the API can do. Pull documents and acknowledgements, push despatch confirmations, query rule results and download the raw EDI for any message.
Webhooks deliver events as they happen: order received, ASN sent, acknowledgement received, rule failed. Payloads are versioned JSON with a signature header so you can trust them.
- REST API with bearer tokens per company
- Signed webhooks with automatic retry
- Sandbox company with replayable test documents
- OpenAPI specification and Postman collection
$ curl -H "Authorization: Bearer ..." \
https://<your-host>/api/v1/documents{
"event": "document.acknowledged",
"occurred_at": "2026-09-18T14:52:10Z",
"document": {
"id": "doc_01J8Q2K7X",
"type": "DESADV",
"partner": "tesco",
"reference": "3352019"
},
"acknowledgement": {
"type": "CONTRL",
"status": "accepted",
"elapsed_minutes": 11
}
}Audit and retention
When a retailer disputes a delivery, you have the evidence
Every message, in both raw and translated form, is stored for seven years with the acknowledgements, rule results and user actions that go with it. Nothing is overwritten.
Exports are built for the conversation you are about to have: a single PDF per document with the EDI, the MDN, the CONTRL and the timeline, or a CSV across a date range for finance.
- Seven-year retention as standard
- Raw EDI and translated document kept side by side
- User actions logged with who, what and when
- Evidence pack export per document or per dispute
Comparison
Doing it yourself vs FTP EDI
An in-house EDI stack is a permanent project. This is what you take off the list.
| What you need | Doing it yourself | FTP EDI |
|---|---|---|
| Retailer connectivity | Your own AS2 software and certificates, or a VAN contract per retailer | Held and renewed for you, one connection per retailer |
| Message mapping | Hand-written maps per retailer and version, updated when the spec changes | Retailer templates maintained centrally, rule checks included |
| ASNs and labels | Spreadsheet SSCCs and a label tool that nobody trusts | ASN built from the despatch confirmation, GS1-128 labels generated from the same data |
| Acknowledgements | Someone checks the mailbox and hopes | Every CONTRL, 997 and MDN matched, chased and alerted |
| Audit and disputes | Search through email and FTP logs | Seven-year archive, timeline per document, evidence exports |
Questions
Product questions
Which EDI standards does FTP EDI support?
EDIFACT (EANCOM D96A and later), Tradacoms and ANSI X12, all mapped to one canonical document model. You never write a map; you pick the retailer template and we fill in the depot details.
Do I need my own AS2 certificate or VAN account?
No. FTP EDI holds the AS2 connections and VAN mailboxes on your behalf and completes the retailer connectivity forms with you. If you already have a VAN we can route through it.
Can FTP EDI connect to my warehouse or ERP?
Yes. We have a native Clarus WMS connector and connect to any WMS or ERP that can exchange files over SFTP or call a REST API. See warehouse integration.
What happens when a retailer rejects a document?
The rejection is matched to the original document, the reason is translated into plain English and the people you nominate are alerted by email, SMS or webhook. You fix the data in the portal and resend in one click.
Is there an API?
Every document, acknowledgement and event is available through the REST API, and webhooks push events to your systems as they happen. Authentication is by bearer token per company.
Ready to stop worrying about EDI?
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.