Your vendor is likely to produce the minimum required to fit your definition of documentation.
You will need to spend some time thinking about what kind of documentation you want, and possibly provide them with templates, a wiki, etc. that you want them to use if you don't want to get junk when you are done, and you want it to be easy to update as things change.
What are you likely to need? I think of documents that are accessible to different kinds of people, at different kinds of decision making levels. As ratchet freak said, there is lots of auto generated junk that adds zero value, and you rarely get good information at the very detailed level. Besides, software developers are generally good with the details. You need good documentation for communicating with stakeholders and management.
I think you will want things that explain at different levels of detail. Using the airplane altitude analogy, an example (vary the altitudes for your organization. Since you say that your commissioned software will be used by several companies, you may need more levels):
The 30,000 m view for decision makers at a very high level, for when big changes are needed. (i.e. how this software integrates with existing systems, interfaces, and the major components) You may need more than one of these, if you have disparate existing systems, so negotiation can be done among the several companies you are talking about. Above all, this needs to be brief and clear, with diagrams, and in natural language that a NON-TECHNICAL person can understand.
The 15,000 m view for project teams that might be tasked by the decision makers. You will want this to include the specific differences in the software for the several companies you discuss in the top. There are ALWAYS one-off situations to get from a theoretical design to getting stuff to work. Depending on where the one-off stuff is done (by individual companies, or by this development group), this may get messy. Again, brevity, non-technical language, and diagrams are most useful. It shouldn't matter what language the code is written in, etc. for people to understand this documentation. You want it as a negotiation tool with the user companies, and with the development team.
The 5,000 m view of major code components and how they fit together. Here is the first place where technical language may start to be useful. This is for project teams who have to specify changes, and determine what major chunks of work need to be done. Here is where the developers, designers, and start the back and forth of how things will get done, what parts of the software will need to be changed, etc.
This is what I would want. I'm a developer/integrator in a large multi-site organization. I am often in conference calls with non-technical people who don't care about details, and are trying to understand jargon of IT folks who love the details. You need docs that will communicate the space between big picture and detail, so that you can get everyone in the same place during discussions.