You can have your starting rule for the workflow run on any document created, and you can use RegEx to ensure it is only running on the documents within the specific folder structure you indicated.
You said you have TOP FOLDER > SUB FOLDER > YEAR > ACCOUNT > DOCUMENT
It sounds like TOP FOLDER is always consistent, but SUB FOLDER can be a few options, YEAR is always a 4-digit year, and presumably ACCOUNT has a pattern it always follows. We can work with that.
Here's some RegEx for example:
\\Folder1\\[A-Za-z1-9 ]*\\[0-9]{4}\\[0-9]{3,9}\\
This expects Folder1 for TOP FOLDER, then any string of letters, numbers and spaces for SUB FOLDER, then a 4-digit number for the YEAR, and a number between 3 and 9 digits for the ACCOUNT.
So something like this would match:
\Folder1\SubFolder 1A\2024\54321\
The Workflow starting condition would look something like this:
In the Workflow itself, you could use a "Find Entries" activity to get the other entries that are in the same folder:
If you set the "Find Entries" activity to sort by Entry ID in Ascending order, it'll basically sort the entries by the creation order, with the newest entry (the one that triggered the workflow) being at the end of the sort.
You can also have the "Find Entries" activity retrieve the fields you want from the entries it found.
That means that single activity has found the other documents in the folder, sorted them by creation date, and retrieved the values of their fields.
In order to get at the information from the "Find Entries" activity, we need to use a "For Each Entry" activity to loop through the "Output Entries" from the "Find Entries" activity.
Within that loop, we can assign the field values from the current entry we are looking at, to the new entry that triggered the workflow. But since we are looping through every document in the folder, we don't want it to try to copy the values from itself to itself, since that will just mean the values remain blank. So we can use a Conditional Sequence activity to confirm the current entry's entry ID does not equal the entry ID that triggered the workflow.
Finally, we can populate the current entry's values to the entry that triggered the workflow, using an "Assign Field Values" activity.
The whole thing will look something like this:
The cool thing about Workflow, is there is very often more than one way to solve a problem. This is probably not the only way to do it, it might not even be the best way to do it, but I think it'll work, based on the described situation.