Ab dem 1. Januar 2027 müssen inländische Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz ihre B2B-Rechnungen als E-Rechnung ausstellen, ab dem 1. Januar 2028 alle übrigen. Rechnungen bis 250 Euro bleiben davon ausgenommen. Die Pflicht gilt auch für Bargeschäfte an der Kasse.

Damit ein Betrieb überhaupt eine gültige E-Rechnung erzeugen kann, braucht er die Stammdaten seines Kunden. An einer Kasse ist das ein Problem, weil niemand Firmenname, Anschrift, Steuernummer und Zustelladresse abtippen will, während zehn Leute in der Schlange stehen.

Der Rechnungspass löst genau diesen einen Schritt. Der Käufer erzeugt einmalig einen QR-Code mit seinen Rechnungsdaten und zeigt ihn vor. Das Kassensystem liest ihn und hat alle Angaben, die es für die Käuferseite einer Rechnung nach EN 16931 braucht.

• Alle Daten stehen im Code selbst. Es gibt keinen Server-Abruf, keine ID und keine Datenbank dahinter. Der Code funktioniert offline, auch auf Papier, und auch dann noch, wenn es den Herausgeber des Formats nicht mehr gibt.
• Eine einzige Zeile, keine Zeilenumbrüche. Viele Kassenscanner geben Gelesenes als Tastatureingabe weiter. Ein Zeilenumbruch würde dort wie die Eingabetaste wirken und das Formular abschicken.
• Benannte Felder statt fester Reihenfolge. Das kostet ein paar Zeichen, macht das Format aber erweiterbar, ohne alte Leser zu brechen.
• Kurz genug für einen kleinen Code. Ein typischer Datensatz bleibt unter 250 Zeichen. Damit passt er in einen QR-Code, der von einem Handydisplay und von einer laminierten Karte zuverlässig gelesen wird.
• Offen und frei. Jeder darf das Format lesen, erzeugen und in eigene Produkte einbauen. Ohne Lizenz, ohne Anmeldung, ohne Gebühr.

Ein Rechnungspass ist eine einzelne Zeichenkette in UTF-8. Sie besteht aus Segmenten, die durch einen senkrechten Strich | getrennt sind. Das erste Segment ist die Kennung, alle weiteren sind Felder in der Form TAG:Wert.

RPASS:1|TAG:Wert|TAG:Wert|TAG:Wert

Regeln für den Aufbau

• Das erste Segment lautet RPASS: gefolgt von der Hauptversion als Dezimalzahl. In dieser Fassung also RPASS:1.
• Ein Tag besteht aus genau drei Großbuchstaben A bis Z.
• Tag und Wert werden durch den ersten Doppelpunkt im Segment getrennt. Weitere Doppelpunkte gehören zum Wert.
• Die Reihenfolge der Felder ist beliebig. Jedes Tag darf höchstens einmal vorkommen.
• Ein Feld ohne Wert wird weggelassen, nicht leer mitgeschickt.
• Steuerzeichen von U+0000 bis U+001F sind verboten. Damit auch Zeilenumbrüche und Tabulatoren.
• Führende und abschließende Leerzeichen eines Wertes werden vom Leser entfernt.

Maskierung

Zwei Zeichen haben im Wert eine Sonderbedeutung und werden mit einem Rückstrich maskiert.

Die Spalte rechts nennt das entsprechende Feld der Norm EN 16931, damit die Abbildung auf XRechnung und ZUGFeRD eindeutig ist.

Ein Busunternehmen, das an einer Tankstelle oder in einer Gaststätte einkauft. Der Datensatz ist 153 Zeichen lang und passt damit in einen QR-Code der Version 9, also 53 Module je Kante.

RPASS:1|FIR:Reisedienst Halbach GmbH|STR:Buswerk 14|PLZ:03046|ORT:Cottbus|LND:DE|UST:DE271884903|EAD:rechnung@halbach-reisen.de|EAS:EM|ANS:Sabine Halbach

Dieselbe Firma mit Adresszusatz und Kostenstelle, und ein öffentlicher Auftraggeber mit Leitweg-ID:

RPASS:1|FIR:Stadtverwaltung Cottbus|STR:Neumarkt 5|PLZ:03046|ORT:Cottbus|LND:DE|EAD:991-12345-67|EAS:0204|KRF:991-12345-67|BST:Kostenstelle 4711

Ein Leser muss

• Die Zeichenkette ablehnen, wenn sie nicht mit RPASS: beginnt.
• Die Hauptversion prüfen. Ist sie höher als die unterstützte, wird der Code abgelehnt und dem Bediener gemeldet, statt Felder zu raten.
• Unbekannte Tags stillschweigend übergehen. Nur so bleiben spätere Erweiterungen verträglich.
• Fehlende Pflichtfelder melden, statt einen unvollständigen Datensatz zu übernehmen.
• Die gelesenen Daten anzeigen, bevor sie in die Kundendatei übernommen werden. Der Bediener bestätigt.

Ein Leser sollte

• Die USt-IdNr. gegen das Bestätigungsverfahren prüfen, also VIES oder die Schnittstelle des Bundeszentralamts für Steuern, und das Ergebnis anzeigen.
• Bekannte Kunden am Datensatz wiedererkennen und nicht doppelt anlegen.
• Den Rohtext des Codes zusammen mit dem Vorgang speichern, damit später nachvollziehbar ist, welche Daten der Kunde geliefert hat.

Ein Erzeuger muss

• Alle Pflichtfelder setzen.
• Werte maskieren, die | oder \ enthalten.
• Den Nutzer die Daten vor dem Erzeugen prüfen lassen. Ein falscher Code verteilt den Fehler an jede Kasse.

Version 1 ist nicht signiert. Wer einen Rechnungspass erzeugt, kann beliebige Daten hineinschreiben. Das ist bewusst so und kein Rückschritt, denn heute diktiert derselbe Kunde dieselben Daten mündlich an der Kasse, und auch das prüft niemand.

Die Verantwortung bleibt, wo sie ohnehin liegt. Der Verkäufer stellt die Rechnung aus und muss die Angaben seines Kunden im üblichen Rahmen prüfen. Deshalb schreibt diese Spezifikation vor, dass ein Leser die Daten anzeigt und bestätigen lässt, und empfiehlt die Abfrage der USt-IdNr. beim Bestätigungsverfahren.

• Ein Rechnungspass enthält im Regelfall nur Firmendaten. Sobald ANS oder TEL gesetzt sind, stehen auch personenbezogene Daten im Code. Diese Felder sind deshalb optional.
• Beim Erzeugen und beim Lesen entsteht keine Verbindung zu einem Server des Herausgebers. Es gibt keinen Ort, an dem sich nachvollziehen ließe, wer wann wo eingekauft hat.
• Der Verkäufer speichert die Daten in seiner Kundendatei, wie er es bei jeder Rechnung ohnehin tut. Es entsteht keine zusätzliche Verarbeitung.
• Ein Rechnungspass gehört der Firma, nicht einer Person. Er wird an Mitarbeiter weitergegeben und darf keine Angaben enthalten, die nur eine einzelne Person betreffen.

• Neue Tags und neue optionale Felder ändern die Hauptversion nicht. Alte Leser übergehen sie.
• Die Hauptversion steigt nur, wenn sich der Aufbau ändert oder ein Pflichtfeld hinzukommt.
• Tags werden nie neu belegt. Ein zurückgezogenes Tag bleibt für immer zurückgezogen.
• Das Format darf frei implementiert werden, kommerziell wie nicht kommerziell, ohne Lizenzgebühr und ohne Anmeldung. Dieses Dokument steht unter CC BY 4.0.