Computer-Assisted Audit Tools and Techniques

Tugas Mata Kuliah

Auditing EDP

Oleh :
Anisa Tus Saidah 150810301008
Alifiera Putri Afifah 150810301028
Diah Wahyuni 150810301131
Putri Qutsiyah Sari 150810301155

Program Studi S1 Akuntansi

Fakultas Ekonomi dan Bisnis
Universitas Jember
2018
 PENDAHULUAN

Resume ini membahas mengenai Computer-Assisted Audit Tools and

Techniques, hal ini adalah setiap penggunaan teknologi informasi sebagai alat bantu
dalam kegiatan audit. Teknik audit ini digunakan auditor dalam mengumpulkan data
akuntansi untuk menguji pengendalian aplikasi dan dalam melakukan uji substantif.
Computer-Assisted Audit Tools and Techniques sering digunakan oleh auditor karena
mampu mempermudah mengerjakan tugas dari auditor itu sendiri.

PEMBAHASAN

KONTROL APLIKASI
Kontrol aplikasi adalah prosedur yang dirancang untuk menghadapi ancaman
luar dari aplikasi yang mengancam aplikasi tersebut. Seperti halnya sistem penggajian,
pembelian, dan pengeluaran uang tunai. Kontrol aplikasi ini dibagi menjadi tiga kontrol
yaitu kontrol input, kontrol pemrosesan, dan kontrol output.
Kontrol Input
Kontrol input merupakan komponen pengumpulan data dari sistem informasi yang
bertanggung jawab untuk membawa data ke dalam sistem untuk diproses. Kontrol
input pada tahap ini dirancang untuk memastikan bahwa transaksi ini valid, akurat, dan
lengkap. Prosedur dalam input data dapat berupa sumber dokumen yang dipicu atau
input langsung yang meng-input sumber dokumen hal itu memerlukan keterlibatan
manusia dan sering terjadi kesalahan administrasi. Beberapa jenis kesalahan yang
dimasukkan pada sumber dokumen tidak dapat dideteksi dan diperbaiki selama tahap
input data. Hal itu akan berurusan dengan masalah ini, untuk mencegah hal ini
mungkin memerlukan pelacakan transaksi kembali ke sumbernya seperti menghubungi
pelanggan untuk memperbaiki kesalahan.
 Jenis Kontrol Input
Dalam jenis kontrol input ini dibagi menjadi beberapa jenis yaitu:
1. Sumber Pengendalian Dokumen.
2. Pengkodean Data
3. Kontrol Batch
4. Kontrol Validasi
5. Pengoreksian Kesalahan.
6. Sistem Input Data Umum.
Sumber Pengendalian Dokumen. Pengendalian yang hati-hati harus dilakukan
terhadap sumber dokumen fisik dalam sistem yang menggunakannya untuk memulai
transaksi. Penipuan terhadap sumber dokumen dapat digunakan untuk menghapus
aset dari organisasi. Misalnya, seorang individu dengan mengakses pesanan
pembelian dan menerima laporan hal itu dapat membuat transaksi pembelian ke
pemasok yang tidak kompeten. Jika dokumen-dokumen ini dimasukkan ke dalam
aliran pemrosesan data, bersama dengan faktur vendor yang dibuat maka sistem
dapat memproses dokumen-dokumen ini seolah-olah transaksi yang sah itu telah
terjadi. Dengan tidak adanya kontrol kompensasi lain untuk mendeteksi jenis penipuan
ini, sistem akan membuat akun hutang dan selanjutnya menulis cek dalam
pembayaran.
Gunakan Dokumen Sumber yang telah Diberi Nomor Sebelumnya. Dokumen sumber
harus diberi nomor dari printer dengan nomor urut unik pada setiap dokumen. Nomor
dokumen sumber memungkinkan pembukuan yang akurat atas penggunaan dokumen
dan memberikan jejak audit untuk transaksi penelusuran melalui catatan akuntansi.
Gunakan Dokumen Sumber dalam Urutan. Dokumen sumber harus didistribusikan
kepada pengguna dan digunakan secara berurutan. Ini mensyaratkan bahwa
keamanan fisik yang memadai menjadi utama atas persediaan dokumen sumber di
situs pengguna. Saat tidak digunakan, dokumen harus dikunci. Setiap saat, akses ke
dokumen sumber harus dibatasi untuk orang yang berwenang.
Secara Berkala Dokumen Sumber Audit. Rekonsiliasi nomor urut dokumen harus
mengidentifikasi dokumen sumber yang hilang.
Kontrol Pengkodean Data. Kontrol pengkodean adalah memeriksa integritas kode data
yang digunakan dalam pemrosesan. Nomor akun pelanggan, nomor barang inventaris,
dan bagan nomor akun adalah contoh kode data. Tiga jenis kesalahan dapat merusak
kode data dan menyebabkan kesalahan pemrosesan: kesalahan transkripsi, kesalahan
transposisi tunggal, dan beberapa kesalahan transposisi.
Kesalahan transkripsi jatuh ke dalam tiga kelas yaitu :
1. Kesalahan tambahan terjadi ketika digit atau karakter tambahan ditambahkan
ke kode. Contoh jumlah item persediaan 83276 dicatat sebagai 832766.
2. Kesalahan pemotongan terjadi ketika angka dihapus dari akhir kode. Dalam
jenis kesalahan ini maka item persediaan akan dicatat sebagai 8327.
3. Kesalahan subtitusi adalah penggantian satu digit dalam kode dengan yang
lain. Misalnya nomor item persediaan 83276 dicatat sebagai 832766.
Periksa Digit. Salah satu metode untuk mendeteksi kesalahan pengkodean data
adalah mengecek digit. Periksa digit adalah digit kontrol (atau digit) yang ditambahkan
ke kode ketika awalnya ditetapkan yang memungkinkan integritas kode yang akan
dibuat selama pemrosesan berikutnya. Digit cek dapat ditemukan di mana saja dalam
kode: sebagai awalan, akhiran, atau tempat yang disematkan di tengah. Bentuk cek
digit yang paling sederhana adalah menjumlahkan digit dalam kode dan menggunakan
jumlah ini sebagai digit cek. Misalnya, untuk kode akun pelanggan 5372, digit cek yang
dihitung akan menjadi
5 +3 +7+2 =17
Dengan menjatuhkan kolom puluhan, angka cek 7 ditambahkan ke kode asli untuk
menghasilkan kode baru 53727. Seluruh string digit (termasuk digit cek) menjadi
nomor akun pelanggan. Selama entri data, sistem digit untuk memastikan bahwa kode
sudah benar. Teknik ini hanya akan mendeteksi kesalahan transkripsi.
Kapan Harus Memeriksa Digit Digunakan?. Penggunaan check digit memperkenalkan
penyimpanan dan pemrosesan in-efisiensi dan karenanya harus dibatasi untuk data
penting, seperti bidang kunci primer dan sekunder. Semua teknik cek digit
membutuhkan satu atau lebih ruang tambahan di lapangan untuk mengakomodasi digit
cek. Dalam kasus modulus 11, jika langkah ketiga di atas menghasilkan sisa 1, digit
cek 10 akan membutuhkan dua ruang karakter tambahan. Jika panjang bidang
merupakan perpanjangan, salah satu cara menangani masalah ini adalah untuk
melarang kode yang menghasilkan digit cek 10. Ini akan membatasi jangkauan kode
yang tersedia sekitar 9 persen.
Kontrol Batch. Kontrol batch adalah metode yang efektif untuk mengelola volume tinggi
data transaksi melalui suatu sistem. Tujuan pengendalian ini output yang dihasilkan
oleh sistem dengan input yang awalnya dimasukkan ke dalam sistem. Ini memberikan
jaminan bahwa :
1. Semua catatan dalam batch diproses.
2. Tidak ada catatan yang diproses lebih dari satu kali
3. Jejak audit transaksi dibuat dari input melalui pemrosesan ke tahap output dari
sistem.
Kontrol batch tidak secara eksklusif merupakan teknik kontrol input. Mengontrol terus
berlanjut melalui semua fase sistem. Dalam mencapai tujuan pengendalian batch
membutuhkan pengelompokan jenis transaksi input yang serupa (seperti pesanan
penjualan) bersama-sama dalam batch dan kemudian mengisi batch di seluruh
pemrosesan data. Dua dokumen digunakan untuk menyelesaikan tugas ini yaitu
lembar transmittal batch dan log kontrol batch.
Hash Total. Istilah hash total, yang digunakan dalam diskusi sebelumnya, mengacu
pada teknik kontrol sederhana yang menggunakan data non-finansial untuk melacak
rekaman dalam batch.
Kontrol Validasi. Kontraksi input validasi dimaksudkan untuk mendeteksi kesalahan
dalam data transaksi sebelum data diproses. Prosedur validasi paling efektif ketika
dilakukan sedekat mungkin dengan sumber transaksi. Namun, tergantung pada jenis
teknologi yang digunakan, validasi input dapat terjadi pada berbagai titik dalam sistem.
Sebagai contoh, beberapa prosedur validasi memerlukan pembuatan referensi
terhadap file master saat ini. Sistem yang menggunakan pemrosesan real-time atau
pemrosesan batch dengan file master akses langsung dapat memvalidasi data pada
tahap input. Jika sistem menggunakan pemrosesan batch dengan file sekuensial,
catatan transaksi yang divalidasi harus terlebih dahulu diurutkan dalam urutan yang
sama dengan file master. Berurusan dengan transaksi yang selesai sebagian akan
memerlukan prosedur penanganan kesalahan khusus.
Interogasi Lapangan. Interogasi lapangan melibatkan prosedur yang diprogram yang
menggambarkan karakteristik data di lapangan. Berikut ini adalah beberapa jenis
interogasi lapangan yang umum.
Pengecekan data yang tidak ada digunakan untuk memeriksa isi dari suatu
bidang untuk keberadaan ruang kosong. Beberapa bahasa pemrograman bersifat
membatasi untuk pembenaran (kanan atau kiri) data dalam bidang tersebut. Jika data
tidak dibenarkan dengan benar atau jika karakter hilang (telah diganti dengan kosong),
nilai dalam bidang akan diproses secara tidak benar. Dalam beberapa kasus,
kehadiran kosong dalam bidang data numerik dapat menyebabkan kegagalan sistem.
Ketika program validasi mendeteksi kosong di mana ia mengharapkan untuk melihat
nilai data, ini akan ditafsirkan sebagai kesalahan.
Pemeriksaan data numerik-alfabetik menentukan apakah bentuk data yang
benar ada dalam suatu bidang. Misalnya, saldo akun pelanggan tidak boleh berisi data
abjad. Seperti kosong, data abjad dalam bidang angka dapat menyebabkan kesalahan
pemrosesan yang serius.
Pemeriksaan nilai nol digunakan untuk memverifikasi bahwa bidang-bidang
tertentu diisi dengan nol. Beberapa bahasa program mengharuskan bidang yang
digunakan dalam operasi matematika dimulai dengan nol sebelum diproses. Kontrol ini
dapat memicu kontrol koreksi otomatis untuk mengganti isi bidang dengan nol jika
mendeteksi nilai bukan nol.
Batasi pemeriksaan menentukan apakah nilai di lapangan melebihi batas yang
diizinkan. Sebagai contoh, asumsikan kebijakan perusahaan adalah bahwa tidak ada
karyawan yang bekerja lebih dari 44 jam per minggu.
Rentang pemeriksaan menetapkan batas atas dan bawah ke nilai data yang
dapat diterima. Misalnya, jika kisaran tingkat pembayaran untuk karyawan per jam
dalam perusahaan adalah antara 8 dan 20 dolar, semua catatan penggajian dapat
diperiksa untuk melihat bahwa rentang ini tidak terlampaui. Tujuan dari kontrol ini
adalah untuk mendeteksi kesalahan keystroke yang menggeser titik desimal satu atau
lebih banyak tempat. Itu tidak akan mendeteksi kesalahan di mana tingkat pembayaran
yang benar, katakanlah, 9 dolar salah dimasukkan sebagai 15 dolar.
Pemeriksaan validitas membandingkan nilai aktual dalam bidang terhadap nilai
yang dapat diterima yang diketahui. Kontrol ini digunakan untuk memverifikasi hal-hal
seperti kode transaksi, singkatan negara, kode pekerjaan karyawan.
Rekam Interogasi. Rekam prosedur interogasi memvalidasi seluruh catatan dengan
memeriksa keterkaitan nilai-nilai bidangnya. Beberapa tes tipikal dibahas di bawah ini :
Pemeriksaan masuk akal menentukan apakah suatu nilai dalam satu bidang,
yang telah melewati pemeriksaan batas dan pemeriksaan rentang, masuk akal bila
dipertimbangkan bersama dengan bidang data lain dalam catatan. Misalnya, tingkat
gaji karyawan sebesar 18 dolar per jam berada dalam kisaran yang dapat diterima.
Namun, tingkat ini berlebihan jika dibandingkan dengan kode keterampilan kerja
karyawan sebesar 693; karyawan di kelas keterampilan ini tidak pernah menghasilkan
lebih dari 12 dolar per jam.
Tanda cek adalah tes untuk melihat apakah tanda bidang sudah benar untuk
jenis rekaman yang sedang diproses. Misalnya, dalam sistem pemrosesan pesanan
penjualan, bidang jumlah dolar harus positif untuk pesanan penjualan tetapi negatif
untuk transaksi penjualan kembali. Kontrol ini dapat menentukan kebenaran tanda
dengan membandingkannya dengan bidang kode transaksi.
Pemeriksaan urutan digunakan untuk menentukan apakah suatu catatan tidak
sesuai pesanan. Dalam sistem batch yang menggunakan file master berurutan, file
transaksi yang sedang diproses harus diurutkan dalam urutan yang sama dengan
kunci primer dari file master yang sesuai. Persyaratan ini sangat penting untuk logika
pemrosesan program pembaruan. Oleh karena itu, sebelum setiap catatan transaksi
diproses, urutannya diverifikasi relatif terhadap catatan sebelumnya yang diproses.
Interogasi File. Tujuan dari interogasi file adalah untuk memastikan bahwa file yang
benar sedang diproses oleh sistem. Kontrol ini sangat penting untuk file induk, yang
berisi catatan permanen dari perusahaan dan yang jika rusak tidak dapat diganti.
Pemeriksaan label internal memverifikasi bahwa file yang diproses adalah yang
sebenarnya diminta oleh program. File yang disimpan pada pita magnetic biasanya
disimpan secara off-line di perpustakaan. File-file ini memiliki label eksternal yang
mengidentifikasi mereka (berdasarkan nama dan nomor seri) ke tape librarian dan
operator. Pelabelan eksternal biasanya merupakan prosedur manal dan seperti halnya
tugas manual, rentan terhadap kesalahan. Kadang-kadang, label eksternal yang salah
ditempelkan ke file ketika dibuat. Jadi, ketika file dipanggil lagi, file yang salah akan
diambil dan ditempatkan pada tape drive untuk diproses. Tergantung pada bagaimana
file tersebut digunakan, ini dapat menyebabkan penghancuran. Untuk mencegah hal
ini, sistem operasi membuat label header internal yang ditempatkan di awal file.
Pemeriksaan versi digunakan untuk memverifikasi bahwa versi file yang
sedang diproses sudah benar. Dalam pendekatan kakek-nenek-anak, banyak versi file
master dan transaksi mungkin ada. Pemeriksaan versi membandingkan nomor versi
file yang sedang diproses dengan persyaratan program.
Pemeriksaan tanggal kedaluarsa dalam sistem GPC misalnya, setelah nomor
file cadangan yang memadai dibuat, file cadangan tertua tergores (terhapus dari disk
atau pita) untuk menyediakan ruang bagi file baru. Panjang periode retensi ditentukan
oleh programer dan berdasarkan jumlah file cadangan yang diinginkan.
Pengoreksian Kesalahan Input. Ketika kesalahan terdeteksi dalam batch, mereka
harus dikoreksi dan catatan dikirim kembali untuk diproses ulang. Ini harus menjadi
proses yang terkontrol untuk memastikan bahwa kesalahan ditangani sepenuhnya dan
benar. Ada tiga teknik penanganan kesalahan umum: (1) benar segera, (2) membuat
file kesalahan, dan (3) menolak seluruh batch.
Segera Koreksi. Setelah mendeteksi kesalahan penekanan tombol atau hubungan
tidak logis, sistem harus menghentikan prosedur entri data sampai pengguna
memperbaiki kesalahan.
Buat File Kesalahan. Ketika validasi tertunda digunakan, seperti dalam sistem batch
dengan file sekuensial, kesalahan individual harus ditandai untuk mencegah mereka
diproses. Pada akhir prosedur validasi, catatan ditandai sebagai kesalahan dihapus
dari batch dan ditempatkan dalam file memegang kesalahan sementara sampai
kesalahan dapat diselidiki. Beberapa kesalahan dapat dideteksi selama prosedur input
data.
Tolak Batch. Beberapa bentuk kesalahan terkait dengan seluruh kelompok dan tidak
secara jelas disebabkan oleh catatan individu. Contoh dari jenis kesalahan ini adalah
ketidakseimbangan dalam total kontrol batch. Asumsikan bahwa lembar pengiriman
untuk batch pesanan penjualan menunjukkan nilai penjualan total $122.674,87, tetapi
prosedur input data menghitung total penjualan hanya $121,454,32. Apa yang
menyebabkan ini? Apakah masalah itu adalah catatan yang hilang atau berubah? Atau
apakah petugas kontrol data salah menghitung total kontrol batch. Solusi yang paling
efektif dalam hal ini adalah menghentikan pemrosesan dan mengembalikan seluruh
batch ke kontrol data untuk mengevaluasi, mengoreksi, dan mengirim ulang. Batch
kesalahan adalah salah satu alasan untuk menjaga ukuran batch ke nomor yang dapat
dikelola. Terlalu sedikit catatan dalam batch membuat pemrosesan batch tidak efisien.
Terlalu banyak record membuat deteksi kesalahan menjadi sulit, menciptakan
gangguan bisnis yang lebih besar ketika batch ditolak dan, dan meningkatkan
kemungkinan kesalahan saat menghitung total kontrol batch.
Sistem Input Data Umum. Untuk mencapai tingkat kontrol dan standarisasi yang tinggi
terhadap prosedur validasi input, beberapa organisasi menggunakan sistem input data
umum (GDIS). Teknik ini mencakup prosedur terpusat untuk mengelola input data
untuk semua sistem pemrosesan transaksi organisasi. Pendekatan GDIS memiliki tiga
keunggulan. Pertama, meningkatkan kontrol dengan memiliki satu sistem umum
melakukan semua validasi data. Kedua, GDIS memastikan bahwa setiap aplikasi AIS
menerapkan standar konsisten untuk validasi data. Ketiga, GDIS meningkatkan
efisiensi pengembangan sistem. Mengingat tingginya tingkat kesamaan dalam
persyaratan validasi input untuk aplikasi AIS, GDIS menghilangkan kebutuhan untuk
membuat ulang rutinitas berlebihan untuk setiap aplikasi baru. GDIS memiliki lima
komponen utama:
1. Modul validasi umum
2. File data yang divalidasi
3. File kesalahan
4. Laporan kesalahan
5. Log transaksi.

Modul Validasi Umum. Modul validasi umum (GVM) melakukan rutin validasi standar
yang umum untuk banyak aplikasi yang berbeda. Rutinitas ini disesuaikan dengan
kebutuhan aplikasi individu melalui parameter yang menentukan persyaratan spesifik
program. Misalnya, GVM dapat menerapkan pemeriksaan rentang ke bidang TARIF
PER JAM catatan penggajian. Batas kisarannya adalah 6 dolar dan 15 dolar. Uji
jangkauan adalah prosedur umum; batas dolar adalah parameter yang menyesuaikan
prosedur ini. Prosedur validasi untuk beberapa aplikasi mungkin sangat unik untuk
menentang solusi umum. Untuk memenuhi tujuan dari sistem input data umum, GVM
harus cukup fleksibel untuk memungkinkan prosedur khusus yang ditentukan
pengguna untuk aplikasi unik. Prosedur ini disimpan, bersama dengan prosedur
umum, dan diminta oleh GVM sesuai kebutuhan.
 File Data yang Divalidasi. Data input yang divalidasi oleh GVM disimpan
pada file data yang divalidasi. Ini adalah file holding sementara melalui
transaksi dimana divalidasi mengalir ke aplikasi masing-masing. File ini
analog dengan tangki air yang tingkatnya terus berubah, karena diisi dari
atas oleh GVM dan dikosongkan dari bawah oleh aplikasi.
 File Kesalahan. File kesalahan dalam GDIS memainkan peran yang sama
sebagai file kesalahan tradisional. Catatan kesalahan terdeteksi selama
validasi disimpan dalam file, dikoreksi, dan kemudian dikirim kembali ke
GVM.
 Laporan Eror. Laporan kesalahan standar didistribusikan kepada pengguna
untuk memfasilitasi koreksi kesalahan. Misalnya, jika bidang TARIF PER
JAM dalam catatan pembayaran gagal pemeriksaan rentang, laporan
kesalahan akan menampilkan pesan kesalahan yang menyatakan masalah
itu. Laporan ini juga akan menyajikan isi dari catatan yang gagal, bersama
dengan batas jangkauan yang dapat diterima yang diambil dari parameter.
 Log Transaksi. Log transaksi adalah catatan permanen dari semua
transaksi yang divalidasi. Dari sudut pandang catatan akuntansi, log
transaksi setara dengan jurnal dan merupakan elemen penting dalam jejak
audit. Namun, hanya transaksi yang berhasil (yang akan diproses
sepenuhnya) yang harus dimasukkan dalam jurnal.

Kontrol Proses
Setelah melewati tahap input data, transaksi memasuki tahap pemrosesan sistem.
Kontrol pemrosesan dibagi menjadi tiga kategori, kontrol run-to-run, kontrol intervensi
operator, dan kontrol jejak audit.
 Kontrol Run-to-Run
Sebelumnya, kami membahas persiapan figur kontrol batch sebagai elemen kontrol
input. Kontrol run-to-run menggunakan angka batch untuk memantau batch saat
bergera dari satu prosedur terprogram (dijalankan) ke yang lain. Kontrol ini
memastikan bahwa setiap run dalam sistem memproses batch dengan benar dan
lengkap. Angka-angka kontrol batch dapat terkandung dalam record kontrol terpisah
yang dibuat pada tahap input data atau label internal. Penggunaan spesifik dari angka
kontrol run-to-run dijelaskan dalam paragraph berikut.
Hitung Ulang Total Kontrol. Setelah setiap operasi besar dalam proses dan setelah
setiap run, bidang jumlah dolar, total hash, dan jumlah catatan diakumulasi dan
dibandingkan dengan nilai-nilai terkait yang disimpan dalam catatan kontrol. Jika
catatan dalam kelompok hilang, tidak diproses, atau diproses lebih dari satu kali, ini
akan diungkapkan oleh perbedaan antara angka-angka ini.
Kode Transaksi. Kode transaksi setiap record dalam batch dibandingkan
dengan kode transaksi yang terkandung dalam catatan kontrol. Ini memastikan bahwa
hanya jenis transaksi yang benar sedang diproses.
Cek Berurutan. Dalam sistem yang menggunakan file master berurutan,
urutan catatan transaksi dalam batch sangat penting untuk memperbaiki dan
menyelesaikan pemrosesan. Saat batch bergerak melalui proses, ia harus ditempatkan
dalam urutan file master yang digunakan di setiap run. Kontrol pengecekan urutan
membandingkan urutan setiap record dalam batch dengan catatan sebelumnya untuk
memastikan bahwa penyortiran yang tepat terjadi. Gambar 7.10 menjelaskan
penggunaan kontrol run-to-run dalam sistem siklus pendapatan. Aplikasi ini terdiri dari
empat jalur. (1) input data, (2)pembaruan piutang, (3) pembaruan inventaris, dan (4)
output. Pada akhir dari proses penerimaan piutang, angka kontrol batch dihitung ulang
dan direkonsiliasi dengan total kontrol yang dilewatkan dari input data yang dijalankan.
Angka-angka ini kemudian diteruskan ke pembaruan inventaris berjalan, di mana
mereka kembali dihitung ulang, direkonsiliasi, dan diteruskan ke output run. Kesalahan
yang terdeteksi di setiap run ditandai dan ditempatkan dalam file kesalahan. Angka-
angka kontrol run-to-run (batch) kemudian disesuaikan untuk mencerminkan
penghapusan catatan-catatan ini.
 Kontrol Intervensi Operator
Sistem terkadang memerlukan intervensi operator untuk memulai tindakan tertentu
seperti memasukkan total kontrol untuk sekumpulan rekaman, memberikan nilai
parameter untuk operasi logis, dan mengaktifkan program dari titik yang berbeda ketika
masuk kembali catatan kesalahan yang diproses secara semi. Intervensi operator
meningkatkan potensi kesalahan manusia. Sistem yang membatasi intervensi operator
melalui kontrol intervensi operator dengan demikian kurang rentan terhadap kesalahan
pemrosesan. Meskipun mungkin mustahil untuk menghilangkan keterlibatan operator
sepenuhnya, nilai parameter dan titik awal program harus sedapat mungkin diturunkan
secara logis atau diberikan kepada sistem melalui tabel pencarian.
Kontrol Jejak Audit
Pelestarian jejak audit adalah tujuan penting dari pengendalian proses. Dalam
sistem akuntansi, setiap transaksi harus dapat dilacak melalui setiap tahap
pemrosesan dari sumber ekonomi hingga penyajiannya dalam laporan keuangan.
Dalam lingkungan otomatis, jejak audit dapat menjadi terfragmentasi dan sulit untuk
diikuti. Dengan demikian menjadi penting bahwa setiap operasi besar yang diterapkan
pada transaksi didokumentasikan secara menyeluruh. Berikut ini adalah contoh teknik
yang digunakan untuk mempertahankan jejak audit dalam sistem akuntansi berbasis
komputer.
Log Transaksi. Setiap transaksi yang berhasil diproses oleh sistem harus
dicatat pada log transaksi, yang berfungsi sebagai jurnal. Gambar 7.11 menunjukkan
pengaturan ini. Ada dua alasan untuk membuat log transaksi. Pertama, log transaksi
adalah catatan transaksi permanen. File transaksi yang divalidasi yang dihasilkan pada
fase input data biasanya adalah file sementara. Setelah diproses, catatan pada file ini
dihapus (tergores) untuk member ruang bagi batch transaksi berikutnya. Kedua, tidak
semua catatan dalam file transaksi yang divalidasi dapat berhasil diproses. Beberapa
catatan ini mngkin gagal tes dalam tahap pemrosesan berikutnya. Log transaksi hanya
boleh berisi transaksi yang berhasil-yang telah mengubah saldo akun. Transaksi yang
tidak berhasil harus ditempatkan dalam file kesalahan. Log transaksi dan file kesalahan
digabungkan harus memperhitungkan semua transaksi dalam batch. File transaksi
yang divalidasi kemudian dapat tergores tanpa kehilangan data. Sistem harus
menghasilkan daftar transaksi hard copy dari semua transaksi yang berhasil. Daftar ini
harus diberikan kepada pengguna yang sesuai untuk memfasilitasi reonsiliasi dengan
masukan.
 Log Transaksi Otomatis. Beberapa transaksi dipicu secara internal oleh sistem.
Contohnya adalah ketika persediaan turun di bawah titik penyetelan ulang yang telah
ditetapkan, dan sistem secara otomatis memproses pesanan pembelian. Untuk
mempertahankan jejak audit dari kegiatan ini, semua transaksi yang dihasilkan secara
internal harus ditempatkan dalam log transaksi.
Pencatatan Transaksi Otomatis. Untuk mempertahankan kendali atas transaksi
otomatis yang diproses oleh sistem, pengguna akhir yang bertanggung jawab harus
menerima daftar terperinci dari semua transaksi yang dihasilkan secara internal.
Pengidentifikasi Transaksi Unik. Setiap transaksi yang diproses oleh sistem
harus diidentifikasi secara unik dengan nomor transaksi. Ini adalah satu-satunya cara
praktis untuk melacak transaksi tertentu melalui database ribuan atau bahkan jutaan
catatan. Dalam sistem yang menggunakan dokumen sumber fisik, nomor unik yang
tercetak pada dokumen dapat ditranskripsikan selama input data dan digunakan untuk
tujuan ini. Dalam sistem real-time, yang tidak menggunakan dokumen sumber, sistem
harus menetapkan setiap transaksi nomor unik.
Daftar Kesalahan. Daftar semua catatan kesalahan harus diberikan kepada
pengguna yang sesuai untuk mendukung koreksi kesalahan dan resubmission.
Kontrol Output
Kontrol memastikan bahwa output sistem tidak hilang, salah arah, atau
terputus-putus dan privasi itu tidak dilanggar. Eksposur semacam ini dapat
menyebabkan gangguan serius pada operasi dan dapat mengakibatkan kerugian
finansial bagi perusahaan. Misalnya, jika cek yang dihasilkan oleh sistem pencairan
tunai perusahaan hilang, salah arah, atau dirusak, rekening perdagangan dan tagihan
lainnya mungkin tidak terbayar, ini dapat merusak peringkat kredit perusahaan dan
mengakibatkan diskon, bunga atau denda penalti yang hilang. Jika privasi jenis output
tertentu dilanggar, perusahaan dapat memiliki tujuan bisnisnya yang terkompromi, atau
bahkan dapat diekspos secara hukum.
 Mengendalikan Sistem Batch Output
Sistem batch biasanya menghasilkan output dalam bentuk hard copy, yang biasanya
membutuhkan keterlibatan perantara dalam produksi dan distribusinya. Output
dikeluarkan dari printer oleh operator komputer, dipisahkan menjadi lembaran dan
dipisahkan dari laporan lain, ditinjau untuk kebenaran oleh petugas kontrol data, dan
kemudian dikirim melalui surat antar kantor kepada pengguna akhir. Setiap tahap
dalam proses ini adalah titik paparan potensial di mana output dapat ditinjau, dicuri,
disalin, atau salah arah. Eksposur tambahan terjadi ketika memproses atau mencetak
salah dan menghasilkan output yang tidak dapat diterima oleh pengguna akhir.
Laporan-laporan yang rusak atau sebagian rusak ini sering dibuang di tempat sampah.
Penjahat komputer telah berhasil menggunakan limbah tersebut untuk mencapai
tujuan terlarang mereka. Setelah itu, kami memeriksa teknik untuk mengontrol setiap
fase dalam proses output. Perlu diingat bahwa tidak semua teknik ini akan selalu
berlaku untuk setiap item yang dihasilkan oleh sistem. Seperti biasa, kontrol digunakan
berdasarkan biaya-manfaat yang ditentukan oleh sensitivitas data dalam laporan.
Spooling keluaran. Dalam operasi pemrosesan data skala besar, perangkat output
seperti printer garis dapat menjadi buntu dengan banyak program sekaligus menuntut
sumber daya yang terbatas ini. Backlog ini dapat menyebabkan kemacetan, yang
berdampak buruk pada throughput sistem. Aplikasi yang menunggu untuk mencetak
output menempati memori komputer dan memblokir aplikasi lain agar tidak memasuki
aliran pemrosesan. Untuk meringankan beban ini, aplikasi sering dirancang untuk
mengarahkan output mereka ke fil disk magnetik daripada ke printer secara langsung.
Ini disebut spooling output. Kemudian, ketika sumber daya printer tersedia, file output
dicetak.
Program Cetak. Ketika printer menjadi tersedia, program print run menghasilkan output
hard copy dari file output. Program cetak seringkali merupakan sistem rumit yang
memerlukan intervensi operator. Empat jenis tindakan operator yang umum adalah:
1. Menghentikan program cetak untuk memuat jenis dokumen output yang benar
(periksa stok, faktur, atau formulir khusus lainnya).
2. Memasukkan parameter yang dibutuhkan oleh hasil cetak, seperti jumlah salinan
yang akan dicetak.
3. Memulai kembali proses cetak di pos pemeriksaan yang ditentukan setelah
kegagalan fungsi printer.
4. Menghapus hasil cetak dari printer untuk diperiksa dan didistribusikan.

Ledakan. Ketika laporan output dihapus dari printer, mereka pergi ke tahap burst untuk
memisahkan halaman dan menyusunnya. Kekhawatiran di sini adalah bahwa petugas
yang meledak dapat membuat salinan laporan yang tidak sah, menghapus halaman
dari laporan, atau membaca informasi sensitif. Kontrol utama terhadap pemaparan ini
adalah pengawasan. Untuk laporan yang sangat sensitif, peledakan dapat dilakukan
oleh pengguna akhir.
Limbah. Output limbah komputer merepresentasikan paparan potensial adalah penting
untuk membuang laporan yang dibatalkan dan salinan karbon dari kertas multipartai
yang dilepaskan selama meledak dengan benar. Penjahat komputer telah dikenal
untuk menyaring melalui tong sampah mencari keluaran yang dibuang sembarangan
yang dianggap oleh orang lain tidak berharga. Dari seperti sampah, penjahat komputer
dapat memperoleh sepotong kunci informasi tentang riset pasar perusahaan, peringkat
kredit pelanggannya, atau bahkan rahasia dagang yang dapat mereka jual ke pesaing.
Sampah komputer juga merupakan sumber data teknis, seperti tabel kata sandi dan
otoritas, yang dapat digunakan pelaku untuk mengakses file data perusahaan.
Melewati mesin penghancur kertas dapat dengan mudah menghancurkan output
komputer yang sensitif.
Kontrol Data. Di beberapa organisasi, kelompok kontrol data bertanggung jawab untuk
memastikan akurasi output komputer sebelum didistribusikan kepada pengguna.
Biasanya, petugas kontrol data akan meninjau angka kontrol batch untuk
keseimbangan; memeriksa badan laporan untuk data yang kacau, tidak terbaca, dan
hilang, dan mencatat penerimaan laporan dalam kontrol data log kontrol batch. Untuk
laporan yang berisi data yang sangat sensitif, pengguna akhir dapat melakukan tugas-
tugas ini. Dalam hal ini, laporan akan melewati grup kontrol data dan langsung menuju
ke pengguna.
Distribusi Laporan. Risiko utama yang terkait dengan distribusi laporan termasuk
laporan yang hilang, dicuri, atau salah arah dalam perjalanan ke pengguna. Sejumlah
kontrol pengukuran dapat meminimalkan eksposur ini. Misalnya, ketika laporan dibuat,
nama dan alamat pengguna harus dicetak pada laporan. Untuk laporan multikopi, file
alamat pengguna yang sah harus dikonsultasikan untuk mengidentifikasi setiap
penerima laporan. Mempertahankan kontrol akses yang memadai atas file ini menjadi
sangat penting. Jika seorang individu yang tidak sah dapat menambahkan namanya ke
daftar pengguna yang berwenang, dia akan menerima salinan laporan.
Kontrol Pengguna Akhir. Setelah berada di tangan pengguna, laporan output harus
ditinjau kembali untuk setiap kesalahan yang mungkin telah menghindari tinjauan
panitera kontrol data. Pengguna berada dalam posisi yang jauh lebih baik untuk
mengidentifikasi kesalahan halus dalam laporan yang tidak diungkapkan oleh
ketidakseimbangan dalam total kontrol. Kesalahan yang dideteksi oleh pengguna
harus dilaporkan ke manajemen layanan komputer yang sesuai. Kesalahan semacam
itu mungkin merupakan gejala dari desain sistem yang tidak benar, prosedur yang
salah, kesalahan yang dimasukkan oleh kecelakaan selama pemeliharaan sistem, atau
akses tidak sah ke file data atau program.
 Mengontrol Output Sistem Real-Time
Sistem real-time mengarahkan output mereka ke layar komputer pengguna, terminal,
atau printer. Ancaman utama ke output real-time adalah intersepsi, gangguan,
penghancuran, atau korupsi dari pesan output saat melewati link komunikasi. Ancaman
ini berasal dari dua jenis eksposur: (1) exposures dari kerusakan peralatan dan (2)
eksposur dari tindakan subversif, di mana kriminal komputer memotong pesan keluar
yang ditransmisikan antara pengirim dan penerima.

APLIKASI PENGENDALIAN PENGUJIAN KOMPUTER

Bagian ini membahas beberapa teknik untuk mengaudit aplikasi komputer. Teknik
kontrol memberikan informasi tentang akurasi dan kelengkapan proses aplikasi.
Pendekatan Black-Box
Auditor menguji dengan pendekatan black-box tidak bergantung pada pengetahuan
detail dari logika internal aplikasi. Sebaliknya, mereka berusaha memahami
karakteristik fungsional dari aplikasi dengan menganalisis flowcharts dan wawancara
personel berpengetahuan dalam organisasi klien. Dengan pemahaman tentang apa
aplikasi yang seharusnya dilakukan, auditor menguji aplikasi dengan mendamaikan
produksi input transaksi yang diproses oleh aplikasi dengan hasil keluaran.
White-Box Approach
Pendekatan white-box bergantung pada pemahaman mendalam tentang logika internal
aplikasi yang sedang diuji. Pendekatan kotak-putih mencakup beberapa teknik untuk
menguji logika aplikasi secara langsung. Teknik ini menggunakan sejumlah kecil
transaksi uji yang dibuat secara khusus untuk memverifikasi aspek tertentu dari logika
dan kontrol aplikasi. Dengan cara ini, auditor mampu melakukan tes yang tepat,
dengan variabel yang dikenal dan memperoleh hasil akhir yang dapat dibandingkan
dengan hasil yang dihitung secara obyektif. Beberapa jenis tes yang lebih umum dari
kontrol termasuk yang berikut: tes keaslian, tes akurasi, tes kelengkapan, uji
redundansi, tes akses, tes jejak audit, Uji kesalahan pembulatan
Gambar 7.15 menunjukkan logika untuk menangani masalah kesalahan
pembulatan. Teknik ini menggunakan akumulator untuk melacak perbedaan
pembulatan antara saldo dihitung dan dilaporkan. Perhatikan bagaimana tanda dan
nilai absolut dari jumlah dalam akumulator menentukan bagaimana akun pelanggan
dipengaruhi oleh pembulatan. Menggambarkan, Logika pembulatan diterapkan pada
Tabel 7.1 hingga tiga saldo bank hipotetis. Perhitungan bunga didasarkan pada tingkat
bunga 5,25 persen.
 Kegagalan untuk memperhitungkan secara tepat perbedaan pembulatan ini dapat
mengakibatkan ketidakseimbangan antara jumlah total (kontrol) bunga dan jumlah
perhitungan bunga individu untuk setiap akun. Akuntansi yang buruk untuk pembulatan
perbedaan juga bisa menghadirkan peluang untuk penipuan.

Program pembulatan sangat rentan terhadap penipuan salami. Penipuan Salami

cenderung mempengaruhi sejumlah besar korban, tetapi kerusakannya tidak material.
Jenis penipuan ini mengambil namanya dari analogi pemotongan salami besar (tujuan
penipuan) menjadi banyak potongan tipis. Setiap korban mengasumsikan salah satu
dari potongan-potongan kecil ini dan tidak sadar ditipu. Misalnya, seorang programmer,
atau seseorang dengan akses ke yang sebelumnya pembulatan program, dapat
melakukan penipuan salami dengan memodifikasi logika pembulatan sebagai berikut:
pada titik dalam proses di mana algoritma harus meningkatkan akun pelanggan (yaitu,
nilai akumulator adalah > +.01), program malah menambahkan satu sen ke akun lain
akun pelaku. Meskipun jumlah absolut dari setiap transaksi penipuan kecil, mengingat
ribuan akun diproses, jumlah total penipuan dapat menjadi signifikan dari waktu ke
waktu.
 Jejak audit sistem operasi dan perangkat lunak audit dapat mendeteksi aktivitas file
yang berlebihan. Dalam kasus penipuan salami, akan ada ribuan entri ke akun pribadi
kriminal komputer yang mungkin terdeteksi dengan cara ini. Seorang programmer
pintar dapat menyamarkan aktivitas ini dengan menyalurkan entri-entri ini melalui
beberapa akun sementara menengah, yang kemudian diposting ke sejumlah kecil akun
perantara dan akhirnya ke akun pribadi pemrogram. Dengan menggunakan banyak
level akun dengan cara ini, aktivitas ke akun mana pun berkurang dan mungkin tidak
terdeteksi oleh perangkat lunak audit. Akan ada jejak, tetapi bisa rumit. Auditor yang
ahli juga dapat menggunakan perangkat lunak audit untuk mendeteksi keberadaan
akun perantara yang tidak sah yang digunakan dalam penipuan semacam itu.

ALAT AUDIT DAN ALAT TEKNIK KOMPUTER UNTUK PENGUJIAN PENGUJIAN

Untuk mengilustrasikan cara kontrol aplikasi diuji, bagian ini menjelaskan lima
pendekatan CAATT: metode pengujian, yang meliputi evaluasi dan penelusuran sistem
alas kasus, fasilitas pengujian terintegrasi, dan simulasi paralel.

Metode Uji Data

Metode data uji digunakan untuk membangun integritas aplikasi dengan

memproses set data input yang disiapkan secara khusus melalui aplikasi produksi
yang sedang ditinjau. Hasil setiap tes dibandingkan dengan harapan yang telah
ditentukan untuk mendapatkan evaluasi yang obyektif dari logika aplikasi dan
efektivitas pengendalian. Teknik data uji diilustrasikan pada Gambar 7.16. Untuk
melakukan teknik data uji, auditor harus mendapatkan salinan dari versi aplikasi saat
ini. Selain itu, uji file transaksi dan file master uji harus dibuat. Sebagai inustrated pada
gambar, transaksi tes dapat memasuki sistem dari pita magnetik, disk, atau melalui
terminal input. Hasil dari uji coba akan berupa laporan keluaran rutin, daftar transaksi,
dan laporan kesalahan. Selain itu, auditor harus meninjau file induk yang diperbarui
untuk menentukan bahwa saldo akun telah diperbarui dengan benar. Hasil tes
kemudian dengan hasil yang diharapkan auditor untuk menentukan apakah aplikasi
berfungsi dengan benar. Perbandingan ini dapat dilakukan secara manual atau melalui
perangkat lunak komputer khusus.

Gambar 7.17 daftar bidang yang dipilih untuk transaksi hipotetis dan catatan
piutang yang disiapkan oleh auditor untuk menguji aplikasi pemrosesan pesanan
penjualan. Angka tersebut juga menunjukkan laporan kesalahan transaksi ditolak dan
daftar file master piutang yang diperbarui. Setiap penyimpangan antara hasil aktual
yang diperoleh dan yang diharapkan oleh auditor dapat menunjukkan masalah logika
atau control.

Membuat Data Uji

Saat membuat data uji, auditor harus menyiapkan satu set lengkap dari
transaksi yang valid dan tidak valid. Jika data uji tidak lengkap, auditor mungkin gagal
untuk memeriksa cabang kritis logika aplikasi dan rutinitas pengecekan kesalahan. Uji
transaksi harus menguji setiap kesalahan input yang mungkin, proses logis, dan
ketidakteraturan.

Mendapatkan pengetahuan tentang logika internal aplikasi yang cukup untuk

membuat data pengujian yang berarti sering membutuhkan investasi waktu yang
besar. Namun, efisiensi tugas ini dapat ditingkatkan melalui perencanaan yang matang
selama pengembangan sistem. Auditor harus menyimpan data uji yang digunakan
untuk menguji modul program selama fase implementasi SDLC untuk penggunaan di
masa mendatang. Jika aplikasi tidak mengalami pemeliharaan sejak implementasi
awal, hasil tes audit saat ini harus sama dengan hasil tes yang diperoleh pada saat
implementasi. Namun, jika aplikasi telah dimodifikasi, auditor dapat membuat data uji
tambahan yang fokus pada bidang perubahan program.

Evaluasi Sistem Basis Kasus

Ada beberapa varian dari teknik data uji. Ketika rangkaian data uji yang
digunakan bersifat komprehensif, teknik ini disebut evaluasi sistem base case (BCSE).
Tes BCSE dilakukan dengan serangkaian transaksi pengujian yang berisi semua jenis
transaksi yang mungkin. Ini diproses melalui iterasi berulang selama pengujian
pengembangan sistem hingga hasil yang konsisten dan valid diperoleh. Hasil ini
adalah kasus dasar. Ketika perubahan berikutnya pada aplikasi terjadi selama
pemeliharaan, efeknya dievaluasi dengan membandingkan hasil saat ini dengan hasil
kasus dasar.

Tracing

Tipe lain dari teknik data uji yang disebut tracing melakukan walkthrough
elektronik dari logika internal aplikasi. Prosedur pelacakan melibatkan tiga langkah:

1. Aplikasi yang sedang diperiksa harus menjalani kompilasi khusus untuk

mengaktifkan opsi jejak.

2. Transaksi khusus atau jenis transaksi dibuat sebagai data uji.

3. Transaksi data uji dilacak melalui semua tahapan pemrosesan program, dan
daftar dihasilkan dari semua instruksi terprogram yang dilaksanakan selama
pengujian.
 Menerapkan penelusuran membutuhkan pemahaman rinci tentang logika internal
aplikasi. Gambar 7.18 mengilustrasikan proses pelacakan menggunakan sebagian dari
logika untuk aplikasi penggajian. Contoh ini menunjukkan catatan dari dua file
penggajian-catatan transaksi menunjukkan jam kerja dan dua catatan dari file master
yang menunjukkan tingkat pembayaran. Daftar jejak di bagian bawah Gambar 7.18
mengidentifikasi pernyataan program yang dieksekusi dan urutan eksekusi. Analisis
opsi jejak menunjukkan bahwa Perintah 0001 hingga 0020 dieksekusi. Pada saat itu,
aplikasi ditransfer ke Command 0060. Ini terjadi karena nomor karyawan (kunci) dari
catatan transaksi tidak sesuai dengan kunci dari catatan pertama dalam file master.
Kemudian Perintah 0010 hingga 0050 dieksekusi.

`Keuntungan Teknik Uji Data

Ada tiga keunggulan utama teknik data uji. Pertama, mereka menggunakan
pengujian komputer, sehingga menyediakan auditor dengan bukti eksplisit mengenai
fungsi aplikasi. Kedua, jika direncanakan dengan benar, uji coba data dapat digunakan
hanya dengan gangguan minimal terhadap operasi organisasi. Ketiga, mereka hanya
membutuhkan keahlian komputer minimal di pihak auditor.

Kekurangan Uji Teknik Data

Kerugian utama dari semua teknik data uji adalah bahwa auditor harus
bergantung pada personel layanan komputer untuk mendapatkan salinan aplikasi
untuk tujuan pengujian. Ini memerlukan risiko bahwa layanan komputer dapat secara
sengaja atau tidak sengaja memberikan auditor sedikit pun salah versi aplikasi dan
dapat mengurangi keandalan bukti audit. Secara umum, bukti audit yang dikumpulkan
oleh sarana independen lebih dapat diandalkan daripada bukti yang diberikan oleh
klien.

Kerugian kedua dari teknik ini adalah bahwa mereka memberikan gambaran
statis tentang integritas aplikasi pada satu titik waktu. Mereka tidak menyediakan
sarana yang nyaman untuk mengumpulkan bukti tentang fungsionalitas aplikasi yang
sedang berlangsung. Tidak ada bukti bahwa aplikasi yang sedang diuji hari ini
berfungsi seperti selama tahun yang diuji.

Kerugian ketiga dari teknik data uji adalah biaya pelaksanaannya yang relatif
tinggi, yang mengakibatkan inefisiensi dalam audit. Auditor dapat mencurahkan banyak
waktu untuk memahami logika program dan membuat data uji. Pada bagian
berikutnya, kita melihat bagaimana teknik pengujian otomatis dapat menyelesaikan
masalah ini.

Fasilitas Uji Terpadu

Pendekatan fasilitas uji terpadu (ITF) adalah teknik otomatis yang

memungkinkan auditor menguji logika dan kontrol aplikasi selama operasi normal. ITF
adalah satu atau lebih modul audit yang dirancang ke dalam aplikasi selama sistem
proses pengembangan. Selain itu, database ITF berisi "dummy" atau uji catatan file
induk yang terintegrasi dengan catatan yang sah. Beberapa perusahaan menciptakan
perusahaan dummy untuk transaksi yang diposting. Selama operasi normal, transaksi
pengujian digabung menjadi aliran transaksi reguler (produksi) dan diproses terhadap
file perusahaan boneka. Gambar 7.19 mengilustrasikan konsep ITF.

Modul audit HEF dirancang untuk membedakan antara transaksi ITF dan data
produksi rutin. Ini dapat dilakukan dengan berbagai cara. Salah satu yang paling
sederhana dan paling umum digunakan adalah menetapkan rentang unik nilai-nilai
kunci secara eksklusif untuk transaksi ITF. Misalnya, dalam sistem pemrosesan
pesanan penjualan, nomor akun antara tahun 2000 dan 2100 dapat dipesan untuk
transaksi ITF dan tidak akan ditetapkan ke akun pelanggan yang sebenarnya. Dengan
memisahkan transaksi ITF dari transaksi yang sah dengan cara ini, laporan rutin yang
dihasilkan oleh aplikasi tidak rusak oleh data uji ITF. Hasil pengujian diproduksi secara
terpisah pada media penyimpanan atau output cetak dan didistribusikan langsung ke
auditor. Sama seperti dengan teknik data uji, auditor menganalisis hasil ITF terhadap
hasil yang diharapkan.

Keuntungan dari IT

Teknik ITF memiliki dua keunggulan dibandingkan teknik data uji. Pertama, ITF
mendukung pemantauan kontrol berkelanjutan seperti yang dipersyaratkan oleh SAS
78. Kedua, aplikasi dengan ITF dapat diuji secara ekonomis tanpa mengganggu
operasi pengguna dan tanpa campur tangan personel layanan komputer. Dengan
demikian, ITF meningkatkan efisiensi audit dan meningkatkan keandalan bukti audit
yang dikumpulkan.

Kerugian ITF

Kerugian utama ITF adalah potensi untuk merusak file data organisasi dengan
data uji. Langkah-langkah harus diambil untuk memastikan bahwa transaksi pengujian
ITF tidak mempengaruhi secara material laporan keuangan dengan secara tidak benar
digabungkan dengan transaksi yang sah. Masalah ini diperbaiki dalam dua cara: (1)
menyesuaikan entri dapat diproses untuk menghapus efek ITF dari saldo akun buku
besar umum atau (2) file data dapat dipindai oleh perangkat lunak khusus yang
menghapus transaksi ITF.

Simulasi Paralel

Paralel simulasi mengharuskan auditor untuk menulis program yang

mensimulasikan fitur utama atau proses aplikasi yang sedang ditinjau. Aplikasi simulasi
kemudian digunakan untuk memproses kembali transaksi yang sebelumnya diproses
oleh aplikasi produksi. Teknik ini diilustrasikan pada Gambar 7.20. Hasil yang diperoleh
dari simulasi direkonsiliasi dengan hasil produksi asli berjalan untuk menetapkan dasar
untuk membuat inferensi tentang kualitas proses aplikasi dan kontrol.

Membuat Program Simulasi.

Program simulasi dapat ditulis dalam bahasa pemrograman apa pun. Namun,
karena sifat satu kali dari tugas ini, itu adalah kandidat untuk generator bahasa
generasi keempat. Langkah-langkah yang terlibat dalam melakukan pengujian simulasi
paralel diuraikan di sini.

1. Auditor harus terlebih dahulu mendapatkan pemahaman menyeluruh tentang

aplikasi yang sedang ditinjau. Dokumentasi lengkap dan terkini dari aplikasi
diperlukan untuk membangun simulasi yang akurat.

2. Auditor kemudian harus mengidentifikasi proses dan kontrol tersebut dalam

aplikasi yang sangat penting untuk audit. Ini adalah proses yang akan
disimulasikan.

3. Auditor menciptakan simulasi menggunakan 4GL atau perangkat lunak audit

umum (GAS).

4. Auditor menjalankan program simulasi menggunakan transaksi produksi yang

dipilih dan file master untuk menghasilkan serangkaian hasil.

5. Akhirnya, auditor mengevaluasi dan merekonsiliasi hasil tes dengan hasil

produksi yang dihasilkan dalam menjalankan sebelumnya.

6. Program simulasi biasanya kurang kompleks daripada aplikasi produksi yang

mereka wakili. Karena simulasi hanya berisi proses aplikasi, perhitungan, dan
kontrol yang relevan dengan tujuan audit tertentu, auditor harus hati-hati
mengevaluasi perbedaan antara hasil tes dan hasil produksi. Perbedaan hasil
output terjadi karena dua alasan: (1) kekasaran melekat program simulasi dan
(2) kekurangan nyata dalam proses aplikasi atau kontrol, yang dibuat jelas oleh
program simulasi.
 KESIMPULAN
Dari pembahasan diatas dapat disimpulkan bahwa Dalam jenis kontrol input ini
dibagi menjadi beberapa jenis yaitu : Sumber Pengendalian Dokumen, Pengkodean
Data, Kontrol Batch, Kontrol Validasi, Pengoreksian Kesalahan, dan Sistem Input Data
Umum. Sedangkan di dalam GDIS memiliki lima komponen utama yaitu : Modul
validasi umum, File data yang divalidasi, File kesalahan, Laporan kesalahan , Log
transaksi.
Empat jenis tindakan operator yang umum adalah: Menghentikan program
cetak untuk memuat jenis dokumen output yang benar (periksa stok, faktur, atau
formulir khusus lainnya), Memasukkan parameter yang dibutuhkan oleh hasil cetak,
seperti jumlah salinan yang akan dicetak, Memulai kembali proses cetak di pos
pemeriksaan yang ditentukan setelah kegagalan fungsi printer, Menghapus hasil cetak
dari printer untuk diperiksa dan didistribusikan, Untuk mengilustrasikan cara kontrol
aplikasi diuji, bagian ini menjelaskan lima pendekatan CAATT: metode pengujian, yang
meliputi evaluasi dan penelusuran sistem alas kasus, fasilitas pengujian terintegrasi,
dan simulasi paralel.

REFERENSI

James A. Hall. 2011. Information Technology Auditing and Assurance. Third edition,
Cengage Learning