Swiss retail has been exchanging structured electronic documents with suppliers for decades. EDI — Electronic Data Interchange — has handled purchase orders, invoices, and despatch advice between large retailers and their suppliers since the 1980s and 1990s. The formats involved (EDIFACT, particularly INVOIC and ORDERS messages) are deeply embedded in supply chain systems on both sides.
Modern e-invoicing standards — PEPPOL BIS Billing 3.0, ZUGFeRD — operate on completely different technical foundations. The migration from legacy EDI to these newer formats is not just a format conversion. It involves changes to how products are identified, how trading partner agreements are structured, and in some cases how the entire supplier onboarding process works.
This post covers the specific considerations for Swiss retailers and their suppliers navigating this transition.
How EDI and modern e-invoicing differ
EDIFACT INVOIC and PEPPOL BIS Billing 3.0 achieve the same goal — transferring invoice data electronically — but their design assumptions are very different.
EDI was designed for bilateral, point-to-point integration between known trading partners. Each EDI connection is set up with a specific partner, with agreed message formats, field mappings, and data standards negotiated upfront. A retailer with 500 suppliers might have 500 separate EDI configurations. The value is in the automation of high-volume, repetitive transactions between established relationships.
PEPPOL is designed as a network where any registered participant can exchange documents with any other participant without a bilateral setup. The format is standardised, so a compliant invoice from any sender should be processable by any compliant receiver. This dramatically reduces setup overhead for new trading relationships but requires stricter adherence to the standard than bilateral EDI typically does.
In practice, large Swiss retailers run both. Their top 50–100 suppliers by volume often have direct EDI connections that work reliably and will not be replaced soon. The pressure to migrate to PEPPOL or ZUGFeRD typically comes from:
- The federal B2G e-invoicing mandate, which affects retailers who supply goods or services to federal bodies
- Pressure from smaller suppliers who want to use standard tools rather than set up bespoke EDI connections
- Technology modernisation programmes inside the retailer that are replacing legacy EDI infrastructure
- EU border trading partners where PEPPOL is the expected channel
GS1 and GTINs in e-invoicing
GS1 is the international standards body responsible for the Global Trade Item Number (GTIN) — the barcode system that identifies every product sold at retail. Swiss retail invoicing has always been heavily GS1-dependent: purchase orders reference GTINs, delivery notes reference GTINs, and invoices reference GTINs so that three-way matching can work at the line-item level.
In PEPPOL BIS Billing 3.0, product identifiers on line items are supported through the CommodityClassification and SellersItemIdentification / BuyersItemIdentification fields. GTINs map to these fields, but you need to specify the identifier scheme so the receiving system knows it is a GTIN rather than a proprietary product code.
In PEPPOL XML the structure looks like this:
<cac:Item>
<cbc:Name>Organic Whole Milk 1L</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>7612345678901</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">7612345678901</cbc:ID>
</cac:StandardItemIdentification>
</cac:Item>
The scheme ID 0160 is the GS1 GTIN scheme in the PEPPOL code list. Using it correctly tells the retailer's system that the identifier is a globally unique GTIN, not just a supplier-internal article number — which matters for automated matching against their product master.
If your invoicing system currently exports GTINs in an EDIFACT LIN segment, the migration to PEPPOL line items requires mapping that data to the correct XML element. This sounds straightforward but is often where implementation time is actually spent — especially when product masters have inconsistent data quality, with some items having valid GTINs and others using internal codes that have never been mapped to the GS1 registry.
The EDI-to-e-invoice migration path
A realistic migration for a supplier currently trading via EDIFACT with Swiss retailers involves several phases:
Phase 1: Audit your current EDI setup. For each retailer you trade with via EDI, document what messages are exchanged (ORDERS, INVOIC, DESADV, RECADV), what data each message carries, and which fields are critical for the retailer's downstream processing. Pay particular attention to any non-standard field usage — EDI implementations frequently use optional or free-form fields in ways that the standard does not define, and these are the hardest parts to replicate in a new format.
Phase 2: Establish which retailers have PEPPOL endpoints. Not all Swiss retailers are PEPPOL participants yet. Check the PEPPOL participant directory for each retailer's buyer identifier. For those not yet on PEPPOL, ZUGFeRD via email or a shared portal may be an intermediate option.
Phase 3: Build or procure a PEPPOL-capable invoicing tool. If your ERP does not support PEPPOL output natively, you need a middleware or conversion layer. Evaluate this against the actual data complexity of your retail invoices — if you have GTINs, weight-based pricing, promotional allowances, and multi-line despatch references all on a single invoice, a generic PEPPOL generator may need significant customisation.
Phase 4: Test with actual invoice data. Run your most complex invoices — promotions, variable weight items, credit notes, mixed-rate VAT — through the new pipeline in the retailer's test environment. Do not test only with simple clean invoices. The edge cases are where EDI-to-PEPPOL migrations typically break.
Phase 5: Run parallel for a period. Keep your EDI connection live while you validate PEPPOL invoices alongside it. Only switch off EDI once you have confidence that every invoice type you generate produces a valid, accepted PEPPOL document on the retailer's side.
Promotional allowances and charges
Swiss retail invoicing frequently includes promotional allowances — discounts applied to invoices when a supplier participates in a retailer's promotional programme. In EDIFACT, these are carried in ALC (Allowance or Charge) segments. In PEPPOL BIS Billing 3.0, they map to AllowanceCharge elements at line item or document level.
The common mistake in migration is to fold allowances into line-item prices rather than representing them as explicit allowance fields. This produces invoices where the unit price already reflects the promotional rate rather than showing the list price with a discount — which breaks the retailer's margin analysis and makes auditing promotional spend much harder. Keep allowances as explicit fields, matching the structure of your EDI messages.
Despatch advice and goods receipt linking
In a full EDI supply chain, invoices reference the DESADV (despatch advice) message that was sent when goods were shipped. This link allows three-way matching on the retailer's side: purchase order, despatch advice, invoice.
PEPPOL BIS Billing 3.0 supports a DespatchDocumentReference field on the invoice. If your current EDI invoices reference the DESADV number, preserve this reference in the PEPPOL migration. Retailers whose matching systems rely on this reference will see exception rates spike if invoices suddenly arrive without it, even if everything else about the invoice is correct.
What is not changing
The underlying commercial logic of retail invoicing does not change when the format changes. GTINs are still GTINs. Allowances are still allowances. VAT is still VAT. The migration from EDI to PEPPOL is primarily a technical translation exercise — the data exists in both systems, it just needs to move to different field positions with different encoding.
The projects that go well are the ones that start with the data, not the technology. Map every field in your current EDIFACT INVOIC against the PEPPOL BIS schema before you write a line of code. Identify the fields that have direct equivalents, the ones that need transformation, and the ones that have no equivalent and may need to be dropped or moved to a note field. That mapping exercise, done properly, tells you how complex the migration will actually be — and it is almost always less complex than people initially fear.