3.1 Jenis Jenis Resiko Audit

Dari rumusan model risiko audit ada 4 (empat) jenis risiko audit. Masing-masing jenis risiko audit tersebut akan dijelaskan sebagai berikut:

1. Planned Detection Risk (Risiko Penemuan yang Direncanakan)
            Adalah risiko bahwa bukti yang dikumpulkan dalam segmen gagal menemukan kekeliruan yang melampaui jumlah yang dapat ditolerir. Jika kekeliruan semacam itu timbul. Ada dua hal penting yang harus diperhatikan:
a. PDR tergantung pada tiga unsur risiko lainnya dalam model. Jadi risiko penemuan yang direncanakan hanya akan berubah jika auditor mengubah salah satu unsur lainnya.
b. PDR menentukan besarnya bukti yang akan dikumpulkan. Hubungan antara PDR dengan bukti berbanding terbalik. Jika nilai risiko penemuan yang direncanakan diperkecil, berarti jumlah bukti yang harus dikumpulkan auditor dalam audit lebih banyak.

2. Acceptable Audit Risk (Risiko Audit yang dapat diterima)
            Adalah ukuran ketersediaan auditor untuk menerima bahwa laporan keuangn mengandung salah saji material tanpa pengecualian telah diberikan. Risiko ini ditetapkan secara subyektif bahwa auditor bersedia menerima laporan keuangan tidak disajikan secara wajar setelah audit selesai dan pendapat wajar tanpa pengecualian telah diberikan. Kalau auditor menetapkan tingkat risiko audit yang dapat diterima rendah, berarti ia ingin lebih memastikan bahwa tidak ada kekeliruan yang material dalam laporan keuangan.
            Tingkat risiko nol berarti kepastian penuh bahwa laporan keuangan tidak mengandung kekeliruan yang materia dan tingkat risiko ini 100% berarti auditor sangat tidak yakin kalau laporan keuangan tidak mengandung salah saji atau kekeliruan yang material.

3. Inherent Risk (Risiko Bawaan atau Risiko Melekat)
            Adalah penetapan auditor akan kemungkinan adanya kekeliruan (salah saji) dalam segmen audit yang melampaui batas toleransi, sebelum memperhitungkan faktor efektivitas pengendalian intern. Risiko bawaan menunjukkan faktor kerentanan laporan keuangan terhadap kekeliruan yang material dengan asumsi tidak ada pengendalian intern.
Bila auditor berkesimpulan bahwa akan banyak kemungkinan terjadi kekeliruan tanpa pengendalian intern, berarti risiko bawaannya tinggi.
Faktor pengendalian intern tidak diperhitungkan dalam menetapkan inherent risk (risiko bawaan) karena dalam model risiko audit hal itu akan diperhitungkan tersendiri sebagai risiko pengendalian. Hubungan antara risiko bawaan (inherent risk) dengan risiko penemuan (planned detection risk) serta rencana pengumpulan bukti adalah bahwa inherent risk sifatnya berbanding terbalik dengan planned detection risk rendah, maka planned detection risk tinggi dan bukti yang harus dikumpulkan pun sedikit.


4. Control Risk (Risiko Pengendalian)
            Adalah ukuran penetapan auditor akan kemungkinan adanya kekeliruan (salah saji) dalam segmen audit yang melampaui batas toleransi yang tidak terdeteksi atau tercegah oleh struktur pengendalian intern klien. Risiko pengendalian (control risk) mengandung unsur:
a. Apakah struktur pengendalian intern klien cukup efektif untuk mendeteksi atau mencegah kekeliruan.
b. Keinginan auditor untuk membuat penetapan tersebut di bawah nilai maksimum (100%) dalam rencana audit.
Misalnya: auditor menyimpulkan bahwa struktur pengendalian intern yang ada sama sekali tidak efektif dalam mencegah atau mendeteksi kekeliruan.

Komentar

Posting Komentar

Postingan populer dari blog ini

Manajemen Layanan Sistem Informasi

Gambar
Pengertian Manajemen Layanan Sistem Informasi Manajemen Layanan SIstem Informasi adalah manajemen melakukan atau melaksanakan pelayanan dalam suatu sistem di dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian, mendukung operasi, bersifat manajerial dan kegiatan strategi dari suatu organisasi dan menyediakan pihak luar tertentu dengan laporan-laporan yang diperlukan. Manajemen Layanan SIstem Informasi juga dapat diartikan sebagai suatu metode pengelolaan sistem teknologi informasi (TI) yang secara filosofis terpusat pada perspektif konsumen layanan TI terhadap bisnis perusahaan. Manajemen Layanan Sistem Informasi merupakan kebalikan dari pendekatan manajemen TI dan interaksi bisnis yang terpusat pada teknologi. Istilah Manajemen Layanan Sistem Informasi tidak berasal dari suatu organisasi, pengarang, atau pemasok tertentu dan awal penggunaan frasa ini pun tidak jelas kapan dimulainya. Manajemen Layanan TI atau manajemen layanan dukungan TI
Baca selengkapnya

Masa Depan Cemerlang Bersama Astra International

Gambar
Sejarah Astra berawal pada tahun 1957 di Jakarta. Astra memulai bisnisnya sebagai sebuah perusahaan perdagangan umum dengan nama PT Astra International Inc. Pada tahun 1990, dilakukan perubahan nama menjadi PT Astra International Tbk, seiring dengan pelepasan saham ke publik beserta pencatatan saham Perseroan di Bursa Efek Indonesia yang terdaftar dengan ticker ASII. Astra saat ini memiliki 223.019 karyawan pada 198 anak perusahaan, perusahaan asosiasi dan pengendalian bersama entitas yang menjalankan enam segmen usaha, yaitu Otomotif, Jasa Keuangan, Alat Berat dan Pertambangan, Agribisnis, Infrastruktur dan Logistik, dan Teknologi Informasi. Nilai kapitalisasi pasar PT Astra International Tbk ditutup di penghujung tahun 2014 sebesar Rp 300,6 triliun. Selama 58 tahun, Astra telah menjadi saksi pasang surut ekonomi Indonesia dan terus berkembang dengan memanfaatkan peluang bisnis berbasis sinergi yang luas dengan pihak eksternal maupun internal Grup Astra. Sebagai salah sa
Baca selengkapnya

Tugas PBO 1 - Class Diagram dan Use Case Path

Gambar
Use Case Diagram Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use case merupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client. Gambar Use Case Diagram Diagram Use Case berguna dalam tiga hal : -       Menjelaskan fasilitas yang ada (requirements) -      Membuat test dari kasus-kasus secara umum -      Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk -         -     Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas. -       Komunikas dengan klien -     Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkom
Baca selengkapnya