Rounding money in financial application

Question

I am composing some core types for an application which will deal with money. A simple money class may look like this:

public class Money 
{
    private decimal RawAmount { get; set; }
    public Currency Currency { get; set; }
    public decimal Amount
    {
        get
        {
            return Math.Round(RawAmount, 2);
        }
        set
        {
            RawAmount = value;
        }
    }
}

Initially I thought this seemed like a good idea, until I have to compose more complex values based on several Money.Amounts.

The issue is obviously that the amount of each Money instance will be rounded and could therefore trim the odd value off.

So my question is this, what is the recommended way to work with money where you expect a rounded output?

Specifically I'm wondering:

1. Is there a way to avoid needing to round all my values in the UI they are displayed it, could I do it better via some formatter class perhaps?

2. If I'm working with complex calculations, what's the best way to generate test values. E.g. If I use a decimal for my Amount property and want to test the output of 10/3, how would you recommend I check the result without just re-phrasing the calculation?

3. Is rounding each composite Amount is the way to go? and just accept the inaccuracy? does anyone have experience of apps dealing with financials (note this is not a serious banking app or anything so perhaps fractions of pence may not be too much of a problem.)

Any input greatly appreciated.

Answer 1

We are making app working with money (even foreign currencies - but not banking app) right now... (btw sorry for my engrish - and sorry for lack of "public" code, i am not sure if i can just copy & paste anything from my work)

The best approach is simply "ask the client". Its not your business to know, what the internal regulations of every clients are.

I know you dont ask about foreign currencies, so you can skip to 4) and 5), but for context... :)

1) Internally, we use only one currency.

2) Every job is under contract with fixed rate (may be 1:1 if it is our internal currency -- Becouse no trader want to speculate with exchange rate, so they have fixed rate under signed contract & job, for next job, they can make new contract with different rate)

3) Any money can be traced back to job & contract & rate.

4) Rounding can be set for whole app (one, two ... n decimal places) Somebody want two decimal places but one client want to see 5 decimals)

5) We are rounding ONLY for gui&reports, even then, if you click on decimal box, you will see unrounded values. No one care about 0.1 CZK, but may care about 0.01 € (which is 0.2 CZK... Strange, but people are strange :) )

Answer 2

Is there a way to avoid needing to round all my values in the UI they are displayed it, could I do it better via some formatter class perhaps?

Yes:

public string ToString(string format, IFormatProvider provider)
{
    return Currency + " " + RawAmount.ToString(format, provider);
}
public string ToString(string format)
{
    return ToString(format, NumberFormatInfo.CurrentInfo);
}
public string ToString(IFormatProvider provider)
{
    return ToString("0.00", provider);
}
public override string ToString()
{
    return ToString(provider);
}

You can go much beyond this, but now just how such an object is presented is up to the code presenting it (but with a two-decimal place default).

If I'm working with complex calculations, what's the best way to generate test values. E.g. If I use a decimal for my Amount property and want to test the output of 10/3, how would you recommend I check the result without just re-phrasing the calculation?

Rephrasing the calculation outside of the class. Assert.Equal(10/3, (new Amount(10) / 3).Value);

Is rounding each composite Amount is the way to go? and just accept the inaccuracy? does anyone have experience of apps dealing with financials (note this is not a serious banking app or anything so perhaps fractions of pence may not be too much of a problem.)

This depends on the reason it's being used. If you are tallying a bunch of things presented to a user at a given price, then you are going to have to add the rounded values up, because you said you were charging them USD 12.03 and USD 3.12 and so they expect a total of USD 15.15 as that's the sum of what they were told about, not USD 15.16 because that's the sum of 12.034 and 3.1246 when rounded from USD 15.1586.

If you are tallying a bunch of small items including perhaps currency exchange etc. you are going to have to keep all of those small fractions until nearer the end.

You are also going to have to have a decision about whether to apply Bankers Rounding (the default, and the one to go for most of the time) or school-child rounding (the sort expected by some customers, should the details prior to the rounding be visible to them), or always round down (has been legally insisted upon during some currency-change transition periods).

Really, for any given financial process, which sort of rounding, to what degree, and when it is applied is one of the things that need to be recorded in the rules for that process. It is not something that you can generalise about in a general-purpose class.

If you were going to have such a class, then it would make more sense to have this as an operation on the objects themselves:

public Money Round(int decimals, MidpointRounding mode)
{
    return new Money(Currency, Amount.Round(decimals, mode));
}
public Money Round(MidpointRounding mode)
{
    return Round(2, mode);
}
public Money Round(int decimals)
{
    return Round(decimals, MidpointRounding.ToEven);
}
public Money Round()
{
    return Round(2);
}

There; the user code can decide when to round, and also how to round but with sensible defaults.

I'd also recommend making such a class a struct and definitely to make it immutable.