I'd like to to rephrase your question as this:
"Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?"
I would see two approaches to that problem. The first one starts with the data, the second one, with the final view.
In order to implement this, you need to start with a common set of data and describe some type of two way rule that will generate your final views. That can be an XML transform, some type of form description or anything you fancy as long as all important information from the source data can be safely identified in the final view.
For instance, if your data represent invoices, the important element might be amount, currency, client account number, tax code, invoice number, invoice date, etc. You could then transform this data into a document (word, PDF, XML, etc) and you be able to extract that data back from the output document.
In this case, you should generate a separate view of your document that contains all this important business information (typically, an XML document) and design transforms for all your other document types that will output the same format (so you could extract the important business data from each document type).
You then digitally sign that (either with the identity of the emitter or with the identity of the application generating the data, depending on how your trust system is designed). That digital signature could happen on the server when the data is extracted/transformed which means that you can use an application key.
When validation a document, an application can then use the transforms to get a synthetic view of the business data and use the digital signature to verify the authenticity of the document.
If the design is done correctly, you could then safely validate documents even if they have been altered in non-important ways.
The downside of that approach is that it isn't always easy to transform all types of document into the synthetic view. Another downside is that this doesn't work for data that doesn't conform to a normal model. For instance, if you want to handle purely generic data (letters, pictures, etc.) then this approach would probably fail.
This approach is good for document that can't easily be transformed into data.
You need to start with the final document at the location when you can authenticate them. in your case, that seems to be the end user PC. You then generate a small "description" document that contains a hash of each document (typically as an XML snippet) and any important data that should be authenticated and that isn't already covered by your digital signature system.
You then sign that description file and upload it on the server alongside the two other documents. Your server can then verify the signature on the description file and compare the hash of each document with what is stored in order to authenticate them. Since that signature can only happen when the two document exists, it should be applied where they are generated. And since that happen on the client system, it means you should use a key that belongs to the user, not the application.
The downside of that approach is that you depend strongly on what happen on the location when you apply the signature. The key factor here is that you have, in effect, two documents that you want to pair and no easy way to make sure they really belong to the same pair: you're sending one document from your server and are hoping that the client will be secure and send you back a valid pair along with the digital signature. It means that a client could decide to cheat (by signing two documents that aren't a valid pair) or that some form of malware could display one document pair to the user and then sign something else.
One way to (somewhat) mitigate that downside is to make sure you have good traceability: if at a later stage, someone could look at both document and confirm that they are, in fact, two view of the same data and make sure this reviewed is done, you then place a strong incentive on users not to attempt to cheat the system (because the digital signature engage their responsibility). That leaves you with some form of malware on the client system. whether or not that is an acceptable risk is up to you.