Will this Database design logic work?
There are a couple of problems with this design.


Your link between users and expenses is around the wrong way. As it is designed, a single expense record can have multiple users. This should be a single user can have multiple expense records. Remove expense_id from users and add user_id to expenses (with related foreign keys).
You're going to end up with many NULL values in your expenses table and it will be a pain to query for analysis because of this, you will end up having to coalesce fields for any analysis of total expenses rather than individual expense types. Instead of having separate columns for the gas expense, toll expense and misc expense, have a single expense_value field and create an expense_type field linking to an expense_type lookup table that contains gas, toll and miscellaneous as records
Your personal_salary field should not be an attribute of an expense record, it should be an attribute of the user record. Again, you'll be storing this data repeatedly for no reason. Imagine if you were asked to provide a report on personal salaries only - do you want to query thousands of expense records or a few dozen employee records?
As above but with company_income, this should be an attribute of a company record, not an expense record.


NOTE: With points 3 &amp; 4 above, if personal salary and company income are not annual/on-going static values but are instead values for a specific project or contract then these should still not be stored with expenses. Create a new table for Project/Contract, add a foreign key referencing a project/contract to the expense table and do it that way.

Also, consider your application design. Doing aggregations and calculations across small data sets in Java is fine, but if you're talking about producing annual reports and your data set grows large, this processing would probably be best handled by the database engine which can handle this work in a set-based method rather than row-by-row processing as happens in most applications.