When Swiss companies start looking at e-invoicing, the first call they make is usually to their ERP vendor. The response they get varies enormously — from "yes, fully supported, just enable this module" to vague reassurances that something is coming in the next release. Knowing which questions to ask makes the difference between a smooth rollout and a project that stalls six months in when you discover the feature you thought was included is not actually built yet.
Here is a practical set of questions to work through with your ERP or accounting software vendor before you commit to an e-invoicing rollout.
On supported formats and channels
Which e-invoice formats can your system generate, and to what profile level?
There are several formats relevant in Switzerland: PEPPOL BIS Billing 3.0 (with the SwissDIGIN Swiss extension), ZUGFeRD / Factur-X, and the eBill format as delivered through a service provider. Each has multiple profile levels — PEPPOL has the base profile and the Swiss extension, ZUGFeRD has MINIMUM, BASIC, EN 16931, and EXTENDED. Ask for specifics, not just "yes we support PEPPOL." You want to know exactly which version and profile the system outputs.
Can the system receive as well as send structured invoices?
Many ERP vendors have built outbound e-invoicing before inbound. If you also want to automate your accounts payable — receiving structured invoices from suppliers and processing them without manual data entry — ask explicitly whether inbound PEPPOL or ZUGFeRD is supported, and at what level of automation.
Does your system support the SwissDIGIN extension of PEPPOL BIS Billing 3.0?
The SwissDIGIN profile adds Swiss-specific fields: the UID company identifier, Swiss VAT categories, and Swiss payment reference formats. A system that generates generic PEPPOL BIS invoices without the SwissDIGIN extensions will fail validation against the Swiss federal procurement portal and some large Swiss buyers. Ask whether the Swiss extension is supported and whether the validation includes the SwissDIGIN Schematron rules.
Which delivery channels are supported — PEPPOL, eBill, both?
For sending, do you connect directly to a PEPPOL access point, or do you need to route through a third-party intermediary? For eBill, does the system integrate with a biller service provider natively, or do you need to export files and upload them manually? Understanding what is built in versus what requires an additional service provider relationship matters for both implementation complexity and ongoing costs.
On data mapping and field coverage
Which invoice fields are mapped in the standard configuration, and which require customisation?
This is one of the most important questions and the one most likely to get an evasive answer. Ask your vendor to walk through the mandatory fields in a PEPPOL BIS invoice against your current invoice data: seller and buyer identifiers (including UID), purchase order reference, delivery address, VAT breakdown by rate, payment terms and due date, and line-item details. For each field, ask whether it is mapped automatically from your existing ERP data, requires manual entry, or is not supported.
How does the system handle multiple VAT rates on a single invoice?
Swiss invoices can combine items at the standard rate (8.1%), reduced rate (2.6%), and special hospitality rate (3.8%). The structured invoice format requires a separate VAT subtotal per rate. Ask whether the system generates these subtotals correctly from line-item VAT codes, or whether it collapses everything to a single VAT total. The handling of multiple VAT rates is a common gap in older systems.
How are credit notes handled?
Credit notes in PEPPOL and ZUGFeRD are a separate document type with specific rules. Ask whether the system generates technically valid credit notes (correct document type code, reference to the original invoice, negative amounts handled correctly) rather than just negative-value invoices. Some systems generate what looks like a credit note on screen but produces an invalid XML document that fails validation.
Can the system carry a purchase order reference on outbound invoices?
If your customers use purchase orders, the PO reference on the invoice is critical for their automated matching. Ask whether the PO reference is a standard field in the invoice output, where it is sourced from in your ERP (sales order, manual entry), and whether it maps to the correct OrderReference field in the PEPPOL schema rather than being dropped into a free-text remarks field.
On validation
Does the system validate outbound invoices against the relevant Schematron rules before sending?
A system that generates an invoice and sends it without validating it first will discover errors only when the recipient rejects the document. Ask whether the vendor runs Schematron validation — specifically the official PEPPOL BIS and SwissDIGIN validation artefacts — on every outbound invoice, and whether validation failures are surfaced to the user clearly or just logged silently.
How are validation errors reported to users?
A validation error message saying "BT-25 must be present" is not useful to an accounts receivable clerk. Ask how validation errors are presented: do they include a plain-language explanation of what is wrong and how to fix it? Is there a way for the user to correct the issue and resend without re-creating the invoice from scratch?
Can you run the validation tool independently against a sample invoice?
Before you sign anything, ask for a test environment and run a sample invoice through their validation pipeline. This is the fastest way to discover whether "we support PEPPOL" means a fully validated, standards-compliant output or a best-effort XML file with no systematic checks.
On the implementation timeline and support
What does a typical implementation take — in weeks and in person-days from your team?
Vendors often quote optimistic timelines. Ask for the median timeline for a company of your size and complexity, not the best-case scenario. Ask what the most common causes of project delay are. The honest answers tell you where the real risks sit — usually in data mapping, master data quality, or customer onboarding, not in the technical integration itself.
What happens when the standard changes?
The SwissDIGIN specification is versioned and updated. PEPPOL BIS Billing 3.0 itself receives periodic updates. When a new version of the standard is published, your system needs to be updated to stay compliant. Ask what the vendor's track record is on standards updates: how quickly after a new specification version is published does the system support it? Is this included in your maintenance contract or is it a separate paid upgrade?
Who is responsible for the PEPPOL access point connection?
If your ERP vendor offers PEPPOL connectivity, they typically either run their own access point or resell access through a partner. Ask which it is. If they use a partner access point, ask who it is, what the SLA is, and what happens to your invoicing if the access point has an outage. Knowing the dependency chain matters for your own business continuity planning.
What does your support process look like when an invoice is rejected by a recipient?
Invoice rejections happen — wrong format, validation failure, recipient not found in the PEPPOL directory. Ask how the system surfaces rejection notifications, how quickly, and what support the vendor provides to diagnose and resolve the underlying problem. A rejection that sits unnoticed for three days is a payment delay you did not plan for.
A note on "roadmap" answers
If a vendor answers "yes, that's on our roadmap" to more than two or three of these questions, be cautious. Roadmap items that have not yet been scoped or scheduled are not a reliable basis for an e-invoicing project. Either get a contractual commitment with a delivery date, or factor the missing functionality into your project plan as a risk. The open-source vs commercial e-invoicing solutions comparison is worth reading if you are weighing up whether to complement your ERP with a specialist tool while waiting for your vendor's roadmap to catch up.