GnuCash 5.9 veröffentlicht

 (gnucash.org)
2 Punkte von GN⁺ 2024-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • GnuCash 5.9 ist das zehnte Release der stabilen 5.x-Serie und enthält Fehlerbehebungen seit 5.8 sowie Verbesserungen beim CSV-Datumsparsing und bei Online-Kursen
  • Diese Version behebt 12 Bugs, unter anderem im Abstimmungsfenster, bei Fehlermeldungen des MySQL-Backends, beim Kopieren/Einfügen von Buchungen, bei einem Absturz beim Löschen von Konten und bei einem Locale-Fehler mit dem Dezimaltrennzeichen des Windows-Ziffernblocks
  • Für Online-Kurse wurden die API-Key-Konfiguration für YH Finance(FINANCEAPI) und die Quelle financeapi hinzugefügt; der CSV-Import verarbeitet locale-basierte Datumsangaben und englische Monatsnamen besser
  • Pakete für Windows 10 oder neuer, macOS 10.13 High Sierra oder neuer sowie ein Flathub-Flatpak sind verfügbar; wer selbst bauen möchte, benötigt die angegebenen Mindestabhängigkeiten wie Gtk+, Guile und Boost
  • Deutsche AQBanking-Nutzer verwenden das gebündelte AQBanking 6.5.4; die Beta der neuen PIN/TAN-Implementierung ist nur in GnuCash nightly builds verfügbar

Charakter des GnuCash-5.9-Releases

  • GnuCash 5.9 ist das zehnte Release der stabilen 5.x-Serie
  • GnuCash ist ein kostenloses Open-Source-Buchhaltungsprogramm, das unter der GNU General Public License(GPL) verbreitet wird und GNU/Linux, *BSD, Solaris, macOS sowie Microsoft Windows unterstützt
  • Die Entwicklung begann 1997, das erste stabile Release erschien 1998

Wichtige seit 5.8 behobene Probleme

  • Ein Problem wurde behoben, bei dem neu hinzugefügte Buchungen während einer Abstimmung(reconcile) nicht im Abstimmungsfenster erschienen
  • Das MySQL-Backend meldet bei ungültigen Zugangsdaten nun "access denied" statt "bad or corrupt data"
  • Das Verhalten beim Kopieren/Einfügen sowie Ausschneiden/Einfügen von Buchungen wurde korrigiert
    • Dazu gehört ein Problem, bei dem das Ausschneiden/Einfügen von Buchungen die Buchung nicht in das Zielkonto verschob
  • Ein Problem wurde behoben, bei dem Beispiel-Python-Skripte beim Erstellen einer neuen Datei mit dem sqlite-Backend Fehler ausgaben
  • In der Ansicht Transaction Journal wurde ein Problem behoben, bei dem die Cursorposition nach dem Commit von Änderungen an Buchungen verschoben war
  • Fehler beim Parsen des Abstimmungsdatums, ein Absturz beim Löschen von Konten und ein Fehler bei der Quartalsberechnung relativer Datums-Offsets wurden behoben
  • Unter Windows wurde ein Problem behoben, bei dem die Eingabe des Dezimaltrennzeichens über den Ziffernblock nicht zum Locale passte
  • Ein zu kleines Konto-Dropdown-Listenfeld im Bildschirm zum Buchen von Rechnungen sowie sporadische Probleme mit Kurswerten wurden korrigiert

Verbesserungen bei Online-Kursen und CSV-Import

  • Der Infrastruktur für Online-Kurse wurde die API-Key-Konfiguration für YH Finance(FINANCEAPI) hinzugefügt
    • Die zugehörigen Einstellungen können auf der Seite Online Quotes verwaltet werden
    • financeapi wurde zu den bekannten Kursquellen hinzugefügt
  • Der CSV-Datumsparser wurde verbessert und nutzt nun ICU und Boost
    • Datumsangaben des aktuellen Locales werden über das ICU-basierte Locale-Datumsformat geparst
    • Eingaben wie "3 May 2023" oder bei LC_TIME=zh_TW.utf8 "2024年9月13日" können verarbeitet werden
    • Die Formate d-m-y, m-d-y und y-m-d werden durch die UK/US/ISO-Parser von Boost ergänzt
    • Datumsangaben mit englischen Monatsnamen wie "30 Sep 2023", "May 4, 1978" oder "2023-Dec-25" können ebenfalls beim CSV-Import verarbeitet werden
    • Der Boost-Parser erkennt keine zweistelligen Jahreszahlen, daher ist "30 Sep 24" nicht gültig
  • Die Einführungsseite des CSV Import Assistant wurde verbessert

Interne Aufräumarbeiten und entwicklerseitige Änderungen

  • Die Struktur zur Verarbeitung kopierter Elemente wurde aufgeräumt
    • copied_class und copied_leader_guid wurden von statischen Variablen in die Struktur copied_item verschoben
    • Es wurde deutlicher gemacht, dass der Aufruf von clear_copied_item vor der Verwendung von copied_item erforderlich ist
  • Nicht committete Bearbeitungen werden beim Öffnen von Dateien aus der Dateihistorie korrekt behandelt
  • gnc_difftime wurde als deprecated markiert, weil es time64 nach double castet
  • Die ungenutzten Funktionen gnc_pricedb_substitute_commodity und gnc_pricedb_lookup_at_time64 wurden entfernt

Änderungen an Übersetzungen und Dokumentation

  • Neu hinzugefügte oder aktualisierte Übersetzungen: Assamese, Chinese(Simplified), Chinese(Traditional), Croatian, Dutch, English(United Kingdom), Hebrew, Hungarian, Macedonian, Norwegian Bokmål, Portuguese(Brazil), Russian, Spanish, Swedish und Turkish
  • Die Änderung an der Dokumentation betrifft ein Update der GitHub-CI-actions-Versionen
  • Bei den Dokumentationsübersetzungen wurde German neu hinzugefügt oder aktualisiert
  • Informationen zur Mitarbeit an Übersetzungen finden sich im GnuCash-Projekt auf Weblate

Hinweise zu AQBanking

  • Es sind separate Hinweise für deutsche AQBanking-Nutzer enthalten
  • Der Autor von AQBanking arbeitet weiter am Abschluss des aktualisierten PIN/TAN-Codes
  • Die Flatpak-, macOS- und Windows-Bundles dieses Releases enthalten die letzte stabile Version AQBanking 6.5.4
  • Falls das stabile AQBanking nicht funktioniert, können GnuCash nightly builds mit der Beta der neuen Implementierung in Betracht gezogen werden
  • Die vollständige Liste der offenen Bugs ist in der GnuCash-Bugliste einsehbar

Distributionspakete und Build-Voraussetzungen

  • GnuCash 5.9 ist als vorgefertigtes All-in-one-Paket für Microsoft Windows 10 oder neuer und macOS 10.13 High Sierra oder neuer verfügbar
    • Unter Windows wird es als Installer bereitgestellt
    • Das macOS-Paket ist ein Disk-Image mit einem Drag-and-drop-Anwendungsbundle
  • Es ist außerdem als Flatpak über Flathub.org verfügbar
  • Die Download-Dateien umfassen Tarball, Windows-Installer, dmg für Apple Silicon, dmg für Intel-Macs und Dokumentations-Tarball
  • Der Quellcode ist bei SourceForge und GitHub im Format bzip2 oder gzip erhältlich und kann auch direkt aus dem Git-Repository ausgecheckt werden
  • Für die eigene Kompilierung sind folgende Mindestabhängigkeiten erforderlich
  • Die genaue Liste der Abhängigkeiten und Versionen ist der Datei README.dependencies im Quellcode zu entnehmen

GnuCash-5.9-Dokumentation

  • Die Dokumentation zu GnuCash 5.9 ist auf der Documentation page der GnuCash-Website verfügbar
  • Unter GnuCash v5 (current stable release) werden Online-Lesen und Downloads in mehreren Sprachen angeboten
  • Die Download-Formate umfassen pdf, epub und mobi
  • Die Dokumentation ist auch in den macOS- und Windows-Anwendungsbundles enthalten
  • Die Quellen für GnuCash Documentation 5.9 sind bei SourceForge oder GitHub erhältlich und können auch direkt aus dem Git-Repository ausgecheckt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-02
Meinungen auf Hacker News

  • Ich nutze GnuCash für die Buchhaltung meines Unternehmens, und es bietet genug von den Funktionen, die ich brauche.
    QuickBooks, das VCs in Blogs empfehlen, nutze ich nicht; es hat zwar bequeme Funktionen, aber nicht so sehr, dass ich den Preis zahlen würde, und ich brauche weder VC-Geld noch einen CPA.
    Ich habe GnuCash noch nie mit SQLite verwendet, würde es aber gern ausprobieren, wenn ich Zeit habe, und frage mich, wie zuverlässig es ist.
    Früher habe ich als Technik-/Funktions-Engineer für Oracle EBS gearbeitet und dabei komplexe, bis in die Nebenbücher miteinander verflochtene Schemata betreut; außerdem habe ich immer wieder darüber nachgedacht, Funktionen zur Erlöserfassung zu GnuCash hinzuzufügen.
    Wenn ich mir das SQLite-Schema ansehe, könnte ich es vielleicht einmal versuchen.

    • Falls jemand, der von QuickBooks migriert, anderen helfen möchte: Der qb-escape-Konverter von QuickBooks zu GnuCash braucht Unterstützung: https://github.com/erikmack/qb-escape/
    • SQLite ist in GnuCash stabil.
      Ich bin vor ein paar Jahren von XML auf SQLite umgestiegen und hatte keine Probleme.
    • Für den Privatgebrauch oder ein sehr kleines Unternehmen ist es großartig, aber wenn man versucht, ein echtes Startup mit GnuCash zu betreiben, kann man in große Schwierigkeiten geraten.
      Aus eigener Erfahrung ist GnuCash-Eiferertum schädlich; die Geschäftswelt mag GnuCash nicht und interessiert sich nur für QuickBooks.
      Seit Anfang der 2000er habe ich diesen Kampf in Non-Profits und Startups geführt, und früher war ich selbst jemand, der sagte: „Wir müssen unbedingt GnuCash verwenden.“
      In einer idealen Welt wären GnuCash oder irgendein anderes Tool außer QuickBooks eine Option für die Buchhaltung kleiner Unternehmen, aber in der Realität hat Intuit es über APIs und Dateiformate schwer gemacht, sich für etwas anderes als QuickBooks zu entscheiden.
      Wenn man QuickBooks nicht verwendet, macht man es Banken, Investoren, Payroll-Systemen, Steuersystemen und Buchhaltern schwerer; in manchen Fällen können sogar Fördermittel oder Audits blockiert werden.
      Ich sehe oft Situationen, in denen wohlmeinende Open-Source-Anhänger die Nutzung von GnuCash verlangen; so jemand sollte man nicht sein.
      Die Welt hat sich für QuickBooks entschieden, und diese Entscheidung kam zwar unter Druck und durch korrupte Machtvermittlung zustande, ist aber bereits gefallen.
      Es mag brauchbare SaaS-Optionen geben, aber nur solange Intuit sie zulässt; wer mit QuickBooks konkurriert, wird wahrscheinlich von Intuit übernommen und verschwindet.
      Mehrere Non-Profits und Unternehmen haben GnuCash gewählt und mussten dann wegen Finanzierungsabschlüssen, Bankanforderungen, Kreditanfragen oder Förderanträgen hastig die Plattform wechseln; am Ende musste die Buchhaltung alles in Wochen mit über 60 Arbeitsstunden neu machen.
      GnuCash ist ein tolles Projekt, und es wäre schön, wenn alle es nutzen könnten, aber für ein echtes Unternehmen ist es aus willkürlichen und künstlich geschaffenen Gründen nicht nutzbar.
      Wenn ein Buchhalter käme und euch zwingen würde, NetBeans zu verwenden, würdet ihr das nicht akzeptieren; bei der Wahl ihrer Werkzeuge sollte man ihnen also denselben Respekt entgegenbringen.
    • Es wirkt wie ein weiteres Beispiel dafür, dass freie Software dank ihrer Eigenschaft, kostenlos wie Freibier zu sein, Erfolg hat.

  • Ich habe schon viele Programme für private Buchhaltung ausprobiert, aber abgesehen vom alten Pocket Money für PalmOS war die Eingabe von Ausgaben bei allen viel zu umständlich.
    Wenn man den gesamten Ladenbesuch als eine Transaktion wie „Lebensmittel bei Lidl“ erfasst, ist es erträglich. Versucht man aber, jede Zeile des Kassenzettels als eigenen Posten einer Split-Buchung einzutragen, muss man sie jedes Mal wieder neu eingeben, ohne gute Vorschläge auf Basis früherer Einträge.
    Dabei könnte das ziemlich ausgefeilt sein: Wenn der Geschäftspartner Lidl ist, könnte schon „br“ food:bread samt Preis vorschlagen; wenn der Geschäftspartner Victoria Secret ist, clothing:bra mit einem anderen Preis. Aber nichts von dem, was ich ausprobiert habe, unterstützt das.
    Das wirklich alte PalmOS 3.0 Pocket Money war sehr komfortabel, und alles andere, ob Desktop oder mobil, ist in diesem Punkt deutlich schlechter.
    Wenn man Transaktionen sehr detailliert erfasst, halte ich verschachtelte Kategorien für besser als verschachtelte „Konten“.
    Es ist fast nur ein oberflächlicher Unterschied, aber es wirkt seltsam, dass „Bargeld“ und „food:meat:pork“ Objekte derselben Art sein sollen.
    Man überweist Geld nicht nach „food:meat:pork“, sondern gibt es dafür aus; man sendet Geld an ein Geschäft, nicht an eine Ware.
    Nach meinem Verständnis legen auch professionelle Buchhaltungssysteme nicht für jeden Monitor, Laptop, Computer und jede Maus ein eigenes Anlagenkonto des Unternehmens an.
    Vielleicht habe ich es nur noch nicht gefunden; ich frage mich, ob es etwas Empfehlenswertes gibt.

    • Ich frage mich, ob es tatsächlich so nützlich ist, jeden einzelnen Posten eines Kassenzettels nachzuverfolgen.
      Für manche Arten von Käufen kann es sinnvoll sein, aber im Verhältnis zum Aufwand ist es wahrscheinlich unnötige Detailarbeit, die keinen entsprechenden Mehrwert schafft.
    • Ich habe früher mehrere Tools ausprobiert und war um 2009 herum von proprietärer OS-X-Software, insbesondere iBank, genervt; GNUCash und KDEMoney gefielen mir ebenfalls nicht, also habe ich mir schließlich selbst eine einfache Open-Source-App gebaut.
      Es ist eine native Cocoa-App, inzwischen gibt es auch einen Qt-Port für Linux, und ich nutze sie seitdem täglich.
      Früher habe ich Kategorien sehr fein aufgeteilt, aber heute sehe ich darin kaum noch Sinn. Die App unterstützt Split-Buchungen, aber normalerweise verwende ich nur Kategorien wie „Lebensmittel“, „Getränke“ und „Bedarfsartikel“.
      Dinge wie „Kaffee“ führe ich allerdings als „Drinks:Coffee“, damit ich sehen kann, wie viel ich für bestimmte Posten ausgebe.
      Am Ende scheint es eine Frage der Balance zwischen dem Aufwand für so genaue Erfassung und dem tatsächlichen Nutzen zu sein; bei „Car:Fuel“, „Car:Service“ usw. ist es genauso.
    • Als ich anfing, meine Finanzen zu verfolgen, stieß ich mit einer Tabellenkalkulation schnell an Grenzen, und die vorhandenen Optionen passten nicht zu meinen Bedürfnissen.
      Für die meisten Menschen mag Tracking in dieser Detailtiefe übertrieben sein, aber für mich kostet es nicht viel Zeit.
      Also habe ich schließlich selbst eine App gebaut: https://github.com/VMelnalksnis/Gnomeshade
      Bei Konten ging es mir ähnlich, daher habe ich Transaktionen in zwei Teile aufgeteilt: Umbuchungen und Käufe. Dadurch kann ich mehrere Währungen handhaben und Kategorien getrennt von Konten behandeln.
      Die erwähnten automatischen Vorschläge habe ich mir nicht angesehen; stattdessen bin ich dazu übergegangen, Kassenzettel für häufig gekaufte Dinge zu parsen.
    • Vermutlich unterteilst du zu fein.
      Ich unterscheide nur grob nach „Lebensmittel“, „Verbrauchsmaterial“ und „Kleidung“.
      Ich habe nicht ganz verstanden, was du genau brauchst, aber ich bin vor mehr als zehn Jahren von GnuCash zu KMyMoney gewechselt.
      Wenn man bei Walmart früher einzelne Posten eingegeben hat, nimmt es beim nächsten Walmart-Besuch und Import der Kreditkartenabrechnung eine frühere Walmart-Transaktion mit ähnlichem Gesamtbetrag als Ausgangspunkt, was ein wenig hilft.
      Und KMyMoney verwendet Kategorien statt Konten, auch wenn der Kontenansatz besser zu den Buchhaltungsgrundsätzen passt.
    • Es wäre schön, wenn es für diesen Zweck ein QR-Code-Format auf Kassenzetteln gäbe.
      Es könnte ungefähr den Namen/Standort des Geschäfts, den Gesamtbetrag, getrennte Steuerfelder, bei einfachen Käufen eine allgemeine Kategorie wie „Kraftstoff“ oder „Essen“ auf einem McDonald’s-Beleg sowie Postengruppen für Orte wie Costco enthalten, wo man Lebensmittel und Kleidung zusammen kaufen kann.
      Für die Hauptkategorien könnte man sich an dem orientieren, was mehrere Länder für Verbraucherpreisindex-Kategorien verwenden.
      https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
      https://www.bls.gov/news.release/cpi.t01.htm
      https://www.stat.go.jp/english/data/cpi/158c.html
      https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...

  • Das GNUCash-Modell gefällt mir nicht besonders.
    Es ist etwas mühsam zu benutzen, und es ist ziemlich schwierig, die gewünschten Statistiken herauszubekommen; früher habe ich mehrere andere Pakete ausprobiert und mich dann für eines entschieden.
    Trotzdem: Als ich vor Jahrzehnten meinen ersten Job bekam, gab es GNUCash bereits, und es gibt es immer noch.
    Es scheint nur wenige andere Pakete zu geben, die eine solche Beständigkeit gezeigt haben.

    • Dass es ein Utility-Design aus der Mitte der 90er hat, ist durchaus reizvoll.
      Gleichzeitig ist genau dieses 90er-Jahre-Interface unglaublich frustrierend.
      Ich habe kaum ein Utility gesehen, dessen Interface-Design sich so wenig weiterentwickelt hat wie bei GNUCash.
      Es fühlt sich an, als hätte man einen Prototyp gebaut, „perfekt!“ gesagt, Nutzerfeedback ignoriert und sich dann der Backend-Arbeit zugewandt.
    • Diese Beständigkeit ist enorm wertvoll.
      Ich nutze gnucash seit Ende der 90er und habe sämtliche Datendateien bis zurück ins Jahr 2000.

  • Habe es vor ein paar Jahren ausprobiert, bin am Ende aber bei HLedger geblieben
    Wie bei GnuCash kann ich meine Daten besitzen und kontrollieren, aber mit HLedger kann ich sie direkt in Sublime Text bearbeiten und massenhaft Dinge korrigieren oder ändern
    Mein Anwendungsfall ist natürlich ziemlich grundlegend und kein geschäftskritisches System, daher kann das je nach Person anders sein

    • Das ist ein triftiger Grund, GnuCash nicht zu verwenden
      Ich stimme zu, dass das XML-Format nicht großartig ist, aber ich nutze das SQLite-Format und kann darauf Skripte aufsetzen
    • Ich nutze Firefly III: https://firefly-iii.org
      Als selbst gehostete Web-App passt es gut für mich, da ich es meistens am Smartphone verwende
      Es hat eine recht umfangreiche API, und auch wenn Massenbearbeitung nicht so einfach ist wie bei Textdateien, dürfte sie vergleichsweise unkompliziert sein
      Es gibt auch ein Regelsystem, das man für Massenbearbeitungen nutzen kann
    • Ich nutze GnuCash, und dass Massenänderungen oder einfaches Scripting nicht möglich sind, ist ziemlich lästig
      Besonders zum Beispiel, wenn man beim CSV-Import einen kleinen Fehler gemacht hat
    • Ich habe hledger und ledger, insbesondere die Lots-Funktion, mehrere Jahre lang genutzt
      Eine der Stärken von hledger ist sein sehr flexibles CSV-Regelsystem
      Daran habe ich ein kleines Python-Skript gehängt, um zusätzliche Informationen einzufügen, die für die Erfassung von Kapitalgewinnen nötig sind
      Am Ende sind die Roh-Eingabedaten CSV-Dateien mit den Aufzeichnungen, und die Ausgabe sind Finanzberichte in verschiedenen Detailstufen
    • Ich lasse tatsächlich ein kleines Skript laufen, das gnucash-XML in ledger umwandelt, und verfolge sowohl das Konvertierungsergebnis als auch das ursprüngliche XML mit git
      Wenn man es beim Eingeben in die gnucash-UI ziemlich häufig ausführt, kann man die Änderungen als gut lesbare git-Logs und Diffs sehen
      Allerdings fehlt die Fähigkeit zu „Massenänderungen“
      Da gnucash einfach XML ist, könnte man es direkt bearbeiten, aber ich habe mich bisher noch nicht daran gewagt
      Basierend auf [0]: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • Wir nutzen GnuCash für die Buchhaltung eines Hackerspaces
    Die Wahl war, entweder das zu verwenden oder eine Website namens „wave“, die der Buchhalter eines nahegelegenen Makerspaces empfohlen hatte
    Ich habe mich bei wave registriert und ein wenig damit herumgespielt, war aber nicht überzeugt; ein paar Wochen später, als ich mich entschieden hatte, wave zu verwenden, war mein Konto ohne ersichtlichen Grund gesperrt
    Also sind wir zu GnuCash gegangen
    Es ist gute Software, und am Ende habe ich Code geschrieben, der dynamisch gegen die libgnucash-Bibliothek linkt, um monatliche Rechnungen für Mitgliedsbeiträge automatisch zu erzeugen

    • Ich frage mich, ob es keinen besseren Weg gibt, GnuCash zu automatisieren, etwa mit Bash- oder Python-Skripten
    • Interessant; ich frage mich, ob du den Code teilen kannst

  • Bevor ich mich für Beancount oder generell Plain-Text-Accounting als persönliche Finanzsoftware entschieden habe, habe ich mir GnuCash genauer angesehen
    Der entscheidende Knackpunkt war das interne XML- oder SQLite-Format von GnuCash
    Für das Sammeln von Rohdaten oder das Skripten der Berichtserstellung ist es nicht besonders gut geeignet; Plain-Text-Tools wie Beancount oder HLedger zielen genau darauf ab
    Im Vergleich zu Plain-Text-Tools fühlt sich GnuCash zu sehr wie ein Walled Garden an
    Plain-Text-Formate erfordern anfangs mehr Arbeit, sind aber großartig, wenn man sich daran gewöhnt hat und einen Scripting-Hintergrund mitbringt

    • Geschmackssache, aber meine Erfahrung ist genau das Gegenteil
      Plain Text wirkt für Menschen einfach lesbar, ist strukturell aber ein Albtraum beim Parsen, und das Skripten von Plain-Text-Bearbeitung ist ebenfalls unsauber
      Datenbanken hingegen sind genau für solche Zwecke gemacht
      Nachdem ich viel Zeit mit Beschwerden über Plain-Text-Accounting und Verbesserungsversuchen verbracht hatte, nutze ich jetzt SQLite, und das war eine enorme Verbesserung
    • Wenn das XML-/DB-Schema dokumentiert ist, ist es in der Praxis besser und robuster als das Plain-Text-Format von Beancount/Ledger
      Ich nutze das XML-Backend von KMyMoney und habe auch ein Skript, das die Daten ins Ledger-Format umwandelt
      Gerade weil es kein Freiformtext ist, war dieses Skript eher leichter zu schreiben
    • Die Kombination Beancount + Fava sieht ziemlich gut aus; ich frage mich, ob du von deinen Erfahrungen damit erzählen kannst
    • Wenn SQLite nicht ausreicht, unterstützt GnuCash auch SQL-Backends
      Ich betreibe es seit fast 10 Jahren so

  • GnuCash hat einen besonderen Platz in meinem Herzen
    In den ersten Jahren nach dem Uniabschluss habe ich mit knappem Einkommen ein sehr enges Budget geführt, und nach jedem Einkauf habe ich den Kassenbon mit nach Hause genommen und gewissenhaft in die Bücher eingetragen
    Am Ende hat immer alles gestimmt, aber es war enorm viel Arbeit

  • Als freiberuflicher Berater in Schweden habe ich mir GnuCash in den letzten über zehn Jahren mehrfach angesehen, hatte aber immer dasselbe Problem
    Es ist nicht auf unsere Wirtschaft und das System der Steuerbehörde zugeschnitten
    In Schweden kann man bei einem Jahresumsatz von unter 3 Millionen SEK ein „förenklat årsbokslut“ verwenden, grob gesagt einen „vereinfachten Jahresabschluss“
    In der Praxis reicht es, ein sehr einfaches Programm zur Verwaltung von Ausgaben und Einnahmen selbst zu schreiben, die nötigen Zahlen zu erzeugen und sie jedes Jahr manuell in die Online-App der Steuerbehörde einzutragen

    • Ich bin ebenfalls Solo-Freelancer und nutze den vereinfachten Abschluss
      Doppelte Buchführung hat nach der anfänglichen Lernkurve nicht mehr Aufwand verursacht als einfache Buchführung
      Denn sie hilft, häufige Fehler automatisch zu vermeiden
      Ich nutze GnuCash seit 20 Jahren erfolgreich und habe nicht vor, zu fragilen Tabellenkalkulationen oder einer halbgar gebauten Access-DB zurückzukehren

  • Ich habe GnuCash eine Zeit lang genutzt, aber am Ende zu viel Zeit damit verbracht, die Online-Synchronisierung richtig einzurichten.
    Bei Konten, die manuell heruntergeladen und importiert werden mussten, führte die zusätzliche Reibung dazu, dass ich den Import immer wieder aufschob.
    Inzwischen zahle ich für Quicken Classic, und von allen jährlichen Ausgaben bin ich damit am zufriedensten.
    Die Verbindungen zu Online-Konten funktionieren dauerhaft wie erwartet, und insgesamt erledigt es die Arbeit mit deutlich weniger Kopfzerbrechen.

    • Ich muss Konten in den USA, Kanada, zwei EU-Ländern und Mexiko im Blick behalten.
      Es wäre schön, eine kostenpflichtige Option zu haben, bei der Bankverbindungen so zuverlässig funktionieren wie bei Quicken Classic, aber es scheint nicht einmal ein einzelnes Produkt zu geben, das gleichzeitig die USA und auch nur eine große EU-Volkswirtschaft abdeckt; alle Regionen, die ich brauche, erst recht nicht.
      Quicken Classic ist nur für die USA und Kanada gedacht.
      Ich frage mich, ob jemand solche Optionen kennt oder mehrere Optionen, die man sinnvoll zusammen nutzen kann, um dieses Ziel zu erreichen.
      Dass Unternehmen für den Zugriff auf Transaktionsdaten die Brücke zwischen USA und EU nicht auf eine für Privatpersonen gut nutzbare Weise schlagen, deutet darauf hin, dass es wohl Gründe wie inkompatible Bürokratien auf beiden Seiten gibt.
      Oder vielleicht leben einfach nicht genug Menschen so international.

  • Ich habe mit GnuCash ein Unternehmen geführt und damit auch Gehaltsabrechnung sowie 401k-Konten verwaltet.
    Es war stabil, und für ein Unternehmen mit begrenzten Ausgaben oder wenn man einen Hintergrund in Buchführung hat, war auch die Kostenverfolgung ausreichend.
    Wirklich gut war, dass ich Bilanz und Gewinn-und-Verlust-Rechnung für meinen Steuerberater erstellen konnte.