In business, there are other costs: costs for your time, costs for missing deadlines, opportunity costs (eg. not having coders to work on a quick, high revenue project because they're all slowly and methodically refactoring old code) and so forth.

Code management is a gamble: if you write a perfectly clean, shiny, maintainable codebase that never gets touched again, you've wasted the company's time and money on something it never really saw value from (code that could be maintained, but never was). On the other hand, if you write a horrible, unmaintainable mess, assuming it will be a one-off script, the rewrite may be very costly when business needs change.

It's hard to predict what business requirements will be in the future. Some people advocate always writing the best quality code you can, at all times: this is a nice goal, but sometimes management won't let you do it. You have to respect this; sometimes your perception of the long term business risk won't match your employer's; and it's their money to risk, not yours. Let them know the cost/benefit analysis of a given decision, but accept their decision. There's no point in doing a major re-working of the billing system if the whole account collections department is going to be outsourced in three months. Sometimes management is right.

So, give your management the most honest appraisal you can; but then don't blame yourself if you're wrong. After all, they knew the risks up front...

Just my $0.02,
--
Ytrew