OK, I'm sensing something. And if I'm wrong, don't take it as being critical of your efforts.
First principle: If you can always recalculate it, never store it. (What, never? No, never. What never? ... Well, hardly ever.)
Second principle: Store data as you get it if there is ever an accountability issue in showing what you got. Don't store data in the form you need it if that differs from what you received. (See first principle.)
Third principle: Anything you can do with a table can be done just as well - and often better - in a query. Which is why the second principle works.
Therefore, if you are basing a report on a table, base it on a query instead, and remember that the name on the report is just a label-box. You can make it say anything. The name of the underlying field is never seen by the folks who read the report. So if you need to base a report or other action on the negative of a field, make it happen in a query.
I won't say that you should NEVER base a report on a table. NEVER is a rare word. (See first principle above.) We have found in general practice, however, that things work better through queries, particularly if you need to show something positive sometimes and negative sometimes. Use different base queries for the two cases and your problem is solved. Queries, coupled with judicious use of computational formulas and the FORMAT function, can do a LOT to make your life easier in reports, forms, and general data processing operations.