Connecting your ERP to eBill is not a weekend project, but it is not a six-month infrastructure overhaul either. For most Swiss companies the realistic timeline is four to eight weeks from first contact with a service provider to live invoices reaching customers. What stretches it out is usually incomplete data, internal sign-off processes, or underestimating the testing phase — not the technology itself.
Here is what the integration actually involves, step by step.
How eBill connectivity works
You do not connect your ERP directly to SIX and the eBill network. You connect through a certified eBill service provider — sometimes called a biller service provider or BSP. The service provider handles the eBill protocol, network connectivity, and regulatory requirements. Your job is to get invoice data from your ERP to the service provider in a format they can accept.
This two-layer setup means your integration work is mainly about building a reliable data feed from your ERP to the service provider's API or file exchange. The service provider handles the rest.
There are around fifteen certified eBill service providers in Switzerland, including accounting software vendors like Abacus, Sage, and SAP Switzerland, as well as independent intermediaries. Choosing the right one depends on your ERP, your invoice volume, and how much of the data mapping you want to handle yourself versus delegate. The eBill service providers overview covers the main options.
Step 1: Assess your invoice data quality
Before you touch any integration, export a sample of fifty to a hundred recent invoices from your ERP and look at the data fields. You need to establish whether what your ERP holds is clean enough to generate valid eBill invoices.
The fields that cause the most problems at this stage:
Customer eBill registration status. eBill only delivers invoices to payers who have registered with eBill through their bank. Before sending, you need to check whether each customer has an active eBill account. The service provider API provides a lookup endpoint — you submit a customer identifier (typically IBAN or email) and get back their registration status. You will need to build this lookup into your send workflow or run it as a batch check before each billing cycle.
Creditor IBAN. Your payment IBAN must be registered with your service provider. If you use multiple bank accounts for different business units or currencies, each needs separate registration.
Invoice line items. eBill invoices can carry line-item detail. If your ERP stores items in a structure that maps cleanly to the eBill schema — description, quantity, unit price, VAT rate per line — this is straightforward. If your ERP produces summary invoices without line-item detail, check with your service provider whether that is supported. Most accept them, but the data mapping differs slightly.
Customer identifiers. eBill uses the customer's e-banking login to route invoices to the right payer. Your service provider will ask you to supply a customer identifier — either the customer's IBAN, their eBill participant ID, or sometimes their email address. This needs to be stored against each customer record in your ERP. If your customer master does not currently hold this information, collecting it becomes a prerequisite.
Step 2: Choose your integration method
Service providers typically offer three integration models. Which one fits depends on your ERP and your technical resources.
Direct API integration. Your ERP or a middleware layer calls the service provider's REST or SOAP API each time an invoice is generated. This gives real-time delivery and enables automated status feedback — you can retrieve delivery confirmations and rejection notifications and update invoice status in your ERP automatically. It requires development work but produces the cleanest operational result.
File-based exchange via SFTP. Your ERP exports invoices as structured files — usually XML or CSV in a provider-specified format — to a secure file transfer location. The provider picks them up on a schedule, typically every hour or a few times per day. Status feedback arrives as response files on the same SFTP location. This is simpler to implement and works well for batch billing cycles.
Provider portal. For low volumes, most service providers offer a web portal where you can upload invoice files or enter data manually. This is not a real ERP integration, but it is a practical way to start sending eBill invoices while a proper integration is being built.
Most mid-sized companies start with file-based exchange because it requires minimal changes to the ERP and can be implemented without deep API development. API integration becomes worthwhile when volume grows or when real-time status feedback matters operationally.
Step 3: Map your ERP data to the eBill format
The eBill invoice schema is defined by SIX and your service provider will give you documentation for their specific implementation. The core fields are straightforward — invoice number, date, due date, creditor details, debtor identifier, line items, totals, VAT breakdown — but there are always mapping decisions to work through.
Things that commonly require explicit decisions:
VAT treatment. How does your ERP store VAT? As a percentage per line, as a total amount, or both? eBill invoices need the rate and the calculated amount per tax category. If your ERP only stores a total VAT figure, you may need to calculate the per-category breakdown during the mapping step.
Currency. eBill primarily handles CHF. If you invoice in EUR or other currencies, check with your service provider how this is handled — some support multi-currency, others require a separate process.
Payment reference. The reference you put on the invoice needs to match what will appear in the camt.054 notification when the customer pays. If you use QR references for automated reconciliation, make sure the same reference is encoded in the eBill invoice and in any QR payment section you include.
PDF attachment. eBill supports attaching a PDF of the invoice alongside the structured data. Many companies include one so the customer sees a familiar-looking invoice inside their e-banking. Check whether your service provider generates the PDF or whether you need to supply it.
Step 4: Testing
Service providers give you access to a test environment before go-live. Use it properly. Running two or three happy-path tests and declaring the integration ready is a common mistake. The test cases worth covering:
- Invoice to a registered eBill customer — confirm delivery and status callback
- Invoice to a customer who is not registered — confirm correct rejection handling
- Invoice with zero VAT (export or non-taxable services)
- Invoice with multiple VAT rates on separate line items
- Credit note
- Invoice with a long customer name or address (test field length limits)
- Duplicate invoice number — confirm the system rejects or flags it
Status callbacks deserve particular attention. When eBill delivers an invoice, the payer can accept it, reject it, or let it expire. Your ERP needs to handle all three outcomes. Rejected invoices need to trigger a process — someone needs to be notified and the invoice corrected and resubmitted. If your integration silently discards rejection notifications, you will have unpaid invoices with no visibility into why.
Step 5: Onboarding your customers
Technical integration is the easier half. Getting customers to register with eBill and elect to receive your invoices through the platform takes longer.
For business customers, this usually means contacting your accounts receivable contacts and asking them to register for eBill through their bank. Most major Swiss banks have a straightforward registration process, and many larger companies are already on the network.
For consumer customers, the standard approach is to include a prompt on paper invoices and email communications: "Register for eBill at your bank to receive future invoices directly in your e-banking." The eBill network technical overview covers the registration flow from the payer's side in more detail.
Add a tracking field in your CRM or ERP to record whether each customer is eBill-registered. This lets you route invoices automatically once the integration is live — eBill for registered customers, paper or email PDF for everyone else — without manual routing decisions each billing cycle.
What tends to go wrong after go-live
The post-launch issues that come up most often:
Customers do not notice or approve invoices sitting in their e-banking, especially in the first weeks when the channel is unfamiliar. If your payment terms are 30 days, it is worth building a reminder trigger: if an invoice has not been approved after 10 to 15 days, send a courtesy nudge by email.
Rejection notifications go unmonitored because nobody was assigned to watch the feedback channel. Assign ownership of the eBill status queue to a specific person from day one.
Customer registration lapses. If a customer switches banks, their eBill registration may become inactive without notice. Your send workflow should re-check registration status periodically and fall back to an alternative delivery channel when registration is no longer active.
None of these are technical problems — they are process gaps. The integration is the straightforward part. Building the operational habits around it is what determines whether eBill genuinely improves your billing cycle or just adds another channel nobody monitors.