You need to define/design the recovery points and audit points in your solution. These may be different, so for example, you may use the TN database as the sole recovery point for replay of transactions but choose to audit the activity at each IS. Auditing within the Broker would normally use the document logging under the Logging Utility. A recent update here allows the Logging Utility (patch on v6.5, built in for v7.1) to capture a custom document ID instead of the internal broker document ID and this makes tracing back to an original business request much easier.
One limitation for the Logging Utility is that you have to capture the entire document, which is not always desired. In this case you may meet your requirement by auditing in the IS.
So you could log full content at TN suitable for resubmission from there, audit in the IS, log in the Broker, audit in the IS. You can resubmit docs from the document log if required.
There are additional mechanisms for handling reprocessing in TN, IS and Broker (via Document Logging) and various mechanisms for handling failures (error logs, audits, duplicate document detections, transactions where appropriate, trigger retries, etc). For pure support/tracing, I would suggest looking at recording a business ID in the IS at both ends that can be linked back to the TN perspective.
For resilience to failure, and recovery/replay, you need to design to specific requirements and use the appropriate techniques (it isn’t a short topic), but you can replay services in IS or documents from Broker using the administrative screens.
These are general considerations for any loosely-coupled B2B-A2A interaction which should map to the use of the appropriate product capabilities.
One final thought is that if the B2B part feeds a business process then the same considerations apply around what to log/audit, where recovery makes sense, etc but you have access to the BPM monitoring/tracing as well.