Dependent class is invalid and needs recompilation

What does "Dependent class is invalid" mean?

Apex classes are compiled against each other. When you save a class, Salesforce recompiles everything that calls it. If one of those callers no longer compiles, the save or deploy fails and the message names the caller, followed by the actual compile error.

In the message above, a class in the org calls validateRequiredFields(List<Account>) and that method no longer matches. The first line names the broken class, then the reason ("Method does not exist or incorrect signature"). The reason is the part you fix.

What causes it?

• You changed a method signature (a parameter type, a return type, a rename) and some other class still calls the old one. The best-known Stack Exchange question covers this case (Salesforce Stack Exchange).
• You deleted or never deployed a field, object or class that the code refers to. The plain compile errors look like Variable does not exist: InvoiceSyncHelper (a class missing from the project) or Field does not exist: Renewal_Date__c on Account. Those are the same root problem, one level earlier.
• Linked classes (an interface, its service and its implementation) went up in separate deploys, so for a while the target holds a mismatched set.
• A package or another team's class depends on yours. This appears with managed packages too (Salesforce Stack Exchange).

How do I fix it in Setup?

1. Read past the first line. The text after "Class X :" is the real compile error. Note the class name and the method.
2. In the source org, open the named class (Setup, Apex Classes) and confirm it compiles there.
3. Add the dependents to the same change set or deploy. In a change set, click View/Add Dependencies, then add what it misses by hand.
4. In the target org, go to Setup, Apex Classes, and click Compile all classes. This forces a full recompile and shows every class that is broken right now, not only the first.
5. Validate again.

How do I fix it with the CLI?

Deploy the whole family in one call so Salesforce compiles them together:

sf project deploy start --source-dir force-app/main/default/classes --dry-run --test-level NoTestRun -o target-org

Drop --dry-run only after the check passes. If you are refactoring in a scratch org and every order of saving fails, a practical tip from the same Stack Exchange thread is to touch every related class without saving and then use Save All, so they compile as one unit.

How do I avoid it?

Change a signature in two steps. First add the new method and keep the old one. Move callers across. Remove the old method in a later release. Keep the callers in the same deploy as the signature change when you cannot split it.

Keep the test classes with the code too. A test class that still calls the old signature stops compiling, so its tests cannot run, and the 75% coverage check suffers for it. AI Salesforce deployments checks the downstream dependencies of a bundle before you approve it. The Apex glossary entry and the change set errors guide cover related ground.