“ERP Kami Mencatat Semuanya”: Kenapa Itu Bukan Audit Trail

The myth: timestamps and user IDs equal an audit trailMitosnya: timestamp dan user ID sudah sama dengan audit trail

The belief is understandable. Modern ERP and EAM platforms keep detailed technical records: when a record was created, which account created it and, where change logging is switched on, which fields changed along with their old and new values. To a system administrator, that looks like complete traceability.Keyakinan ini wajar. Platform ERP dan EAM modern menyimpan catatan teknis yang rinci: kapan record dibuat, akun mana yang membuatnya, dan, jika change logging aktif, field apa yang berubah beserta nilai lama dan barunya. Dari kacamata system administrator, itu sudah terlihat seperti traceability yang lengkap.

An audit trail, in the sense auditors use the term, is more than a record of events. It is a record of decisions that can be followed from start to finish: who asked, what was checked, who approved, on what basis, and what changed afterwards. A system log captures the last step of that chain. The earlier steps tend to happen in email, spreadsheets, chat messages and phone calls, and many of them never reach the ERP at all.Padahal, audit trail dalam pengertian auditor bukan sekadar catatan kejadian. Ia adalah rangkaian keputusan yang bisa ditelusuri dari awal sampai akhir: siapa yang meminta, apa yang dicek, siapa yang menyetujui, atas dasar apa, dan apa yang berubah setelahnya. System log hanya menangkap langkah terakhir dari rangkaian itu. Langkah-langkah sebelumnya biasanya terjadi di email, spreadsheet, chat, dan telepon, dan banyak di antaranya tidak pernah masuk ke ERP sama sekali.

System log vs decision trailSystem log vs decision trail

It helps to give the two things separate names, because they are produced by different parts of the organisation and answer different questions.Ada baiknya keduanya diberi nama yang berbeda, karena dihasilkan oleh bagian organisasi yang berbeda dan menjawab pertanyaan yang berbeda pula. Di sini kita sebut decision trail untuk jejak keputusan di balik sebuah record.

Neither replaces the other. The system log shows that the posting happened. The decision trail shows that the posting was justified. An auditor testing master data controls usually needs both.Keduanya tidak saling menggantikan. System log menunjukkan bahwa posting terjadi. Decision trail menunjukkan bahwa posting itu memang layak dilakukan. Auditor yang menguji kontrol Material Master Data biasanya butuh keduanya.

What the ERP captures well, and what sits outside itYang dicatat ERP dengan baik, dan yang berada di luarnya

Credit where it is due: the ERP is good at what it was designed to do. Once a material record is posted, it can typically show the material number, the creation date and time, the account that posted it, the plant and storage location extensions, and every transaction that followed, from purchase orders and goods receipts to issues against work orders. Depending on configuration, it can also show field-level changes with before and after values.Kita perlu adil: ERP sangat baik dalam hal yang memang menjadi tugasnya. Begitu sebuah material diposting, ERP umumnya bisa menunjukkan nomor material, tanggal dan jam pembuatan, akun yang memposting, extension ke plant dan storage location, serta semua transaksi sesudahnya, mulai dari PO, goods receipt, sampai pengeluaran barang untuk work order. Tergantung konfigurasinya, ERP juga bisa menampilkan perubahan per field lengkap dengan nilai sebelum dan sesudahnya.

What it usually cannot show is everything that happened before someone pressed Save. Consider a request for a new mechanical seal. Before it became a material number, a planner described the need, perhaps in an email with a photo of a pump nameplate. Someone checked, or did not check, whether a matching item already existed. Someone decided the request was valid. Someone chose the noun, modifier and attributes. None of those steps is an ERP transaction, so none of them appear in its log.Yang biasanya tidak bisa ditunjukkan ERP adalah semua hal yang terjadi sebelum seseorang menekan tombol Save. Ambil contoh request untuk mechanical seal baru. Sebelum menjadi nomor material, seorang planner menjelaskan kebutuhannya, mungkin lewat email dengan foto nameplate pompa. Lalu ada yang mengecek, atau tidak mengecek, apakah item serupa sudah ada. Ada yang memutuskan request itu valid. Ada yang memilih noun, modifier, dan atributnya. Tidak satu pun dari langkah itu merupakan transaksi ERP, jadi tidak satu pun muncul di log-nya.

The gap matters because auditors, internal or external, tend to test controls, not only outcomes. A control over master data creation usually implies that requests are reviewed and approved before posting. If the only evidence available is the posting itself, the team ends up reconstructing the story from inboxes and chat history. That is slow, it depends on who still works there, and the result is rarely complete.Celah ini penting karena auditor, baik internal maupun eksternal, cenderung menguji kontrol, bukan hanya hasil akhirnya. Kontrol atas pembuatan Material Master Data biasanya mengandaikan bahwa request di-review dan di-approve sebelum posting. Kalau bukti yang tersedia hanya posting-nya, tim terpaksa menyusun ulang ceritanya dari inbox dan riwayat chat. Prosesnya lambat, bergantung pada siapa yang masih bekerja di sana, dan hasilnya jarang lengkap.

The shared-account problem: when SYSTEM_USER created the recordMasalah akun bersama: ketika SYSTEM_USER yang membuat record

The second gap is accountability. In many landscapes, material records do not come from a person typing into the ERP. They arrive through an interface, a batch upload, a middleware job or an integration account. The ERP faithfully records the account that executed the posting, and that account is often a generic one: SYSTEM_USER, INTERFACE, BATCH_01, or the login of a data team that loads records on behalf of others.Celah kedua menyangkut akuntabilitas. Di banyak landscape, record material tidak berasal dari orang yang mengetik langsung di ERP. Record masuk lewat interface, batch upload, job middleware, atau akun integrasi. ERP mencatat dengan setia akun yang menjalankan posting, dan akun itu sering kali bersifat generik: SYSTEM_USER, INTERFACE, BATCH_01, atau login tim data yang mengunggah record atas nama orang lain.

From the ERP's point of view, the entry is correct: SYSTEM_USER did post the record. From an auditor's point of view, the entry names no one. The accountable person, whether the planner who raised the need or the reviewer who approved it, is invisible. When several people share one login, the problem is the same even without an interface: the log points to a role or a team, not to an individual.Dari sisi ERP, entri itu benar: SYSTEM_USER memang yang memposting record tersebut. Dari sisi auditor, entri itu tidak menyebut siapa pun. Orang yang seharusnya bertanggung jawab, entah planner yang mengajukan kebutuhan atau reviewer yang menyetujuinya, tidak terlihat. Kalau satu login dipakai bersama oleh beberapa orang, masalahnya sama saja walaupun tanpa interface: log hanya menunjuk ke sebuah peran atau tim, bukan ke individu.

Generic and shared accounts are a familiar topic in IT general controls reviews precisely because they weaken the link between an action and an individual. Fixing it purely inside the ERP, for example by issuing a named posting account to every requester, is often impractical for integration-heavy landscapes. And even a named account would only tell you who pressed Save, not why the item was needed.Akun generik dan akun bersama adalah topik yang cukup sering muncul dalam review IT general controls, justru karena akun seperti ini melemahkan hubungan antara sebuah aksi dan individunya. Membereskannya murni di dalam ERP, misalnya dengan memberi akun posting atas nama setiap requester, sering kali tidak praktis untuk landscape yang banyak integrasinya. Lagi pula, akun atas nama pun hanya memberi tahu siapa yang menekan Save, bukan kenapa item itu dibutuhkan.

Amendments that overwrite the originalAmendment yang menimpa deskripsi asli

The third gap tends to appear months later. A description is corrected, an attribute is added, a unit of measure is changed. Many ERPs can log field-level changes, but logging is configurable, and coverage is not always what the team assumes. Long texts, classification values, or records changed through mass maintenance tools may fall outside what is actually being logged in your system.Celah ketiga biasanya baru muncul beberapa bulan kemudian. Deskripsi dikoreksi, atribut ditambahkan, unit of measure diganti. Banyak ERP bisa mencatat perubahan per field, tetapi logging itu bisa dikonfigurasi, dan cakupannya tidak selalu seperti yang dibayangkan tim. Long text, nilai klasifikasi, atau record yang diubah lewat tools mass maintenance bisa saja berada di luar apa yang benar-benar tercatat di sistem Anda.

Even where old and new values are captured, the reason is not. A change from “SEAL, MECHANICAL” to “SEAL, MECHANICAL, CARTRIDGE 45MM” might be a legitimate correction. It might also quietly turn one item into another so it can be reused for a different pump. The log shows the edit. It does not show whether anyone checked that the item still means the same thing as the parts already sitting in the bin.Kalaupun nilai lama dan baru tercatat, alasannya tetap tidak. Perubahan dari “SEAL, MECHANICAL” menjadi “SEAL, MECHANICAL, CARTRIDGE 45MM” bisa saja koreksi yang sah. Tapi bisa juga diam-diam mengubah satu item menjadi item lain supaya kodenya bisa dipakai untuk pompa yang berbeda. Log memperlihatkan editnya, tetapi tidak memperlihatkan apakah ada yang mengecek bahwa item itu masih sama artinya dengan part yang sudah ada di bin.

This is where audit conversations become uncomfortable. If the description changed, did the physical parts in stock change too? Were open purchase orders still valid against the new description? Who decided the change was safe? Without a recorded reason and approval, the honest answer is often “we would need to ask around.”Di titik inilah percakapan dengan auditor mulai tidak nyaman. Kalau deskripsinya berubah, apakah part fisik di gudang juga berubah? Apakah PO yang masih terbuka tetap sesuai dengan deskripsi baru? Siapa yang memutuskan bahwa perubahan itu aman? Tanpa alasan dan approval yang tercatat, jawaban jujurnya sering kali: “Kami harus tanya-tanya dulu.”

An upstream gate before the ERPGerbang di hulu, sebelum data masuk ERP

If the decision trail is created before posting, the natural place to capture it is before posting. That is the idea behind an upstream gate: a governed step where requests are submitted, screened and approved, and where each decision is recorded with a name, a time and a reason before anything reaches the ERP.Kalau decision trail terbentuk sebelum posting, tempat paling masuk akal untuk menangkapnya juga sebelum posting. Itulah gagasan di balik gerbang di hulu: satu tahap yang dikelola, tempat request diajukan, di-screening, dan di-approve, dan setiap keputusan dicatat lengkap dengan nama, waktu, dan alasannya sebelum apa pun masuk ke ERP.

At Panemu, this gate is ANSI, our Master Data Governance web app (not to be confused with the American National Standards Institute). ANSI is designed to help decide what is allowed into the ERP, giving requests, screening and approvals a defined workflow so the reasoning is recorded where the decision happens. SCS^® supports the data side, preparing and standardising descriptions and attributes so that what passes the gate follows an agreed naming convention.Di Panemu, gerbang itu adalah ANSI, web app Master Data Governance kami (bukan American National Standards Institute). ANSI dirancang untuk membantu memutuskan data apa yang boleh masuk ke ERP, dengan memberi request, screening, dan approval sebuah workflow yang jelas, sehingga alasan di balik keputusan tercatat tepat di tempat keputusan itu dibuat. SCS^® mendukung sisi datanya: menyiapkan dan menstandarkan deskripsi serta atribut, supaya data yang lolos gerbang mengikuti naming convention yang sudah disepakati.

Notice what this does to the SYSTEM_USER problem. The posting account can stay generic, because accountability no longer depends on it. The request record behind the posting holds the named requester, the screening result and the approver. When an auditor asks who created material 10045871, the answer can point to a person and a reason, not only to an account.Perhatikan dampaknya pada masalah SYSTEM_USER. Akun posting boleh tetap generik, karena akuntabilitas tidak lagi bergantung padanya. Record request di balik posting itulah yang menyimpan nama requester, hasil screening, dan approver. Saat auditor bertanya siapa yang membuat material 10045871, jawabannya bisa menunjuk ke orang dan alasan yang jelas, bukan hanya ke sebuah akun.

The same logic applies to amendments. A change to a description can pass through the gate as a change request with a reason and a reviewer, so the before-and-after values in the ERP log are matched by a recorded why. The ERP still shows what changed; the gate shows why it was allowed to change.Logika yang sama berlaku untuk amendment. Perubahan deskripsi bisa melewati gerbang sebagai change request, lengkap dengan alasan dan reviewer-nya, sehingga nilai sebelum dan sesudah di log ERP punya pasangan berupa alasan yang tercatat. ERP tetap menunjukkan apa yang berubah; gerbang di hulu menunjukkan kenapa perubahan itu diizinkan.

The ERP stays the system of recordERP tetap menjadi system of record

None of this is a criticism of the ERP. It should remain the system of record for material master data: the place where the official item, its stock, its transactions and its financial value live. Moving that role elsewhere would create a different, and larger, problem.Semua ini bukan kritik terhadap ERP. ERP sebaiknya tetap menjadi system of record untuk Material Master Data: tempat item resmi, stok, transaksi, dan nilai finansialnya berada. Memindahkan peran itu ke sistem lain justru akan menciptakan masalah baru yang lebih besar.

The point is narrower. The ERP records the outcome of a decision; the decision itself needs a home. Capturing the decision trail before posting lets each system do what it does best: the governance layer explains why, and the ERP records what. Together they give auditors a chain they can follow without anyone digging through old inboxes.Intinya lebih sederhana. ERP mencatat hasil dari sebuah keputusan; keputusannya sendiri butuh tempat. Dengan menangkap decision trail sebelum posting, setiap sistem bisa fokus pada keahliannya: lapisan governance menjelaskan kenapa, ERP mencatat apa. Keduanya memberi auditor rangkaian bukti yang bisa ditelusuri tanpa harus ada yang membongkar email lama.

For IT and ERP owners, this also changes the conversation with auditors. Instead of defending the change log as something it was never designed to be, you can present two complementary sources of evidence, each fit for its purpose. That is usually an easier conversation, and a more honest one.Bagi tim IT dan pemilik ERP, ini juga mengubah cara berdiskusi dengan auditor. Daripada membela change log sebagai sesuatu yang memang tidak dirancang untuk itu, Anda bisa menunjukkan dua sumber bukti yang saling melengkapi, masing-masing sesuai fungsinya. Diskusinya biasanya jadi lebih mudah, dan lebih jujur.

Questions to raise with your team this quarterPertanyaan untuk dibahas bersama tim kuartal ini

1. For a sample of recently created items, can we show the original request and its reason?Untuk sampel item yang baru dibuat, bisakah kita menunjukkan request awal beserta alasannya?
2. Which accounts post material records, and how many of them are generic or shared?Akun mana saja yang memposting record material, dan berapa yang generik atau dipakai bersama?
3. Which fields, texts and classification values are covered by change logging, and which are not?Field, text, dan nilai klasifikasi mana yang tercakup change logging, dan mana yang tidak?
4. Where do approvals for new items and amendments live today, and who can retrieve them?Di mana approval untuk item baru dan amendment disimpan saat ini, dan siapa yang bisa mengambilnya?
5. Could we answer an audit question about a single item without searching through inboxes?Bisakah kita menjawab pertanyaan audit tentang satu item tanpa harus menyisir inbox?

Key TakeawaysPoin Penting