<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 4:01 PM, Bradley M. Kuhn <span dir="ltr"><<a href="mailto:bkuhn@ebb.org" target="_blank">bkuhn@ebb.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[ Crossposted to ledger-cli and npo-accounting mailing list.  Feel free<br>

  to crosspost your replies or not as you feel appropriate.  I'll try to<br>
  keep the discussion in sync if some folks don't crosspost. ]<br>
<br>
As many of you know, I'm mentoring this summer a GSoC student (Tripun<br>
Goel) who is investigating issues of precision in Ledger-CLI (see my<br>
other post about the NPO Accounting project and its overlap with<br>
Ledger-CLI, and Tripun's post today).<br>
<br>
Tripun is first investigating various problems that Conservancy has had<br>
using Ledger-CLI for currency conversion, and generally is going to<br>
investigate how to create clearly defined rules that we can show to an<br>
accountant about how rounding is handled in Ledger-CLI, and possibly<br>
propose patches that make the rounding behavior more configurable and<br>
documented in Ledger-CLI.<br>
<br>
<br>
Tripun's initial research has shown that there appears to be no<br>
specifically recommended accounting methodology for storing numbers and<br>
handling rounding.  I somewhat expected there would be accounting<br>
guidelines on this point, but it seems that most accountants haven't<br>
thought deeply about the question (which I suppose is not surprising).<br>
In fact, accountants likely figure that any given transaction is only<br>
going to be off a penny or two, which isn't consider "material":<br>
<a href="http://en.wikipedia.org/wiki/Materiality_%28auditing%29" target="_blank">http://en.wikipedia.org/wiki/Materiality_%28auditing%29</a></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.  </div>
<div><br></div><div>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).</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
My argument is that if rounding is buggy, single penny errors in each<br>
transaction can add up to "real money" (cf: the plots of the films<br>
Superman 3 and Office Space).  Therefore, the important thing is to<br>
verify that whatever mechanism are used for rounding and that mechanism<br>
is reproducible with other systems, including by hand with pen and<br>
paper, if an auditor wants to verify a transaction is correct.<br></blockquote><div><br></div><div>Test cases for number rounding is one of the things we added early on to LSMB for this reason. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Indeed, accountants prefer predictable behavior from accounting systems<br>
that are documented officially as part of the fiscal policies.<br>
Currently, there are various types of transaction I'm doing with<br>
Ledger-CLI that are unpredictable with regard to rounding (of course,<br>
johnw can always explain it to me -- but he's not always going to be<br>
available to talk to everyone's auditors ;).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Hope this helps,</div><div>Chris Travers</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span class=""><font color="#888888">--<br>
Bradley M. Kuhn, President, Software Freedom Conservancy<br>
_______________________________________________<br>
npo-accounting mailing list <<a href="mailto:npo-accounting@sfconservancy.org">npo-accounting@sfconservancy.org</a>><br>
List URL: <a href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting" target="_blank">http://lists.sfconservancy.org/mailman/listinfo/npo-accounting</a><br>
Wiki URL: <a href="http://npoacct.sfconservancy.org/" target="_blank">http://npoacct.sfconservancy.org/</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Wishes,<div>Chris Travers</div>
<div><br></div><div>Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.</div><div><a href="http://www.efficito.com/learn_more" target="_blank">http://www.efficito.com/learn_more</a></div></div>

</div></div>