Double-entry book-keeping for software systems

As "enterprise" software grows in scope and scale it becomes harder to keep track of all the transactions that are created. At a certain level of complexity - say high volume work flows containing parallel or time-delayed steps - I think that it makes sense to introduce a double-entry book-keeping approach. Doing so makes it easy to aggregate completed transactions (and the effects of those transactions) and to identify and isolate incomplete transactions - just as accountants do with financial transactions. And it is certainly easier to reconcile between (or across) multiple collaborating systems if you can treat the transactions flowing between them as credit and debit entries that offset each other in a virtual ledger. (This post was prompted by the interplay between comments made by my colleagues about the desirability of queue-based / event-driven architectures, and the problems I have encountered trying to reconcile messages sent between intertwined sales and stock systems.)