Note: All of these suggestions are based on the assumption that this code will continue to be maintained and extended for a long time. If it's going to be retired soon, ignore everything I've said, do what you need to do (no matter how dirty), and be glad the monstrosity is dying a well-deserved death.

1. Get the specs. I don't care what you have to do - beg, borrow, steal, whatever. You can't (re)write or maintain anything unless you know what it's supposed to do. If there was a design, even if it's a bunch of scribbled-on cocktail napkins, get that too. Get all of the consultant's notes. If there was a tester, get their notes, too. Ask your boss for a few emails describing what s/he thinks this thing should do.
2. Take a week and build a bunch of test data. Make it resettable. Use this as a good first project in Perl and SQL. The idea is that you can do a test run, then reset the datasource(s) and run the testsuite again.
3. That test-suite thingy - make one. DO NOT DO ANY WORK ON THE CODE WITHOUT ONE. I have only recently come to see the light re: test suites and I cannot imagine working without one. That difference between 90% certain and 99.999% certain is a huge one.
4. Build your test-suite from the specs. Do not build it from the current code! For all you know, the code is full of bugs. Your first priority is detailing what this thing is supposed to do.
5. Once you have a test suite, run it against the current code. I can almost guarantee that the current code will fail at least 10-20% of the tests. (You can use this information later.)
6. Factor the code into smaller pieces. Do this one baby step at a time. Every single time you make a change, run your test suite. You're looking to see if your change introduced a bug.
7. Now, if your change introduced a bug, do not assume that you messed up. It could be that your change exposed a bug. Often, production code has two bugs that offset each other. When you fix one, you expose the other. This is a good thing!
8. Keep repeating the refactoring process until you understand what's going on. Now, at this point, the code most likely will not be where most of us would consider to be good. That's ok. You're in a remediation process.
9. Now, throughout this entire process, you're keeping notes. The notes include
   1. Places that need improvement
   2. Refactoring ideas
   3. Business flows
   4. Data flows
   5. Execution flows (all three are different)
   6. Ideas you have for improvements
   7. Modules you can leverage to help out
   Do not make any of these changes ... yet. (Except, of course, where the change is obvious and will make an immediate positive impact.)
10. Release a version of the code that's yours. Call it v2.0.0 and make your boss happy.
11. Add each report. When you design a report, design the tests first. Build the report. Test it. (You might want to consider writing a Report object that will handle most of the common tasks for you. At a previous position, I did that and reduced the development time for a new report from 40 hours to 25 hours, while improving maintainability and promoting a common look and feel.)

Good luck. If you ever need to vent/ask/whatever, please don't hesitate to come here. :-)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.