Got to side with Galaxiom and June7 on this one.
From your description, you have "allowed the tail to wag the dog" and thus failed to completely analyze the data from a database viewpoint. Excel is incredibly powerful but it is not capable of doing everything you want (obviously) because otherwise you would not have attempted to unify everything through Access. But just putting things into Access tables and then trying to treat them like Excel-structured data is, long-term, a waste of time.
This statement is not intended to be a scathing rebuke but rather is a suggestion that you really need to consider. We have seen this a thousand times or more. Excel does things one way; Access does them another. You have transferred data but didn't change the structure and now you face difficulties.
Enough with the platitudes. Your contention that the tables have fields in common (hence the ability to make a UNION query) but that a lot of fields are different? That doesn't matter. From the viewpoint of what they represent, these tables of sub-schools should be ONE TABLE. If there are a few differences that cannot be mapped to one another, then it is OK for you that you have extra fields and that some of them are either blank or have "N/A" (meaning not applicable).
Without more information we cannot tell you how to perform that cross-field mapping. BUT here is the truth about database entity analysis.
Things that are to be treated similarly belong in a single table. The fact that you need to use a UNION query to treat the sub-schools together means that they belong together no matter how superficially different they might appear.
Things that are to be treated differently belong in different tables. That way you get the interference out of the way so that you CAN unify what you are doing across all the things you have to process.
Where you face a hybrid of similarities and differences, you face a case where your database is not normalized. Normalizing a database allows you to keep like things together in one table for treatment according to uniform rules. And it allows you to split out things that are different into child tables where you can isolate the differences.
Therefore, I see it as imperative that you try to study normalization techniques. If you do a web search, look for "database normalization" because by itself, "normalization" would give you articles with mathematical, political, and chemical subject matter.
I am not chastising you. As I said, you made this change because you thought it would help you, and it probably will. But probably under pressure to get something done, you have proceeded too early to write code based on the differences when you should still be isolating the similarities. We've seen it before. It is NOT a character flaw. It is just that you have a goal and a deadline and the deadline was not realistic. Been there, done that - no fun. I really do sympathize and understand. But there is no excuse for skimping on the analysis phase of a project. You only do yourself AND your users a grave disservice.