Construction billing in Switzerland does not look like invoicing in most other industries. Projects run for months or years, payments are tied to milestones or measured work rather than delivered products, and the invoicing format is shaped by SIA norms that have been standard in the sector for decades. Layering e-invoicing requirements on top of this creates some genuine complexity — but also real efficiency gains for firms that get it right.
This post covers how SIA billing norms work, where they intersect with Swiss e-invoicing standards, and what construction companies need to know if they are required to submit invoices electronically to public sector clients.
What SIA norms govern in construction billing
The Swiss Society of Engineers and Architects (SIA) publishes a set of norms that govern contract types, service descriptions, and billing practices across architecture, engineering, and construction. The two most relevant for invoicing are:
SIA 118 governs contracts for construction work. It defines how progress payments (Abschlagszahlungen) work: a contractor can request payment for work completed to date at agreed intervals, typically monthly. Each payment request is based on a measured valuation of completed work, not on a fixed schedule or percentage. The final invoice is issued once the works are complete and the final measurement is agreed.
SIA 102, 103, 108 and related norms govern service contracts for architects, civil engineers, and specialist engineers. Fees are structured according to defined service phases (Leistungsphasen), from preliminary studies through to project completion and handover. Invoices reference the phase, the agreed fee for that phase, and what percentage has been completed.
In both cases, the invoicing model is fundamentally different from a standard goods or services invoice. There is no single quantity and unit price. Instead, each invoice references a contract, a valuation period or service phase, and a running total of what has been billed versus what has been agreed.
How this creates challenges for structured e-invoicing
Standard e-invoice formats — PEPPOL BIS Billing 3.0, ZUGFeRD, the SwissDIGIN profile — are designed around a fairly universal model: a seller delivers goods or services, lists them as line items, and requests payment. The schema is flexible, but it was not designed with construction progress billing in mind.
The fields that cause friction:
Contract reference. A construction invoice should reference the specific contract it is billing against. PEPPOL BIS supports a ContractDocumentReference field, and you should use it. But the contract reference on its own does not convey the billing model — it does not tell the buyer's system that this is a progress invoice against a longer-running contract.
Cumulative billing. SIA progress invoices typically show both the cumulative value of work to date and the amount being requested in the current invoice (current invoice = cumulative to date minus previously billed). Standard line-item fields can carry this, but it requires a clear mapping decision: do you represent the cumulative amount as the line item total and include previously billed amounts as a negative line? Or do you simply invoice the current period's amount? Both approaches work technically, but your buyer needs to understand which model you are using.
Retentions. Swiss construction contracts commonly include a Garantierückhalt — a retention, typically 5–10% of the contract value, held back by the buyer until the defects liability period expires. This retention needs to appear on invoices so both parties have a clear record of what has been held and when it is due for release. Most e-invoice formats support allowances and charges at the line or document level; map the retention as a document-level charge with a clear description.
Measurement-based line items. Progress invoices reference measured positions (Positionen) from a bill of quantities (Leistungsverzeichnis), each with a unit, quantity, unit price, and total. This maps reasonably well to e-invoice line items if your construction software can export them in a structured format. The practical challenge is that many construction firms use specialist project management software (ORCA, G+H, BRZ) that was not built with PEPPOL or ZUGFeRD export in mind.
The B2G mandate and Swiss federal construction projects
From 2026, suppliers invoicing Swiss federal government bodies are required to submit invoices electronically via eBill or PEPPOL. This directly affects construction firms working on federally funded projects — roads, rail, public buildings, defence infrastructure.
For most construction contracts, PEPPOL is the more practical channel for federal B2G invoicing. Federal procurement is handled through systems like SIMAP and the federal PEPPOL access point, and the invoice format required is the SwissDIGIN PEPPOL profile. This means your project management or ERP software needs to export invoices that are valid PEPPOL BIS Billing 3.0 XML with the SwissDIGIN extensions.
If your current construction software cannot do this natively, the options are:
- Check whether your software vendor has released or planned a PEPPOL export module (many Swiss construction software vendors are working on this for 2025–2026)
- Use a middleware conversion layer that takes your software's export format (often GAEB or proprietary XML) and converts it to PEPPOL BIS
- Work with an e-invoicing service provider that accepts your existing format and handles the conversion and transmission
The step-by-step supplier guide for invoicing federal agencies covers the practical submission process.
VAT considerations specific to construction
Construction invoicing involves a few VAT situations that are worth handling carefully in structured formats:
Partial exemptions. Work on residential properties may be partially exempt from VAT depending on the use of the building. Make sure your invoicing system correctly applies the relevant VAT category codes rather than defaulting to the standard rate on everything.
Self-billing (Gutschriftverfahren). On some large construction projects, the client issues the invoice on behalf of the contractor — a process called self-billing. If you are on the receiving end of self-billing, you need to agree with your client how the structured invoice will be generated and transmitted, since the standard e-invoicing workflow assumes the seller initiates the invoice.
Reverse charge on cross-border subcontracting. If you subcontract work to a foreign firm performing construction services in Switzerland, the reverse charge mechanism applies. The structured invoice from the subcontractor should carry the appropriate tax category code (AE for reverse charge) rather than a Swiss VAT amount. The VAT reverse charge mapping guide covers how to handle this in XML.
Practical steps for construction firms
If you are a Swiss general contractor or engineering firm looking to get compliant with e-invoicing requirements, the realistic path is:
Start by identifying which of your clients are subject to the B2G e-invoicing mandate. Federal clients will require electronic invoices from 2026; some cantonal clients are already requiring them now. These projects should be your priority for getting a PEPPOL-capable workflow in place.
Talk to your construction software vendor now. The gap between what your current software can export and what a valid PEPPOL invoice requires may be smaller than you think — or it may require a planned software update. Better to know before you are mid-project with a federal client asking why invoices are still arriving as PDFs.
For projects that are not subject to the mandate, consider whether ZUGFeRD hybrid invoices are a useful interim step. Your client gets a human-readable PDF that also carries structured XML — no special infrastructure required on their side, but you are already generating structured data that you can route through PEPPOL later.
The SIA billing model is more complex than most standard invoice schemas assume, but it is not incompatible with structured e-invoicing. The fields exist in PEPPOL and ZUGFeRD to represent contracts, retentions, and cumulative billing — they just require deliberate mapping rather than an out-of-the-box template.