If you mean to create a class with 43 atrributes then I don't like either of your plans.
It's hard to say exactly what your model should be because I am not sure what you are looking to accomplish exactly, however, the idea is to create a model the encompasses the information and is flexible enough not to rely on their only being x types.
No, you should never make instance-specific classes unless you have an extremely good business reason to do so. Expenses should able to be cast into a single expense class with some exceptions that you may want 2-3 types of groupings that can likely be handled by sub-inheritence.
For example, you might have an Automobile class and an SUV sub-class. But, you wouldnt want a class for every possible SUV. Maintaining such a beast would be very difficult (unless you were using good code generation).
I am thankful for the code from Maixmilian. Yes, you are right scott... I can give you an example of two expenses: (These are their categorisations)
1) Plant and Nursery Purchase (fields) date, vendor name, item, Qty, Amount, Paid Amount (meaning the amount they have paid to the vendor at the time picking up or getting that item. So the amount yet to pay is the difference of amount and paid amount ), Balance Amount (but I don't need that at saving time, right? I can use query for that a display time.)
i am not sure i got you right ? do you plan on making 33 expense classes now ?
i count 6 groups of expenses. you do not need a single expense class for all the different expenses.
how about you create a hierarchy of expense classes (base class contains all the attributes you determined to be common) and let them have an additional type/name attribute (as in Maximillians example) for the exact expense type ?