Metro AG
METRO receives supplier invoices via EDI using the EDIFACT subset EANCOM. Identification runs entirely on GS1 master data — GLN for the parties and GTIN for the goods. Before going live, every supplier passes a mandatory test phase.
Status of this page. The publicly available EDI guidelines of METRO’s invoice processing unit date from the MGP era and reference Group companies that have since been divested. The framework below is therefore an orientation, not a binding specification. The current message implementation guideline is issued by METRO directly during onboarding — always work from that document.
Submission channels
EDI Classic
The supplier converts invoice data into EANCOM format with its own EDI translator or through an external service provider and transmits it to METRO.
Transmission via X.400 mailbox or AS2 / EDIINT
Web-EDI
Browser-based application. Invoices are prepared offline and transmitted in converted EANCOM form.
Details depend on the EDI service provider used
Accepted standards
- EANCOM 2002 (D.01B) INVOIC
- EANCOM 97 (D.96A) INVOIC
- Other EDIFACT subsets or versions are not accepted.
Only two document types are exchanged: commercial invoices and credit notes. Debit notes issued by METRO must not be mirrored back as EDI credit notes.
Master data
| Identifier | Requirement |
|---|---|
| GLN | Identifies supplier, buyer/invoicee and delivery party. 13 digits including the check digit |
| GTIN | Identifies the invoiced goods. 13 digits including the check digit; GTIN-14 with 14, GTIN-8 with 8 |
| Supplier number | Assigned by METRO; one EDI file per supplier number |
| VAT ID | Required for both supplier and buyer |
| IBAN / SWIFT | Bank details must be transmitted without blanks |
Master data maintenance is the supplier’s responsibility. An invalid or outdated GLN causes the invoice to be refused and delays the payment due date. GLNs of the buyer and delivery party can change between the order and the invoice.
Onboarding
| Phase | Content |
|---|---|
| Preparation | Contacts for EDI and master data are defined, open questions on the guideline clarified, a go-live timetable agreed |
| Test | Test files must contain real data from current business, flagged as test. Paper invoices continue in parallel. Each test file receives a qualified test report; errors are corrected and a new file submitted |
| Production | Switch on a fixed date. From then on no paper invoices are accepted. Later changes affecting invoice content must be agreed and re-tested |
Invoice rules
- One invoice per delivery note. The delivery note number in the EDI data must match the physical delivery note exactly in length and content.
- Delivery note number, delivery date and the customer order number are mandatory entries.
- Invoices with a total of zero must still be transmitted.
- Amounts are implicitly positive; the document type distinguishes invoice from credit note. Message function must always be “original”.
- A maximum of three VAT rates per invoice. Beyond that, a further invoice must be issued.
- Returned goods do not belong in an invoice — apart from deposit returns. Quantity or price differences are settled by credit or debit note.
- Freight and packaging are recorded at invoice level; allowances and charges at line level.
- Within one file, place invoices before credit notes.
Error handling
- A syntax error rejects the entire file, not just the affected invoice.
- Content errors lead to refusal of individual invoices, reported through an EDI error protocol.
- Refused invoices must be cancelled internally, corrected and re-transmitted via EDI — not on paper.
