I actually do use release candidate for the technical drafts that I write.
We use a major.minor versioning system to denote drafts. In a typical case, the first widely circulated draft would be draft 1.0, the second widely circulated draft would be draft 2.0, and the final release would be designated version 3.0 and archived. In between, I use minor version numbers to save my daily progress and distribute interim drafts to the core team: draft 1.1, 1.2, and so on. I got annoyed when I would create what I expected to be the final draft and designated it 3.0, only to have various bigwigs demand last-minute changes, necessitating the creation of a 3.1, 3.2, etc. So now I publish a release candidate draft that may have an internal version number of 2.6, say, but gets circulated as "Draft 3.0 RC1" (Release Candidate 1). If there are any changes, I circulate 3.0 RC2 (internally saved as 2.7), RC3 (internally saved as 2.8), and so on, until we get the go-ahead to publish. The final RC version then gets saved as 3.0 in our version control system.
The term "release candidate" is borrowed from software development, as is the concept of major.minor versioning. A release candidate is exactly what it sounds like: the product is believed to be ready for release, unless additional changes are requested. You note that "within the target group this expression is too closely related to software development rather than text documents," but I find that to be an advantage, rather than a drawback: the team knows exactly what a release candidate is, and doesn't need it explained to them.