Anda di halaman 1dari 19

1.

1 Tahapan Desain Program Pengujian Substantif Tahapan fungsi dalam pengujian melalui General Audit Software (GAS) menurut Willkinson (2000) : a. Extracting data fromfile; Langkah ini GAS ACL harus mampu menguraikan file data base transaksi dalam berbagai struktur, media, dan format tampilan untuk diedit dalam file kertas kerja menurut ACL. b. Calculatingwith data; Langkah untuk menguji penjumlahan, pengurangan, pembagian dan pengalian dalam berbagai format dan tampilan file kertas kerja, sebagai prosedur awal atas saldo. c. Performingcomparisonswith data; Langkah ini melakukan pembandingan elemen data untuk memastikan konsistensi data antar file data base dan memverifikasi kondisi yang memungkinkan terjadi. Auditor menggunakan ekspresi logika untuk menginvenstigasi perbandingan data. d. Summarizing data; Elemen data pada tahap ini perlu diringkas untuk dapat diperbandingkan dengan laporan yang ada. e. Analyzing data; Berbagai data dianalisis untuk menyediakan dasar telaah atas tren atau pertimbangan yang diperlukan. f. Reorganizing data; Langkah ini melakukan sortasi atau penggabungan elemen data untuk mengorganisir data. g. Selectingsample data for testing; Tahapan ini diperlukan seandainya terdapat serangkaian data yang tidak dapat diuji semua. Pemilihan data dapat dilakukan secara acak berdasarkan kriteria tertentu. h. Gatheringstatstical data; Auditor seringkali memerlukan analisis berdasarkan perhitungan statistik atas sejumlah data. i. Printing confirmatonrequest, analysesandotherouputs; Langkah terakhir ini untuk mendukung dokumentasi dan analisis hasil.

Aplikasi atas fungsi pengujian diatas dapat digambarkan sebagai berikut:


MF
MF

1.
2. 3. 4. 5.

TF

6. 7. 8.

CF

9.

Extracting data Calculating with data Performing comparison data Summarizing data Analyzing data Reorganizing data Selecting sample data items Gatering Stsistical data Printing confirmaton request, analyses and other ouputs

Sample data, analyses, control data

Exception report

GAS

Keterangan : MF : master file data base, TF ; transactionfile, CF ; controlfile, GAS : general audit software.

Prosedur di atas dilakukan untuk dapat memberikan panduan atas model pengujian dan tindak lanjut atas laporan perbedaan (exceptionreport). Model yang dihasilkan diharapkan memudahkan dalam melaksanakan pengujian substantif dengan GAS.

Tahapan fungsi dalam pengujian melalui General Audit Software (GAS) menurut Willkinson (2000) yaitu : 4.1.1 Extracting data fromfile Langkah ini dilakukan dengan menguraikan file data base(ekstensi mdb) menjadi struktur, media, dan format tampilan untuk diedit dalam file kertas kerja menurut ACL. Data base yang diekstrak antara lain : filecustomer, salesinvoice, shipping log, cashreceipt, cash register, dan fileinventory. Identifikasi dilakukan terhadap jenis tabel data base, record dan field yang ada dalam filemdb, menentukan tipe data serta memberikan nama tabel data. Relasi atas tabel yang ada dapat digambarkan secara singkat pada Gambar 4.1 berikut: Gambar 4.1Relasi antar Data Base

Sumber : Data sekunder yang diolah, 2009 Contoh ekstraksi data base dari data perusahaan menjadi file kerja pada ACL adalah sebagai berikut : Gambar 4.2 Tampilan FileCustomer
Page 1 Producedwith ACL by: ACL Educational Edition - Not For Commercial Use: 64 record 10/11/09 02:08:06

Customer Number 35189 444413 463451 269267 359310

Name VERSA TIRES EQUITABLE CORPO RATION BLUE ATLANTA UNIVERSITY NATIO NAL SECOND BONNET COMMERCIAL

Street 51001 BORNEO RD 6300 METZEROTT RD 301 E 2ND ST 9600 MARKET ST 20500 AMERICAN RD

City PITTSBURGH LOUISVILLE ST LOUIS SCARSDALE RICHMOND

State TX CO MO NY VA

Zip 75686 80027 63131 10583 23219

Credit Limit 32000 22000 53000 22000 60000

Sales Rep 210 40 120 170 230

519311 564291 815062

QUORUM JOY MICHIGAN OILFIEL D INC. BANCO INC.

650 BROADWAY 8335 GRANDVIEW AVE 4441 N 12TH ST

LA JOLLA WILLOUGHB Y BRONX

CA OH NY

92037 44094 10467

59000 8000 66000

30 180 170

Sumber : Data sekunder yang diolah, 2009

Gambar 4.3Tampilan FileSalesInvoice


Page 1 Producedwith ACL by: ACL Educational Edition - Not For Commercial Use; 700 record 10/11/09 14:24:37

RemitNumber InvoiceNumber CustomerNumber 12654 12655 12656 12657 12659 12660 12661 12663 12664 200000 202284 203065 203452 203614 205605 211206 212297 212334 65003 516372 516372 516372 222006 795401 516372 784647 518008

Amount 95.20 1229.10 3038.10

PaymentDate 01/10/2004 01/11/2004 02/01/2004

CheckNumber 14834.9804346158 6493.1563417580 16728.8160350712 48619.0995594978 90421.1324057503 80396.6433171224 66115.3699318149 68532.3869245832 39421.5725428487

278660.60 02/01/2004 5399.70 4747.00 12984.30 737.60 122.30 02/01/2004 03/19/2004 03/18/2004 06/20/2004 06/20/2004

Sumber : Data sekunder yang diolah, 2009 Ekstraksi data transaksi menjadi file yang terbaca oleh project ACL akan memudahkan tahap pengujian selanjutnya, terutama menghindari adanya data yang tidak terbaca, rusak dan tidak lengkap dalam analisisnya. Pengujian terhadap data dilanjutkan dengan uji verifikasi dan validitas error data, dengan output sebagai berikut : Gambar 4.4Tampilan Sortasi Data

Sumber : Data sekunder yang diolah, 2009 Producedwith ACL by: ACL Educational Edition - Not For Commercial Use Command: VERIFY FIELDS City Credit_LimitCustomer_NumNameSales_Rep State StreetZip ERRORLIMIT 10 --------------------------------------------------------------------------0 data validityerrorsdetected 0 recordsproduced Command: VERIFY FIELDS Amount_DueCustomer_NumDue_DateInvoice_NumberRemit_NumSales_Datetestdate ERRORLIMIT 10 -------------------------------------------------------------------------------0 data validityerrorsdetected 0 recordsproduced

Producedwith ACL by: ACL Educational Edition - Not For Commercial Use Command: VERIFY FIELDS AmountCheck_NumberCustomer_NumInvoice_NumberPayment_DateRemit_Num ERRORLIMIT 10 -------------------------------------------------------------------------------0 data validityerrorsdetected 0 recordsproduced

Verifikasi terhadap filecustomer, salesinvoice, shipping log menunjukkan tidak terdeteksi adanya data error, kecuali 1 data pada bill of loading (BOL) yang tidak terisi. Command: VERIFY FIELDS BOL_NumCarrierCustomer_NumInvoice_NumberShip_Date ERRORLIMIT 10 -------------------------------------------------------------------------------1 data validityerrorsdetected 1 recordsproduced Deteksi awal verifikasi data kemudian ditindaklanjuti dengan mengecek silang dengan tabel data shipping log untuk mengetahui record yang error. Terlihat pada record ke-700 terisi data 0, namun ikut terproses dalam sistem seperti terlihat pada Gambar 4.5 berikut: Gambar 4.5.Hasil Verifikasi Data Error pada FileShipping Log

Sumber: Data sekunder yang diolah, 2009

Auditor disarankan meminta dokumen pendukung record transaksi ke-700 serta penjelasan terjadinya data tersebut.

4.1.2 Calculatingwith data Langkah untuk menguji penjumlahan, pengurangan, pembagian dan pengalian dalam berbagai format dan tampilan file kertas kerja, sebagai prosedur awal atas saldo. Langkah ini dilakukan dengan menghitung jumlah (amount) tiap tabel data, statistik dari data, serta mengecek silang (crosschek) antar data. As of: 10/11/2009 Command: TOTAL FIELDS Amount_Due Table:Sales_Invoice Amount_Due 5,379,996.96 Pengujian juga dilakukan dengan statistik pada file data base, misal seperti terlihat pada gambar berikut, dengan hasil pada hasil log dibawah : Gambar 4.6Tampilan Statistik pada FileCustomer

Hasil pengujian statistik dapat terlihat pada log atas command statistik sebagai berikut: Command: STATISTICS ON Credit_Limit STD TO SCREEN Table:Customer Credit_Limit Range Positive Negative Zeros Totals Number 64 0 0 64 Total 98,000 3,093,000 0 3,093,000 Average 48,328 0 48,328

Sumber : Data sekunder yang diolah, 2009

Statistik pada tabel customer menunjukkan terdapat 64 record, tidak ditemukan record yang benilai nol atau tidak terisi, nilai negatif. Command: STATISTICS ON Amount STD TO SCREEN NUMBER 5 Table:Cash_Receipts

Amount Number Range Positive Negative Zeros Totals AbsValue Std. Dev. -

Total 278,660.60

Average -

163 1,125,020.22 6,901.96 0 2 0.00 0.00 -

Statistik pada tabel cash receipt menunjukkan terdapat 165 record, ditemukan 2 record yang benilai nol atau tidak terisi, tidak ada yang nilai negatif.

165 1,125,020.22 6,818.30 - 1,125,020.22 30,573.73 -

Tampilan kalkulasi data dapat diperlihatkan pada profil field yang ada file, misalnya filesalesinvoice berikut : Command: PROFILE FIELDS Amount_DueCustomer_NumRemit_Num Table:Sales_Invoice FieldName Amount_Due Total Value AbsoluteValue Minimum Maximum 5,379,996.96 5,379,996.96 341,423,038 2,063,574 0.00 55,491.90 51,593 0 994,403 12,820

Customer_Num 341,423,038 Remit_Num 2,063,574

Tabel salesinvoice menunjukkan nomor customer dari 51.593 sampai 994.403 dengan total invoice 5.379.996,96 (sesuai data tabel amountsales_invoice).

4.1.3

Performingcomparisonswith data Langkah ini melakukan pembandingan elemen data untuk memastikan konsistensi data antar file data

base dan memverifikasi kondisi yang memungkinkan terjadi. Auditor dapat menggunakan ACL menentukan sampel yang diperlukan sesuai dengan memperhatikan tingkat keyakinan (confidance), tingkat ketepatan (precession) dan kesalahan (errorrate) yang timbul. Misalnya pada file salesinvoice, dengan ketentuan populasi 700 record, confidence 95%, tingkat precesion 5% dan errorrate 0,00 menampilkan sampel 60 record, dengan interval 11,66, seperti terlihat log file dan gambar berikut:

Command: SIZE RECORD CONFIDENCE 95 POPULATION 700 TO SCREEN PRECISION 5 Population: 700, Confidence: 95%, Precision: 5.00%, ErrorRate: 0.00 Samplesize Interval size 60 11.66

Number of tolerableerrors 0 Gambar 4.7 Tampilan Sampel Size

Auditor menggunakan ekspresi logika untuk menginvenstigasi perbandingan data. Pengujian dilakukan baik untuk memverifikasi urutan (sequence), duplikasi (duplicate) dan senjangan (gaps) diantara data spesifik, seperti : urutan nomor invoice, nomor cek, nomor konsumen, nomor penerimaan kas. Pengujian ini untuk menganalisis adanya urutan yang tidak sesuai, hilang atau rangkap padahal seharusnya harus bernomor urut tercetak (prenumbered). Langkah pengujian analisis gaps, duplicate, dan sequence seperti terlihat pada gambar dibawah 12. Gambar 4.8 Langkah Uji Analisis Gaps, Sequence dan Duplicate

Sumber : Data sekunder yang diolah, 2009

Hasil pengujian tersebut tersaji dalam hasil command log dibawah ini secara berurutan. Sequencetesterror limit of 10 reached 10 sequenceerrorsdetected Sequence: RecordNumber 3 5 105 108 109 110 126 130 133 143 Invoice_Number 213,674 200,000 214,106 213,955 213,894 213,562 213,849 214,040 203,614 213,052 Customer_Num 56,016 65,003 81,559 97,627 113,236 176,437 202,028 207,275 222,006 230,575

Uji analisis urutan (sequence) pada tabel sales_invoice menemukan terdapat 10 record yang tidak urut terutama nomor customer dan nomor invoice. Misalnya pada record 3 dengan nomor 2 terdapat angka yang missing dari 213912 ke 213674, demikian record nomor 5 yang missing dengan record nomor 4 (Gambar 4.9) Gambar 4.9Tampilan Sequence

Sumber : Data sekunder yang diolah, 2009 Command: SEQUENCE ON Check_NumberCustomer_NumInvoice_NumberPayment_Date ERRORLIMIT Table:Cash_Receipts Sequencetesterror limit of 10 reached 10 sequenceerrorsdetected

Sequence: RecordNumber 2 Check_Number 6,493.1563417580 Customer_Num Invoice_Number Payment_Date 516,372 795,401 516,372 518,008 501,657 516,372 516,372 516,372 516,372 516,372 202,284 205,605 211,206 212,334 212,824 213,133 213,134 213,135 213,138 213,151 01/11/2004 03/19/2004 03/18/2004 06/20/2004 07/30/2004 09/09/2004 09/09/2004 09/09/2004 09/09/2004 09/09/2004

6 80,396.6433171224 7 66,115.3699318149 9 39,421.5725428487 11 72,514.0878660114 12 71,853.0836899778 13 27,680.5539541483 14 3,696.8280067156

17 62,259.1890228067 19 65,663.2470522815

Tabel cashreceipt menunjukkan terdapat 10 record yang tidak urut, yang mengungkapkan acaknya urutan nomor cek dan nomor customer pada record bersangkutan. Auditor pada saat pelaksanaan audit di lapangan disarankan untuk meminta 10 record nomor cek yang tidak urut untuk dilihat kesesuaian dan kelengkapan data pendukungnya. Command: GAPS ON Remit_Num PRESORT TO SCREEN Table:Cash_Receipts 2 gaprangesdetected 2 missingitems GapsFoundBetween: Gap Start(Exclusive) 12,657 12,661 Gap End(Exclusive) 12,659 12,663 Number ofMissingItems 1 1

Pengujian terhadap gap (senjangan) atas data cashreceipt menunjukkan nomor pemberitahuan penerimaan kas (cashremittancenumber) terdapat 2 nomor yang senjang; antara nomor 12657 12659 (nomor 12658 yang hilang) dan nomor 12661 12663 (nomor 12662 yang hilang). Auditor dalam pelaksanaan audit harus meminta penjelasan terjadinya nomor yang hilang. Command: DUPLICATES ON Invoice_Number PRESORT TO SCREEN Table:Cash_Receipts 2 duplicatesdetected Duplicates: RecordNumber Invoice_Number

5 33

203,452 213,423

Pengujian terhadap duplikasi data nomor faktur penjualan (invoicenumber) menunjukkan record ke 4 dan 159 serta record ke 31 dan 32 untuk nomor invoice, nomor konsumen dan nilai faktur (amount) yang sama, sedangkan tanggal pembayaran dan nomor cek berbeda. Auditor diharuskan meminta data pendukung nomor invoice 23423 dam 203452 serta penjelasan atas transaksi tersebut, seperti terlihat pada Gambar 4.10

Gambar 4.10 Tampilan Duplikasi Data pada FileCashReceipt

Sumber: Data sekunder yang diolah, 2009

4.1.4

Summarizing data Elemen data pada tahap ini perlu diringkas untuk dapat diperbandingkan dengan laporan yang ada.

Tahap peringkasan data dapat mengambil hasil uji pada profilingdata, seperti tampilan pada filesalesinvoice berikut : Command: PROFILE FIELDS Amount_DueCustomer_NumRemit_Num Table:Sales_Invoice FieldName Amount_Due Total Value AbsoluteValue Minimum Maximum 5,379,996.96 5,379,996.96 341,423,038 2,063,574 0.00 55,491.90 51,593 0 994,403 12,820

Customer_Num 341,423,038 Remit_Num 2,063,574

Tabel salesinvoice menunjukkan nomor customer dari 51.593 sampai 994.403 dengan total invoice 5.379.996,96 sesuai data tabel amountsales_invoice.

4.1.5

Analyzing data Berbagai data dianalisis untuk menyediakan dasar telaah atas tren atau pertimbangan yang diperlukan.

Analisis dapat dilakukan dengan tampilan grafik data, stratifikasi data, aging dan tabulasi silang data, seperti terlihat pada gambar dibawah :

Gambar 4.11. Histogram Nilai Invoice

Command: STRATIFY ON Customer_Num SUBTOTAL Customer_Num MINIMUM 50000 MAXIMUM 1000000 Table:Sales_Invoice Minimum encounteredwas 51,593 Maximumencounteredwas 994,403 Customer_Num 50,000 - 144,999 145,000 - 239,999 240,000 - 334,999 335,000 - 429,999 430,000 - 524,999 525,000 - 619,999 620,000 - 714,999 715,000 - 809,999 810,000 - 904,999 905,000 - 1,000,000 Totals Count 109 40 119 30 153 13 36 14 82 104 700 Percent of Count 15.57% 5.71% 17% 4.29% 21.86% 1.86% 5.14% 2% 11.71% 14.86% 100% Percent of Field 2.11% 2.37% 9.34% 3.31% 22.9% 2.12% 6.75% 3.21% 19.63% 28.27% 100%

Stratifikasi data salesinvoice menunjukkan penggolongan data berdasarkan nomor konsumendari yang paling kecil (nomor 515.593) sampai terbesar (nomor 994.403), dengan prosentase per golongan dan per field data yang menunjukkan sebaran terbesar masing-masing golongan. Perintah skedul waktu atas faktur penjualan,

untuk menggolongkan usia faktur dan mengidentifikasi batas pelunasannya sampai cut off (misalnya 31 Desember 2004) menghasilkan command log sebagai berikut. Terdapat 68 invoice yang usianya kurang dari 0 hari (belum jatuh tempo) dan terdapat 204 invoice yang usianya lebih dari 120 hari (telah jatuh tempo). Memperhatikan persentase sebaran tanggal jatuh tempo invoice menunjukkan sebagian besar telah jatuh tempo (204 invoice atau 29,14%). Command: AGE ON Due_Date CUTOFF 20041230 INTERVAL 0,30,60,90,120,10000 Table:Sales_Invoice Minimum encounteredwas -10 Maximumencounteredwas 7,287 Days <0 0 29 30 59 60 89 90 119 120 - 10,000 Totals Count Percent of Count 68 243 130 42 13 204 700 9.71% 34.71% 18.57% 6% 1.86% 29.14% 100%

Analisis lebih lanjut melalui uji BenfordAnalysis untuk mencermati anomali data misalnya dalam filecashreceipt menunjukkan bahwa leading digit 1-9 mempunyai zstatratio tidak lebih dari 1,96 sebagai batas normalitas data. Hasil ini mengungkapkan bahwa data cashreceipt cenderung acak. Tampilan log command dan hasilnya terlihat seperti berikut : Command: BENFORD ON Amount LEADING 1 BOUNDS TO SCREEN Table:Cash_Receipts

LeadingDigits 1 2 3 4 5 6 7 8 9

ActualCount 51 23 17 15 15 10 12 13 7

ExpectedCount 49 29 20 16 13 11 9 8 7

ZstatRatio LowerBound UpperBound 0.245 1.070 0.679 0.078 0.462 0.129 0.686 1.480 0.172 38 19 12 8 6 5 4 3 2 61 38 29 23 20 17 15 14 13

4.1.6

Reorganizing data Langkah ini melakukan sortasi atau penggabungan elemen data untuk mengorganisir data.Sortasi data

salesinvoice berdasarkan invoicenumber menunjukkan hasil : 1. Ditemukan banyak remmitancenumber yang tidak diisi misalnya invoicenumber 213567 remit_number 0 untuk customernumber 51593, demikian juga invoicenumber 213277 213593; 2. Invoicenumber 213567 menunjukkan tanggal penjualan (salesdate) 23 September 2004 (23.09.04) namun tanggal jatuh tempo (duedate) 22 Maret 2004. Demikian juga invoicenumber 200000 (record 5) dan 213474 (record 21), semuanya untuk satu customernumber 65003.

Gambar 4.12. Tampilan SortasiSalesInvoice

Sumber: Data sekunder yang diolah, 2009

4.1.7

Selectingsample data for testing Tahapan ini diperlukan seandainya terdapat serangkaian data yang tidak dapat diuji semua. Pemilihan

data dapat dilakukan secara acak berdasarkan kriteria tertentu. Set filter terhadap invoicenumber>214385 menunjukkan invoicenumber 214395 terdapat fieldamount yang 0 (nol). Invoicenumber 1929511 (nomor yang tidak identik dengan nomor invoice yang hanya 6 digit) menunjukkan sales data dan duedate yang tidak terisi. Auditor harus melakukan pengecekan terhadap data ini dan meminta kelengkapan bukti pendukung. Command:report FIELD Invoice_Number WIDTH 11 Customer_Num WIDTH 10 Amount_Due WIDTH 9 Sales_Date WIDTH 12 Due_Date WIDTH 12 Remit_Num WIDTH 9

Invoice_Number Customer_Num Amount_Due Sales_Date 214386 214387 214388 214389 214390 214391 214392 214393 214395 1929511 925007 516372 516372 262001 641464 222006 641464 262001 513574 4500261 8082.00 7377.40 66.60 3003.90 467.70 621.50 467.70 6053.40 0.00 26140.20 12/10/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004 12/10/2004

Due_Date 01/09/2005 01/09/2005 01/09/2005 01/09/2005 01/09/2005 01/09/2005 01/09/2005 01/09/2005 01/09/2005

Remit_Num 0 0 0 12817 12818 12819 0 0 12820 51274

9 of 700 matched the Filter: Invoice_Number > 214385

4.1.8

Gatheringstatistical data Auditor seringkali memerlukan analisis berdasarkan perhitungan statistik atas sejumlah data. Analisis

statistik juga telah dilakukan pada tahap summarizing data, dan pada tahap ini menverifikasi berbagai tahapan pengujian. Set uji duplikasi terhadap shipdate menunjukkan tidak terdapat duplikasi tanggal pengiriman, namun setelah difilter yang tanggal pengiriman lebih dari 31 Desember 2004 ( cutofflaporan keuangan) menemukan 10 record dengan karakteristik tersebut. Satu record yang tidak identik yaitu record nomor bill of lading- BOL number 170145 (tidak identik dengan BOL number yang hanya 5 digit) mengungkapkan data tidak diisi carrier (pengiriman) dan tanggal shipdate. Tampilan command log hasil uji duplikasi seperti tertera di bawah ini :

Command: DUPLICATES ON Invoice_Number2 Invoice_Number PRESORT TO SCREEN Tables: tes / Shipping_Log 0 duplicatesdetected Command:report FIELD BOL_Num WIDTH 11 Carrier WIDTH 7 Invoice_Number WIDTH 10 Customer_Num WIDTH 12 Ship_Date WIDTH 9
BOL_Num Carrier Invoice_Number Customer_Num Ship_Date 17010 17011 17012 17013 UPS UPS ABX ABX 214385 214386 214387 214388 463451 925007 516372 516372 01/04/2005 01/04/2005 01/04/2005 01/04/2005

17014 17015 17016 17017 17018 17019 170145

PAR PAR ABX ABX PAR PAR

214389 214390 214391 214392 214393 214395 2143896

262001 641464 222006 641464 262001 513574 4963712

01/04/2005 01/04/2005 01/04/2005 01/04/2005 01/04/2005 01/04/2005

10 of 700 matched the Filter: Ship_Date >= `20041231`

4.1.9

Printing confirmatonrequest, analysesandotherouputs Output berupa command log, perhitungan, tampilan data, grafik diperlukan sebagai bagian dokumen

audit, untuk bahan pelaksanaan audit misalnya konfirmasi, observasi, permintaan keterangan dan inspeksi.

4.2 Pembahasan Berdasarkan 9 prosedur dasar penerapan pada uji kasus Bradmark ditemukan beberapa hasil, antara lain: 1. Terdapat 1 record pada fileshipping log yang terisi data 0, sehingga oleh ACL mendeteksinya sebagai data yang errors; 2. Terdapat 64 record pada filecustomer tidak ditemukan record yang benilai nol atau tidak terisi, nilai negatif sehingga cukup andal untuk digunakan sebagai file utama 3. Statistik pada tabel cashreceipt menunjukkan terdapat 165 record, ditemukan 2 record yang benilai nol atau tidak terisi, tidak ada yang nilai negatif. 4. Verifikasi terhadap filecustomer, salesinvoice, shipping log menunjukkan tidak terdeteksi adanya data error, kecuali 1 data pada bill of loading (BOL) yang tidak terisi, 5. Terdapat 10 record yang tidak urut terutama nomor customer dan nomor invoice. Misalnya pada record 3 dengan nomor 2 terdapat angka yang missing dari 213912 ke 213674, demikian record nomor 5 yang missing dengan record nomor 4; 6. Terdapat 10 record yang tidak urut, yang mengungkapkan acaknya urutan nomor cek dan nomor customer pada record bersangkutan. Auditor pada saat pelaksanaan audit di lapangan disarankan untuk meminta 10 recordnomor cek yang tidak urut untuk dilihat kesesuaian dan kelengkapan data pendukungnya; 7. Ditemukan nomor pemberitahuan penerimaan kas (cashremittancenumber) terdapat 2 nomor yang senjang; antara nomor 12657 12659 (nomor 12658 yang hilang) dan nomor 12661 12663 (nomor 12662 yang hilang). Auditor dalam pelaksanaan audit harus meminta penjelasan terjadinya nomor yang hilang; 8. Terhadap duplikasi data nomor faktur penjualan (invoicenumber) menunjukkan record ke 4 dan 159 serta record ke 31 dan 32 untuk nomor invoice, nomor konsumen dan nilai faktur (amount) yang sama,

sedangkan tanggal pembayaran dan nomor cek berbeda. Auditor diharuskan meminta data pendukung nomor invoice 23423 dam 203452; 9. Perintah skedul waktu atas faktur penjualan, untuk menggolongkan usia faktur dan mengidentifikasi batas pelunasannya sampai cut off (misalnya 31 Desember 2004) menghasilkan command log sebagai berikut. Terdapat 68 invoice yang usianya kurang dari 0 hari (belum jatuh tempo) dan terdapat 204 invoice yang usianya lebih dari 120 hari (telah jatuh tempo). Memperhatikan persentase sebaran tanggal jatuh tempo invoice menunjukkan sebagian besar telah jatuh tempo (204 invoice atau 29,14%). 10. Set filter terhadap invoicenumber>214385 menunjukkan invoicenumber 214395 terdapat fieldamount yang 0 (nol). Invoicenumber 1929511 (nomor yang tidak identik dengan nomor invoice yang hanya 6 digit) menunjukkan sales data dan duedate yang tidak terisi. 11. Satu record yang tidak identik yaitu record nomor bill of lading. BOL number 170145 (tidak identik dengan BOL number yang hanya 5 digit) mengungkapkan data tidak diisi carrier (pengiriman) dan tanggal shipdate. Identifikasi dan pelaksanaan penerapan pengujian atas siklus penerimaan pada kasus Bradmark 04 seperti diuraikan diatas kemudian dirumuskan menjadi program audit untuk 9 prosedur dasar audit dengan berbantuan komputer. Program audit beserta indikator pelaksanaan audit di lapangan dapat disajikan sebagai berikut:

TABEL 4.1 PROGRAM AUDIT SIKLUS PENERIMAAN BRADMARK COMPANY


Verifikasi Tgl PIC

No 1

Uraian Program Audit Peroleh data base klien secara lengkap untuk satu siklus penerimaan, baik master filemaupun transactionfile Ekstraksi data base klien ke fileproject ACL. Verifikasi record yang tidak terbaca, tidak lengkap, dan tidak terisi

Indikator Pelaksanaan Audit Data base per siklus penerimaan Master file utama: customer, inventory, cashreceipt Transactionfile : check register, shipping log, salesinvoice Deteksi validitas data yang errors Record yang tidak dihasilkan Apabila ditemukan log bahwa data error, mintalah dokumen pendukung dan penjelasan tertulisnya

Lakukan verifikasi terhadap kelengkapan data tiap field

Lakukan perhitungan terhadap format tampilan kertas kerja file bersangkutan Buat uji statistik dan profil atas data file terkait

Dokumentasikan uji verifikasi data terhadap tiap file Berikan indeks dan lengkapi dengan printoutfile daftar error kalau ditemukan Buat uji total field atas file terkait Cek jumlah record tiap file dan verifikasi silang dengan data yang lain Buat analisis statistik, uji tabulasi silang dan histogram untuk file yang terkait Periksai isi field yang tidak identik, berbeda karakter dan tidak sesuai dengan SOP pengisian; misal tanggal, nilai negatif, nol, pecahan desimal yang tidak sesuai Buat uji urutan (sequence); tentukan apakah terdapat isi field, record atau data file yang tidak urut, nilai yang terlewatkan bahkan tidak ada Dokumentasikan hasil uji sequence, lakukan konfirmasi dan interview untuk data pendukungnya Buat uji duplikasi(duplicate); tentukan apakah isi field, record atau data file yang terduplikasi, nilai yang rangkap Dokumentasikan hasil uji duplicate, lakukan konfirmasi dan interview untuk data pendukungnya

Lakukan perbandingan antar data

No

Uraian Program Audit

Indikator Pelaksanaan Audit Buat uji senjangan(gap); tentukan apakah isi field, record atau data file yang terlewatkan, nilai yang hilang Dokumentasikan hasil uji gap, lakukan konfirmasi dan interview untuk data pendukungnya Dokumentasikan file hasil profiling data, untuk dicrosscheck dengan hasil kalkulasi dan ringkasan data Berikan komentar hasil crosschek Buat sampel data per file Lakukan perhitungan materialitas dan resiko audit terkait sampel data Mintalah dokumen pendukung dari sampel data per file Periksa terpenuhinya unsur asersi dari dokumen pendukung Cetak tampilan hasil tiap pengujian Buat analisis dan komentar atas hasil pengujian Identifikasi : command dan log file tiap pengujian Simpan dan kopi outputfile tiap pengujian Simpan dan kopi command dan log file tiap pengujian

Verifikasi Tgl PIC

Buat profil data atas file terkait

Tentukan sampel yang diperlukan

Peroleh dan lengkapi cetak hasil pengujian

Anda mungkin juga menyukai