General Journal

[cgw993 at aol.com]

Having the journal be the point of entry into the bookkeeping system is in fact a fundamental function of double entry accounting.  I thought the rest of your bookkeeping examples were great.

 

I agree that "importing" isnt as that was not around when bookkeeping fundamentals were developed.

 

  I am sorry some people thought this was a flame war, I did not realize that and I do not want to fill up mailboxes with junk so I will back out.   I look forward to seeing questions from other people regarding other parts of the software.  Thanks for everyone's input.  

 

From: Buddha Buck [mailto:blaisepascal at gmail.com] 
Sent: Thursday, August 08, 2013 2:41 PM
To: cgw993
Cc: Ian Konen; GnuCash Users List
Subject: Re: General Journal

 

I'll state this clearly:

 

Importing data from the books and accounts of other organizations is not a fundamental function of double-entry accounting.  It never has been.  Anything that Quicken, Peachtree, GC, or any other accounting package does to facilitate data entry by doing such importing is going beyond the necessary fundamental properties of double-entry accounting.  Double-entry accounting is concerned with tracking the monetary transactions of your own organization, not others.  Bank account statements, etc, are fundamentally the records of other organizations books, not your own.  It is reasonable, and desirable, for your understanding of the status of those accounts to match those of the banks, but fundamentally, your "bank account" account in the your books is a different thing than the "cgw993 account" in your bank's books.  That is why periodic reconciliation between the two sets of books is important, but reconciliation isn't the same as importing a set of transactions.

 

I have never used the bank statement import functionality of any DE-accounting system I have ever used, because it is not the bank's responsibility to keep track of my transactions.  By using such am import functionality, I lose control over being able to verify that the bank is actually doing the right thing.  Of course my records would match the banks; I would not be independently verifying that they were correct.  

 

To get into some technical detail here, since you seem to be hung up on the idea of a separate General Journal from the ledgers, let's talk database structure.

 

A General Journal entry looks like the following (note: I'm explicitly saying "debit" and "credit" rather than using left/right columnar formatting because formatting doesn't tend to survive well in email):

 

2013-08-08 Paycheck for W/E 8-02

    Assets:Checking DEBIT $500

    Expenses:Taxes DEBIT $200

    Income:Salary CREDIT $700

 

The transaction has a date, a description, and a bunch of lines, one for each affected account.  Each line lists the account, whether it's debit or credit (traditionally written in separate columns, explicitly spelled out here because of formatting issues), and the amount debited or credited.  The fundamental accounting formula insists that for each transaction, the sum of debits = the sum of credits.  Here, it does ($500+$200debit = $700credit)

 

In manual accounting, this would later be transcribed into three ledgers:

 

Assets:Checking

2013-08-08 Paycheck for W/E 8-02 DEBIT $500

 

Expenses:Taxes

2013-08-08 Paycheck for W/E 8-02 DEBIT $200

 

Income:Salary

2013-08-08 Paycheck for W/E 8-02 CREDIT $700

 

How would this be handled in a computer application backed by a database?

 

First off, the General Journal entry has a problem:  Databases which follow the Relational Database Model (which is virtually all in common use, as the model has been the dominant database paradigm since the 1970s) can only have one "row" per record, and each record has to be a fixed length.  Having some General Journal entries with two accounts and others with three (and others with potentially hundreds) can't be accommodated with a single database table.  So you are going to need two tables (the "primary key" notation means that the database can enforce that all the primary key fields in a table are unique; the "keyed to ...." notation means that the database can enforce that the value in that field matches the value in the primary key of the target table)

 

GeneralJournalEntries

    EntryId (primary key)

    EntryDate

    EntryDescription

 

GeneralJournalLines

    EntryId (keyed to GeneralJournalEntries)

    AccountId (keyed to Accounts)

    Debit

    Credit

 

This also suggests a third table:

 

Accounts

    AccountId (primary key)

    AccountDescription

 

In this structure, the General Journal Entry above would be stored in the database as:

 

Accounts

Assets:Checking | My Checking Account at BoA

Expenses:Taxes | Total withheld/pre-paid income taxes

Income:Salary | My salary from EmployerCo

 

GeneralJournalEntries

1 | 2013-08-08 | Paycheck for W/E 8/2

 

GeneralJournalLines

1 | Assets:Checking | 500 | 0

1 | Expenses:Taxes | 200 | 0

1 | Income:Salary | 0 | 700

 

Databases are designed to make reporting easy, so it's in fact very simple to write a report that takes data in the above set of tables and generates a copy of the General Journal in the format you expect.

 

The ledgers, in traditional accounting, are simple.  We have a separate book for each account, and each entry in the ledger has transaction identifying information (date, description, etc), and debit and credit amounts.  Duplicating this information in database tables seems easy:

 

AssetsCheckingLedger

    Date

    Description

    Debit

    Credit

 

ExpensesTaxesLedger

    Date

    Description

    Debit

    Credit

 

IncomeSalaryLedger

    Date

    Description

    Debit

    Credit

 

There are a couple of problems, though.  First off, in this schema, you need a table for every account, which makes it difficult to add new accounts.  Doing a Trial Balance (finding the sum of debits and credits across all ledgers to find any data entry errors) is very difficult, since finding all the ledger tables is hard to do.  Since the data structure in all the ledgers is exactly the same, with the only difference being what account it is associated with, we can get away with using one table for all ledger entries by simply adding an account column to the ledger table:

 

Ledgers

  AccountId (keyed to Accounts)

  Date

  Description

  Debit

  Credit

 

It's easy to get a report detailing the ledger for any given account; databases are designed to allow you filter and format data, so filtering the data for a specific account is easy, or group the data by account so you output all the ledgers at once.  A trial balance is as easy as summing all the debits and credits in the table and making sure they match.  Getting the balance for a single account is essentially doing the same computation for a trial balance, but filtering it to a single account.  So this easily functions just like separate ledgers.

 

The next problem is that there is no linkage between ledger entries and the journal entries.  It's hard to tell if a particular journal entry has been properly posted, as there's no easy way to go from ledger entry to the journal entry it came from.  We can fix this by adding an EntryId field.

 

Ledgers

  EntryId (keyed to GeneralJournalEntries)

  AccountId (keyed to Accounts)

  Date

  Description

  Debit

  Credit.

 

At this point, it should be clear that the date and description of a Ledger entry is simply copied from the corresponding General Journal entry.  Database designers rarely like duplicate data, especially when having the data accidentally drift is a major problem.  It's easy enough (using a "join") to pull the date and description data from the linked GeneralJounralEntries table, so those two fields can go away.

 

Ledgers

  EntryId (keyed to GeneralJournalEntries)

  AccountId (keyed to Accounts)

  Debit

  Credit

 

The basic accounting practices are:

* Entering transactions into the General Journal -- under the condition that within a single transaction the sum of debits equals the sum of credits.

* Once all transactions are in the General Journal, "post" them to the ledgers by copying data from the journals to the ledgers.

* Extract information from the ledgers to help guide business practice.

 

The first is simple enough.  Data entry UI can take many forms.  Additional support for adding/editing accounts is necessary, but not that hard.  For convenience, just like paper journals, there may be a desire to have multiple ways of entering transactions -- different specialized forms, different layouts, etc.

 

The second is also simple enough.  But implementing it reveals something: The GeneralJournalLines table and the Ledgers table have exactly the same structure, and holds exactly the same information.  The second accounting practice consists of copying data from one table to another identical table.  This is generally considered bad practice.

 

Why was this done in traditional accounting?  Because it is difficult to look at data in books in more than one way.  The General Journal provides a time-ordered view of transactions (which are cross-account events).  The ledgers provide a view of what is happening with a specific account.  You can't group the lines in the Journal that affect the Expenses:Taxes account because they are fixed to the page.  But you can do that easily with a database table.

 

So we can drop either the GeneralJournalLines table or the Ledgers table.  They are two names for the same data.  Personally, I prefer dropping the GeneralJournalLines table, giving just Accounts, GeneralJournalEntries, and Ledgers tables.  

 

But doing so has a side-effect:  Adding transactions to the General Journal simultaneously posts those transactions to the ledgers.  There no longer are separate "put the transaction in the Journal" and "post the Journal to the ledgers" operations.  There's just "Add a transaction", and all the reports, all the computations, work just as expected as if both steps had happened separately.

 

Posting traditionally happened at the end of the day (or at some other time when business wasn't being otherwise conducted) because while it is relatively easy to record transaction details in the Journal while they are happening (especially with special journals designed to simplify things), juggling the multiple ledgers necessary to post the transactions was a lot more time and space consuming, and would interrupt normal business.  That is not a problem with computer systems, as they specialize in data manipulation, etc.  So posting simultaneous with journaling is not a problem these days -- and with the accounts/journal/ledger three table structure, trivial.

 

No accounting package follows this approach exactly -- there's a lot of ancillary data associated with each table that I left out -- but the general approach is common.  GnuCash doesn't use relational databases, but still maintains the equivalent data structures (GeneralJournalEntries are called "transactions", GeneralJournalLines are called "splits").