# Rechnungstool — Kundenstamm und Weboberflaeche (offen, aufgenommen 06.09.2026)

## Woher das kommt

Aus der Planung fuer Andreas' eigene Firma: **polnische sp. z o.o., Verkauf ausschliesslich B2B,
Kunden ueberwiegend in Deutschland**. Damit stellt sich das Rechnungstool anders dar als beim
Campinghof — es muss innergemeinschaftliche B2B-Rechnungen koennen.

Sein Wort: *"da fehlt dann die kundennummer noch mit drin ... ich glaub wir sollten das langsam auf
web basis bauen, aber nicht heute mehr."*

## 1. Kundenstamm (fehlt bisher ganz)

Es gibt keinen Kundendatensatz. Fuer B2B-Rechnungen ins EU-Ausland ist er Pflicht, nicht Komfort.

Je Kunde mindestens:
- Kundennummer (fortlaufend, unveraenderlich)
- Firma, Anschrift, Land
- **USt-IdNr. des Kunden** — Pflichtangabe auf der Rechnung
- Ansprechpartner, Zahlungsziel, abweichende Lieferanschrift

## 2. Rechnungsanforderungen bei innergemeinschaftlicher B2B-Lieferung

Auf der Rechnung muessen stehen:
- **eigene USt-IdNr.** UND **USt-IdNr. des Kunden** (beide!)
- Hinweis auf die **Steuerschuldnerschaft des Leistungsempfaengers** (Reverse Charge)
- keine Umsatzsteuer ausgewiesen

**WICHTIG — das Programm muss ZWEI Faelle koennen, nicht nur einen:**

| Fall | Rechnung |
|---|---|
| Kunde hat **gueltige USt-IdNr.** | ohne Umsatzsteuer, beide IdNr. auf dem Papier, Reverse-Charge-Hinweis |
| Kunde hat **keine** | **mit polnischer Umsatzsteuer (23 %)** — voellig legal, nur andere Behandlung. **Der Auftrag ist NICHT verloren.** |

(Andreas' Sorge am 06.09.2026: *"dann kaufen die bei mir nicht"* — trifft nicht zu. Die USt-IdNr.
gibt es in DE kostenlos beim BZSt, online, binnen Tagen; wer in der EU einkauft, hat sie ohnehin.
Ohne Nummer wird schlicht mit polnischer Steuer fakturiert. Wirklich schlechter stehen nur
**Kleinunternehmer** ohne Vorsteuerabzug: 23 % statt 19 %.)

Dahinter haengen drei Nachweispflichten, an denen die Steuerfreiheit tatsaechlich haengt und die das
Programm mitfuehren sollte:
1. **Pruefung der USt-IdNr.** ueber das EU-Portal, qualifiziert, **mit Beleg und Datum je Auftrag**
   speichern (ungueltige Nummer = er schuldet die Steuer selbst)
2. **Nachweis des Grenzuebertritts** — Frachtpapier oder **Gelangensbestaetigung**, dem Vorgang
   zuordenbar ablegen
3. **Zusammenfassende Meldung** — Auswertung je Zeitraum, Kunde + Betrag, exportierbar

Das sind genau die Stellen, an denen Betriebspruefer zuerst nachsehen. Gehoert von Anfang an rein,
nicht nachtraeglich.

## ⚠️ FUND 06.09.2026 — DIE STEUERLOGIK IST DIE GROSSE BAUSTELLE, NICHT DER KUNDENSTAMM

`berechnung.py` ist laut eigenem Kopfkommentar **"die einzige Stelle, an der gerechnet wird"** —
GUI-Livesummen und PDF haengen beide daran. Sie rechnet heute:
- **BRUTTO-Preise**, USt wird herausgerechnet
- Saetze **7 % (ermaessigt) und 19 % (regulaer)** = deutsche Umsatzsteuer
- plus **Beherbergungssteuer** als Aufschlag

Das ist die Campinghof-Welt: Endkunden, Uebernachtungen, deutsche Steuer.

**Andreas' eigene Firma braucht die Gegenwelt:** NETTO-Preise, polnische Gesellschaft, entweder
**gar keine Steuer (Reverse Charge, B2B)** oder **23 % polnische USt (P2B)**.

→ **Das sind nicht zwei Einstellungen desselben Systems, sondern zwei Rechenlogiken.**

**Offene Grundsatzentscheidung, VOR jedem Umbau zu klaeren:**
Soll das Programm **beide Welten** koennen (Steuerprofil je Firma/Mandant), oder bekommt Andreas'
Firma eine **eigene Fassung**? Solange das offen ist, nicht an `berechnung.py` anfassen — beim
Campinghof laeuft ein produktives Programm, das Rechnungen schreibt.

**Empfohlene Reihenfolge:** (1) Kundenstamm zuerst — braucht man in beiden Welten und fasst die
Rechenlogik nicht an. (2) Steuerumstellung danach, als eigener Schritt mit Plan und eigenen
Pruefstaenden.

## 3. Weboberflaeche

Wunsch: das Tool langsam **auf Webbasis** umbauen. Noch nicht begonnen, kein Termin, ausdruecklich
**nicht heute**. Vor dem Umbau planen (Regel: Plan vor Neubau), nicht nebenbei anfangen.

## Status

**Offen. Nicht begonnen.** Erst ansprechen, wenn er das Thema selbst wieder aufmacht.