First thing your dataAusit tablke needs a datTime column to denote when that change took place.
Now into the point:
This is a very good question, whe I think of it, I see many risks here, the fact that an entity structure might change introduces many facts, that fields can be added, fields can be removed, fields can be re-ordered, and fields can have their type changed.
And this will introduce too much problems to the serilaization/deserilaization routine.
The work around I can think of is as follows:
1- Add a version column to the Audit Table, to denote the version of the database schema, also you might need to add an entityType column, unless you deduce that from the screenName.
2- Then you should store entity fields' values after converting them to strings in a coma separated way, in the before and after columns.
3- And so when displaying the audit report, you should have your own method which reconstructs the entity fields values from the comma separated data.
This method will be very customized for each entity, and inwhich it will check the Schema Version value to know which fields are stored.