These kinds of decisions are the real art of database design. Every choice means a compromise.
Try to think in terms of simplicity versus the ability to extend the database in future without editing any table structure code or queries. New abilities are added to an advanced application by adding records to tables, not modifying their design. This is why you have the table of ExpenseIds rather than a column for each type of expense in the main table.
Taking that concept further we ask are there other attributes of each Expense record that I want to record? In the case of the fuel you want the amount of fuel which isn't used on other records. In the future you might want to record some other aspect of the expense that you have not thought of now. No worries if you don't think of it up front. Just add it in a table and presto.
While attributes that are on every record might as well be in the main record, any number of additional attributes can be added to an expense record using a related table in what is known as an Entity-Attribute-Value structure. In your case the related table would have fields for the Expense record (the Entity), the AttributeID and the Value. For a FuelExpense an AttributeId may represent FuelAmount, FuelCost, Odometer or anything you want to record with fuel. Other expenses have attributes for them. Meal expenses can have an Attribute as HadForBreakfast if you want. A travel expense might have StartOdo and EndOdo attributes. Whatever the user wants to add.
The downside of EAV is the complexities of the deign using subforms and dealing with datatypes and units which also often need to be in the Attribute definitions. Is the fuel in Litres or Gallons? Odometer in Kilometres or Miles. You can define this with a table of Units for the measurement. Yet another table defines the units that can be applied to an Attribute. You don't want Kilometres available on FuelAmount. You can design the main records to simultaneously support any applicable unit for the same ExpenseType if you like.
There are performance limitations with calculations too if you record every Value as text so it can be better to separate out the numeric data from the text data.
Clearly it is also going to take a lot longer to set up the EAV model. Once done it can be incredibly extensible but will always involve some compromise.
Designing any database depends on priorities and the value of extensibility versus its development cost. If you are likely to need to be adding new attributes then make sure it involves adding records, not changing the design. Designing in the capability at the start will be better value for money over the life of the application, which very often far exceeds the initial expectation, especially if a database application works well.
Of course the customer must be willing to make that investment or the choices become academic.
