RechnungsFee v0.5.4

💾 Downloads

Plattform	Download
🪟 Windows (x64)	⬇ RechnungsFee_0.5.4_x64-setup.exe
🐧 Linux (x86_64, versioniert)	⬇ RechnungsFee_0.5.4_amd64.AppImage
🐧 Linux (x86_64, via install.sh)	⬇ RechnungsFee_amd64.AppImage
🐧 Linux Installer	⬇ install-linux.sh
🍎 macOS (Apple Silicon, versioniert)	⬇ RechnungsFee_0.5.4_aarch64.dmg
🍎 macOS (Apple Silicon)	⬇ RechnungsFee_aarch64.dmg

🐧 Linux: install-linux.sh lädt die App nicht selbst herunter – zusätzlich die AppImage in denselben Ordner legen (empfohlen: die neutrale RechnungsFee_amd64.AppImage, bleibt bei Updates gleich benannt). Dann bash install-linux.sh ausführen (kein chmod +x nötig).

🍎 macOS: Nicht signiert – beim ersten Start Rechtsklick → Öffnen, oder:
xattr -cr RechnungsFee_0.5.4_aarch64.dmg

🔍 OCR für gescannte Belege & Kassenbons (Tesseract OCR):

• 🪟 Windows: automatisch durch den Installer
• 🐧 Linux: wird vom install-linux.sh-Skript angeboten; manuell: sudo apt install tesseract-ocr tesseract-ocr-deu
• 🍎 macOS: brew install tesseract tesseract-lang

Ohne Tesseract zeigt RechnungsFee einen Installationshinweis sobald ein gescannter Beleg importiert wird.

---

✨ Neu

• Vorsteuerabzug nach Soll-Prinzip (§15 UStG): Die Vorsteuer aus Eingangsrechnungen ist rechtlich bereits mit Rechnungseingang abzugsfähig – unabhängig vom Zahlungsdatum und unabhängig davon, ob du selbst Ist- oder Soll-versteuerst (das betrifft nur deine eigene USt-Schuld, nicht den Vorsteuerabzug). Bisher wurde die Vorsteuer in der UStVA erst beim tatsächlichen Bezahlen einer Eingangsrechnung berücksichtigt – eine unbezahlte Eingangsrechnung tauchte damit gar nicht auf. Ab dem 01.10.2026 gilt: Eingangsrechnungen werden bereits bei der Finalisierung mit ihrer Vorsteuer in der UStVA erfasst, unabhängig davon wann (oder ob) sie bezahlt werden. Voraussetzung dafür ist ab diesem Datum eine Kategorie je Position (oder als Hauptkategorie) bereits bei der Finalisierung – bisher war das erst beim Bezahlen nötig. Eingangsrechnungen mit Rechnungsdatum vor dem 01.10.2026 sind davon nicht betroffen und laufen unverändert wie bisher über das Zahlungsdatum. Die EÜR ist von dieser Änderung nicht betroffen und bleibt weiterhin korrekt beim Zahlungsdatum (Zufluss-/Abflussprinzip §11 EStG) – das ist eine andere Rechtsgrundlage als der Vorsteuerabzug (Issue #338).
• Rabatt (Position und Gesamtbetrag, in % oder €) ist jetzt auch bei Angeboten, Aufträgen und Proforma-Rechnungen verfügbar – bisher gab es das Rabatt-Feld nur bei Rechnungen, obwohl das Backend es für alle Dokumenttypen bereits unterstützte.
• Bank-Import – neues Template für Finom (CSV-Export). Berücksichtigt die Finom-Eigenheiten Dezimalpunkt statt Komma, „N/A" statt leerer Felder bei Kartenzahlungen (jetzt generisch als leer behandelt, betrifft auch künftige Banken mit demselben Verhalten) und ein gequotetes Feld mit eingebettetem Komma bei der Jahresgebühr. Der von Finom ebenfalls angebotene MT940-Export (rohes SWIFT-Format) wird nicht unterstützt – dafür bräuchte es einen eigenen Tag-Parser, den es in RechnungsFee noch nicht gibt. Danke an flole für den sehr detaillierten Report inkl. anonymisierter Beispieldateien (Issue #342).

🐛 Bugfixes

• Der Rabatt auf den Gesamtbetrag ging beim erneuten Speichern eines bereits angelegten Dokuments (z. B. Entwurf bearbeiten) verloren – betraf alle Dokumenttypen inkl. normaler Rechnungen. Ursache: Das Update-Schema im Backend kannte die Felder für den Gesamtrabatt gar nicht, nur das Anlegen-Schema. Nur der Rabatt beim allerersten Speichern kam korrekt an, jede weitere Bearbeitung setzte ihn stillschweigend auf 0 zurück.
• Reverse Charge (ig. Erwerb / §13b UStG) auf einer Kategorie mit 0 % Vorsteuerabzug (z. B. „Bankgebühren“, inländisch nach §4 Nr. 8 UStG steuerfrei) verwarf die Vorsteuer stillschweigend, obwohl der Sonderfall-Haken sie ausdrücklich zusagte – die UStVA wies dadurch eine zu hohe Zahllast aus. Betroffen war jede 0 %-Kategorie in Kombination mit ig. Erwerb, §13b Abs. 1 oder §13b Abs. 2 – also typischerweise EU-Anbieter für Hosting, SaaS oder Zahlungsdienste. Die 0 % einer Kategorie beschreiben nur den inländischen Normalfall der Ausgabenart, nicht den Reverse-Charge-Sonderfall, bei dem die Vorsteuer nach §15 Abs. 1 Nr. 3/4 UStG unabhängig davon in voller Höhe abziehbar ist. Danke an flole für den Report inkl. Ursachenanalyse und Lösungsvorschlag (Issue #339).
• Beim Verbuchen der Zahlung einer Reverse-Charge-Eingangsrechnung (ig. Erwerb / §13b) wurde der Zahlbetrag fälschlich als Bruttobetrag inkl. USt behandelt und die USt daraus herausgerechnet – tatsächlich zahlt man an einen ausländischen Anbieter ohne ausgewiesene deutsche USt immer den Nettobetrag, die USt wird additiv aufgeschlagen (z. B. 128,38 € Zahlbetrag ergaben fälschlich 107,88 € Netto/20,50 € USt statt korrekt 128,38 €/24,39 €). Betrifft Netto- und USt-/Vorsteuerbasis in Journal und UStVA gleichermaßen; beim Buchen über das Journal direkt oder bei einer normalen (nicht Reverse-Charge-)Eingangsrechnung war das schon immer korrekt. Derselbe Fehler steckte in einer zweiten, unabhängigen Kopie derselben Berechnung beim automatischen Verbuchen aus dem Bank-Import – ebenfalls angeglichen (Issue #339-Folgefund).
• EÜR – Buchungen auf „EU-Dienstleistungen (§13b Abs. 1)" oder „Drittland-Dienstleistungen (§13b Abs. 1)" (z. B. Hosting, SaaS, Zahlungsdienste aus dem Ausland) erschienen in Zeile 27 „Waren, Rohstoffe, Hilfsstoffe" statt in Zeile 60 „Sonstige Betriebsausgaben" – beide Kategorien erfassen laut Namen sonstige Leistungen, keine Waren, so wie es die dritte Reverse-Charge-Kategorie „Bauleistungen / §13b Abs. 2" bereits richtig macht. Die Gewinnhöhe war davon nicht betroffen, nur die Zeilenzuordnung im amtlichen Formular. Danke an flole für den Report (Issue #340).
• Journal – selbst angelegte Kategorien mit Kontenart „Privat" (z. B. für Personengesellschaften mit getrennten Einlage-/Entnahme-Konten je Gesellschafter) waren im Buchungsformular nicht auswählbar; angeboten wurden ausschließlich die beiden mitgelieferten Kategorien „Privateinlage" und „Privatentnahme". Bei einer bereits über die API angelegten Buchung auf einer eigenen Privat-Kategorie stand das Kategoriefeld beim Öffnen zum Bearbeiten sogar leer, da die passende Option im Dropdown fehlte – beim Speichern wäre die Kategorie verloren gegangen. Ursache war eine Namensprüfung statt einer Prüfung der EÜR-Zeile; eigene Privat-Kategorien sind jetzt sichtbar. Danke an flole für Report und Lösungsvorschlag (Issue #341).
• DATEV-Export – bei einer mit Skonto bezahlten Rechnung (z. B. 119,00 € Rechnung, 2 % Skonto, 116,62 € bezahlt) wurde das Skonto in der DATEV-Buchhaltung doppelt abgezogen: Das Erlöskonto kam nur mit dem bereits geminderten Betrag (116,62 €) an statt mit den vollen 119,00 €, und die Bank wurde durch die separate Skonto-Buchung zusätzlich um den Skonto-Betrag reduziert, obwohl die tatsächliche Zahlung bereits vollständig in der Hauptbuchung steckte. Ursache: Die Skonto-Buchung wurde mit „Bank" als Gegenkonto exportiert statt mit dem Erlös-/Aufwandskonto der zugehörigen Rechnung – dort findet aber kein zusätzlicher Zahlungsfluss statt, nur eine Umbuchung zwischen Erlös- und Erlösschmälerungskonto. Danke an Peter1061 für den Report (Issue #343).