Don't store multiple months in one record!  Each month should have its own
record then
you can DSum across records picking out the months you want to sum.
Something like this:

DSum("MyItem","BudgetTable","Month=" & [SelectMonth1] & " Or Month=" &
[SelectMonth2] & " Or Month=" & [SelectMonth3])

where MyItem is the field you want to sum, BudgetTable is the table that
contains the records to be summed and SelectMonth1, 2 and 3 are the months
you are looking to be summed.

Tom Lake

That's what I was worried about.  The idea of having a
column in a table for each month is a gross violation of
relational databases.  To be blunt, you need to stop
thinking spreadsheet and realign your brain to the rules of
database Normalization (Google will find a gazillion
explanations).

In a normalized table structure, you would have a table for
budget items and a separate table for all transactions
against budget items.

For example:
table BudgetItems
ItemtID                        (Primary Key)
ItemDescr        Text
Assigned        Long    (Foreign Key to managers table)

table Transactions
TrID                                (Primary Key)
TrDate            Date/Time
TrType            Text
TrAmount        Currency

Then your user interface would use a mainform for budget
items and a linked subform for the transactions against each
item.

Searching for transactions in a date range becomes very easy
with this arrangement and the subform could easily be
limited to the desired entries.