2

I've been doing research into the implementation of a double-entry accounting system (specifically using Django as a DB backend). What I am having difficulty understanding is the translation of a "Sub-ledger" and "General Ledger" from the accounting world into the database/software world.

In accounting, we might see something like:

Sales Sub-Journal:
---------------------------------------------------------------
Date      Description           Amount        Acct      Balance
---------------------------------------------------------------
Jan 1     Cust. A Sale         500.00          AR         500.00
Jan 15    Cust. B Sale         300.00          AR         800.00

General Journal:
---------------------------------------------------------------
Date      Description           Acct        Debit      Credit
---------------------------------------------------------------
Jan 15    Sales for Jan          AR          800.00
                                Sales                   800.00

Effectively, the sub-ledger is copied to the General Ledger with a single journal entry.

What I'm struggling to understand is the purpose of the Sub-ledger and General Ledger from a database perspective. Couldn't the above three entries be recorded in the DB with only two normal journal entries? This would remove the duplication of data (the $800 recorded in the sub-ledger and the $800 also recorded in the general journal entry)?

General Journal Entries:
---------------------------------------------------------------
Date      Description           Acct        Debit      Credit
---------------------------------------------------------------
Jan 1     Cust. A Sale           AR         500.00
                                 Sales                 500.00

Jan 15    Cust. B Sale           AR         300.00
                                 Sales                 300.00

I understand that in a paper system, a sub-ledger makes a lot of sense as you can see the detail of the sales transactions throughout a period (a day/week/month, whatever the interval is). Then the general ledger shows the "big picture" of your sales, accounts receivable, etc.

But in a relational database model, it seems the second example where everything is recorded through journal entries, and there are no sub-ledgers, would be far more optimal. You still log every transaction and if you need to see the detail of a specific vendor or customer (the sub-ledgers), you can simply provide a filter list of the journal entries.

Does that make sense? Am I missing something with the above?

Garfonzo
  • 3,876
  • 6
  • 43
  • 78
  • Yes, you can have one General Ledger database table, as long as you identify the sub-ledger as a column in the table. That way, you can create sub-ledger displays and general ledger displays. Your database model doesn't matter as long as you can create all accounting reports or displays and your database model can be audited. – Gilbert Le Blanc Jul 20 '21 at 20:23
  • @GilbertLeBlanc Thanks for the response -- your response is in line with my thought process. And yes, I believe I can generate all the necessary sub-ledger style reports that are normally crafted as separate ledgers in the paper format. Simple queries to the database, filtering on various columns such as a specific account, client, vendor, etc, will provide a list of transactions (sub-ledger) for that object. – Garfonzo Jul 20 '21 at 20:55

2 Answers2

9

The difficulty is with your terminology.

Effectively, the sub-ledger is copied to the General Ledger with a single journal entry.

Ledger

  • The Ledger is the Ledger, and nothing but the Ledger. It does not contain detail, only Journal Entries.

Account Book

  • Your "sub-ledger" is an Account Book, not a Ledger. It contains details (eg. each receipt for groceries in the Grocery Account). It does not contain Journal Entries.

Journal Entry

  • One entry in the Ledger.

DayEnd/MonthEnd

  • At the end of each day/month, one might summarise the days/months Account entries (eg. daily for a Grocery; monthly for Sales), and make one Journal Entry in the Ledger with that summarised Amount

  • It is not "copied"

  • Full details for summarising are provided in Derived Account Balance vs Stored Account Balance.

Error

  • In a paper-based system, placing Account entries in the Ledger would be a gross bookkeeping error.

  • In a database, placing the two of them in one table (with a flag to indicate what it is) is a gross Normalisation error.

  • If you perceive the Account Book as a Ledger or "subledger", you will remain confused, and the database will be a nightmare.

Answer
If you would like a full Answer, including implementaiton details and Relational data models, refer to these, in sequence:

PerformanceDBA
  • 32,198
  • 10
  • 64
  • 90
-1

I'm building a General Ledger with a General Journal for digital bank and I'm finding that some the accounting terminally isn't actually very helpful for the specific design that we have in mind.

We are approaching the problem using domain driven development and thus we have separate domains for Account and Ledger.

I our case a Banking Product can have multiple accounts associated with it, with each account having a different asset class (fiat, crypto, etc). I'm leaning towards having two tables, one for the General Ledger and one for the General Journal.

When an account is created a General Ledger Entry is created for that account. The General Ledger is really just a mapping between accounts and General Journal Entries which provides various balance services to accounts (available balance, actual balance, trial balance, etc).

I'd be happy to discuss ideas others building a similar ledger.

hoos
  • 174
  • 2
  • 10