Reading is writing
User documentation falls under the same rules as any other writing; reading is more than half the job. So, you should definitely look into some existing user documentation to get a feel for how they have done it.
By target audience
That being said...
When I document software I always take the target audience into consideration. In your case, it's the end-user. However, end-users aren't a homogenous group.
The biggest difference comes from experience with the software. Is it a user fresh off the introduction course needing a step-by-step description of the process, or is it an experienced user needing to look up some command or other fact?
For the first type of user, it would be best to document by process, maybe even (but this almost falls into training material) in a way that shows the user how to perform tasks/processes with an example set of data ("How to create monthly ABC-reports for company ACME's XYZ..." etc.)
For the second type of user, some kind of command/task dictionary would be most helpful. A good approach I use is to start off with a "quick guide" where you get the bare minimum answering the "how was the command/task performed now again"-question, e.g. syntax descriptions for SQL software, or as a terse list of steps that an experienced user will understand immediately.
After the quick guide, you could add details, discussions about options, further information, references to other parts of the documentation, etc.
Grouped by feature
Depending on the complexity of the software you are documenting it may be necessary to divide the documentation into groups by feature and then for each feature offer both feature type documentation (what reports exist) and process type documentation (how to produce reports).
Very important processes may also get their own "level 1"-heading alongside the features. One example that comes to mind is the introduction to the software, the introduction to the documentation, and the "getting started" section. But most software may also have one or a few processes that are central, important, and/or span several features.
As a complement to training courses
Another aspect of documentation is; should it be a complement to training courses where the user could be expected to already have course material? In this case, you need more reference type material and less step-by-step type.
Creating and offering course material can also be part of the documentation strategy with or without selling a course with it. And selling courses for the software are sometimes part of the business strategy as well.
Other types of helpful documentation
Another type of documentation I find useful is different types of troubleshooting help. As a technical support person, I've built a dictionary of error messages and possible causes and fixes. I feel the software developer could have spared me the pain by just providing it... and spared me the pain of having to divulge that information to the end-user... again... and again... and again... but maybe, that's just me... ;o)
I've also seen documentation that walks through the user interface of the system. This, however, is usually part of the step-by-step documentation, but sometimes I've seen it in the shape of a UI-reference section as well.
Finally, I think it's worth considering the choice of medium for a bit.
In most cases, it may be possible to convince users to visit a website with a wiki or similar format for information. In this case, the issues of having to repeat information will of course be less problematic, just link, include, or otherwise reuse the digital information.
However, PDFs seem to be the safest bet (unless your program is to be used by the military...)
I've seen cases where security concerns would have prevented or at least severely limited the end-users from visiting the web. So going web all out or as an only option may be problematic.
But this probably depends on what kind of software you're documenting.
In-system-documentation is usually of the "dictionary" type mentioned above and would probably not be a good fit for a new user unless they had good support from training material.