Manually make a copy of the fully structured DB. Copy it to another file with a name like MyEmptyDB.MDB (or .ACCDB as appropriate).
Go into MyEmptyDB and empty it with suitable DELETE queries. Remember that relational integrity means you empty child tables first.
Now the next time you need your template, just copy it to a new name. In Access, there is the File System Object that will allow you to do a copy command that includes a new name for the thing being copied. Or, as rarely as you do this, build a batch job to do a rename and copy.
Going through the formality of a template is a pain in the toches. I've made a template file for Word because of my writing hobby and even THAT was a real pain to get right. I eventually did, but HOLY MOLEY what a convoluted process. Having done it once, I can do it easier the second time, but the instructions online were not 100% clear. And the difference between Word and Access is that your application doesn't really need a template. It can make do perfectly well using a blank copy.
But there is another issue to consider. The process you described can be managed another way by simply including a "date of import" field so that you can focus on one data set or another just by choosing the import date (or if you prefer, "applicability" date.) Queries can select for each year of applicability. You don't NEED to separate out data that badly as to have a whole new file.
However, here is ANOTHER approach. Go ahead and manually make the copy of the back-end file. Empty it out by manually making some DELETE queries that you just don't save. Now when the time comes, rename the previous backend for historical record-keeping purposes and then copy the empty backend to the same name as the previous backend. Access links its "native" backend files by name, not by any internal Windows File ID number or anything like that. So you can keep the FE, keep the BE structure, and not worry about templates. Run that little rename/copy script and you are all set up for the next cycle.