There are a few things I want to point out about your test case that I believe is somewhat crucial to understanding the problem here.

I just want to point out that anytime you maintain a bidirectional relationship, both sides should be manipulated regardless which one owns the relationship. That ensures that when you don't explicitly clear the PersistenceContext that any inspection of the relationship from either side is guaranteed to reflect the right association. The only exception to this is when bytecode enhancement is being used to handle manipulating one of the sides for you, but that clearly isn't the case here in your test case.

So if we assume for a moment we set boths sides of the relationship, that addresses part of the problem.

There is still the issue with the null value being stored however and that is because of the use of #load versus #get. Its important to remember that whenever you use Session#load, there is a chance the returned object will be a proxy and therefore only the identifier loaded. Since the process of making the association as you did in your code doesn't require that any other state be loaded, that is why we're seeing that the data property gets stored as null rather than the name assigned.

The workaround here is to use #get rather than #load.

What I need to determine then is whether Envers can determine the entity has been loaded lazily in this case and subsequently load the entity state needed in order to properly audit the row correctly without tainting the current session's PersistenceContext. I'll update this JIRA's subject to more aptly name the issue that proxied objects may not have their full state audited when loaded using Session#load.