I'm going to assume that when you say you "inherited it", you mean that you have been hired into a position where the existing code base was a mess. The other interpretation is that it was left to you in a will - which would be very cool, but unlikely...
I think that the most important thing you can do is review the code, identify risks and plan to address them. This is a very professional and measured approach to fixing the problems and should be viewed favourably by management. What you need to communicate very clearly is the value you will add to the business though your refactoring efforts given that it doesn't necessarily add features that translates into sales (or whatever the business does) in the short term.
The benefits include things like:
- Bug fix times are reduced, leading to faster turn around of getting patches to clients.
- Feature development time will be reduced while quality will be increased.
- Decoupling components allows them to be tested in isolation, making testing more effective at finding and pinpointing bugs. This leads to increased productivity and quality.
- Overall the software development will cater for change more effectively as a loosely coupled, well tested system can be extended and reconfigured quickly while maintaining a very high quality standard.
You need to find reasons to refactor that have a direct correlation with the business's drivers. If you do not know what dives the business, then have a discussion an appropriate management type who can help.
My advice is quite simple - refactoring is good so long as it's done for a good reason. A reason like "the code is not neatly structured, without any form of architecture or beauty or clarity" is not motivation enough. Engage management and get them excited about the possibilities that an improved code base will give them!
... and then deliver it. If you don't, you're going to look like a clown.