Let's look a little in the history of reports. In the beginning there were punch cards and printouts. We were preached I-P-O (not the stock game) Input Processing Output. There was no way but a printed report to get something out a computer. Then came the terminal. With it's incredible 80x25 character output it was no match to the paper used for reports. Since then we are used to develop our dialogue systems and then in a separate step design our reports.
What's wrong with this approach?
Mainly two items: first it is based on the assumption, that our business documentation is still living mainly OUTSIDE of computers. Secondly you miss a big chance to get your data model right. I witnessed a number of projects where the reports weren't taken into account until late in the project (reports?- The report software package does it!) and the projects failed. The so called paper artefacts give you enormous clues where the special needs of the systems are. (On of my best tricks: look for documents/reports where there is a lot of handwriting added).
How to do it better?
Integrate it. For every report there is a business case (sometimes strong, sometimes weak like "We always print on of these) and question, so make sure your interactive system can answer easily every of these questions. With the power of hyperlinking (hyperlinks are not limited to browsers) you can build interfaces, where any item in a list could become the new information category. Then just add a "Print this" button and there you are. If your application is webbased you even might not need this, a proper formatted css stylesheet for print will do.
There are examples
Intuit's Quicken goes a long way there. Wherever you are you can call up a report and drill down until you are back at an single entry. When you use Crystal Reports to do a web report it provides the drill down until you link it back to a single entry. I think it's a step in the right direction, that could be followed by a number of additional steps: Make it seamless, reports (until printed) should look like the rest of the application. Allow (if authorized) changes as early as possible, so you don't need to drill down the whole information tree. Make change of the report parameters as modeless as possible (e.g. when you drag an line item to a category it becomes the new category for that report.