General Journal

[Buddha Buck]

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").