replied on November 20, 2014
Each event written to the audit log contains just the specifics of that event. Deletion events contain information about who did the deleting, when they did it, and which entry was deleted. It does not include secondary information such as metadata attached to the entry at the time of deletion.
The kind of query you can try to run against the audit data would be more like looking for an entry that was deleted and at one point had the status field set to "Paid". You might be able to also filter out entries where the status field was subsequently written to with another value, but that would be tricky. The web UI doesn't support these kinds of queries, this would be something you'd have to write yourself. The audit documentation includes descriptions of the schema and event values. Since a single set field event can contain multiple field assignments, looking for a particular one might be hard (Let me know if you want to pursue this route and I'll look into it). And of course you can find only those events that have been loaded into the reporting database, so you could miss the field assignment event if it happened long enough ago.
I think you'll want to take another approach to this. If you need to record metadata at the time of deletion, maybe you can have a workflow write that to an external database? Or if you're trying to prevent this situation, maybe remove delete rights and have a process that verifies the field data?