reproducible, & possibly configurable rounding

Chris Travers chris.travers at gmail.com
Thu May 8 19:44:59 EDT 2014


On Wed, May 7, 2014 at 4:01 PM, Bradley M. Kuhn <bkuhn at ebb.org> wrote:

> [ 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


With due respect, documented rounding methods are important as they avoid
misunderstandings, as are questions of how you allocate extra pennies to
earmarks.  But whatever method is used for rounding (round away from 0 or
round to even), it needs to be documented.

The real problem IMHO (and this comes up on the LSMB list) is that there
are places where number rounding makes sense, where you want to store more
precise values than the currency would suggest, and cases where discrete
math makes more sense.

For example, you might want to do discrete math  when dealing with sales
taxes (probably not so much an issue for most NPO's but it can be), but you
may want to do greater precision for handling depreciation of assets (so
that extra cents are distributed across the whole set of assets and over
time).

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

Test cases for number rounding is one of the things we added early on to
LSMB for this reason.

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

IME, number rounding in accounting systems usually follows round away from
0 (the kind we are taught in math), but sometimes round to even is done by
some systems.  The key is to test and document so everyone knows what to
expect.  Predictable behavior won't appear predictable if folks expect
different behavior which sometimes matches the observed behavior.

Hope this helps,
Chris Travers

> --
> Bradley M. Kuhn, President, Software Freedom Conservancy
> _______________________________________________
> npo-accounting mailing list <npo-accounting at sfconservancy.org>
> List URL: http://lists.sfconservancy.org/mailman/listinfo/npo-accounting
> Wiki URL: http://npoacct.sfconservancy.org/




-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20140508/0e1f59f8/attachment-0001.html>


More information about the npo-accounting mailing list