What is event log?

Three columns are enough. The case is the thing travelling — an RA bill, a purchase order, a vendor invoice. The activity is the step that happened to it. The timestamp is when. Everything else is optional colour: amount, owner, vendor, project.

case id + activity + timestamp

Anything that can export those three columns can be mined — SAP, Oracle, Tally, a ticketing system, or a spreadsheet.

Four rows from a real-shaped event log for one purchase order.

Three columns — case, activity, timestamp — and the journey falls out. Nothing else in those rows is required.

Your systems have been writing this log for years whether or not anyone reads it. It is the only record of what actually happened that nobody edited afterwards.

A log is only as honest as the moment the stamp is written. If an approval is entered in bulk on Friday for work done all week, the log shows one Friday spike and the real waiting time is invisible. Backdated entries are the single most common reason a mined duration is wrong.

Backdated and batched entries

Approvals keyed in weekly, GRNs entered at month end, POs raised after the invoice arrives. Each one moves a timestamp away from the event, and the delay in between simply stops existing in the data.

Dropping the rows that look wrong

Cases that skipped a step or ran out of order are usually the finding, not the dirty data. Filtering them out produces a clean map of a process nobody actually follows.

Assuming one system holds it all

Work that happens over email, on site or in a spreadsheet leaves no stamp. It shows up as one long unexplained wait — which is itself worth knowing, as long as it is read that way.

Crestline builds the event log from your ERP's own tables rather than asking you to produce one. The mapping from your field names to case, activity and timestamp is agreed once, then the log rebuilds itself on every sync.