eBill vs. QR-Rechnung: Posteingang-Workflow für KMU

eBill und die QR-Rechnung sind die zwei dominanten Eingangskanäle in einem Schweizer KMU-Posteingang: eBill ist vollelektronisch und landet über die Bank-Infrastruktur direkt im E-Banking des Bezügers, die QR-Rechnung kommt als PDF oder Papier mit eingebettetem Swiss QR Code ins Mailpostfach oder in die Post. eBill ist seit 2018 verfügbar — eBill — Im Auftrag des Finanzplatzes Schweiz, eine Initiative von SIX im Auftrag des Finanzplatzes Schweiz; rund 95 Prozent der Schweizer Finanzinstitute sind an die eBill-Infrastruktur angeschlossen. Die QR-Rechnung wiederum ist seit dem 30. September 2022 obligatorischer Schweizer Zahlungsstandard, nach der finalen Ablösung der orangen und roten Einzahlungsscheine.

Die in der SERP häufige Frage „eBill vs QR-Rechnung — was nutzen?" ist aus AP-Empfänger-Sicht falsch gestellt. Wer Lieferantenrechnungen erhält, hat keine Wahl zwischen den beiden Kanälen, sondern bekommt beide parallel: eBill-Notifikationen von Telekommunikationsanbietern, Versicherungen, Versorgern und der SBB im E-Banking, QR-Rechnungen als PDF von kleineren bis mittleren Lieferanten, dazu einen Restanteil reines PDF oder Papier ohne QR von ausländischen Lieferanten und Altverträgen. Die zwei Schweizer Kanäle sind komplementär, nicht konkurrierend — die Frage ist nicht welcher gewinnt, sondern wie der AP-Posteingang sie zusammenführt.

Wer Format-Tiefe sucht, findet sie in zwei separaten Stücken: das eBill-Format inklusive Peppol- und B2G-Kontext steht in Swiss e-invoicing: eBill, Peppol und B2G im Detail, die Datenfelder und technischen Anforderungen der QR-Rechnung in Swiss QR-Bill: Datenfelder und Anforderungen für AP-Teams. Hier geht es nicht um das Format, sondern um den Workflow: ein ehrlicher Vergleich der zwei Kanäle, die Aktivierung pro Bank und Buchhaltungssoftware, der integrierte Posteingang für den Mischeingang aus eBill, QR-Rechnung und Restpapier, und am Schluss eine Mengenheuristik, die zur Lieferantenstamm-Grösse des einzelnen KMU passt.

Vergleich auf einen Blick: eBill und QR-Rechnung im AP-Posteingang

Die folgende Tabelle ist als Entscheidungsraster gedacht, nicht als Pro-Contra-Werbevergleich. Beide Kanäle haben für KMU-Empfänger ehrliche Schwächen, und die Wahl ist meistens keine Wahl, sondern eine Frage der gleichzeitigen Verarbeitung.

Aspekt	eBill	QR-Rechnung
Datenträger	Vollelektronisch via Bank- und SIX-Infrastruktur	PDF oder Papier mit eingebettetem Swiss QR Code
Empfänger-Aktion	Im E-Banking freigeben oder über die Banking-Integration der Buchhaltungssoftware ziehen	PDF in den Buchhaltungs-Posteingang importieren oder Papierbeleg scannen
Datenstrukturierung	Vollständig strukturiert, inklusive Positionen	Zahlungsdaten strukturiert im QR-Code, Rechnungs-Body unstrukturiert
Eingangs-Zeit	Sofort, digitaler Push	E-Mail-Eingangszeit oder Postlaufzeit
Lieferanten-Adoption	Hoch bei Telekommunikation, Versicherung, Versorgern, SBB und grösseren Cloud-Anbietern; mittlere bis niedrige Adoption bei kleinen und mittleren KMU-Lieferanten	Universell, Standard seit 2022
Empfänger-Adoption	Hochschwellig: einmalige eBill-Aktivierung pro Bank, anschliessend Anmeldung pro Lieferant	Niederschwellig: jeder, der eine QR-Rechnung lesen kann
Format-Konsistenz	Hoch, weil das SIX-Format vereinheitlicht ist	Mittel: QR-Code standardisiert, das übrige PDF-Layout je Lieferant unterschiedlich
Zahlungs-Auslösung	Direkt aus dem E-Banking nach Freigabe	Manuell oder via Buchhaltungs-Zahllauf
Empfangs-Kosten	Bank-abhängig, oft kostenlos für Geschäftskunden	Keine direkten Empfangs-Kosten
Reverse-Workflow	Im E-Banking ablehnen, der Lieferant erhält eine strukturierte Notification	Per E-Mail oder Telefon mit dem Lieferant klären

Zwei Zeilen lohnen die separate Aufmerksamkeit, weil sie in den meisten SERP-Quellen unterbeleuchtet sind. Die Empfänger-Adoption ist beim eBill-Kanal hochschwellig: ein einmaliger Aktivierungsschritt pro Bank, dann eine Anmeldung pro Lieferant — beides Aufwand, der bei der QR-Rechnung schlicht entfällt, weil jedes PDF und jeder Papierbeleg ohne Vorbedingung gelesen werden kann. Und die Datenstrukturierung trennt die zwei Kanäle in der Buchhaltung sichtbarer als jedes andere Merkmal: eBill liefert den vollständigen Buchungssatz inklusive Positionen, die QR-Rechnung nur die Zahlungsdaten — Lieferant, Positionen und MWST-Aufschlüsselung müssen aus dem Rechnungs-Body gelesen werden. Genau dieser Unterschied erklärt, warum der Tagesposteingang eine Pipeline braucht, die die Strukturierungs-Differenz aktiv auffängt — nicht nur eine Importschiene.

eBill-Empfang aktivieren: Was pro Bank zu tun ist

Die Aktivierung folgt bei jeder Schweizer Bank dem gleichen zweistufigen Aufbau. Im ersten Schritt wird eBill einmalig im E-Banking aktiviert: der Geschäftskunde öffnet einen Bereich, der je nach Bank "eBill", "E-Rechnungen" oder eine vergleichbare Bezeichnung trägt, und legt dort ein Bezüger-Profil an — der eBill-spezifische Begriff für das Empfänger-Profil, an das die SIX-Infrastruktur künftige Rechnungen ausliefert. Im zweiten Schritt erfolgt für jeden Lieferanten, von dem man künftig eBill-Rechnungen empfangen will, eine Anmeldung: der Empfänger sucht den Lieferanten im eBill-Verzeichnis seiner Bank, reicht die Anmeldung ein, und der Lieferant bestätigt sie einmalig. Erst danach fliesst die nächste Rechnung dieses Lieferanten als eBill statt als QR-Rechnung in den Posteingang.

Bei den fünf Banken, die zusammen den grössten Teil der Schweizer KMU-Konten abdecken, sieht der Pfad so aus:

• UBS: im UBS E-Banking den Bereich eBill aufrufen, das Bezüger-Profil erstellen und anschliessend einzelne Lieferanten freischalten.
• ZKB: das eBill-Modul im E-Banking oder in Z-Connect aktivieren und pro Lieferant eine Anmeldung erfassen.
• PostFinance: die Aktivierung erfolgt nicht im E-Banking, sondern in E-Finance — der PostFinance-spezifische Begriff für das eigene Banking-Portal — über den eBill-Service. Die Anmeldung pro Lieferant funktioniert analog zu den anderen Banken.
• Raiffeisen: im Raiffeisen-E-Banking die eBill-Sektion aufrufen, aktivieren und pro Lieferant anmelden.
• Kantonalbanken: BCV, BCGE, LUKB und die übrigen Kantonalinstitute pflegen jeweils eigene UI-Pfade. Das Vorgehen bleibt das gleiche zweistufige Muster — Bezüger-Profil und Anmeldung pro Lieferant.

Bank-UIs ändern sich periodisch; konkrete Klick-Sequenzen veralten schnell. Jede der genannten Banken pflegt eine eigene Hilfeseite zur eBill-Aktivierung, auf der die aktuell gültigen Pfade dokumentiert sind. Der schnellste Weg, wenn der Bereich nicht auf den ersten Blick erscheint, ist die Suche nach "eBill" oder "E-Rechnungen" innerhalb des E-Bankings oder in der Hilfe der jeweiligen Bank.

In der Lieferanten-Kommunikation und in der Bank-Dokumentation taucht regelmässig der Begriff Netzwerkpartner auf. Dahinter steht der Service-Provider, der zwischen dem Lieferanten und der SIX-Infrastruktur sitzt und die Rechnung technisch ins eBill-System einliefert. Der Empfänger muss diesen Partner nicht kennen oder auswählen — die Rechnung erscheint nach der Anmeldung im richtigen Bezüger-Profil, unabhängig davon, welchen Netzwerkpartner der Lieferant benutzt.

Die Anmeldung pro Lieferant ist der Schritt, an dem die meisten Aktivierungs-Projekte hängen bleiben. Praktisch lässt sich das gut in einem Rutsch erledigen: einmal die Liste der wiederkehrenden Lieferanten aus der Buchhaltung ziehen, im eBill-Bereich der Bank die anbietenden Lieferanten suchen und nacheinander anmelden. Eine Initialaktivierung über zwanzig oder dreissig Lieferanten dauert je nach Bank-UI dreissig bis sechzig Minuten und muss danach nur noch für neue eBill-Lieferanten ergänzt werden.

Geschäftskunden mit mehreren Bankverbindungen sollten beachten, dass die eBill-Aktivierung pro Bank erforderlich ist — das Bezüger-Profil ist nicht bank-übergreifend. In der Praxis bündeln die meisten KMU den eBill-Empfang auf der Hausbank, weil die parallele Pflege mehrerer Bezüger-Profile die Übersicht im Posteingang zerlegt. Wenn ein Lieferant nur an ein bestimmtes Bezüger-Profil ausliefern soll, geschieht das durch die Anmeldung bei genau einer der Banken; die anderen bleiben für diesen Lieferanten ausgeblendet.

eBill in Bexio, Abacus, Banana, Crésus und Topal

Die Buchhaltungssoftware bestimmt, ob eBill-Rechnungen direkt im Buchhaltungs-Posteingang erscheinen oder ob ein Zwischenschritt über das E-Banking nötig bleibt. Direkte eBill-Integration heisst: die Software hat eine eigene Banking- und eBill-Schnittstelle, und die strukturierte Rechnung kommt ohne Umweg im Posteingang der Software an. Indirekte Integration heisst: der Empfang läuft weiterhin über das E-Banking, und die Rechnung muss als PDF oder als Datensatz in die Buchhaltung gebracht werden — manuell, per Bankschnittstellen-Export oder über einen separaten Import-Schritt.

Bexio bietet die direkte eBill-Integration über das Banking-Modul. eBill-Rechnungen erscheinen im Bexio-Posteingang, ohne dass der Buchhalter ins E-Banking wechseln muss; die strukturierten Daten fliessen unmittelbar in den Buchungssatz-Vorschlag, sodass nur Konto- und Kostenstellen-Zuordnung in der Review-Schicht zu prüfen sind. Wer den Bexio-Posteingang als zentrale Anlaufstelle für sämtliche Lieferantenrechnungen nutzt, findet die operative Logik in Bexio-Posteingang für Lieferantenrechnungen automatisch importieren.

Abacus integriert eBill über die Abacus-Banking-Module. Der Empfang ist Teil der Abacus-Banking-Integration und mündet direkt im AP-Posteingang der Kreditorenbuchhaltung. Strukturell verhält sich der eBill-Stream identisch zur Bexio-Logik: der Buchungssatz-Vorschlag entsteht aus den vom SIX-Format gelieferten Feldern, ohne dass die Rechnung über E-Banking-Export laufen muss. Die Treuhand- und Mandatslogik rund um AbaScan und AbaWebTreuhand für den Mischeingang aus eBill und gescanntem QR-Beleg ist separat in Abacus-Kreditorenbuchhaltung mit AbaScan und AbaWebTreuhand automatisieren beschrieben.

Banana kennt keine direkte eBill-Anbindung. eBill-Rechnungen kommen weiterhin im E-Banking der Hausbank an; der Buchhalter exportiert manuell als PDF oder als Datensatz und importiert ihn anschliessend in Banana. Der eBill-Stream verhält sich in Banana damit faktisch wie ein QR-Rechnungs-Stream mit einer zusätzlichen Quelle, weil die Datei den Träger zwischen E-Banking und Buchhaltung wechselt. Wer die Standard-Import-Wege für Belege und Bankauszüge in Banana sauber aufsetzt, findet die Details in Belege und Bankauszüge in Banana Buchhaltung importieren.

Crésus bewegt sich in der gleichen Logik wie Banana: keine direkte eBill-Schnittstelle, der Empfang verbleibt im E-Banking, und die Übergabe an Crésus erfolgt manuell oder über die Bankschnittstellen-Exporte, die das Programm für den Zahlungsverkehr ohnehin nutzt. Für Crésus-Anwender ist eBill damit ein zweiter Posteingang neben der Buchhaltung, nicht ein integrierter.

Topal stellt eine direkte eBill-Anbindung bereit. Der Empfang erfolgt strukturiert in den Buchhaltungs-Posteingang, ähnlich wie bei Bexio und Abacus.

Bei direkter Integration übernimmt die Software das Bezüger-Profil aus der Bank-Aktivierung und lässt die Rechnung im strukturierten Format ankommen; bei indirekter Integration bleibt das Bezüger-Profil bei der Bank, und nur die Datei oder der exportierte Datensatz wechselt den Träger. Worauf die Software-Wahl in jedem Fall keinen Einfluss hat: die zwei Aktivierungsschritte aus dem vorigen Abschnitt — eBill bei der Hausbank einmalig aktivieren, dann pro Lieferant anmelden — sind die Voraussetzung dafür, dass irgendeine Software überhaupt etwas zu importieren bekommt. Auch Bexio, Abacus und Topal erhalten erst dann eBill-Rechnungen, wenn das Bezüger-Profil bei der Bank steht und die Anmeldung pro Lieferant erfolgt ist.

Die Konsequenz für den Tagesposteingang fällt deutlich aus. Bei direkter Integration ist der eBill-Stream bereits in der Buchhaltung, und der Buchhalter sieht alle Lieferantenrechnungen — eBill und QR-Rechnung — in einem einzigen Posteingang. Bei indirekter Integration entsteht ein zweiter Posteingang im E-Banking, der zusätzlich zum Buchhaltungs-Posteingang täglich oder wöchentlich konsolidiert werden muss. Diese organisatorische Differenz wirkt sich stärker aus als jede technische Detail-Spezifikation der einzelnen Software, weil sie bestimmt, wie viele parallele Posteingänge das AP-Team überhaupt bewirtschaftet.

Der integrierte Posteingang: eBill, QR-Rechnung und Restbelege in einer Buchungs-Pipeline

Ein realistischer Schweizer KMU-Posteingang besteht aus drei Streams, die parallel ins AP-Team einlaufen. Erstens: eBill-Notifikationen — entweder direkt in der Buchhaltungssoftware bei Bexio, Abacus oder Topal, oder im E-Banking bei Banana und Crésus. Zweitens: QR-Rechnungen als PDF-Anhang im Mailpostfach oder als Papier per Post, vorwiegend von kleineren bis mittleren Schweizer Lieferanten. Drittens: ein Restanteil reines PDF oder Papier ohne QR — überwiegend ausländische Lieferanten, Altverträge und Privatpersonen-Rechnungen. Dieser gemischte Posteingang aus eBill, QR-Rechnung und Papier ist der Normalfall, nicht eine Übergangsphase auf dem Weg zu einem reinen eBill-Eingang.

Stream 1, eBill. Der Eingang erfolgt entweder über die Banking-Integration der Buchhaltungssoftware oder durch manuelle Übernahme aus dem E-Banking. Die Daten sind vollständig strukturiert: Lieferant, Rechnungsdatum, Positionen, Netto, MWST und Total liegen in den vom SIX-Format vorgegebenen Feldern. Sie fliessen direkt in den Buchungssatz-Vorschlag, und die Review-Schicht beschränkt sich auf die Konto- und Kostenstellen-Zuordnung. Vollautomatik-Anteil bei reinem eBill: rund 90 bis 95 Prozent. Den verbleibenden Anteil verursacht in der Regel die individuelle Kontierung wiederkehrender Rechnungen, nicht die Datenerfassung selbst.

Stream 2, QR-Rechnung. Das PDF kommt per E-Mail in den Buchhaltungs-Posteingang oder wird in einen Drop-Ordner gelegt, den die Buchhaltungssoftware überwacht. Der QR-Code liefert die Zahlungsdaten strukturiert — IBAN, Betrag, Referenz, Empfänger — aber der Rechnungs-Body bleibt unstrukturiert. Lieferantenname, Rechnungsdatum, Positionen und vor allem die MWST-Aufschlüsselung müssen aus dem PDF gelesen werden, weil sie nicht im QR-Code stehen. Eine Belegerkennungs-Schicht extrahiert diese Felder, sodass Teams QR-Rechnungen strukturiert scannen und buchen können und das Ergebnis zusammen mit den QR-Daten in den Buchungssatz-Vorschlag fliesst. Vollautomatik-Anteil bei reiner QR-Rechnung: rund 60 bis 80 Prozent, weil die strukturierten QR-Daten nur einen Teil des Buchungssatzes abdecken und die übrigen Felder pro Lieferanten-Layout unterschiedlich liegen.

Stream 3, Papier oder PDF ohne QR. Papierbelege werden wöchentlich gesammelt und gescannt, PDFs ohne QR per E-Mail-Forwarding in den Buchhaltungs-Posteingang gelegt. Hier deckt der QR-Code nichts ab; die Belegerkennung muss das gesamte Dokument lesen. Der Buchungssatz-Vorschlag entsteht vollständig aus dem erkannten Inhalt, und die Review-Schicht ist entsprechend grösser. Vollautomatik-Anteil: rund 30 bis 60 Prozent, je nach Dokumenten-Qualität — gescannte Originale liegen am oberen Ende, Mobiltelefon-Fotos und Mehrfach-Kopien am unteren.

Eine vierte Kategorie sind Auslandsrechnungen mit fremden Zahlungsformaten oder aus Sondermärkten, deren Datenpunkte nicht zur Schweizer Buchungslogik passen — andere Steuersysteme, Fremdwährungen ohne Wechselkurs-Stempel, Lieferanten ohne MWST-Nummer. Diese Belege gehen an die manuelle Erfassung. Der Anteil sinkt mit klarer Lieferanten-Kommunikation, fällt aber selten auf null.

Die drei Streams unterscheiden sich in der Eingangs-Strukturierung erheblich, und genau hier entscheidet sich, ob der AP-Posteingang wirklich integriert ist oder nur scheinbar. eBill liefert bereits strukturierte Daten und braucht keine externe Erkennung — das ist der Punkt, an dem das Argument umkippt: für die zwei nicht-eBill-Streams ist eine Belegerkennungs- und Strukturierungsschicht nötig, die QR-Rechnungen und Restpapier in das gleiche Buchungssatz-Format bringt wie der eBill-Stream. Genau dieser Gleichschritt — Belegerkennung als einheitliche Output-Schicht für gemischten Schweizer Posteingang — macht aus drei Streams eine Pipeline.

In der Praxis lässt sich das mit unserer Software so umsetzen: PDF- oder Bilddateien (gescannte Papierbelege wie auch QR-Rechnungs-PDFs) werden hochgeladen, der Nutzer beschreibt in einem Prompt das gewünschte Output-Format — etwa Lieferant, Rechnungsdatum, Netto, MWST, Total, optional Positionen, mit Spaltennamen und Datenformaten, die zur Buchhaltung passen — und das Ergebnis ist eine strukturierte Excel-, CSV- oder JSON-Datei, die in Bexio, Abacus oder ein anderes Buchhaltungspaket importiert werden kann. Derselbe Prompt liefert für hundert Lieferanten-Layouts denselben Spaltenaufbau, sodass die QR-Rechnungs- und die Restpapier-Streams nach der Verarbeitung dasselbe Datenschema haben wie der bereits strukturierte eBill-Stream — eine einheitliche Output-Schicht über alle drei Eingänge. Wer Lieferantenrechnungen erfasst, bekommt damit ein konstantes Buchungssatz-Format, unabhängig davon, ob die Rechnung als eBill, als QR-PDF oder als gescannter Restbeleg eintrifft.

Was am Ende dieser Pipeline steht, hat eine konkrete Konsequenz für die AP-Steuerung: pro Lieferantenrechnung ein vergleichbarer Buchungssatz-Vorschlag, unabhängig vom Eingangsformat. Das ist die Voraussetzung für reproduzierbare Auto-Buchung in der Buchhaltungssoftware, für saubere Audit-Spuren und für eine konsistente MWST-Aufschlüsselung über sämtliche Lieferanten hinweg — und damit für eine Buchhaltung, die nicht je nach Eingangskanal anders aussieht.

Adoptions-Realität: Wann eBill sich für ein KMU wirklich lohnt

Die Schweizer eBill-Adoption ist ungleich verteilt, und die Verteilung ist nicht zufällig. Hoch ist sie dort, wo ein KMU ohnehin wiederkehrende, standardisierte Rechnungen erhält — Telekommunikation, Versicherungen, Versorger für Strom, Gas und Wasser, grössere Cloud- und Software-Lieferanten, sowie SBB. Diese Lieferanten haben das Volumen und die Standard-Prozesse, um eBill auf der Sender-Seite produktiv zu betreiben, und sie nutzen den Kanal entsprechend aktiv. Mittel bis niedrig bleibt die Adoption bei kleinen und mittleren Schweizer KMU-Lieferanten, die weiterhin QR-Rechnungen als PDF oder Papier verschicken — und das wird auch in den nächsten Jahren der Normalfall bleiben, weil die Kostenrechnung für eBill-Versand bei niedrigem Rechnungsvolumen nicht aufgeht.

Daraus folgt der Honest Gap, den die Bank- und SIX-Kommunikation selten so direkt benennt: eBill löst den Posteingang nicht abschliessend. Damit eine Rechnung als eBill ankommt, müssen drei Bedingungen gleichzeitig erfüllt sein. Der Lieferant muss eBill anbieten und im SIX-Verzeichnis publiziert sein. Der Empfänger muss aktiv pro Lieferant anmelden. Und die Hausbank muss in der eBill-Infrastruktur sein. Solange einer dieser drei Punkte fehlt — und das ist der häufige Fall — läuft die Rechnung als QR-Rechnung oder als Restbeleg in den Posteingang. Das ist kein Übergangs-Defekt, sondern die strukturelle Bedingung des Kanals.

Daraus lässt sich eine Mengenheuristik ableiten, die zur Lieferantenstamm-Grösse passt:

• Kleiner Lieferantenstamm, unter zwanzig Lieferanten. Der einmalige Aktivierungs- und Anmeldeaufwand pro Lieferant amortisiert sich schnell. Die zeitliche Ersparnis pro Rechnung — kein PDF-Handling, strukturierte Daten direkt im Buchungssatz, weniger Review — übersteigt den einmaligen Anmeldeaufwand bereits nach wenigen Eingängen. Hier lohnt eBill für jeden Lieferanten, der den Kanal anbietet.
• Mittlerer Stamm, etwa zwanzig bis zweihundert Lieferanten. Der Schwerpunkt liegt auf den wiederkehrenden Lieferanten — Telco, Versicherungen, Versorger, SBB, grössere Cloud-Anbieter. Bei einmaligen oder kleinvolumigen Lieferanten lohnt sich die Anmeldung selten, weil der eBill-Vorteil bei einer einzigen Rechnung nicht den Anmeldungs-Aufwand wettmacht. Die Faustregel: anmelden, sobald ein Lieferant im Jahr drei oder mehr Rechnungen schickt.
• Breiter Stamm, über zweihundert Lieferanten. Die Anmeldung pro Lieferant skaliert nicht. Der Posteingang braucht ohnehin eine QR-Rechnungs- und Belegerkennungs-Pipeline, weil die Mehrzahl der Lieferanten weiterhin nur QR-Rechnung anbietet. eBill bleibt in diesem Segment eine Nische für die wenigen Top-Lieferanten, deren Volumen den Anmeldungs-Aufwand klar rechtfertigt — Telco-Sammelrechnungen, Energieversorger, grosse Cloud-Plattformen. Das Zentrum der Posteingangs-Automatisierung liegt hier nicht bei eBill, sondern bei der Verarbeitung des QR-Rechnungs- und Restbeleg-Stroms.

Die Adoptions-Realität für Schweizer KMU ist damit weder eine eBill-Erfolgsgeschichte noch ein Argument gegen den Kanal — sie ist eine Verteilung, die jedes Unternehmen für seinen eigenen Lieferantenstamm liest und in eine konkrete Setup-Entscheidung übersetzt. Auch Treuhand-Mandate folgen derselben Logik: bei Kleinmandaten mit zwanzig Lieferanten sind die wenigen eBill-fähigen Stammlieferanten schnell aktiviert; bei grösseren Mandaten ist der eBill-Workflow Schweiz ein Teil-Strom neben einer voll ausgebauten QR- und Belegerkennungs-Pipeline.

Für die meisten Schweizer KMU bedeutet das eine dreigleisige Empfehlung: eBill dort aktivieren, wo es verfügbar und nach der Mengenheuristik sinnvoll ist; eine QR-Rechnungs-Pipeline für die Mehrheit der Lieferanten aufbauen, weil sie es bleiben werden; Restbelege mit Belegerkennung in dieselbe Output-Schicht führen, sodass am Ende ein einheitlicher Buchungssatz steht. Das ist der Posteingang, der heute realistisch ist — und der in den nächsten fünf bis zehn Jahren mit der eBill-Adoption mitwächst, ohne dass der Mischeingang verschwindet.