Oh boy ... it would be difficult for ANYBODY to change it, much less the person who created it. Data should not be contained within repetitions; that is what related records are for.
It would be highly beneficial to change the structure. If you cannot then you will need to either present the file for reverse engineering to a qualified Developer or contact the person who created it, since they understand the structure and requirements and could handle your request with less effort that someone unfamiliar.
From your description, this is not the only example where multiple fields (which should be related records) or repetitions (which should be related records) exist within your solution. Was this file migrated from older pre-fp7 files by chance? Imports take place converting a cell to a field and a row to a record.
Without reviewing the file, I would suggest that the Excel cells be defined in an intermediate file as fields and the import take place there. From the fields, repetitions can be set but it will be tedious. However, I'm just taking a WAG without seeing exactly what you have. And no, I'm not saying you need some expert assistance here since I'm not available for hire right now anyway.
Thank you for the feedback. What do you mean by intermediate file? Are you referring to a MS WORD file, CSV, or text file?
I am speaking of using another table within the same FileMaker file and import your data there into fields (map the Excel cells to the various fields - set up one field for each repetition) which will easily map) . From there, use script to translate from those fields in the intermediate table to the various repetitions. As said, I have no information regarding your structure or the purpose of the 14 Reguirement repetitions.
BUT ... I believe you will be adding duct tape instead of addressing the underlying issue ... repetitions should not hold data - that is what relationships are for and it is known as a one-to-many (1:n).