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

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.

1 Like

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 Like

+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…

1 Like

This is still not fixed.

Percentages aren’t calculated as percentages, they are just “pretty to look at” with a % at the end.

1 Like

+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


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.

1 Like

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.



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):


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.

1 Like