Are you talking about the "list calculations"?
If so, I kinda tried to explain that earlier in the thread. Calc element values are only saved to the database when you save a form. So, say you change the calculations (like we did), such that every row now has different values for the calcs, you may see the new values in the list's individual rows, but that's because the values are being calc'ed on the fly as the element is being rendered (your calc is re-run during list display). But the column totals are built from the data actually in the database, using database queries (like SUM() or AVG(), etc). And because those calc values haven't yet been saved to the database, the calculations don't see them.
So, yes ... you can "fix" it (in quotes, because it's not really "broken", you just haven't saved those values yet) by editing and saving all your forms, to force the calc values to be saved to the database. Which is why it pays to get all your calcs right before you have a lot of data.
I just did that for the first record in the list, and the totals now look OK for that one.
BTW, I notice that some of those forms are HUGE. You may well run into issues with PHP's settings, which by default restricts the number of form inputs to 1000, and also restricts the total size of form inputs. You'll notice you have that problem if you start to lose repeats after saving. At which point you need to edit your php.ini, and increase max_input_vars, and possibly max_post_size (or some such).
-- hugh