So, there's a basic two fold path here, and you might draw from one or both of these options... I'm drawing from a diverse spectrum of IT/develoment engineering jobs and trying to give an a la carte option. :)
Change the Managers
Sometimes, you can talk it through with a set of managers and get an agreement on a One True Status to Rule Them All... this can be easier when your managers are more aligned. For example:
on a development team in govt. contracting, you probably have a task manager, a program manager (or deputy), a resource manager and maybe others. One cares about your availability, one cares about cost/schedule, one cares about overall organizational performance.
in an IT department, one engineer may "report" to several project managers and a single staff manager. The staff manager really guides the person, but project managers are accountable for different non-overlapping subsets of work.
I hope you can see that these are two very different cases. In the first one, you can get the managers more aligned, because (in the end) they care about all the work you do for the organization, you just need to give them the info they need in a way they can parse.
In the second, the different PMs should not know each other's work. One PM cannot and should not care about a thing you did for the other PM, so status for each has to be separate. If you give them One True Status Report, you'll still have to break it into each PM's area.
The goal with any change the managers effort is to get a common element agreed upon that minimizes the time to prepare your status and makes it consistent so you don't have to context switch much when drafting status. Options might include:
common format - with clear subtitles, so they can pick out what they need. Cost-driven manager pulls completion and cost forecasts, technical manager pulls technical tasks and architectural changes, but you provide all of it in one format.
common day - how much does it matter if one person gets data that is several days old? If you draft all status reports on Wed, and they get used through the end of the week, is that OK? On a many month project, it should be. Crisises may have exceptions, but crisises are not for every week.
common location - instead of hand generated email - can they go to a site or a tool that shows them a report of what they need? This can be as easy as an Excel spreadsheet with a number of views on different worksheets and one data store that only you edit.
The "sell" is important. If you say - "this is incredibly annoying and time consuming" you may not get far. But say:
I'm trying to create a streamlined process for creating consistent status reports that are of a consistently high quality...
I want to standardize the process for everyone, so you get consistent information no matter who gives you status and which project ...
They may see the big picture and think of you as a go-getter.
Change the Status
Often the path of least resistence. Here's some ideas that assume that your management is set in concrete on this, and simply won't be moved from having their own Super Special Just for Me Status Reports. Cause... let's face it... sometimes status reports are not about status, they are about ego. Here's some tips to minimizing work
Never provide more than they want. State it clearly, concisely and unambiguously.. but that often means figuring out what the manager thinks of as "clear", "concise" and "unambiguous".
Do not provide extra info unless you need them to take action. And then, consider whether you want it in a status report, or a phone call. Some of this is knowing where the status goes. They are tremendously useful red flags when you know who they will go to and how the reader will be reading it.
Due date is usually the LAST date - I have never heard a manager say "hey, you gave me status too early!!!" - minimize the context switch and send status when you've finished the last reportable thing for that project.
Keep a secret one true status report - It doesn't matter if it makes sense only to you - a status report that lets you build the others quickly will save a lot of time. It is also a wonderful thing if you work in a high-audit field where people with long lists of questions come to you asking to to prove that you know or did what you said you knew or did.
Every situation is different, so treat these as items on a buffet. Take what you think will work and try it. The big picture is - there's an organizational cost to companies. Managers need to know status. But what they need and how they need it presented, can a be dialogue between you and them. Some managers will give you a format and a date and they simply cannot change that... but others are often throwing the first idea on the wall to see if it sticks, and they are open to a counter offer.
How you sell your idea will have a big impact on your success. "hey, we're all busy, let's save time!" may work, but proposing something consistent across the company is the same idea, but shows a potential for much bigger impact. Saving your own 1 hour a week is awesome. But saving your whole department 1 hour a week makes you a huge hero.