When you create a form bound to a record, there is a moment of data synchronization between the form and the record that is signaled as the Form_Current event. It says that whatever is in the bound record, the form currently reflects it. I.e. the data in the form is "current."
As you make changes to bound controls, the form and underlying record diverge from each other. Some actions that you take will make them become current again. The "Save Current Record" action occurs manually OR if you are set up to allow an auto-save on navigation, but that auto-save IS an option that you didn't have to take. (It's a cursor setting that says rather than navigate, your cursor moves back to the first field.)
If you have the "cyclic" cursor setting then that auto-save is not available then you can't so easily navigate away from the form while it is dirty. It got dirty when you changed a bound control in the AfterUpdate event.
This link explains the order of events on a form. Scroll down to the heading that includes "updating data in records" and check for the events - including one event that doesn't appear.
support.microsoft.com
Access calls your event entry points if you declare the event code. The BeforeUpdate event occurs before Access writes back the changes you have made on the form. The AfterUpdate event occurs when it is done making the changes. A couple of events later, the Current event kicks in to let you know that all changes have settled.
Here is where that error occurs. Your AfterUpdate event dirtied the form and somehow you are not allowing automatic updates. So to navigate to a new record at that time, you have to first SAVE the current record (again) because you dirtied it in the AfterUpdate event. It is legal to move to a new record - but not if you don't save the current one first. And not if you dirty it after you save it but before you try to navigate.
In this case, I am not sure that the Form_Current event will occur if you dirtied the form in AfterUpdate because the form is still dirty (or dirty again) after that event routine.
Now, your actual complaint is "They all work fine until I put an After Update event on the form itself." Move that code to the BeforeUpdate event and you will see things working a LOT better.
EDIT: I see June7 ended with the same advice I ended with. But I like to explain WHY things work that way. Forgive me if I get long-winded at times. It's a remnant of the teacher that I was in several jobs, none of which were actually in a learning institution.