rainman, your basic question is to look hard at your business model for "entities" that are significant to the model.
Let's digress for example only...
You are a person who makes items for craft fairs.
Your entities are finished products (sellable), customers, locations where fairs were/are to be held, raw materials, labor hours.
OK, change hats. You are a chef in a restaurant.
Your entities are recipes, raw food, spices, tableware, flatware, linens, staff, tables, cooking utensils, appliances, ...
What you need to do is make a list of the categories of things that are part of your business. These become your entities. Then you have to decide how you treat each entity and how it is tracked. That will go a long way towards deciding the answer to your question.
Now, let's go back and ask the question with that thought in mind.
i was trying to get around the fact that an expense needed to be related to a time entry... wanted them to be seperate.
This can happen if an expense exists that is NOT related to a time entry in the "real world" business model.
Here's how it happens in our office.
We have contracts to which time charges represent an expense. However, the people who work on these contracts sometimes have to buy supplies or take trips. The latter two categories are what we call "other direct costs." The expenses on any contract are then the SUM of the labor charges and the other direct charges.
How do you do this? Damfino - it's your DB. But you can do it many ways. Here is one way that comes to mind. Have TWO tables that represent charges. One is labor-related and for that table, ALL entries correspond to a time entry. It becomes possible to either (A) establish a hard-and-fast relationship from Labor Charges to Time Expended or (B) include the time charges IN THE SAME TABLE. (Matter of formatting.) For the other table, you have the "Other Direct" stuff. This will tie back, not to TIME charges, but to expence sheets, receipts, etc.
Now make a UNION query that stacks time charges with other charges so that you can use that query as the basis for billing information.
But that is only true if your shop is similar to the model I just explained for my shop. Which is also why you need to understand that you are going to have to be the one to figure this out. We don't know your model. All we can do at THIS stage of the game is help you with guidelines and approaches.