Tahapan ACL New

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


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


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


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


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


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


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


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


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

Tahapan ACL New

Documents