Übungsaufgaben zur E-Rechnung

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „E-Rechnung“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/e-rechnung
- https://oer-informatik.de/xml-einstieg
- Stilbeispiel: https://oer-informatik.de/e-rechnung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- E-Rechnung
- EN 16931
- XRechnung
- ZUGFeRD
- XML
- CII
- UBL
- Validierung

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Semantisches Datenmodell (2 Punkte): legt fest, welche Angaben eine Rechnung enthalten kann oder muss und was sie bedeuten (business terms wie Rechnungsnummer BT-1, Rechnungsdatum BT-2, Käuferreferenz BT-10) sowie Geschäftsregeln, wie die Angaben zusammenhängen (z. B. fälliger Betrag = Gesamtbetrag − bereits gezahlter Betrag + Rundung). Es ist unabhängig von einem Dateiformat.

• Syntax (2 Punkte): legt fest, wie diese Angaben in eine Datei geschrieben werden, also Elementnamen, Verschachtelung und Reihenfolge in XML. Erlaubt sind UBL 2.1 und UN/CEFACT CII. Deshalb kann dieselbe Rechnung in zwei unterschiedlich aussehenden, aber gleichwertigen XML-Dateien stehen.

Bewertung: je Begriff 1 Punkt für die Kernaussage, 1 Punkt für Beispiel bzw. Begründung aus dem Text.

Wenn XML und PDF getrennt erzeugt werden, können sie voneinander abweichen (z. B. anders gerundete Beträge, vergessener Rabatt, alte Adresse in der Vorlage) (1 Punkt). Laut Text ist das PDF nur eine Ansicht; bei Widersprüchen gelten die strukturierten Daten (XML) (1 Punkt). Die Kundin bzw. der Kunde sieht dann im PDF einen anderen Betrag, als rechtlich gilt und vom ERP-System verbucht wird – Rückfragen, Fehlzahlungen und eine fehlerhafte Rechnung sind die Folge. Beide Teile müssen daher aus derselben Datenquelle erzeugt werden, am besten das PDF aus der XML (1 Punkt).

• PDF: Für die Software ist das PDF nur eine Seite, auf der Text an bestimmten Stellen steht. Sie kann nicht sicher erkennen, welche Zeichenfolge die Rechnungsnummer und welche Zahl der Zahlbetrag ist. Jemand muss die Werte abtippen, oder eine Texterkennung errät sie anhand des Layouts und ein Mensch kontrolliert das Ergebnis (1 Punkt).

• ZUGFeRD: Im PDF steckt zusätzlich eine XML-Datei nach EN 16931. Jede Angabe hat dort ein festgelegtes Element (Rechnungsnummer, jede einzelne Position, fälliger Betrag), sodass die Software sie ohne Raten übernehmen, prüfen und buchen kann (1 Punkt).

• Folgerung: Entscheidend ist nicht, dass die Rechnung elektronisch verschickt wird, sondern ob ihre Daten strukturiert vorliegen und sich automatisch verarbeiten lassen. Das reine PDF ist deshalb eine „sonstige Rechnung“ (1 Punkt).

Bewertung: je Zeile 1 Punkt für die richtige Entscheidung und 1 Punkt für die Begründung. In Zeile 3 auch „ja, wegen der Vorgaben für öffentliche Auftraggeber/E-Rechnungsverordnung“ als richtig werten; Leitweg-ID oder Portal sind für die volle Punktzahl nicht nötig.

Nein. Unternehmen mit höchstens 800.000 € Gesamtumsatz im Vorjahr dürfen 2027 noch sonstige Rechnungen ausstellen (Papier; PDF mit Zustimmung des Empfängers) (1 Punkt). Erst ab 01.01.2028 muss auch Senne Velo E-Rechnungen schicken. Für CSB-Rad selbst gilt die Übergangsregel nicht, weil der Vorjahresumsatz weit über 800.000 € liegt (1 Punkt).

Je 1 Punkt, z. B.:

• als Anhang einer E-Mail (XML-Datei bzw. ZUGFeRD-PDF),

• Upload in das Rechnungsportal des öffentlichen Auftraggebers,

• über das Peppol-Netzwerk,

• Bereitstellung zum Download im Händlerportal bzw. direkte Übertragung an das ERP-System des Kunden über eine Schnittstelle (API, EDI) nach Vereinbarung.

Je Maßnahme 2 Punkte (1 Punkt Einschätzung, 1 Punkt Begründung), z. B.:

Fazit: 1, 2 und 5 zusammen ergeben einen tragfähigen Testplan; 3 wird gestrichen, 4 bleibt höchstens als fachliche Stichprobe.

Fehler (2 Punkte): Der fällige Betrag DuePayableAmount (5.492,80 €) weicht vom Gesamtbetrag GrandTotalAmount (5.604,90 €) ab, obwohl nichts angezahlt wurde. Das Modul hat den Skonto (2 % von 5.604,90 € = 112,10 €) schon abgezogen. Skonto ist aber nur eine Zahlungsbedingung, die in SpecifiedTradePaymentTerms beschrieben wird; abziehen darf ihn erst die Kundin bzw. der Kunde, wenn rechtzeitig gezahlt wird.

Die übrigen Werte stimmen: Position 1: 6 · 671,43 € = 4.028,58 €, abzüglich 15 % (604,29 €) = 3.424,29 €; mit Position 2 (1.285,71 €) ergibt sich 4.710,00 € netto, 19 % USt = 894,90 €, brutto 5.604,90 €.

Richtiger Wert (1 Punkt): DuePayableAmount = 5.604,90 € (gleich GrandTotalAmount).

Welche Maßnahmen ihn finden (2 Punkte):

• Maßnahme 1 (XSD) nicht: 5492.80 ist eine gültige Dezimalzahl an einer erlaubten Stelle; rechnerische Zusammenhänge zwischen Elementen kennt ein Schema nicht.

• Maßnahme 2 (Validator) ja: Die Geschäftsregel BR-CO-16 der EN 16931 (fälliger Betrag = Gesamtbetrag − bereits gezahlter Betrag + Rundungsbetrag) ist verletzt; die Testrechnung wird abgelehnt.

• Maßnahme 5 nur bedingt: Nur wenn ein Testfall mit Skontobedingung erwartet, dass der fällige Betrag dem Bruttobetrag entspricht. Wer beim Schreiben des Tests denselben Denkfehler macht, bestätigt den Fehler sogar.

• Maßnahme 4 eher nicht: Das PDF wird aus denselben Daten erzeugt und zeigt denselben Betrag; auffallen würde er nur, wenn Natalia die Skontoregel genau im Blick hat.

Bewertung: 1 Punkt für die richtig begründete Einschätzung von Maßnahme 1 und 2, 1 Punkt für Maßnahme 4 oder 5.

• Aussage 1 trifft nicht zu (2 Punkte): Laut Text prüft invoice-lens die Dateien nicht. Eine ordentliche Darstellung belegt also nicht, dass die Rechnung die Regeln der EN 16931 erfüllt – und erst recht nicht, dass Leistung und Preis stimmen. Das Modul muss die Datei vor der Anzeige validieren, und Clara muss die Rechnung vor der Freigabe sachlich prüfen.

• Aussage 2 trifft zu (2 Punkte): Das Layout entsteht erst im Viewer und ist kein Teil der Rechnung; zwei Viewer dürfen dieselbe Rechnung unterschiedlich darstellen. Ein eigenes Stylesheet ändert nur die Ansicht, die XML-Daten bleiben unverändert. Maßgeblich bleibt die Originaldatei, die auch so archiviert wird.

• Eine XML-Rechnung ist für die automatische Verarbeitung gebaut: Das System liest Lieferant, Positionen und Betrag direkt aus den Elementen und kann buchen, ohne dass jemand tippt (1 Punkt).

• Menschen müssen Rechnungen trotzdem ansehen, etwa für die Freigabe oder wenn ein Lieferant wegen einer Zahlung nachfragt. Rohes XML ist dafür unübersichtlich; ein Viewer wandelt die Daten deshalb in eine lesbare Seite um (1 Punkt).

• Ein PDF ist von vornherein eine Seite für Menschen und braucht keinen Viewer, enthält aber keine Daten, die eine Software sicher auslesen kann. Bei der E-Rechnung ist es umgekehrt: Die Daten sind das Original, die Ansicht wird bei Bedarf daraus erzeugt (1 Punkt).

Bewertung: je Zeile 1 Punkt für die richtige Entscheidung, 1 Punkt für die Begründung. Für das Modul folgt daraus: Es braucht neben dem automatischen Weg einen zweiten Weg für sonstige Rechnungen.

Vier Schritte in sinnvoller Reihenfolge, je 1 Punkt, z. B.:

1. Anhang abholen und Format erkennen: XML-Datei (UBL oder CII) direkt übernehmen, bei PDF/A-3 die eingebettete XML herauslösen; Rechnungen ohne strukturierte Daten in einen Sonderweg (manuelle Erfassung) leiten.

2. Validieren: Schema und Geschäftsregeln (EN 16931, ggf. XRechnung) prüfen, Prüfbericht speichern; bei Fehlern Rückfrage an den Absender.

3. Abgleichen: Lieferant bekannt? Käuferreferenz bzw. Bestellnummer vorhanden? Betrag und Leistung passen zu Bestellung bzw. Vertrag? Rechnungsnummer noch nicht erfasst (keine Doppelzahlung)?

4. Zur Freigabe vorlegen: Anzeige mit dem Viewer, Freigabe durch Clara (z. B. ab einer Betragsgrenze), danach Übergabe der Daten an Buchhaltung bzw. Steuerbüro und Zahlung.

5. Auch richtig: Originaldatei unverändert archivieren (siehe Teilaufgabe f).

Der Validator prüft nur, ob die Datei formal stimmt: Schema (Struktur, Datentypen) und Geschäftsregeln (z. B. ob die Summen zueinander passen) (1 Punkt). Er prüft nicht, ob die Rechnung inhaltlich richtig ist: ob Let’s Meet die Leistung bestellt und erhalten hat, ob die Preise dem Vertrag entsprechen, ob die Rechnung schon bezahlt wurde oder ob sie überhaupt von einem echten Lieferanten stammt (Betrug mit gefälschten Rechnungen) (1 Punkt). Deshalb braucht es den Abgleich mit Bestellung bzw. Vertrag und bei Abweichungen oder höheren Beträgen eine Freigabe durch einen Menschen; auch die Finanzverwaltung betont, dass eine Validierung die Prüfung durch den Empfänger nicht ersetzt (1 Punkt).

• Rechnungsnummer: TRZ-2026-10873 (cbc:ID) (1 Punkt)

• Fälligkeitsdatum: 16.11.2026 (cbc:DueDate) (1 Punkt)

• zu zahlender Betrag: 2.261,00 € (cbc:PayableAmount) (1 Punkt)

Hinweis: IssueDate (02.11.2026) ist das Rechnungsdatum, TaxInclusiveAmount der Bruttobetrag; zu zahlen ist PayableAmount, das hier gleich ist, weil nichts angezahlt wurde.

• Das Modul liest die Datei mit einem XML-Parser und greift über den Elementpfad (z. B. per XPath /ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount unter Beachtung der Namensräume) auf genau ein Element zu, dessen Bedeutung festgelegt ist (fälliger Betrag, BT-115) (1 Punkt).

• Der Wert hat ein festes, maschinenlesbares Format (Dezimalpunkt, keine Tausenderpunkte) und die Währung steht im Attribut currencyID (1 Punkt).

• In einem PDF ohne XML sind die Angaben nur Text an einer Position auf der Seite. Das Programm müsste per Texterkennung und Mustersuche raten, welche Zahl der Endbetrag ist (Netto, Brutto, Zwischensumme, Skontobetrag?) und wie sie formatiert ist; jedes Layout ist anders – das ist fehleranfällig (1 Punkt).

Der Vorschlag ist nicht zulässig (Stellungnahme 1 Punkt):

• Rechnungen müssen acht Jahre aufbewahrt werden (§ 14b UStG); bei E-Rechnungen mindestens der strukturierte Teil unverändert in der ursprünglichen Form, also die empfangene XML-Datei bzw. das ZUGFeRD-PDF. Ein Datensatz in einer eigenen Tabelle ist eine Umwandlung und ersetzt das Original nicht; nach den GoBD muss das Archiv unveränderbar und maschinell auswertbar sein (1 Punkt).

• Die Datenminimierung steht dem nicht entgegen: Die gesetzliche Aufbewahrungspflicht ist eine Rechtsgrundlage für die Speicherung (Art. 6 Abs. 1 lit. c DSGVO). Datenschutzgerecht ist es, die Originale in einem zugriffsgeschützten Archiv zu speichern und nach Ablauf der Frist zu löschen (1 Punkt).

Die zusätzliche Übernahme der Daten in die Datenbank für Auswertungen ist erlaubt. Speicherplatz ist bei rund 120 Rechnungen pro Monat kein Argument (eine E-Rechnung ist meist nur wenige bis einige hundert Kilobyte groß).

Je Anfrage 3 Punkte (1 Punkt für die zutreffende Aussage, 2 Punkte für die Begründung). Stand der Rechtslage: Oktober 2026.

Für eine verbindliche Auskunft im Einzelfall verweist das Systemhaus auf eine Steuerberatung; die Stellungnahmen sind eine technische Beratung.

Je Aussage 1 Punkt:

Je Vorteil bzw. Nachteil 2 Punkte (1 Punkt für die Nennung, 1 Punkt für die Beschreibung), z. B.:

Auch richtig: Variante A braucht eine Anfangsinvestition, ist dafür bei vielen Rechnungen günstiger; Variante B braucht eine stabile Internetverbindung.

• Rechnungen enthalten personenbezogene Daten (z. B. Namen und Kontaktdaten der Ansprechpersonen bei den Firmenkunden, bei Einzelunternehmen auch Namen der Inhaber*innen, Bankverbindungen) (1 Punkt).

• Der Cloud-Anbieter verarbeitet diese Daten im Auftrag des Modehauses. Deshalb muss vorher ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO geschlossen werden (1 Punkt).

• Darin werden u. a. Zweck, Weisungsbindung, technische und organisatorische Maßnahmen (Verschlüsselung, Zugriffsschutz, Datensicherung), Unterauftragnehmer und die Löschung bzw. Rückgabe der Daten nach Vertragsende geregelt; zu prüfen sind außerdem der Serverstandort (hier EU, Frankfurt) und die Exportmöglichkeit für das Archiv (1 Punkt).

Beide Empfehlungen sind möglich, wenn sie mit den Angaben begründet werden (1 Punkt Entscheidung, 2 Punkte Begründung). Beispiel:

Ich empfehle Variante B. Mit 60 Rechnungen im Monat ist die Menge überschaubar, sodass die Kosten je Rechnung gering bleiben. Der Laden hat keine eigene IT-Abteilung; der Anbieter hält Formate und Prüfregeln aktuell und übernimmt Archiv und Datensicherung, was der kleine Server im Büro nur mit zusätzlichem Aufwand leisten würde. Voraussetzung ist ein Vertrag zur Auftragsverarbeitung und die Zusage, dass alle Rechnungen jederzeit in den Originalformaten exportiert werden können.

Ebenso vertretbar: Variante A, weil die Warenwirtschaft ohnehin von Lutterkolk betreut wird, die Daten im Haus bleiben und langfristig keine Kosten je Rechnung anfallen – dann muss aber ein GoBD-konformes Archiv mit Datensicherung eingeplant werden.

Je Anforderung 2 Punkte, z. B.:

• Aufbewahrungsfrist: Rechnungen müssen seit 2025 acht Jahre aufbewahrt werden (§ 14b UStG; vorher zehn Jahre). Wer nach sechs Jahren löscht, verstößt gegen die Aufbewahrungspflicht.

• Unveränderbarkeit: Nach den GoBD dürfen archivierte Rechnungen nicht unbemerkt verändert oder gelöscht werden; Änderungen müssen nachvollziehbar sein. Mit Schreibzugriff für alle kann jede*r Datei ändern, überschreiben oder löschen. Nötig ist z. B. ein Archiv mit Schreibschutz nach dem Ablegen (WORM) oder Versionierung.

• Originalformat: Mindestens der strukturierte Teil (XML bzw. ZUGFeRD-PDF mit eingebetteter XML) muss unverändert in der empfangenen bzw. versendeten Form gespeichert werden; ein Ausdruck oder eine umgewandelte Datei reicht nicht.

• Zugriffsschutz und Protokollierung: Nur berechtigte Personen dürfen auf Rechnungen zugreifen (auch wegen personenbezogener Daten); Zugriffe und Änderungen werden protokolliert.

• Wiederauffindbarkeit und maschinelle Auswertbarkeit: Rechnungen müssen über einen Index (z. B. Rechnungsnummer, Datum, Geschäftspartner) in angemessener Zeit auffindbar und für eine Betriebsprüfung auswertbar sein.

• Datensicherung: Ein einzelnes NAS ohne Sicherung kann ausfallen; die Daten müssen über die gesamte Frist lesbar bleiben.

ea) Sinnvoll ist B – D – E – A – F – C (3 Punkte; kleinere, begründete Abweichungen sind möglich, z. B. F und C tauschen oder die Verfahrensdokumentation schon während des Tests beginnen; B muss am Anfang stehen, A nach D und E).

Begründung: Erst wenn bekannt ist, was gebraucht wird (B), lässt sich eine Lösung auswählen (D). Die Lösung braucht korrekte Stammdaten (E), bevor Testrechnungen sinnvoll sind (A). Erst der getestete Ablauf wird dokumentiert (F) und geschult (C).

eb) Die Verfahrensdokumentation nach den GoBD beschreibt nachvollziehbar, wie Rechnungen erzeugt bzw. empfangen, geprüft, freigegeben, gebucht und archiviert werden: beteiligte Systeme und Schnittstellen, Zuständigkeiten und Berechtigungen, Kontrollen (z. B. Validierung, Freigabegrenzen), Ablage und Aufbewahrung sowie Datensicherung (2 Punkte). Sie muss so verständlich sein, dass eine sachverständige dritte Person (z. B. bei einer Betriebsprüfung) den Ablauf in angemessener Zeit nachvollziehen kann.

aa) Je Angabe 1 Punkt (Element und Wert):

Wenn Dir beim Lesen schon auffällt, dass 6 · 78,00 € nicht 486,00 € ergibt, bist Du Teilaufgabe b) voraus.

ab)

• Präfixe/Namensräume (2 Punkte): cbc: und cac: sind Kürzel für Namensräume, die im Wurzelelement über xmlns:cbc="…" bzw. xmlns:cac="…" festgelegt sind. Sie zeigen, aus welchem Teil des UBL-Vokabulars ein Element stammt: cbc (Common Basic Components) für einfache Werte wie cbc:DueDate, cac (Common Aggregate Components) für Elemente, die weitere Elemente enthalten, wie cac:InvoiceLine. Gleich lautende Namen aus anderen Standards können so nicht verwechselt werden.

• Elementinhalt und Attribut (2 Punkte): In <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> ist „EUR“ der Inhalt des Elements – die Rechnungswährung ist hier selbst die Angabe. In <cbc:PayableAmount currencyID="EUR">5381.18</cbc:PayableAmount> ist der Betrag der Inhalt; die Währung steht als Attribut im Start-Tag und ergänzt den Wert um eine Zusatzinformation (ebenso unitCode bei der Menge).

ac) Die Leitweg-ID ist eine Adresse für die Zustellung von Rechnungen an öffentliche Auftraggeber. Sie gibt an, welche Behörde bzw. Dienststelle (hier die Schul-IT OWL) die Rechnung bekommt, damit das Rechnungsportal sie automatisch an die richtige Stelle weiterleitet (1 Punkt). In der XRechnung ist sie als Käuferreferenz (BT-10) Pflicht; der Auftraggeber teilt sie dem Lieferanten bei der Bestellung mit (1 Punkt).

ba)

Geg.: Pos. 1: n_1 = 4, p_1 = 389{,}00\ €; Pos. 2: n_2 = 2, p_2 = 1.240{,}00\ €; Pos. 3: n_3 = 6\ \text{h}, p_3 = 78{,}00\ €/\text{h}; Steuersatz s = 19\ \%; Rechnung: N_R = 4.522{,}00\ €, B_R = 5.381{,}18\ €

Ges.: richtiger Nettobetrag N, Umsatzsteuer U, Bruttobetrag B, Differenz \Delta B

\begin{aligned} \text{I}\quad N &= n_1 \cdot p_1 + n_2 \cdot p_2 + n_3 \cdot p_3\\ N &= 4 \cdot 389{,}00\ € + 2 \cdot 1.240{,}00\ € + 6\ \text{h} \cdot 78{,}00\ €/\text{h}\\ N &= 1.556{,}00\ € + 2.480{,}00\ € + 468{,}00\ €\\ N &= \underline{\underline{4.504{,}00\ €}} \end{aligned}

Position 3 ist mit 486,00 € statt 468,00 € berechnet (Zahlendreher); Positionen 1 und 2 stimmen (2 Punkte für das Finden des Fehlers und den richtigen Nettobetrag).

\begin{aligned} \text{II}\quad U &= N \cdot s = 4.504{,}00\ € \cdot 0{,}19 = \underline{\underline{855{,}76\ €}}\\ \text{III}\quad B &= N + U = 4.504{,}00\ € + 855{,}76\ € = \underline{\underline{5.359{,}76\ €}} \end{aligned}

(2 Punkte für Umsatzsteuer und Bruttobetrag)

\Delta B = B_R - B = 5.381{,}18\ € - 5.359{,}76\ € = \underline{\underline{21{,}42\ €}}

Die Rechnung ist um 18,00 € netto bzw. 21,42 € brutto zu hoch (2 Punkte). Die Umsatzsteuer der Rechnung (859,18 € = 19 % von 4.522,00 €) und die Summen sind in sich stimmig – sie bauen nur auf dem falschen Positionsbetrag auf.

bb)

• Das Portal prüft die Datei gegen das Schema (Struktur, Datentypen) und die Geschäftsregeln der EN 16931 und der XRechnung, z. B. ob die Summe der Positionsbeträge dem Gesamtnettobetrag entspricht und ob Pflichtangaben wie die Leitweg-ID vorhanden sind. Diese Regeln sind erfüllt, weil alle Summen konsequent mit 486,00 € weiterrechnen (1 Punkt).

• Ob der Positionsbetrag zu Menge und Preis passt und ob die Preise dem Auftrag entsprechen, ist damit nicht geprüft; die vereinbarten Preise kennt das Portal ohnehin nicht (1 Punkt).

• Die Validierung zeigt also nur, dass die Rechnung formal korrekt ist. Die sachliche und rechnerische Prüfung (Abgleich mit Auftrag und Lieferbestätigung, Nachrechnen der Positionen) bleibt Aufgabe der Rechnungsstelle bzw. eines automatischen Abgleichs mit den Bestelldaten im ERP-System (1 Punkt).

Beide Entscheidungen sind vertretbar, wenn sie begründet werden (1 Punkt Entscheidung, 3 Punkte Begründung). Beispiel:

Ich empfehle, bei der reinen XRechnung zu bleiben:

• Für Bernd wäre das PDF bequemer: Er könnte die Rechnung wie gewohnt öffnen, drucken und weiterleiten. Der Gewinn ist aber klein, weil das Rechnungsportal bzw. ein Viewer die XRechnung ohnehin lesbar darstellt (1 Punkt).

• Welche Formate angenommen werden, legt der öffentliche Auftraggeber bzw. sein Rechnungsportal fest. Ein ZUGFeRD-Profil müsste die XRechnung-Regeln (z. B. Leitweg-ID) erfüllen und vom Portal akzeptiert werden; das wäre vorher zu klären (1 Punkt).

• PDF-Ansicht und eingebettete XML können voneinander abweichen. Maßgeblich ist dann der strukturierte Teil; wer nur das PDF liest, prüft womöglich andere Beträge als die, die gebucht werden. Die Rechnungsstelle müsste also trotzdem die XML-Daten prüfen (1 Punkt).

Ebenso vertretbar: das Angebot annehmen, wenn das Portal das Format (z. B. ZUGFeRD-Profil XRECHNUNG) akzeptiert und die Rechnungsstelle verbindlich mit den XML-Daten arbeitet.

Der Vorschlag ist abzulehnen (1 Punkt):

• Die empfangene E-Rechnung muss unverändert in ihrer ursprünglichen Form aufbewahrt werden; nach den GoBD darf ein Beleg nicht nachträglich unbemerkt verändert werden. Eine selbst geänderte Datei ist kein Originalbeleg mehr und passt nicht mehr zum Prüfbericht des Portals; außerdem wäre unklar, welcher Betrag tatsächlich gefordert wurde (1 Punkt).

• Die Rechnung kann nur der Rechnungssteller berichtigen. Die Schul-IT beanstandet die Rechnung bei der Netzwerkbau Ostwestfalen GmbH und bittet um eine korrigierte Rechnung (bzw. Stornorechnung und neue Rechnung) über 5.359,76 €. Da die Fälligkeit erst am 18.12.2026 liegt, ist dafür genug Zeit; alternativ kann der unstrittige Betrag nach den Regeln der Rechnungsstelle bezahlt und die Differenz geklärt werden (1 Punkt).