Among many different implementations of accounting apps there are 2 main approaches to db design when it comes to keeping Journal & Ledger data.
Keep Journal information only & then Ledger is just a view on Journal (as journal always keeps more info than ledger)
Keep Journal in separate table and then post journal entries to ledger table thus duplicating data
When it comes to sub-ledgers/journals there are implementations that have all info in one journal/ledger table & then different views for different sub journal/ledger using charts of accounts as basis
I have seen people have specialized tables for each Sub-journal/ledgers leading to having as many table paurs as there are special journals types (receivables, payables, purchases, sales, etc...)
At the moment, my thinking is that at most, there should be just one Journal and one Ledger table & then specialized journals/ledgers would be compiled at query time through definitions in charts of accounts. I am maybe even considering having Journal table only and then also compiling ledgers at query time as a subset of Joirnals.
I would like to check if i am missing something ? Is there some real reason in having separate Journal and Ledger tables and especially, is there a reason for having specialised journal > specialized ledger > general journal > general ledger tables, as it seems alot of data duplication, insert, update, delete anomalies for a reason i cant see at the moment ?
The main reason could be queries SLAs. From my POV I prefer to have a 3NF data model made with all the entries in the Journal entity. The Journal is then linked to Ledger, COA, etc. In this way you have the ledgers build with views: on the 3NF model you need to build a semantic model made with views (could be materialized views for the queries which have tight SLAs).
In this way you can reduce the duplication materializing only the critical queries and you are open for future integrations/analysis with other data.