Alex, My understanding of the use of accrual accounts in Germany is very limited. but my understanding that the e-Bilanz requires a mapping of the general ledger accounts in GnuCash onto a taxonomy which defines the format of the E-Bilanz ( presumably theDiFin - the digital financial reports in XBRL format and that this taxonomy can be changed annually by the Ministry of Finance.
Given this it seems that it would make much more sense to construct this mapping externally using the python interface to construct the required mapping and to produce the XBRL document required for submission from a stock standard GnuCash data file/database. Others may be able to answer whether the python bindings provide sufficient database/datafile access to be able to produce this mapping as I have no experience using them. A shift to accrual accounting proper, while it will primarily affect the business features accounts in GnuCash, involves a change primarily in the timing of when transactions including income and expenses are recorded not a particular positioning of accounts in the Accounts heirarchy. The timing or recording an event in accrual accounting is determined, not by the exchange of monies, but by the time of entering into the contractual commitment to receive or expend funds. Standard accounting practice for accruals accounting (the default in most jurisdictions in any case - GnuCash has no special requirements to implement it other than the user entering the appropriate date/time for a specific transactions and the business features and accounts implement it implicitly) has no requirement for a separate category of Accruals accounts and doing so would complicate even further the programming of the application of the accounting equation which is fundamental to accounting practice. Some of these accounts are classifiable as Assets and some as Liabilities and having both Asset and Liability accounts in a single class of Accruals is a mess. As usual when governments implement these sort of things what you actually have to do is hidden deeply in multiple layers of gobbledegook so neither they nor anyone else can really be clear on what is actually required. This is usually because they outsource this development to private companies who have a vested interest in the obscurity to ensure you are required to use their particular proprietary software to successfully submit electronically. This seems to be the case both in the UK and Australia with the implementation of digital submission using XRBL which is really what the e-Bilanz seems to be really about. Heiling's 2020 paper (has some perspectives on the transition to accrual accounting in Germany although not directly relevant to the e_Bilanz question David Cousens On Wed, 2022-04-13 at 07:58 +0200, Alex Ritzer wrote: > Hello, > > I'm currently using GnuCash 4.1. on Windows with a mysql Backend > > Every year I have to create a so called "e-Bilanz" for the german finance > department after the annual statement of accounts . > > Due to the mandatory Taxonomie I have to use among other things the > following acoounts: > > Activ: > (Fixed Assets) de-gaap-ci:bs.ass.fixAss > (Current Assets) de-gaap-ci:bs.ass.currAss > > Passiv: > (Equity) de-gaap-ci:bs.eqLiab.equity > (Accurals)de-gaap-ci:bs.eqLiab.accruals > (Liability) de-gaap-ci:bs.eqLiab.liab > > [image: image.png] > > Currently I programmed a workaround in python to get all the liabilities > from the db. > Still it would be nicer, if we would have an account_type "accurals" or > another field in the table accounts to distinguish between liability and > accurals. > > > From a short check on the db model I would estimate that there would be no > harm on the db > Scheme, if a new account type or another field would be added. > > Regards > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
