# Belege — 1000 deutsche Rechnungen und Gutschriften mit Feld-Labels

Synthetischer Datensatz für Belegerkennung im deutschen Markt. Jedes Dokument
liegt als Bild vor, dazu eine JSON-Datei mit Text und Pixel-Box für jedes Feld.

Erzeugt am 15.08.2026 von Immineal (Linus Oskar Linhof), Revision 4 (Wortschatz
der Positionszeilen von 61 auf 191 Bezeichnungen verbreitert).
Lizenz: `LICENCE.txt` im selben Archiv. Kommerzielles Training ist erlaubt,
Weitergabe der Dateien selbst nicht.

## Aufbau des Archivs

```
manifest.jsonl        eine Zeile pro Dokument, der Index
images/beleg-000000.jpg
labels/beleg-000000.json
DATASET.md            diese Datei
LICENCE.txt
COUNT.txt
```

`manifest.jsonl` ist der Einstieg. Eine Zeile:

```json
{"id": "beleg-000000", "image": "images/beleg-000000.jpg",
 "label": "labels/beleg-000000.json", "variant": "scan", "layout": "window",
 "vat_scheme": "regelbesteuert", "document_type": "Rechnung", "line_items": 3}
```

## Drei strukturell unterschiedliche Layouts

**Revision 1 hatte genau ein Seitenskelett** — nur Schriftart, Akzentfarbe und
Aufnahmebedingung variierten. Ein Modell, das darauf trainiert, lernt eine
Geometrie und scheitert an echten Rechnungen mit anderem Aufbau. Das war ein
echter Mangel, kein Stilproblem, und wurde als solcher gemeldet.

Revision 3 wählt pro Dokument zwischen drei Layouts, die sich strukturell
unterscheiden, nicht nur farblich — eines davon auch im Seitenformat:

| Layout | Anteil | Format | Kopf | Adresse | Positionen | Fuß |
|---|---:|---|---|---|---|---|
| `window` | 505 | Hochformat | Absenderzeile links/rechts/Balken | DIN-5008-Sichtfenster links | Tabelle mit Kopfzeile | Fließtext |
| `list` | 291 | Hochformat | zentriertes Briefkopf-Logo | Empfänger rechtsbündig, kein Fenster | Listenblock, keine Spaltenköpfe | umrandetes Zahlungsdaten-Feld |
| `landscape` | 204 | Querformat | Absender links, Titel rechts in einer Kopfzeile | Empfänger und Metadaten in der linken Spalte | Tabelle in der rechten Spalte | zweigeteilt: Zahlungsbedingungen links, Bankdaten rechts |

Alle drei Layouts durchlaufen dieselbe Feldprüfung (siehe unten), die Boxen
sind in allen dreien gegen das erzeugte Bild verifiziert (Feld- und
Positions-Boxen wurden auf Stichproben visuell auf das Bild gelegt, nicht nur
rechnerisch geprüft). `manifest.jsonl` und jedes Label führen jetzt auch das
Feld `layout`, damit Sie nach Struktur filtern können, nicht nur nach
Aufnahmeart. Drei Layouts sind ein echter Fortschritt gegenüber einem, aber
noch keine "mehreren" im vollen Sinne der Anfrage, die das ausgelöst hat:
mehrseitige, fortlaufende Belege fehlen weiterhin — siehe `REVIEW.md` für
den Stand.

## Was drin ist

1000 Dokumente, davon 895 Rechnungen und 105 Gutschriften, zusammen 3777
Positionszeilen.

| Steuerfall | Dokumente | was daran besonders ist |
|---|---:|---|
| `regelbesteuert` | 626 | 19 %, 7 % oder beides auf einem Beleg |
| `kleinunternehmer` | 170 | § 19 UStG: keine Steuerzeile, stattdessen ein Pflichtsatz |
| `gutschrift` | 105 | alle Beträge negativ |
| `reverse_charge` | 99 | § 13b UStG: ebenfalls 0 €, anderer Pflichtsatz |

Die zwei Nullsteuer-Fälle — Kleinunternehmer und Reverse Charge — sind der
Grund, warum es diesen Datensatz gibt. Sie machen 269 von 1000 Dokumenten aus.
Ein Modell, das auf englischen Rechnungen oder auf SROIE trainiert wurde,
erwartet eine Steuerzeile und erfindet eine, wenn keine da ist. Die Gutschrift
ist kein Nullsteuer-Fall — sie trägt dieselbe Steuer wie eine reguläre
Rechnung, nur mit negativem Vorzeichen auf jedem Betrag.

| Aufnahme | Dokumente | wie erzeugt |
|---|---:|---|
| `photo` | 436 | perspektivisch verzerrt, Lichtverlauf mit Objektiv-Abfall, Sensorrauschen, JPEG |
| `scan` | 414 | leichter Schiefstand, Staubkörner, JPEG-Artefakte |
| `clean` | 150 | direkter Export, keine Degradation |

Die Bilder liegen zwischen 908 × 969 und 2476 × 2494 Pixel, im Median rund
1445 × 1793, weil Kameraabstand, Beschnitt und jetzt auch das Seitenformat
mitvariieren — 992 verschiedene Größen unter den 1000 Dokumenten. Zusammen
252 MB.

**Wortschatz der Positionszeilen und Firmennamen, ehrlich beziffert.** Ein
unabhängiger Review dieser Zahl (siehe `REVIEW.md`) hat sie erneut geprüft:
selbst 61 unterschiedliche Bezeichnungen wiederholten sich in einem
3777-Positionen-Datensatz noch rund 90-mal je Phrase — genug, dass ein Modell
die Zeichenketten selbst lernen könnte statt Layout und Steuerlogik. Die
3777 Positionszeilen bestehen jetzt aus 191 unterschiedlichen Bezeichnungen
(153 bei 19 %, 38 bei 7 % Steuersatz) aus Handwerk, IT, Reinigung, Garten,
Kfz, Veranstaltungstechnik, Sicherheit, Verwaltung, Transport, Personal,
Energie, Werbung, Möbeln, Gastronomie, Bildung, Gesundheit, Landwirtschaft
und Kultur — keine
wiederholt sich öfter als 40-mal. 900 der 1000 Firmennamen sind untereinander
verschieden (Kombinationen aus 28 Wortstämmen, 24 Branchenzusätzen und 6
Rechtsformen). Wer ein Modell auf reine Textvielfalt statt auf Layout und
Steuerlogik prüft, sollte diese Zahl kennen, bevor er kauft, nicht erst
danach.

## Das Label

Bis zu 17 Kopffelder pro Dokument, sonst 15 oder 16 — 17 kommt nur bei
gemischtem Steuersatz (19 % und 7 % auf demselben Beleg) vor, aber nicht jedes
gemischte Dokument hat alle 17: `due_date` fehlt auf gut einem Drittel aller
Belege unabhängig vom Steuersatz, also auch auf einigen mit gemischtem Satz
(106 Belege sind gemischt, 74 davon haben 17 Felder, die übrigen 32 nur 16) —
dazu jede Position einzeln
zerlegt. Jedes
Feld hat `text` und `box` als `[x0, y0, x1, y1]` in Bildkoordinaten — nach der
Verzerrung, nicht davor.

**Nicht jedes Feld ist auf jedem Dokument.** Das ist kein Fehler im Datensatz,
sondern der Fall, an dem Extraktionsmodelle scheitern, also hier die tatsächliche
Häufigkeit:

| Feld | auf n Dokumenten |
|---|---:|
| `supplier_name`, `supplier_address`, `customer_name`, `customer_address` | 1000 |
| `invoice_number`, `invoice_date`, `service_date`, `customer_number` | 1000 |
| `doc_type`, `net_total`, `gross_total`, `iban`, `bic` | 1000 |
| `vat_id` | 830 |
| `vat_amount_19` | 714 |
| `due_date` | 696 |
| `tax_note` | 269 |
| `tax_number` | 170 |
| `vat_amount_7` | 123 |

`tax_note` ist der Pflichtsatz bei § 19 und § 13b und liegt genau auf den 269
Dokumenten dieser beiden Fälle. `tax_number` steht dort, wo statt einer
Umsatzsteuer-ID eine Steuernummer angegeben ist — Kleinunternehmer haben in der
Regel keine USt-IdNr.

Positionen liegen unter `line_items`, jede mit `description`, `quantity`,
`unit_price` und `line_total`, jeweils mit eigener Box.

Zahlen stehen im Bild deutsch formatiert (`1.234,56`), in `totals` und
`line_items` dagegen als JSON-Zahl. Wer den gedruckten String braucht, findet
ihn im jeweiligen Feld unter `text`.

## Wie geprüft wurde

Jedes Label wurde beim Erzeugen gegen sich selbst geprüft, bevor die Datei
geschrieben wurde: die Positionen müssen sich zur Nettosumme addieren, Brutto
muss Netto plus Steuer sein, die gedruckte Bruttosumme muss mit der berechneten
übereinstimmen, jede Box muss innerhalb des Bildes liegen, und bei § 19 und
§ 13b muss die Steuer 0 € sein und der Pflichtsatz vorhanden. Dokumente, die das
nicht bestehen, landen nicht im Datensatz. Von 1000 erzeugten wurden 0
verworfen.

Die Boxen werden mit derselben Homographie transformiert wie das Bild, das Blatt
wird also genau einmal neu abgetastet. Zwei getrennte Verzerrungsschritte würden
den Text zweimal weichzeichnen und die Boxen um einige Pixel danebenlegen.

## Was der Datensatz nicht kann

- Es sind **keine echten Belege**. Die Layouts stammen aus einem Generator —
  aktuell drei strukturell unterschiedliche, siehe oben. Wer die volle
  Streuung echter Lieferantenformulare braucht, bekommt sie hier noch nicht.
- **Keine mehrseitigen Belege.** Jedes Dokument ist eine einzelne Seite, auch
  `landscape`. Fortlaufende, mehrseitige Rechnungen sind der nächste
  Ausbauschritt, nicht Teil dieser Revision.
- **Nichts Handschriftliches**, keine Stempel, keine Heftklammern. Jedes
  Dokument ist einseitig.
- **Keine Tabellenstruktur-Annotation** über die Positionsfelder hinaus: Boxen
  für Zellen, aber keine Zeilen- und Spaltenlinien.
- Rund 1400 × 2000 Pixel. Für 300-dpi-Faksimiles ist das zu wenig.
- Nur Deutsch, nur EUR.

Der ehrliche Anwendungsfall ist Vortraining und Regressionstesten: genug Volumen
und exakte Boxen, damit ein Modell die deutschen Sonderfälle kennt, bevor es auf
die paar hundert echten Belege trifft, die Sie rechtmäßig besitzen.

## Datenschutz

Jede Firma, Person, Adresse, Bankverbindung und Steuernummer ist erfunden. Die
IBANs tragen eine korrekte Prüfsumme auf der Bankleitzahl `99999999`, die die
Bundesbank nie vergeben hat, ein generiertes Konto kann also nicht mit einem
echten kollidieren. Orte und Postleitzahlen sind echte Verwaltungsdaten. Es sind
keine personenbezogenen Daten enthalten, DSGVO-seitig ist also nichts zu prüfen.

## Fehler und Sonderwünsche

Wenn etwas in den Daten falsch ist, schreiben Sie an mail@j4zz.eu; es wird in
der nächsten Revision korrigiert, die Käufer kostenlos bekommen. Andere Layouts,
mehr Dokumente oder zusätzliche Felder sind machbar — fragen Sie.
