Sebuah rekening vendor diperbarui pada sore hari. Keesokan paginya, pembayaran bernilai besar diproses ke rekening baru tersebut. Perubahan itu bisa sah karena vendor berpindah bank, tetapi waktu dan nilainya membuat transaksi layak diperiksa sebelum tim menyimpulkan apa pun.
Perubahan rekening vendor merupakan kejadian pada master data yang perlu memiliki bukti, otorisasi, dan jejak waktu. Analisis data membantu tim menemukan perubahan yang berdekatan dengan pembayaran, dilakukan berulang, atau mempunyai pola berbeda dari kebiasaan. Hasilnya adalah daftar prioritas pemeriksaan, bukan tuduhan terhadap vendor atau karyawan.
Mulai dari pertanyaan risiko yang jelas
Pertanyaan yang terlalu luas akan menghasilkan terlalu banyak alert. Tentukan skenario yang ingin dicari, misalnya rekening berubah beberapa hari sebelum pembayaran, satu pengguna mengubah banyak vendor, atau rekening lama dikembalikan setelah transaksi selesai.
Dalam audit master data vendor, definisi perubahan perlu mencakup nomor rekening, nama pemilik, bank, cabang, kode negara, metode pembayaran, dan status vendor sesuai struktur sistem. Tim juga perlu mengetahui apakah perubahan berasal dari antarmuka utama, integrasi, atau migrasi data.
Hubungkan log perubahan dengan transaksi
Data minimum biasanya meliputi identitas vendor, nilai lama dan baru, waktu perubahan, pengguna, sumber perubahan, waktu persetujuan, serta transaksi setelah perubahan. Analisis transaksi pembayaran kemudian menghubungkan catatan tersebut dengan invoice, jumlah, tanggal jatuh tempo, dan rekening tujuan.
Jangan hanya mengambil kondisi master data saat ini. Tanpa riwayat, tim tidak dapat mengetahui rekening mana yang aktif ketika pembayaran disiapkan. Monitoring perubahan data membutuhkan log yang mempertahankan siapa mengubah apa dan kapan perubahan terjadi.
Gunakan beberapa indikator sekaligus
Satu indikator jarang cukup. Rekening baru mungkin sah, pembayaran besar mungkin rutin, dan perubahan di luar jam kerja dapat terjadi karena perbedaan zona waktu. Risiko meningkat ketika beberapa kondisi muncul bersamaan.
Contohnya, perubahan dilakukan oleh pengguna yang jarang mengelola vendor, tidak mempunyai approval, terjadi menjelang pembayaran, lalu rekening dipakai oleh lebih dari satu vendor. Kombinasi ini lebih berguna untuk deteksi anomali pembayaran daripada aturan yang hanya melihat nilai transaksi.
Periksa rekening yang digunakan bersama
Analisis data vendor dapat mencari nomor rekening yang sama pada beberapa vendor, kemiripan nama pemilik, perubahan bolak balik, atau rekening yang pernah dinonaktifkan. Namun, hasil yang sama tidak otomatis salah. Perusahaan dalam satu grup, agen pembayaran, atau penyedia layanan bersama dapat mempunyai alasan yang sah.
Tambahkan atribut negara, grup perusahaan, kategori vendor, dan hubungan kepemilikan jika tersedia. Informasi tersebut membantu pemeriksa membedakan pola normal dari kondisi yang membutuhkan konfirmasi.
Nilai desain kontrol sebelum menilai orang
Kontrol perubahan rekening dapat mencakup pemisahan tugas, approval dua tingkat, verifikasi melalui kontak vendor yang sudah dikenal, pembatasan hak akses, dan periode tunggu sebelum rekening baru dipakai. Cara penerapannya bergantung pada risiko serta sistem perusahaan.
Jika pengguna yang sama dapat membuat vendor, mengubah rekening, dan memproses pembayaran, masalah pertama adalah desain akses. Pemeriksaan tidak boleh berhenti pada satu transaksi ketika kelemahan kontrol berlaku untuk populasi yang lebih luas.
Gunakan AI untuk membantu eksplorasi
AI Data Analytics dapat membantu pengguna merumuskan pertanyaan, menggabungkan sumber data yang telah diberi akses, mengelompokkan pola, serta menyarankan pengujian tambahan. AI juga dapat membantu menjelaskan mengapa suatu kasus berada pada urutan prioritas.
AI tidak mengetahui apakah perubahan sudah diverifikasi melalui telepon atau surat resmi jika bukti itu berada di luar data. Keputusan tetap memerlukan dokumen, konfirmasi, dan penilaian manusia.
Susun prioritas berdasarkan dampak dan bukti
Prioritas pemeriksaan audit dapat mempertimbangkan nilai pembayaran, jarak waktu dari perubahan, jumlah vendor yang berbagi rekening, hak akses pengguna, status approval, dan histori pengecualian. Bobot harus diuji agar tidak menghasilkan daftar yang didominasi satu indikator.
Tim perlu menilai false positive dan memperbaiki aturan. Jika terlalu banyak kasus sah terangkat, tambahkan konteks. Jika insiden penting terlewat, tinjau sumber data, rentang waktu, dan batas yang digunakan.
Jangan menyimpulkan fraud dari pola saja
Risiko fraud vendor perlu ditangani dengan hati hati. Pola data hanya menunjukkan kondisi yang perlu diperiksa. Bukti pendukung dapat berupa formulir perubahan, approval, konfirmasi vendor, histori komunikasi, kontrak, invoice, dan rekening penerima.
Simpan hasil pemeriksaan, alasan penutupan, serta perbaikan kontrol. Informasi tersebut membantu analisis berikutnya dan mencegah tim mengulang pemeriksaan yang sama tanpa alasan.
Pelajari solusi AI Data Analytics Actifficient untuk mengeksplorasi perubahan master data dan transaksi dari sumber yang berwenang. Jika tim Anda ingin menguji skenario ini menggunakan sampel yang aman, hubungi Actifficient untuk konsultasi. Siapkan struktur log, daftar vendor, data pembayaran, serta aturan approval agar ruang lingkup dapat dinilai dengan jelas.