Upload
fatmawati-nova-artanti
View
223
Download
12
Embed Size (px)
Citation preview
MFMF
CF
TF
GAS
Extracting dataCalculating with dataPerforming comparison dataSummarizing dataAnalyzing dataReorganizing dataSelecting sample data itemsGatering Stsistical dataPrinting confirmaton request, analyses and other ouputs
Sample data, analyses, control data
Exception report
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:
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 110/11/09 02:08:06
Producedwith ACL by: ACL Educational Edition - Not For Commercial Use: 64 record
CustomerNumber
Name Street City State ZipCredit Limit
SalesRep
35189 VERSA TIRES 51001 BORNEO RD PITTSBURGH TX 75686 32000 210
444413EQUITABLE CORPORATION
6300 METZEROTT RD LOUISVILLE CO 80027 22000 40
463451 BLUE ATLANTA 301 E 2ND ST ST LOUIS MO 63131 53000 120
269267UNIVERSITY NATIONAL
9600 MARKET ST SCARSDALE NY 10583 22000 170
359310SECOND BONNET COMMERCIAL
20500 AMERICAN RD RICHMOND VA 23219 60000 230
519311 QUORUM JOY 650 BROADWAY LA JOLLA CA 92037 59000 30
564291MICHIGAN OILFIELD INC.
8335 GRANDVIEW AVE WILLOUGHBY OH 44094 8000 180
815062 BANCO INC. 4441 N 12TH ST BRONX NY 10467 66000 170
Sumber : Data sekunder yang diolah, 2009
Gambar 4.3Tampilan FileSalesInvoice
Page 1 10/11/09 14:24:37
Producedwith ACL by: ACL Educational Edition - Not For Commercial Use; 700 record
RemitNumber InvoiceNumber CustomerNumber Amount PaymentDate CheckNumber
12654 200000 65003 95.20 01/10/2004 14834.9804346158
12655 202284 516372 1229.10 01/11/2004 6493.1563417580
12656 203065 516372 3038.10 02/01/2004 16728.8160350712
12657 203452 516372 278660.60 02/01/2004 48619.0995594978
12659 203614 222006 5399.70 02/01/2004 90421.1324057503
12660 205605 795401 4747.00 03/19/2004 80396.6433171224
12661 211206 516372 12984.30 03/18/2004 66115.3699318149
12663 212297 784647 737.60 06/20/2004 68532.3869245832
12664 212334 518008 122.30 06/20/2004 39421.5725428487
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 UseCommand: 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 UseCommand: 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_DueTable: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 SCREENTable:Customer
Credit_Limit Number Total Average
Range - 98,000 -
Positive 64 3,093,000 48,328
Negative 0 0 0
Zeros 0 - -
Totals 64 3,093,000 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 5Table:Cash_Receipts
Amount Number Total Average
Range - 278,660.60 -
Positive 163 1,125,020.22 6,901.96
Negative 0 0.00 0.00
Zeros 2 - -
Totals 165 1,125,020.22 6,818.30
AbsValue - 1,125,020.22 -
Std. Dev. - 30,573.73 -
Statistik pada tabel cash receipt menunjukkan terdapat 165 record, ditemukan 2 record yang benilai nol atau tidak terisi, tidak ada yang nilai negatif.
Tampilan kalkulasi data dapat diperlihatkan pada profil field yang ada file, misalnya filesalesinvoice
berikut :
Command: PROFILE FIELDS Amount_DueCustomer_NumRemit_NumTable:Sales_Invoice
FieldName Total Value AbsoluteValue Minimum Maximum
Amount_Due 5,379,996.96 5,379,996.96 0.00 55,491.90
Customer_Num 341,423,038 341,423,038 51,593 994,403
Remit_Num 2,063,574 2,063,574 0 12,820
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 filesalesinvoice, 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 5Population: 700, Confidence: 95%, Precision: 5.00%, ErrorRate: 0.00
Samplesize 60
Interval size 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 reached10 sequenceerrorsdetected
Sequence:RecordNumber Invoice_Number Customer_Num
3 213,674 56,016
5 200,000 65,003
105 214,106 81,559
108 213,955 97,627
109 213,894 113,236
110 213,562 176,437
126 213,849 202,028
130 214,040 207,275
133 203,614 222,006
143 213,052 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 reached10 sequenceerrorsdetected
Sequence:RecordNumber Check_Number Customer_Num Invoice_Number Payment_Date
2 6,493.1563417580 516,372 202,284 01/11/2004
6 80,396.6433171224 795,401 205,605 03/19/2004
7 66,115.3699318149 516,372 211,206 03/18/2004
9 39,421.5725428487 518,008 212,334 06/20/2004
11 72,514.0878660114 501,657 212,824 07/30/2004
RecordNumber Check_Number Customer_Num Invoice_Number Payment_Date
12 71,853.0836899778 516,372 213,133 09/09/2004
13 27,680.5539541483 516,372 213,134 09/09/2004
14 3,696.8280067156 516,372 213,135 09/09/2004
17 62,259.1890228067 516,372 213,138 09/09/2004
19 65,663.2470522815 516,372 213,151 09/09/2004
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 SCREENTable:Cash_Receipts
2 gaprangesdetected2 missingitems
GapsFoundBetween:Gap
Start(Exclusive)Gap
End(Exclusive)Number ofMissingItems
12,657 12,659 1
12,661 12,663 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 SCREENTable:Cash_Receipts
2 duplicatesdetectedDuplicates:
RecordNumber Invoice_Number
5 203,452
33 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_NumTable:Sales_Invoice
FieldName Total Value AbsoluteValue Minimum Maximum
Amount_Due 5,379,996.96 5,379,996.96 0.00 55,491.90
Customer_Num 341,423,038 341,423,038 51,593 994,403
Remit_Num 2,063,574 2,063,574 0 12,820
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,593Maximumencounteredwas 994,403
Customer_Num Count Percent of Count Percent of Field
50,000 - 144,999 109 15.57% 2.11%
145,000 - 239,999 40 5.71% 2.37%
240,000 - 334,999 119 17% 9.34%
335,000 - 429,999 30 4.29% 3.31%
430,000 - 524,999 153 21.86% 22.9%
525,000 - 619,999 13 1.86% 2.12%
620,000 - 714,999 36 5.14% 6.75%
715,000 - 809,999 14 2% 3.21%
810,000 - 904,999 82 11.71% 19.63%
905,000 - 1,000,000 104 14.86% 28.27%
Totals 700 100% 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 -10Maximumencounteredwas 7,287
Days Count Percent of Count
<0 68 9.71%
0 – 29 243 34.71%
30 – 59 130 18.57%
60 – 89 42 6%
90 – 119 13 1.86%
120 - 10,000 204 29.14%
Totals 700 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 SCREENTable:Cash_Receipts
LeadingDigits ActualCount ExpectedCount ZstatRatio LowerBound UpperBound
1 51 49 0.245 38 61
2 23 29 1.070 19 38
3 17 20 0.679 12 29
4 15 16 0.078 8 23
5 15 13 0.462 6 20
6 10 11 0.129 5 17
7 12 9 0.686 4 15
8 13 8 1.480 3 14
9 7 7 0.172 2 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 Due_Date Remit_Num
214386 925007 8082.00 12/10/2004
01/09/2005
0
214387 516372 7377.40 12/10/2004
01/09/2005
0
214388 516372 66.60 12/10/2004
01/09/2005
0
214389 262001 3003.90 12/10/2004
01/09/2005
12817
214390 641464 467.70 12/10/2004
01/09/2005
12818
214391 222006 621.50 12/10/2004
01/09/2005
12819
214392 641464 467.70 12/10/2004
01/09/2005
0
214393 262001 6053.40 12/10/2004
01/09/2005
0
214395 513574 0.00 12/10/2004
01/09/2005
12820
1929511 4500261 26140.20 51274
9 of 700 matched the Filter: Invoice_Number > 214385
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 SCREENTables: 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 UPS 214385 463451 01/04/2005
17011 UPS 214386 925007 01/04/2005
17012 ABX 214387 516372 01/04/2005
17013 ABX 214388 516372 01/04/2005
17014 PAR 214389 262001 01/04/2005
17015 PAR 214390 641464 01/04/2005
17016 ABX 214391 222006 01/04/2005
17017 ABX 214392 641464 01/04/2005
17018 PAR 214393 262001 01/04/2005
17019 PAR 214395 513574 01/04/2005
170145 2143896 4963712
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.1PROGRAM AUDIT SIKLUS PENERIMAAN BRADMARK COMPANY
No Uraian Program Audit Indikator Pelaksanaan AuditVerifikasi
Tgl PIC1 Peroleh data base klien secara lengkap untuk satu siklus
penerimaan, baik master filemaupun transactionfile Data base per siklus penerimaan Master file utama: customer, inventory, cashreceipt Transactionfile : check register, shipping log, salesinvoice
2 Ekstraksi data base klien ke fileproject ACL. Verifikasi record yang tidak terbaca, tidak lengkap, dan tidak terisi
Deteksi validitas data yang errors Record yang tidak dihasilkan Apabila ditemukan log bahwa data error, mintalah dokumen
pendukung dan penjelasan tertulisnya3 Lakukan verifikasi terhadap kelengkapan data tiap field Dokumentasikan uji verifikasi data terhadap tiap file
Berikan indeks dan lengkapi dengan printoutfile daftar error kalau ditemukan
4 Lakukan perhitungan terhadap format tampilan kertas kerja file bersangkutan
Buat uji total field atas file terkait Cek jumlah record tiap file dan verifikasi silang dengan data yang
lain5 Buat uji statistik dan profil atas data file terkait 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
6 Lakukan perbandingan antar data 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
Buat uji senjangan(gap); tentukan apakah isi field, record atau data
No Uraian Program Audit Indikator Pelaksanaan AuditVerifikasi
Tgl PICfile yang terlewatkan, nilai yang hilang
Dokumentasikan hasil uji gap, lakukan konfirmasi dan interview untuk data pendukungnya
7 Buat profil data atas file terkait Dokumentasikan file hasil profiling data, untuk dicrosscheck dengan hasil kalkulasi dan ringkasan data
Berikan komentar hasil crosschek8 Tentukan sampel yang diperlukan 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
9 Peroleh dan lengkapi cetak hasil pengujian 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