In one sentence: number, currency and percent fields all store a decimal with a fixed precision and scale you choose at creation, and almost every “the total is wrong by a penny” report traces back to rounding happening at a different point than you assumed. Decide the scale deliberately, understand that values are rounded when they are stored rather than when they are displayed, and treat currency conversion as a separate source of drift again.
Precision and scale
When you create the field you set two numbers: the digits to the left of the decimal point and the digits to the right. Together they are capped, so a field with six decimal places has far fewer digits available for the whole part than one with two.
Scale is not formatting. A number field with two decimal places does not store 10.005 and show 10.01. It stores 10.01, and the third decimal is gone. Anything writing through the API, a Flow or Apex gets the same treatment, silently.
Increasing decimal places later is allowed. Decreasing them rounds every existing record, permanently.
Currency fields
A currency field is a number field with a symbol and, in a multi-currency org, a currency code on the record. Two decimal places is the default and is right for most money.
In a multi-currency org every record carries a currency ISO code, and reports display amounts converted into the running user’s currency. Conversion happens per record, using the current rate or, where dated exchange rates are enabled, the rate in force on the record’s date. Sum a converted column and you are summing rounded conversions, which is why a total can disagree with the same figure taken from a different starting currency.
Roll-up summaries convert child amounts to the parent’s currency before summing. A parent in EUR with children in USD gives a roll-up that changes when the exchange rate changes, even though no child record was edited.
Percent fields
A percent field shows a percent sign and stores a plain number. That is the whole feature, and it is enough to cause trouble.
The classic mistake is in formulas, where whether you multiply or divide by 100 is the thing people get wrong first time. Do not reason about it. Build the formula, put a known value like 25 on a test record, look at the result, adjust. Two minutes of checking beats a month of revenue figures out by two orders of magnitude.
Percent fields accept values above 100 and below zero without complaint. If a discount must sit between 0 and 100, write the validation rule.
Why the total does not match
The usual suspects, roughly in order of how often they turn out to be the cause.
- Per-record rounding. A formula field computing unit price times quantity rounds each line to the field’s scale, and the sum of rounded lines is not the rounded sum. Reports total the stored values, so the discrepancy is real, not a display artefact.
- Display rounding on a formula field. A formula field set to zero decimal places shows 100 for a value of 99.6. Two of those side by side appear to add up wrongly.
- Null versus zero. A null number is not zero. It is excluded from averages, and it makes any arithmetic expression containing it return null unless the treat-blank-as-zero option is on.
- Currency conversion. Covered above, and always worth checking first in a multi-currency org.
- Different filters. Duller than a rounding bug and far more common. Compare the record counts before comparing the totals.
Choosing the scale
Money in a currency with minor units: two decimal places. Rates and multipliers used inside a calculation: four or more, because rounding compounds through every downstream formula. Quantities of whole things: zero, so nobody can enter half a laptop.
Where a calculation chains through several formula fields, give the intermediate fields more decimal places than the final result needs. Rounding once at the end is defensible. Rounding at every step is how a report ends up several pounds out with no single record to blame.
Frequently asked
Can I change a number field to currency? Yes, but in a multi-currency org the existing values are then read as being in each record’s currency. Check what that means for your data before converting.
Does Apex round the same way? Apex Decimal carries its own scale and offers several rounding modes, so a calculation can be exact in Apex and still round when assigned to a field with fewer decimal places. The field’s scale always wins at save time.
Why does my roll-up summary show more decimals than the child field? The roll-up has its own scale, set when you created it. Match it to the child field unless you have a reason not to.
