eCH-0069 is the Swiss e-government standard that defines the data model and technical requirements for electronic invoices in the Swiss public sector. It sits alongside the SwissDIGIN PEPPOL profile as part of the broader Swiss e-invoicing standardisation landscape — eCH-0069 focuses particularly on the requirements of federal and cantonal government procurement systems, while SwissDIGIN focuses on the PEPPOL-specific implementation.
Version 4 of the standard was published by the eCH organisation following a consultation process that included federal IT stakeholders, software vendors, and cantonal representatives. Here is what changed and what it means if you already have an implementation based on an earlier version.
Background: what eCH-0069 covers
Before looking at the changes, it helps to understand the scope. eCH-0069 defines:
- The semantic data model for a Swiss e-invoice — what fields must be present, which are optional, and what each field means
- The syntactic binding to specific XML formats (primarily PEPPOL BIS Billing 3.0 / UN/CEFACT CII and UBL 2.1)
- Swiss-specific extensions beyond the EN 16931 European baseline — the UID format, Swiss VAT categories, Swiss payment references, and public sector specific fields like budget codes and cost centre references
- Validation rules expressed as Schematron, which complement the XSD structure validation
Version 4 is an evolution from version 3, not a wholesale rewrite. The underlying EN 16931 semantic model is unchanged — the European baseline is stable. The changes in v4 are primarily in the Swiss extensions and in tightening up rules that were ambiguous in practice.
What changed in version 4
Mandatory UID on all invoices to Swiss public sector buyers
In earlier versions, the seller UID (CHE-xxx.xxx.xxx) was required for VAT-registered sellers but technically optional for non-VAT-registered suppliers. Version 4 makes the seller UID mandatory on all invoices submitted to Swiss public sector buyers, regardless of VAT registration status.
The rationale is administrative: federal and cantonal procurement systems use the UID as the primary supplier identifier for vendor master matching and payment processing. An invoice without a UID creates a manual intervention step to identify the supplier. Making it mandatory removes that exception handling path.
For non-VAT-registered suppliers — freelancers with revenue below the CHF 100,000 threshold, for example — this means you need a UID even though you do not use it for VAT purposes. Every Swiss company and self-employed person can obtain a UID from the federal UID register (UID-Register) at no cost. If you supply the federal government and do not yet have a UID, obtaining one is a prerequisite for compliance.
Tighter rules on the OrderReference field
The OrderReference/ID field — where you put the buyer's purchase order number — had loose validation in earlier versions. V4 introduces explicit Schematron rules that enforce:
- The field must be present on invoices to public sector buyers where a purchase order was issued
- The value must match the format specified by the procuring authority (some federal offices use numeric-only PO numbers; others include alphanumeric codes)
- A blank or placeholder value ("N/A", "0", "-") is no longer accepted by v4-compliant validators
In practice, this means your invoicing system must actually carry the PO number from the sales order or customer instruction through to the invoice XML, and must validate that it is present before transmission. Invoices that previously slipped through with a blank PO reference field will be rejected under v4 validation.
New budget code field for cantonal invoicing
Version 4 adds an optional but recommended field for cantonal budget codes (Voranschlagspositionen). Several cantons require this information on invoices to route payment through their budget accounting systems correctly. Without it, the invoice is accepted but requires manual intervention in the cantonal treasury system to assign the payment to the correct budget line.
The field maps to AdditionalDocumentReference with a defined DocumentTypeCode value specific to the Swiss cantonal context. If you invoice cantonal governments, check whether the relevant canton has communicated a required budget code structure — implementing the field now means you are ready rather than having to retrofit it when a canton starts enforcing it.
Updated Swiss VAT code list
Switzerland's standard VAT rate changed from 7.7% to 8.1% in January 2024 (with corresponding changes to the reduced and hospitality rates). Version 4 updates the Swiss VAT code list to reflect the current rates and formally deprecates the pre-2024 rate codes. Invoices using old rate codes (7.7%, 2.5%, 3.7%) will fail v4 Schematron validation.
If your invoicing system still has the old rates in its tax configuration — possible if you were using a system that was not fully updated when the rate change took effect — this is the point at which that gap becomes a validation failure rather than just an inconsistency. Audit your VAT code configuration as part of the v4 migration.
Clarification on credit note document type codes
Earlier versions were ambiguous about which document type code to use for credit notes versus corrective invoices. V4 provides explicit guidance:
- Credit note (Gutschrift): used when the seller is refunding an amount to the buyer — a returned goods credit, a billing error, or a post-delivery price adjustment. Document type code 381.
- Corrective invoice (Korrekturrechnung): used when the original invoice contained an error and is being replaced by a corrected version. The corrective invoice references the original invoice number. Document type code 384.
In practice, many Swiss implementations used 381 for both cases. V4 does not reject 381 for corrective invoices, but the guidance makes clear that 384 is the correct code when an original invoice is being superseded rather than partially credited.
Removal of the fax number field
This is minor but worth noting: the optional sender fax number field, inherited from earlier versions when fax was still a relevant contact channel, has been removed from the data model in v4. Any implementation that populated this field will need to drop it from the output to avoid unexpected behaviour with v4-strict validators.
Migration impact assessment
For most implementations, the migration from v3 to v4 is not a major project. The changes that require actual code or configuration work are:
- UID as mandatory field — if your system had a conditional check on UID presence, change it to unconditional
- VAT rate codes — verify your tax configuration uses the post-January 2024 rates (8.1%, 2.6%, 3.8%)
- PO reference validation — add a pre-send check that the OrderReference field is populated for public sector invoices
- Fax field removal — drop the field from your XML template if it was included
The budget code field and the credit note type code clarification require decisions about implementation rather than code changes: decide whether to implement the cantonal budget code field now or wait, and update your credit note generation logic to use 384 where appropriate.
The updated Schematron validation artefacts for v4 are published on the eCH website and through the SwissDIGIN GitHub repository. Running your existing test invoice set through the v4 Schematron before deploying any changes is the fastest way to identify exactly which rules are failing in your current output. Start there before estimating the migration scope.