Block 06 · Schnittstellen & Datenformate

A · Erklärungssatz

Schnittstellen und Datenformate kamen in 8 von 9 Prüfungen vor, fast immer in Teil 1 als eine Teilaufgabe von 6 bis 25 Punkten. Die Fragen sind meist Wissens- und Verständnisfragen („Erläutern Sie …“, „Beschreiben Sie die Parameter …“), dazu kommen Anwendungsaufgaben: XML-Fehler anhand einer DTD finden, Tabellen in JSON überführen, eine HTTP-Antwort im Code zusammenbauen. Einen Belegsatz mit Notationshilfen gibt es für diesen Block nicht – Syntax und Begriffe musst du selbst können.

Punkte des Blocks je Prüfung: W21 2 · S22 – · W22 13 · S23 13 · W23 14 · S24 25 · W24 18 · W25 24 · S26 12.

SD-01 · XML Meistens

Vorkommen: JSON/XML zusammen 6/9 (W22, S23, W23, S24, W24, W25) · XML konkret: W22 T1 A3c (13 P: Zweck der DTD, wohlgeformt/gültig, Fehler finden), W25 T1 A3bc (6 P: warum Schema-Validierung nicht reicht); eRechnungen (W25) sind XML-Dokumente

Was ist XML?

XML (Extensible Markup Language) ist eine textbasierte Auszeichnungssprache für hierarchisch strukturierte Daten. Sie ist für Menschen und Maschinen lesbar, plattform- und programmiersprachenunabhängig und wird vor allem für den Datenaustausch zwischen Systemen verwendet (eRechnung, Behördenstandards, SOAP-Webservices, Konfigurationsdateien, Office-Dateiformate). Anders als HTML gibt XML keine Elementnamen vor („extensible“): Die Namen legt man selbst fest. Welche Elemente in welcher Reihenfolge erlaubt sind, beschreibt eine DTD oder ein XML-Schema (XSD).

Aufbau eines XML-Dokuments

Beispiel: Spielplan eines Stadttheaters (die Zeilennummern gehören nicht zum Dokument).

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <!DOCTYPE spielplan SYSTEM "spielplan.dtd">
 3  <!-- Spielplan des Stadttheaters (Auszug) -->
 4  <spielplan saison="2026/27">
 5    <vorstellung id="v1" saal="gross">
 6      <stueck>Der Besuch der alten Dame</stueck>
 7      <datum>2026-11-14</datum>
 8      <preis>32.00</preis>
 9    </vorstellung>
10    <vorstellung id="v2" saal="studio" ausverkauft="ja">
11      <stueck>Momo</stueck>
12      <datum>2026-11-15</datum>
13      <preis>12.50</preis>
14      <hinweis>ab 8 Jahren</hinweis>
15      <hinweis>Einführung 19:15 Uhr</hinweis>
16    </vorstellung>
17  </spielplan>

Element oder Attribut? Faustregel: Attribute für Kennungen und kurze Metadaten (id, saal, einheit), Elemente für die eigentlichen Daten – und immer dann, wenn ein Wert mehrfach vorkommen oder selbst Struktur haben kann (Attribute sind nicht wiederholbar und nicht verschachtelbar).

Namensräume (namespaces) verhindern Namenskonflikte, wenn Elemente aus verschiedenen Vokabularen in einem Dokument zusammenkommen. Ein Namensraum wird durch eine eindeutige URI bezeichnet (sie muss nicht abrufbar sein) und entweder als Standardnamensraum (xmlns="…") oder mit Präfix (xmlns:cbc="…", Elemente dann <cbc:ID>) deklariert. eRechnungen im UBL-Format nutzen z. B. die Präfixe cbc und cac (Beispiel in SD-05).

Wohlgeformt und gültig

DTD (Document Type Definition)

Die DTD ist die Grammatik (der Bauplan) eines Dokumenttyps: Sie legt fest, welche Elemente und Attribute vorkommen dürfen, in welcher Reihenfolge und wie oft. Wofür? Damit Sender und Empfänger eine gemeinsame, verbindliche Struktur haben (Schnittstellenvertrag) und eingehende Dokumente automatisch geprüft (validiert) werden können, bevor sie verarbeitet werden. Die DTD kann im Dokument stehen (interne DTD in <!DOCTYPE spielplan [ … ]>) oder – wie oben – in einer externen Datei, auf die die DOCTYPE-Deklaration mit SYSTEM "datei.dtd" verweist; so können viele Dokumente dieselbe DTD nutzen.

 1  <!ELEMENT spielplan (vorstellung+)>
 2  <!ATTLIST spielplan saison CDATA #REQUIRED>
 3  <!ELEMENT vorstellung (stueck, datum, preis, hinweis*)>
 4  <!ATTLIST vorstellung id          ID             #REQUIRED
 5                        saal        (gross|studio) "gross"
 6                        ausverkauft (ja|nein)      #IMPLIED>
 7  <!ELEMENT stueck  (#PCDATA)>
 8  <!ELEMENT datum   (#PCDATA)>
 9  <!ELEMENT preis   (#PCDATA)>
10  <!ELEMENT hinweis (#PCDATA)>

Kardinalitäten gelten auch für Gruppen: (telefon | email)+ heißt „mindestens ein Kontakt, jeweils Telefon oder E-Mail“. Lies die DTD aus Zeile 3 so: Eine Vorstellung besteht aus genau einem Stück, dann genau einem Datum, dann genau einem Preis, danach beliebig vielen Hinweisen – genau in dieser Reihenfolge.

So gehst du vor: Fehler in einem XML-Dokument anhand der DTD finden

1. DTD in Worte fassen: Für jedes Element notieren, welche Kinder in welcher Reihenfolge und Anzahl erlaubt sind; für jedes Attribut: Pflicht? erlaubte Werte? ID?
2. Erster Durchgang – Wohlgeformtheit, Zeile für Zeile: passt jedes End-Tag exakt (auch Groß-/Kleinschreibung, Schrägstrich)? Ist alles korrekt verschachtelt und geschlossen? Stehen alle Attributwerte in Anführungszeichen?
3. Zweiter Durchgang – Gültigkeit: Ist jedes Element und Attribut deklariert? Stimmen Reihenfolge und Anzahl der Kinder? Fehlen Pflichtelemente oder Pflichtattribute? Sind Aufzählungswerte erlaubt? Kommt ein ID-Wert doppelt vor?
4. Antwort je Fehler: Zeile, kurze Beschreibung („End-Tag passt nicht zum Start-Tag“), verletzte Eigenschaft (Wohlgeformtheit oder Gültigkeit).

Beispiel: Auszug mit Fehlern, geprüft gegen die Spielplan-DTD von oben.

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <!DOCTYPE spielplan SYSTEM "spielplan.dtd">
 3  <spielplan saison="2026/27">
 4    <vorstellung id="v3" saal="foyer">
 5      <datum>2026-11-20</datum>
 6      <stueck>Faust</stueck>
 7      <preis>18.00</preis>
 8    </vorstellung>
 9    <vorstellung id="v3">
10      <stueck>Woyzeck</Stueck>
11      <datum>2026-11-21</datum>
12      <preis>21.00</preis>
13    </vorstellung>
14  </spielplan>

XML-Schema (XSD)

Ein XML-Schema (XML Schema Definition, Dateiendung .xsd) erfüllt denselben Zweck wie eine DTD, ist aber selbst ein XML-Dokument und deutlich mächtiger: Es kennt Datentypen, Wertebereiche, genaue Mindest- und Höchstanzahlen und Namensräume. eRechnungen (UBL, CII) werden mit XSD-Dateien beschrieben. Dasselbe Spielplan-Format als XSD:

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 3    <xs:element name="spielplan">
 4      <xs:complexType>
 5        <xs:sequence>
 6          <xs:element ref="vorstellung" maxOccurs="unbounded"/>
 7        </xs:sequence>
 8        <xs:attribute name="saison" type="xs:string" use="required"/>
 9      </xs:complexType>
10    </xs:element>
11    <xs:element name="vorstellung">
12      <xs:complexType>
13        <xs:sequence>
14          <xs:element name="stueck"  type="xs:string"/>
15          <xs:element name="datum"   type="xs:date"/>
16          <xs:element name="preis"   type="betrag"/>
17          <xs:element name="hinweis" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
18        </xs:sequence>
19        <xs:attribute name="id"          type="xs:ID"      use="required"/>
20        <xs:attribute name="saal"        type="xs:string"  default="gross"/>
21        <xs:attribute name="ausverkauft" type="xs:string"/>
22      </xs:complexType>
23    </xs:element>
24    <xs:simpleType name="betrag">
25      <xs:restriction base="xs:decimal">
26        <xs:minInclusive value="0"/>
27        <xs:fractionDigits value="2"/>
28      </xs:restriction>
29    </xs:simpleType>
30  </xs:schema>

Warum eine Schema-Validierung allein nicht reicht

DTD und XSD prüfen Struktur und (nur XSD) Datentypen einzelner Felder. Sie prüfen nicht, ob die Inhalte fachlich zueinander passen. Am Spielplan-Beispiel:

Für solche logischen Fehler braucht man zusätzlich Geschäftsregeln: Plausibilitätsprüfungen im Programmcode, Regeln in Schematron (XML-basierte Regelsprache mit XPath-Ausdrücken, z. B. <sch:assert test="gesamt = sum(position/betrag)">), Unit-Tests mit Testdokumenten und – bei Standards wie der eRechnung – den offiziellen Validator, der Schema und Schematron prüft.

SD-02 · JSON Meistens

Vorkommen: JSON/XML zusammen 6/9 · JSON konkret: S23 T1 A4cb (JSON-Sensordaten in ein Relationenmodell übernehmen), W23 T1 A3c (14 P: Tabellen in JSON überführen, Embedding), S24 T1 A2c (JSON-Body eines Requests), W24 T1 A2c (8 P: Skript mit JSON-Ausgabe)

Syntax

JSON (JavaScript Object Notation) ist ein schlankes, textbasiertes Datenaustauschformat. Es ist das Standardformat von REST-APIs und dokumentenorientierten NoSQL-Datenbanken (z. B. MongoDB). Medientyp: application/json, Zeichenkodierung UTF-8. JSON kennt genau sechs Arten von Werten:

Objekte und Arrays lassen sich beliebig verschachteln. Schlüssel sind immer Strings in doppelten Anführungszeichen. Ein Datum hat keinen eigenen Typ – es wird als String geschrieben, üblich im ISO-Format "JJJJ-MM-TT".

Beispiel: Die Tabelle Kurs eines Sportvereins …

… als JSON-Dokument mit einem Array kurse:

{
  "kurse": [
    { "kursNr": 101, "titel": "Rückenfit", "trainerin": "Meyer", "plaetze": 12,
      "ausgebucht": false, "beitrag": 45.00, "start": "2026-09-07" },
    { "kursNr": 102, "titel": "Yoga am Abend", "trainerin": "Öztürk", "plaetze": 15,
      "ausgebucht": true, "beitrag": 60.00, "start": null }
  ]
}

So gehst du vor: Tabellen in JSON überführen

1. Jede Zeile wird ein Objekt {…}, jede Spalte ein Schlüssel (Spaltennamen übernehmen, sofern nichts anderes verlangt ist).
2. Mehrere Zeilen kommen in ein Array […], meist mit sprechendem Namen: {"kurse": [ … ]}.
3. Datentyp je Spalte wählen: Zahlen ohne Anführungszeichen, Texte und Datumswerte mit, ja/nein → true/false, leere Zelle → null.
4. Beziehungen (Fremdschlüssel) abbilden: entweder als Verweis (die ID wird übernommen) oder eingebettet (die zugehörigen Datensätze stehen als Array im übergeordneten Objekt) – siehe unten.
5. Zum Schluss Klammern zählen und Kommas prüfen: Komma zwischen den Elementen, nie nach dem letzten.

Der umgekehrte Weg (S23 T1 A4cb: JSON-Sensordaten in ein Relationenmodell übernehmen): Jedes wiederkehrende Objekt wird eine Entität/Tabelle, ein eingebettetes Array wird eine eigene Tabelle mit Fremdschlüssel auf das übergeordnete Objekt.

Embedding und Referenz

In einer dokumentenorientierten Datenbank (Sammlungen von JSON-Dokumenten statt Tabellen) gibt es zwei Möglichkeiten, eine 1:n-Beziehung abzubilden. Beispiel: Abteilungen eines Sportvereins und ihre Trainingszeiten.

Referenz – Dokument in der Sammlung „abteilungen“

{ "abteilungId": 3, "name": "Handball", "leitung": "K. Brandt" }

Referenz – Dokumente in der Sammlung „trainingszeiten“ (verweisen über abteilungId)

[
  { "zeitId": 31, "abteilungId": 3, "tag": "MO", "von": "18:00", "halle": "Sporthalle Nord" },
  { "zeitId": 32, "abteilungId": 3, "tag": "DO", "von": "19:30", "halle": "Sporthalle Nord" }
]

Embedding – ein Dokument in der Sammlung „abteilungen“

{
  "abteilungId": 3,
  "name": "Handball",
  "leitung": "K. Brandt",
  "trainingszeiten": [
    { "tag": "MO", "von": "18:00", "halle": "Sporthalle Nord" },
    { "tag": "DO", "von": "19:30", "halle": "Sporthalle Nord" }
  ]
}

JSON im Programm erzeugen

Manchmal soll ein Skript oder eine Funktion ihr Ergebnis als JSON ausgeben (W24 T1 A2c). In der Praxis erledigen das Bibliotheken (z. B. Jackson oder Gson in Java), in der Prüfung baut man den Text meist selbst zusammen. Dabei kommt es auf drei Dinge an: Klammern öffnen und schließen, Kommas nur zwischen den Elementen, Strings in Anführungszeichen (im Code als \" maskiert). Beispiel: Namen aus einem Array als JSON-Array ausgeben.

funktion namenAlsJson(namen : string[]) : string
  json : string := "["
  zähle i von 0 bis namen.length - 1
    wenn i > 0 dann
      json := json + ", "                  // Komma nur ZWISCHEN den Elementen
    Ende wenn
    json := json + "\"" + namen[i] + "\""   // Wert in Anführungszeichen
  Ende zähle
  json := json + "]"
  rückgabe json
Ende funktion

Ergebnis für ["Anna", "Ben", "Cem"]: ["Anna", "Ben", "Cem"]; für ein leeres Array: []. Zahlen und true/false werden ohne Anführungszeichen angehängt.

JSON, XML, CSV und YAML im Vergleich

kursNr;titel;plaetze
101;Rückenfit;12
102;Yoga am Abend;15

kurs:
  kursNr: 101
  titel: Rückenfit
  tage: [MO, MI]   # Kommentar erlaubt

SD-03 · REST-Grundlagen & HTTP-Methoden Oft ↑

Vorkommen: REST/HTTP zusammen 4/9 (W21, S24, W24, S26), davon 3 in den letzten 4 Prüfungen · S24 T1 A2a/b (REST-Konzept 2 P, CRUD-Tabelle 6 P), S26 T1 A2ba/bc (REST-Konzept 3 P, zwei weitere HTTP-Methoden 6 P)

Begriffe

• Schnittstelle / API (Application Programming Interface): festgelegter Zugang, über den ein Programm Funktionen oder Daten eines anderen Programms nutzt – welche Anfragen möglich sind, wie sie aussehen und was zurückkommt.
• Web-API / Webservice: eine API, die über das Netz per HTTP(S) aufgerufen wird. Der Client (App, Web-Frontend, anderes System) kennt nur die Schnittstelle, nicht die Implementierung des Servers (lose Kopplung).
• REST (Representational State Transfer): ein Architekturstil – kein Protokoll und kein Standard –, der 2000 von Roy Fielding beschrieben wurde und HTTP konsequent nutzt. Eine API nach diesem Stil heißt REST-API bzw. RESTful.

Die Prinzipien von REST

Selten gefragt: HATEOAS – Antworten enthalten Links auf mögliche Folgeaktionen, z. B. zur Verlängerung einer Ausleihe.

CRUD und HTTP-Methoden

CRUD steht für die vier Grundoperationen auf Daten: Create, Read, Update, Delete. Bei REST übernimmt die HTTP-Methode die Rolle des Verbs, die URI benennt nur die Ressource.

Weitere Methoden: HEAD (wie GET, aber nur die Header – z. B. um Größe oder Änderungsdatum zu prüfen) und OPTIONS (welche Methoden sind für eine Ressource erlaubt?).

Sicher und idempotent

• Sicher (safe): Die Methode verändert auf dem Server nichts, sie liest nur. Sicher sind GET, HEAD und OPTIONS.
• Idempotent: Wird dieselbe Anfrage mehrfach gesendet, ist der Zustand auf dem Server danach derselbe wie nach einmaligem Senden. Idempotent sind alle sicheren Methoden sowie PUT (zweimal „ersetze durch X“ ergibt X) und DELETE (zweimal löschen: weg ist weg – die zweite Antwort darf 404 sein, der Zustand ändert sich nicht mehr).
• Nicht idempotent: POST – jede Wiederholung kann eine weitere Ressource anlegen. PATCH ist nicht garantiert idempotent: „setze E-Mail auf x“ wäre es, „erhöhe den Zähler um 1“ nicht. Entscheidend ist also, was die konkrete Änderung bewirkt.

Warum das wichtig ist: Bei schlechter Verbindung weiß ein Client oft nicht, ob seine Anfrage angekommen ist. Idempotente Anfragen darf er (oder ein Proxy) gefahrlos wiederholen – bei nicht idempotenten Anfragen kann eine Wiederholung Schaden anrichten.

PUT oder PATCH?

Die Ressource /leser/4711 sieht so aus: {"leserNr": 4711, "name": "Tom Berger", "email": "tom@mail.example", "newsletter": false}. Nur die E-Mail-Adresse soll sich ändern:

PUT /v2/leser/4711
Content-Type: application/json

{"leserNr": 4711, "name": "Tom Berger",
 "email": "t.berger@mail.example",
 "newsletter": false}

PATCH /v2/leser/4711
Content-Type: application/json

{"email": "t.berger@mail.example"}

PUT überträgt die vollständige neue Repräsentation und ersetzt die alte. Schickt man bei PUT nur ein Feld, wären die übrigen danach leer bzw. auf Standardwerte gesetzt. PATCH überträgt nur die Änderung.

Endpunkte entwerfen

• Substantive statt Verben, Sammlungen im Plural: /medien, nicht /getMedien. Die Aktion steckt in der HTTP-Methode.
• Hierarchie für abhängige Ressourcen: /leser/{leserNr}/ausleihen/{ausleihId}.
• Pfadparameter identifizieren eine bestimmte Ressource (/medien/M-30815). Query-Parameter filtern, sortieren oder teilen eine Ergebnisliste in Seiten auf (/medien?typ=dvd&sort=titel&seite=2) – sie sind meist optional.
• Kleinbuchstaben, keine Dateiendungen (.json); das Format regeln Accept und Content-Type.
• Versionierung, meist im Pfad (/v1/…, /v2/…), seltener über einen Header: Bei inkompatiblen Änderungen (Feld umbenannt, Struktur geändert) wird eine neue Version veröffentlicht, die alte bleibt eine Zeit lang parallel erreichbar. So funktionieren bereits ausgelieferte Clients (z. B. nicht aktualisierte Apps) weiter.
• Dokumentiert werden REST-APIs heute meist mit OpenAPI (früher Swagger).

Ablauf eines API-Aufrufs

In S24 T1 A2e (11 P) sollte der Ablauf App → WebService → Datenbank als Sequenzdiagramm mit alt-Fragment gezeichnet werden (Notation siehe Block 03 UML). So sieht das für eine einfache Leseanfrage aus:

REST und SOAP

SD-04 · HTTP-Request/Response & Statuscodes Oft ↑

Vorkommen: REST/HTTP zusammen 4/9 · W21 T1 A3c (Ursache für HTTP 404, 2 P), S24 T1 A2c/d (Bestandteile eines Requests 3 P, Statuscode-Klassen 3 P), W24 T2 A2a (HTTP-Antwort im Code bauen, 10 P), S26 T1 A2bb (Parameter einer URL beschreiben, 3 P)

HTTP in Kürze

HTTP (Hypertext Transfer Protocol) ist ein Protokoll der Anwendungsschicht nach dem Request-Response-Prinzip: Der Client sendet eine Anfrage, der Server beantwortet sie. HTTP ist zustandslos – jede Anfrage steht für sich (Sitzungen entstehen erst durch Cookies oder Tokens). Standardport 80; HTTPS ist HTTP über eine TLS-verschlüsselte Verbindung (Port 443) und heute der Normalfall. Bei HTTP/1.1 sind die Nachrichten reiner Text; HTTP/2 und HTTP/3 übertragen binär, Methoden, Header und Statuscodes bleiben aber gleich.

Aufbau von Request und Response

Aufbau einer URL

• Der Query-String beginnt mit ?; Parameter haben die Form name=wert und werden durch & getrennt. Die Reihenfolge ist egal.
• Sonderzeichen werden URL-kodiert (Prozentkodierung): Leerzeichen → %20 (oder +), ä → %C3%A4, & im Wert → %26.
• So beschreibst du einen Parameter (S26): Name, was er für die Anfrage bedeutet und was der Wert bewirkt – z. B. „titel=Momo: Suchbegriff; es werden nur Medien geliefert, deren Titel ‚Momo‘ enthält“ oder „seite=2: Bei seitenweiser Ausgabe (Paginierung) wird die zweite Seite der Treffer geliefert“.

API-Schlüssel

Ein API-Schlüssel (API key) ist eine eindeutige, geheime Zeichenfolge, mit der sich eine Anwendung (nicht eine Person) gegenüber einer API ausweist. Zweck: nur registrierte Clients erhalten Zugriff, Anfragen lassen sich einem Kunden zuordnen (Abrechnung, Statistik), und die Anzahl der Anfragen lässt sich begrenzen (Rate-Limiting, Überschreitung → 429 Too Many Requests). Übertragung immer über HTTPS, besser im Header als in der URL, und nie im öffentlich einsehbaren Quellcode ablegen. Ein API-Schlüssel ersetzt keine Benutzeranmeldung – dafür gibt es Tokens (z. B. OAuth 2.0).

Content-Length zählt Bytes, nicht Zeichen

In UTF-8 belegen ASCII-Zeichen (A–Z, a–z, Ziffern, Leerzeichen, { } " : usw.) je 1 Byte, ä ö ü Ä Ö Ü ß je 2 Bytes, das Eurozeichen € 3 Bytes, Emojis 4 Bytes. Gezählt wird nur der Body, nicht die Header.

Eine HTTP-Antwort im Code zusammenbauen

In W24 T2 A2a war eine Klasse HttpResponse vorgegeben und eine Methode zu schreiben, die eine vollständige Antwort mit Statuscode, Content-Type, Content-Length (in Bytes) und Body erzeugt. Das Muster an einem einfachen Beispiel – ein „Lebenszeichen“-Endpunkt der Bibliotheks-API, der immer mit einem kurzen Text antwortet (Methoden wie in der Klasse HttpResponse des Belegsatzes):

funktion createPingResponse() : HttpResponse
  body : string := "Bücherei-API läuft"
  antwort : HttpResponse := new HttpResponse()
  antwort.setStatus(200)
  antwort.setHeader("Content-Type", "text/plain; charset=utf-8")
  antwort.setHeader("Content-Length", body.byteLength().toString())   // 20, nicht 18!
  antwort.setBody(body)
  rückgabe antwort
Ende funktion

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 20

Bücherei-API läuft

Prüfreihenfolge in einem Endpunkt. Ein Endpunkt prüft der Reihe nach und kehrt beim ersten Problem sofort mit dem passenden Code zurück („frühes Return“):

1. Ist der Client authentifiziert (Token/API-Schlüssel vorhanden und gültig)? sonst 401
2. Darf er diese Ressource bzw. Aktion nutzen? sonst 403
3. Sind die Eingaben gültig (Pflichtfelder, Formate)? sonst 400
4. Gibt es die Ressource? sonst 404 · Widerspricht die Aktion dem aktuellen Zustand? 409
5. Aktion ausführen → 200, 201 oder 204; ist ein benötigter Dienst nicht erreichbar → 503; unerwarteter Fehler → 500

SD-05 · eRechnung Sonstige ⚠

Vorkommen: 1/9, aber in der vorletzten Prüfung: W25 T1 A2b (9 P: englischer Text – Hauptziel, Aspekte einer digitalen Rechnung) und A3 (Transportverschlüsselung 4 P, Konformität sicherstellen 3 P, Online-Prüfseite 6 P, XSD-Validierung reicht nicht 6 P). Wegen der neuen gesetzlichen Pflicht ein naheliegendes Thema für weitere Prüfungen.

Was ist eine eRechnung?

Nach der EU-Richtlinie 2014/55/EU und § 14 UStG ist eine elektronische Rechnung (eRechnung, e-invoice) eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine automatische und elektronische Verarbeitung ermöglicht. In Deutschland muss das Format der europäischen Norm EN 16931 entsprechen (oder mit ihr kompatibel sein).

Zwei Aspekte einer digitalen Rechnung: Der visuelle Aspekt erlaubt einem Menschen, den Inhalt zu sehen und zu lesen (z. B. als PDF). Der Datenaspekt erlaubt einem Computer, die enthaltenen Informationen strukturiert zu verarbeiten (z. B. als XML mit festgelegten Feldern für Rechnungsnummer, Beträge, Steuersätze). Eine PDF hat nur den visuellen Aspekt, eine XRechnung nur den Datenaspekt, ZUGFeRD beide.

Vorteile: keine manuelle Erfassung, dadurch weniger Fehler und schnellere Bearbeitung und Zahlung; geringere Kosten für Druck, Porto und Erfassung; einfache, durchsuchbare Archivierung; automatische Prüfung (Pflichtangaben, Rechenwerte); Grundlage für digitale Meldeverfahren der Steuerverwaltung. Herausforderungen: Software muss eRechnungen erzeugen, prüfen, anzeigen und revisionssicher im Originalformat archivieren; Abläufe und Stammdaten müssen angepasst werden.

Pflicht in Deutschland (Stand 2026)

Ausnahmen: Kleinbetragsrechnungen bis 250 € (brutto) und Fahrausweise. Rechnungen an Privatkunden (B2C) sind nicht betroffen. eRechnungen müssen im Originalformat (also als XML) aufbewahrt werden (GoBD) – ein ausgedrucktes Bild reicht nicht.

Formate

Die EN 16931 legt ein semantisches Datenmodell der „Kernrechnung“ fest (welche Angaben es gibt und was sie bedeuten, z. B. BT-1 Rechnungsnummer) und lässt zwei XML-Syntaxen zu: UBL (Universal Business Language) und UN/CEFACT CII (Cross Industry Invoice). In Deutschland sind zwei Formate verbreitet:

Bei ZUGFeRD ist der XML-Teil maßgeblich: Weichen PDF und XML voneinander ab, gelten die XML-Daten. Die Leitweg-ID ist eine Kennung des öffentlichen Rechnungsempfängers (z. B. einer bestimmten Behörde oder Einrichtung). Sie wird vom Auftraggeber mitgeteilt, steht in der XRechnung im Feld „Käuferreferenz“ (BT-10) und sorgt dafür, dass die Rechnung automatisch an die zuständige Stelle weitergeleitet wird.

So sieht der Anfang einer echten XRechnung im UBL-Format aus (Auszug, Beispiel einer Tischlerei an eine Behörde; cbc und cac sind Namensraum-Präfixe):

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#…:xrechnung_3.0</cbc:CustomizationID>
  <cbc:ID>TB-2026-0815</cbc:ID>                              <!-- Rechnungsnummer (BT-1) -->
  <cbc:IssueDate>2026-10-02</cbc:IssueDate>                 <!-- Rechnungsdatum -->
  <cbc:DueDate>2026-11-01</cbc:DueDate>                     <!-- Fälligkeit -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>            <!-- 380 = Handelsrechnung -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>04011000-1234512345-06</cbc:BuyerReference>  <!-- Leitweg-ID -->
  <!-- … Verkäufer, Käufer, Zahlungsangaben, Steuern … -->
  <cac:LegalMonetaryTotal>                <!-- Summen: Positionen, netto, brutto, Zahlbetrag -->
    <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1200.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1428.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1428.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <!-- … Rechnungspositionen (cac:InvoiceLine) … -->
</ubl:Invoice>

Übertragungswege

Das Gesetz schreibt keinen bestimmten Weg vor. Üblich sind:

• E-Mail mit der XML- bzw. ZUGFeRD-Datei als Anhang (an eine eigens eingerichtete Rechnungsadresse),
• Upload in ein Portal – z. B. die Rechnungseingangsplattformen von Bund und Ländern (ZRE, OZG-RE) oder ein Lieferantenportal,
• Peppol: europäisches Netzwerk für den Austausch von Geschäftsdokumenten; Sender und Empfänger sind über zertifizierte Zugangspunkte (Access Points) angebunden, die Zustellung ist sicher und nachweisbar,
• EDI oder eine Web-API zwischen den Systemen großer Geschäftspartner.

Validierung: Entspricht die Rechnung der Spezifikation?

Eine eRechnung wird in zwei Stufen geprüft:

1. Schema-Validierung (XSD von UBL bzw. CII): Struktur, Pflichtelemente, Reihenfolge, Datentypen (Datum, Dezimalzahl, Codes). Sie stellt die formale Korrektheit sicher.
2. Schematron-Prüfung: Geschäftsregeln der EN 16931 und der XRechnung, die sich mit einem Schema nicht ausdrücken lassen – z. B. „Summe der Positionsnettobeträge = Nettogesamtbetrag“, „Bruttobetrag = Nettobetrag + Umsatzsteuer“, „bei XRechnung ist die Käuferreferenz (Leitweg-ID) anzugeben“.

Beides erledigt der KoSIT-Validator, das offizielle Prüfwerkzeug: frei verfügbar (Open Source), lokal ausführbar und auch in automatisierte Tests einbindbar; er erstellt einen Prüfbericht. Bei der Entwicklung einer Rechnungssoftware sichern außerdem ab: die verbindlichen Anforderungen der Spezifikation konsequent umsetzen, erprobte Bibliotheken nutzen, automatisierte Tests mit den offiziellen Testrechnungen, Testläufe mit Empfängern bzw. deren Portalen (Interoperabilität) und die Validierung als festen Schritt vor jedem Versand.

Datenschutz und Sicherheit

• Online-Prüfseiten: Rechnungen enthalten personenbezogene Daten (Namen, Anschriften, Bankverbindungen) und Geschäftsgeheimnisse (Preise, Mengen, Kundenbeziehungen). Wer eine Rechnung auf eine fremde Website hochlädt, übermittelt diese Daten an Dritte – nach DSGVO braucht das eine Rechtsgrundlage. Deshalb: keine echten Rechnungen hochladen, nur Test- oder anonymisierte Daten; den Anbieter prüfen (Impressum, Sitz bzw. Serverstandort, Datenschutzerklärung, Löschung); bedenken, dass das Ergebnis einer unbekannten Seite falsch oder veraltet sein kann (welche Regeln und welche Version werden geprüft?); im Zweifel den Validator lokal betreiben.
• Transport: Beim E-Mail-Versand verschlüsselt TLS die Verbindung zwischen den Mailservern (Transportverschlüsselung). TLS ist ein hybrides Verfahren: asymmetrische Verschlüsselung für den sicheren Austausch eines Sitzungsschlüssels, symmetrische Verschlüsselung für die schnelle Übertragung der Daten. Die Transportverschlüsselung schützt nur die einzelnen Teilstrecken; auf den beteiligten Servern liegt die Nachricht unverschlüsselt. Ende-zu-Ende schützen S/MIME oder PGP bzw. die Übermittlung über Peppol oder ein Portal per HTTPS. (Kryptografie im Detail: Block 07.)

Englischer Fachtext: so gehst du vor

In W25 kam die eRechnung als englischer Text. Gefragt wird nicht nach einer Übersetzung, sondern nach dem Inhalt in eigenen Worten auf Deutsch. Erst die Frage lesen, dann im Text die passende Stelle suchen (Schlüsselwörter wie main objective, aspects, from … until), dann in ganzen Sätzen antworten. Hilfreiche Vokabeln:

B · Belegsatz

Für diesen Block legt die IHK keine Notationshilfen bei. Der Belegsatz enthält deshalb nur die Anlagen zur Ausgangssituation (Szenario, API-Dokumentation, Beispielnachrichten, Klassen, XML- und JSON-Daten, englischer Text). Keine Erklärungen.

{
  "aboId": 5531,
  "kundenNr": 10427,
  "kisteId": "K-OBST-M",
  "rhythmus": "woechentlich",
  "liefertag": "DI",
  "lieferadresseId": 1,
  "status": "aktiv",
  "pausiertBis": null
}

POST /v1/kunden/10427/abos HTTP/1.1
Host: api.frischekiste.example
Content-Type: application/json
Accept: application/json
X-API-Key: app-7Fq2-Lx91
Content-Length: 88

{"kisteId": "K-GEM-L", "rhythmus": "14-taegig", "liefertag": "FR", "lieferadresseId": 2}

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: /v1/kunden/10427/abos/5547
Content-Length: 162

{"aboId": 5547, "kundenNr": 10427, "kisteId": "K-GEM-L", "rhythmus": "14-taegig", "liefertag": "FR", "lieferadresseId": 2, "status": "aktiv", "pausiertBis": null}

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <!DOCTYPE wochenangebot SYSTEM "wochenangebot.dtd">
 3  <wochenangebot kw="46">
 4    <erzeuger erzeugerId="E07">
 5      <name>Hof Brammer</name>
 6      <ort>Wiesede</ort>
 7      <biozertifikat>DE-ÖKO-006</biozertifikat>
 8    </erzeuger>
 9    <artikel artNr="A-101" einheit="kg">
10      <bezeichnung>Möhren, lose</bezeichnung>
11      <menge>120</menge>
12      <preis>1.40</preis>
13    </artikel>
14    <artikel artNr="A-102" einheit="stueck">
15      <bezeichnung>Kürbis Hokkaido</Bezeichnung>
16      <menge>40</menge>
17      <preis>2.10</preis>
18      <hinweis>nur bis KW 48 lieferbar</hinweis>
19    </artikel>
20    <artikel artNr="A-103" einheit="bund">
21      <bezeichnung>Lauchzwiebeln</bezeichnung>
22      <preis>0.90</preis>
23      <menge>60</menge>
24    </artikel>
25    <artikel artNr="A-101" einheit="Kilo">
26      <bezeichnung>Rote Bete</bezeichnung>
27      <menge>35<menge>
28      <preis>1.80</preis>
29      <lieferant>Hof Brammer</lieferant>
30    </artikel>
31    <artikel artNr=A-105>
32      <bezeichnung>Feldsalat</bezeichnung>
33      <menge>15</menge>
34      <preis>7.50</preis>
35    </artikel>
36  </wochenangebot>

 1  <!ELEMENT wochenangebot (erzeuger, artikel+)>
 2  <!ATTLIST wochenangebot kw   CDATA #REQUIRED
 3                          jahr CDATA #REQUIRED>
 4  <!ELEMENT erzeuger (name, ort, biozertifikat?)>
 5  <!ATTLIST erzeuger erzeugerId ID #REQUIRED>
 6  <!ELEMENT name (#PCDATA)>
 7  <!ELEMENT ort (#PCDATA)>
 8  <!ELEMENT biozertifikat (#PCDATA)>
 9  <!ELEMENT artikel (bezeichnung, menge, preis, hinweis*)>
10  <!ATTLIST artikel artNr   ID              #REQUIRED
11                    einheit (kg|stueck|bund) "kg">
12  <!ELEMENT bezeichnung (#PCDATA)>
13  <!ELEMENT menge (#PCDATA)>
14  <!ELEMENT preis (#PCDATA)>
15  <!ELEMENT hinweis (#PCDATA)>

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <!DOCTYPE lieferschein SYSTEM "lieferschein.dtd">
 3  <lieferschein nr="LS-2026-1187" datum="2026-11-10">
 4    <kunde kundenNr="20015">
 5      <name>Kita Sonnenblume</name>
 6      <adresse>Am Mühlenbach 3, 21391 Heidmoor</adresse>
 7    </kunde>
 8    <position>
 9      <kiste>K-OBST-M</kiste>
10      <anzahl>4</anzahl>
11    </position>
12    <position>
13      <kiste>K-GEM-L</kiste>
14      <anzahl>2</anzahl>
15      <bemerkung>ohne Sellerie</bemerkung>
16      <bemerkung>Kühlware zuerst ausladen</bemerkung>
17    </position>
18    <fahrer>T. Ohlsen</fahrer>
19  </lieferschein>

// JSON-Syntaxbeschreibung
// wert kann sein: "zeichenkette", zahl, true, false, null, objekt, array
{
    "attributname": wert,
    ...,
    "objektname": {
        "attributname": wert,
        ...
    },
    "arrayname": [
        wert,
        ...
    ]
}

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <rechnung xmlns="urn:kranich:frischekiste:rechnung:1.0">
 3    <rechnungsnummer>RE-2026-04711</rechnungsnummer>
 4    <rechnungsdatum>2026-11-30</rechnungsdatum>
 5    <faelligAm>2026-11-16</faelligAm>
 6    <leitwegId>03359012-4711-08</leitwegId>
 7    <verkaeufer>
 8      <name>FrischeKiste Nordheide GmbH</name>
 9      <ustId>DE123456789</ustId>
10    </verkaeufer>
11    <kaeufer>
12      <name>Stadt Heidmoor, Kita Sonnenblume</name>
13    </kaeufer>
14    <position nr="1">
15      <bezeichnung>Obstkiste mittel</bezeichnung>
16      <menge>8</menge>
17      <einzelpreis>18.50</einzelpreis>
18      <nettobetrag>148.00</nettobetrag>
19      <steuersatz>7</steuersatz>
20    </position>
21    <position nr="2">
22      <bezeichnung>Gemüsekiste groß</bezeichnung>
23      <menge>4</menge>
24      <einzelpreis>27.90</einzelpreis>
25      <nettobetrag>101.60</nettobetrag>
26      <steuersatz>7</steuersatz>
27    </position>
28    <summen>
29      <nettogesamt>259.60</nettogesamt>
30      <umsatzsteuer>18.17</umsatzsteuer>
31      <bruttogesamt>278.77</bruttogesamt>
32    </summen>
33  </rechnung>

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Algorithmen sind in Pseudocode zu entwickeln; eine Programmiersprache (z. B. Java) ist ebenfalls zulässig. Für alle Attribute stehen Get-Methoden zur Verfügung (Anlage 4).

SD-01 · XML

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <lieferung nr="88120">
 3    <status>zugestellt</status>
 4    <zeit>2026-11-10T09:42:00</zeit>
 5    <ablage hinweis="Garage"/>
 6  </lieferung>

<artikel artNr="A-110" einheit="kg">
  <bezeichnung>Grünkohl</bezeichnung>
  <menge>ca. 80</menge>
  <preis>-1.90</preis>
</artikel>

SD-02 · JSON

1  {
2    'kisteId': "K-MIX-S",
3    "preis": 14,20,
4    "bio": False,
5    "inhalt": ["Äpfel", "Möhren", "Kartoffeln",]
6  }

[{"position": 2, "kundenNr": 20015, "ort": "Heidmoor", "kisten": 6}, {"position": 3, "kundenNr": 10533, "ort": "Wiesede", "kisten": 1}, {"position": 5, "kundenNr": 20022, "ort": "Wiesede", "kisten": 4}]

SD-03 · REST-Grundlagen & HTTP-Methoden

SD-04 · HTTP-Request/Response & Statuscodes

GET https://api.geodienst.example/v2/route?start=53.3297,9.8722&ziel=53.2464,10.4115&profil=transporter&apikey=GD-55K2-ZZ81

HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8
Content-Length: 57

{"status": 404, "fehler": "Kiste K-XXL-Z nicht gefunden"}

SD-05 · eRechnung

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (dort vom u-form-Verlag).