I copied the base and am playing in that copy, so you can remove my access to your original.
After messing with it a bit, I don’t think it’s a problem with MOD, but rather a side-product of some of the math taking place leading up to that, and how those values are being represented internally, regardless of how they appear based on the field formatting options.
First off, using SUM(values)
as your aggregation function should return a number, so forget what I said above about the array-to-string-to-number conversion process. That’s not necessary.
Here’s one of the primary clues that leads me to think that the internal numbers are not as clean as they appear. I made a test formula to force {BALLS BOWLED}
to an integer:
INT({BALLS BOWLED})
Putting that next to {BALLS BOWLED}
, the result for that problem line surprised me:

Because the INT()
function “Returns the greatest integer that is less than or equal to the specified value.”, that tells me that the true value of {BALLS BOWLED}
isn’t an even 30 like the field displays, but actually 29.??? However, I wasn’t able to see that detail by forcing {BALLS BOWLED}
to display as a decimal, even with the highest precision formatting option.
My next test was to try to round the value with the ROUND()
function, and see how the rounded value compared to the unrounded one:
ROUND({BALLS BOWLED}, 0) = {BALLS BOWLED}
Based on the earlier INT() test, the results didn’t totally surprise me, but also showed that other values were also not as clean as they appeared on the surface:
In the end, applying ROUND()
in your {OVERS}
field did the trick:
MOD(ROUND({BALLS BOWLED}, 0), 6)
Why isn’t the value cleaner even though you’re using a combination of rounding functions leading up to that? No idea.