About LedgLive

LedgLive is open-source software. Binaries are also provided.

A clear meaning of the use of the terms journal and ledger for this project is provided.

The terms journal entry and ledger entry are given a formal meaning in LedgLive that is best explained through origins story below.

Why LedgLive as ‘live ledger’ or ‘extensible journal to ledger’?#

From an example below it can be appreciated that for traditional paper based systems that the terms ‘journal’, ‘ledger’ and ‘posting to ledger’ had specific workflow meanings and purposes. It was this workflow that defined the meanings of the terms.

Workflows are different now. For online systems the distinction between the terms becomes blurred, and as shown below, the terms can be dropped altogether as they don’t really have a useful workflow purpose and lack legal definition. They have an educational use.

LedgLive offers a way for very small entities and individuals to determine instant impacts on cash flow.

LedgLive’s flexibility and openness is powerful. Do you need instant reporting? LedgLive is wide open to this. The server API can be easily extended. You can even host additional clients on the server in binary versions. LedgLive also has a CLI client built as example for reporting.

Do you need extensions such as workflow approval purposes? LedgLive gives you a useful base for this.

So the ledger part in ledglive indicates ledglive is for recording and reporting.

The live part indicates ledglive is open and primed for report generation and for building extensions.

Origins Of LedgLive Software#

LedgLive software has its origins in the rules and regulations of the Australian Taxation Office (ATO)

Their rules can be summarised in two words: keep records.

Their rules mention records, depreciation, assets, GST, private proportions, profit, loss, claimable, not-claimable. GST is equivalent to VAT or consumption tax elsewhere.

The developer does not recall words like, ledger, journal, profit and loss statement, balance sheet.

The developer wrote software from the ground up using the simplest possible database table definitions they could find.

The developer found they could keep records with just three main simple tables called accounts, transactions and transactionitems. The names did not matter, they are just labels but are self explanatory to an extent. There are some additional peripheral tables which are not important to the story.

The transactionitems table is at the core. It is linked by relationally to two other tables, the transactions table and the accounts table.

Each transactionsitem table entry must link to an entry in the accounts table and must also link to an entry in the transactions table. The transactionitems table also records a positive value in a debit or credit column. More information below on debit and credit in ledglive.

There was one very simple rule to be enforced. For all transactionitems table with this same related transaction id, the sum of the debits must equal the sum of the credits, also known as double balanced.

With these three very simple tables and one very simple rule, the developer found they could generate Profit and Loss statements and Balance Sheets, use a chart of accounts (using an additional peripheral table) and make automatic equity/retained earnings adjustments after applying depreciation. Asset depreciation calculation is another story. LedgLive is not for this.

So basically they had a modern and functioning accounts keeping system without the words journal or ledger appearing anywhere.

But now the developer is working on open-sourcing the software and so there is as an expectation of use of words like journal and ledger.

The solution for the developer was very simple. They simply renamed the transactionitems table to be the journal table, renamed the transactions table the ledger table and renamed the accounts table the account table (just to be consistent with using singular names).

Is this justified?

It is justified in the sense that the tables can be made to function, at a higher level, like any description the developer says they ever tried to understand of what a journal and ledger is.

Definitions#

So in LedgLive, for those who like formal definitions, the developer provides the following definitions:

Journal Entry#

A journal entry is a record of acquisition, disposal or movement within an entity of something that has an account id and has a financial value

Ledger Entry#

A ledger entry is a way of providing a Foreign Key for journal entries to ensure that journal entries are double balanced.

Foreign Key#

The formal definition of ‘Foreign Key’ is, admittedly, not helpful in this context.

A foreign key provides a means of extracting, grouping or isolating information in a table for a particular purpose. There are parallels with a traditional ledger book system.

With LedgLive, a relevant foreign key for the journal table is the ID of a ledger table entry. All journal entries with the same ledger table entry ID must be double balanced, just as all entries on a ledger page or in a ledger book must be double balanced. In this case the ledger pages or books extracts or groups information from journals that must be double balanced and the equivalent of the foreign key is the ledger page number or ledger book name.

It might seem more obvious to use a term like ‘relational ID’, instead of ‘foreign key’ however the term ‘relation’ already has a specific meaning for SQL, even though it is not used in practice. In SQL database language terms, a relation represents a table, but no one calls a table a relation.

What these definitions mean in practice#

With these definitions, the developer does not need to add general ledger, sales ledger, chart of accounts, golden rules etc. to these definitions. That is higher level functionality that can be imposed arbitrarily. An example is provided next.

Example of use of a traditional Purchase Journal system#

Suppose you operate with using a traditional specialised journal system and you get handed a paper copy of the days purchase journal with four purchases on credit from different suppliers, having received approved invoices and using accrual accounting.

On a traditional papers based manual ledger system this would mean posting the journal entries to five different accounts: four accounts payable liability accounts (one for each supplier) and one with the total for the day to a sundry purchases expense account.

An equivalent with LedgLive#

This is not a recommendation to follow any particular process. Instead this is an illustration of how LedgLive can parallel traditional paper based journal/ledger processes

With LedgLive you can do the same as above. Create a new ledger entry for the day, add four lines of journal credit entries for each accounts payable liability account of the suppliers, note how much LedgLive says the ledger entry is imbalanced by, and debit a general purchases expense account account equal to the imbalanced total. Five lines in total, same as before.

In fact you can go even further, just bypass the paper purchase journal altogether and record the credit purchases directly in LedgLive. At some time you can choose to debit the imbalanced amount with a single entry. However it so quick with LedgLive to add in a balancing credit or debit that you might choose to just balance straight away and add in four balanced LedgLive ledger entries with two journal lines each instead.

Further refinements#

Traditional workflow#

If you like you can use LedgLive in a traditional journal to ledger workflow manner very easily to start a workflow process. To set up a journal only just create a ledger entry and leave credit amounts as zero with future estimated credit amount in comments. You can create a dummy account and enter zero amounts to to keep track of your journals. You can post the journal entries to the ledger one by one as approved by posting invoice amounts and see what remains and add in new entries or start new ledger entries with new journal entries or easily transfer journal entries to different accounts for the same ledger entry. You can extend ledglive to make this more sophisticated.

Simplifying interface#

A possible but unlikely further over-simplistic refinement is to add in user interface code that disguises the double entry system and only exposes approved creditors to an employee charged with making credit purchases. Each entry the employee makes automatically credits the creditors account and debits the sundry purchases expense account.

Including invoice breakdown#

Another refinement is to include in LedgLive a breakdown of the invoice details. For example suppose one invoice was for items A, items B and for shipping. Then instead of debiting a general purchases expense account, debit separate purchase expense accounts for A, B and shipping.

Conclusion#

When moving away from traditional manual paper based journal/ledger based systems, recording tends to become more sophisticated.

Debit and Credit in LedgLive#

The convention of keeping a debit column on the left, a credit column on the right, and not displaying negative values for the user interface is retained.

There was no need to keep to this convention in the database itself. Instead it makes sense to just use a single column with negative values mapping to the credit column and positive values to the debit column. However the convention has been retained at the database table for reasons below.

Using the raw database and coding reports#

It is common to access database tables without a regular user interface, to generate ad-hoc reports and view results. For this it helps to retain separate debit and credit columns.

Also is is less confusing when coding reports, although it does make coding slightly more complicated.

Allowing both a debit and credit entry on the same line, such as a discount#

By having separate debit and credit columns in the database, there is sufficient flexibility to enter both a debit and a credit on a single journal entry line instead of in two journal entry lines.

This would allow a discount or a refund or to represented, according to whatever higher order conventions are practised, expected and allowed.