1.1 Tahapan Desain Program Pengujian Substantif
Tahapan fungsi dalam pengujian melalui General Audit Software (GAS) menurut Willkinson (2000) : a. Extracting data fromfile; 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 Performingcomparisonswith data; data; Langkah ini melakukan pembandingan elemen data untuk memastikan konsistensi data antar file data base dan memverifikasi memverifikasi kondisi yang memungkinkan memungkinkan terjadi. Auditor menggunakan menggunakan ekspresi logika untuk menginvenstigasi perbandingan data. d. Summarizing data; Elemen data pada tahap ini perlu diringkas untuk dapat di perbandingkan perbandingkan dengan laporan yang ada. e. Analyzing data; Berbagai data dianalisis untuk menyediakan dasar telaah atas tren atau pertimbangan yang diperlukan. f. Reorganizing data; 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 Gatheringstatstical data; Auditor seringkali memerlukan analisis berdasarkan perhitungan statistik atas sejumlah data. i. Printing confirmatonrequest, confirmatonrequest, analysesandotheroup analysesandotherouputs uts;; Langkah Langkah terakhir ini untuk mendukung dokumentasi dan analisis hasil.
Aplikasi atas fungsi pengujian diatas dapat digambarkan sebagai sebagai berikut: MF MF
1. 2. 3. 4. 5.
TF
6. 7. 8.
CF
9.
GAS
Keterangan :
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
Sample data, analyses, control data
Exception report
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 Extr acting data fromfil e
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 10/11/09 02:08:06
Page 1 Producedwith ACL by: ACL Educational Edition - Not For Commercial Use: 64 record
Customer Number 35189
Name
Street
City
State
Zip
Credit Limit
Sales Rep
VERSA TIRES
51001 BORNEO RD
PITTSBURGH
TX
75686
32000
210
444413
EQUITABLE CORPO RATION
6300 METZEROTT RD
LOUISVILLE
CO
80027
22000
40
463451
BLUE ATLANTA
301 E 2ND ST
ST LOUIS
MO
63131
53000
120
269267
UNIVERSITY NATIO NAL
9600 MARKET ST
SCARSDALE
NY
10583
22000
170
SECOND BONNET
519311
QUORUM JOY
650 BROADWAY
LA JOLLA
CA
92037
59000
30
564291
MICHIGAN OILFIEL D INC.
8335 GRANDVIEW AVE
WILLOUGHB Y
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 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 l oading (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
Auditor disarankan meminta dokumen pendukung record transaksi ke-700 serta penjelasan terjadinya data tersebut.
4.1.2 Calculati ngwith 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
Number
Total
Average
-
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 5 Table:Cash_Receipts
Amount Range
Number -
Positive
Total
Average
278,660.60
-
163 1,125,020.22 6,901.96
Negative
0
0.00
0.00
Zeros
2
-
-
Totals
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
AbsValue
- 1,125,020.22
-
Std. Dev.
-
-
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
Customer_Num 341,423,038
341,423,038
51,593
994,403
2,063,574
0
12,820
Remit_Num
2,063,574
0.00 55,491.90
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
Perf ormi ngcompari sonswith 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
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 reached 10 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 reached 10 sequenceerrorsdetected
Sequence: RecordNumber
Check_Number 2
Customer_Num Invoice_Number Payment_Date
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
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 SCREEN Table:Cash_Receipts 2 gaprangesdetected 2 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 SCREEN Table:Cash_Receipts 2 duplicatesdetected Duplicates:
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
Summari zing 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
Customer_Num 341,423,038
341,423,038
51,593
994,403
2,063,574
0
12,820
Remit_Num
2,063,574
0.00 55,491.90
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
Anal yzin g 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
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 -10 Maximumencounteredwas 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 SCREEN Table: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
Reorganizin g 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 SortasiSalesI nvoice
Sumber: Data sekunder yang diolah, 2009
4.1.7
Selectin gsample data for testi ng
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
4.1.8
Gatheri ngstatisti cal 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 (cutoff laporan 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
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
2143896
4963712
170145
10 of 700 matched the Filter: Ship_Date >= `20041231`
4.1.9
Pri nti ng conf ir matonrequest, analysesandother ouputs
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 l oading (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 P ENERIMAAN BRADMARK COMPANY
No 1
2
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
3
Lakukan verifikasi terhadap kelengkapan data tiap field
4
5
Lakukan perhitungan terhadap format tampilan kertas kerja file bersangkutan Buat uji statistik dan profil atas data file terkait
6
Lakukan perbandingan antar data
Apabila ditemukan log bahwa data error, mintalah dokumen pendukung dan penjelasan tertulisnya 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
Verifikasi Tgl
PIC
No
Uraian Program Audit
Indikator Pelaksanaan Audit
7
8
Buat profil data atas file terkait
Tentukan sampel yang diperlukan
Peroleh dan lengkapi cetak hasil pengujian
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
9
Buat uji senjangan(gap); tentukan apakah isi field, record atau data file yang terlewatkan, nilai yang hilang
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
