answers:

This is a result of the floating point representation of the numbers involved. See the wikipedia. Probably 0.05 has an infinite base 2 representation as a double, so the value Math.Ceiling actually sees might be slightly larger than 130.

To be absolutely annoyingly precise: a small (mathematical) integer such as 130 has an accurate finite representation in IEEE floating point numbers (either 32 bit or 64 bit). What may not be representable in floating point numbers is the (mathematical) real number close to 130 that OP thinks is equal to 130

Your percentage isn't actually 0.05. It's a value close to 0.05... and probably a little bit more than 0.05. Thus when it's multiplied by 2600, you're getting a value just over 130.0... which is then being "ceilinged" to 131.0.

Using a little tool I wrote a while ago (available from this page about .NET binary floating point types) it looks like the actual float value closest to 0.05 is 0.0500000007450580596923828125. For doubles, it's 0.05000000000000000277555756156289135105907917022705078125.

Moral of the story: don't use float for this sort of thing - use decimal. Or if you're just trying to represent a percentage, if it's okay to actually be only accurate to one percent, use an integer value 0-100.

@pixel3cs: No, don't use `double`, either. It has the same problems as `float`. The reason `decimal` avoids these issues is because it is a floating point base 10 number instead of a floating point base 2 number. In general, `decimal` is going to be your safest choice for working with money, because the internal representation of `decimal` matches the thing you are trying to represent (though less efficiently).