The design of the form is confusing and there is no data validation. You are taking unbound values from the parent form and using them to populate fields in the subform if the subform gets updated. However, you are not validating the data. You are just blindly copying nothing or something to the subform. For example, you seem to have a default for Estimator of XXXX. Do you really want that to be added to every new subform record or do you want the person to actually choose a name? You need to at least ensure that there are values to be copied. Also, if people do their own data entry, they shouldn't have to choose their name at all. YOU should be automatically populating their UserIDs (Initials are a poor choice because they can be duplicated although you can display as initials if the initials are unique) based on who is logged in. You are also duplicating other data but I didn't investigate that.
Your code contains multiple refreshes. Refresh and Requery have specific tasks but as a SIDE EFFECT before performing their assigned task, they must force the current record to be saved. If you want to save a record, do it explicitly. Do not rely on a side effect of a different command. You have no control over the decisions MS makes internally and at some point, the "side effect" may not be to save. This is very poor (and dangerous) programming practice. Logically, you don't actually want to save a record at all until the data is complete. If you had proper validation code, the save would fail if you saved before all the required data had been collected and verified so I recommend removing ALL the refreshes. Access will save the record when you leave it. You do not need to expressly save it. Access has a personal mission to not let data go unsaved so most people new to Access, especially experienced developers who don't understand the "Access way" get in trouble with this concept and think they need to control forcing a save. But, in fact, you need to work to PREVENT saving should the data be invalid or the user change his mind and let Access always try to save. Your validation code belongs mostly in the FORM's BeforeUpdate event. That is the last event that runs before a record gets saved and all you have to do to prevent a record from being saved is to use:
Cancel = True
So, do the validation and set the Cancel argument to True and exit the sub. The record will be left dirty so the user can fix the problem and try again. Only in very rare cases would you ever use Me.Undo to remove what the user typed. I don't use it to remove invalid data. The user needs to see what he typed. I would only use Me.Undo if I was going to prevent the user from saving anything, including valid data. So if a user is not authorized to update/add/delete, I use Me.Undo. Otherwise, I leave the bad data to be corrected.
As others have mentioned, If the type is mutually exclusive (I.e. only one value at a time), then the proper technique is to use an option group or a combo rather than separate checkboxes. On a subform, a combo is preferred since it takes less screen real estate.
I would also rethink the presentation. An Access form is not a web page. It shouldn't be huge and have to scroll in all directions. This makes it much harder for the user to work with because he probably can't see everything he needs to see at one time. Rather than having two huge subforms, you might consider using a tab control so you can show one subform or the other depending on which tab is selected. I would also consider making the Estimate data subform several rows high so it can be viewed without horizontal scrolling. Vertical scrolling from one record to the next is perfectly rational. I'm sure you can organize the individual fields so they are clumped by relevance to help the user focus.
And finally, it is really important to your future sanity and that of anyone who works with the database for you to give every control added to a form a meaningful name so some late night you don't have to go searching for what chk40 is or text382. AND it is important to do this BEFORE you actually use the control because after you use it in code, changing becomes a PITA. Doesn't mean you shouldn't still make the change. Just means it is more work.