If you check the documentation for order form calculator (I don't have permission to add links) you you can easily overwrite to default functionality.

Why would the sub total need to have 3 decimal points though?

Hi Stu!

Ah just just checked it and can see they have a sample of overriding the validators thanks. What I think I need to override is the CalculateSubTotal virtual method. But it is not clear what is causing the value to round up in the GetSubTotal method (which is called within CalculateSubTotal). Any ideas?

Its 3 digits because that is what is past through via our price feed. For now we have set the price feed to send through just 2 decimal places which has solved the issue for now.

It rounds up because GetSubTotal returns the type Money and I believe in that type it will make sure it returns a valid value for the set currency which wouldn't ever have 3 decimal places

Cheers Stu. I did have a feeling it might be something to do with it changing types but didnt run any tests at the time.

Just ran a quick one:

double doubleTest = 18.325;
decimal d = (decimal)doubleTest; //Equals 18.325
Money m = new Money((decimal)doubleTest, c); //Equals 18.33

In this case they didnt want it rounding up to 18.33 which is why it was an issue. 

This release note might be interesting, if you are considering an upgrade to Commerce 13.
Re-work rounding strategy in calculators

Also, Quan Mai wrote some tips on tweaking the number of decimal places for a currency.
Control the rounding level of currencies

Thanks again Mads!