Probably 99.95% true that if you can imagine it, it can be done. How to handle it depends on your business policy, of which all factors should be considered. For example, if a new employee were to fall ill and miss a month, would you grant the full allocation anyway? Regardless of those factors, one thing that is pretty much cast in stone is that all calculations should be handled by forms, queries or reports. No calculations should be stored, and that's pretty much a universal stipulation wrt databases.
So when your CE funds form opens, you'd have all the necessary underlying data loaded into it, then unbound textboxes would do the calculations. Perhaps there would need to be a manager approval option, in which case your table would need a yes/no field to flag approvals before the form textboxes start doing the math. One of the decisions is, do you use queries to perform some or all of the calculations, and base the form on the final query, or do you do form level calculations based on the displayed records? If you want to see all the transactions, I'd do the latter. If all you want is a summary, the former. So you have some decisions to make AFAIC. If you are well versed in database normalization and adept with queries and tables, you might be able to build something with a bit of coaxing here. If not, more information might be needed from you regarding your tables and relationships, because if they're not right, it can make things much more difficult to achieve - sometimes impossible. It would also be wise for you to do some research on normalization as well as naming conventions and reserved words to get you off on the right foot. A bit of learning on these subjects can save you a TON of headaches later on.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.