There are several approaches to attacking the time bloat of automated testing. Some of the approaches such as running multiple virtual environments and running the tests in parallel, and reducing the scope of what is actually tested may not not suitable for your workload, but are worth mentioning as possible strategies for other readers in the future.
One of the areas that automated tests can spend a lot of time, is getting the test run into the 'test state'.
One suboptimal solution is group together the tests so that you only need to get into that test state once, and then you run all of the tests in this state as part of a group test. This is flawed, because you can have situations where tests only pass because of artefacts left over by an earlier sequences in the test run.
A more complete solution is to find a mechanism to quickly recreate your starting environment. Have a lot at the systemic effect of the import of these documents. Are they processed into different configuration files? are they updating multiple database tables? and then finding a more efficient mechanism for the injection of this state information into the test environment. However, this approach can be problematic if the format of the state information changes during product development, its a substantial job to recreate.
The solution I would probably use is to use a mechanism that allowed rollback. It might be virtual environment that could rollback to a snapshot, or perhaps using LVM below the file system and then at the start of each test, we just roll back to the start point, losing the artifacts from the previous run.