Scaling Ledger - Organization

[Russell Adams]

The first issue that arises is how to organize Ledger data. I rapidly
import many txns, and having a single Ledger file would quickly become
unmaintainable. The way I've organized my data is documented
below. Note that this is my personal organization, and it could likely
use some improvement.

I use Version Control on my Ledger data using Bazaar. I know many
others prefer Git, but any kind of version control provides important
features including:

- Change tracking
- Backup/Restore points
- Branching & Merging
- Test vs Prod
- (Potential) Multiuser Access

I VC all my Ledger files, the ledger binary, scanned receipts and all
configuration. My repo now totals nearly 2GB. Many of my scripts also
are integrated with VC, automatically adding files that are created,
or generating a balance statement on each commit.

Unlike a central database with views into the data, I've split out my
data into many files where it seemed to make sense to keep related
txns together. This helps simplify editing.

A high level view is that I use my .ledger file in the repo root to
import all other DAT files from multiple subdirectories when reporting
with Ledger, with approximately 100 files and growing. My files
revolve around my workflow, with "glue" scripts helping maintain
order.

I import data into a transitory queue file which I edit to assign
metadata, and then use scripts to relocate txns to their permanent
location. The queue is then cleared to remove txns that aren't yet
permanently stored, and the process repeats.

Because I'm importing with deduplication, removing txns that aren't
relevant to the task at hand does not cause data loss. They will be in
the queue again after the next bulk import.

An example of my typical workflow would be:

- Download latest CSV from bank, file into Archive
- Clear the Queue
- Import all CSVs to Queue
- Relies heavily on deduplication
- Edit queue and assign metadata to txns
- ER & Project & Category
- Verify current ER, editing as needed
- Business logic (ie: spending limits)
- Accurate file links
- Accurate metadata & accounts
- Uses several scripts to verify different items
- File finished txns to permanent storage
- Generate & email PDF
- Commit ER to VC

My repo includes:

- Repo root
- ledger binary
- Ensures that the compiled version is in the repo with the data
- .ledger
- Uses !include on every DAT file in every directory,
automatically generated from script
- Sets precision & mileage rates
- Queue.dat
- All txns are imported here via script, and once an ER# has been
assigned txns are "filed" to permanent DAT files in ER/
- CSV2Ledger Configuration Files
- Account matching and translation
- Txn transformations
- .MD5Sum.cache
- Used by CSV2Ledger to cache all md5's, updated by a separate script
- .env
- Provides shell functions for business logic reporting
- .startcommit
- Triggers automatic reports on commit
- Generates:
- ERStatus.txt
- Outstanding amounts on each ER
- LedgerBalance.txt
- ledger bal output
- Commits FAIL if ledger files are not valid and reports could
not run
- Projects.txt
- Human readable lookup table of project codes to customers
- Archive/
- Permanaent CSV data storage, downloaded from bank.
- Txns in files may overlap, importing must dedupe.
- Data/
- DAT files for "misc" txns with one file per year
- Opening balances in oldest file
- Often for manual txns
- ER/
- Permanent txn storage
- One DAT file for EACH expense report which includes most txns in
that report (ie: ER/AISER0123.dat)
- Some txns span multiple ER's, and are typically stored with the
first posting's ER.
- PDF/
- Finished PDF expense reports with receipt images
- Receipts/
- Each project code gets a subdirectory, storing jpeg images of
scanned receipts, one page per file
- 2,300 Receipts and growing.
- bin/
- Misc scripts, including:
- CSV2Ledger.pl
- More later on automation, but ensures I always have a working
production copy
- ClearQueue.sh
- Clears all txns with an md5sum from Queue.dat, recreates
md5sum cache
- ERStatus.sh
- Generate outstanding balance report by ER
- GenerateLatexExpeneseReport.pl
- Creates Latex expense reports from Ledger and compiles to PDF
- LoadAllCSV.sh
- Loads all archives CSV files, deduplication is built in.
- RefileER.sh
- Move txns for specified ER # from Queue.dat to permanent file
in ER/
- RegenMD5.sh
- Recreate md5sum cache, called by other scripts after changes
- RenameVisaCSV.sh
- Rename credit card CSV's from the bank for archival
- UnmatchedImages.sh
- Find receipt images NOT linked to a txn (ie: compare
filesystem to txns)
- VerifyImages.sh
- Check filenames in metadata against filesystem (ie: missing images)

Eyes crossed yet?

I had considered a database like SQL to minimize the number of files
involved, and enable a better workflow based on a view into specific
txns instead of static placement in diverse text files.

------------------------------------------------------------------
Russell Adams RLA...@AdamsInfoServ.com

PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/

Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3

[Bradley M. Kuhn]

I hope this rather long post is appropriate (especially as a first post
by a lurker) but I've seen similar posts of this nature in the archives,
so I am not too worried.

TL;DR:

I run for an non-profit org that depends heavily on Ledger, and I
want to work with the community on a project around Ledger to make a
"more complete non-profit accounting system" -- with Ledger as the
center, including perhaps some ERP-like features, that a "normal
accountant" could look at and recognize. If you want to help with
that or just talk about it, please read the full message.

Full Details:

First of all, many on this list know that I'm the Executive Director of
the Software Freedom Conservancy ( http://sfconservancy.org ), and at
least a few also know the basics of Conservancy's use of Ledger.

Conservancy is now facing growing pains with our use of Ledger (which,
BTW, is stuck on 2.6.2 for merely tuit reasons). Mainly, I don't have
many of the tools Conservancy needs alongside Ledger to really complete
what Conservancy needs to serve its projects.

Conservancy chose Ledger many years ago because it could do two key
things that no Free Software accounting tool could do: (a) it allowed
multiple, separate files for Conservancy's various member projects to
see their own finances (separately), and (b) Ledger's plain-text format
could be stored easily in version control. It's not an exaggeration to
say that Ledger 2.6.2 was *the key* piece of infrastructure that allowed
Conservancy to grow from our 5-10 member projects in 2007 to nearly
thirty now. Indeed, perhaps unbeknown to all of you, the Ledger
developers were a key part of what made Conservancy's growth possible,
and I give my wholehearted thanks to all of you for this amazing work!

For some time, though, Conservancy has had on hold new projects joining
(including Ledger *itself*, BTW, which applied some time ago and is
still waiting in the join queue :) simply because Conservancy didn't
have the bandwidth to accept more projects. Ledger allowed me to run
Conservancy as a single-person shop where I do all the accounting
myself. But Conservancy's accounting system now doesn't scale for two
key reasons:

0. Invoicing, accounts receivable, and receipt and reimbursement
tracking have become a time problem, due to volume. The Ledger
part of the picture is fast and easy, but these other things
"surround" Ledger and it means the bookkeeping is needlessly
time-consuming.

1. Our ability to hire a bookkeeper (which I hope to do within a
year of now so Conservancy can grow) is hampered because, right
now, any bookkeeper Conservancy might hire now *must* be able to
edit text files and use version control. (These skills are rarely
found in the bookkeeping profession.)

I'm aware there are multiple tools (such as hledger-web) floating around
our community that are the start of something to solve parts of (1).
Meanwhile, I've just this weekend caught up on nearly a year's worth of
traffic on this list, I found and read with interest Russell Adams'
posts from February 2012 about his system of scripts, which work through
some of the things in (0).

What Russell is doing is very similar to what Conservancy does (or, at
least, wants to do), although Russell now has a lot more automation and
more data kept in the Ledger file. Thus, one option for Conservancy is
to take Russell's scripts and start adapting them.

But, instead, I'd like to propose that the Ledger community think about
this problem and perhaps consider what we might do together to develop
more tools. I'm not in so much of a hurry to scale with a
quick-and-dirty solution. Instead, right along with Conservancy's own
mission to improve Free Software for our projects, I'd like to improve
the infrastructure around Ledger for everyone in the hopes that a
Ledger-based accounting system could be developed and used by
non-profits and for-profits alike.

There are tons of Free Software ERP and accounting applications. I
evaluated nearly every one that existed between 2005-2007 until finally
settling on Ledger, and none of them of that era could handle the simple
needs of a non-profit operation run by people who prefer to keep
documents in version control rather than databases. I doubt anything
else can.

Of course, I could slam all Conservancy's records out of Ledger into
SQL-Ledger or SMBLedger, hire a traditional bookkeeper, and be done with
it. But, that would throw away years of work that I've put into setting
up Conservancy around Ledger, and I also think a whole other host of
problems would come about.

So, I'm writing here instead to suggest coming up with a plan to take
things to the next step. Does anyone want to work together to tackle
this problem? Admittedly, the problem is rather ill-defined at the
moment, but the short version is: an accounting system that a non-profit
can use to manage its operations based on Ledger. Conservancy is going
to do this anyway, and I'd love to have help and make it as generalized
as possible.
--
-- bkuhn

[Russell Adams]

On Sun, May 13, 2012 at 02:16:18PM -0400, Bradley M. Kuhn wrote:

> Conservancy chose Ledger many years ago because it could do two key
> things that no Free Software accounting tool could do: (a) it
> allowed multiple, separate files for Conservancy's various member
> projects to see their own finances (separately), and (b) Ledger's
> plain-text format could be stored easily in version control.

Here! here! Well spoken Bruce!

> It's not an exaggeration to say that Ledger 2.6.2 was *the key*
> piece of infrastructure that allowed Conservancy to grow from our
> 5-10 member projects in 2007 to nearly thirty now. Indeed, perhaps
> unbeknown to all of you, the Ledger developers were a key part of
> what made Conservancy's growth possible, and I give my wholehearted
> thanks to all of you for this amazing work!

I'll include my thanks as well. John's put in many custom features for
me, and is thinking ahead. The other recent volunteers assisting with
patches and documentation are great too!

> But Conservancy's accounting system now doesn't scale for two
> key reasons:
>
> 0. Invoicing, accounts receivable, and receipt and reimbursement
> tracking have become a time problem, due to volume. The Ledger
> part of the picture is fast and easy, but these other things
> "surround" Ledger and it means the bookkeeping is needlessly
> time-consuming.

I feel your pain!

> 1. Our ability to hire a bookkeeper (which I hope to do within a
> year of now so Conservancy can grow) is hampered because, right
> now, any bookkeeper Conservancy might hire now *must* be able to
> edit text files and use version control. (These skills are rarely
> found in the bookkeeping profession.)

I tried this, and failed. I couldn't get an experienced bookkeeper to
understand Ledger, text files, and version control.

> I'm aware there are multiple tools (such as hledger-web) floating around
> our community that are the start of something to solve parts of (1).
> Meanwhile, I've just this weekend caught up on nearly a year's worth of
> traffic on this list, I found and read with interest Russell Adams'
> posts from February 2012 about his system of scripts, which work through
> some of the things in (0).

Ad-hoc, and cobbled. Applying logic from the outside using text really
isn't a good way to do it.

> What Russell is doing is very similar to what Conservancy does (or, at
> least, wants to do), although Russell now has a lot more automation and
> more data kept in the Ledger file. Thus, one option for Conservancy is
> to take Russell's scripts and start adapting them.

I'm open to sharing, but I'd suggest that my scripts are likely so
tightly integrated with my use case they may not be helpful. Perhaps
you can learn from them though.

> But, instead, I'd like to propose that the Ledger community think about
> this problem and perhaps consider what we might do together to develop
> more tools. I'm not in so much of a hurry to scale with a
> quick-and-dirty solution. Instead, right along with Conservancy's own
> mission to improve Free Software for our projects, I'd like to improve
> the infrastructure around Ledger for everyone in the hopes that a
> Ledger-based accounting system could be developed and used by
> non-profits and for-profits alike.

That's the reason I made so many long posts in Feb. I was hoping we
can make a real solution together, because at the moment everyone is
separately cobbling together one-off tools. Look at how many CSV
converters there are...

> There are tons of Free Software ERP and accounting applications. I
> evaluated nearly every one that existed between 2005-2007 until finally
> settling on Ledger, and none of them of that era could handle the simple
> needs of a non-profit operation run by people who prefer to keep
> documents in version control rather than databases. I doubt anything
> else can.

I was sold on version control and the flexibility. No other product
can do splits like I can with Ledger.

> Of course, I could slam all Conservancy's records out of Ledger into
> SQL-Ledger or SMBLedger, hire a traditional bookkeeper, and be done with
> it. But, that would throw away years of work that I've put into setting
> up Conservancy around Ledger, and I also think a whole other host of
> problems would come about.

I've strongly considered writing a python/sql expense reporting
application and be done with it. I just don't care for SQL, I prefer
text and version control.

John's added some recent support for Python interacting with the
Ledger data which I need to go back and look at more closely.

> So, I'm writing here instead to suggest coming up with a plan to
> take things to the next step. Does anyone want to work together to
> tackle this problem?

I'd love to help and see some progress. It's always daunting to be
trying to fix something, *again*, alone.

> Admittedly, the problem is rather ill-defined at the moment, but the
> short version is: an accounting system that a non-profit can use to
> manage its operations based on Ledger. Conservancy is going to do
> this anyway, and I'd love to have help and make it as generalized as
> possible.

So what I hear is: We need a way to build business logic on top of
Ledger. Would that be a fair summary of both of our issues?

[John Wiegley]

>>>>> Russell Adams <RLAdams-oD4XmFtju8vuCfmLQ01/GwC/G2K4...@public.gmane.org> writes:

> So what I hear is: We need a way to build business logic on top of
> Ledger. Would that be a fair summary of both of our issues?

Given what we have today, I think the path of last resistance to getting
something like this up and running would be to use the Python bridge to write
a GUI in either HTML5 or an app framework like WxWindows. The advantage to
HTML5 is that not only could it be accessed remotely, but it would be easy to
write mobile interfaces as well.

John

[Bradley M. Kuhn]

Russell Adams wrote at 10:39 (EDT):

> So what I hear is: We need a way to build business logic on top of
> Ledger. Would that be a fair summary of both of our issues?

I don't really need the business logic implemented in software. What I
need are software tools for other accounting-related tasks, like
invoicing, to work with version control underneath and be aware of
Ledger.

I think that's the first step.


BTW, one of the projects I evaluated and gave up on at the time that I
selected Ledger was TinyERP, renamed OpenERP, and now has a
non-Open-Core fork active called Tryton:
http://www.tryton.org/index.html.

We *might* consider making a Ledger backend for this, but that might be
overkill than rather home-growing. The upside is we might get a lot of
people interested in Ledger suddenly who weren't before.
--
-- bkuhn

[Russell Adams]

On Mon, May 14, 2012 at 02:53:20PM -0400, Bradley M. Kuhn wrote:
> Russell Adams wrote at 10:39 (EDT):
>
> > So what I hear is: We need a way to build business logic on top of
> > Ledger. Would that be a fair summary of both of our issues?
>
> I don't really need the business logic implemented in software. What I
> need are software tools for other accounting-related tasks, like
> invoicing, to work with version control underneath and be aware of
> Ledger.
>
> I think that's the first step.

Isn't that "business logic"? A system which converts hours to dollars,
creates a document which aggregates hours/dollars into an invoice,
tracks whether or not that invoice was paid... etc. That is all
business logic, which ties into the accounts that Ledger maintains.

I think we're basically on the same page though.

[Russell Adams]

I'm all for it! What's the chance of using Python3?

[Zack Williams]

On Mon, May 14, 2012 at 1:45 PM, John Wiegley <jwie...@gmail.com> wrote:
> Given what we have today, I think the path of last resistance to getting
> something like this up and running would be to use the Python bridge to write
> a GUI in either HTML5 or an app framework like WxWindows.  The advantage to
> HTML5 is that not only could it be accessed remotely, but it would be easy to
> write mobile interfaces as well.

Agreed.

I'm assuming you can add/remove data into an already parsed ledger
document via the python interface, and run multiple queries on it
without having to reparse?

- Zack

[Zack Williams]

On Mon, May 14, 2012 at 11:53 AM, Bradley M. Kuhn <bk...@ebb.org> wrote:
> Russell Adams wrote at 10:39 (EDT):
>
>> So what I hear is: We need a way to build business logic on top of
>> Ledger. Would that be a fair summary of both of our issues?
>
> I don't really need the business logic implemented in software.  What I
> need are software tools for other accounting-related tasks, like
> invoicing, to work with version control underneath and be aware of
> Ledger.
>
> I think that's the first step.

Invoicing isn't an accounting task - it's a document generation task.

My solution to the above problem was a few rake scripts, some PDF
generation code for invoices, and a preprocessor that takes my own
tag-augmented version of markdown and does things like time math for
counting hours, etc. . My output formats are ledger files, PDF
invoices, and various other reports. Everything is text kept in
version control.

I haven't posted my workflow tools yet as they're extremely rough
around the edges, but I intend to when I get it cleaned up.

- Zack

[Andrew Potter]

> On Mon, May 14, 2012 at 02:45:30PM -0600, John Wiegley wrote:
>> Given what we have today, I think the path of last resistance to getting
>> something like this up and running would be to use the Python bridge to write
>> a GUI in either HTML5 or an app framework like WxWindows.  The advantage to
>> HTML5 is that not only could it be accessed remotely, but it would be easy to
>> write mobile interfaces as well.

While I'm all for ending up there, it seems to me like we still have
an opportunity to build a suite of discrete tools:
e.g.:
o ledger-invoice: spits out invoices based on the queried account or
tag or txn(s)
o ledger-bookkeep: Merges a set of new txns into a central ledger
file, makes sure ledger parses it okay, saves it, and checks it into
version control. (This would be the only program that would actually
modify a ledger file)
o various scripts running complex queries on ledger for the
receipt/reimbursables tracking, etc.

I'd love to help develop this, but I don't actually run a business
myself so I don't know whats needed for accounts receivable, etc.. but
I feel like if we first build a set of tools that automate each
different process Bradley has to do, we can abstract them afterwards
for the real gui application that less technically adept people could
use, while still preserving the ability for power users to go in and
work by hand.

[Alexandre Rademaker]

On 14/05/2012, at 19:27, Zack Williams <zdw...@gmail.com> wrote:
> Invoicing isn't an accounting task - it's a document generation task.
>
> My solution to the above problem was a few rake scripts, some PDF
> generation code for invoices, and a preprocessor that takes my own
> tag-augmented version of markdown and does things like time math for
> counting hours, etc. . My output formats are ledger files, PDF
> invoices, and various other reports. Everything is text kept in
> version control.
>
> I haven't posted my workflow tools yet as they're extremely rough
> around the edges, but I intend to when I get it cleaned up.
>
> - Zack

Please Zack, your scripts would be very useful as they are right now. Please consider put them in a public repo if it is possible...

Alexandre

[nx]

Here is a discussion on a method for generating PDF invoices from
ledger: https://groups.google.com/forum/?fromgroups#!topic/ledger-cli/uvYxLRJLHws

I've got a similar need. I want to be able to make transactions and
use metadata to label them as invoices with each transaction posting a
line on the invoice and possibly metadata for each posting with a
human-readable description, then come up with some kind of toolchain
using LaTeX to generate PDF invoices for me.

I'm not sure currently how I could get the line item description out of ledger.

Since I haven't worked on this I've just rolled an interim solution using:
- an invoice template written in LaTeX
- little invoice text files named by invoice id containing the
customer name and line items
- an awk script that parses the invoice text files
- an awk script that parses the customers.txt file database
- a inv2pdf shell script that takes an invoice id and outputs the invoice pdf

Like I said the caveat is that my invoice line item info is separate
from my ledger file, so I have to add the invoice in two places.

[John Wiegley]

>>>>> Russell Adams <RLAdams-oD4XmFtju8vuCfmLQ01/GwC/G2K4...@public.gmane.org> writes:

> I'm all for it! What's the chance of using Python3?

If it gets you involved, I can add support for that. :) But it all depends on
what Boost.Python supports.

John

[John Wiegley]

>>>>> Zack Williams <zdwzdw-Re5JQEe...@public.gmane.org> writes:

> I'm assuming you can add/remove data into an already parsed ledger document
> via the python interface, and run multiple queries on it without having to
> reparse?

Yep.

John

[Russell Adams]

On Mon, May 14, 2012 at 03:23:37PM -0700, Zack Williams wrote:
> I'm assuming you can add/remove data into an already parsed ledger
> document via the python interface, and run multiple queries on it
> without having to reparse?

The REPL now can do multiple reports without reparsing.

The option to add & remove data violates the initial precept of
Ledger, which is it doesn't edit your files... How to handle that?

[Russell Adams]

On Mon, May 14, 2012 at 03:27:36PM -0700, Zack Williams wrote:
> On Mon, May 14, 2012 at 11:53 AM, Bradley M. Kuhn <bk...@ebb.org> wrote:
> > Russell Adams wrote at 10:39 (EDT):
> >
> >> So what I hear is: We need a way to build business logic on top of
> >> Ledger. Would that be a fair summary of both of our issues?
> >

> > I don't really need the business logic implemented in software. ?What I

> > need are software tools for other accounting-related tasks, like
> > invoicing, to work with version control underneath and be aware of
> > Ledger.
> >
> > I think that's the first step.
>
> Invoicing isn't an accounting task - it's a document generation task.

It's a document generation task that also requires a database to track
and manage documents, that directly affects the accounts in
Ledger. The accounting and business logic are directly inter-related.

Storing Ledger data is nice, how do you intend to store the data about
the invoices? Just a practical consideration.

I could post an example of how I generate PDF's from Ledger now.

[Zack Williams]

On Mon, May 14, 2012 at 7:04 PM, Alexandre Rademaker
<arade...@gmail.com> wrote:
> Please Zack, your scripts would be very useful as they are right now. Please consider put them in a public repo if it is possible...

You REALLY don't want them right now... they currently go through a
very badly written XML phase (one of the first attempts at XML/XSLT
that I ever did, which has things like unix timestamps as dates
instead of ISO8601), and all the PDF generation code is in command
line PHP with a hacked up old version of TCPDF (I originally was going
to do a web interface, so PHP wasn't that bad of a choice).

I'll probably redo the XML then use a more modern PDF generation
engine, but it's frankly too embarrassing and full of business
specific kludges to release now.

- Zack

[Zack Williams]

On Tue, May 15, 2012 at 6:44 AM, Bradley M. Kuhn <bk...@ebb.org> wrote:
> I said "accounting-related" in my original email; it's related to
> accounting.  Basically, I'm looking for the toolset that I could handle
> a non-technically-sophisticated bookkeeper and tell him/her to do the
> job, and I could check everything myself by looking in the version
> control repository and see what was done.

Ah... well, my take on that is make scripts to reduce the amount of
work done by a bookkeeper.

One example - I have a OCR/regex contraption that auto-categorizes
receipts ala commercial prodducts like NeatReceipts with minimal human
intervention, and spits out XML (and soon, ledger).

>> It's a document generation task that also requires a database to track
>> and manage documents, that directly affects the accounts in
>> Ledger.

I'm thinking that could be handled with ledger's metadata.
Fundamentally you need a superset of data per document that includes
things that aren't pertinent to Ledger.

>> Storing Ledger data is nice, how do you intend to store the data about
>> the invoices? Just a practical consideration.

In text. In files that contain things like "work performed", lists of
items sold (I'm toying with ideas of a CLI driven inventory system),
and similar that are a superset of my ledger data. I just generate
ledger from those, and use it to balance the accounts, but ledger
isn't the center of the world in my use case.

If you want an idea of what my workflow looks like, I did a version
control specific presentation at the MacTech Conference last year, in
which I show using git, ledger, and the rest of my toolset - the .mov
is probably the most interesting bit to this list:

https://github.com/zdw/mtc2011

- Zack

[Zack Williams]

On Mon, May 14, 2012 at 9:12 PM, Russell Adams
<RLA...@adamsinfoserv.com> wrote:
> On Mon, May 14, 2012 at 03:23:37PM -0700, Zack Williams wrote:
>> I'm assuming you can add/remove data into an already parsed ledger
>> document via the python interface, and run multiple queries on it
>> without having to reparse?
>
> The REPL now can do multiple reports without reparsing.
>
> The option to add & remove data violates the initial precept of
> Ledger, which is it doesn't edit your files... How to handle that?

The external code would have to handle that as well, or you could do a
"ledger print" which would dump most of the internal state.

- Zack

[Russell Adams]

Not to derail the threads or pump my ego, but I'd suggest everyone
review the 'Scaling Ledger - *' threads from Feb where I covered quite
a few of these issues. Perhaps they are a good base to start from for
discussion and features.

Thanks.

[John Wiegley]

>>>>> John Wiegley <jwiegley-Re5JQE...@public.gmane.org> writes:

> Given what we have today, I think the path of last resistance to getting
> something like this up and running would be to use the Python bridge to
> write a GUI in either HTML5 or an app framework like WxWindows. The
> advantage to HTML5 is that not only could it be accessed remotely, but it
> would be easy to write mobile interfaces as well.

I've added a "json" report to Ledger. I also have a local branch which
includes an HTTP server based on Boost.Asio. This way we can write an HTML5
Ledger UI entirely in Javascript, using REST to query/update the Ledger data.

John