Two Tables, and Nothing More
Sounds like you’ve identified the specific problem and solution yourself in your response to Taylor L’s advice. The problem is an inconsistent UI, with a separate edit section for the Companies table while having in-line editing for the Employees table. The solution is to provide in-line editing in the Companies table and eliminate the editing area. This makes the UI consistent, fastest and simplest to use, and puts the available real estate to best use. It would be very similar to the master-detail windows commonly seen for file managers, with a list (or tree) of folders on the left, and a list of folder contents on the right, so you should be able to make it familiar to your users (although window managers tend to have relatively limited in-line editing ability).
I don’t understand why you “just did not want to use the ugly Master-Detail with two tables.” (To me, "master-detail" refers to any hierarchical multi-pane layout where one pane provides additional information related to the current object in another. That additional information could be a list of components, such as employees of the current company. It does not necessarily mean a separate editing region for objects in a table or list). A two-pane master-detail layout seems like the right solution. As for ugliness, maybe that’s more an issue with graphic design than page layout, and you need to a skilled designer to work it, perhaps taking inspiration from other more attractive multi-table master-detail windows, like file managers through the ages.
Primary Window, not a Dialog
Other than that, good labeling, as Taylor L suggested, is helpful.
Also, instead of Save and Cancel buttons, consider Save, Undo, and Close toolbar/menubar controls, along with other basic commands (e.g., Cut, Copy, Paste, Insert, Delete). The difference is that neither Save nor Undo closes the window and that Undo reverts one change to one field at a time, instead of discarding all edits the user made (to do the latter, the user closes the window without saving). A large window with so much data to edit shouldn’t be a dialog, but a primary window, allowing users to incrementally save (and revert) their work, and providing users a full set of tools for sophisticated editing that will likely be necessary. If the window were a dialog, then one slip of the mouse on the Cancel button could vaporize a half hour of work.