Neue Seite Rechnungen → Export mit Zeitraum-/Status-Filter und drei
Downloads, nie Entwürfe:
- Rechnungsjournal als CSV (Semikolon, Dezimalkomma, UTF-8-BOM):
Nummer, Datum, Kunde, Netto/USt/Brutto, effektiver USt-Satz, Status,
Zahlungsdatum, aufgelöste Storno-Referenzen.
- Alle zugehörigen Rechnungs-PDFs als ZIP (die eigentlichen Belege,
wie von GoBD neben dem Journal verlangt), gebaut über das lokale
zip-Binary wie in ops/backup.ts.
- Echter DATEV-Buchungsstapel (EXTF, Format 700/21) zum direkten
Import beim Steuerberater. Pro Rechnung eine Buchungszeile je
USt-Satz-Gruppe (Automatikkonten-Verfahren: Konto = aus der
Kundennummer abgeleitetes Debitorenkonto, Gegenkonto = konfiguriertes
Erlöskonto des jeweiligen Satzes – kein geratener BU-Schlüssel
nötig). Kopf- und Buchungszeilen-Layout (31 bzw. 125 Felder) gegen
die offizielle DATEV-Formatbeschreibung und ein reales Beispiel aus
github.com/ledermann/datev verifiziert, nicht aus dem Gedächtnis
geraten. Ausgabe in Windows-1252 (eigener Encoder: Node kennt nur
striktes ISO-8859-1, das den Halbgeviertstrich in den DATEV-
Spaltennamen stillschweigend verstümmelt hätte – beim Testlauf
gefunden und behoben).
Dafür neue DATEV-Stammdaten unter Einstellungen → Firma (Berater-/
Mandantennummer, SKR, Sachkontenlänge, Wirtschaftsjahresbeginn,
Erlöskonten je Steuersatz; Migration 031). Ohne diese Angaben liefert
der DATEV-Export eine klare Fehlermeldung statt einer falschen Datei;
das CSV/ZIP funktioniert unabhängig davon immer.
Gegen echte Rechnungen (RE-1001/RE-1002, Original + Storno) über eine
temporäre Test-Session verifiziert: CSV/ZIP/DATEV liefern korrekte
Inhalte, Storno kehrt Soll/Haben korrekt um, Feldzahlen exakt 31/125,
Encoding rund-trip-fest.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
