Kassenanbieter in Europa stehen gleichzeitig vor zwei Compliance-Pflichten. Die Fiskalisierung ist bekanntes Terrain: Ein Land nach dem anderen verlangt inzwischen, dass jede Transaktion an der Kasse manipulationssicher signiert wird. Die E-Rechnung kommt mit hohem Tempo. Italien verlangt strukturierte Rechnungen seit 2019, Belgien, Frankreich und Polen folgten 2026, und Deutschland und Spanien sind 2027 an der Reihe.
Bei zwei Pflichten bauen die meisten Anbieter zwei Integrationen. Die Fiskalisierung bleibt im Kassensystem, die E-Rechnung wandert ins Backoffice, abgekoppelt von dem Kassiervorgang, bei dem der Verkauf stattgefunden hat.
Auf dem Papier funktioniert das. In der Praxis landet ein Verkauf in zwei Datenbanken, mit zwei Prüfpfaden, die nicht unbedingt übereinstimmen, und im schlimmsten Fall wird dieselbe Umsatzsteuer zweimal geschuldet.
So funktioniert es, wenn stattdessen beides über das Kassensystem läuft: mit einer API, einem Anbieter und einem Prüfpfad.
Was passiert tatsächlich, wenn die Rechnung in einem zweiten System liegt?
„Getrennt“ heißt heute kaum noch Stift und Papier. Meist ist das E-Rechnungs-Tool an das ERP, die Buchhaltungssoftware oder eine Middleware dazwischen angebunden. Jede Transaktion wird exportiert, synchronisiert oder neu erfasst, und auf einer Folie sieht das nach einem gelösten Problem aus.
In Wirklichkeit teilen sich jetzt mehrere Systeme die Aufgabe, einen einzigen Verkauf zu erfassen, und jede Übergabe zwischen ihnen ist eine Stelle, an der sich die Wahrheit aufspalten kann.
Verfolgen wir einen B2B-Verkauf durch diese Kette:
- Der Verkauf beginnt im Kassensystem. Positionen, Steuersätze, Zahlung und Signatur werden an der Theke erfasst. Das ist der rechtlich maßgebliche Datensatz.
- Die Daten verlassen das Kassensystem. Sie wandern per nächtlichem Export, Middleware-Sync oder CSV-Import, oder jemand tippt sie vom Beleg ab. Bei jedem Schritt werden Steuerschlüssel, Rundungsregeln, Warengruppen und Rabatte auf das Datenmodell eines anderen Systems abgebildet. Jede dieser Zuordnungen ist eine Übersetzung, keine Kopie.
- Die Rechnung wird neu erzeugt. Das zweite System erstellt die E-Rechnung aus den Daten, die es erhalten hat, nicht aus dem Verkauf selbst. Fällt eine Position weg, wird ein Steuerschlüssel neu zugeordnet oder ein Rabatt in anderer Reihenfolge angewendet, passt die Rechnung nicht mehr zum fiskalischen Datensatz.
- Korrekturen treiben die Systeme auseinander. Angenommen, ein Verkauf wird im Kassensystem storniert, nachdem der Sync schon gelaufen ist, oder eine Rechnung wird im ERP gutgeschrieben, ohne das Kassensystem anzufassen. Dann sind sich die beiden Systeme dauerhaft uneinig darüber, was verkauft wurde, und nichts in diesem Aufbau bringt sie wieder in Einklang.
- Der Prüfer sieht zwei Versionen. Das fiskalische Journal hält eine Version des Verkaufs fest, das Rechnungsarchiv eine andere. Sie Transaktion für Transaktion abzugleichen, über Aufbewahrungsfristen von bis zu zehn Jahren, bleibt am Händler hängen. Das merkt er meist im ungünstigsten Moment: während der Prüfung.
Es gibt eine schärfere Folge als nicht übereinstimmende Datensätze: derselbe Verkauf, zweimal versteuert.
In den Umsatzsteuersystemen der EU wird Steuer, die auf einem ausgestellten Dokument ausgewiesen ist, grundsätzlich dem Finanzamt geschuldet. Stellt das Kassensystem einen Beleg mit ausgewiesener Umsatzsteuer aus und erzeugt ein zweites System später eine vollständige Rechnung für denselben Verkauf, ohne dass beide als eine Leistung verknüpft sind, riskiert der Händler, diese Umsatzsteuer doppelt zu schulden, bis das Duplikat entdeckt und korrigiert ist. Deutschland regelt das ausdrücklich in § 14c UStG: Zu hoch oder unberechtigt ausgewiesene Umsatzsteuer wird geschuldet, Punkt. Was als Lücke im Ablauf beginnt, endet als Steuerschuld.
Nichts davon ist ein Sonderfall. Es ist der Alltag des Zwei-System-Aufbaus, und jedes Backoffice-Tool für E-Rechnungen ist darum herum gebaut.
Warum die Rechnung dorthin gehört, wo verkauft wird
Die integrierte Alternative ist einfach. Dieselbe Cloud-Schicht, die die Transaktion für die Fiskalisierung signiert, stellt auch die E-Rechnung aus, und zwar mit den Live-Transaktionsdaten im Moment des Verkaufs.
Drei alltägliche Szenen zeigen den Unterschied:
Das Geschäftsessen. Ein Gast bezahlt ein Teamessen, das deutlich über der Grenze für Kleinbetragsrechnungen liegt.
- Integriert: Die E-Rechnung wird am Tisch ausgestellt oder landet Sekunden später im Postfach des Gastes. Sie entsteht aus der signierten Transaktion und ist mit dem Beleg verknüpft, sodass der Betriebsausgabenabzug vom ersten Tag an gesichert ist.
- Getrennt: Wochen später bittet der Gast per E-Mail um eine Rechnung. Jemand baut das Essen anhand eines Fotos vom Beleg in der Buchhaltungssoftware nach. Das Restaurant hat nun zwei Dokumente mit ausgewiesener Umsatzsteuer für eine Mahlzeit ausgestellt. Sind sie nicht als eine Leistung verknüpft, schuldet das Restaurant diese Umsatzsteuer womöglich zweimal. Das ist ein Steuerrisiko, nicht nur ein Serviceproblem.
Die Fachhandelstheke. Ein gewerblicher Käufer nennt an der Kasse eines Einzelhändlers seine USt-IdNr.
- Integriert: Die Kasse, die den Beleg druckt, stellt auch die E-Rechnung aus, und das Kreditorensystem des Käufers verarbeitet sie automatisch.
- Getrennt: Der Verkauf gelangt mit dem nächtlichen Export ins ERP. Dort erzeugen ein neu zugeordneter Steuerschlüssel und eine abweichende Rundungsregel eine Rechnung, die nicht mehr centgenau zum fiskalischen Datensatz passt. Das fällt niemandem auf, bis ein Prüfer die beiden Systeme vergleicht.
Der Hotel-Check-out. Ein Firmengast reist ab.
- Integriert: Die Rezeption stellt die E-Rechnung für den gesamten Aufenthalt sofort aus. Der Tourist dahinter in der Schlange bekommt einfach einen Beleg. Es ist derselbe Ablauf, mit einer einzigen Abfrage.
- Getrennt: Das Hotelverwaltungssystem synchronisiert die Gastrechnung über Nacht an die Finanzabteilung. Am nächsten Morgen passt die Finanzabteilung den Firmentarif an, sodass die Rechnung, die schließlich verschickt wird, nicht mehr zu den Unterlagen der Rezeption passt.
In jedem Fall beginnen die Daten im Kassensystem. Die Rechnung in ein zweites System zu verlagern heißt, diese Daten anderswo neu aufzubauen, mit allem, was schiefgeht, wenn ein Sync, eine Zuordnung oder ein Mensch Daten nachbaut, statt sie wiederzuverwenden.
Integriert oder getrennt: der Vergleich
| Kriterium | Integriert (im Kassensystem über die Cloud) | Getrennt (Backoffice-Aufbau) |
|---|---|---|
| Datengenauigkeit | Rechnung aus der Live-Transaktion: gleiche Positionen, gleiche Steueraufteilung, ein führendes System | Übersetzt in das Datenmodell eines anderen Backend-Systems, und Übersetzungen driften: Steuerschlüssel, Rundung und Positionsstruktur passen nach und nach nicht mehr zum fiskalischen Datensatz |
| Prüfpfad | Signatur, Beleg und XML-Rechnung in einem System verknüpft und gesetzeskonform archiviert | Zwei Prüfpfade in zwei Datenbanken, die Transaktion für Transaktion abgeglichen werden müssen |
| Risiko doppelter Umsatzsteuer | Eine verknüpfte Dokumentenkette pro Verkauf: Beleg und Rechnung verweisen auf dieselbe Leistung | Beleg plus später ausgestellte, nicht verknüpfte Rechnung für denselben Verkauf: Doppelt ausgewiesene Umsatzsteuer kann bis zur Korrektur doppelt geschuldet sein (§ 14c UStG) |
| Vorsteuerabzug des Käufers | Gesetzeskonforme E-Rechnung an der Kasse oder Sekunden später | Käufer läuft der Rechnung wochenlang hinterher; oft kommt sie nie an |
| Aufwand fürs Personal | Eine Abfrage an der Kasse, kein zweiter Schritt, an den man denken muss | B2B-Fall erkennen, Daten auf Papier notieren, ans Backoffice übergeben |
| Bereitschaft für Echtzeit-Meldungen | Die Cloud-Schicht sitzt bereits im Transaktionspfad: Meldungen kommen hinzu, ohne das Kassensystem anzufassen | Kann prinzipbedingt nicht zum Transaktionszeitpunkt melden; struktureller Umbau, sobald Meldepflichten kommen |
| Skalierung über Märkte | Eine Integration deckt XRechnung, ZUGFeRD, Factur-X, FatturaPA, Peppol und weitere Systeme ab | Formate und Kanäle jedes Landes werden in jedem Backoffice-Tool separat behandelt |
Eine API, ein Anbieter: was die Bündelung spart
Technisch lösen Fiskalisierung und E-Rechnung dieselbe Art von Problem. Beide nehmen eine Transaktion, bringen sie in ein gesetzlich vorgeschriebenes Format, übermitteln sie und bewahren sie über Jahre revisionssicher auf.
Betreiben Sie sie als zwei getrennte Systeme, verdoppeln Sie jede Schicht:
- zwei Datenmodelle, die synchron gehalten werden müssen
- zwei Authentifizierungen und Organisationsstrukturen
- zwei Prüfpfade, die abgeglichen werden müssen
- zwei Anbieter und Support-Kanäle, die koordiniert werden müssen
- zwei Sätze regulatorischer Änderungen, die in jedem Land verfolgt werden müssen
Im integrierten Modell läuft die E-Rechnung auf dem, was Sie für die Fiskalisierung schon haben: dieselben Transaktionsdaten, Authentifizierung und Organisationsstruktur, dasselbe manipulationssichere Journal und Archiv, derselbe Supportvertrag. Zwei Pflichten, eine Integration. Die zweite Pflicht kostet so deutlich weniger, und das nächste Land ebenso.
ViDA kommt und rückt die Compliance näher an den Verkauf
Der stärkste Grund, diese Architektur richtig aufzusetzen, ist das, was als Nächstes kommt. Das EU-Paket VAT in the Digital Age (ViDA) macht digitale Meldepflichten für grenzüberschreitende Transaktionen bis 2030 verpflichtend, und die Mitgliedstaaten legen eigene nationale Echtzeitsysteme darüber.
Die Richtung ist klar: Die Meldung rückt näher an die Transaktion. Ein Backoffice-Tool, das die Daten Tage nach dem Verkauf erhält, kann nur Schritt halten, indem es seinen Sync verkürzt, und jeder Sync ist eine weitere Stelle, an der die beiden Datensätze auseinanderlaufen können. Wenn die Meldefrist schrumpft, braucht der getrennte Aufbau kein Update. Er muss neu gebaut werden.
Eine integrierte Cloud-Schicht sitzt bereits im Transaktionsfluss. Sie signiert die Transaktion heute, und ein Meldeschritt morgen erweitert genau diesen Fluss, ohne die Kassenintegration erneut anzufassen. Es ist dieselbe Architekturentscheidung, die die letzte Compliance-Welle entschieden hat: Die Cloud-Fiskalisierung hat Hardware verdrängt, gerade weil eine zentrale, versionierte Plattform regulatorische Änderungen für jede angebundene Kasse übernimmt.
Wo das getrennte Modell noch trägt
Eine integrierte E-Rechnung ist heute gesetzlich nicht vorgeschrieben, und an einigen Stellen ist das getrennte Modell weiterhin sinnvoll:
- Kleine Belege bleiben einfach. Unterhalb der Grenze für Kleinbetragsrechnungen (250 € in Deutschland) reicht ein Beleg. Doch Verkäufe oberhalb dieser Grenze sind genau die B2B-Transaktionen, die Prüfungs- und Doppelsteuerrisiken tragen.
- Die Fristen sind gestaffelt. In mehreren Märkten bleibt die Ausstellung von E-Rechnungen aus dem Kassensystem noch ein oder zwei Jahre optional. Doch der Bau der Integration braucht Zeit, und Anbieter, die jetzt beginnen, müssen sie nicht im letzten Jahr unter Druck bauen.
Das getrennte Modell ist legal, aber es ist teuer, auf eine Weise, die keine Preisliste zeigt: Abgleicharbeit, Reibung bei Prüfungen, Risiko doppelter Umsatzsteuer, frustrierte Käufer, doppelter Entwicklungsaufwand und ein Umbau, sobald die Meldung vor 2030 näher an den Verkauf rückt.
Das Wichtigste in Kürze
- Ein einzelner B2B-Verkauf an der Kasse kann sowohl unter die Fiskalisierung als auch unter die E-Rechnungspflicht fallen. Wer beides auf zwei Systeme verteilt, erzeugt zwei Datensätze für eine Transaktion.
- Sind ein Beleg und eine separate Rechnung nicht als eine Leistung verknüpft, kann dieselbe Umsatzsteuer doppelt geschuldet sein. In Deutschland regelt das § 14c UStG.
- Laufen beide Pflichten über eine API, teilen sie sich Authentifizierung, Prüfpfad und Archiv, sodass das nächste Land weniger kostet.
- ViDA rückt die Umsatzsteuermeldung bis 2030 näher an die Transaktion. Eine Cloud-Schicht, die bereits im Transaktionsfluss sitzt, kann Meldungen ohne Umbau ergänzen.
Wo fiskaly ins Spiel kommt
fiskaly baut cloudbasierte Infrastruktur für die Umsatzsteuer-Compliance, genau für diese Situation. Unsere E-Rechnungs-API fiskaly E-INVOICE läuft auf derselben Plattform wie unsere Fiskalisierungsprodukte, sodass sich beide Pflichten eine Authentifizierung, eine Organisationsstruktur und einen Prüfpfad teilen. EN-16931-Formate, Peppol-Zugang und gesetzeskonforme Archivierung sind alle über eine einzige Integration abgedeckt.
