PDF Rechnungen in E-Rechnung Konvertieren. Format: ZUGFeRD oder XRechnung http://erechnung/
Go to file
dfuhrmann3 ac233baa2f feat: BT-41 Bearbeiter, BT-34/BT-43 split, Ihr Auftrag->BT-13, Referenznummer->Freitext
- BT-41: Bearbeiter wird aus der Rechnung erkannt (deterministisch) und als editierbares
  Kopfdaten-Feld gefuehrt; ersetzt das fixe 'Geschaeftsfuehrung' (kein Fallback, leer bleibt leer).
- BT-34 und BT-43 als zwei getrennte, editierbare Verkaeufer-Felder (elektronische Adresse vs.
  Kontakt-E-Mail), beide vorbelegt mit der office-Mail.
- 'Ihr Auftrag' deterministisch in BT-13 (statt LLM-Fehlzuordnung nach BT-14).
- 'Referenznummer' (z.B. SAP) hat kein EN16931-Feld -> in den Freitext (BT-22).
- Generatoren fallen ohne die neuen Keys auf VERKAEUFER zurueck (Golden-Verhalten unveraendert).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:03:51 +02:00
.dockerignore chore: keep tests, test-config and planning docs local-only (untrack from repo) 2026-07-07 15:57:09 +02:00
.gitignore chore: keep tests, test-config and planning docs local-only (untrack from repo) 2026-07-07 15:57:09 +02:00
Dockerfile Update für API & Docker 2026-07-02 14:19:25 +02:00
README.md Update 2026-07-07 11:09:47 +02:00
docker-compose.yml Update für API & Docker 2026-07-02 14:19:25 +02:00
invoice_logic.py feat: BT-41 Bearbeiter, BT-34/BT-43 split, Ihr Auftrag->BT-13, Referenznummer->Freitext 2026-07-13 15:03:51 +02:00
main.py feat: BT-41 Bearbeiter, BT-34/BT-43 split, Ihr Auftrag->BT-13, Referenznummer->Freitext 2026-07-13 15:03:51 +02:00
requirements.txt Test 2026-07-07 10:52:43 +02:00
sRGB.icc Test 2026-07-06 09:23:01 +02:00

README.md

README

Description

Dieses Tool konvertiert Rechnungen im PDF-Format über eine Weboberfläche in die offiziellen E-Rechnungsformate XRechnung (UBL 3.0) und ZUGFeRD 2.4 (hybride PDF mit eingebettetem CII-XML). Die Datenextraktion erfolgt über ein LLM, das intern im Firmennetzwerk läuft – sensible Finanzdaten verlassen das lokale Netzwerk nicht.

Zugriff

Die Anwendung läuft als Docker-Container und ist im lokalen Firmennetzwerk erreichbar unter:

http://erechnung

Aufbau

Das System besteht aus zwei Komponenten:

  • Web-Oberfläche (main.py, Streamlit): PDF-Upload, Datenvalidierung, Export
  • vLLM-Backend: separat betriebener Inferenz-Server (Standard: gemma431b), der die strukturierten Metadaten aus dem Rechnungstext extrahiert

Installation (Docker)

1. Repository holen

git clone https://gitea.scitech-gmbh.de:8443/dfuhrmann/E-Rechnung.git
cd E-Rechnung

2. Umgebungsvariablen prüfen

In docker-compose.yml sind das vLLM-Backend und Modell hinterlegt:

environment:
  - VLLM_URL=http://10.192.0.140:8002
  - LLM_MODEL=gemma431b

Bei Bedarf hier anpassen (z.B. anderes Modell oder Backend-Host).

3. Container bauen und starten

docker compose up -d --build

Die Anwendung ist danach unter http://localhost:8040 (bzw. im Firmennetz unter http://erechnung) erreichbar.


Use

Der Konversionsprozess gliedert sich in folgende Schritte:

  1. Dokumenten-Upload: Laden Sie die Rechnungs-PDF über die Weboberfläche hoch. Die PDF wird direkt zur Kontrolle angezeigt.
  2. Extraktion: Starten Sie die Analyse über den Button "Daten extrahieren".
  3. Validierung: Prüfen Sie die extrahierten Kopfdaten und die Positionstabelle in der Benutzeroberfläche. Da alle Felder editierbar sind, können Korrekturen direkt vorgenommen werden. Pflichtfelder sind mit :red[*] markiert; der Export wird blockiert, solange Pflichtangaben fehlen.
  4. Export: Wählen Sie das gewünschte Format (XRechnung-XML oder ZUGFeRD-PDF) und starten Sie den Download.

Notes

Human-in-the-Loop

Das Tool dient als Automations-Assistent. Vor dem finalen Export ist eine visuelle Endkontrolle der extrahierten Daten (insbesondere Rechnungsnummer und Empfängeradresse) durch den Sachbearbeiter zwingend erforderlich, um KI-Fehlinterpretationen auszuschließen.

GoBD-Konformität

Das Tool generiert ausschließlich das strukturierte XML- bzw. hybride PDF-Format. Für die Einhaltung der GoBD-Richtlinien (u. a. die revisionssichere Archivierung der Original-PDF sowie der generierten E-Rechnung über den gesetzlichen Zeitraum von 10 Jahren) ist der Betreiber der Software selbst verantwortlich.