reproducible, & possibly configurable rounding

[Bradley M. Kuhn]

[ Crossposted to ledger-cli and npo-accounting mailing list.  Feel free
  to crosspost your replies or not as you feel appropriate.  I'll try to
  keep the discussion in sync if some folks don't crosspost. ]

As many of you know, I'm mentoring this summer a GSoC student (Tripun
Goel) who is investigating issues of precision in Ledger-CLI (see my
other post about the NPO Accounting project and its overlap with
Ledger-CLI, and Tripun's post today).

Tripun is first investigating various problems that Conservancy has had
using Ledger-CLI for currency conversion, and generally is going to
investigate how to create clearly defined rules that we can show to an
accountant about how rounding is handled in Ledger-CLI, and possibly
propose patches that make the rounding behavior more configurable and
documented in Ledger-CLI.


Tripun's initial research has shown that there appears to be no
specifically recommended accounting methodology for storing numbers and
handling rounding.  I somewhat expected there would be accounting
guidelines on this point, but it seems that most accountants haven't
thought deeply about the question (which I suppose is not surprising).
In fact, accountants likely figure that any given transaction is only
going to be off a penny or two, which isn't consider "material":
http://en.wikipedia.org/wiki/Materiality_%28auditing%29

My argument is that if rounding is buggy, single penny errors in each
transaction can add up to "real money" (cf: the plots of the films
Superman 3 and Office Space).  Therefore, the important thing is to
verify that whatever mechanism are used for rounding and that mechanism
is reproducible with other systems, including by hand with pen and
paper, if an auditor wants to verify a transaction is correct.

Indeed, accountants prefer predictable behavior from accounting systems
that are documented officially as part of the fiscal policies.
Currently, there are various types of transaction I'm doing with
Ledger-CLI that are unpredictable with regard to rounding (of course,
johnw can always explain it to me -- but he's not always going to be
available to talk to everyone's auditors ;).

I originally characterized Tripun's project as a "implement fixed point
arithmetic"; which I naïvely thought was the "only way to handle the
rounding problem properly".  I've since been educated: there is more
than one way to get this done right, and I think the way we're leaning
is to clearly document options, why we picked the option we did, and
(ideally) make Ledger-CLI more configurable on this point by the user.

That's the plan from my point of view, anyway.  Tripun keeps teaching me
new things, so I may change based on what he discovers next. :)  Tripun
and I will keep the lists informed on our progress.
-- 
Bradley M. Kuhn, President, Software Freedom Conservancy