QR-Rechnungen verbuchen: Schweizer AP-Workflow

Eine QR-Rechnung verbuchen heisst nicht nur, den QR-Code zu scannen. Der QR-Code liefert Zahlungsdaten: QR-IBAN oder IBAN, Empfänger, Betrag, Währung, Referenz und allenfalls eine Mitteilung oder strukturierte Zusatzinformationen. Für eine vollständige Kreditorenbuchung braucht die Buchhaltung aber zusätzlich die Daten aus dem Rechnungsbody: Rechnungspositionen, MWST-Sätze, Lieferantenstamm, Kostenstellen, Zahlungsbedingungen und den nachvollziehbaren Link zum Originalbeleg.

Genau dort entsteht der operative Unterschied. Die QR-Rechnung vereinfacht die Zahlung, ersetzt aber nicht die vollständige Buchung. Wer eine QR-Rechnung Schweiz verbuchen will, muss QR-Code-Daten mit Rechnungspositionen, MWST-Aufschlüsselung, Lieferantenmatch, Kostenstellenlogik und Archivierungsnachweis aus dem Belegkörper zusammenführen.

Der Standard ist in der Schweiz nicht optionaler Komfort. Nach dem 30. September 2022 verarbeiten Schweizer Finanzinstitute keine roten und orangen Einzahlungsscheine mehr; Rechnungssteller mussten auf QR-Rechnung oder eBill umstellen, wie das KMU-Portal zur Ablösung der Einzahlungsscheine festhält. Für Schweizer AP-Teams ist die Frage deshalb nicht, ob QR-Rechnungen vorkommen, sondern wie sie im täglichen Belegstrom verarbeitet werden.

Ein einzelner QR-Scan reicht oft für eine Zahlung oder für das Anlegen einer einfachen Lieferantenrechnung. Er reicht nicht, wenn eine Hotelrechnung mehrere MWST-Sätze enthält, eine Sammelrechnung auf drei Kostenstellen aufgeteilt werden muss oder der Lieferant dieselbe Rechnung per PDF und Papier schickt. Auch die Bestellreferenz, eine Skontofrist oder die eigentlichen Leistungspositionen stehen häufig ausserhalb des QR-Codes.

Der sinnvolle Workflow beginnt deshalb mit einer einfachen Trennung: Der QR-Code beantwortet die Zahlungsfrage, der Rechnungsbody beantwortet die Buchungsfrage. Erst wenn beide Datenquellen zusammen geprüft werden, entsteht ein Buchungsvorschlag, den ein Schweizer KMU, eine Treuhandfirma oder ein AP-Team sauber in Bexio, Abacus, Banana oder ein anderes Zielsystem übernehmen kann.

Was der QR-Code liefert und was im Rechnungsbody bleibt

Der Swiss QR-Code ist wertvoll, weil er Zahlungsdaten maschinenlesbar macht. Je nach Rechnung enthält er IBAN oder QR-IBAN, Empfängerangaben, Betrag, Währung, Referenztyp, QR-Referenz oder Creditor Reference, eine unstrukturierte Mitteilung und optional strukturierte Rechnungsinformationen nach Swico S1. Für den Zahlungslauf sind diese Felder der Kern.

Für die Kreditorenbuchhaltung ist das nur ein Teil des Datensatzes. Die QR-Referenz identifiziert die Zahlung, aber sie erklärt nicht, welche Leistungen verrechnet wurden. Die QR-IBAN hilft beim Bankverbindungsabgleich, aber sie entscheidet nicht, ob der Lieferant im Stamm sauber gematcht ist. Swico S1 kann zusätzliche Informationen transportieren, wird in der Praxis aber nicht von jedem Lieferanten vollständig gepflegt. Viele QR-Codes enthalten deshalb genug für die Zahlung und zu wenig für die Buchungsprüfung.

Die buchungsrelevanten Details stehen meistens im sichtbaren Rechnungsbody. Dort finden sich Positionen, Mengen, Einzelpreise, Rabatte, MWST-Sätze, Bestellnummern, Lieferdaten, Projekt- oder Kostenstellenhinweise, Skonto und Zahlungsfrist. Gerade bei Schweizer Rechnungen mit mehreren MWST-Sätzen wird die Grenze sichtbar: Ein Standard-MWST-Code aus dem Lieferantenstamm ist bequem, aber nicht zuverlässig, wenn auf derselben Rechnung unterschiedliche Leistungen mit unterschiedlichen Sätzen stehen.

Auch das Position-Splitting entsteht nicht aus dem QR-Code. Eine Sammelrechnung kann Büromaterial, Wartung und Verbrauchsmaterial enthalten, die auf verschiedene Konten oder Kostenstellen gehören. Der Zahlungsdatensatz bleibt derselbe, aber die Buchung muss aufgeteilt werden. Deshalb ist "QR-Rechnung Rechnungspositionen extrahieren" kein Zusatzwunsch für Perfektionisten, sondern oft die Voraussetzung dafür, dass der Import in die Buchhaltung nicht nachträglich korrigiert werden muss.

Ein guter AP-Workflow behandelt den QR-Code als sichere Quelle für Zahlungsfelder und den Rechnungsbody als Quelle für Buchungsfelder. Wenn diese Rollen vermischt werden, entstehen typische Fehler: korrekte Zahlung an den richtigen Empfänger, aber falscher Aufwand, falsche Vorsteuer, fehlende Bestellreferenz oder ein nicht nachvollziehbarer Beleglink.

Der reale Posteingang ist ein gemischter Belegbatch

In der Praxis kommt die QR-Rechnung selten als sauberer Einzelfall. Ein Schweizer AP-Team verarbeitet PDF-Rechnungen aus E-Mails, gescannte Papierrechnungen, Handyfotos aus der Filiale, Portaldownloads, ausländische Lieferantenrechnungen ohne QR-Teil und eBill-Meldungen im selben Tagesgeschäft. Der Posteingang ist ein gemischter Belegbatch, nicht ein QR-Labor.

Darum scheitern viele Prozesse nicht am QR-Code selbst, sondern an der Trennung der Eingangskanäle. Wenn QR-Rechnungen im Buchhaltungssystem erfasst werden, Nicht-QR-PDFs in einer separaten Tabelle landen und Papierbelege später nachgereicht werden, verliert das Team die einheitliche Sicht auf Dubletten, offene Prüfungen und fehlende Lieferantendaten. Für die Buchhaltung zählt am Ende nicht, aus welchem Kanal ein Beleg kam, sondern ob daraus ein prüfbarer Buchungsvorschlag mit Belegnachweis entsteht.

Mobile-Erfassung ist in diesem Mix nützlich, aber kein Ersatz für Prozessdisziplin. Ein Foto funktioniert gut bei einfachen einseitigen Belegen, wenn Beleuchtung, Rand und Lesbarkeit stimmen. Es wird riskanter bei mehrseitigen Lieferantenrechnungen, bei Schatten auf dem Betrag, bei unscharfen Positionstabellen oder wenn der QR-Code auf einer Folgeseite steht. Gerade Treuhand-Teams sehen solche Fälle häufig, weil Mandanten Belege aus sehr unterschiedlichen Situationen hochladen. Ein verwandter Kanal sind Mitarbeiterbelege aus Restaurant, Hotel oder Tankstelle, die im Rahmen der Spesenabrechnung mit Reglement-Compliance und MWST-Vorsteuer-Recovery erfasst werden und ebenfalls in Bexio, Abacus oder Banana zurückfliessen müssen.

eBill ist nochmals anders gelagert. Der Kanal ist stärker strukturiert und reduziert den klassischen Scanbedarf, aber er ersetzt nicht den Rest des Posteingangs. Wer eBill und QR-Rechnung gegeneinander abgrenzt, sollte den eBill-vs.-QR-Rechnung-Workflow für den Posteingang als Kanalfrage betrachten: eBill kann bestimmte Rechnungen direkter in den Prozess bringen, während PDF-, Scan- und Foto-Belege weiterhin extrahiert und geprüft werden müssen.

Ein belastbarer Workflow führt diese Eingänge früh zusammen. Die erste Frage lautet nicht "Hat der Beleg einen QR-Code?", sondern "Welche Felder brauchen wir, um ihn korrekt zu verbuchen?" Bei QR-Rechnungen kommen die Zahlungsfelder aus dem Code. Bei allen Belegen kommen Buchungsfelder, Plausibilitätsprüfungen und Archivbezug aus dem Dokument und aus dem Zielsystem.

Drei Workflows nach Volumen: manuell, Stapel, Ausnahmeprozess

Bei kleinem Volumen, ungefähr unter 50 Lieferantenrechnungen pro Monat, kann ein manueller Workflow wirtschaftlich sein. Die Buchhalterin scannt oder liest den QR-Code im Buchhaltungssystem, prüft Lieferant, Betrag und Referenz, ergänzt MWST-Code, Konto, Kostenstelle und Zahlungsfrist und legt den Beleg ab. Der Aufwand liegt dann weniger in der QR-Erfassung als in den Ergänzungen, die der QR-Code nicht kennt.

Bei mittlerem Volumen, etwa 50 bis 500 Lieferantenrechnungen pro Monat, wird Stapelverarbeitung entscheidend. Alle eingehenden Belege laufen zuerst durch eine Vor-Erfassung: QR-Zahlungsdaten, Rechnungsnummer, Datum, Lieferant, Positionen, MWST-Aufschlüsselung und Kostenstellenhinweise werden in einem gemeinsamen Datensatz gesammelt. Das AP-Team prüft danach nicht jede Zahl von Hand, sondern Ausnahmen: fehlender Lieferantenmatch, ungewohnter MWST-Satz, doppelte Rechnungsnummer, Betrag ausserhalb der Erwartung oder unvollständige Positionstabelle.

Bei hohem Volumen, oft ab 500 Lieferantenrechnungen pro Monat oder bei Treuhandfirmen mit mehreren Industrie-Mandanten, braucht der Prozess eine klare Pipeline. Belegerkennung, Lieferantenstamm, Bestellbezug, Drei-Wege-Match, Freigabe, Zahlungslauf und Archivierung müssen ineinandergreifen. Die Buchhaltung arbeitet dann nicht mehr als Erfassungsstelle, sondern als Quality Owner für Ausnahmen und Abstimmungen.

Diese Schwellen sind Orientierungswerte, keine Norm. Ein Treuhandbüro mit 80 komplexen Mandantenbelegen kann früher automatisieren müssen als ein Handelsbetrieb mit 300 sehr gleichförmigen Lieferantenrechnungen. Entscheidend ist nicht nur die Anzahl Belege, sondern die Fehlerkosten: falsche Vorsteuer, falsche Kostenstelle, doppelte Zahlung oder fehlende Prüfspur.

Auch bei guter Automatisierung bleibt Review notwendig. Saubere QR-PDFs lassen sich deutlich stabiler verarbeiten als verwackelte Fotos oder mehrseitige Sammelrechnungen. Der richtige Anspruch ist deshalb nicht "alles blind verbuchen", sondern "Routinefälle schnell erfassen und Ausnahmen sichtbar machen".

Wo Bexio, Abacus und Banana helfen und wo eine Erfassungsschicht nötig wird

Schweizer Buchhaltungssysteme nehmen dem Team einen wichtigen Teil der Arbeit ab. QR-Erfassung kann Zahlungsdaten übernehmen, Lieferanten vorschlagen, eine Lieferantenrechnung vorbereiten oder den Zahlungslauf sauberer machen. Für viele kleine Teams ist das bereits ein grosser Fortschritt gegenüber dem Abtippen von IBAN, Referenz und Betrag.

Die Grenze liegt dort, wo der Beleg mehr verlangt als Zahlungsdaten. Ein Bexio-Workflow für Lieferantenrechnungen kann den Zielprozess in Bexio strukturieren, und wer Abacus-Kreditorenbuchhaltung automatisieren will, denkt stärker in Freigaben, Lieferantenstamm und ERP-nahe Abläufe. Auch Banana-Belege und QR-Rechnungen importieren ist für kleinere Schweizer Setups relevant. In allen Fällen bleibt aber dieselbe fachliche Frage: Sind die Daten vor dem Import vollständig genug, um richtig zu verbuchen?

Native QR-Funktionen lesen nicht automatisch jede Position, prüfen nicht jede mehrstufige MWST-Aufschlüsselung, erkennen nicht jede Dublette und entscheiden nicht immer, wie eine Sammelrechnung auf Kostenstellen aufzuteilen ist. Sie sind Zielsysteme oder Erfassungspfade, aber nicht zwingend die vollständige Vor-Erfassungsschicht für gemischte Belegbatches.

Invoice Data Extraction passt genau in diese Vorstufe. Das Team lädt Schweizer QR-Rechnungen, Nicht-QR-PDFs, Scans oder Bilddateien hoch, beschreibt per Prompt, welche Felder benötigt werden, und exportiert die Ergebnisse als XLSX, CSV oder JSON. Für den Schweizer QR-Workflow heisst das: QR-Zahlungsfelder und Rechnungsbody-Felder werden gemeinsam in eine prüfbare Tabelle gebracht, bevor die Daten in Bexio, Abacus, Banana oder ein anderes System gehen. Wer Rechnungsdaten aus QR-Belegen extrahieren will, sollte die Erfassung deshalb als Vorbereitung für Review und Import verstehen, nicht als Ersatz für die eigentliche Buchhaltung.

Diese Rollenteilung hält die Verantwortlichkeiten sauber. Die Extraktion bereitet strukturierte Daten vor. Die Buchhaltungssoftware verbucht, zahlt, archiviert und bleibt System of Record. Die Buchhalterin entscheidet, welche Ausnahmen geklärt werden müssen.

Kontrollen vor dem Import: Lieferant, MWST, Positionen und Dubletten

Der Lieferantenmatch ist der erste Kontrollpunkt. Eine QR-IBAN oder IBAN hilft beim Abgleich, aber sie ersetzt nicht den Lieferantenstamm. Bankverbindungen ändern sich, Namen werden unterschiedlich geschrieben, mehrere Standorte verwenden ähnliche Rechnungsdesigns, und nach Firmenfusionen oder Bankmigrationen entstehen leicht neue Kontakte, obwohl der Lieferant bereits existiert. Vor dem Import sollte deshalb klar sein, welcher Stammdatensatz verwendet wird und ob Name, Adresse und Bankverbindung plausibel zusammenpassen.

Die MWST-Prüfung ist der zweite Kontrollpunkt. Eine Rechnung kann mehrere Sätze enthalten, etwa Beherbergung, Restaurantleistung und sonstige Leistungen auf einem Beleg. Wenn der Prozess nur den Standard-MWST-Code des Lieferanten übernimmt, ist die Vorsteuer möglicherweise falsch aufgeteilt. Eine brauchbare Vor-Erfassung muss die MWST-Aufschlüsselung aus dem Rechnungsbody erkennen und die Beträge so darstellen, dass die Buchhaltung sie prüfen kann.

Der dritte Kontrollpunkt sind Positionen und Splits. Sammelrechnungen müssen oft auf verschiedene Aufwandkonten, Kostenstellen, Projekte oder Mandanten verteilt werden. Das gilt besonders bei Treuhand-Setups, Bau- und Servicebetrieben oder Gruppenstrukturen mit internen Kostenstellen. Der QR-Code kann den Gesamtbetrag korrekt liefern und trotzdem keinerlei Hinweis darauf geben, wie die Rechnung intern zu verteilen ist.

Dublettenprüfung gehört ebenfalls vor den Import. Eine Rechnung kann per E-Mail eintreffen, zusätzlich als Papierbeleg gescannt werden und später nochmals aus einem Lieferantenportal heruntergeladen werden. Die Kombination aus Rechnungsnummer, Lieferant, Datum, Betrag, QR-Referenz und Dateiherkunft ist deshalb wichtiger als ein einzelnes Feld. Nur so fallen doppelte Belege auf, bevor sie im Zahlungslauf oder in der Kreditorenliste landen.

Der Archivierungsbezug sollte im selben Schritt erhalten bleiben. Originalbeleg, extrahierte Daten und späterer Buchungssatz müssen nachvollziehbar zusammengehören. Für die tägliche Arbeit ist das weniger eine juristische Fussnote als eine praktische Suchfrage: Kann das Team sechs Monate später erklären, warum diese Rechnung auf dieses Konto, diese Kostenstelle und diesen MWST-Code gebucht wurde?

Exportfähig verbuchen: das Ziel ist ein prüfbarer Buchungsvorschlag

Ein guter QR-Workflow endet nicht beim Scan. Er endet bei einem Datensatz, den die Buchhaltung prüfen, korrigieren und importieren kann: Zahlungsdaten aus dem QR-Code, Buchungsdaten aus dem Rechnungsbody, Lieferantenmatch aus dem Stamm, MWST-Aufschlüsselung, Kostenstellenlogik und Link zum Originalbeleg.

Für den Review-Export sind die Felder wichtiger als das Dateiformat. Sinnvoll sind mindestens Rechnungsnummer, Rechnungsdatum, Lieferant, IBAN oder QR-IBAN, QR-Referenz, Betrag, Währung, MWST-Sätze, Positionszeilen, Konto- oder Kostenstellenvorschlag, Zahlungsfrist, Skonto, Belegdatei und ein Statusfeld für die Prüfung. Bei Sammelrechnungen braucht es zusätzlich eine Zeilenstruktur, sonst verschwindet die wichtigste Buchungsinformation in einem Gesamtbetrag.

Der Import in die Buchhaltung sollte erst danach kommen. Bexio, Abacus, Banana oder ein ERP-System sind die Orte für Verbuchung, Zahlungslauf, Freigabe und Archiv. Die Vor-Erfassung muss ihnen Daten liefern, die konsistent genug sind, um verarbeitet zu werden, aber transparent genug, dass die Buchhaltung die fachliche Verantwortung behält.

Für Teams, die QR-Rechnung Stapelverarbeitung einführen, ist die Reihenfolge entscheidend: zuerst definieren, welche Felder pro Beleg wirklich gebraucht werden; dann festlegen, welche Review-Regeln Ausnahmen sichtbar machen; erst danach das Tooling auswählen. Wer mit dem Werkzeug beginnt, optimiert leicht den Scan. Wer mit dem Buchungsvorschlag beginnt, optimiert den ganzen AP-Workflow.