COMPUTER - ASSISTED AUDIT TOOLS AND TECHNIQUES

(ALAT DAN TEKNIK AUDIT BERBANTUAN KOMPUTER)

Tugas Mata Kuliah

Auditing EDP

Oleh :

Citra Karunia P. 180810301225

Nike Ayu Fatmawati 180810301228
Q. Lisa Dwi Saputri 180810301230

Program studi Akuntansi

Fakultas Ekonomi dan Bisnis

Universitas Jember

2019
 BAB 1

PENDAHULUAN

1.1 Pendahuluan
Perkembangan dalam kemajuan teknologi informasi telah mengubah cara perusahaan
dalam mengumpulkan data, memproses dan melaporkan informasi keuangan. Oleh karena
itu auditor akan banyak menemukan lingkungan dimana data tersimpan lebih banyak dalam
media elektronik dibanding media kertas. Auditor harus menentukan bagaimana
perusahaan menggunakan sistem teknologi informasi untuk menginisiasi, mencatat,
memproses dan melaporkan transaksi dalam laporan keuangan.
Sebenarnya tidak ada perbedaan konsep audit yang berlaku untuk sistem yang komplek
dan sistem manual, yang berbeda hanya pada metode-metode spesifik yang cocok dengan
situasi sistem informasi akuntansi yang ada. Pemahaman ini diperlukan dalam rangka
mendapatkan pemahaman internal kontrol yang baik agar dapat merencanakan audit dan
menentukan sifat, waktu dan perluasan pengujian yang akan dilakukan.
Statement on Auditing Standar (AICPA) dan Standar Profesional Akuntan Publik (IAI)
juga mengatur masalah ini. Beberapa item dalam standar audit tersebut mengatur tata cara
audit dalam lingkungan sistem informasi berbasis computer. Pengaruh terbesar
penggunaan teknologi informasi sebagai perangkat yang digunakan oleh perusahaan untuk
menghasilkan informasi sebagai objek data diantaranya: yang pertama, perubahan bentuk
informasi sebagai bukti audit dari informasi yang menggunakan kertas (visual) menjadi
bentuk elektronik (non visual) yang tersimpan dalam media penyimpanan computer. Yang
kedua, perubahan bentuk bukti audit tersebut pada gilirannya juga mempengaruhi cara
memperoleh bukti audit dan cara mengevaluasi bukti audit yang telah diperoleh tersebut.
Yang ketiga, volume data yang tersimpan pada sebuah perusahaan, apalagi perusahaan
multinasional, misalnya telah mencapai ukuran yang sangat besar, yaitu mencapai
kapasitas terra byte, bahkan mungkin penta byte. Yang keempat, perubahan jejak audit,
yakni suatu mekanisme yang memungkinkan pelacakan kronologis suatu transaksi dari awal
sampai akhir ataupun sebaliknya. Dan yang terakhir, adanya perubahan struktur
pengendalian internal perusahaan, terutama yang berkaitan dengan pengolahan data.
 BAB II

PEMBAHASAN

2.1 Data Structures

A. Struktur Basis Data Relasional, Konsep, dan Terminologi
Database relasional didasarkan pada struktur file berurutan diindeks. Struktur ini,
diilustrasikan pada Gambar 8.10, menggunakan indeks bersama dengan sekuensial
organisasi file. Ini memfasilitasi baik akses langsung ke catatan individu dan
pemrosesan batch dari seluruh file. Beberapa indeks dapat digunakan untuk
membuat referensi silang, yang disebut daftar terbalik, yang memungkinkan akses
yang lebih fleksibel ke data. Dua indeks ditunjukkan pada Gambar 8.10. Satu berisi
nomor karyawan (kunci utama) untuk menemukan secara unik catatan dalam file.
Indeks kedua berisi alamat-alamat rekaman diatur oleh penghasilan tahun-ke-
tanggal. Menggunakan bidang nonunique ini sebagai kunci sekunder memungkinkan
semua catatan karyawan untuk dilihat dalam urutan menaik atau menurun sesuai
dengan penghasilan. Atau, catatan individu dengan saldo penghasilan yang dipilih
dapat ditampilkan. Indeks dapat dibuat untuk setiap atribut dalam file,
memungkinkan data untuk dilihat dari banyak perspektif.
Teori Relasional Database
E. P. Codd Awalnya memberikan prinsip-prinsip model relasional pada akhir 1960-
an. Model formal memiliki fondasinya dalam aljabar relasional dan teori himpunan,
yang memberikan dasar teoritis untuk sebagian besar operasi manipulasi data yang
digunakan. Dengan demikian, suatu sistem bersifat relasional jika:
1. Mewakili data dalam bentuk tabel dua dimensi.
2. Mendukung fungsi aljabar relasional pembatasan, proyek, dan bergabung.

B. Konsep Database Relasional

Entitas, Kejadian, dan Atribut
Entitas adalah sesuatu yang ingin organisasi ambil untuk menangkap data.
Entitas dapat berupa fisik, seperti persediaan, pelanggan, atau karyawan. Mereka
mungkin juga konseptual, seperti penjualan (ke pelanggan), piutang dagang (AR),
atau hutang CAP). Desainer sistem mengidentifikasi entitas dan menyiapkan
modelnya seperti yang disajikan pada Gambar 8.12. Model data ini adalah cetak biru
untuk akhirnya menciptakan database fisik. Representasi grafis yang digunakan
untuk menggambarkan model disebut diagram entitas hubungan (ER). Sebagai soal
konvensi, setiap entitas dalam model data diberi nama dalam bentuk kata benda
tunggal, seperti "Pelanggan" daripada "Pelanggan." Istilah kejadian digunakan untuk
menggambarkan jumlah contoh atau catatan yang berhubungan dengan entitas
tertentu. Sebagai contoh, jika suatu organisasi memiliki 100 karyawan, entitas
Karyawan dikatakan terdiri dari 100 kejadian. Atribut adalah elemen data yang
mendefinisikan entitas. Untuk contoh, entitas Pegawai dapat ditentukan oleh set
atribut parsial berikut: Nama, Alamat, Skill Pekerjaan, Masa Kerja, dan Tarif Per Jam
Bayar. Setiap kejadian dalam entitas Karyawan terdiri dari jenis atribut yang sama,
tetapi nilai dari masing-masing atribut akan bervariasi di antara kejadian-kejadian.
Karena atribut adalah karakteristik yang logis dan relevan dari suatu entitas, mereka
unik untuk itu. Dengan kata lain, atribut yang sama tidak boleh digunakan untuk
mendefinisikan dua entitas yang berbeda.

Asosiasi dan Kardinalitas

Garis berlabel yang menghubungkan dua entitas dalam model data
menggambarkan sifat dari hubungan di antara mereka. Asosiasi ini diwakili dengan
kata kerja, seperti kapal, permintaan, atau diterima. Keunikan adalah tingkat
hubungan antara dua entitas. Secara sederhana menyatakan, kardinalitas
menjelaskan jumlah kemungkinan kejadian dalam satu tabel yang terkait dengan
satu kejadian dalam tabel terkait. Empat bentuk dasar kardinalitas mungkin: nol atau
satu (0,1), satu dan hanya satu (1,1), nol atau banyak (0, N1), dan satu atau banyak
(l, M). Ini digabungkan untuk merepresentasikan asosiasi logis antar entitas. Nilai
kardinalitas atas di setiap ujung garis asosiasi mendefinisikan asosiasi. Sebagai
contoh, kardinalitas (0,1) pada satu ujung dan kardinalitas (1,1 \ 11) pada yang
lainnya adalah asosiasi (Lv)). Gambar 8.13 menyajikan beberapa contoh asosiasi
entitas, yang akan dibahas selanjutnya.
Contoh 1 (1: 1). Asumsikan bahwa sebuah perusahaan memiliki 1.000 karyawan,
tetapi hanya lOO dari mereka yang merupakan staf penjualan. Asumsikan bahwa
masing-masing tenaga penjual diberi mobil perusahaan, tetapi staf non-penjualan
tidak. Contoh 1 dalam Gambar 8.13 menunjukkan bahwa untuk setiap kejadian
(catatan) dalam entitas Karyawan, ada kemungkinan nol atau satu kejadian dalam
entitas Perusahaan Mobil.
C. Anomali, Dependensi Struktural, dan Normalisasi Data
Anomali Database
Jawaban atas pertanyaan di atas adalah tabel yang dinormalisasi dengan tidak
semestinya dapat menyebabkan masalah pemrosesan DBMS yang membatasi, atau
bahkan menolak, pengguna mengakses informasi yang mereka butuhkan. Tabel
semacam itu menunjukkan gejala operasional negatif yang disebut anomali. Secara
khusus, ini adalah anomali pembaruan, anomali penyisipan, dan anomali
penghapusan. Satu atau lebih dari anomali ini akan ada dalam tabel yang tidak
ternormalisasi atau busur dinormalisasi pada tingkat rendah, seperti bentuk normal
pertama (INF) atau bentuk normal kedua (2NF). Agar bebas dari anomali, tabel
harus dinormalisasi ke tingkat normal ketiga (3NF) level.
Perbarui Anomali. Anomali pembaruan hasil dari redundansi data dalam tidak
dikenalimeja. Untuk mengilustrasikan, perhatikan bahwa Pemasok Nomor 22
menyediakan masing-masing dari tiga item persediaan (BAGIAN NUM 1,2, dan 3)
ditunjukkan pada Gambar 8.16. Atribut data yang berkaitan dengan Pemasok Nomor
22 (NAMA, ALAMAT, dan TELE NUM) dengan demikian diulang dalam setiap
catatan setiap item persediaan yang diberikan oleh Pemasok Nomor 22. Setiap
perubahan dalam nama, alamat, atau nomor telepon pemasok harus dibuat untuk
setiap catatan ini dalam tabel. Dalam contoh, ini berarti tiga pembaruan berbeda.
Untuk lebih menghargai implikasi dari anomali pembaruan, pertimbangkan situasi
yang lebih realistis di mana vendor memasok 10.000 item inventaris yang berbeda.
Setiap pembaruan untuk atribut harus dibuat10.000 kali.
Penyisipan Anomali. Untuk menunjukkan efek dari anomali penyisipan, berasumsi
bahwa vendor baru telah memasuki pasar. Dokumen organisasi belum membeli dari
vendor, tetapi mungkin ingin melakukannya di masa depan. Sementara itu,
organisasi ingin menambahkan vendor ke database. Ini tidak mungkin, karena kunci
utama untuk tabel Inventory adalah PART NUM. Karena dokumen vendor tidak
memasok organisasi dengan item inventaris apa pun, data pemasok tidak dapat
ditambahkan ke tabel.
Penghapusan Anomali. Anomali penghapusan melibatkan penghapusan data yang
tidak disengaja dari meja. Untuk mengilustrasikan, asumsikan bahwa Pemasok
Nomor 27 menyediakan perusahaan hanya dengan satu item: Nomor Bagian 1. Jika
organisasi menghentikan item persediaan ini dan menghapusnya dari tabel, data
yang berkaitan dengan Pemasok Nomor 27 juga akan dihapus. Meskipun
perusahaan mungkin ingin mempertahankan informasi pemasok untuk penggunaan
di masa mendatang, desain tabel saat ini mencegahnya untuk melakukannya.
Kehadiran anomali penghapusan kurang mencolok, tetapi berpotensi lebih serius
daripada pembaruan dan penyisipan anomali. Desain basis data terlarang yang
mencegah penyisipan catatan atau mengharuskan pengguna untuk melakukan
pembaruan yang berlebihan, menarik perhatian dengan cepat. Anomali
penghapusan, bagaimanapun, mungkin tidak terdeteksi, membuat pengguna tidak
menyadari hilangnya data penting sampai terlambat. Hal ini dapat mengakibatkan
kehilangan yang tidak disengaja pada catatan akuntansi penting dan penghancuran
jejak audit. Oleh karena itu, desain meja bukan hanya masalah efisiensi operasional;
itu membawa signifikansi pengendalian internal yang perlu dikenali akuntan.

Auditor dan Normalisasi Data

Normalisasi database adalah masalah teknis yang biasanya menjadi tanggung
jawab para profesional sistem. Subjek, bagaimanapun, memiliki implikasi untuk
pengendalian internal yang membuatnya menjadi perhatian auditor juga. Sebagai
contoh, anomali pembaruan dapat menghasilkan nilai-nilai database yang
bertentangan dan usang, anomali penyisipan hasil Gill dalam transaksi yang tidak
tercatat dan jejak audit yang tidak lengkap, dan anomali penghapusan dapat
menyebabkan hilangnya catatan akuntansi dan penghancuran jejak audit. Meskipun
sebagian besar auditor tidak akan bertanggung jawab untuk normalisasi database
organisasi, mereka harus memiliki pemahaman tentang proses dan dapat
menentukan apakah tabel dinormalkan dengan benar.
Selanjutnya, auditor perlu mengetahui bagaimana data disusun sebelum dia atau
dia dapat mengekstrak data dari tabel untuk melakukan prosedur audit. Seperti yang
telah kita lihat, pengguna dilihat dari data yang sangat berbeda dari struktur
penyimpanan mereka. Sebagai contoh, tugas audit mengambil data yang berkaitan
dengan pandangan pengguna yang kompleks seperti pesanan pembelian akan
melibatkan mengidentifikasi dan mengakses beberapa tabel terkait. Hubungan yang
rumit ini diilustrasikan secara lebih rinci dalam bagian-bagian berikut ketika kami
memeriksa langkah-langkah yang terlibat dalam pembuatan bagian dari database
relasional perusahaan.
2.2 Designing Relational Database
Perancangan basis data adalah komponen dari proses pengembangan sistem yang
jauh lebih besar yang melibatkan analisis ekstensif terhadap kebutuhan pengguna. Jadi,
titik awal kami adalah salah satu yang biasanya mengikuti pekerjaan pendahuluan yang
cukup besar yang telah mengidentifikasi secara detail elemen-elemen kunci dari sistem
yang sedang dikembangkan. Dengan latar belakang ini, fokusnya akan berada pada
enam fase desain database berikut, yang secara kolektif dikenal sebagai pemodelan
tampilan:
1. Identifikasi entitas.
2. Buat model data yang menunjukkan asosiasi entitas.
3. Tambahkan kunci utama dan atribut ke model.
4. Normalisasikan model data dan tambahkan kunci asing.
5. Bangun database fisik.
6. Persiapkan pandangan pengguna.

Identifikasi Entitas
Pemodelan pandangan dimulai dengan mengidentifikasi entitas utama dari
fungsi bisnis yang dimaksud. Ingat bahwa entitas adalah hal-hal di mana organisasi
ingin menangkap data. Untuk mendemonstrasikan identifikasi entitas, kami akan
menganalisis fitur utama berikut dari sistem pembelian yang disederhanakan:
1. Agen pembelian meninjau laporan status persediaan untuk item yang perlu diurutkan
ulang
2. Agen memilih pemasok dan menyiapkan pesanan pembelian online.
3. Agen mencetak salinan pesanan pembelian dan mengirimkannya ke pemasok
4. Pemasok mengirim inventaris ke perusahaan. Setelah kedatangannya, panitia
penerima memeriksa inventaris dan menyiapkan laporan penerimaan online. Sistem
komputer secara otomatis memperbarui catatan inventaris.
Entitas direpresentasikan sebagai kata benda dalam deskripsi sistem. Sejumlah entitas
kandidat dapat diidentifikasi dalam uraian sebelumnya: Agen Pembelian, Penerimaan
Petugas, Inventaris, Pemasok, Laporan Status Inventaris, Pesanan Pembelian, dan
Laporan Penerimaan. Tidak semua kandidat ini adalah entitas nyata yang perlu
dimodelkan dalam database. Untuk lulus sebagai entitas yang valid, dua ketentuan
harus dipenuhi:
Kondisi 1. Suatu entitas harus terdiri dari dua atau lebih kejadian.
Kondisi 2. Suatu entitas harus menyumbangkan setidaknya satu atribut yang tidak
disediakan melalui entitas lain.
Kita perlu menguji kondisi ini untuk setiap kandidat untuk menghilangkan entitas palsu.

Buat Model Data Menampilkan Asosiasi Entitas

Langkah selanjutnya dalam pemodelan tampilan adalah untuk menentukan
hubungan antara entitas dan mendokumentasikannya dengan diagram ER. Ingat bahwa
asosiasi mewakili aturan bisnis. Terkadang aturannya jelas dan sama untuk semua
organisasi. Misalnya, hubungan normal antara entitas Pelanggan dan entitas Orde
Penjualan adalah l: M (atau 1: O, tvl). Ini menandakan bahwa satu pelanggan dapat
menempatkan banyak pesanan selama periode penjualan. Asosiasi tidak akan pernah
menjadi 1: 1. Ini berarti bahwa organisasi membatasi setiap pelanggan ke Singlesale,
yang tidak masuk akal.
Kadang-kadang hubungan antara entitas tidak jelas karena aturan yang berbeda
mungkin berlaku di organisasi yang berbeda. Untuk menegaskan kembali poin penting
yang dibuat sebelumnya, aturan bisnis organisasi langsung berdampak pada struktur
tabel basis data. Jika database berfungsi dengan baik, perancangnya perlu memahami
aturan bisnis organisasi serta kebutuhan khusus dari pengguna individu.

Tambahkan Kunci Utama dan Atribut ke Model

Tambahkan Kunci Utama. Langkah selanjutnya dalam proses ini adalah menetapkan
kunci primer ke entitas dalam model. Analis harus memilih kunci utama yang secara
logis mendefinisikan atribut nonkey dan secara unik mengidentifikasi setiap kejadian
dalam entitas. Kadang-kadang ini dapat diselesaikan dengan menggunakan kode
sekuensial sederhana seperti Nomor Faktur, Nomor Cek, atau nomor Pesanan
Pembelian. Kode berurutan, bagaimanapun, tidak selalu merupakan kunci yang efisien
atau efektif. Melalui desain blok kode yang cermat, kode grup, kode abjad, dan kode
mnemonik, kunci primer juga dapat memberikan informasi yang berguna tentang sifat
entitas. Teknik-teknik ini dibahas secara rinci di Bab 6. Gambar 8.22 menyajikan empat
entitas dalam model dengan kunci primer yang ditugaskan.
Tambahkan Atribut. Setiap atribut dalam suatu entitas harus muncul secara langsung
atau tidak langsung (nilai yang dihitung) dalam satu atau lebih pandangan pengguna.
Atribut entitas, oleh karena itu, awalnya berasal dan dimodelkan dari pandangan
pengguna. Dengan kata lain, jika data yang disimpan tidak digunakan dalam dokumen,
laporan, atau perhitungan yang dilaporkan dalam beberapa cara, maka itu tidak
berfungsi dan tidak boleh menjadi bagian dari database. Atribut yang ditugaskan untuk
setiap entitas pada Gambar 8.23 berasal dari pandangan pengguna dari Purchase Order
dan ReceivingReport yang diilustrasikan pada Gambar 8.20 dan dari Laporan Status
lnventory yang sebelumnya telah dinormalkan.

Normalisasikan Model Data dan Tambah Kunci Asing

Masalah normalisasi yang memerlukan resolusi diuraikan dalam bagian berikut:
1. Mengulang Data Grup dalam Pesanan Pembelian. Atribut Part Number, Deskripsi,
Kuantitas Pesanan, dan Biaya Unit mengulang data grup. Ini berarti bahwa ketika
pesanan pembelian tertentu berisi lebih dari satu item (sebagian besar waktu), maka
beberapa nilai perlu diambil untuk atribut ini. Untuk mengatasinya, pengulangan data
grup ini dihapus ke entitas Item Detail PO baru. Entitas baru diberi kunci utama yang
merupakan gabungan dari Nomor Bagian dan Nomor PO. Penciptaan entitas baru
juga menyelesaikan hubungan M: M antara Purchase Order dan entitas Inventory
dengan menyediakan tautan.
2. Mengulang Data Grup dalam Menerima Laporan. Atribut Nomor Bagian, Kuantitas
yang Diterima, dan Kode Kondisi adalah grup berulang dalam entitas Laporan
Penerimaan dan telah dihapus ke entitas baru yang disebut Item Rekam Detail Item.
KUNCI KOMPOSIT yang terdiri dari BAGIAN NOMOR dan REC REPT NUMBER
telah ditetapkan. Seperti pada contoh sebelumnya, membuat entitas baru ini juga
menyelesaikan hubungan M: M antara Receiving Report dan Inventory.
3. Ketergantungan Transitif. Entri Laporan Pembelian dan Penerimaan Laporan berisi
atribut yang berlebihan dengan data dalam entitas Inventaris dan Pemasok.
Redudansi ini terjadi karena dependensi transitif (lihat Apendiks dari bab ini) dalam
entitas Purchase Order and Receiving Report dan dijatuhkan.

Bangun Database Fisik

Setiap catatan dalam tabel Rincian Item Laporan Rcc mewakili item individu
pada laporan penerimaan. Tabel memiliki kunci gabungan yang terdiri dari REC REPT
NUMBER dan PART NUMBER. Kunci komposit ini diperlukan untuk mengidentifikasi
secara unik atribut Kuantitas yang Diterima dan Kondisi dari setiap detail item-detail.
Bagian REC REPT NUMBER dari kunci menyediakan tautan ke tabel Laporan
Penerimaan yang berisi data umum tentang peristiwa penerimaan. Bagian BAGIAN
NOMOR kunci digunakan untuk mengakses tabel Inventaris untuk memfasilitasi
memperbarui bidang Jumlah pada Tangan dari Kuantitas yang Diterima dari catatan
Item-Detil.
Tabel Item PO Detail menggunakan kunci primer gabungan dari PO NUMBER
dan BAGIAN NOMOR untuk mengidentifikasi atribut Urutan Pesanan secara unik.
Komponen PO NUMBER dari kunci komposit menyediakan tautan ke tabel Purchase
Order. BAGIAN NUMBERdari kunci adalah tautan ke tab Inventori di suatu tempat
Keterangan dan Data Biaya Unit berada.
Langkah selanjutnya adalah membuat tabel fisik dan mengisi mereka dengan
data. Ini adalah langkah yang terlibat yang harus direncanakan dan dilaksanakan
dengan hati-hati dan mungkin memakan waktu berbulan-bulan dalam instalasi besar.
Program perlu ditulis untuk mentransfer data organisasi yang saat ini disimpan dalam
file Hat atau database warisan ke tabel relasional baru. Data yang saat ini disimpan di
dokumen kertas mungkin perlu dimasukkan ke dalam tabel database secara manual.
Setelah ini selesai, tampilan pengguna fisik dapat dihasilkan.

Mempersiapkan Tampilan Pengguna (Prepare the User Views)

Tabel yang dinormalisasi harus cukup kaya untuk mendukung pandangan semua
pengguna sistem yang dimodelkan. Misalnya, Purchase Order (PO) pada Gambar 8.25
dibawah, yang bisa menjadi layar entri data untuk petugas pembelian, telah dibangun
dari atribut yang terletak di beberapa tabel. Untuk mengilustrasikan hubungan, bidang
dalam tampilan pengguna dirujuk silang melalui nomor yang dilingkari ke atribut di tabel
pendukung.Perlu diingat bahwa tabel ini mungkin juga menyediakan data untuk banyak
tampilan lain yang tidak ditampilkan di sini, seperti laporan penerimaan, daftar
permintaan pembelian, laporan status persediaan, dan laporan aktivitas pembelian
vendor.
Fungsi kueri dari DBMS relasional memungkinkan perancang sistem untuk
membuat dengan mudah pandangan pengguna dari tabel. Perancang hanya memberi
tahu DBMS tabel mana yang akan digunakan, kunci utama dan asing mereka, dan
atribut untuk dipilih dari setiap tabel. DBMS yang lebih lama mengharuskan perancang
untuk menentukan parameter tampilan secara langsung dalam SQL. Sistem yang lebih
baru melakukannya secara visual. Perancang hanya menunjuk dan mengklik pada tabel
dan atribut. Dari representasi visual ini, DBMS menghasilkan perintah SQL untuk kueri
untuk menghasilkan tampilan.
 Perintah-perintah SQL yang ada akan disimpan dalam program pengguna yang
disebut kueri. Untuk melihat laporan Status Persediaan, agen pembelian menjalankan
program kueri. Setiap kali ini dilakukan, permintaan membangun tampilan baru dengan
data saat ini di tabel Persediaan dan Vendor. Dengan memberikan pengguna dengan
permintaan pribadinya, daripada mengizinkan akses ke tabel dasar yang mendasari,
pengguna hanya terbatas pada data yang diotorisasi.
Integrasi Tampilan Global (Global View Integration)
Proses pemodelan pandangan yang dijelaskan sebelumnya tergolong hanya satu fungsi
bisnis - sistem pembelian - dan tabel dan penayangan yang dihasilkan hanya
merupakan subskema dari keseluruhan skema basis data. Perusahaan modern,
bagaimanapun, akan membutuhkan ratusan atau ribuan tampilan dan tabel terkait.
Menggabungkan kebutuhan data semua pengguna ke dalam skema tunggal atau
tampilan seluruh perusahaan disebut integrasi tampilan.

2.3 Modul Audit Tertanam (Embedded Audit Module)

Embedded Audit Module(EAM)juga dikenal sebagai audit kontinyu.Tujuan dari
modul audit tertanam iniyaitu untuk mengidentifikasi transaksi penting ketika mereka
sedang diproses dan mengekstrak salinan dari mereka secara real time. EAM sendiri
adalah modul yang diprogram khusus yang tertanam dalam aplikasi host untuk
menangkap jenis transaksi yang telah ditentukan untuk analisis selanjutnya. Pendekatan
ini diilustrasikan pada Gambar 8.26.
 Karena transaksi yang dipilih sedang diproses oleh aplikasi host, salinan
transaksi disimpan dalam file audit untuk peninjauan berikutnya. Pendekatan EAM
memungkinkan transaksi yang dipilih untuk ditangkap selama periode audit. Transaksi
yang diambil tersedia untuk auditor secara real time, pada akhir periode, atau kapan
saja selama periode tersebut, sehingga secara signifikan mengurangi jumlah pekerjaan
auditor harus dilakukan untuk mengidentifikasi transaksi signifikan untuk pengujian
substantif.
Untuk memulai penangkapan data, auditor menentukan EAM parameter dan
ambang materialitas dari transaksi yang ditetapkan untuk ditangkap. Sebagai contoh,
mari kita asumsikan bahwa auditor menetapkan ambang batas materialitas $ 50.000
untuk transaksi yang diproses oleh sistem pemrosesan pesanan penjualan. Transaksi
yang sama atau lebih besar dari $ 50.000 akan disalin ke file audit. Dari serangkaian
transaksi ini, auditor dapat memilih subset yang akan digunakan untuk pengujian
substantif. Transaksi yang jatuh di bawah ambang ini akan diabaikan oleh EAM.
Meskipun teknik pengujian substantif, EAM juga dapat digunakan untuk
memantau kontrol secara berkelanjutan seperti yang dipersyaratkan oleh SAS 109.
Sebagai contoh, transaksi yang dipilih oleh EAM dapat ditinjau untuk otorisasi,
kelengkapan dan akurasi ketepatan pemrosesan , dan pengeposan yang benar untuk
akun.
Kekurangan EAM
Pendekatan EAM memiliki dua kerugian yang signifikan. Yang pertama berkaitan
dengan efisiensi operasional dan yang kedua berkaitan dengan integritas EAM.
 Efisiensi operasional
Dari sudut pandang pengguna, EAM menurunkan kinerja operasional. Kehadiran
modul audit dalam aplikasi host dapat membuat overhead yang signifikan,
terutama ketika jumlah pengujian sangat luas. Salah satu pendekatan untuk
menghilangkan beban dari sistem ini adalah merancang modul yang dapat
dinyalakan dan dimatikan oleh auditor. Dengan demikian, tentu saja, mengurangi
efektivitas EAM sebagai alat audit yang sedang berjalan.
 Memverifikasi Integritas EAM
Pendekatan EAM mungkin bukan teknik audit yang layak di lingkungan dengan
tingkat pemeliharaan program yang tinggi. Ketika aplikasi host mengalami
perubahan yang sering, EAM yang tertanam dalam host juga akan membutuhkan
modifikasi yang sering. Masalah integritas yang dikemukakan sebelumnya
 mengenai pemeliharaan aplikasi berlaku sama untuk EAM. Integritas EAM
secara langsung mempengaruhi kualitas proses audit. Oleh karena itu, auditor
harus mengevaluasi integritas EAM. Evaluasi ini dilakukan dengan cara yang
sama seperti menguji kontrol aplikasi host.

2.4 Perangkat Lunak Audit Secara Umum (Generalized Audit Software)

Perangkat lunak audit umum /Generalized audit software(GAS)adalah CAATT
yang paling banyak digunakan untuk audit IS. GAS memungkinkan auditor untuk
mengakses file data yang dikodekan secara elektronik dan melakukan berbagai operasi
pada isinya. Beberapa penggunaan yang lebih umum untuk GAS meliputi:
 Memfokuskan dan menyeimbangkan seluruh file atau item data yang dipilih
 Memilih dan melaporkan data terperinci yang terkandung dalam file
 Memilih sampel statistik stratifikasi dari file data
 Memformat hasil tes menjadi laporan
 Konfirmasi pencetakan dalam susunan kata standar atau khusus
 Menyaring data dan secara selektif termasuk atau tidak termasuk item
 Membandingkan banyak file dan mengidentifikasi perbedaan apa pun
 Hitung ulang bidang data
Popularitas luas GAS adalah karena empat faktor: (1) bahasa GAS mudah
digunakan dan memerlukan sedikit latar belakang komputer pada bagian auditor; (2)
banyak produk GAS dapat digunakan pada sistem mainframe dan PC; (3) auditor dapat
melakukan tes mereka independen dari staf layanan komputer klien; dan (4) GAS dapat
digunakan untuk mengaudit data yang disimpan di sebagian besar struktur dan format
file.

Menggunakan GAS untuk Mengakses Struktur Kompleks

Mendapatkan akses ke struktur kompleks, seperti file hash atau bentuk file acak
lainnya, dapat menimbulkan masalah bagi auditor. Tidak semua produk GAS di pasar
dapat mengakses semua jenis struktur file. Jika CAATT yang bersangkutan tidak dapat
menangani struktur yang kompleks, auditor mungkin perlu mengajukan banding kepada
profesional sistem untuk menulis program khusus yang akan menyalin catatan dari
struktur aktual mereka ke struktur sekuensial file datar untuk pengambilan yang mudah.
Sebagian besar DBMS memiliki fitur utilitas yang dapat digunakan untuk
memformat ulang struktur kompleks menjadi file datar yang sesuai untuk tujuan ini.
 Struktur basis data menggunakan pointer untuk mengintegrasikan tiga file terkait -
Pelanggan, Faktur Penjualan, dan Item Baris-dalam pengaturan hierarkis.
Mengekstraksi bukti audit dari struktur kompleksitas ini menggunakan GAS mungkin
sulit, jika bukan tidak mungkin. File datar tunggal menyajikan tiga jenis catatan sebagai
struktur sekuensial yang dapat dengan mudah diakses oleh GAS.
Masalah Audit Berkaitan dengan Pembuatan File Datar
Auditor kadang-kadang harus bergantung pada personel layanan komputer
untuk menghasilkan file datar dari struktur file yang kompleks. Ada risiko bahwa
integritas data akan dikompromikan oleh prosedur yang digunakan untuk membuat file
datar. Misalnya, jika tujuan auditor adalah untuk mengkonfirmasi piutang, akun penipuan
tertentu dalam struktur kompleks dapat dengan sengaja dihilangkan dari salinan file
datar yang dibuat. Contoh konfirmasi yang diambil dari file datar mungkin tidak dapat
diandalkan. Auditor yang ahli dalam bahasa pemrograman dapat menghindari
kemungkinan jebakan ini dengan menulis rutinitas ekstraksi data mereka sendiri.

2.5 Perangkat Lunak Acl (Acl Software)

Di masa lalu, perusahaan akuntan publik mengembangkan versi eksklusif GAS,
yang mereka gunakan dalam audit klien mereka. Baru-baru ini, perusahaan perangkat
lunak telah melayani pasar ini. Di antara mereka, Bahasa Perintah Audit(Audit
Command Language – ACL) adalah pemimpin dalam industri. ACL dirancang sebagai
meta bahasa bagi auditor untuk mengakses data yang disimpan dalam berbagai format
digital dan untuk mengujinya secara komprehensif. Banyak masalah yang terkait dengan
mengakses struktur data yang kompleks telah dipecahkan oleh antarmuka Open
Database Connectivity (ODBC) ACL.
A. Definisi Data (Data Definition)
Kita telah menetapkan bahwa sistem klien dapat menyimpan data menggunakan
sejumlah file flat atau struktur database, termasuk file sekuensial (berurutan), file
VSAM, daftar terkait, dan tabel relasional. Salah satu kekuatan ACL adalah
kemampuan untuk membaca data yang tersimpan dalam sebagian besar format. ACL
menggunakan fitur definisi data untuk tujuan ini. Untuk membuat definisi data, auditor
perlu mengetahui baik di mana file sumber secara fisik berada dan tata letak struktur
bidangnya. File kecil dapat diimpor melalui file teks atau spreadsheet. File yang
sangat besar mungkin perlu diakses langsung dari komputer mainframe. Ketika ini
terjadi, auditor harus mendapatkan hak akses ke direktori tempat file berada. Sedapat
mungkin, bagaimanapun, salinan file harus disimpan dalam direktori pengujian
terpisah atau diunduh ke PC auditor, langkah ini biasanya memerlukan bantuan dari
para profesional sistem. Auditor harus memastikan bahwa dia mengamankan versi
yang benar dari ubin, bahwa itu sudah lengkap, dan bahwa dokumentasi struktur ubin
masih utuh. Pada titik ini, auditor siap untuk menentukan ubin ke ACL.

B. Penyesuaian Tampilan (Customizing a View)

Sebuah tampilah adalah cara sederhana untuk melihat data dalam file. Auditor
jarang menggunakan semua data yang terdapat dalam file.ACL memungkinkan
auditor untuk menyesuaikan tampilan asli yang dibuat selama definisi data ke definisi
yang lebih baik dalam memenuhi kebutuhan auditnya. Auditor dapat membuat dan
memformat ulang tampilan baru tanpa mengubah atau menghapus data dalam file
 yang mendasarinya. Hanya penyajian data yang terpengaruh. Misalnya, file
persediaan pada Gambar 8.32 berisi sejumlah bidang yang tidak relevan dengan
audit. Juga, data kunci yang penting bagi auditor tidak diatur dalam bidang yang
bersebelahan. Sebaliknya, mereka diselingi dengan data yang tidak relevan,
membuat peninjauan data penting menjadi sulit. Auditor dapat dengan mudah
menghapus dan/atau mengatur ulang data untuk memfasilitasi penggunaan yang
efektif.

C. Memfilter Data (Filtering Data)

ACL menyediakan opsi kuat untuk memfilter data yang mendukung berbagai tes
audit. Filter adalah ekspresi (tanda/lambang) untuk mencari catatan yang memenuhi
kriteria filter. Pembuat ekspresi (tanda/lambang) ACL memungkinkan auditor untuk
menggunakan operator logika seperti AND, OR, <,>, NOT dan lainnya untuk
menentukan dan menguji kondisi dari setiap kerumitan dan untuk memproses catatan
yang cocok dengan kondisi tertentu. Sebagai contoh, auditor dapat mencari catatan
file persediaan dengan kuantitas negatif atau jumlah nol di tangan.

D. Stratifikasi Data (Stratifying Data)

Fitur stratifikasi ACL memungkinkan auditor untuk melihat distribusi catatan yang
termasuk dalam strata tertentu. Data dapat dikelompokkan pada bidang angka apa
pun seperti harga penjualan, biaya unit, kuantitas yang terjual, dan sebagainya. Data
diringkas dan diklasifikasikan berdasarkan strata, yang dapat memiliki ukuran yang
sama (disebut interval) atau bervariasi dalam ukuran (bebas).
Laporan stratifikasi yang disajikan pada Gambar 8.36 menunjukkan data biaya
satuan dialokasikan di 10 interval hom $ -6,87 menjadi $ 381,20. Auditor dapat
memilih untuk mengubah ukuran dan jumlah interval atau memeriksa hanya sebagian
dari file. Sebagai contoh, dua strata pertama menunjukkan bahwa mereka
mengandung sejumlah item yang tidak proporsional. Auditor dapat memperoleh
gambaran yang lebih jelas tentang struktur biaya persediaan dengan meningkatkan
jumlah interval atau dengan mengurangi batas atas kisaran hingga $ 71.
E. Analisis Statistik (Statistical Analysis)
ACL menawarkan banyak metode sampling untuk analisis statistik. Dua yang paling
sering digunakan adalah sampel rekaman (record sampling) dan sampel unit moneter
(Monetary Unit Sampling - MUS). Setiap metode memungkinkan pengambilan sampel
 secara acak dan interval. Pilihan metode akan bergantung pada strategi auditor dan
komposisi file yang diaudit. Di satu sisi, ketika catatan dalam file terdistribusi merata
di seluruh strata, auditor mungkin menginginkan sampel yang tidak bias dan dengan
demikian akan memilih pendekatan sampel rekaman. Menggunakan persediaan
untuk mengilustrasikan, setiap catatan, terlepas dari jumlah dolar dari nilai persediaan
yang dimiliki, memiliki kesempatan yang sama untuk dimasukkan dalam sampel. Di
sisi lain, jika file tersebut sangat miring dengan item nilai besar, auditor dapat memilih
MUS, yang akan menghasilkan sampel yang mencakup semua jumlah dolar yang
lebih besar.

BAB III
PENUTUP

3.1 Kesimpulan
Bab ini dimulai dengan peninjauan struktur data, yang menentukan (I)
bagaimana catatan disusun dalam file fisik atau database dan (2) metode akses
yang digunakan untuk navi-gate file. Sejumlah struktur data dasar diperiksa,
termasuk sekuensial, in-dexed, hashing. dan petunjuk. Bab ini juga meninjau model
data relasional secara rinci. Cakupan termasuk konsep relasional, terminologi, teknik
tabel-link, normalisasi database, dan prosedur desain database. Bab ini kemudian
berfokus pada penggunaan CAKIT untuk ekstraksi dan analisis data. Ekstraksi data
dapat dilakukan oleh modul audit embed-ded dan perangkat lunak audit umum.
Perangkat lunak ini mendukung dua jenis tes audit yang (I) memungkinkan auditor
membuat kesimpulan tentang efektivitas kontrol aplikasi, dan (2) menyediakan akses
ke data yang diperlukan untuk pengujian substantif. Bab ini menjelaskan fitur,
kelebihan & kekurangan dari pendekatan modul audit tertanam (PAM). Kemudian
diuraikan fungsi-fungsi khas dan penggunaan perangkat lunak audit umum (GAS).
Bab ini ditutup dengan ulasan tentang fitur Act yang lebih umum digunakan, produk
GAS komersial terkemuka.

REFERENSI
A Hall, James. 2011. Information Technology Auditing. South-Western Cengage Learning.