Multiplying by a percent column acts as if the percent were in fact an integer. So 100 * 50% yields 5000 in a formula column rather than the correct result of 50.

# Multiplying by percent column yields result that is 100 times too big [SOLVED]

Iâ€™m having the same issue. Any input from support on how to address this?

Apologies, our percent field behaves a bit differently than it does in excel, as youâ€™ve pointed out. We treat the percent as formatting, and then just multiply the actual numbers. Weâ€™re looking into changing the behavior so that it does what you expect. In the meantime, you can divide everything by 100 as follows:

(Percent * Number) / 100

+1 for changing the behavior to match Excel.

A calculated field that returns 0.5 should be displayed as 50% when the format gets switched to a percentage.

Just noticed this too! When formatting a column where, for example, mathematical result is 1.03, formatting as a % displays as 1.03% in stead of 103%.

+1, this is really confusing.

No joke. +1 for making a percentage field type compute likeâ€¦ wait for itâ€¦ a percentage.

PS- Sorry for the snark, but having a percentage field type that just adds a % symbol to an integer is just super funky. It makes sense to just add a % when you set the FORMATTING type to â€śpercentageâ€ť, but not when setting the field type for a columnâ€¦

This is still not fixed.

Percentages arenâ€™t calculated as percentages, they are just â€śpretty to look atâ€ť with a % at the end.

+1 very confused by how Airtable multiplies percentages

This **does** seem to be one of the most common of Airtable 'gotcha!'s.

Until itâ€™s fixed â€” and, unfortunately, the longer it goes unfixed, the greater the pressure will be on Airtable **not** to fix it, for fear of disrupting existing bases that have implemented workarounds â€” one can use the following function:

Instead of

`Value * Percent`

use

`Value * (Percent/100)`

Similarly, if calculating a percentage discount (as discussed in this post) you can use

`Value * (1-(Percent/100))`

to calculate the amount of `{Value}`

after the percentage discount has been applied.

I have the same issueâ€¦ somehow strangeâ€¦ unexpected that 20% x 1 give 20â€¦ ??

How does this only have 11 comments? This should have 1,111 comments. Airtable is such a wonderful product, but this one thing is so, so wrong. I honestly donâ€™t know how a company that considers itself a database company can let a bug this big persist for years.

Please update/fix this. As discussed, the longer it goes the more formulas I have that include a *.01 calculation will need to be fixed. Just to be clear, itâ€™s worth the short-term pain to fix as soon as you can.

Alternatively, if the delay is fear of breaking existing airtables, maybe you can just add a 2nd Field Type. Percent (as Integer) and Percent (as fraction)â€¦ or whatever word better describes the difference between the stored magnitude.

Thanks,

Mike

Big fail here, peeps. Please correct.

Agree easy workaround. And think of all the bases that will have to have formulas change if they ever fix. But it is just not right.

There are possible ways around this (e.g., a configurable option to enable/disable legacy functionality, or a versioning system that say 'this base created under Airtable #.#, so behave in such and such a manner"). Weâ€™ll have to see what Airtable choosesâ€¦

+1! I just spend 20 wasteful minutes trying to figure out what I was doing wrong before searching and finding this post.

Also this thread was started in January 2016. High time to fix it already!

I suspect the horse has already bolted, so closing the door wonâ€™t help. Airtable has indicated there are so many customer formulas out there that assume `##%`

is equal to `##`

, rather than `0.##`

, correcting the problem would wreak havoc in existing applications. Instead, going forward there are steps one can take to minimize the issue.

One approach would be to wrap percentage values with the following (where `{Pct}`

is the name of my percent field):

```
VALUE({Pct}&'%')
```

That will return the appropriate decimal value for the percent field. One good thing about this approach is that it will return the correct value regardless if `{Pct}`

is a percent field *or* a text representation of a percentage â€” that is, using that function to wrap either `13%`

(percent field) or `'13%'`

(text field) will return `0.13`

.

+1 on this. Thereâ€™s no point having a percentage classification if it doesnâ€™t operate as a percentage. Just confusing and a hidden source of error.