Stück, Stunde oder Pauschale: Welche Einheit in die E-Rechnung gehört

Kurzantwort: In einer strukturierten E-Rechnung reicht die sichtbare Angabe „Stück“, „Std.“ oder „Pauschale“ nicht aus. Jede Rechnungsposition benötigt eine Menge und einen maschinenlesbaren Einheitencode. Für ein Stück kann beispielsweise H87, für eine Stunde HUR und für ein Kilogramm KGM verwendet werden. Wird ein Preis für 10, 100 oder 1.000 Einheiten angegeben, müssen außerdem Preisbasismenge und Einheit zusammenpassen. KMU sollten diese Werte deshalb nicht erst beim XML-Export improvisieren, sondern in Produkt- und Leistungsstammdaten eindeutig festlegen.

Das klingt nach einem kleinen technischen Detail. In der Praxis entscheidet die Einheit aber darüber, ob Empfänger eine Position automatisch prüfen, verbuchen und mit Bestellung oder Wareneingang abgleichen können. Eine falsche Einheit kann außerdem eine formal fehlerhafte XRechnung oder Peppol-Rechnung erzeugen. Der folgende Leitfaden zeigt, wie Unternehmen in Österreich und Deutschland typische Waren, Dienstleistungen und Pauschalen sauber abbilden.

Warum eine E-Rechnung mehr als „Stk.“ braucht

Eine PDF-Rechnung richtet sich primär an Menschen. Wer „3 Stk. Filter“ liest, versteht die Position meist ohne Rückfrage. Eine strukturierte E-Rechnung enthält dagegen ein semantisches Datenmodell: Der Empfänger verarbeitet Felder wie Rechnungspositionsmenge, Einheit, Nettopreis und Steuerkategorie einzeln. In der europäischen Norm EN 16931 heißen die beiden zentralen Angaben BT-129 für die abgerechnete Menge und BT-130 für deren Einheitencode.

Die Geschäftsregel BR-23 verlangt für jede Rechnungsposition einen solchen Code. Das gilt unabhängig davon, ob die Rechnung als UBL-Datei, XRechnung oder eingebettetes XML in einem hybriden Format übertragen wird. Der sichtbare Begriff „Stunde“ kann im PDF stehen bleiben; im strukturierten Datensatz wird ergänzend der standardisierte Code HUR benötigt.

Für deutsche XRechnungen stellt die Koordinierungsstelle für IT-Standards (KoSIT) Spezifikation, Codelisten und Prüfkomponenten bereit. Aktuell ist XRechnung 3.0.2 maßgeblich; das Winter-Bugfix-Bundle 2025/26 trägt die Fassung vom 31. Januar 2026. In Österreich unterstützt e-Rechnung.gv.at unter anderem UBL 2.1 über Peppol, Upload und Webservice. Die technische Syntax unterscheidet sich, das Grundprinzip der codierten Einheit bleibt jedoch gleich.

Die wichtigsten Einheitencodes für KMU

Peppol und XRechnung verwenden Einheiten aus UNECE Recommendation 20. Verpackungsarten aus Recommendation 21 werden mit einem vorangestellten X eingebunden. Die folgende Auswahl deckt viele typische Fälle ab, ersetzt aber keine Prüfung spezieller Empfängervorgaben.

Geschäftliche Bedeutung	Code	Typischer Einsatz
Stück	H87	Einzelne Artikel, Geräte oder Ersatzteile
Einheit / eins	C62	Abstrakte zählbare Einheit, wenn „Stück“ nicht die genaue Bedeutung trifft
Stunde	HUR	Beratung, Montage, Entwicklung oder Schulung
Tag	DAY	Tagessätze, Miete oder projektbezogene Leistungen
Minute	MIN	Telefonie, Maschinenzeit oder kurze Services
Kilogramm	KGM	Lebensmittel, Rohstoffe oder Schüttgut
Meter	MTR	Kabel, Stoffe, Rohre oder Leisten
Quadratmeter	MTK	Boden, Beschichtung, Reinigung oder Malerarbeiten
Liter	LTR	Flüssigkeiten, Farben oder Betriebsstoffe
Kilowattstunde	KWH	Energiebezogene Abrechnung
Karton	XCT	Verkauf als vollständige Kartons
Paket	XPK	Definierte Verpackungs- oder Leistungspakete
Palette	XPX	Handels- und Logistikpositionen pro Palette

Wichtig: H87 und C62 sind nicht bloß zwei Schreibweisen für dasselbe Feld. H87 bezeichnet ein Stück als einzelnen Artikel oder einzelnes Exemplar. C62 bedeutet allgemeiner „eins“ beziehungsweise eine Einheit. Entscheidend ist die tatsächliche Geschäftslogik, nicht die Gewohnheit des Rechnungsprogramms.

Für die Stammdaten empfiehlt sich eine Trennung zwischen sichtbarer Bezeichnung, Standardcode und Preisbasis. So kann im Beleg weiterhin „Std.“ stehen, während der Export eindeutig HUR verwendet. Ergänzend sollte dokumentiert werden, ob der Preis pro 1, 10 oder 100 Einheiten gilt und seit wann die Zuordnung freigegeben ist. Bei einer späteren Änderung darf eine bereits ausgestellte Rechnung nicht rückwirkend eine neue Einheit erhalten. Die damals verwendete Bezeichnung, Menge, Preisbasis und Code-Zuordnung müssen mit dem Beleg nachvollziehbar bleiben.

Was bei einer Pauschale in die E-Rechnung gehört

Für „Pauschale“ existiert kein universeller Code, der jede fachliche Bedeutung abdeckt. Eine Pauschale beschreibt meist die Preislogik, nicht die Maßeinheit. Deshalb sollte zuerst geklärt werden, was verkauft wird:

• Eine einmalige Analyse kann als Menge 1 mit einer allgemeinen Einheit und einer präzisen Leistungsbezeichnung abgerechnet werden.
• Ein Wartungspaket kann Menge 1 XPK sein, wenn das Paket als klar definierte Verkaufseinheit geführt wird.
• Eine Tagespauschale bleibt fachlich oft ein Tag und kann daher Menge 1 DAY verwenden.
• Ein Materialpaket sollte nicht pauschal als „Stück“ codiert werden, wenn Bestellung und Preis tatsächlich auf Kartons, Paletten oder Metern beruhen.

Die Positionsbezeichnung muss zusätzlich verständlich erklären, was der Kunde erhält. „Servicepauschale Juli“ ist besser als nur „Pauschale“; noch klarer wäre „Monatliche Systembetreuung Juli inklusive vereinbartem Leistungsumfang“. Der Einheitencode transportiert die maschinenlesbare Mengendimension, nicht den gesamten Vertragsinhalt.

Preisbasismenge: der häufig übersehene zweite Hebel

Viele Preise gelten nicht für genau eine Einheit. Schrauben werden etwa mit 8,50 Euro je 100 Stück angeboten, Kabel mit 75 Euro je 50 Meter oder Reinigungsmittel mit 42 Euro je 10 Liter. Dafür kennt EN 16931 die Preisbasismenge BT-149 und deren Einheit BT-150.

Die Positionsrechnung folgt vereinfacht diesem Zusammenhang:

Positionsnetto = Menge × (Nettopreis ÷ Preisbasismenge) + Zuschläge − Nachlässe

Peppol verlangt, dass die Preisbasismenge größer als null ist. Außerdem muss ihr Einheitencode mit dem Einheitencode der abgerechneten Menge übereinstimmen. Wer 300 Stück berechnet, darf den Preis also auf 100 H87 beziehen, nicht auf 100 Kilogramm. Unterschiedliche physische Dimensionen gehören nicht in dieselbe Preisformel.

Praxisbeispiel 1: Handwerksbetrieb mit Stunden und Kabel

Ein Elektrobetrieb rechnet für einen Gewerbekunden 6,5 Montagestunden zu je 92 Euro und 80 Meter Datenkabel zu 1,85 Euro ab. Die erste Position enthält Menge 6,5, Einheit HUR, Nettopreis 92 und Preisbasismenge 1 HUR. Das ergibt 598 Euro netto. Die zweite Position verwendet Menge 80, Einheit MTR, Nettopreis 1,85 und Preisbasismenge 1 MTR. Das ergibt 148 Euro netto.

Problematisch wäre, beide Positionen mit der Standardangabe „Stück“ zu exportieren. Menschen könnten die Beschreibung noch richtig deuten, eine automatische Bestellprüfung würde aber Stunden oder Meter gegen eine Stückmenge abgleichen. Auch ein Preis je 100 Meter müsste ausdrücklich mit Preisbasismenge 100 MTR modelliert werden.

Praxisbeispiel 2: Großhandel mit Kartons und Einzelartikeln

Ein Getränkehändler verkauft drei Kartons mit je zwölf Flaschen. Entscheidend ist, welche Einheit bestellt und bepreist wurde. Kostet ein Karton 24 Euro, lautet die Rechnungsposition Menge 3 XCT zu 24 Euro je 1 XCT. Kostet eine Flasche 2 Euro und werden 36 Flaschen berechnet, ist Menge 36 H87 plausibel. „3 Stück Getränk“ wäre fachlich unklar, obwohl der Endbetrag zufällig stimmen kann.

Verpackungs- und Rechnungseinheit müssen nicht immer identisch sein. Eine Palette kann nur der Transport dienen, während nach Kilogramm abgerechnet wird. Dann gehört KGM in die Rechnungsposition; Paletteninformationen können ergänzend in Bestellung, Lieferschein oder Beschreibung stehen. Für Recommendation-21-Verpackungscodes ist der Präfix X erforderlich: also beispielsweise XCT statt CT.

Deutschland und Österreich: gleicher Kern, andere Kanäle

In Deutschland konkretisiert XRechnung die EN 16931. Unternehmen sollten für XRechnungen die jeweils aktuelle KoSIT-Spezifikation, die zugehörigen Codelisten und eine aktuelle Validator-Konfiguration verwenden. Ein früher akzeptierter Datensatz muss nicht dauerhaft ohne Warnung oder Fehler bleiben, wenn Prüfartefakte und Codelisten aktualisiert werden. Das spricht für eine Validierung direkt vor dem Versand und nach jedem relevanten Software-Update.

Österreichische Bundesstellen akzeptieren über e-Rechnung.gv.at unter anderem UBL 2.1. Für eine Übertragung über das Peppol-Netzwerk ist UBL vorgesehen; UBL kann dort auch über Upload und Webservice verwendet werden. Österreichische Unternehmen, die sowohl inländische öffentliche Auftraggeber als auch deutsche Kunden beliefern, sollten deshalb nicht zwei freie Einheitenlisten pflegen. Besser ist ein zentraler fachlicher Stammdatensatz, aus dem der jeweilige Export die passende Syntax erzeugt.

Empfängerspezifische Regeln bleiben trotzdem relevant. Bestellplattformen können etwa festlegen, dass eine Position dieselbe Einheit wie die Bestellung verwendet oder dass bestimmte Verpackungseinheiten nicht akzeptiert werden. Die technische Gültigkeit ist daher notwendig, aber nicht immer ausreichend für die fachliche Annahme.

Sechs typische Fehler und ihre Folgen

1. Nur sichtbarer Text: Im PDF steht „Stunde“, im XML fehlt BT-130. Die Rechnung verletzt eine zentrale Geschäftsregel.
2. Standardcode für jede Position: Ein Programm exportiert alles als C62. Beträge können stimmen, Mengenvergleiche mit Bestellung und Wareneingang werden jedoch unzuverlässig.
3. Verpackungscode ohne X: CT wird statt XCT verwendet. Dadurch kann der Code mit Recommendation 20 kollidieren oder als ungültig bewertet werden.
4. Unpassende Preisbasiseinheit: Der Preis gilt je 100 Stück, die Basis wird aber als Kilogramm codiert. Peppol verlangt für BT-150 dieselbe Einheit wie für BT-130.
5. Pauschale ohne Leistungsbezug: Menge 1 und ein allgemeiner Code sind technisch möglich, aber die Position bleibt für Einkauf, Buchhaltung und Prüfung fachlich unklar.
6. Veraltete Zuordnung: Freie Eingaben wie „Pkg“, „Karton“ oder „Std“ werden über Jahre gesammelt, ohne die daraus abgeleiteten Codes nach Software- oder Codelistenupdates erneut zu testen.

Eine gute Fehleranalyse beginnt deshalb nicht erst in der XML-Datei. Sie führt zurück zu Produktstammdaten, Preislogik, Bestelleinheit und der Frage, welche Menge der Kunde tatsächlich kauft. Der Beitrag „Produktstammdaten: Preis, Einheit und Steuer sauber pflegen“ zeigt, wie diese Angaben als gemeinsame Datenbasis organisiert werden können.

Checkliste: Einheiten in acht Schritten bereinigen

1. Einheiten inventarisieren: Alle freien Werte aus Produktkatalog, Angeboten und Rechnungen sammeln, inklusive Varianten wie „Stk“, „Stück“, „pcs“ oder „Std.“.
2. Fachliche Bedeutung festlegen: Pro Artikel oder Leistung klären, ob nach Stück, Zeit, Länge, Fläche, Gewicht, Volumen oder Verpackung abgerechnet wird.
3. Standardcode zuordnen: Einen gültigen Recommendation-20-Code oder einen mit X präfixierten Recommendation-21-Code hinterlegen.
4. Preisbasismenge dokumentieren: Festhalten, ob der Preis je 1, 10, 100 oder 1.000 Einheiten gilt. Null und negative Basismengen ausschließen.
5. Einheiten konsistent halten: Rechnungseinheit und Preisbasiseinheit je Position identisch codieren. Umrechnungen vorher fachlich durchführen.
6. Pauschalen beschreiben: Eine aussagekräftige Positionsbezeichnung und den vereinbarten Leistungsumfang verwenden; den Code nach dem verkauften Gegenstand wählen.
7. Testrechnungen validieren: Mindestens je einen typischen Fall für Ware, Dienstleistung, Verpackung und Preis je Mehrfacheinheit durch den aktuellen Validator schicken.
8. Änderungen kontrollieren: Codelisten- und Exportupdates in den Freigabeprozess aufnehmen und historische Rechnungen unverändert nachvollziehbar halten.

Claribill unterstützt in den Produkt- und Leistungsstammdaten flexible Einheiten sowie Standardbeschreibungen. Damit lässt sich die fachliche Grundlage zentral pflegen, statt dieselbe Angabe in jeder Rechnung neu einzutippen. Vor dem produktiven E-Rechnungsversand bleibt eine technische Prüfung wichtig; der Leitfaden „E-Rechnung validieren: Fehler vor dem Versand finden“ erläutert dafür einen passenden Prüfablauf.

FAQ zu Mengeneinheiten in E-Rechnungen

Muss im PDF der Code H87 statt „Stück“ erscheinen?

Nein. Die menschenlesbare Darstellung kann weiterhin „Stück“ oder „Stk.“ zeigen. Entscheidend ist, dass der strukturierte Datensatz für BT-130 einen gültigen maschinenlesbaren Code enthält.

Ist C62 immer der richtige Code für Pauschalen?

Nein. C62 bezeichnet eine allgemeine Einheit, löst aber nicht die fachliche Frage. Für einen Tagessatz kann DAY, für ein definiertes Paket XPK und für einen einzelnen Artikel H87 treffender sein. Vertrag und Empfängervorgaben sind mitzudenken.

Darf der Preis je 100 Stück angegeben werden?

Ja. Dann beträgt die Preisbasismenge 100 und ihre Einheit entspricht der Rechnungsmenge, beispielsweise jeweils H87. Der Validator prüft unter anderem, dass die Basismenge positiv ist und die Codes übereinstimmen.

Reicht eine einmalige Prüfung der Stammdaten?

Nein. Technische Komponenten und Codelisten werden weiterentwickelt. Unternehmen sollten Zuordnungen nach Exportupdates erneut testen und zusätzlich kontrollieren, ob Kunden oder öffentliche Auftraggeber eigene Bestell- und Einheitenregeln vorgeben.

Fazit: Die Einheit ist Teil der Geschäftslogik

Mengeneinheiten sind in E-Rechnungen kein dekoratives Kürzel. Sie verbinden die verkaufte Leistung mit Menge, Preisbasis, Bestellung und automatischer Buchung. Wer Stück, Stunden, Meter, Kartons und Pauschalen im Stammdatensatz fachlich trennt, reduziert Ablehnungen und Rückfragen. Der wirksamste Ablauf lautet: Bedeutung klären, Standardcode zuordnen, Preisbasis prüfen, Testfälle validieren und Änderungen kontrolliert ausrollen.

Für die Wahl des Übertragungsformats hilft ergänzend der Vergleich „XRechnung oder ZUGFeRD: Welches Format passt wann?“. Die Formatentscheidung ändert jedoch nichts an der Kernaufgabe: Jede Position braucht eine eindeutige Menge, eine passende Einheit und eine nachvollziehbare Preislogik.

Quellen

• XStandards Einkauf / KoSIT: Versionen und Bundles der XRechnung
• XStandards Einkauf / KoSIT: FAQ zur XRechnung
• OpenPeppol: Peppol BIS Billing 3.0, Regeln und Berechnung auf Positionsebene
• OpenPeppol: Recommendation 20 einschließlich präfixierter Recommendation-21-Codes
• e-Rechnung.gv.at: UBL 2.1 und Übermittlungskanäle