If you billed it as an addition, then don't make extra work for yourself by rebuilding it from the ground up.
Sounds to me like you should clone the file and start from that point to meet your needs for the new department.
Hopefully you've clearly explained the limits of the budget you outlined with your client.
A decision like this is usually best made based on use case. Ask yourself several questions:
1) Do these departments share just the structure of the common tables, or do they share the actual data?
2) Do these departments share a common or very similar workflow?
3) How much drift in workflow and / or data and / or feature set can reasonably be anticipated between the two departments?
4) Is it reasonable to maintain a common set of code between the two customers, or are their demands sufficiently different you'd be better off maintaining it as two separate systems?
The answers to these and similar questions will usually guide you. For example, if they share common table structure, but not data, then you're better off cloning what you have and running it separately. OTOH, if they have a common set of data, then you might be better off going with a separated model, giving each department its own interface file and tapping a common back-end data file.
If the workflows are very similar, then perhaps a common interface file works well. OTOH, if the workflows are only superficially similar or expected to drift, then you're probably better off keeping them separate.
Remember that, if you go with separate databases, you'll be maintaining two systems instead of one. That's a consideration for things like your time - and the customer's budget, as Mike B. alluded to.