[{"data":1,"prerenderedAt":182},["ShallowReactive",2],{"\u002Fblog\u002Fhow-the-ebill-network-works-a-technical-overview":3},{"id":4,"title":5,"body":6,"description":173,"extension":174,"lastUpdatedAt":175,"meta":176,"navigation":177,"path":178,"publishedAt":175,"seo":179,"stem":180,"__hash__":181},"blog\u002Fblog\u002F0042.how-the-ebill-network-works-a-technical-overview.md","How the eBill network works: a technical overview",{"type":7,"value":8,"toc":162},"minimark",[9,13,18,21,28,40,46,52,55,59,62,93,96,100,103,106,109,113,116,119,127,131,134,137,141,144,147,151,154],[10,11,12],"p",{},"eBill is not a single application — it is a network. When a biller sends an invoice and a payer approves it from inside their e-banking, several separate systems are talking to each other behind the scenes. Understanding the architecture helps if you are evaluating an eBill integration, troubleshooting a delivery issue, or just trying to understand why the network behaves the way it does.",[14,15,17],"h2",{"id":16},"the-four-roles-in-the-ebill-network","The four roles in the eBill network",[10,19,20],{},"Every eBill transaction involves four distinct parties:",[10,22,23,27],{},[24,25,26],"strong",{},"The biller"," is the company sending the invoice. Billers do not connect to SIX directly — they connect through a service provider. A biller can be a large utility sending millions of invoices per month or a sole trader sending a few dozen.",[10,29,30,33,34,39],{},[24,31,32],{},"The biller service provider (BSP)"," receives invoices from the biller, converts them into the eBill format, and delivers them to SIX. BSPs also handle biller registration, reporting, and in many cases provide the portal or API integration that the biller uses to submit invoices. There are around a dozen BSPs in Switzerland, mostly banks, postal finance, and specialist fintech companies. The ",[35,36,38],"a",{"href":37},"\u002Fblog\u002Febill-service-providers-in-switzerland-an-overview","overview of eBill service providers"," lists the active ones.",[10,41,42,45],{},[24,43,44],{},"SIX"," operates the central eBill infrastructure. SIX does not hold the invoice data permanently — it routes messages between BSPs and financial institutions, maintains the payer registry (which IDs are registered and with which bank), and enforces network rules.",[10,47,48,51],{},[24,49,50],{},"The financial institution (FI)"," is the payer's bank. The FI receives invoice notifications from SIX, makes them available inside the payer's e-banking interface, and sends back the payer's approval or rejection decision.",[10,53,54],{},"The payer — the person or company receiving and paying the invoice — interacts only with their bank's e-banking. From their point of view, an invoice just appears in their banking app.",[14,56,58],{"id":57},"message-flow-step-by-step","Message flow step by step",[10,60,61],{},"When a biller submits an invoice, this is what happens:",[63,64,65,69,72,75,78,81,84,87,90],"ol",{},[66,67,68],"li",{},"The biller sends invoice data to their BSP — either via API, SFTP, or a web portal depending on the BSP's integration options.",[66,70,71],{},"The BSP validates the invoice data, converts it to the eBill network format, and forwards it to SIX.",[66,73,74],{},"SIX looks up the payer in the registry. The registry maps each payer's identifier (typically their e-banking login or a UID) to their financial institution. If the payer is not registered for eBill, SIX returns a negative response to the BSP, which notifies the biller.",[66,76,77],{},"SIX routes the invoice to the payer's financial institution.",[66,79,80],{},"The FI stores the invoice and generates a notification — typically an e-banking alert, push notification, or email — telling the payer they have an invoice to review.",[66,82,83],{},"The payer logs into their e-banking, reviews the invoice, and either approves it for payment on a chosen date, rejects it, or defers it.",[66,85,86],{},"The payer's decision (approval, rejection, or deferred) is sent back to SIX.",[66,88,89],{},"SIX forwards the status update to the BSP.",[66,91,92],{},"The BSP passes the status back to the biller. If approved, the biller knows payment will arrive on the specified date. If rejected, the biller receives a rejection reason code.",[10,94,95],{},"The biller never has direct visibility into the payer's e-banking. Everything flows through the BSP and SIX.",[14,97,99],{"id":98},"how-payer-registration-works","How payer registration works",[10,101,102],{},"Before a payer can receive eBill invoices, they must register for eBill within their e-banking. Registration typically takes a few clicks — the payer confirms they want to receive e-invoices and provides the identifier that billers will use to address invoices to them. This identifier is most commonly the payer's e-mail address or UID, though the exact options vary by bank.",[10,104,105],{},"Once registered, the financial institution reports the payer's identifier to SIX, which adds it to the central registry. When a biller tries to deliver an invoice to that identifier, SIX can resolve it to the correct bank.",[10,107,108],{},"This is an important practical point: before sending an eBill invoice to a customer, the biller (or BSP) should query the registry to check whether that customer is registered. Most BSP APIs expose a registration-check endpoint. Sending an invoice to an unregistered payer fails at SIX — the invoice is not queued or held for later.",[14,110,112],{"id":111},"the-underlying-message-format","The underlying message format",[10,114,115],{},"The eBill network messages between SIX and financial institutions are based on ISO 20022. SIX has published its own subset of the standard — the eBill specification defines exactly which fields are used, which are mandatory, and which Swiss-specific extensions apply.",[10,117,118],{},"The invoice payload itself uses a structured XML format that carries the key invoice fields: biller details, payer identifier, invoice number, due date, amount in CHF, line items if provided, and a PDF representation for display in e-banking. Not all billers send line-item detail — for many use cases, the summary fields (total, due date, reference) are sufficient for the payer to recognise and approve the invoice.",[10,120,121,122,126],{},"The QR reference (",[123,124,125],"code",{},"QRR",") from a QR-Rechnung can be embedded in the eBill payload. When the payer approves the invoice, the payment instruction their bank creates will carry the same QR reference, ensuring the biller's payment reconciliation works correctly at the other end. This is the main integration point between the eBill network and the QR-bill infrastructure.",[14,128,130],{"id":129},"what-happens-after-approval","What happens after approval",[10,132,133],{},"When a payer approves an eBill invoice, the instruction does not go directly to the payment clearing system at the moment of approval. The payer specifies a payment date (which can be the due date or any date they choose), and the financial institution schedules a domestic payment for that date. On the execution date, the payment is sent through the Swiss Interbank Clearing (SIC) system as a standard credit transfer.",[10,135,136],{},"The biller's bank account receives the payment in the normal way — there is nothing special about the incoming credit from the biller's bank's perspective. The link between the incoming credit and the original eBill invoice is maintained through the payment reference, not through any special eBill message on the payment leg.",[14,138,140],{"id":139},"rejection-and-error-handling","Rejection and error handling",[10,142,143],{},"If a payer rejects an invoice, the rejection flows back to the biller via the same chain. The rejection includes a reason code — common reasons are \"amount incorrect\", \"invoice already paid\", \"dispute\", or \"unknown invoice\". The biller receives this via their BSP and can follow up with the payer directly.",[10,145,146],{},"If an invoice cannot be delivered because the payer is not registered, the BSP notifies the biller promptly so they can fall back to another delivery channel (paper, email, or a different e-invoicing network). Most production eBill integrations include logic to handle this case gracefully — checking registration before submission rather than waiting for a delivery failure.",[14,148,150],{"id":149},"where-ebill-fits-in-a-broader-invoicing-setup","Where eBill fits in a broader invoicing setup",[10,152,153],{},"eBill is a delivery channel, not an invoice format or a payment standard. You can think of it as structured email for invoices — the difference is that the structured data drives automatic presentation inside e-banking and a direct payment action, rather than just a document that sits in an inbox.",[10,155,156,157,161],{},"For businesses that also need to invoice large B2B customers or public sector buyers through PEPPOL, eBill and PEPPOL coexist without conflict. Many service providers offer both channels through a single integration. The ",[35,158,160],{"href":159},"\u002Fblog\u002Fchoosing-between-ebill-and-peppol-for-your-business","comparison of eBill and PEPPOL"," covers when to use each.",{"title":163,"searchDepth":164,"depth":164,"links":165},"",2,[166,167,168,169,170,171,172],{"id":16,"depth":164,"text":17},{"id":57,"depth":164,"text":58},{"id":98,"depth":164,"text":99},{"id":111,"depth":164,"text":112},{"id":129,"depth":164,"text":130},{"id":139,"depth":164,"text":140},{"id":149,"depth":164,"text":150},"An inside look at the eBill infrastructure — participant registration, message flow, and ISO 20022 underpinnings.","md","2026-10-04",{},true,"\u002Fblog\u002Fhow-the-ebill-network-works-a-technical-overview",{"title":5,"description":173},"blog\u002F0042.how-the-ebill-network-works-a-technical-overview","1orpZNjA1dujBXbYcHgwc7Q-PijikM1xoIhlnAPdo1g",1777105007713]