Re: Deutsche Kontenrahmen und Eigenkapital

Johannes Triegel <[email protected]> Sat, 28 Feb 2026 09:50:56 +0100
Newsgroups gmane.comp.gnome.apps.gnucash.german
Message-ID <[email protected]>
Hallo Gunter,

es sieht so aus als liegen die Dateien dazu hier ab: =

https://github.com/Gnucash/gnucash/tree/stable/data/accounts/de_DE

Hier gibt es eine Beschreibung, wie das funktioniert: =

https://wiki.gnucash.org/wiki/Account_Hierarchy_Template

Am Ende wirst du dich ein bisschen mit Git besch=E4ftigen m=FCssen, damit d=
u =

einen entsprechenden Pull-Request machen kannst: =

https://wiki.gnucash.org/wiki/Git#Pull_Requests

Ich hoffe damit kommst du weiter.

F=FCr mich pers=F6nlich hat sich aber nicht so wirklich der Sinn erschlosse=
n =

einen kompletten SKR04 zu haben, weil ich lege mir eigentlich gerne nur =

die Konten an, die ich wirklich brauche. Die DATEV kennt quasi unendlich =

viele Konten und die meisten Unternehmen (vor allem in dem Bereich wo =

gnucash noch ernsthaft eine Option ist) nutzen vielleicht 20 Sachkonten. =

Aber trotzdem w=E4re eine sinnvolle Vorlage sicher gut.

Gru=DF

Johannes

Am 27.02.26 um 10:30 schrieb Gunter Kramp:
> Hallo zusammen,
>
> mir ist aufgefalle, dass bei allen deutschen Kontenrahmenvorlagen die =

> ich bisher ausprobiert habe ein Fehler drin ist der die Benutzung =

> betr=E4chtlich erschwert:
>
> Die Eigenkapitalkonten sind dort, wie es auch von der DATEV vorgegeben =

> ist als Passivkonten einsortiert.
> M=F6glicherweise weil sie einfach automatisch importiert wurden.
>
> Das funktioniert dann aber in GnuCash nicht weil f=FCr das Programm =

> "Eigenkapital" eine dritte Kontoart der obersten Ebene ist.
> Damit ist dann zum Beispiel nicht m=F6glich Anfangsbest=E4nde oder die =

> Salden des Jahresabschlusses auf diese Konten zu buchen.
>
> Daher finde ich die Kontenrahmenvorlagen sollten ge=E4ndert werden.
>
> Seht ihr das auch so ?
>
> und
>
> Wie k=F6nnte das passieren ?
> Kann mir jemand erkl=E4ren wie ich die =FCberarbeiten und einreichen kann=
 ?
> Oder kann jemand anders das schneller umsetzen als es braucht mir das =

> zu erkl=E4ren?
>
> Ich w=E4re bereit SKR 49, SKR 03 und 04 entsprechend anzupassen.
>
> Randbemerkung: SKR49 ist zwar veraltet, die DATEV will ihn durch SKR42 =

> ersetzen.
>
> SKR42 ist eine Variante von SKR4 und f=FCr GnuCash unbrauchbar weil er =

> Kostenstellen verwendet um die steuerlichen Bereiche eines Vereins =

> bzw. allgemeiner einer gemeinn=FCtzigen Organisation abzubilden.
>
> Daher sollten wir SKR49 weiter anbieten, SKR42 macht wenn =FCberhaupt =

> nur Sinn mit einer klaren Warnung versehen, dass er nicht nutzbar ist =

> solange GnuCash keine Kostenstellen kann.
>
> Zum Gl=FCck ist die Einsch=E4tzung von einigen Vereinsexperten dass reale =

> Nutzung des SKR42 noch fraglich ist, da die zus=E4tzliche Komplexit=E4t =

> von Kostenstellen f=FCr viele Institution zu viel w=E4re.
>
> Zur Implementierung von Kostenstellen habe ich ja hier schon mal was =

> geschrieben.
> SKR42 w=FCrde nicht nur Kostenstellen erzwingen sondern f=FCr realen =

> Einsatz auch, dass diese Kostenstellen als Tags organisiert w=E4ren, =

> dass also eine Buchung auch mehreren Kostenstellen zugeordnet sein =

> k=F6nnen und es dann eine frei definierte Auswertung nach Kostenstellen =

> gibt. Denn gemeinn=FCtzige Institutionen m=FCssen nicht nur nach den =

> steuerlichen Bereichen sondern auch nach Projekten/Abteilungen =

> Abrechnungen erzeugen.
> Hier gilt denke ich: Wer die Komplexit=E4t von Kostenstellen sich gibt =

> braucht das auch.
>
> Herzliche Gr=FC=DFe
> Gunter
>