Your choice of words tells me you migrated from Excel/other spreadsheet to get to Access. You need to do a paradigm shift if that is so. You are still thinking "flat-file" and that isn't Access. However, be that as it may, there are ways to do what you want and never let it be said we would blow you off just 'cause of your choice of words.
It is not clear in what form you are storing your data so I'm going to be less than perfectly lucid in my answer. If I take you literally, you have a record with some sort of date field and a number. What you want is a computation of the difference between successive months.
The way to do this, in overview, is to compute the values of whatever month/year key you are using for the date field. Do it for the month in question and the month prior to that one. Then you can subtract the stored values, perhaps at worst via two DLookup calls. I have seen topics on "running totals" but to be honest, this appears to be different. You want a running difference, and that is trickier. I think GHudson has published a couple of articles on the topic but I can't recall what keyword you would use to search for it other than his name.
If you tell us what form your date takes in your table, one of us might be able to give you a more specific answer as to exactly how to do this. Like, do you have year/month as a string, or short-date of the 1st of the month, or long-date of the last day of the month, or some encoded time-tag format? That sort of thing.
OK, now the "lesson" side of this to help you shift paradigms...
If all you are storing in your DB is this total once per month, you should not have left the spreadsheet. You don't need Access for this class of operation. And Excel can do this very conveniently. On the other hand, if you are trying to upgrade, you are going to give up some things in order to gain some other things.
For instance, if you are storing ALL of the contributors to the monthly total as well, you can just directly compute the monthly sums (that should equal your monthly incremental difference) in a query - and NEVER have to actually store the total. This is done by a Summation query over your detail records grouped by year/month, which you can do as the concatenation (using & operator) of two calls to a DatePart function. Or the query wizard can build a summation query with year/month GroupBy for you, if I recall it correctly. (HINT: Sometimes the Access wizards are your friends DESPITE their being dumber than a box of rocks. Because at least they give you a good starting point that you can then customize.)
You should NEVER EVER store a field that can be recomputed on-demand from other data in your tables. Storing computed data violates one of the principles of normalization, which therefore relates both to the accuracy and the efficiency of your data storage.
