記錄(logging)這件事在中大型應用系統中，是非常重要的一環，它可以重現資料變動的前後狀況，以及是誰去動了資料，如何動資料等等，除了作為財務部門稽核的基本資料外，也是一種保護自己的證據。
在像是掌管銷售，物流或是金融的系統中，稽核 (audit) 這件事可是無比的重要，稽核作業可以判斷特定的流程是否正確的執行（請注意，是正確），該交換的資料，修改的資料以及活動日誌等是否都有跡可循，這些資料在日後會有一定的機率用來證明系統是沒有問題的。
因為在系統推展的過程中，總是會有部份的使用者對系統是抱持不信任態度（MIS 講的 TPB 理論中的抗拒因素之一），每次都對系統產出的報表或數字抱持懷疑或否定的態度，而當開發人員檢視系統後又發現流程是正常的時候，該使用者就會開始講一堆推託之詞，此時如果想要證明是使用者自己的操作出問題時，唯一可以作為跡證的，就只有放在系統中的記錄機能 (logging mechanism) 了，因此如果系統是運作在這種高度商業資訊或是使用者不信任的環境中時，記錄的能力就非常重要了。
好的記錄機能可以將下列動作記錄下來（其中紅字是必定要記的）：
- 使用者操作程序。
- 使用者提交的資料。
- 異動前的資料。
- 異動後的資料。
- 何時異動。
- 異動的人是誰。
- 異動的方式為何。
舉個例來說，以物流管理系統為例，在大多數情況下，收貨的那一端的數字應該要和出貨一樣，但總會有一些人為因素或其他問題而導致數字不對，最常發生的爭議莫過於庫存數字 (stock quantity) 了，此時如果系統中沒有這樣子的記錄檔的話，那麼系統管理人員等於是沒有任何保障，只能夠乖乖被使用者鞭。但如果有了記錄檔，那麼情況可能就會大不相同，因為管理人員可以由記錄檔回溯到某些時間點，來驗證庫存數字的正確性，也許是之前就不正確了，或是在之後發生了什麼事（例如收退貨）造成數字變動，這些只能透過記錄檔的方式來得到。
例如，在系統的出貨模組中，在每次出貨變更時，記錄數量的異動：
<changeItem productID="1023" paperQty="1" acceptQty="1" preQty="9" afterQty="8" />
- productID: 商品代碼。
- paperQty: 出貨單上的數量。
- acceptQty: 實際出去的數量。
- preQty: 異動前庫存數。
- afterQty: 異動後數量。
同樣的，在收貨模組中同樣有這樣的記錄。如果某一天發生爭議時，可以利用小程式或是 SQL 指令來調出這些資料，並且比對它的正確性，藉以證明系統本身是無問題的。
這個概念也可以用在很多對外的系統中，主要都是要證明系統執行流程是正確無誤的。而稽核需求的不同，記錄的方式，內容與格式也會有所差異，像是做 Hosting 的記錄檔應該會是效能以及 downtime 等等，而網路服務的記錄檔則會是服務時間，中斷時間以及流量等等，可以作為客戶詢問或內部管理時用來佐證用的資料。
因此，如果你做的是需要財務或是會計稽核的應用系統時，請務必一定要做好記錄的工作，否則到時就算系統沒有問題，面對使用者的質疑也只能啞吧吃黃蓮，有苦說不出啊 ...
