[GNC-dev] „Accruals are potentially missing as account_types in the db scheme

[davidcousens49 at gmail.com]

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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel