Jurnal ESB semua entitas — voucher dikelompokkan & transaksi berantai (barang datang → tagihan → pembayaran) saling terhubung.
s.d.
Ketik tahun 4 digit penuh atau pakai ikon kalender — kalau kosong/belum lengkap, filter tanggal ini diabaikan (cek chip "Filter aktif" di bawah)
s.d.
Ketik tahun 4 digit penuh atau pakai ikon kalender — kalau kosong/belum lengkap, filter tanggal ini diabaikan
Sales Recapitulation
Rekap penjualan per bill dari ESB (Sales Recapitulation Report), dilengkapi Payment Method dari Sales Payment Recapitulation Report. Unggah kedua laporan di Setting → Upload Sales Recapitulation.
s.d.
Kolom yang ditampilkan (tampilan Detail)
Menu No Price
Menu yang terjual tanpa harga (No Price Sales Report ESB), per bill. Lihat daftar rinci di tab Detail, atau perkembangan Qty tiap menu per hari dan akumulasinya di tab Time Series. Unggah file di Setting → Data sumber → No Price.
s.d.
Rekonsiliasi Pendapatan
Settlement penjualan (General Journal) dibandingkan dengan mutasi rekening koran & reperformance MDR, per POS Settlement Number. Unggah General Journal & PDF rekening koran di Setting terlebih dulu.
s.d.
Anomaly Detection — Sales
Deteksi indikasi anomali pada Sales Recapitulation: penjualan harian, payment method cash, diskon, dan void. Sumber data sama dengan halaman Sales Recapitulation — unggah dulu di Setting bila belum ada.
Metodologi — 21 uji, 4 area (mengikuti Katalog Metode Uji Anomali KKA)
Semua uji statistik memakai robust z-score (median & MAD, bukan mean/std biasa) dgn ambang tetap |z| ≥ 3,5 (Iglewicz–Hoaglin) — median/MAD tahan thd outlier itu sendiri, jadi baseline-nya tidak ikut rusak oleh anomali yg sedang dicari.
Baseline dikelompokkan sesuai konteks: hari-dalam-minggu yg sama (rolling median 8 periode utk GT/ATV harian) supaya pola weekend/weekday tak salah kena flag; peer sesama kasir dlm satu outlet utk cash/diskon/void per kasir; lintas-outlet dlm bulan yg sama utk tren cash/diskon bulanan (memisahkan perubahan pasar yg wajar dari anomali satu outlet).
Diskon & void jg memakai uji kepatuhan berbasis aturan (rate baku, plafon, pola berulang, silang-cek file pembayaran) yg tak butuh asumsi statistik.
Uji Benford's Law tidak dipakai (hasil awal tidak konklusif utk data ini). Semua ini indikatif utk prioritas pemeriksaan lanjutan — bukan bukti kecurangan.
s.d.
Anomaly Detection General Journal
Deteksi indikasi anomali pada General Journal (semua tipe transaksi ESB): backdating, nilai janggal, duplikasi, referensi hilang, hingga status vouching yang menggantung. Sumber data sama dengan halaman General Journal, memuat entitas yang sama otomatis dipakai ulang, tidak perlu unggah lagi.
s.d.
Anomaly Detection — Pricelist History
Deteksi anomali harga beli satuan dari Price & Pricelist History Report ESB. Dua mode: Intra-Entitas (riwayat harga satu entitas dari waktu ke waktu, tanpa membandingkan entitas lain) dan Antar-Entitas (harga rata-rata dalam periode filter, dibandingkan lintas entitas). Unggah dulu di Setting → tab Pricelist History bila belum ada.
Metodologi — berbasis harga satuan saja, TANPA qty
Laporan ESB ini memang tidak memuat kolom qty/amount. Konsekuensinya temuan dinyatakan dalam persen selisih harga, bukan rupiah kerugian; sebagai pengganti bobot materialitas dipakai frekuensi transaksi (skor = gap × frekuensi) — frekuensi jg menentukan keandalan bukti, sel dgn n<3 ditandai [KONFIRMASI] dan bukan temuan siap-lapor.
Lapis 0 (order-of-magnitude log₁₀) selalu dijalankan lebih dulu utk membuang salah-input basis satuan; ini wajib krn agregasi memakai rata-rata yang tidak tahan outlier — satu baris salah unit terbukti mampu memunculkan "anomali" +6.767% palsu.
Uji outlier memakai robust z-score (median & MAD) ambang |z| ≥ 3,5plus lantai materialitas ≥10%, supaya produk berharga pecahan rupiah tidak menghasilkan z besar utk deviasi 0,4% yg tak berarti secara audit.
Perbandingan antar entitas mengecualikan Central Kitchen dari benchmark (itu transfer intercompany, bukan harga pasar) dan menganalisisnya terpisah. Semua hasil bersifat indikatif utk prioritas pemeriksaan — bukan bukti kecurangan.
s.d.
Cek Data Basi
Membandingkan jurnal yang tersimpan di sini dengan kondisi TERKINI ESB lewat Purchase Payment Report — untuk semua entitas sekaligus. Unggahan dataset sifatnya menggabung, jadi dokumen yang sudah dibatalkan/di-unrelease di ESB tidak pernah hilang sendiri dari database ini.
Report Profit Loss
Laporan Laba Rugi disusun otomatis dari General Journal per akun, mengikuti struktur Chart of Account ESB (Pendapatan → HPP → Biaya Operasional → Biaya Headquarter & Pendapatan Lainnya → Pajak) — dilengkapi tren time series serta persentase kenaikan Month-over-Month (MoM) dan Year-over-Year (YoY). Sumber data sama dengan General Journal, tidak perlu unggah lagi.
s.d.
Sama dgn filter Journal Date di General Journal/General Ledger — rentang ini menentukan periode Laporan Laba Rugi (tab Statement). Tab Time Series tetap menampilkan semua bulan yg ada di data.
Financial Highlight Analisa Pendapatan
Pendapatan (Total Sales) dari Report Profit Loss dibandingkan dengan target penjualan, periode sebelumnya (MoM / QoQ), dan tahun lalu (YoY). Target diisi di Setting → Data master → Target Penjualan; analisa ditulis di halaman ini dan tersimpan otomatis. Pilih analisa Bulanan, Kuartal, atau Tahunan.
Memuat …
Pratinjau report
Financial Highlight Analisa Biaya OpEx
Biaya OpEx dari Report Profit Loss (Total Operational Expense) dibandingkan dengan bulan lalu (MoM), triwulan lalu, semester lalu, atau tahun lalu (YoY). Buka akun untuk melihat rinciannya dibanding periode pembanding. Analisa ditulis di halaman ini dan tersimpan otomatis.
Memuat …
Pratinjau report
Financial Highlight Analisa Other Income & Expense
Other Income & Expense (pendapatan lain dikurangi biaya lain) dari Report Profit Loss dibandingkan dengan bulan lalu (MoM), triwulan lalu, semester lalu, atau tahun lalu (YoY). Nilai positif menambah laba, nilai negatif menguranginya. Buka akun untuk melihat rinciannya dibanding periode pembanding. Analisa ditulis di halaman ini dan tersimpan otomatis.
Memuat …
Pratinjau report
Financial Highlight Analisa Tax
Beban pajak (akun Tax pada Report Profit Loss) dibandingkan dengan bulan lalu (MoM), triwulan lalu, semester lalu, atau tahun lalu (YoY). Kenaikan beban pajak mengurangi laba, penurunannya menambah laba. Buka akun untuk melihat rinciannya dibanding periode pembanding. Analisa ditulis di halaman ini dan tersimpan otomatis.
Memuat …
Pratinjau report
Financial Highlight Analisa Net Profit
Net Profit/(Net Loss) pada Report Profit Loss dibandingkan dengan bulan lalu (MoM), triwulan lalu, semester lalu, atau tahun lalu (YoY). Jembatan menunjukkan dari komponen mana perubahan laba berasal (Pendapatan, Diskon, HPP, Biaya OpEx, Other Income & Expense, Penyusutan, Tax), dan kesimpulan analisa Pendapatan, %HPP, Biaya OpEx, Other Income & Expense, dan Tax bisa dikutip ke kesimpulan akhir. Kesimpulan ditulis di halaman ini dan tersimpan otomatis.
Memuat …
Pratinjau report
Financial Highlight Analisa %HPP
Report Profit Loss bagian Analisa %HPP dan %HPP Gudang Kering / Basah / Central dibandingkan dengan bulan lalu (MoM), triwulan lalu, semester lalu, atau tahun lalu (YoY). Perubahan dinyatakan dalam %HPP (pemakaian rupiah ÷ Net Sales) dan selisihnya dalam persen. Analisa %HPP menampilkan rupiah dan persentase per nama akun; tiap gudang menampilkan harga, pemakaian qty, dan %HPP per produk. 10 perubahan terbesar (selisih %HPP) ditampilkan per gudang. Analisa ditulis di halaman ini dan tersimpan otomatis.
Memuat …
Pratinjau report
Report General Ledger
Buku besar per akun (accordion) dari General Journal — tiap akun bisa dibuka untuk melihat mutasi barisnya lengkap dengan saldo berjalan. Baris pembelian dipecah per item barang (QTY & harga satuan) hanya bila nilainya rekonsiliasi persis dengan jurnalnya. Sumber data sama dengan General Journal, tidak perlu unggah lagi.
s.d.
Kalau tanggal awal diisi, mutasi sebelum tanggal itu diringkas jadi baris Saldo Awal di tiap akun (dipakai tab Buku Besar).
Dipakai tab Saldo Bulanan saja.
Report Balance Sheet
Neraca disusun otomatis dari General Journal secara kumulatif sejak baris paling awal s.d. akhir bulan terpilih (bukan hanya bulan itu, beda dgn Laba Rugi) mengikuti struktur Chart of Account ESB (Aset → Liabilitas → Ekuitas), dilengkapi pengelompokan Lancar/Tidak Lancar dari Master COA (Setting → Chart of Account) bila sudah diunggah. Baris "Laba (Rugi) Berjalan" di Ekuitas memakai angka Net Profit kumulatif yang sama persis dgn Report Profit Loss, supaya Neraca balance (Aset = Liabilitas + Ekuitas). Akun berlabel "CoA Lama" (peninggalan sistem lama, tidak dihitung ESB di laporan resminya) dikeluarkan dari Aset/Liabilitas aktif dan dipindah jadi baris "Penyesuaian Akun CoA Lama" di Ekuitas — supaya Total Aset selaras dgn ekspor resmi ESB, tanpa menyembunyikan saldonya (tetap ditampilkan, cuma dipindah). Sumber data sama dengan General Journal, tidak perlu unggah lagi.
Presisi harian, sama dgn Journal Date di General Journal/GL — bukan cuma akhir bulan.
Report Cash Flow
Laporan Arus Kas disusun otomatis dari General Journal dalam dua metode. Direct Method: tiap transaksi yang menyentuh akun Kas/Bank ("1 1 xx xx") dipetakan ke akun lawannya. Indirect Method: berangkat dari Laba (Rugi) Bersih Report Profit Loss, lalu disesuaikan dengan beban non-kas & perubahan pos Neraca. Keduanya dikelompokkan Aktivitas Operasional/Investasi/Pendanaan dan seharusnya menghasilkan Kenaikan (Penurunan) Kas yang sama. Saldo Kas Awal & Akhir diambil langsung dari Report Balance Sheet (akun Kas dan Bank) supaya selalu sinkron — bukan dihitung ulang terpisah. Tab Direct & Indirect: klik ▶ di tiap akun utk lihat detail transaksinya. Tab Pivot Sumber Dana: klik nama akun/angkanya utk lihat mutasinya di General Ledger. Sumber data sama dengan General Journal, tidak perlu unggah lagi.
s.d.
Sama dgn filter Journal Date di General Journal/GL/Profit Loss — rentang ini menentukan periode arus kas. Saldo Kas Awal diambil per tanggal sehari sebelum tanggal awal ini.
Dashboard Control Activities & Financial Highlight
Approval: Report yang perlu persetujuan Anda sekarang (Admin melihat semua yang belum lengkap approval-nya). Status Control Activities: posisi setiap kontrol per periode & entitas, termasuk progres dan daily stand-up. Status Financial Highlight: posisi laporan Analisa Pendapatan, dari belum dimulai sampai approved.
Perlu tindakan Anda
Memuat…
Memuat...
Status laporan Financial Highlight
Analisa Pendapatan, %HPP, Biaya OpEx, Other Income & Expense, Tax, dan Net Profit per entitas.
Memuat…
Status per periode & entitas
Status Report setiap Control Activity per periode.
Memuat...
Memuat...
Memuat...
Pengeluaran Antar Cabang
Pilih entitas & periode untuk mulai.
Tersimpan otomatis · terlihat oleh tim
s.d.
Periode menandai titik nilai di Risk Matrix. Tanggal otomatis satu bulan penuh; ubah bila Cut Off Audit berbeda.
Tentang kontrol iniTujuan, event risiko & aturan materialitas+
Tujuan strategis
Menjamin efisiensi rantai pasok agar operasional dan kitchen selalu memiliki bahan baku segar tepat waktu, mendukung cita rasa khas dan pelayanan legendaris.
Tujuan operasional
Menjamin kecepatan dan ketepatan pengiriman bahan sesuai permintaan kitchen dengan sistem permintaan.
Tujuan kepatuhan
Memastikan seluruh transaksi pengeluaran dicatat dan disetujui sesuai SOP perusahaan.
Tujuan pelaporan
Menyediakan laporan pemakaian bahan baku secara harian dan mingguan untuk analisis efisiensi.
Jangka waktu
Bulan berjalan
Event Identification & Risk Assessment
No
Nama
Catatan prosedur
Pilih entitas & rentang tanggal dulu.
Ceklist per tanggal
Apakah pengeluaran antar cabang pada tanggal ini tercatat & disetujui sesuai SOP?
Control Activities — Pengeluaran Daging dari Gudang ke Kitchen
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin ketersediaan daging berkualitas di kitchen secara tepat waktu untuk mendukung cita rasa khas dan pelayanan legendaris.
Tujuan Operasional: Memastikan pengeluaran daging dari gudang ke kitchen sesuai kebutuhan produksi, tercatat dan terverifikasi secara akurat.
Tujuan Kepatuhan: Memastikan seluruh transaksi pengeluaran daging dicatat dan disetujui sesuai SOP perusahaan, termasuk kesesuaian destination location dengan gudang asalnya.
Tujuan Pelaporan: Menyediakan laporan pengeluaran & selisih daging secara berkala untuk analisis efisiensi dan pengendalian biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transfer Report
Unggah Transfer Report (Report Mode "Flow") dari ESB utk entitas & periode yg dipilih di atas — Transfer Date/Product Name/Transfer Qty pada tabel di bawah terisi otomatis dari sini (cuma produk berawalan GB-DG yg ditampilkan). Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal); Total Pengambilan Daging & Nilai ikut terbentuk otomatis begitu Receipt Qty tiap baris diisi.
📂
Klik atau tarik file Transfer Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Pengeluaran Daging per Tanggal & Produk
Satu baris per Transfer Date + Product Name (awalan GB-DG) dlm rentang yang dipilih di atas. Transfer Qty dari Transfer Report yg diunggah; isi Receipt Qty hasil reperforming di kitchen. Difference = Receipt Qty − Transfer Qty.
Pengeluaran Daging per Tanggal & Produk Tidak ada SR
Pengeluaran daging yang tidak ada SR-nya (tidak tercatat di Transfer Report). Kolom sama dengan tabel di atas, tapi Transfer Qty diisi manual. Difference = Receipt Qty − Transfer Qty. Product Name bisa diketik utk mencari (produk awalan GB-DG dari Setting → Master Product).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Form SR Sistem Telah Diotorisasi Sesuai dengan Kewenangannya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap perpindahan barang antar gudang/kitchen berlangsung di bawah kendali yang sah untuk melindungi aset perusahaan.
Tujuan Operasional: Memastikan setiap form Simple Transfer (SR) yang terbentuk di sistem diotorisasi oleh pihak yang berwenang sebelum dieksekusi.
Tujuan Kepatuhan: Memastikan otorisasi form SR di sistem sesuai dengan matriks kewenangan/SOP perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat otorisasi form SR secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Authorize Simple Transfer saja, tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Simple Transfer per Baris
Satu baris per otorisasi (Authorize Simple Transfer) dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Origin/Destination Location ID msh ditampilkan sbg ID mentah (pemetaan ke nama Gudang menyusul). Kolom Kesesuaian DIHITUNG OTOMATIS: Sudah Sesuai kalau Created By & Authorize By baris itu keduanya berwenang menurut Setting → Log Report, selain itu Belum Sesuai — inilah yang dipakai menghitung Nilai (satu tanggal dihitung sesuai kalau SEMUA otorisasi tanggal itu sesuai).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Barang SR dari Gudang ke Kitchen Sesuai dengan Penempatan Gudangnya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin rencana produksi & food cost tidak terganggu oleh kesalahan pengiriman barang antar gudang.
Tujuan Operasional: Memastikan barang yang dikirim (SR) dari gudang besar ke gudang kitchen sesuai dengan penempatan gudangnya (Origin sejenis ke Destination sejenis).
Tujuan Kepatuhan: Memastikan pengiriman barang antar gudang sesuai dengan SOP penempatan gudang perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat kesesuaian penempatan gudang secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Authorize Simple Transfer saja, tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini (data mentah yg sama dengan "Memastikan Form SR Sistem Diotorisasi" — unggah di salah satu halaman, baris terpakai bersama di keduanya). Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Simple Transfer per Baris
Satu baris per otorisasi (Authorize Simple Transfer) dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom Kesesuaian DIHITUNG OTOMATIS: Sudah Sesuai kalau pasangan Origin Location & Destination Location baris itu sesuai dengan settingan (Setting → Log Report), selain itu Belum Sesuai — inilah yang dipakai menghitung Nilai (satu tanggal dihitung sesuai kalau SEMUA otorisasi tanggal itu sesuai). Otorisasi yang transaksinya sudah dihapus bisa ditandai Tidak Masuk Materialitas di kolom Materialitas: baris itu tidak ikut dihitung di Nilai dan pindah ke tab Tidak Masuk Materialitas.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Barang SR dari Gudang ke Kitchen Tidak Ada yang Terpending
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin rencana produksi tidak terganggu oleh keterlambatan pengiriman barang antar gudang.
Tujuan Operasional: Memastikan setiap Goods Delivery (SR) dari gudang ke kitchen tuntas diotorisasi, tidak ada yang terpending.
Tujuan Kepatuhan: Memastikan seluruh SR yang terpending di sistem sudah dilengkapi SR manual sesuai SOP perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat SR yang terpending secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Good Delivery Recapitulation Report With Value
Unggah Good Delivery Recapitulation Report With Value dari ESB (Report Mode "Group by Product With Value") utk entitas & periode yg dipilih di atas — Goods Delivery yang statusnya BUKAN Authorized otomatis muncul di tabel bawah. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal); kalau status sebuah SR berubah di ESB (mis. sudah diotorisasi belakangan), unggah ulang laporan terbarunya — status TERBARU yang otomatis dipakai.
📂
Klik atau tarik file Good Delivery Recapitulation Report With Value ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Goods Delivery (SR) yang Bukan Authorized
Satu baris per Goods Delivery Number (SR) yang statusnya BUKAN Authorized dlm rentang yang dipilih di atas, dari Good Delivery Recapitulation Report With Value yg diunggah. Tandai per baris Pending (kalau memang belum ada SR manual pendukungnya) atau Tidak Pending (kalau SR manualnya sudah ada) — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "ada yang terpending" kalau minimal SATU baris tanggal itu ditandai Pending). SR yang statusnya Authorized tidak ditampilkan di sini (otomatis dianggap tidak terpending).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi SR Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap pembatalan (delete) transaksi SR di sistem berlangsung di bawah kendali yang sah & terdokumentasi.
Tujuan Operasional: Memastikan setiap delete transaksi SR di sistem dilengkapi berita acara yang menjelaskan alasan pembatalannya.
Tujuan Kepatuhan: Memastikan berita acara delete SR sesuai dengan SOP dokumentasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete SR & kelengkapan berita acaranya secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Delete Simple Transfer saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Simple Transfer per Baris
Satu baris per Delete Simple Transfer dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Isi Additional Info (alasan delete, ketikan bebas auditor) lalu tandai Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Proses Pengiriman Barang dari Gudang ke Kitchen Sesuai dengan SOP
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin pengambilan dan pengiriman barang dari gudang ke kitchen dilakukan tertib sesuai SOP (waktu approve, waktu pengambilan, hingga penerimaan barang di kitchen), sehingga mendukung akurasi food cost dan kelancaran operasional kitchen sehari-hari.
Tujuan Operasional: Memastikan proses pengiriman barang (SR) dari gudang ke kitchen dilakukan sesuai dengan SOP yang berlaku, termasuk kesesuaian waktu approve dan pengambilan barang.
Tujuan Kepatuhan: Memastikan seluruh proses pengiriman barang dari gudang ke kitchen dipatuhi sesuai SOP perusahaan yang berlaku, termasuk pengecualian yang diperbolehkan.
Tujuan Pelaporan: Menyediakan hasil uji kendali kesesuaian SOP pengiriman gudang ke kitchen secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ceklist Uji Kendali Kesesuaian SOP per Tanggal
Satu baris per tanggal dalam rentang yang dipilih di atas. Kolom Additional Info diisi manual (ketikan bebas) sbg keterangan kenapa tidak sesuai SOP, tidak mempengaruhi Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Form SR ERP Telah Diapproval Sesuai dengan Waktunya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin proses approval form SR di ERP berjalan tepat waktu sesuai jadwal pengambilan barang per jenis gudang, sehingga mendukung kelancaran pengambilan barang ke kitchen dan akurasi pengendalian food cost.
Tujuan Operasional: Memastikan form SR di ERP diapprove sesuai dengan waktu maksimal pengambilan yang berlaku per jenis gudang.
Tujuan Kepatuhan: Memastikan proses approval SR sesuai dengan SOP jam pengambilan barang yang berlaku di perusahaan.
Tujuan Pelaporan: Menyediakan riwayat ketepatan waktu approval SR secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Authorize Simple Transfer saja, tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini (data mentah yg sama dengan "Memastikan Form SR Sistem Diotorisasi" & "Memastikan Barang SR Sesuai Penempatan Gudang" — unggah di salah satu halaman, baris terpakai bersama di ketiganya). Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Simple Transfer per Baris
Satu baris per otorisasi (Authorize Simple Transfer) dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom Overtime DIHITUNG OTOMATIS dari jam Authorized Date dibanding Waktu Maksimal Pengambilan per Gudang (Setting → Log Report) — boleh diganti manual per baris, isi Additional Info sbg dasar kalau diganti. Inilah yang dipakai menghitung Nilai (satu tanggal dihitung sesuai/tidak overtime kalau SEMUA otorisasi tanggal itu tidak overtime). Kolom Print Date (dd/mm/yyyy) & Print Time (HH:MM, 24 jam) diisi manual dari kertas SR yang dicetak — terhubung dgn CA "Memastikan Hasil Print SR Sistem Telah Dilakukan TTD" (diisi di salah satu, otomatis ikut terisi di CA satunya); Variance = Print Time − Authorized Date, merah bila plus, hijau bila nol/minus — informasi audit, tidak mempengaruhi Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Hasil Print SR Sistem Telah Dilakukan TTD
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap SR yang di-print memiliki bukti otorisasi fisik (TTD) yang sah, mendukung akurasi food cost dan pengendalian pengambilan barang dari gudang ke kitchen.
Tujuan Operasional: Memastikan setiap hasil print SR dari sistem dilengkapi tanda tangan (TTD) pihak yang berwenang sebelum barang diambil dari gudang.
Tujuan Kepatuhan: Memastikan kelengkapan TTD pada print SR sesuai dengan SOP dokumentasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat kelengkapan TTD pada print SR secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Authorize Simple Transfer saja, tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini (data mentah yg sama dengan "Memastikan Form SR ERP Telah Diapproval Sesuai dengan Waktunya" & CA lain yg numpang Transaction Log Report yg sama — unggah di salah satu halaman, baris terpakai bersama). Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Simple Transfer per Baris
Satu baris per otorisasi (Authorize Simple Transfer) dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Tandai Ada TTD atau Tidak Ada TTD per baris (cek fisik dokumen print SR) — SEMUA baris wajib ditandai sebelum Nilai bisa disimpulkan. Inilah yang dipakai menghitung Nilai (satu tanggal dihitung "Ada TTD" kalau SEMUA otorisasi tanggal itu Ada TTD). Tandai Sudah Dihapus kalau transaksinya sudah dihapus dari sistem — baris ini OTOMATIS DIKECUALIKAN dari perhitungan Nilai (tak ikut menandai tanggalnya "Tidak Ada TTD", dan kalau SEMUA baris tanggal itu Sudah Dihapus, tanggalnya tak ikut dihitung sama sekali). Kolom Print Date (dd/mm/yyyy) & Print Time (HH:MM, 24 jam) diisi manual dari kertas SR yang dicetak (terhubung dgn CA "Memastikan Form SR ERP Telah Diapproval Sesuai dengan Waktunya" -- diisi di salah satu, otomatis ikut terisi di CA satunya); Variance = Print Time − Authorized Date, merah bila plus (dicetak setelah diotorisasi), hijau bila nol/minus — informasi audit, tidak mempengaruhi Nilai. Kolom Additional Info diisi manual (ketikan bebas) sbg keterangan siapa yang tidak TTD, tidak mempengaruhi Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Barang Expired
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Baris Barang Expired di bawah TIDAK py tanggal per baris (murni per entitas & periode) — rentang tanggal di sini cuma dipakai utk aturan Cut Off Audit >45 hari kerja.
Tujuan Strategis: Menjamin barang persediaan yang disajikan ke pelanggan selalu dalam kondisi layak konsumsi, mendukung reputasi kualitas produk dan mencegah risiko kesehatan pelanggan.
Tujuan Operasional: Memastikan barang expired di gudang teridentifikasi, tercatat, dan ditangani sesuai SOP (metode FEFO, berita acara, dan otorisasi yang sesuai).
Tujuan Kepatuhan: Memastikan penanganan barang expired sesuai dengan SOP dokumentasi dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat nilai barang expired secara berkala untuk analisis kepatuhan pengendalian internal dan pengendalian food cost.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Tambah Baris Barang Expired
Sub Category & Product Name bisa diketik utk mencari (dropdown search), diambil dari Setting → Master Product — Product Name otomatis difilter sesuai Sub Category yang dipilih. Value = Price × Qty, dihitung otomatis.
Baris Barang Expired Tersimpan
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris. Total Value seluruh baris inilah yang dipakai menghitung Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Stock Opname Gudang
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Baris Stock Opname di bawah TIDAK py tanggal per baris (murni per entitas & periode) — rentang tanggal di sini cuma dipakai utk aturan Cut Off Audit >45 hari kerja.
Tujuan Strategis: Menjamin keakuratan data persediaan sebagai dasar pengambilan keputusan operasional dan mencegah kerugian akibat kehilangan atau penyimpangan barang yang tidak terdeteksi.
Tujuan Operasional: Memastikan stock opname di seluruh gudang (Kering, Basah, Central) dilaksanakan sesuai SOP (metode double count, blind count, hitung per rak), serta selisih yang ditemukan teridentifikasi dan ditindaklanjuti.
Tujuan Kepatuhan: Memastikan pelaksanaan & dokumentasi stock opname sesuai dengan SOP perhitungan fisik dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat selisih stock opname secara berkala untuk analisis kepatuhan pengendalian internal dan pengendalian persediaan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Tambah Baris — Gudang Kering
Sub Category & Product Name bisa diketik utk mencari (dropdown search), diambil dari Setting → Master Product — Product Name otomatis difilter sesuai Sub Category yang dipilih. Variance = Qty On Hand − Qty System, Value = Price × Variance, dihitung otomatis.
Baris Stock Opname Tersimpan — Gudang Kering
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris.
Tambah Baris — Gudang Basah
Sub Category & Product Name bisa diketik utk mencari (dropdown search), diambil dari Setting → Master Product — Product Name otomatis difilter sesuai Sub Category yang dipilih. Variance = Qty On Hand − Qty System, Value = Price × Variance, dihitung otomatis.
Baris Stock Opname Tersimpan — Gudang Basah
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris.
Tambah Baris — Gudang Central
Sub Category & Product Name bisa diketik utk mencari (dropdown search), diambil dari Setting → Master Product — Product Name otomatis difilter sesuai Sub Category yang dipilih. Variance = Qty On Hand − Qty System, Value = Price × Variance, dihitung otomatis.
Baris Stock Opname Tersimpan — Gudang Central
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris.
Total Selisih Stock Opname — Gabungan 3 Gudang
Subtotal Value Gudang Kering + Gudang Basah + Gudang Central (selisih lebih & kurang saling mengurangi) — nilai absolut total inilah yang dipakai menghitung Nilai di atas.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Stock Opname Daging Gudang Kitchen
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Baris Stock Opname Daging di bawah TIDAK py tanggal per baris (murni per entitas & periode) — rentang tanggal di sini cuma dipakai utk aturan Cut Off Audit >45 hari kerja.
Tujuan Strategis: Menjamin keakuratan data persediaan daging di Gudang Kitchen sebagai dasar pengendalian food cost dan mencegah kerugian akibat kehilangan atau penyimpangan barang yang tidak terdeteksi.
Tujuan Operasional: Memastikan stock opname daging di Gudang Kitchen dilaksanakan sesuai SOP (perhitungan pagi hari sebelum kegiatan operasional dimulai, metode lembar tanpa angka saldo, reperforming), serta selisih yang ditemukan teridentifikasi dan ditindaklanjuti.
Tujuan Kepatuhan: Memastikan pelaksanaan dan dokumentasi stock opname daging sesuai dengan SOP metode perhitungan fisik dan waktu pelaksanaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat selisih stock opname daging secara berkala untuk analisis kepatuhan pengendalian internal dan pengendalian food cost.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Tambah Baris Stock Opname Daging
Category selalu "Persediaan Daging" (terkunci). Product Name bisa diketik utk mencari (dropdown search), diambil dari Setting → Master Product — sudah difilter ke Category "Persediaan Daging" saja. Variance = Qty On Hand − Qty System, Value = Price × Variance, dihitung otomatis. Masuk Perhitungan menentukan apakah baris ini ikut dihitung ke Nilai/Risk Matrix — ubah lagi kapan saja lewat kolom yg sama di tabel baris tersimpan di bawah.
Baris Stock Opname Daging Tersimpan
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris. Total selisih = jumlah Value seluruh baris (selisih lebih & kurang saling mengurangi) — nilai absolut total inilah yang dipakai menghitung Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Stock Opname Selain Gudang Besar dan Daging Gudang Kitchen
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Baris Stock Opname di bawah TIDAK py tanggal per baris (murni per entitas & periode) — rentang tanggal di sini cuma dipakai utk aturan Cut Off Audit >45 hari kerja.
Tujuan Strategis: Menjamin keakuratan data persediaan barang di luar Gudang Besar dan Gudang Kitchen Daging sebagai dasar pengendalian aset dan mencegah kerugian akibat kehilangan atau penyimpangan barang yang tidak terdeteksi.
Tujuan Operasional: Memastikan stock opname barang selain kategori Gudang Besar dan Daging Gudang Kitchen dilaksanakan sesuai SOP (perhitungan pagi hari sebelum kegiatan operasional dimulai, metode lembar tanpa angka saldo, reperforming barang keluar dibandingkan penjualan sistem), serta selisih yang ditemukan teridentifikasi dan ditindaklanjuti.
Tujuan Kepatuhan: Memastikan pelaksanaan dan dokumentasi stock opname ini sesuai dengan SOP metode perhitungan fisik dan waktu pelaksanaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat selisih stock opname ini secara berkala untuk analisis kepatuhan pengendalian internal dan pengendalian persediaan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Tambah Baris Stock Opname
Product Name diketik manual (tanpa dropdown Master Product). Variance = Qty On Hand − Qty System, Value = Price × Variance, dihitung otomatis.
Baris Stock Opname Tersimpan
Ubah langsung di kolomnya (tersimpan otomatis begitu pindah fokus) atau hapus per baris. Total selisih = jumlah Value seluruh baris (selisih lebih & kurang saling mengurangi) — nilai absolut total inilah yang dipakai menghitung Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Stock Opname Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap pembatalan (delete) Stock Opname di sistem berlangsung di bawah kendali yang sah & terdokumentasi.
Tujuan Operasional: Memastikan setiap delete Stock Opname di sistem dilengkapi berita acara yang menjelaskan alasan pembatalannya.
Tujuan Kepatuhan: Memastikan berita acara delete Stock Opname sesuai dengan SOP dokumentasi & kewenangan perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Stock Opname & kelengkapan berita acaranya secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Delete Stock Opname (Transaction Type "Inventory Adjustment") saja, kartu per Reference Number di bawah terisi otomatis dari sini (termasuk Before/After Value per produk). Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Stock Opname per Reference Number
Satu kartu per Reference Number Delete Stock Opname dlm rentang yang dipilih di atas, dgn Before Value & After Value produk berdampingan supaya gampang dibandingkan. Isi Additional Info (alasan delete) lalu tandai Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Tidak Terdapat Saldo Pemakaian dengan Qty Plus
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Rentang tanggal ini jg yg dipakai memfilter Stock Opname Date & Journal Date (Simple Transfer) di bawah -- tidak berlaku aturan Cut Off Audit >45 hari kerja di sini krn Nilai dihitung dari persentase, bukan jumlah hari/tanggal.
Tujuan Strategis: Menjamin keakuratan data pemakaian persediaan sebagai dasar pengendalian food cost dan mencegah kerugian akibat pencatatan atau pemakaian barang yang tidak wajar.
Tujuan Operasional: Memastikan setiap saldo pemakaian dengan Difference Value plus (stok bertambah saat seharusnya berkurang) teridentifikasi dan ditelusuri penyebabnya.
Tujuan Kepatuhan: Memastikan pencatatan pemakaian persediaan sesuai dengan SOP stock opname dan tidak ada anomali qty plus yang dibiarkan tanpa analisa.
Tujuan Pelaporan: Menyediakan riwayat saldo pemakaian dengan qty plus secara berkala untuk analisis kepatuhan pengendalian internal dan pengendalian food cost.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Saldo Pemakaian dengan Qty Plus (Stock Opname Report)
Baris Stock Opname Report yg Difference Value-nya POSITIF dlm rentang yang dipilih di atas. Kalau ditemukan, lihat history di stock list utk mengetahui kapan pemakaian dgn qty plus itu terjadi supaya bisa dianalisa (poin 1 Catatan Prosedur). Centang Tidak Masuk Perhitungan utk baris yg menurut aturan perusahaan bukan anomali qty plus sungguhan (mis. trimingan) — Total & Nilai di atas otomatis menyesuaikan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Stock Opname Sesuai dengan Dokumen Sumber Stock Opname
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). Rentang tanggal ini jg yg dipakai memfilter Stock Opname Date di bawah — berlaku aturan Cut Off Audit >45 hari kerja (syarat Major dikali kelipatan otomatis saat disimpan).
Tujuan Strategis: Menjamin keakuratan pencatatan persediaan sebagai dasar pelaporan keuangan yang andal dan pengambilan keputusan operasional yang tepat.
Tujuan Operasional: Memastikan hasil input stock opname di sistem sesuai dengan dokumen sumber fisik (kertas hasil stock opname) yang ditandatangani oleh pelaksana dan manager.
Tujuan Kepatuhan: Memastikan proses input stock opname ke sistem sesuai dengan SOP dokumentasi dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat kesesuaian stock opname sistem dengan dokumen sumber secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Stock Opname vs Dokumen Sumber
SEMUA baris Stock Opname Report dlm rentang yang dipilih di atas. Isi kolom Stock Report dari dokumen sumber fisik — kalau hasilnya SAMA semua dgn Opname Stock, klik tombol di bawah utk mempercepat pengisian, lalu koreksi manual baris yang ternyata beda.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Item Jurnal Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap pembatalan (delete) transaksi Item Jurnal di sistem berlangsung di bawah kendali yang sah & terdokumentasi.
Tujuan Operasional: Memastikan setiap delete transaksi Item Jurnal di sistem dilengkapi berita acara yang menjelaskan alasan pembatalannya.
Tujuan Kepatuhan: Memastikan berita acara delete Item Jurnal sesuai dengan SOP dokumentasi dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Item Jurnal & kelengkapan berita acaranya secara berkala untuk analisis kepatuhan pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Delete Item Journal saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Item Jurnal per Baris
Satu baris per Delete Item Jurnal dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom Additional Info (Sistem) otomatis terisi dari Before Value (catatan yg diketik saat Item Jurnal itu masih ada) — isi Additional Info (alasan delete hasil tanya jawab auditor, ketikan bebas) lalu tandai Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Form PR Diotorisasi Sesuai Kewenangan dan Waktunya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin proses pembelian berlangsung di bawah kendali yang sah untuk melindungi aset perusahaan dan mendukung efisiensi anggaran.
Tujuan Operasional: Memastikan setiap Purchase Request (PR) yang terbentuk di sistem diotorisasi oleh pihak yang berwenang sebelum diproses lebih lanjut.
Tujuan Kepatuhan: Memastikan otorisasi Purchase Request di sistem sesuai dengan matriks kewenangan/SOP pembelian perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat otorisasi Purchase Request secara berkala untuk analisis kepatuhan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Add Purchase Request & Authorize Purchase Request (digabung per No. PR), tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Purchase Request per Baris
Satu baris per No. PR dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Created Date berlatar kuning kalau dibuat pada jam kerja (08:00-17:00). Authorized Date bergaris oranye kalau tanggalnya melebihi Created Date (Aging > 0 hari). Kolom Aging = selisih TANGGAL (kalender) Authorized Date dikurangi Created Date, jam-of-day TAK dihitung (14/7 23:59 → 15/7 00:01 tetap 1 hari). Kolom Kesesuaian DIHITUNG OTOMATIS (Sesuai kalau Created By & Authorized By baris itu keduanya berwenang menurut Setting → Log Report Pembelian, selain itu Tidak Sesuai) TAPI bisa DIUBAH MANUAL lewat dropdown-nya — begitu diubah manual, warnanya berganti ungu supaya jelas bukan hasil sistem. Kolom Keterangan menyebut bagian yang tidak sesuai menurut penilaian otomatis (Create dan/atau Approve); kolom Additional Info diisi manual auditor sbg alasan/dasar kalau Kesesuaian di-adjust manual. Kesesuaian EFEKTIF (manual menang kalau diisi) inilah yang dipakai menghitung Nilai (satu tanggal dihitung tidak sesuai kalau minimal SATU otorisasi tanggal itu Tidak Sesuai).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Form PO Diotorisasi Sesuai Kewenangan dan Waktunya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin proses pembelian berlangsung di bawah kendali yang sah untuk melindungi aset perusahaan dan mendukung efisiensi anggaran.
Tujuan Operasional: Memastikan setiap Purchase Order (PO) yang terbentuk di sistem diotorisasi oleh pihak yang berwenang sebelum diproses lebih lanjut ke supplier.
Tujuan Kepatuhan: Memastikan otorisasi Purchase Order di sistem sesuai dengan matriks kewenangan/SOP pembelian perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat otorisasi Purchase Order secara berkala untuk analisis kepatuhan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Approve Purchase (Transaction Type Purchase Order), tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Purchase Order per Baris
Satu baris per No. PO dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Created Date berlatar kuning kalau dibuat pada jam kerja (08:00-17:00). Authorized Date bergaris oranye kalau tanggalnya melebihi Created Date (Aging > 0 hari). Kolom Aging = selisih TANGGAL (kalender) Authorized Date dikurangi Created Date, jam-of-day TAK dihitung. Kolom Kesesuaian DIHITUNG OTOMATIS (Sesuai kalau Created By & Authorized By baris itu keduanya berwenang menurut Setting → Log Report Pembelian, selain itu Tidak Sesuai) TAPI bisa DIUBAH MANUAL lewat dropdown-nya — begitu diubah manual, warnanya berganti ungu supaya jelas bukan hasil sistem. Kolom Keterangan menyebut bagian yang tidak sesuai menurut penilaian otomatis (Create dan/atau Approve); kolom Additional Info diisi manual auditor sbg alasan/dasar kalau Kesesuaian di-adjust manual. Kesesuaian EFEKTIF (manual menang kalau diisi) inilah yang dipakai menghitung Nilai (satu tanggal dihitung tidak sesuai kalau minimal SATU otorisasi tanggal itu Tidak Sesuai).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Form GR Diotorisasi Sesuai Kewenangan dan Waktunya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin proses pembelian berlangsung di bawah kendali yang sah untuk melindungi aset perusahaan dan mendukung efisiensi anggaran.
Tujuan Operasional: Memastikan setiap Goods Receipt (GR) yang terbentuk di sistem diotorisasi oleh pihak yang berwenang sebelum barang diakui diterima.
Tujuan Kepatuhan: Memastikan otorisasi Goods Receipt di sistem sesuai dengan matriks kewenangan/SOP pembelian perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat otorisasi Goods Receipt secara berkala untuk analisis kepatuhan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Approve Goods Receipt (Transaction Type Goods Receipt), tabel dokumentasi per-otorisasi di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Otorisasi Goods Receipt per Baris
Satu baris per No. GR dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Created Date berlatar kuning kalau dibuat pada jam kerja (08:00-17:00). Authorized Date bergaris oranye kalau tanggalnya melebihi Created Date (Aging > 0 hari). Kolom Aging = selisih TANGGAL (kalender) Authorized Date dikurangi Created Date, jam-of-day TAK dihitung. Kolom Kesesuaian DIHITUNG OTOMATIS (Sesuai kalau Created By & Authorized By baris itu keduanya berwenang menurut Setting → Log Report Pembelian, selain itu Tidak Sesuai) TAPI bisa DIUBAH MANUAL lewat dropdown-nya — begitu diubah manual, warnanya berganti ungu supaya jelas bukan hasil sistem. Kolom Keterangan menyebut bagian yang tidak sesuai menurut penilaian otomatis (Create dan/atau Approve); kolom Additional Info diisi manual auditor sbg alasan/dasar kalau Kesesuaian di-adjust manual. Kesesuaian EFEKTIF (manual menang kalau diisi) inilah yang dipakai menghitung Nilai (satu tanggal dihitung tidak sesuai kalau minimal SATU otorisasi tanggal itu Tidak Sesuai).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Barang yang Dibeli Sesuai dengan Alur Pendek atau Panjang
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap barang yang dibeli diproses melalui alur pembelian yang sesuai dengan karakteristiknya untuk mendukung akurasi food cost dan kelancaran rencana produksi.
Tujuan Operasional: Memastikan barang yang tidak memakai PR-PO diproses lewat Simple Transfer, barang biaya tertentu diproses lewat Simple Purchase, dan seluruh barang lainnya diproses lewat alur panjang (PR-PO) sesuai SOP.
Tujuan Kepatuhan: Memastikan pemilihan alur pembelian (Simple Transfer/Simple Purchase/PR-PO) sesuai dengan SOP pembelian perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat kepatuhan alur pembelian secara berkala untuk analisis pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Purchase Item Summary Report
Laporan ini TIDAK punya kolom tanggal per baris (ringkasan per periode) -- pilih dulu Tanggal di bawah utk mewakili hari sampling yang sedang diperiksa, baru unggah file Purchase Item Summary Report dari ESB utk entitas yg dipilih di atas. Baris menumpuk antar unggahan (boleh unggah utk beberapa tanggal berbeda, tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Purchase Item Summary Report ke sini
Pilih Entitas & Tanggal dulu di atas
Purchase Item Summary per Baris
Satu baris per Product+Transaction Type per tanggal sampling yang diunggah, dari Purchase Item Summary Report. Kolom Additional Info diisi manual (dropdown Sesuai/Tidak Sesuai) sesuai Catatan Prosedur — SEMUA baris wajib diisi dulu sebelum Nilai bisa disimpulkan (satu tanggal dihitung Sesuai kalau SEMUA barisnya ditandai Sesuai).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Nota Telah Ditandatangani oleh 2 Orang Penerima (Admin Gudang & Head Kitchen)
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). "Tampilkan" akan memuat/menyegarkan data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel Release Payment di bawah (boleh diisi satu sisi saja) — Nilai & rekap tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin perusahaan hanya membayar barang yang benar-benar sudah diterima dalam kondisi layak — setiap penerimaan dari supplier diverifikasi bersama oleh pihak penerima sebelum pembayarannya dilepas, melindungi perusahaan dari pembayaran atas barang yang belum diterima maupun klaim barang rusak atau tidak layak di kemudian hari.
Tujuan Operasional: Memastikan nota/dokumen penerimaan barang (Goods Receipt/Simple Purchase) yang mendasari Release Payment ditandatangani oleh Admin Gudang dan Head Kitchen sebagai bukti fisik barang sudah datang dan kondisinya sudah diperiksa kedua pihak, sebelum pembayaran ke supplier diproses.
Tujuan Kepatuhan: Memastikan seluruh Release Payment atas pembelian barang (bukan Disbursement) hanya dilepas atas barang yang sudah diterima dan dilengkapi tanda tangan penerima, sesuai SOP serah terima barang dan SOP pembayaran perusahaan.
Tujuan Pelaporan: Menyediakan riwayat kelengkapan tanda tangan penerima atas setiap Release Payment secara berkala, untuk analisis risiko pembayaran barang yang belum diterima dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Release Payment per Nota (dari General Journal)
Satu baris per rantai Release Payment yang mengandung Goods Receipt, Simple Purchase, atau Purchase Invoice bahan (akun Pemakaian 5 2 01 — sayur, buah, air galon, food non-stock) (Additional Info TIDAK berawalan "DS"), dari data General Journal yang sudah diunggah utk entitas ini. Centang TTD Admin Gudang & TTD Head Kitchen di sini (SAMA tanda dgn yang ada di menu General Journal, tersimpan bersama) — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "Sesuai" kalau SEMUA Release Payment tanggal itu sudah lengkap dua tanda tangan).
Rekap Tanggal Belum Lengkap TTD
Tanggal (Journal Date) yang MASIH punya minimal satu Release Payment belum lengkap TTD Admin Gudang & Head Kitchen -- inilah yang membuat tanggal itu dihitung "Tidak Sesuai" di Nilai. Klik nomor Release Payment di tabel atas (atau centang "Tampilkan hanya yang belum lengkap TTD") utk melengkapinya.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Proses Penerimaan Barang Sesuai dengan SOP
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap barang yang dibeli diterima dalam kondisi, jumlah, dan spesifikasi yang sesuai pesanan, sehingga kualitas bahan baku terjaga untuk mendukung cita rasa khas dan akurasi food cost.
Tujuan Operasional: Memastikan proses penerimaan barang dari supplier dilakukan sesuai SOP — berdasarkan PO yang sah, dicek fisik saat datang, dan dicatat pada tanggal yang sebenarnya (tanpa backdate).
Tujuan Kepatuhan: Memastikan seluruh proses penerimaan barang dipatuhi sesuai SOP penerimaan barang perusahaan yang berlaku, termasuk kesesuaian print date PO dengan waktu penerimaan.
Tujuan Pelaporan: Menyediakan hasil uji kendali kesesuaian SOP penerimaan barang secara berkala untuk analisis kepatuhan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ceklist Uji Kendali Kesesuaian SOP Penerimaan Barang per Tanggal
Satu baris per tanggal dalam rentang yang dipilih di atas. Kolom Additional Info diisi manual (ketikan bebas) sbg keterangan kenapa tidak sesuai SOP, tidak mempengaruhi Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Barang yang Diterima Memiliki Nilai (Tidak 0)
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin nilai persediaan yang tercatat mencerminkan harga perolehan yang sebenarnya, sehingga food cost dan laporan keuangan tidak over atau under stated.
Tujuan Operasional: Memastikan setiap barang yang diterima melalui Goods Receipt tercatat dengan nilai/harga yang benar (tidak Rp 0), sesuai PO dan harga yang disepakati dengan supplier.
Tujuan Kepatuhan: Memastikan pencatatan penerimaan barang di sistem sesuai SOP pembelian dan kebijakan penilaian persediaan perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan daftar penerimaan barang bernilai 0 secara berkala untuk analisis akurasi nilai persediaan dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Item Goods Receipt per Rentang Cut Off
Satu baris per item (produk) Goods Receipt dalam rentang tanggal yang dipilih, dari Goods Receipt Recapitulation Report. Tanggal diambil dari nomor GR; baris Simple Transfer (STF) di laporan yang sama tidak ikut. Item dengan Total Rp 0 ditandai merah — inilah yang dipakai menghitung Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Pembelian antara Nota dengan Buku Kas Telah Sesuai
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total selisih tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap rupiah yang dibayarkan untuk pembelian sesuai dengan nilai transaksi sebenarnya, sehingga tidak ada kebocoran kas akibat pembayaran lebih maupun pencatatan biaya yang keliru.
Tujuan Operasional: Memastikan nilai pembelian yang dicatat dan dibayarkan melalui Release Payment (buku kas/bank) sama dengan nilai pada nota/dokumen pembelian dari supplier, termasuk ketepatan tanggal, nominal, dan deskripsi barang.
Tujuan Kepatuhan: Memastikan setiap pembayaran pembelian didukung nota yang sah dan diproses sesuai SOP pembelian dan pembayaran perusahaan, mulai dari PR, PO, penerimaan barang, Purchase Invoice, hingga pembayaran.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi nota terhadap buku kas beserta total selisihnya secara berkala, untuk analisis akurasi nilai pembayaran dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Selisih Nota vs Buku Kas
Dihitung dari SELURUH Release Payment pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Total Selisih = jumlah nilai absolut Variance per nota — inilah yang dibandingkan dgn Total Pembelian utk Nilai.
Release Payment per Nota (dari General Journal)
Baris SAMA dengan CA "Memastikan Nota Ditandatangani Admin Gudang & Head Kitchen". Purchase Amount = nilai Release Payment. Centang Nilai Pembelian Sesuai kalau nota cocok — Purchase Amount Adjustment otomatis terisi sama dgn Purchase Amount. Kalau tidak dicentang, otomatis dihitung Nilai Pembelian Tidak Sesuai dan Adjustment WAJIB diisi manual sesuai nota. Variance = Adjustment − Purchase Amount. Keterangan menandai Release Payment yang Created Date-nya melewati bulan Journal Date.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Melakukan Rekonsiliasi antara Rekening dengan Pengeluaran Pembelian
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total selisih tetap dihitung dari seluruh Release Payment Bank pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap dana yang keluar dari rekening bank perusahaan benar-benar sampai ke supplier yang berhak dengan jumlah yang tepat, sehingga kas perusahaan terlindungi dari kesalahan transfer maupun potensi fraud.
Tujuan Operasional: Memastikan setiap pembayaran pembelian via bank yang tercatat di sistem (Release Payment) cocok dengan mutasi rekening koran — jumlah yang terpotong sama, dan nama serta nomor rekening penerima sesuai dengan data supplier.
Tujuan Kepatuhan: Memastikan pembayaran ke supplier hanya dilakukan ke rekening yang terdaftar di master data supplier, sesuai SOP pembayaran dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi rekening terhadap pengeluaran pembelian beserta total selisih dan ruang perbaikan penerima yang tidak sesuai secara berkala, untuk analisis pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Total Selisih Rekening vs Pengeluaran
Dihitung dari SELURUH Release Payment Bank pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Total Selisih = jumlah nilai absolut Variance — inilah yang dibandingkan dgn Total Pembelian utk Nilai.
Release Payment via Bank (dari General Journal)
Baris SAMA dengan CA "Memastikan Nota Ditandatangani Admin Gudang & Head Kitchen", hanya yang sumber dananya rekening Bank (kolom Bank). Purchase Amount = nilai Release Payment. Centang Rekonsiliasi Rekening Cocok kalau cocok dgn rekening koran — Adjustment otomatis sama dgn Purchase Amount. Centang Beneficiary name mismatch kalau nama penerima transfer bukan supplier — Adjustment otomatis 0 (dana dianggap tak sampai ke supplier). Selain itu otomatis Rekonsiliasi Rekening Tidak Cocok & Adjustment WAJIB diisi manual sesuai jumlah yang terpotong di rekening. Variance = Adjustment − Purchase Amount.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Otorisasi Tanda Terima untuk Pengeluaran Uang yang Lebih dari Rp 300.000,- dan Nota Manual
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap pengeluaran uang bernilai besar maupun pembelian dengan nota manual benar-benar diterima oleh pihak yang berhak, sehingga kas perusahaan terlindungi dari pembayaran fiktif maupun uang yang tidak sampai ke supplier.
Tujuan Operasional: Memastikan setiap Release Payment lebih dari Rp 300.000 dan setiap pembelian dengan nota manual (sayur, buah, air galon, es, non food) dilengkapi tanda terima yang memuat nama & alamat supplier, nama, tanda tangan, dan nomor HP penerima uang.
Tujuan Kepatuhan: Memastikan pengeluaran uang di atas batas Rp 300.000 dan pembelian bernota manual diotorisasi dengan tanda terima sesuai SOP pembayaran perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan daftar dan total pembayaran yang belum dilengkapi tanda terima secara berkala, untuk analisis risiko uang pembayaran yang belum sampai ke supplier dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Release Payment Tanpa Tanda Terima
Dihitung dari SELURUH Release Payment pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Persentase = total Release Payment yang TIDAK ada tanda terimanya ÷ total pembelian yang memerlukan tanda terima — inilah yang dipakai utk Nilai.
Release Payment yang Memerlukan Tanda Terima (dari General Journal)
Centang Sudah Tanda Terima kalau tanda terimanya ada & lengkap. Kalau tidak dicentang, otomatis dihitung Tidak Ada Tanda Terima — Purchase Amount-nya masuk total yang tidak ada tanda terima. Kolom Alasan menjelaskan kenapa Release Payment itu wajib tanda terima.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Hutang Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Saldo & aging hutang dihitung per tanggal s.d. (kumulatif, sama dengan Balance Sheet); total pembelian = Release Payment CA "Memastikan nota telah ditandatangani oleh 2 orang penerima" pada rentang Journal Date. Data baru dimuat & rantai transaksi dibangun saat Anda klik Tampilkan.
Tujuan Strategis: Menjaga kewajiban perusahaan kepada supplier tercatat lengkap, tepat nilai, dan dibayar tepat waktu, sehingga hubungan dengan supplier tetap sehat dan kelancaran pasokan bahan baku terjamin.
Tujuan Operasional: Memastikan setiap hutang supplier dicocokkan dengan nota hutangnya, hutang berumur lebih dari 1 bulan dikonfirmasi dan ditindaklanjuti, serta barang yang datang di akhir bulan langsung dicatat sebagai hutang pada periode tersebut.
Tujuan Kepatuhan: Memastikan pencatatan dan pembayaran hutang sesuai SOP siklus pembelian perusahaan, termasuk pembayaran barang yang masuk stock tidak menggunakan Disbursement.
Tujuan Pelaporan: Menyajikan saldo hutang supplier di Balance Sheet secara wajar — tidak ada hutang yang tidak tercatat, tercatat ganda, maupun salah supplier — beserta aging-nya sebagai dasar analisis risiko dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Hutang & Total Pembelian
Persentase = (Sub Total Hutang Lebih dari 1 Bulan + Sub Total Nota Hutang Belum Diinput) ÷ Total Pembelian — inilah yang dipakai utk Nilai. Hutang yang dicentang "Sudah Dibayar belum masuk General Journal" tidak ikut dihitung.
Hutang Supplier per Rantai Transaksi & Aging (akun 2 1 01 01, dari Balance Sheet General Journal)
Satu baris per rantai transaksi (Purchase Invoice / Disbursement / Simple Purchase s.d. Release Payment) yang saldo hutangnya belum nol per tanggal s.d. Aging = jumlah hari dari Journal Date hutang tercatat s.d. tanggal s.d.; lebih dari 30 hari = Lebih dari 1 Bulan (bisa diubah manual, lihat tombol ↻ kalau sudah pernah diubah). Centang Sudah Dibayar belum masuk General Journal kalau hutang itu sebenarnya sudah dibayar tapi pembayarannya belum tercatat — pilihan Lebih/Tidak Lebih dari 1 Bulan-nya hilang & tidak ikut dihitung.
Nota Hutang yang Belum Diinput
Tambahkan nota hutang yang ternyata belum diinput ke sistem (per entitas & periode di atas). Total Value = QTY × Value. Sub total-nya ikut dihitung dalam Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan COA yang Masuk Kategori Pembelian Telah Sesuai
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin laporan keuangan mencerminkan aktivitas pembelian yang sebenarnya, sehingga biaya dan persediaan tersaji secara akurat untuk mendukung pengambilan keputusan manajemen.
Tujuan Operasional: Memastikan setiap Release Payment atas pembelian dijurnal ke akun (COA) yang tepat sesuai jenis dan kategori barang/jasa yang dibeli.
Tujuan Kepatuhan: Memastikan pencatatan akun pembelian sesuai dengan Chart of Account dan kebijakan klasifikasi biaya/persediaan perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan daftar dan total pembayaran yang COA-nya tidak sesuai secara berkala, untuk analisis risiko salah akun pembelian dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Purchase Amount dengan COA Tidak Sesuai
Dihitung dari SELURUH Release Payment pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Persentase = total Purchase Amount yang COA-nya TIDAK sesuai ÷ total pembelian — inilah yang dipakai utk Nilai.
Release Payment per Nota (dari General Journal)
Centang COA Pembelian Sesuai kalau akun (COA) yang dipakai transaksi ini sudah benar. Kalau tidak dicentang, otomatis dihitung COA Pembelian Tidak Sesuai — Purchase Amount-nya masuk total yang tidak sesuai. Isi Adjust COA untuk mencatat akun yang seharusnya dipakai (tidak mempengaruhi Nilai, hanya dokumentasi).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Pembelian yang Dikeluarkan Telah Diotorisasi dan di TTD oleh Manager
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). "Tampilkan" akan memuat/menyegarkan data General Journal & releasedBy Transaction Log Report entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel Release Payment di bawah (boleh diisi satu sisi saja) — Nilai & rekap tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap pengeluaran uang perusahaan sudah melalui persetujuan pihak yang berwenang, sehingga kas perusahaan terlindungi dari pembayaran yang tidak sah maupun penyalahgunaan wewenang.
Tujuan Operasional: Memastikan setiap Release Payment atas pembelian sudah diotorisasi (ditandatangani/approve) oleh Manager sebelum uang dikeluarkan ke supplier.
Tujuan Kepatuhan: Memastikan seluruh pengeluaran uang pembelian diotorisasi sesuai jenjang persetujuan (approval hierarchy) dan SOP pembayaran perusahaan yang berlaku, termasuk kesesuaian antara pihak yang tanda tangan dengan pihak yang approve.
Tujuan Pelaporan: Menyediakan riwayat kelengkapan otorisasi Manager atas setiap Release Payment secara berkala, untuk analisis risiko pembayaran tanpa izin resmi dan potensi fraud keuangan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Release Payment (Transaction Type Release Payment, Description Release Payment), satu baris terbaru per No. Release Payment, kolom releasedBy diambil dari After Value. Dipakai mengisi kolom Approval Sesuai/Belum Sesuai di tabel Kertas Kerja bawah, dicocokkan ke matriks kewenangan di Setting → Control Activities → Log Report Pembelian.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Release Payment per Nota (dari General Journal)
Satu baris per rantai Release Payment yang mengandung Goods Receipt, Simple Purchase, atau Purchase Invoice bahan, dari data General Journal yang sudah diunggah utk entitas ini. Centang TTD Manager di sini (SAMA tanda dgn yang ada di menu General Journal, tersimpan bersama). Approval Sesuai/Belum Sesuai terisi OTOMATIS dari releasedBy Transaction Log Report dicocokkan ke matriks kewenangan (tak bisa diubah manual di sini). Aging = Created Date − Journal Date, badge oranye kalau >1 hari. Nilai dihitung dari jumlah tanggal yang SEMUA Release Payment-nya sudah lengkap TTD Manager dan Approval Sesuai.
Rekap Tanggal Belum Lengkap Otorisasi Manager
Tanggal (Journal Date) yang MASIH punya minimal satu Release Payment belum TTD Manager atau belum Approval Sesuai -- inilah yang membuat tanggal itu dihitung "Tidak Sesuai" di Nilai. Klik nomor Release Payment di tabel atas (atau centang "Tampilkan hanya yang Belum TTD Manager atau Belum Approval Sesuai") utk melengkapinya.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan bahwa Uang Muka Pembelian untuk Kebutuhan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). "Tampilkan" akan memuat/menyegarkan data Advance Purchase entitas ini.
Tujuan Strategis: Melindungi kas perusahaan dari penyalahgunaan Uang Muka Pembelian (Advance Purchase) untuk kepentingan di luar kebutuhan operasional perusahaan.
Tujuan Operasional: Memastikan setiap Uang Muka Pembelian yang dikeluarkan benar-benar digunakan untuk kebutuhan pembelian barang/jasa perusahaan (DP kepada supplier), bukan untuk keperluan lain.
Tujuan Kepatuhan: Memastikan proses Create → Approve → Release Uang Muka Pembelian sudah sesuai jenjang otorisasi (approval hierarchy) dan SOP pembayaran perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat pemakaian dan umur (aging) Uang Muka Pembelian secara berkala, untuk analisis risiko penyalahgunaan dana dan uang muka yang menggantung terlalu lama.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis digabung dari tiga baris log per dokumen Advance Purchase: Create Advance Purchase, Approve Advance Purchase, dan Release Payment (khusus yang transType-nya Advance Purchase, dicocokkan lewat refNum). Boleh diunggah bertahap — kalau Approve/Release-nya belum terjadi saat unggahan pertama, cukup unggah ulang Transaction Log Report yang lebih baru nanti, baris yang sama otomatis diperbarui.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Advance Purchase (dari Transaction Log Report)
Satu baris per dokumen Advance Purchase. Purchase Amount = AdvancePaymentTotal dokumen itu sendiri. Authorized Sesuai/Tidak Sesuai terisi OTOMATIS dari AuthorizedBy dicocokkan ke matriks kewenangan (Setting → Control Activities → Log Report Pembelian). Centang Untuk Kebutuhan Perusahaan/Tidak Untuk Kebutuhan Perusahaan sesuai bukti pendukung — sub total Purchase Amount yang TIDAK untuk kebutuhan perusahaan inilah yang dibagi dengan Total Purchase Amount (SEMUA Release Payment CA "Memastikan Nota Ditandatangani Admin Gudang & Head Kitchen" periode ini, SAMA basis "total pembelian" dgn CA Siklus Pembelian lain) untuk menghasilkan Nilai. Released Date diambil dari After Value Release Payment (bisa beda dari tanggal Log Release-nya sendiri). Aging Belum Terpakai = hari ini − tanggal dibuat (kosong begitu sudah ada Release Payment), Aging Approve = Log Approve − Log Create, Aging Release = Log Release − Log Approve, Aging Release Date = Released Date − Log Release — keempatnya badge oranye kalau >30 hari.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Uang Muka Pembelian yang Dikeluarkan Telah Diotorisasi oleh Manager
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). "Tampilkan" akan memuat/menyegarkan data Advance Purchase entitas ini.
Tujuan Strategis: Menjamin setiap uang muka pembelian yang dikeluarkan sudah melalui persetujuan pihak yang berwenang, sehingga kas perusahaan terlindungi dari pengeluaran uang muka yang tidak sah dan tanpa pertanggungjawaban.
Tujuan Operasional: Memastikan setiap Advance Purchase sudah diotorisasi (di-approve) oleh Manager yang berwenang sebelum uang muka dikeluarkan (Release Payment).
Tujuan Kepatuhan: Memastikan proses Create → Approve → Release uang muka pembelian sesuai jenjang persetujuan (approval hierarchy) dan SOP pembayaran perusahaan yang berlaku, termasuk bahwa yang melakukan approval adalah pihak yang berwenang.
Tujuan Pelaporan: Menyediakan riwayat kelengkapan otorisasi Manager atas setiap uang muka pembelian secara berkala, untuk analisis risiko uang muka yang dikeluarkan tanpa izin resmi dan tanpa pertanggungjawaban.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis digabung dari tiga baris log per dokumen Advance Purchase: Create Advance Purchase, Approve Advance Purchase, dan Release Payment (khusus yang transType-nya Advance Purchase, dicocokkan lewat refNum). Data yang sama dipakai bersama CA "Memastikan bahwa Uang Muka Pembelian untuk Kebutuhan Perusahaan" — cukup unggah sekali di salah satunya. Boleh diunggah bertahap: kalau Approve/Release-nya belum terjadi saat unggahan pertama, unggah ulang Transaction Log Report yang lebih baru nanti, baris yang sama otomatis diperbarui.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Advance Purchase (dari Transaction Log Report)
Satu baris per dokumen Advance Purchase, kolom SAMA dgn CA "Memastikan bahwa Uang Muka Pembelian untuk Kebutuhan Perusahaan". Authorized Sesuai/Tidak Sesuai terisi OTOMATIS dari AuthorizedBy dicocokkan ke matriks kewenangan (Setting → Control Activities → Log Report Pembelian) — inilah yang menentukan Nilai: satu tanggal (Advance Payment Date) dihitung "tidak" kalau ADA dokumen di tanggal itu yang Authorized Tidak Sesuai (termasuk yang belum di-Approve). Kolom Untuk Kebutuhan Perusahaan/Tidak Untuk Kebutuhan Perusahaan TERSIMPAN BERSAMA CA "Uang Muka Pembelian untuk Kebutuhan Perusahaan" — mencentang di sini juga mengubah CA itu, tapi TIDAK mempengaruhi Nilai CA ini.
Rekap Tanggal Authorized Tidak Sesuai
Tanggal (Advance Payment Date) yang MASIH punya minimal satu Advance Purchase dengan Authorized Tidak Sesuai (termasuk yang belum di-Approve) -- inilah yang membuat tanggal itu dihitung "Tidak Sesuai" di Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi PR Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Purchase Request di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi PR dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete PR sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete PR & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Purchase Request" & Description "Delete Purchase Request" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete PR per Baris
Satu baris per Delete Purchase Request dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom PurchaseRequestNum s.d. AdditionalInfo otomatis terisi dari Before Value (data PR sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi PO Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Purchase Order di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi PO dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete PO sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete PO & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Purchase Order" & Description "Delete Purchase" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete PO per Baris
Satu baris per Delete Purchase dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom PurchaseNum s.d. Username otomatis terisi dari Before Value (data PO sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi GR Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Goods Receipt di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Goods Receipt dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Goods Receipt sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Goods Receipt & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Goods Receipt" & Description "Delete Goods Receipt" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Goods Receipt per Baris
Satu baris per Delete Goods Receipt dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom Goods Receipt Num, Goods Receipt Date, Ref Num (No. PO), Created By/Date, dan Edited By/Date otomatis terisi dari Before Value (data GR sebelum dihapus). Isi Keterangan (alasan kenapa dihapus dan transaksi apa ini, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Purchase Invoice Pembelian Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Purchase Invoice di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Purchase Invoice dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Purchase Invoice sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Purchase Invoice & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Purchase Invoice" & Description "Delete Purchase Invoice" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Purchase Invoice per Baris
Satu baris per Delete Purchase Invoice dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom PurchaseInvoiceNum s.d. AuthorizedDate otomatis terisi dari Before Value (data Purchase Invoice sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Purchase Payment Pembelian Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Purchase Payment di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Purchase Payment dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Purchase Payment sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Purchase Payment & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Purchase Payment" & Description "Delete Purchase Payment" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Purchase Payment per Baris
Satu baris per Delete Purchase Payment dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom PurchasePaymentNum s.d. AuthorizedDate otomatis terisi dari Before Value (data Purchase Payment sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Release Payment Pembelian Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Release Payment di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Release Payment dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Release Payment sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Release Payment & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Release Payment" & Description "Unrelease Payment" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Release Payment per Baris
Satu baris per Delete Release Payment dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom releasePaymentNum s.d. releasedDate otomatis terisi dari Before Value (data Release Payment sebelum dihapus). Release Payment dengan refNum berawalan "DS" (Disbursement) tidak ditampilkan dan tidak ikut dihitung — yang dicek hanya pembelian (mis. refNum berawalan AP dan VS). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Advance Purchase Pembelian Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Advance Purchase di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Advance Purchase dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Advance Purchase sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Advance Purchase & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Advance Purchase" & Description "Delete Advance Purchase" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Advance Purchase per Baris
Satu baris per Delete Advance Purchase dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom AdvancePaymentNum s.d. AuthorizedDate otomatis terisi dari Before Value (data Advance Purchase sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Delete Transaksi Jurnal Memorial Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Jurnal Memorial di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi penting yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete transaksi Jurnal Memorial dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Jurnal Memorial sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Jurnal Memorial & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan hilangnya data transaksi penting.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Memorial Journal" & Description "Delete Memorial Journal" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Jurnal Memorial per Baris
Satu baris per Delete Jurnal Memorial dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom MemorialJournalNum s.d. AdditionalInfo otomatis terisi dari Before Value (data Jurnal Memorial sebelum dihapus). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — inilah yang dipakai menghitung Nilai (satu tanggal dihitung "tidak ada berita acara" kalau minimal SATU delete tanggal itu ditandai Tidak Ada). Centang Bukan Kategori Pembelian untuk jurnal yang bukan transaksi pembelian — baris itu tidak masuk perhitungan materialitas (tidak perlu ditandai Ada/Tidak Ada Berita Acara), tapi tetap tampil di tabel. Kalau SEMUA baris periode ini dicentang Bukan Kategori Pembelian, centang juga "Tidak Ada Transaksi" di bawah.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Item Journal Hanya Digunakan untuk Peruntukkannya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori.
Tujuan Strategis: Menjamin akun persediaan dan biaya perusahaan tidak dimanipulasi nominalnya lewat Item Journal, sehingga laporan keuangan tetap menggambarkan kondisi yang sebenarnya.
Tujuan Operasional: Memastikan Item Journal hanya dipakai untuk peruntukan yang semestinya (mis. penyesuaian pemakaian/stok yang sah), bukan untuk menggeser atau mengubah nominal transaksi lain.
Tujuan Kepatuhan: Memastikan penggunaan Item Journal sesuai dengan SOP dan kebijakan perusahaan tentang jenis transaksi yang boleh dicatat melalui Item Journal.
Tujuan Pelaporan: Menyediakan daftar dan total nominal Item Journal yang tidak sesuai peruntukannya secara berkala, untuk analisis risiko manipulasi nominal dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Item Journal Tidak Sesuai Peruntukkannya
Dihitung dari SELURUH Item Journal pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Total Tidak Sesuai = jumlah nominal Item Journal yang ditandai Tidak Sesuai Peruntukkannya — inilah yang dibandingkan dengan ambang Rupiah utk Nilai.
Item Journal (dari General Journal)
Satu baris per transaksi Item Journal. Centang Sesuai Peruntukkannya kalau Item Journal ini dipakai sebagaimana mestinya, atau Tidak Sesuai Peruntukkannya kalau tidak — dua-duanya saling meniadakan. Semua baris wajib diceklist sebelum Nilai bisa disimpulkan & disimpan. Klik dok untuk membuka rantai jurnalnya.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Item Journal Diapprove Hanya Dilakukan oleh Manager
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori, lalu mencocokkannya dengan log approve yang sudah diunggah.
Tujuan Strategis: Menjamin setiap Item Journal yang memengaruhi persediaan dan biaya perusahaan disetujui oleh pihak yang berwenang, sehingga tidak ada perubahan pada catatan perusahaan tanpa izin.
Tujuan Operasional: Memastikan approval setiap Item Journal hanya dilakukan oleh Manager yang berwenang, pada tanggal dan jam yang wajar.
Tujuan Kepatuhan: Memastikan approval Item Journal sesuai dengan jenjang otorisasi (approval hierarchy) dan SOP perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat kesesuaian approval Item Journal secara berkala, untuk analisis risiko perubahan tanpa izin dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas yg dipilih di atas — otomatis difilter ke Transaction Type "Item Journal" & Description "Approve Item Journal" saja; AuthorizedBy & AuthorizedDate diambil dari kolom After Value, dicocokkan ke No. Item Journal lewat kolom Reference Number. Kalau satu Item Journal di-approve lebih dari sekali, yang TERBARU yang dipakai. Baris menumpuk antar unggahan. Daftar username approver di Setting → Control Activities → Log Report Pembelian ikut terisi dari file ini.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Item Journal & Approval-nya
AuthorizedBy/AuthorizedDate terisi dari log approve yang diunggah (tanda "-" = belum ada log approve untuk No. Item Journal itu di file yang diunggah — dihitung Belum Sesuai). Sudah Sesuai/Belum Sesuai terisi OTOMATIS: Sesuai kalau AuthorizedBy termasuk Manager yang berwenang (Setting → Control Activities → Log Report Pembelian). Satu tanggal (Journal Date) dihitung "tidak sesuai" kalau ADA Item Journal di tanggal itu yang Belum Sesuai — inilah yang menentukan Nilai.
Rekap Tanggal Approval Tidak Sesuai
Tanggal (Journal Date) yang MASIH punya minimal satu Item Journal dengan approval Belum Sesuai — inilah yang membuat tanggal itu dihitung "Tidak Sesuai" di Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Saldo Account Payable Suspense yang Menggantung Tidak Berubah Disetiap Bulannya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh. Bulan yang dihitung di Nilai = bulan-bulan kalender yang tercakup rentang tanggal itu, masing-masing dibanding bulan sebelumnya (mis. rentang September 2026 = saldo September dibanding Agustus). Tahun menentukan tabel isian Januari s/d Desember di bawah.
Tujuan Strategis: Menjamin saldo hutang sementara (Account Payable Suspense) atas barang yang sudah diterima tetapi belum ditagih tercatat wajar dan tidak dimanipulasi nominalnya, sehingga laporan keuangan menggambarkan kewajiban perusahaan yang sebenarnya.
Tujuan Operasional: Memastikan saldo AP Suspense yang menggantung tidak berubah dari bulan ke bulan, kecuali karena proses yang sah (penerimaan barang baru atau pengajuan Purchase Invoice).
Tujuan Kepatuhan: Memastikan pengelolaan akun AP Suspense sesuai kebijakan akuntansi dan SOP pembelian perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat perbandingan saldo AP Suspense per bulan beserta sub total perubahannya secara berkala, untuk analisis risiko manipulasi nominal dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Sub Total Perubahan Saldo AP Suspense
Sub Total = jumlah perubahan (nilai mutlak, naik maupun turun) saldo AP Suspense dibanding bulan sebelumnya, untuk bulan-bulan yang tercakup rentang tanggal di atas — inilah yang dibandingkan dengan ambang Rupiah utk Nilai.
Saldo Account Payable Suspense per Bulan
Isi Tanggal (tanggal saldo itu diambil) dan Saldo tiap bulan — tersimpan otomatis begitu kolomnya selesai diisi. Perubahan = saldo bulan itu dikurangi saldo bulan sebelumnya (Januari dibanding Desember tahun sebelumnya, baris paling atas). Bulan berlatar kuning = bulan yang sedang dihitung di Nilai; kalau ada yang belum diisi (termasuk bulan sebelumnya), Nilai belum bisa disimpulkan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Saldo Release Payment Account dengan Saldo 0
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh. Saldo ditampilkan tiap akhir bulan sampai bulan Tanggal s.d. (akhir periode cut off audit). Bulan yang dihitung di Nilai = bulan-bulan kalender yang tercakup rentang tanggal itu.
Tujuan Strategis: Menjamin akun perantara pembayaran (Release Payment Account) tidak menyimpan saldo yang menggantung, sehingga kas dan kewajiban perusahaan tersaji wajar dan nominalnya tidak dimanipulasi.
Tujuan Operasional: Memastikan setiap Release Payment yang dicatat di akun perantara sudah selesai diproses, sehingga saldo akun itu kembali 0 pada setiap akhir bulan.
Tujuan Kepatuhan: Memastikan pencatatan dan penyelesaian akun Release Payment Account sesuai dengan kebijakan akuntansi dan SOP pembayaran perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat saldo Release Payment Account setiap akhir bulan beserta sub total saldo yang menggantung secara berkala, untuk analisis risiko manipulasi nominal dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Sub Total Saldo Menggantung
Sub Total = jumlah saldo yang menggantung (nilai mutlak, saldo tidak 0) di akhir bulan, untuk bulan-bulan yang tercakup rentang tanggal di atas — inilah yang dibandingkan dengan ambang Rupiah utk Nilai.
Saldo Release Payment Account Setiap Akhir Bulan
Saldo = jumlah debit dikurangi credit akun Release Payment Account (COA 1 1 02 05) dari awal data sampai akhir bulan itu (kumulatif), dari General Journal yang sudah diunggah. Bulan berlatar kuning = bulan yang sedang dihitung di Nilai; berlatar merah muda = saldonya menggantung (tidak 0).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Saldo PO yang Menggantung Tidak Berubah Disetiap Bulannya
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh. Saldo PO awal & akhir disimpan per entitas dan bulan; bulan yang dihitung di Nilai = bulan-bulan yang tercakup rentang tanggal audit.
Tujuan Strategis: Menjamin saldo Purchase Order (PO) yang masih menggantung tercatat wajar dan tidak dimanipulasi nominalnya, sehingga komitmen pembelian perusahaan tersaji sebagaimana sebenarnya.
Tujuan Operasional: Memastikan saldo PO yang menggantung tidak berubah dari bulan ke bulan, kecuali karena proses yang sah (penerimaan barang, pelunasan, atau penutupan PO).
Tujuan Kepatuhan: Memastikan pengelolaan PO yang menggantung sesuai kebijakan dan SOP pembelian perusahaan yang berlaku, termasuk bahwa perubahan PO dilakukan dengan izin yang sah.
Tujuan Pelaporan: Menyediakan perbandingan saldo PO yang menggantung pada awal dan akhir tiap bulan yang diaudit beserta perubahannya secara berkala, untuk analisis risiko perubahan tanpa izin, manipulasi nominal, dan pengendalian internal siklus pembelian.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Saldo PO per Bulan
Pilih bulan, isi Saldo PO awal dan akhir bulan itu, lalu Simpan (atau tekan Enter) — formulir langsung lanjut ke bulan berikutnya sehingga beberapa bulan bisa diisi berurutan. Perubahan = saldo akhir − saldo awal. Untuk Nilai, yang dibandingkan dengan ambang Rupiah adalah jumlah nilai mutlak perubahan bulan-bulan yang tercakup rentang tanggal audit di atas.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Biaya antara Nota dengan Buku Kas Telah Sesuai
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total selisih tetap dihitung dari seluruh Release Payment biaya pada rentang Journal Date.
Tujuan Strategis: Menjamin biaya yang dibayarkan melalui Release Payment (di luar pembelian bahan baku/barang) benar, lengkap, dan didukung nota yang sah, sehingga tidak ada salah saji biaya maupun kebocoran kas akibat pembayaran lebih atau pencatatan biaya yang keliru.
Tujuan Operasional: Memastikan nilai biaya yang dicatat dan dibayarkan melalui Release Payment (buku kas/bank) yang belum tercakup di Siklus Pembelian sama dengan nilai pada nota/dokumen biaya, termasuk ketepatan tanggal, nominal, dan deskripsi barang/jasa.
Tujuan Kepatuhan: Memastikan setiap pengeluaran biaya didukung nota yang sah, dijurnal pada periode yang tepat, dan tidak termasuk barang yang seharusnya melalui proses panjang pembelian (PR, PO, penerimaan barang, Purchase Invoice).
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi nota biaya terhadap buku kas beserta total selisihnya secara berkala, untuk analisis akurasi pencatatan biaya dan pengendalian internal siklus biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Selisih Nota vs Buku Kas
Dihitung dari SELURUH Release Payment pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Total Selisih = jumlah nilai absolut Variance per nota — inilah yang dibandingkan dgn Total Biaya utk Nilai.
Release Payment per Nota (dari General Journal)
Baris = Release Payment yang BELUM tampil di CA "Memastikan Pembelian Nota dengan Buku Kas Sesuai" (mis. Disbursement & biaya tanpa rantai pembelian). Purchase Amount = nilai Release Payment. Centang Nilai Biaya Sesuai kalau nota cocok — Purchase Amount Adjustment otomatis terisi sama dgn Purchase Amount. Kalau tidak dicentang, otomatis dihitung Nilai Biaya Tidak Sesuai dan Adjustment WAJIB diisi manual sesuai nota. Variance = Adjustment − Purchase Amount. Keterangan menandai Release Payment yang Created Date-nya melewati bulan Journal Date.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Melakukan Rekonsiliasi antara Rekening dengan Pengeluaran Biaya
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total selisih tetap dihitung dari seluruh Release Payment biaya via Bank pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap dana biaya yang keluar dari rekening bank perusahaan benar-benar sampai ke pihak yang berhak dengan jumlah yang tepat, sehingga kas perusahaan terlindungi dari kesalahan transfer maupun potensi fraud.
Tujuan Operasional: Memastikan setiap pembayaran biaya via bank yang tercatat di sistem (Release Payment) cocok dengan mutasi rekening koran — jumlah yang terpotong sama, dan nama serta nomor rekening penerima sesuai dengan data supplier/penerima.
Tujuan Kepatuhan: Memastikan pembayaran biaya hanya dilakukan ke rekening yang terdaftar di master data, sesuai SOP pembayaran dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi rekening terhadap pengeluaran biaya beserta total selisih dan ruang perbaikan penerima yang tidak sesuai secara berkala, untuk analisis pengendalian internal siklus biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Total Selisih Rekening vs Pengeluaran
Dihitung dari SELURUH Release Payment Bank pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Total Selisih = jumlah nilai absolut Variance — inilah yang dibandingkan dgn Total Biaya utk Nilai.
Release Payment via Bank (dari General Journal)
Baris SAMA dengan CA "Memastikan Biaya antara Nota dengan Buku Kas Telah Sesuai" (Release Payment yang belum tampil di Siklus Pembelian), hanya yang sumber dananya rekening Bank (kolom Bank). Purchase Amount = nilai Release Payment. Centang Rekonsiliasi Rekening Cocok kalau cocok dgn rekening koran — Adjustment otomatis sama dgn Purchase Amount. Centang Beneficiary name mismatch kalau nama penerima transfer bukan penerima yang berhak — Adjustment otomatis 0 (dana dianggap tak sampai). Selain itu otomatis Rekonsiliasi Rekening Tidak Cocok & Adjustment WAJIB diisi manual sesuai jumlah yang terpotong di rekening. Variance = Adjustment − Purchase Amount.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Pengeluaran Bonus untuk CRM Sesuai dengan Pencapaian dari Marketing Activity
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh. Angka yang Anda isi di bawah tersimpan per entitas & periode.
Tujuan Strategis: Menjamin bonus yang dibayarkan kepada CRM benar-benar sebanding dengan pencapaian penjualan dari Marketing Activity, sehingga insentif adil antar karyawan dan tidak ada kebocoran biaya.
Tujuan Operasional: Memastikan insentif CRM yang dibayarkan sama dengan hasil perhitungan ulang (reperforming) 0,5% dari total penjualan CRM yang didukung nota dan approval yang sah.
Tujuan Kepatuhan: Memastikan setiap penjualan yang diperhitungkan sebagai pencapaian CRM didukung bukti dan approval manager sesuai ketentuan perusahaan.
Tujuan Pelaporan: Menyediakan hasil perhitungan selisih insentif CRM secara berkala, untuk analisis akurasi pembayaran bonus dan pengendalian internal siklus biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Perhitungan Insentif CRM
Isi Total Penjualan CRM dan Insentif yang diberikan (Rp). Insentif CRM = 0,5% × Total Penjualan CRM. Selisih insentif = Insentif yang diberikan − Insentif CRM, dibagi total bonus CRM (insentif yang diberikan) untuk mendapatkan Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan COA yang Masuk Kategori Biaya Telah Sesuai
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel di bawah — Nilai & total tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin laporan keuangan mencerminkan biaya yang sebenarnya terjadi, sehingga laba rugi tersaji secara akurat untuk mendukung pengambilan keputusan manajemen.
Tujuan Operasional: Memastikan setiap Release Payment atas biaya dijurnal ke akun (COA) yang tepat sesuai jenis dan kategori biaya yang dikeluarkan.
Tujuan Kepatuhan: Memastikan pencatatan akun biaya sesuai dengan Chart of Account dan kebijakan klasifikasi biaya perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan daftar dan total pembayaran biaya yang COA-nya tidak sesuai secara berkala, untuk analisis risiko salah akun dan salah klasifikasi biaya serta pengendalian internal siklus biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Total Purchase Amount dengan COA Tidak Sesuai
Dihitung dari SELURUH Release Payment pada rentang Journal Date (tidak ikut filter tampilan tabel di bawah). Persentase = total Purchase Amount yang COA-nya TIDAK sesuai ÷ total biaya — inilah yang dipakai utk Nilai.
Release Payment per Nota (dari General Journal)
Baris = Release Payment yang BELUM tampil di CA "Memastikan Pembelian Nota dengan Buku Kas Sesuai". Centang COA Biaya Sesuai kalau akun (COA) yang dipakai transaksi ini sudah benar. Kalau tidak dicentang, otomatis dihitung COA Biaya Tidak Sesuai — Purchase Amount-nya masuk total yang tidak sesuai. Centang Bukan Biaya kalau Release Payment ini ternyata bukan biaya (pindah ke Siklus Pembelian). Isi Adjust COA untuk mencatat akun yang seharusnya dipakai (tidak mempengaruhi Nilai, hanya dokumentasi).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Biaya yang Dikeluarkan Telah Diotorisasi dan di TTD oleh Manager
s.d.
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat). "Tampilkan" akan memuat/menyegarkan data General Journal & releasedBy Transaction Log Report entitas ini kalau belum ada di memori. Created Date cuma menyaring tabel Release Payment di bawah (boleh diisi satu sisi saja) — Nilai & rekap tetap dihitung dari seluruh Release Payment pada rentang Journal Date.
Tujuan Strategis: Menjamin setiap pengeluaran biaya perusahaan sudah melalui persetujuan pihak yang berwenang, sehingga kas perusahaan terlindungi dari biaya yang tidak sah maupun penyalahgunaan wewenang.
Tujuan Operasional: Memastikan setiap Release Payment atas biaya sudah diotorisasi (ditandatangani/approve) oleh Manager sebelum uang dikeluarkan.
Tujuan Kepatuhan: Memastikan seluruh pengeluaran uang untuk biaya diotorisasi sesuai jenjang persetujuan (approval hierarchy) dan SOP pembayaran perusahaan yang berlaku, termasuk kesesuaian antara pihak yang tanda tangan dengan pihak yang approve.
Tujuan Pelaporan: Menyediakan riwayat kelengkapan otorisasi Manager atas setiap Release Payment biaya secara berkala, untuk analisis risiko biaya tidak sah, pengeluaran tanpa izin resmi, dan potensi fraud keuangan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke baris Release Payment (Transaction Type Release Payment, Description Release Payment), satu baris terbaru per No. Release Payment, kolom releasedBy diambil dari After Value. Dipakai mengisi kolom Approval Sesuai/Belum Sesuai di tabel Kertas Kerja bawah, dicocokkan ke matriks kewenangan di Setting → Control Activities → Log Report Biaya. File yang sama juga melayani CA "Memastikan Pembelian yang Dikeluarkan Telah Diotorisasi dan di TTD oleh Manager" (satu kali unggah cukup untuk keduanya).
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Release Payment per Nota (dari General Journal)
Satu baris per Release Payment biaya (yang belum tampil di CA "Memastikan Pembelian Nota dengan Buku Kas Sesuai"), dari data General Journal yang sudah diunggah utk entitas ini. Centang TTD Manager di sini (SAMA tanda dgn yang ada di menu General Journal, tersimpan bersama). Approval Sesuai/Belum Sesuai terisi OTOMATIS dari releasedBy Transaction Log Report dicocokkan ke matriks kewenangan (tak bisa diubah manual di sini). Aging = Created Date − Journal Date, badge oranye kalau >1 hari. Centang Bukan Biaya kalau ternyata bukan biaya (pindah ke Siklus Pembelian). Nilai dihitung dari jumlah tanggal yang SEMUA Release Payment-nya sudah lengkap TTD Manager dan Approval Sesuai.
Rekap Tanggal Belum Lengkap Otorisasi Manager
Tanggal (Journal Date) yang MASIH punya minimal satu Release Payment belum TTD Manager atau belum Approval Sesuai -- inilah yang membuat tanggal itu dihitung "Tidak Sesuai" di Nilai. Klik nomor Release Payment di tabel atas (atau centang "Tampilkan hanya yang Belum TTD Manager atau Belum Approval Sesuai") utk melengkapinya.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Perhitungan SC Sesuai dengan Pendapatan Service Charge
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual sesuai Cut Off Audit). Pendapatan Service Charge dijumlah dari Sales Recapitulation pada rentang tanggal ini; angka yang Anda isi di bawah tersimpan per entitas & periode.
Tujuan Strategis: Menjamin Service Charge yang dipungut dari pelanggan dibagikan kepada karyawan secara adil dan sesuai ketentuan, sehingga tidak ada penyimpangan pembagian maupun kebocoran pendapatan.
Tujuan Operasional: Memastikan total Service Charge yang diterima karyawan sama dengan hasil perhitungan ulang (reperforming) dari Pendapatan Service Charge di Sales Recapitulation dikurangi bonus staf di luar resto.
Tujuan Kepatuhan: Memastikan pembagian Service Charge mengikuti kebijakan perusahaan, termasuk karyawan yang sedang menerima Surat Peringatan (SP) tidak menerima Service Charge.
Tujuan Pelaporan: Menyediakan hasil perhitungan selisih Service Charge secara berkala, untuk analisis keadilan pembagian dan akurasi data pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Perhitungan Service Charge
Pendapatan Service Charge otomatis dari Sales Recapitulation (rentang tanggal Cut Off Audit di atas). Isi Bonus staf di luar resto dan Total Service Charge yang Diterima Karyawan. Total SC yang Seharusnya Diberikan = (Pendapatan SC − Bonus staf di luar resto) ÷ 2. Selisih = Total yang Diterima − Total yang Seharusnya, dibagi Pendapatan Service Charge untuk mendapatkan Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Membandingkan Data Karyawan yang Menerima SC dengan Data Karyawan yang Dimiliki oleh HCGA
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual sesuai Cut Off Audit; rentang >45 hari kerja memperlonggar syarat Nilai 0 secara berjenjang). Angka yang Anda isi di bawah tersimpan per entitas & periode.
Tujuan Strategis: Menjamin Service Charge hanya dibagikan kepada karyawan yang berhak, sehingga pembagian adil dan tidak ada kebocoran akibat penerima yang tidak sah.
Tujuan Operasional: Memastikan jumlah dan nama karyawan penerima Service Charge di data Admin Keuangan sama dengan data karyawan HCGA, dikurangi karyawan yang tidak berhak menerima.
Tujuan Kepatuhan: Memastikan karyawan yang sedang menerima Surat Peringatan (SP) dari divisi HCGA tidak menerima Service Charge sesuai kebijakan perusahaan.
Tujuan Pelaporan: Menyediakan hasil pembandingan data penerima Service Charge dengan data HCGA beserta daftar nama ruang perbaikan secara berkala, untuk analisis risiko salah penerima.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Perbandingan Data Karyawan Penerima Service Charge
Isi Total Karyawan Data HCGA, Total Karyawan yang Tidak Menerima SC, dan Total Data Karyawan Admin Keuangan yang Menerima SC (jumlah orang). Total Karyawan yang Menerima SC = Total HCGA − yang Tidak Menerima. Selisih = Total Data Admin Keuangan − Total yang Menerima; jumlah orang selisih (tanpa memandang plus/minus) menentukan Nilai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Pemberian Cash Back Driver Sesuai Ketentuan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh. Baris yang Anda isi di bawah tersimpan per entitas & periode.
Tujuan Strategis: Menjamin pemberian cash back kepada driver hanya terjadi sesuai ketentuan perusahaan, sehingga biaya promosi terkendali dan tidak ada fee yang melebihi batas maupun mark-up biaya.
Tujuan Operasional: Memastikan setiap pemberian cash back driver memenuhi syarat dan ketentuan pembelian, ditransfer ke rekening tujuan yang benar, dan didukung tanda tangan Driver, Kasir, serta Manager Outlet.
Tujuan Kepatuhan: Memastikan kontrol bertingkat (Driver, Kasir, Manager Outlet) dijalankan pada setiap pengeluaran cash back sesuai kebijakan perusahaan.
Tujuan Pelaporan: Menyediakan hasil pemeriksaan pemberian cash back driver beserta sub total yang tidak sesuai secara berkala, untuk analisis risiko fee berlebih dan mark-up biaya.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Pemberian Cash Back Driver
Klik Tambah Baris utk setiap pemberian cash back, isi Tanggal & Total Pendapatan Pemberian Cash Back, lalu centang ceklist yang sudah terpenuhi. Kalau salah satu ceklist tidak tercentang, nominal baris itu masuk Sub Total Tidak Sesuai; sub total dibagi Total Pendapatan Pemberian Cash Back untuk mendapatkan Nilai. Centang Cash Back Karyawan bila cash back itu untuk karyawan: TTD Driver dan TTD Kasir tidak disyaratkan (kolomnya diredupkan), jadi baris tetap Sesuai walau keduanya tidak tercentang — SnK, Rekening Tujuan, dan TTD Manager tetap harus tercentang.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Transaksi Jurnal Memorial Digunakan untuk Kebutuhan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" akan memuat data General Journal entitas ini kalau belum ada di memori.
Tujuan Strategis: Menjamin Jurnal Memorial hanya digunakan untuk kepentingan perusahaan, sehingga tidak ada pembukuan yang dimanfaatkan untuk kepentingan pribadi maupun untuk memanipulasi laporan keuangan.
Tujuan Operasional: Memastikan setiap transaksi Jurnal Memorial di General Journal jelas peruntukannya — didukung rantai jurnal & uraian yang menunjukkan bahwa transaksi tersebut memang untuk kebutuhan perusahaan.
Tujuan Kepatuhan: Memastikan penggunaan Jurnal Memorial sesuai dengan SOP dan kebijakan perusahaan tentang jenis transaksi yang boleh dicatat melalui Jurnal Memorial.
Tujuan Pelaporan: Menyediakan daftar dan total nominal Jurnal Memorial yang bukan untuk kebutuhan perusahaan, beserta persentasenya terhadap total biaya, secara berkala untuk analisis risiko penyalahgunaan Jurnal Memorial.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Jurnal Memorial
Dihitung dari SELURUH Memorial Journal pada rentang Journal Date (tidak ikut saringan tampilan tabel di bawah). Total Biaya = pembagi Nilai; Bukan untuk Kebutuhan Perusahaan = pembilang (dasar Nilai).
Jurnal Memorial (dari General Journal)
Satu baris per transaksi Memorial Journal. Klik dok untuk membuka rantai jurnalnya, lalu jawab pada kolom Untuk Kebutuhan Perusahaan? — Ya (untuk perusahaan) atau Tidak (bukan untuk perusahaan); klik pilihan yang sama sekali lagi untuk membatalkannya. Semua baris wajib dinilai sebelum Nilai bisa disimpulkan & disimpan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Disbursement Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Disbursement di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi biaya yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete Disbursement dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui (AuthorizedBy) adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Disbursement sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Disbursement & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan kehilangan data transaksi.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Disbursement" & Description "Delete Disbursement" saja, tabel dokumentasi per-delete di bawah terisi otomatis dari sini. Baris menumpuk antar unggahan (tak perlu unggah ulang dari awal); baris yang sama tidak ditambahkan dua kali.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Disbursement per Baris
Satu baris per Delete Disbursement dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah. Kolom Disbursement Number s.d. Description otomatis terisi dari Before Value (data Disbursement sebelum dihapus; Amount = jumlah semua detail). Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — SEMUA baris wajib diklasifikasikan sebelum Nilai bisa disimpulkan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Release Payment Biaya Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (unrelease) Release Payment atas biaya di sistem berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi biaya yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete (unrelease) Release Payment Biaya dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui (Released By) adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Release Payment Biaya sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Release Payment Biaya & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan kehilangan data transaksi.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB utk entitas & periode yg dipilih di atas — otomatis difilter ke Transaction Type "Release Payment" & Description "Unrelease Payment", lalu yang dihitung di CA ini hanya baris transType Disbursement (refNum "DS..."). Data memakai tempat penyimpanan yang sama dengan CA Pembelian "Memastikan untuk Delete Transaksi Release Payment Pembelian Harus Ada Berita Acara" (satu kali unggah cukup untuk keduanya). Baris menumpuk antar unggahan; baris yang sama tidak ditambahkan dua kali.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Delete Release Payment Biaya per Baris
Satu baris per Delete (Unrelease) Release Payment Biaya dlm rentang yang dipilih di atas, dari Transaction Log Report yg diunggah — hanya yang transType-nya Disbursement. Kolom Release Payment Number s.d. Released Date otomatis terisi dari Before Value. Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — SEMUA baris wajib diklasifikasikan sebelum Nilai bisa disimpulkan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan untuk Delete Transaksi Advance Purchase Biaya Harus Ada Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual, mis. utk bulan berjalan yg belum lewat).
Tujuan Strategis: Menjamin setiap penghapusan (delete) Advance Purchase yang tergolong biaya berlangsung di bawah kendali yang sah & terdokumentasi, sehingga tidak ada penghapusan tanpa otorisasi dan tidak ada data transaksi biaya yang hilang tanpa jejak.
Tujuan Operasional: Memastikan setiap delete Advance Purchase Biaya dilengkapi berita acara yang menjelaskan alasan & kejadian penghapusannya, serta bahwa yang menyetujui (AuthorizedBy) adalah pihak yang berwenang.
Tujuan Kepatuhan: Memastikan delete Advance Purchase Biaya sesuai dengan SOP dokumentasi, kewenangan persetujuan, dan otorisasi perusahaan yang berlaku.
Tujuan Pelaporan: Menyediakan riwayat delete Advance Purchase Biaya & kelengkapan berita acaranya secara berkala untuk analisis risiko penghapusan tanpa otorisasi dan kehilangan data transaksi.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Delete Advance Purchase Biaya per Baris
Satu baris per Delete Advance Purchase Biaya dlm rentang yang dipilih di atas — hasil perpindahan dari CA Pembelian. Kolom Advance Payment Number s.d. Authorized Date terisi dari Before Value Transaction Log Report yg diunggah di CA Pembelian. Isi Keterangan (alasan kenapa dihapus, hasil tanya jawab auditor, ketikan bebas) lalu centang Ada Berita Acara atau Tidak Ada Berita Acara — SEMUA baris wajib diklasifikasikan sebelum Nilai bisa disimpulkan. Centang Bukan Biaya kalau baris ini ternyata bukan biaya (pindah kembali ke CA Pembelian).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Rekonsiliasi antara Pendapatan Rekening di Settlement dan Sistem
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat General Journal & rekening koran entitas ini kalau belum ada di memori. Pastikan keduanya sudah diunggah di Setting → Data sumber, termasuk rekening koran awal bulan berikutnya agar settlement akhir bulan ikut terbaca.
Tujuan Strategis: Menjamin seluruh pendapatan penjualan non-tunai tercatat lengkap di sistem dan benar-benar diterima di rekening perusahaan, sehingga laporan pendapatan dapat diandalkan dan tidak ada kebocoran maupun penundaan dana settlement.
Tujuan Operasional: Memastikan nilai pendapatan per payment method di sistem (POS Settlement pada General Journal) sama dengan dana yang masuk di rekening koran beserta MDR-nya, serta setiap selisih dapat dijelaskan dan ditindaklanjuti tepat waktu.
Tujuan Kepatuhan: Memastikan setiap transaksi pendapatan yang di-settlement oleh bank/acquirer tercatat di sistem pada periode yang tepat dan mengikuti prosedur rekonsiliasi pendapatan yang ditetapkan perusahaan.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi pendapatan antara sistem dan rekening settlement beserta sub total variance-nya secara berkala, untuk analisis akurasi pencatatan pendapatan dan pengendalian internal siklus pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Ringkasan Variance
Dihitung dari SELURUH baris pada rentang Sales Date (tidak ikut filter tampilan di bawah). Sub Total Variance = jumlah nilai absolut Variance baris yang tidak dicentang Bukan Variance — inilah yang dibagi Total Pendapatan (SUM Payment Amount GJ) untuk Nilai.
Rekonsiliasi per Payment Method
Pilih Payment Method di bawah untuk mengerjakannya satu per satu. Setiap baris = satu Rekening pada satu Sales Date (voucher POS Settlement-nya bisa dibuka lewat tautan "voucher"). BCA memakai metode gabung DEBIT & KREDIT menjadi satu baris (MDR apple-to-apple). Settled Amount & MDR (Bank) terisi otomatis dari rekening koran — ubah manual kalau ada perbedaan (ditandai , tombol ↺ mengembalikan ke nilai asli). Centang Bukan Variance untuk selisih yang bukan variance sebenarnya (mis. settlement akhir bulan baru masuk awal bulan) dan isi Keterangan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Rekonsiliasi Pendapatan Cash
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat General Journal & Sales Recapitulation entitas ini kalau belum ada di memori. Pastikan General Journal, Sales Recapitulation dan Sales Payment Recapitulation sudah diunggah di Setting → Data sumber.
Tujuan Strategis: Menjamin seluruh pendapatan tunai (cash) outlet tercatat lengkap dan benar di sistem akuntansi, sehingga laporan pendapatan dapat diandalkan dan tidak ada kebocoran uang tunai.
Tujuan Operasional: Memastikan pendapatan cash menurut Sales Recapitulation (Total Penjualan dikurangi seluruh pembayaran non-cash) sama dengan POS Settlement CASH yang dibukukan di General Journal pada setiap Sales Date.
Tujuan Kepatuhan: Memastikan setiap penjualan tunai di POS dibukukan sebagai settlement cash pada periode yang tepat dan mengikuti prosedur penyetoran serta pencatatan kas perusahaan.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi pendapatan cash antara Sales Recapitulation dan POS Settlement beserta sub total variance-nya secara berkala, untuk analisis selisih kas dan pengendalian internal siklus pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Variance
Dihitung dari SELURUH hari pada rentang Sales Date (tidak ikut filter tampilan di bawah). Sub Total Variance = jumlah nilai absolut Variance hari yang tidak dicentang Bukan Variance — inilah yang dibagi Total Pendapatan Cash (SUM Payment Amount GJ POS Settlement CASH) untuk Nilai.
Perhitungan Cash dari Sales Recapitulation
Akumulasi seluruh periode: Total Penjualan dikurangi pembayaran tiap Payment Method non-cash = Cash menurut Sales Recapitulation. Bill bertipe Void tidak dihitung (tidak punya pembayaran).
Rekonsiliasi Cash per Sales Date
Variance = POS Settlement CASH (GJ) − Cash menurut Sales Recapitulation. Tombol "metode" pada kolom Pembayaran Non-Cash membuka rincian per Payment Method. Centang Bukan Variance untuk selisih yang bukan variance sebenarnya (mis. setoran/settlement bergeser hari) dan isi Keterangan.
Catatan Prosedur
Tidak ada catatan prosedur untuk Control Activity ini.
Control Activities — Memastikan Piutang Benar Merupakan Pendapatan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Tanggal akhir menjadi tanggal saldo Balance Sheet & patokan hitung aging; tanggal awal dipakai untuk rentang Sales Date Total Pendapatan. "Tampilkan" memuat General Journal entitas ini kalau belum ada di memori.
Tujuan Strategis: Menjamin piutang yang disajikan di neraca benar-benar berasal dari pendapatan perusahaan dan dapat ditagih, sehingga aset tidak overstated dan tidak ada tagihan atau pinjaman pihak lain yang tercampur sebagai piutang usaha.
Tujuan Operasional: Memastikan setiap akun piutang beserta umurnya telah ditelaah dan dibedakan antara piutang yang timbul dari pendapatan perusahaan dengan piutang yang bukan berasal dari pendapatan (mis. piutang pemegang saham, kasbon karyawan, piutang lain-lain).
Tujuan Kepatuhan: Memastikan pencatatan piutang mengikuti klasifikasi akun dan kebijakan perusahaan, serta piutang yang telah lama terbuka (aging panjang) dikonfirmasi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan daftar piutang per akun beserta aging dan klasifikasinya secara berkala, untuk analisis kewajaran piutang dan pengendalian internal siklus pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Piutang
Dihitung dari SELURUH akun piutang (tidak ikut filter tampilan di bawah). Bukan Piutang Perusahaan = jumlah nilai absolut saldo akun yang Anda tentukan bukan piutang perusahaan — inilah yang dibagi Total Pendapatan (SUM Payment Amount GJ pada Rekonsiliasi Pendapatan, semua Payment Method) untuk Nilai. Nilai baru bisa disimpulkan setelah semua akun bersaldo ditentukan.
Piutang per Akun & Aging (Balance Sheet)
Satu baris = satu akun piutang. Saldo = Debit − Kredit kumulatif s.d. tanggal akhir (sama dengan Balance Sheet). Aging dihitung metode FIFO: kredit (pelunasan) menutup debit tertua lebih dulu, sisa debit yang masih terbuka dihitung umurnya sampai tanggal akhir — warna bar: hijau 0–30, kuning 31–60, oranye 61–90, merah > 90 hari. Tombol "item" membuka rincian piutang yang masih terbuka. Pilih Piutang Perusahaan atau Bukan pada kolom Penentuan.
Catatan Prosedur
Tidak ada catatan prosedur untuk Control Activity ini.
Control Activities — Memastikan Penjualan Pax antara ESB dan Reserva Sudah Sama
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat Sales Recapitulation entitas ini kalau belum ada di memori. Hanya hari yang punya data ESB atau data Reserva yang ditampilkan.
Tujuan Strategis: Menjamin seluruh penjualan berbasis tamu (pax) tercatat lengkap dan benar di sistem, sehingga pendapatan outlet dapat diandalkan dan tidak ada transaksi yang tidak dicatat atau data penjualan yang dimanipulasi.
Tujuan Operasional: Memastikan jumlah pax (beserta BPP) yang terjual menurut ESB (Sales Recapitulation) sama dengan jumlah pax (beserta BPP) menurut data reservasi Reserva pada setiap hari, dan setiap perubahan data penjualan di sisi ESB dapat dijelaskan.
Tujuan Kepatuhan: Memastikan pencatatan penjualan pax mengikuti prosedur perusahaan, yaitu data ESB konsisten dengan data Reserva dan setiap koreksi data didukung keterangan yang jelas.
Tujuan Pelaporan: Menyediakan hasil rekonsiliasi pax ESB terhadap Reserva beserta total selisihnya secara berkala, untuk analisis akurasi pencatatan penjualan dan pengendalian internal siklus pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Selisih Pax
Dihitung dari SELURUH hari pada rentang tanggal (tidak ikut filter tampilan di bawah). Total Selisih = jumlah nilai absolut Selisih (Total ESB − Total Reserva) semua hari — inilah yang dibandingkan dengan syarat Nilai. Nilai baru bisa disimpulkan setelah data Reserva semua hari yang ada penjualannya terisi.
Pax ESB vs Reserva per Hari
Isi Pax dan BPP Reserva pada tiap tanggal (Enter pindah ke baris berikutnya). Pax ESB terisi otomatis dari Sales Recapitulation; ubah kalau perlu — sel berubah warna dan tombol ↺ mengembalikan ke nilai asli. BPP ESB bawaannya 0.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan User Deposit dan Rekonsiliasi Member Deposit dengan Rekening Sesuai
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat transaksi yang sudah diunggah dan General Journal entitas ini (untuk Total Pendapatan) kalau belum ada di memori.
Tujuan Strategis: Menjamin seluruh dana member deposit yang diterima outlet tercatat lengkap di sistem dan benar-benar masuk ke rekening perusahaan, sehingga pendapatan di muka tidak bocor, tidak ada dana yang menggantung, dan laporan keuangan dapat diandalkan.
Tujuan Operasional: Memastikan setiap transaksi deposit dan pemakaian (usage) member deposit di POS tercatat dengan benar, diinput oleh pihak yang berwenang, dan saldo member dapat dijelaskan serta direkonsiliasi dengan dana yang masuk ke rekening.
Tujuan Kepatuhan: Memastikan pencatatan member deposit mengikuti kewenangan input yang ditetapkan perusahaan, dan dana yang tercatat di POS tetapi tidak ada di rekening pada akhir bulan tidak diakui sebagai pendapatan.
Tujuan Pelaporan: Menyediakan rincian transaksi dan saldo member deposit beserta hasil rekonsiliasinya secara berkala, untuk analisis dana menggantung dan pengendalian internal siklus pendapatan.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
1 Bulan
Unggah Member Deposit & Usage Report
Unggah file Member Deposit & Usage Report dari ESB dengan Report Mode "Detail" untuk entitas yang dipilih di atas. Kolom yang dibaca: Member Code, Member Name, Branch Name, User, Cashier, Transaction Date, Transaction Type (Deposit/Usage), Transaction Number, Payment Method Name, Amount (Usage bernilai negatif di file). Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas.
📂
Klik atau tarik file Member Deposit & Usage Report ke sini
Pilih Entitas dulu di atas
Ringkasan Member Deposit
Dihitung dari SELURUH transaksi pada rentang tanggal (tidak ikut filter tampilan di bawah). Sub Total Deposit Tidak Cocok = jumlah Amount Deposit yang pada kolom Rekonsiliasi ditentukan Tidak Cocok dengan rekening — inilah yang dibagi Total Pendapatan (SUM Payment Amount GJ pada Rekonsiliasi Pendapatan, semua Payment Method) untuk Nilai.
Transaksi Member Deposit
Transaksi: setiap Deposit/Usage per baris; Variance = Amount Deposit − Amount Usage. Baris Deposit yang diinput user tidak berwenang berwarna ungu. Pada kolom Rekonsiliasi, tentukan tiap Deposit Cocok atau Tidak Cocok dengan rekening. Sub tab Perlu Dicek = Deposit yang belum ditentukan, Perlu Tindak Lanjut = Deposit Tidak Cocok atau diinput user tidak berwenang (kolom Ruang Perbaikan), Cocok = Deposit yang cocok dengan rekening.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Sisa Member Deposit Memang Belum Terpakai
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Saldo member dihitung kumulatif dari awal data sampai tanggal akhir; tanggal awal dipakai untuk Total Pendapatan. "Tampilkan" memuat data member deposit yang sudah diunggah dan General Journal entitas ini (untuk Total Pendapatan) kalau belum ada di memori.
Tujuan Strategis: Menjamin saldo member deposit yang masih tercatat di sistem benar-benar merupakan dana member yang belum terpakai, sehingga kewajiban kepada member (pendapatan diterima di muka) tersaji wajar dan tidak ada saldo yang dimanipulasi untuk menggeser atau menyembunyikan pendapatan.
Tujuan Operasional: Memastikan setiap saldo member deposit dapat ditelusuri dari riwayat Deposit dan Usage-nya di POS, saldo yang menggantung lama terdeteksi lewat aging, dan selisih yang tidak wajar segera dijelaskan oleh outlet.
Tujuan Kepatuhan: Memastikan pencatatan Deposit dan Usage mengikuti prosedur perusahaan, dan saldo yang tidak dapat dibuktikan masih milik member tidak diakui sebagai saldo deposit yang sah.
Tujuan Pelaporan: Menyediakan rincian saldo per member beserta umur deposit yang belum terpakai dan variance-nya terhadap Total Pendapatan secara berkala, sebagai bahan analisis dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Member Deposit & Usage Report
Unggah file Member Deposit & Usage Report dari ESB dengan Report Mode "Detail" untuk entitas yang dipilih di atas, mulai dari awal (bukan hanya bulan berjalan) supaya saldo dan aging akurat. File ini sama dengan yang dipakai Control Activity "Memastikan User Deposit dan Rekonsiliasi Member Deposit dengan Rekening Sesuai" — mengunggah di salah satunya sudah cukup, dan mengunggah ulang file yang sama tidak menggandakan data.
📂
Klik atau tarik file Member Deposit & Usage Report ke sini
Pilih Entitas dulu di atas
Ringkasan Sisa Member Deposit
Saldo dihitung dari SELURUH transaksi sejak awal data sampai tanggal akhir (tidak ikut filter tampilan di bawah). Sub Total Variance = jumlah nilai absolut saldo member yang tidak dicentang Bukan Variance — inilah yang dibagi Total Pendapatan (SUM Payment Amount GJ pada Rekonsiliasi Pendapatan, semua Payment Method) untuk Nilai.
Saldo per Member
Saldo = Deposit − Usage member sejak awal data. Aging = umur (hari) deposit tertua yang belum terpakai (Usage menghabiskan deposit tertua lebih dulu); umur dihitung sampai tanggal akhir. Centang Bukan Variance (adjustment) untuk saldo yang wajar dan sudah dapat dijelaskan — baris itu tidak masuk Variance dan mengurangi Sub Total. Tab Variance hanya memuat saldo member yang masih dihitung sebagai variance.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Menu Penjualan Gratis (Harga Jual 0) Benar Sesuai dengan Peraturan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat transaksi menu penjualan gratis (No Price) pada rentang Sales Date tersebut.
Tujuan Strategis: Menjamin menu yang dijual dengan harga Rp 0 benar-benar dipakai sesuai tujuan promosi yang ditetapkan perusahaan, sehingga tidak ada kebocoran pendapatan akibat penjualan gratis yang tidak berhak, dan laporan penjualan serta biaya promosi dapat diandalkan.
Tujuan Operasional: Memastikan setiap transaksi menu gratis di POS dapat ditelusuri (tanggal, bill, menu, dan jumlahnya), diberikan sesuai ketentuan perusahaan, dan menu gratis yang sudah tidak terpakai segera direkomendasikan untuk dinonaktifkan.
Tujuan Kepatuhan: Memastikan pemberian menu gratis mengikuti peraturan perusahaan mengenai siapa yang berhak menerima, dalam kondisi apa, dan berapa banyak, sehingga penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian penjualan menu gratis per menu dan per bulan beserta transaksi yang tidak sesuai secara berkala, untuk bahan evaluasi program promosi dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Menu Penjualan Gratis
Dihitung dari SELURUH transaksi No Price pada rentang Sales Date (tidak ikut filter menu di tab Detail). Tidak Sesuai = transaksi yang Anda tandai Tidak Sesuai peraturan perusahaan — jumlah transaksinya dipakai untuk Nilai.
Transaksi Menu Penjualan Gratis
Akumulasi: penjualan gratis tiap menu per bulan — klik nama menu untuk melihat transaksinya di tab Detail, atau pilih Tidak Sesuai pada kolom Aturan Perusahaan untuk menandai semua transaksi menu itu sekaligus (otomatis ikut tampil di Detail dan Yang Tidak Sesuai). Detail: pada kolom Aturan Perusahaan, pilih Tidak Sesuai untuk transaksi yang menyimpang (bawaannya Sesuai). Yang Tidak Sesuai: daftar transaksi yang ditandai, lengkap dengan kolom Keterangan untuk alasannya.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Change Payment Mendapatkan Approval dari Manager
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat change payment yang sudah diunggah pada rentang tanggal perubahan tersebut.
Tujuan Strategis: Menjamin setiap perubahan metode pembayaran (change payment) pada transaksi penjualan disetujui oleh Manager, sehingga tidak terjadi manipulasi data penjualan maupun selisih antara kas dan sistem yang disembunyikan melalui perubahan pembayaran.
Tujuan Operasional: Memastikan setiap change payment di POS tercatat lengkap (waktu, bill, metode dan amount sebelum → sesudah, serta pelaksananya), dilakukan atas approval Manager, dan dana hasil perubahan — terutama dari kas ke bank — benar-benar masuk ke rekening tujuan.
Tujuan Kepatuhan: Memastikan perubahan metode pembayaran hanya dilakukan dan disetujui oleh pihak yang berwenang sesuai peraturan perusahaan, dan setiap penyimpangan terdeteksi serta ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian change payment beserta status approval Manager-nya secara berkala, untuk bahan evaluasi pengendalian kas dan penjualan serta pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Change Payment Report
Unggah file Change Payment Report dari ESB untuk entitas yang dipilih di atas. Kolom yang dibaca: Branch, Change Payment Date, Sales Date, Sales Number, Payment Method (Type & Name, Before & After), Amount (Before & After), dan Edit By. Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas.
📂
Klik atau tarik file Change Payment Report ke sini
Pilih Entitas dulu di atas
Ringkasan Change Payment
Dihitung dari SELURUH change payment pada rentang tanggal (tidak ikut filter tampilan di bawah). Satu transaksi = satu perubahan pada satu Sales Number (bisa memuat beberapa baris pembayaran). Tanpa approval Manager = transaksi yang Edit By-nya tidak termasuk yang berwenang approve menurut Setting — jumlah inilah yang dipakai untuk Nilai.
Change Payment
Transaksi: setiap baris perubahan pembayaran. Kolom Approval Manager terisi otomatis dari matriks kewenangan Edit By (Setting). Baris yang Tidak Sesuai berwarna merah. Badge Dari kas menandai perubahan dari tunai ke non-tunai — pastikan dananya masuk ke rekening lewat rekonsiliasi. Tab Perlu Tindak Lanjut hanya memuat baris yang tidak mendapat approval Manager.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Pembatalan Transaksi Harus Mendapatkan Approval dari Atasan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat pembatalan transaksi yang sudah diunggah pada rentang tanggal pembatalan tersebut.
Tujuan Strategis: Menjamin setiap pembatalan (cancel/void) transaksi penjualan hanya terjadi atas persetujuan atasan yang berwenang dan didukung berita acara, sehingga risiko fraud kasir dan manipulasi nota dapat dicegah dan pendapatan perusahaan tidak bocor.
Tujuan Operasional: Memastikan setiap pembatalan menu di POS tercatat lengkap (waktu, bill, menu, alasan, kasir, dan pihak yang membatalkan), disetujui oleh atasan sesuai kewenangannya, dan disertai berita acara beserta penjelasan kejadiannya.
Tujuan Kepatuhan: Memastikan pembatalan transaksi mengikuti kewenangan approval dan kewajiban berita acara yang ditetapkan perusahaan, serta setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian pembatalan transaksi beserta status approval dan berita acaranya secara berkala, untuk bahan evaluasi pengendalian kasir dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Cancel Menu Detail Report
Unggah file Cancel Menu Detail Report (Type Cancel / Void) dari ESB untuk entitas yang dipilih di atas. Kolom yang dibaca: Sales Number, Branch, Menu, Menu Category, Order By, Order Time, Cancel / Void By, Cancel / Void Time, Cancel / Void, Cancel Notes, Qty, dan Subtotal sampai Total. Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas.
📂
Klik atau tarik file Cancel Menu Detail Report ke sini
Pilih Entitas dulu di atas
Ringkasan Pembatalan Transaksi
Dihitung dari SELURUH pembatalan pada rentang tanggal (tidak ikut filter tampilan di bawah). Satu transaksi = satu pembatalan pada satu Sales Number pada waktu yang sama (bisa memuat banyak menu). Tidak lengkap = transaksi yang Cancel / Void By-nya tidak termasuk yang berwenang approve menurut Setting atau yang berita acaranya ditandai Tidak Ada — jumlah inilah yang dipakai untuk Nilai.
Pembatalan Transaksi
Transaksi: setiap pembatalan beserta menunya (klik "+ menu lainnya" untuk rincian). Kolom Approval Atasan terisi otomatis dari matriks kewenangan Cancel / Void By (Setting); yang Tidak Sesuai bisa diubah manual lewat Adjust ke Sesuai dan wajib diberi Keterangan Adjustment. Pada kolom Berita Acara, pilih Ada atau Tidak Ada. Baris yang tidak lengkap berwarna merah. Sub tab Belum Diperiksa memuat pembatalan yang berita acaranya belum ditentukan, Adjustment Manual memuat seluruh approval yang diubah manual (beserta keterangannya), dan Perlu Tindak Lanjut memuat yang tanpa approval atau tanpa berita acara.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Diskon Harus Mendapatkan Approval dari Atasan dan Pemberian Diskon Sesuai dengan Peraturan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat transaksi ber-diskon (Void Sales dikecualikan) pada rentang Sales Date tersebut.
Tujuan Strategis: Menjamin setiap pemberian diskon kepada pelanggan disetujui oleh atasan yang berwenang dan nominalnya sesuai peraturan perusahaan, sehingga pendapatan tidak bocor akibat diskon yang tidak berhak atau berlebihan, serta risiko kolusi kasir dan manipulasi nota dapat dicegah.
Tujuan Operasional: Memastikan setiap transaksi yang mendapat diskon di POS dapat ditelusuri (tanggal, bill, jenis promosi, nominal, dan pemrosesnya), diproses oleh pihak yang berwenang, didukung berita acara beserta penjelasan kejadiannya, dan nilai diskonnya berada dalam batas ketentuan perusahaan.
Tujuan Kepatuhan: Memastikan pemberian diskon mengikuti kewenangan approval, kewajiban berita acara, dan batas nominal yang ditetapkan perusahaan, serta setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian transaksi ber-diskon beserta status approval, berita acara, dan kesesuaian nominalnya secara berkala, untuk bahan evaluasi kebijakan promosi dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Transaksi Ber-Diskon
Dihitung dari SELURUH bill ber-diskon pada rentang Sales Date (tidak ikut tab di bawah). Satu transaksi = satu bill (Menu Discount atau Bill Discount tidak nol). Tidak lengkap = transaksi yang approval atasannya ditandai Tidak Sesuai, atau berita acaranya ditandai Tidak Ada, atau nominal diskonnya ditandai Tidak Sesuai — jumlah inilah yang dipakai untuk Nilai.
Transaksi Ber-Diskon
Transaksi: setiap bill ber-diskon dengan subtotal, diskon (beserta persennya), dan net sales. Pada kolom Approval Atasan pilih Sesuai / Tidak Sesuai, pada Berita Acara pilih Ada / Tidak Ada, dan pada Nominal Diskon pilih Sesuai / Tidak Sesuai ketentuan perusahaan. Baris yang tidak lengkap berwenang merah. Sub tab Belum Diperiksa memuat transaksi yang pemeriksaannya belum lengkap, dan Perlu Tindak Lanjut memuat yang tidak lengkap.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Compliment Harus Mendapatkan Approval dari Atasan dan Pemberian Compliment Sesuai dengan Peraturan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat transaksi compliment (Void Sales dikecualikan) pada rentang Sales Date tersebut.
Tujuan Strategis: Menjamin setiap pemberian compliment (menu atau tagihan yang digratiskan) disetujui oleh atasan yang berwenang dan dipertanggungjawabkan, sehingga compliment tidak disalahgunakan untuk menggeser atau menyembunyikan pendapatan, dan biaya promosi serta laporan penjualan dapat diandalkan.
Tujuan Operasional: Memastikan setiap transaksi compliment di POS dapat ditelusuri (tanggal, bill, alasan, nilai, dan pemrosesnya), diproses oleh pihak yang berwenang, serta didukung berita acara beserta penjelasan kejadiannya.
Tujuan Kepatuhan: Memastikan pemberian compliment mengikuti kewenangan approval, kewajiban berita acara, serta ketentuan siapa, kapan, dan berapa besar compliment boleh diberikan menurut peraturan perusahaan, dan setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian transaksi compliment beserta status approval dan berita acaranya secara berkala, untuk bahan evaluasi kebijakan compliment dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Transaksi Compliment
Dihitung dari SELURUH bill compliment pada rentang Sales Date (tidak ikut tab di bawah). Satu transaksi = satu bill dengan payment method COMPLIMENT. Tidak lengkap = transaksi yang approval atasannya ditandai Tidak Sesuai, atau berita acaranya Tidak Ada, atau compliment-nya ditandai Tidak Sesuai peraturan — jumlah inilah yang dipakai untuk Nilai.
Transaksi Compliment
Transaksi: setiap bill compliment dengan alasan (Notes), grand total bill, dan nilai compliment-nya. Pada kolom Approval Atasan pilih Sesuai / Tidak Sesuai, pada Berita Acara pilih Ada / Tidak Ada, dan pada Compliment pilih Sesuai / Tidak Sesuai peraturan perusahaan. Baris yang tidak lengkap berwarna merah. Sub tab Belum Diperiksa memuat compliment yang penilaiannya belum lengkap, dan Perlu Tindak Lanjut memuat yang approval-nya tidak sesuai, tanpa berita acara, atau compliment-nya tidak sesuai.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Nama Customer, No Meja Bukan Fiktif (Sesuai Lay Out Resto) saat Transfer Table dan Harus Mendapatkan Approval dari Atasan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat pindah meja yang sudah diunggah pada rentang Event Date tersebut.
Tujuan Strategis: Menjamin pemindahan meja (transfer table) pada transaksi penjualan hanya dilakukan untuk customer dan nomor meja yang nyata sesuai lay out resto, atas persetujuan atasan yang berwenang, sehingga risiko fraud kasir dan manipulasi nota dapat dicegah dan pendapatan perusahaan terlindungi.
Tujuan Operasional: Memastikan setiap pindah meja di POS tercatat lengkap (waktu, Sales Number, meja asal, meja tujuan, dan pihak yang memproses), nama customer dan nomor meja sesuai lay out resto dan bukan fiktif, disetujui atasan sesuai kewenangannya, serta didukung berita acara beserta dasar pemindahannya.
Tujuan Kepatuhan: Memastikan pindah meja mengikuti kewenangan approval dan kewajiban berita acara yang ditetapkan perusahaan, serta setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian pindah meja beserta status approval, berita acara, dan dasar pemindahannya secara berkala, untuk bahan evaluasi pengendalian kasir dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Move Table Report
Unggah file Move Table Report dari ESB untuk entitas yang dipilih di atas. Kolom yang dibaca: Branch, Event Date, Sales Number, Description (Move Table From Table X To Table Y), dan Created By. Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas.
📂
Klik atau tarik file Move Table Report ke sini
Pilih Entitas dulu di atas
Ringkasan Pindah Meja
Dihitung dari SELURUH pindah meja pada rentang tanggal (tidak ikut filter tampilan di bawah). Satu kejadian = satu baris Move Table Report. Tidak lengkap = kejadian yang Created By-nya tidak termasuk yang berwenang approve menurut Setting atau yang berita acaranya ditandai Tidak Ada — jumlah inilah yang dipakai untuk Nilai. Dasar Move Table hanya dokumentasi dan tidak mempengaruhi Nilai.
Pindah Meja (Transfer Table)
Pindah Meja: setiap kejadian beserta meja asal dan tujuannya. Kolom Approval Atasan terisi otomatis dari matriks kewenangan Created By (Setting); pada kolom Berita Acara, pilih Ada atau Tidak Ada; pada Dasar Move Table, tulis alasan pindah meja secara manual (tersimpan saat Anda pindah dari kolom). Baris yang tidak lengkap berwarna merah. Sub tab Belum Diperiksa memuat kejadian yang berita acaranya belum ditentukan, dan Perlu Tindak Lanjut memuat yang tanpa approval atau tanpa berita acara.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan bahwa Pemakaian Voucher dan Kode Referral yang Terbit Merupakan Asli dari Perusahaan dan Pemakaiannya Sesuai dengan Aturan Perusahaan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat pemakaian voucher (Void Sales dikecualikan) pada rentang Sales Date tersebut.
Tujuan Strategis: Menjamin bahwa setiap voucher dan kode referral yang dipakai pada transaksi penjualan benar-benar diterbitkan oleh perusahaan dan dipakai sesuai aturan, sehingga perusahaan terhindar dari kerugian penjualan akibat voucher palsu atau penyalahgunaan promo, dan efektivitas program promosi dapat dipertanggungjawabkan.
Tujuan Operasional: Memastikan setiap pemakaian voucher di POS dapat ditelusuri (tanggal, kode voucher, jenis, bill, nilai diskon, dan pemrosesnya), dicocokkan dengan form pengajuan voucher yang tercatat di sistem ESB, serta setiap kode voucher hanya dipakai sesuai ketentuan (tidak berulang, sesuai jenis dan peruntukannya).
Tujuan Kepatuhan: Memastikan penerbitan dan pemakaian voucher serta kode referral mengikuti aturan perusahaan mengenai siapa yang berwenang menerbitkan, syarat dan masa berlaku, serta batas pemakaian, dan setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian pemakaian voucher beserta hasil pemeriksaan keaslian dan kesesuaian pemakaiannya secara berkala, untuk bahan evaluasi program promosi dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Pemakaian Voucher
Dihitung dari SELURUH pemakaian voucher pada rentang Sales Date (tidak ikut tab di bawah). Satu pemakaian = satu baris pembayaran VOUCHER (bill yang memakai dua voucher dihitung dua pemakaian). Tidak lengkap = pemakaian yang voucher-nya ditandai Bukan Asliatau pemakaiannya ditandai Tidak Sesuai aturan perusahaan — jumlah inilah yang dipakai untuk Nilai. Approval atasan hanya informasi.
Pemakaian Voucher
Pemakaian Voucher: setiap pemakaian dengan kode & jenis voucher (dari Notes pembayaran), bill, nilai bill, dan pemrosesnya. Kode yang dipakai lebih dari sekali diberi tanda merah Dipakai N×. Di bawah kode tertera tanggal terbit yang dibaca dari kode (mis. 010826 = 01-08-2026): pil abu-abu = terbit di bulan yang sama dengan pemakaian, pil kuning bergaris putus-putus ◆ lintas bulan = voucher dipakai di bulan setelah bulan terbit (periksa masa berlakunya), pil merah ⚠ = tanggal terbit pada kode melewati tanggal pemakaian. Kolom Approval Atasan terisi otomatis dari matriks kewenangan Cashier (Setting, hanya informasi); pada Voucher dari Perusahaan pilih Asli / Bukan Asli, dan pada Pemakaian pilih Sesuai / Tidak Sesuai aturan perusahaan. Baris yang tidak lengkap berwarna merah. Sub tab Urut Kode Voucher menampilkan seluruh pemakaian yang diurutkan menurut kode voucher dan dikelompokkan per awalan kode (bisa dicari, atau disaring hanya kode yang dipakai berulang), Belum Diperiksa memuat pemakaian yang penilaiannya belum lengkap, dan Perlu Tindak Lanjut memuat yang bukan asli atau tidak sesuai.
Isi cepatuntuk semua pemakaian yang belum diperiksa pada rentang tanggal ini — yang sudah Anda pilih tidak berubah:
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Melakukan Voucher yang Extended Terdapat Berita Acara dan Terdapat Approval dari Atasan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat voucher yang diupdate pada rentang tanggal log tersebut.
Tujuan Strategis: Menjamin bahwa setiap perpanjangan masa berlaku (extend) voucher hanya dilakukan secara sah, didukung berita acara, dan disetujui atasan yang berwenang, sehingga voucher yang sudah kedaluwarsa tidak dihidupkan kembali secara tidak sah dan perusahaan terhindar dari kerugian penjualan akibat penyalahgunaan promo.
Tujuan Operasional: Memastikan setiap update voucher di Master Voucher ESB dapat ditelusuri (waktu, kode voucher, masa berlaku sebelum dan sesudah, serta pelakunya), disertai berita acara beserta alasan perubahannya, dan mendapat approval atasan sebelum voucher dipakai kembali.
Tujuan Kepatuhan: Memastikan perpanjangan masa berlaku voucher mengikuti kewenangan approval dan kewajiban berita acara yang ditetapkan perusahaan, serta setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian voucher yang diupdate beserta status berita acara, approval, dan alasan updatenya secara berkala, untuk bahan evaluasi pengendalian voucher dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Transaction Log Report
Unggah Transaction Log Report dari ESB untuk entitas yang dipilih di atas — otomatis difilter ke Transaction Type "Master Voucher" & Description "Update Voucher" saja; kode voucher serta tanggal berakhir sebelum dan sesudah diambil dari kolom Before Value & After Value. Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas. Unggahan yang sama juga bisa dilakukan sekaligus untuk semua kontrol di Setting → Transaction Log.
📂
Klik atau tarik file Transaction Log Report ke sini
Pilih Entitas dulu di atas — entitas pada file akan dicocokkan otomatis
Ringkasan Voucher yang Diupdate
Dihitung dari SELURUH update voucher pada rentang tanggal (tidak ikut tab di bawah). Satu update = satu voucher pada satu log Update Voucher. Tidak lengkap = update yang berita acaranya ditandai Tidak Adaatau approval atasannya ditandai Tidak Ada — jumlah inilah yang dipakai untuk Nilai. Status expired saat diupdate dan Alasan Update hanya penanda dan dokumentasi, tidak mempengaruhi Nilai.
Voucher yang Diupdate
Update Voucher: setiap voucher yang diupdate dengan tanggal berakhir sebelum → sesudah (+30 hari = diperpanjang), status masa berlaku saat diupdate (Sudah expired = sudah lewat masa berlaku ketika diupdate), dan pelakunya. Pada kolom Berita Acara dan Approval Atasan pilih Ada / Tidak Ada; pada Alasan Update tulis jawaban atas pertanyaan mengapa kode voucher tersebut diupdate (tersimpan saat Anda pindah dari kolom). Baris yang tidak lengkap berwarna merah. Sub tab Belum Diperiksa memuat update yang penilaiannya belum lengkap, dan Perlu Tindak Lanjut memuat yang tanpa berita acara atau tanpa approval.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Pengembalian Payment (Refund) Harus Dipastikan Mendapatkan Approval, Bukti Transaksi, dan Berita Acara
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat refund yang sudah diisi pada rentang Refund Date tersebut dan mengaktifkan formulir Catat Refund.
Tujuan Strategis: Menjamin setiap pengembalian payment (refund) kepada customer hanya dilakukan atas dasar yang sah, disetujui atasan yang berwenang, dan didukung bukti transaksi serta berita acara, sehingga risiko penyalahgunaan refund, kebocoran pendapatan, dan hilangnya bukti transaksi dapat dicegah.
Tujuan Operasional: Memastikan setiap refund tercatat lengkap (transaksi asal, payment method, tanggal dan nilai refund, serta cara pengembaliannya), dapat ditelusuri ke bill di sistem, disertai bukti dana masuk dan berita acara, serta penyebab refund (kelebihan pembayaran atau double settlement) sudah diperiksa.
Tujuan Kepatuhan: Memastikan refund mengikuti kewenangan approval dan kewajiban bukti transaksi serta berita acara yang ditetapkan perusahaan, dan setiap penyimpangan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian refund beserta status approval, bukti transaksi, dan berita acaranya secara berkala, untuk bahan evaluasi pengendalian pengembalian payment dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Refund
Dihitung dari SELURUH refund pada rentang Refund Date (tidak ikut tab di bawah). Tidak lengkap = refund yang Approval-nya ditandai Tidak Ada, atauBukti Transaksi-nya (bukti dana masuk) ditandai Tidak Ada, atauBerita Acara-nya ditandai Tidak Ada — jumlah inilah yang dipakai untuk Nilai. Penanda refund melebihi Grand Total hanya informasi.
Hasil pemeriksaan (boleh dikosongkan dan dipilih nanti lewat tabel; klik pilihan yang aktif untuk membatalkan)
Approvalatasan
Bukti Transaksibukti dana masuk
Berita Acaraada / tidak
Refund: setiap refund beserta transaksi asalnya. Pada kolom Approval, Bukti Transaksi, dan Berita Acara pilih Ada / Tidak Ada (tersimpan otomatis). Gunakan Ubah / Hapus di kolom Aksi untuk memperbaiki data. Baris yang tidak lengkap berwarna merah. Sub tab Belum Diperiksa adalah daftar kerja refund yang approval, bukti, atau berita acaranya masih kosong (belum Anda pilih Ada / Tidak Ada) — belum dihitung untuk Nilai sampai dipilih. Sub tab Perlu Tindak Lanjut memuat refund yang sudah ditandai tanpa approval, tanpa bukti dana masuk, atau tanpa berita acara.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan User Manager Tidak Digunakan untuk Melakukan Penjualan
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat file Staff Sales & Cancel Report yang periodenya beririsan dengan rentang tanggal tersebut, serta Total Pendapatan dari General Journal pada rentang yang sama.
Tujuan Strategis: Menjamin akun user dengan kewenangan manager hanya dipakai untuk fungsi pengawasan dan persetujuan, bukan untuk melakukan penjualan, sehingga prinsip pemisahan tugas terjaga dan risiko manipulasi data transaksi oleh pihak yang memiliki akses luas dapat dicegah.
Tujuan Operasional: Memastikan setiap penjualan di POS dilakukan oleh user kasir atau staf yang berwenang, user manager tidak melakukan transaksi sampai pembayaran (create order diperbolehkan), dan aktivitas cancel, void, dan remove per user dapat ditelusuri dari Staff Sales & Cancel Report.
Tujuan Kepatuhan: Memastikan pembagian hak akses user POS mengikuti ketentuan perusahaan, dan setiap penjualan oleh user yang tidak diperbolehkan terdeteksi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan rincian penjualan dan aktivitas pembatalan per user beserta ruang perbaikan penjualan oleh user manager terhadap Total Pendapatan secara berkala, untuk bahan evaluasi pengendalian akses dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Unggah Staff Sales & Cancel Report
Unggah file Staff Sales & Cancel Report (Sales Type Sales) dari ESB untuk entitas yang dipilih di atas. Kolom yang dibaca: User, Branch, Sales Qty, Sales Total, Cancel, Void, dan Remove (Qty dan Total), serta Period pada bagian atas file. Laporan ini merangkum satu periode, jadi unggah file yang periodenya sesuai rentang tanggal di atas (mis. satu bulan penuh). Mengunggah ulang file yang sama tidak menggandakan data; entitas pada file dicocokkan dengan pilihan di atas.
📂
Klik atau tarik file Staff Sales & Cancel Report ke sini
Pilih Entitas dulu di atas
Ringkasan Penjualan per User
Dihitung dari SELURUH user pada file yang periodenya beririsan dengan rentang tanggal. Selisih = jumlah Sales Total user yang ditetapkan Tidak Boleh dipakai untuk penjualan (create order tanpa nilai penjualan tidak dihitung); selisih ini dibandingkan dengan Total Pendapatan (Payment Amount GJ pada Rekonsiliasi Pendapatan, Cut Off Audit) dan menjadi dasar Nilai. User yang belum ditetapkan belum ikut dihitung.
Penjualan, Cancel, Void & Remove per User
Semua User: setiap user dengan penjualan dan aktivitas pembatalannya (nilai dan qty), digabung dari seluruh branch. Pada kolom Penggunaan tetapkan Boleh, Change Payment (user dipakai untuk change payment, bukan penjualan — dihitung sama dengan Boleh), atau Tidak Boleh dipakai untuk penjualan (tersimpan otomatis per entitas dan berlaku untuk periode berikutnya); kolom Ruang Perbaikan terisi otomatis. Sub tab Belum Ditetapkan memuat user yang penggunaannya belum dipilih, dan Perlu Tindak Lanjut memuat user tidak boleh yang memiliki penjualan.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Memastikan Proses Siklus Pendapatan Sesuai dengan SOP
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). "Tampilkan" memuat jumlah transaksi pendapatan per tanggal pada rentang tersebut. Data berasal dari Sales Recapitulation & Sales Payment Recapitulation (Setting → Data sumber), laporan Change Payment, Cancel Menu, dan Move Table (diunggah di CA masing-masing), serta refund (diisi di CA Refund).
Tujuan Strategis: Menjamin seluruh proses siklus pendapatan di outlet (penerimaan cash, change payment, pembatalan, pindah meja, diskon, compliment, dan refund) berjalan sesuai SOP perusahaan, sehingga pendapatan tercatat lengkap dan benar, serta penyalahgunaan akses dan manipulasi data transaksi dapat dicegah.
Tujuan Operasional: Memastikan kasir dan staf menjalankan prosedur transaksi sesuai SOP pada setiap jam operasional, termasuk otorisasi bertingkat oleh atasan yang berwenang, penerimaan uang tunai oleh kasir, dan pengurangan pax sesuai kondisi meja yang sebenarnya, yang dibuktikan melalui pengujian transaksi terhadap rekaman CCTV.
Tujuan Kepatuhan: Memastikan setiap transaksi pendapatan, khususnya yang memerlukan otorisasi (diskon, pembatalan, change payment, compliment, refund), dilakukan dan disetujui sesuai kewenangan yang ditetapkan SOP, dan setiap penyimpangan terdeteksi serta ditindaklanjuti.
Tujuan Pelaporan: Menyediakan hasil uji kendali per hari beserta daftar transaksi yang tidak sesuai SOP dan keterangan hasil pengecekan CCTV secara berkala, untuk bahan evaluasi pengendalian outlet dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Uji Kendali
Status tiap hari dihitung otomatis dari penilaian transaksi: hari diuji bila minimal satu transaksinya sudah dinilai, tidak sesuai bila ada transaksi yang ditandai Tidak Sesuai SOP, dan sesuai SOP bila seluruh transaksinya dinilai Sesuai. Jumlah hari yang tidak sesuai inilah yang dipakai untuk Nilai.
Uji Kendali per Hari
Pilih tanggal yang akan diuji, lalu klik Periksa. Kolom Transaksi menunjukkan jumlah transaksi per jenis pada tanggal itu.
Transaksi per Jam
Urut jam supaya mudah dicocokkan dengan CCTV. Pada kolom Sesuai SOP? pilih Sesuai / Tidak Sesuai (tersimpan otomatis); tulis hasil cek CCTV di Keterangan CCTV. Filter jenis di bawah membantu memeriksa satu jenis transaksi dulu.
Untuk tanggal ini (sesuai filter jenis di atas):
Daftar Ruang Perbaikan
Seluruh transaksi yang ditandai Tidak Sesuai SOP pada rentang tanggal ini (semua hari), lengkap dengan keterangan hasil cek CCTV. Klik Buka hari untuk kembali ke transaksi pada hari itu.
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & periode yang dipilih di atas.
Control Activities — Cash Opname
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Tanggal akhir menjadi tanggal saldo buku: ubah ke tanggal pelaksanaan cash opname bila penghitungan fisik dilakukan sebelum akhir bulan. "Tampilkan" memuat General Journal entitas ini kalau belum ada di memori.
Tujuan Strategis: Menjaga keberadaan dan keamanan aset kas perusahaan, sehingga saldo kas dan rekening penampungan yang disajikan dalam laporan keuangan benar-benar ada, dapat dipertanggungjawabkan, dan terlindung dari kehilangan maupun penyalahgunaan.
Tujuan Operasional: Memastikan saldo buku Kas Besar, Kas Kecil, Tabungan Cash, Rekening Penampungan, dan Rekening Penampungan 3 sesuai dengan uang fisik yang sebenarnya ada saat penghitungan, serta setiap selisih lebih maupun kurang segera diketahui dan ditelusuri penyebabnya.
Tujuan Kepatuhan: Memastikan pengelolaan uang tunai dan rekening penampungan mengikuti prosedur serta batas toleransi selisih yang ditetapkan perusahaan, dan cash opname dilaksanakan secara berkala pada bulan berjalan.
Tujuan Pelaporan: Menyediakan perbandingan saldo buku dengan uang fisik per akun beserta selisihnya secara berkala, sebagai bahan evaluasi pengendalian kas dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Cash Opname
Selisih Terbesar = selisih (nilai absolut) paling besar di antara akun yang uang fisiknya sudah diisi — inilah yang menjadi dasar Nilai. Nilai baru bisa disimpulkan setelah semua akun bersaldo diisi uang fisiknya.
Saldo Buku vs Uang Fisik
Satu baris = satu akun. Saldo Buku = Debit − Kredit General Journal kumulatif s.d. tanggal akhir (sama dengan saldo akun di Balance Sheet). Ketik Uang Fisik hasil penghitungan pada kolom yang tersedia (tekan Enter untuk pindah ke baris berikutnya; tersimpan otomatis). Selisih = Uang Fisik − Saldo Buku: Kurang bila uang fisik lebih sedikit dari saldo buku, Lebih bila lebih banyak.
Catatan Prosedur
Tidak ada catatan prosedur untuk Control Activity ini.
Control Activities — Memastikan Saldo Akun L/R Sistem, L/R Excel (Dikirim Email), dan Time Series telah sama
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Rentang tanggal ini menjadi periode L/R Sistem (sama dengan filter Journal Date di Report Profit Loss). "Tampilkan" memuat General Journal entitas ini kalau belum ada di memori.
Tujuan Strategis: Menjamin laporan laba rugi yang disajikan kepada manajemen dan pemilik konsisten di semua sumber (sistem, file Excel yang dikirim melalui email, dan time series), sehingga keputusan bisnis diambil berdasarkan angka yang akurat, utuh, dan dapat dipercaya.
Tujuan Operasional: Memastikan saldo setiap akun L/R pada sistem sama dengan L/R pada file Excel yang dikirim melalui email dan L/R pada time series, serta setiap variance segera diketahui, ditelusuri penyebabnya, dan dikoreksi.
Tujuan Kepatuhan: Memastikan penyusunan dan pengiriman laporan laba rugi mengikuti prosedur dan struktur akun yang ditetapkan perusahaan, tanpa perubahan angka di luar sistem akuntansi.
Tujuan Pelaporan: Menyediakan perbandingan L/R Sistem, L/R Excel, dan L/R Time Series per akun beserta variance-nya secara berkala, sebagai bahan evaluasi keandalan pelaporan keuangan dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Ringkasan Perbandingan L/R
Variance Terbesar = variance (nilai absolut) paling besar di antara semua baris yang sudah diisi, baik terhadap L/R Excel maupun L/R Time Series — inilah dasar Nilai. Nilai bisa disimpulkan begitu kolom L/R Excel dan L/R Time Series masing-masing sudah terisi minimal satu baris; baris yang belum diisi belum ikut dibandingkan.
L/R Sistem vs L/R Excel vs L/R Time Series
Struktur baris sama dengan Report → Profit Loss (akun, subtotal, dan hasil). Ketik angka pada kolom L/R Excel dan L/R Time Series sesuai tanda dan nilai di laporan tersebut (tekan Enter untuk pindah ke baris berikutnya; tersimpan otomatis). Untuk mengisi cepat, salin satu kolom dari Excel lalu tempel (Ctrl+V) pada sel pertama — angka mengisi ke bawah sesuai urutan baris. Variance = L/R Sistem − L/R Excel (atau Time Series).
Catatan Prosedur
Tidak ada catatan prosedur untuk Control Activity ini.
Control Activities — Memastikan bahwa adanya aturan yang mendukung untuk proses bisnis atau ketaatan terhadap aturan yang sudah ada
Kertas kerja Control Activities, Siklus Lain-lain. Control Activity ini tidak memakai data atau ceklist: temuan atas aturan yang belum tersedia atau belum ditaati langsung ditulis di tab Report (kondisi, dampak, rekomendasi, dan management action). Jika terdapat Report, Nilai otomatis 0; jika tidak ada temuan, centang Tidak Ada Temuan. Nilai resmi tersimpan saat Anda klik "Simpan Report" (mengunci Nilai & memulai rantai approval).
s.d.
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix — pilih dulu, tanggal s.d. di atas otomatis terisi satu bulan penuh (bisa diubah manual). Rentang tanggal dicatat sebagai Cut Off Audit pada Report.
Tujuan Strategis: Menjamin setiap proses bisnis perusahaan didukung aturan yang jelas, terdokumentasi, dan dipatuhi, sehingga risiko operasional serta penyimpangan dapat dicegah dan pencapaian tujuan perusahaan tetap terjaga.
Tujuan Operasional: Memastikan setiap proses bisnis memiliki SOP, kebijakan, atau aturan tertulis yang mutakhir, dan seluruh pelaksana memahami serta menjalankan aturan tersebut dalam kegiatan sehari-hari.
Tujuan Kepatuhan: Memastikan aturan yang sudah ada, baik internal maupun peraturan eksternal yang berlaku, ditaati; setiap proses yang belum memiliki aturan pendukung atau pelanggaran terhadap aturan diidentifikasi dan ditindaklanjuti.
Tujuan Pelaporan: Menyediakan laporan temuan atas proses bisnis yang belum memiliki aturan pendukung atau belum ditaati, lengkap dengan kondisi, dampak, rekomendasi, dan tindak lanjut manajemen, sebagai bahan evaluasi pengendalian internal.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Bulan Berjalan
Status Report
Report adalah satu-satunya isian Control Activity ini. Tulis temuan langsung di tab Report; begitu disimpan, Nilai periode ini otomatis 0. Jika pada periode ini tidak ada temuan, centang Tidak Ada Temuan di bawah.
Catatan Prosedur
Tidak ada catatan prosedur untuk Control Activity ini.
Control Activities — Cash Opname Kasir
Periode (bulan/tahun) menandai titik waktu nilai Control Activity ini di Risk Matrix. Isi Mulai dan Sampai sesuai jam kasir dibuka hingga saat cash opname dilakukan; penjualan cash yang dihitung adalah bill yang dibayar (jam keluar / Sales Out Time) dalam rentang itu. Satu Nilai tersimpan per entitas per periode (bulan).
Tujuan Strategis: Menjaga keamanan uang tunai hasil penjualan di kasir, sehingga seluruh penjualan cash tercatat lengkap, setoran dapat dipertanggungjawabkan, dan perusahaan terlindung dari kehilangan maupun penyalahgunaan uang kasir.
Tujuan Operasional: Memastikan uang fisik di kasir sama dengan penjualan cash pada Sales Recapitulation ditambah modal kasir pada saat cash opname, serta setiap selisih lebih maupun kurang segera diketahui dan ditelusuri penyebabnya.
Tujuan Kepatuhan: Memastikan kasir mengelola uang tunai sesuai prosedur dan batas toleransi selisih yang ditetapkan perusahaan, termasuk besaran modal kasir yang ditetapkan, dan cash opname kasir dilakukan secara mendadak maupun berkala.
Tujuan Pelaporan: Menyediakan hasil perbandingan penjualan cash, modal kasir, dan uang fisik beserta selisihnya pada saat cash opname, sebagai bahan evaluasi pengendalian kas outlet dan pelaporan kepada manajemen.
Event Identification & Risk Assessment
Bisa lebih dari satu skenario risiko utk satu Control Activity ini.
No Event Identification & Risk Assessment
Nama Event Identification & Risk Assessment
Jangka Waktu
Saat Itu Juga
Perhitungan Kas Kasir
Uang yang seharusnya di kasir = Penjualan Cash (Sales Recapitulation) + Modal Kasir. Ketik Uang Fisik hasil penghitungan; tersimpan otomatis. Selisih = Uang Fisik − Seharusnya: Kurang bila uang fisik lebih sedikit, Lebih bila lebih banyak.
Rincian Penjualan Cash
Dasar angka Penjualan Cash di atas: bill (bukan Void) dengan pembayaran CASH/TUNAI pada rentang tanggal & jam yang dipilih. Nominal = jumlah pembayaran cash pada bill itu (bill dengan pembayaran campuran hanya dihitung bagian cash-nya).
Catatan Prosedur
Tandai sudah dikerjakan atau belum, per entitas & rentang yang dipilih di atas.
Risk Matrix — Corporate
Ringkasan Risk Matrix tingkat korporat (gabungan seluruh entitas).
Belum tersedia — menyusul setelah struktur konsolidasi tingkat korporat ditentukan. Untuk saat ini, lihat Risk Matrix per entitas di Branch.
Risk Matrix — Branch
Nilai Control Activities per entitas, disusun per Siklus → Event Identification & Risk Assessment → Control Activity, time series per periode (bulan) — sumbernya "Simpan Nilai" di tiap halaman Control Activities, jadi selalu ikut update begitu nilai baru disimpan di sana.
SOP — Standar Operasional Prosedur
Seluruh SOP yang berlaku di Kakkoii, KJT Group & Kurnia Seafood beserta formulir pendukungnya. Yang tampil adalah versi terbaru; versi sebelumnya tersimpan sebagai riwayat dan tetap bisa dibuka.
Internal Memo — IM
Memo internal yang berlaku, dikelompokkan per departemen penerbit. Tanggal adalah tanggal terbit memo; nomor mengikuti yang tertera di dalam dokumen.
Lain-Lain — Dokumen Pendukung
Dokumen di luar SOP & IM: manajemen audit internal, manajemen umum, data frame Kakkoii & Kurnia Seafood, serta data aset. Yang tampil adalah versi terbaru; versi sebelumnya tersimpan sebagai riwayat.
Setting
Kelola data sumber, data master, dan aturan Control Activities.
General Journal
Ekspor ESB menu Report → Journal (.xlsx). Entitas dibaca dari file; baris yang sudah tersimpan dilewati.
Sumber: ESB → Report → Journal
Selengkapnya
Unggah file ekspor General Journal dari ESB (format .xlsx, menu Report → Journal). Baris yang sama persis dengan yang sudah tersimpan otomatis dilewati (tidak dobel) — jadi unggah ulang entitas yang sama (walau periodenya tumpang tindih) aman, data baru akan digabung dengan yang lama. Voucher yang direvisi di ESB (nomornya tetap sama, isinya berubah) otomatis dipakai versi dari file ini — baris versi lamanya dibuang, jadi tidak menumpuk dua versi.
1
Cara menyimpan
SELURUH baris di rentang tanggal file ini DIHAPUS dulu, baru diisi ulang dari file. Hanya boleh dipakai kalau file ini re-export SEMUA branch (Branch = "Multi Branches" di ESB) dan lengkap untuk rentang tanggalnya. Kalau export-nya tersaring per branch/tipe, data yang tidak ada di file akan hilang dari General Ledger s.d. Cash Flow tanpa gejala apa pun — jurnalnya tetap balance walau isinya berkurang. Untuk sekadar membuang dokumen yang sudah dihapus di ESB, pakai Opsi tambahan di langkah 2.
2
Opsi tambahan
3
Pilih file
Unggahan langsung diproses begitu file dipilih, jadi atur langkah di atas lebih dulu.
Klik atau tarik file Excel General Journal ke sini
Bisa beberapa file sekaligus (BKKR, KKVT, KKMTH, AKCL, KKST, dst.) · format ekspor ESB dengan header laporan di baris atas
Data Tersimpan
Jenis
Entitas
File
Baris
Periode
Diunggah
Laporan lain dari Kertas Kerja Control ActivitiesGoods Delivery Recapitulation, Transfer Report, dan Purchase Item Summary yang diunggah di tab Kertas Kerja kontrolnya. Transaction Log Report ada di tab Transaction Log.
Hapus semua data sumberKhusus admin. Semua dataset di tab Data sumber (General Journal, Detail Pembelian, Rekening Koran, Sales, Stock Opname, Pricelist) dan semua unggahan dari Kertas Kerja Control Activities, untuk semua entitas, ikut terhapus dan tidak bisa dikembalikan.
Detail Pembelian (PR → PO → GR)
Goods Receipt Recapitulation, Purchase Order Actuation Detail, Outstanding Purchase, dan Purchase Payment Report. Jenis laporan dikenali dari header-nya. Opsional.
Sumber: ESB
Selengkapnya
Unggah Goods Receipt Recapitulation Report, Purchase Order Actuation Detail Report, dan/atau Outstanding Purchase Report dari ESB supaya tiap Goods Receipt di General Journal menampilkan rantai PR → PO di baliknya, kategori pembeliannya (Sayur/Buah/Air Galon/Es Kristal-Es Tube/Non Food) ikut dipakai utk penandaan "Perlu Tanda Terima", dan PO yang masih menggantung (belum di-GR/di-invoice penuh) ditandai (Outstanding).
1
Cara menyimpan
HANYA berlaku utk file Purchase Order Actuation Detail Report, pakai kalau file ini re-export BERSIH & LENGKAP utk rentang tanggalnya (mis. ada PO yg dikoreksi/reissue di ESB sejak upload terakhir). Baris PO lama di rentang tanggal file ini akan DIHAPUS dulu sebelum diisi ulang — akan ada pratinjau jumlah baris utk dikonfirmasi dulu. Tidak berlaku utk GR Recapitulation (tak ada tanggal per baris) maupun Purchase Payment. Outstanding Purchase selalu diganti utuh otomatis. Kalau ragu, pilih Gabung.
2
Pilih file
Unggahan langsung diproses begitu file dipilih, jadi atur langkah di atas lebih dulu.
Klik atau tarik file Goods Receipt Recapitulation / Purchase Order Actuation Detail / Outstanding Purchase Report / Purchase Payment Report ke sini
Jenis file dideteksi otomatis dari header laporan · bisa beberapa file sekaligus
Data Tersimpan — Detail Pembelian
Jenis
Entitas
File
Baris
Periode
Diunggah
Transaction Log Report
Satu ekspor Transaction Log Report per entitas dipakai 24 kontrol. Unggah sekali di sini; tiap kontrol mengambil transaksinya sendiri.
Sumber: ESB → Transaction Log Report
Selengkapnya
Sama dengan mengunggah file yang sama di tab Kertas Kerja tiap kontrol satu per satu: setiap kontrol memakai penyaringnya sendiri (Transaction Type dan Description), baris yang sudah tersimpan dilewati, dan data disimpan ke entitas tujuan yang dipilih. Kontrol yang tidak menemukan transaksinya ditandai “Tidak ada di file ini”; kalau ekspornya disaring per Transaction Type, kontrol lain memang tidak mendapat data. Centang “Tidak Ada Transaksi” di Kertas Kerja kontrol itu tetap diisi di sana karena terikat periode kerja. Unggah di Kertas Kerja masing-masing kontrol tetap bisa dipakai.
1
Cara menyimpan
Selalu digabung dengan data lama. Baris yang sama persis dilewati.
2
Semua file di unggahan ini disimpan ke entitas ini.
3
Pilih file
Pilih entitas tujuan dulu. Bisa beberapa file sekaligus untuk entitas yang sama; hasil per kontrol tampil di bawah.
Klik atau tarik file Transaction Log Report ke sini
Ekspor ESB tanpa saringan Transaction Type, supaya semua kontrol mendapat datanya · .xlsx
Cakupan Transaction Log per entitas
Rentang periode file Transaction Log yang sudah diunggah per entitas, dihitung dari riwayat unggah (bukan dari tanggal transaksi, karena kontrol seperti Delete bisa lama tanpa transaksi). Merah berarti ada periode di dalam rentang itu yang tidak tercakup file mana pun.
Rincian per entitasPeriode, jumlah baris, file terakhir, dan hapus data per jenis transaksi.
Rekening Koran
PDF mutasi BCA (Kredit Korporat) atau BRI (Laporan Transaksi), untuk rekonsiliasi pendapatan dan pembayaran.
Sumber: internet banking
Selengkapnya
Unggah PDF mutasi rekening BCA/BRI (Kredit Korporat / Laporan Transaksi). Pilih dulu entitas tujuan di bawah — semua file yang diunggah dalam batch ini akan disimpan ke entitas tersebut (nama pemilik rekening di PDF tetap dicocokkan sbg pengecek, tapi entitas final mengikuti pilihan ini).
1
Cara menyimpan
Digabung ke data rekening koran entitas tujuan. Nama pemilik rekening di PDF dicocokkan sebagai pengecek.
2
Semua file di unggahan ini disimpan ke entitas ini.
3
Pilih file
Pilih entitas tujuan dulu. Setelah PDF dibaca, periksa nama akun bank di pratinjau lalu klik Simpan ke Server.
Klik atau tarik file PDF rekening koran ke sini
Bisa beberapa file sekaligus · format Laporan Mutasi BCA atau Laporan Transaksi BRI · pilih entitas tujuan dulu di atas
Data Tersimpan — Rekening Koran
Entitas
Rincian Akun Bank
Baris
Periode
Diunggah
Master Supplier — utk Rekonsiliasi Pembayaran
Daftar Vendor Name → Account Name/Number/Bank tujuan pembayaran, dipakai membandingkan "Rekening Tujuan" pada Rekonsiliasi Pembayaran di General Journal. Pilih dulu entitas di bawah, lalu unggah file Excel Master Supplier (bisa multi-sheet per cabang — pilih sheet yang sesuai) atau tambah/koreksi baris secara manual.
📁
Klik atau tarik file Excel Master Supplier ke sini
Kolom yang dibaca: Vendor Name, Account Name, Account Number, Bank · pilih entitas dulu di atas
Daftar Supplier Tersimpan
Pilih entitas dulu di atas.
Master Chart of Account — berlaku utk SEMUA entitas
Unggah file ekspor "Master Charts Of Account Management" dari ESB (Coa No, Coa Level, Description, Allow Memorial Journal). Satu file berlaku utk semua entitas sekaligus — kolom "Branch" pada file diabaikan karena struktur CoA-nya sama lintas cabang. Dipakai mengelompokkan akun Aset/Liabilitas/Ekuitas & Lancar/Tidak Lancar pada Report → Balance Sheet.
📂
Klik atau tarik file Excel Master Chart of Account ke sini
Kolom yang dibaca: Coa No, Coa Level, Description, Allow Memorial Journal
Data Tersimpan — Master Chart of Account
Belum ada Master COA tersimpan.
Sales Recapitulation
Sales Recapitulation (Bill Report, termasuk Void Sales) dan Sales Payment Recapitulation, dikenali dari header-nya. Unggah keduanya: Payment Method hanya ada di laporan Payment.
Sumber: ESB
Selengkapnya
Unggah Sales Recapitulation Report (ekspor ESB, Sales Report Type: Bill Report) dan Sales Payment Recapitulation Report. Keduanya dideteksi otomatis dari header laporannya — termasuk ekspor Sales Type: Void Sales, yang masuk ke dataset yang sama dan bisa dipisah lewat filter kolom Sales Type. Payment Method & Parent Payment Method hanya ada di laporan Payment, jadi unggah keduanya supaya kolom itu terisi. Baris yang sama persis dengan yang sudah tersimpan otomatis dilewati (tidak dobel).
1
Cara menyimpan
Selalu digabung dengan data lama. Baris yang sama persis dilewati.
2
Pilih file
Unggahan langsung diproses begitu file dipilih, jadi atur langkah di atas lebih dulu.
Klik atau tarik file Sales Recapitulation / Sales Payment Recapitulation ke sini
Bisa beberapa file sekaligus (BKKR, KKVT, KKMTH, AKCL, KKST, dst.) · format .xlsx ekspor ESB
Data Tersimpan — Sales Recapitulation
Jenis
Entitas
File
Baris
Periode
Diunggah
Master Product Data — berlaku utk SEMUA entitas
Unggah file ekspor "Master Product Data" dari ESB (Product Code, Product Name, Category, Subcategory, Unit, Base Price). Satu file berlaku utk semua entitas sekaligus, sama seperti Chart of Account — katalog produk ESB-nya sama lintas cabang. Category/Subcategory di sini sama polanya dgn kolom Category/Subcategory pada Stock Opname Report (tab sebelah), dipakai fitur "%HPP Gudang Kering/Basah/Central" di Report → Profit Loss.
📂
Klik atau tarik file Excel Master Product Data ke sini
Kolom yang dibaca: Product Code, Product Name, Category, Subcategory, Unit, Base Price
Data Tersimpan — Master Product Data
Belum ada Master Product Data tersimpan.
No Price
No Price Sales Report: menu yang terjual tanpa harga, per bill. Entitas dibaca dari file; baris yang sudah tersimpan dilewati.
Sumber: ESB → Report → No Price Sales Report
Selengkapnya
Unggah file ekspor No Price Sales Report dari ESB (format .xlsx). Kolom yang dibaca: Sales Date, Sales Number, Branch, Bill Number, Menu, dan Qty. File boleh memuat banyak bulan sekaligus (ratusan ribu baris); isinya dikirim bertahap supaya tetap lancar. Baris yang sama persis dengan yang sudah tersimpan dilewati, sedangkan menu yang sama dipesan berulang di satu bill tetap tersimpan semuanya. Hasilnya tampil di menu Pendapatan → Menu No Price.
1
Cara menyimpan
Selalu digabung dengan data lama. Baris yang sama persis dilewati.
2
Pilih file
Unggahan langsung diproses begitu file dipilih. File besar membutuhkan beberapa saat untuk dibaca.
Klik atau tarik file No Price Sales Report ke sini
Bisa beberapa file sekaligus (BKKR, KKVT, KKMTH, AKCL, KKST, dst.) · format .xlsx ekspor ESB
Data Tersimpan — No Price
Entitas
File
Baris
Periode
Diunggah
Stock Opname
Untuk %HPP per Produk di Profit Loss. Disimpan ke entitas yang Anda pilih, bukan dibaca dari file.
Sumber: ESB → Stock Opname Report
Selengkapnya
Unggah ekspor Stock Opname Report dari ESB. Pilih dulu entitas tujuan di bawah — berbeda dari General Journal/GR/PO yang entitasnya dideteksi otomatis dari file, laporan ini selalu disimpan ke entitas yang Anda pilih di sini. Baris yang sama persis dengan yang sudah tersimpan otomatis dilewati (tidak dobel) — unggah ulang periode yang tumpang tindih aman, data baru digabung dengan yang lama.
1
Cara menyimpan
SELURUH baris di rentang tanggal file ini DIHAPUS dulu (milik entitas tujuan yang dipilih), baru diisi ulang dari file. Pakai ini kalau entitas tujuannya sempat salah pilih saat unggah sebelumnya (data lama numpuk, tidak otomatis terganti) atau file ini re-export ulang periode yang sama. Hanya boleh dipakai kalau file ini re-export SEMUA branch (Branch = "Multi Branches" di ESB) untuk entitas ini — kalau tersaring per branch, data branch lain di rentang itu akan hilang tanpa penggantinya. Kalau ragu, pilih Gabung.
2
Semua file di unggahan ini disimpan ke entitas ini.
3
Pilih file
Pilih entitas tujuan dulu. Unggahan langsung diproses begitu file dipilih.
Klik atau tarik file Excel Stock Opname Report ke sini
Bisa beberapa file sekaligus · format ekspor ESB dengan header laporan di baris atas · pilih entitas tujuan dulu di atas
Data Tersimpan — Stock Opname Report
Entitas
File
Baris
Periode
Diunggah
Pricelist History
Price & Pricelist History Report dengan Report Mode = Price History, untuk Anomaly Detection. Entitas dibaca dari file.
Sumber: ESB
Selengkapnya
Unggah ekspor Price & Pricelist History Report dari ESB dengan Report Mode = Price History. Entitas dideteksi otomatis dari blok meta di file (baris nama PT), sama seperti General Journal — tidak perlu pilih dropdown. Baris yang sama persis dengan yang sudah tersimpan otomatis dilewati, jadi unggah ulang periode yang tumpang tindih aman. Penting: untuk mode Antar-Entitas, tarik semua entitas dengan rentang periode yang sama — periode yang timpang menghasilkan perbandingan yang menyesatkan (halaman analisis akan memperingatkan bila terdeteksi).
1
Cara menyimpan
Selalu digabung dengan data lama. Baris yang sama persis dilewati. Untuk perbandingan antar-entitas, tarik semua entitas dengan rentang periode yang sama.
2
Pilih file
Unggahan langsung diproses begitu file dipilih, jadi atur langkah di atas lebih dulu.
Klik atau tarik file Excel Price & Pricelist History Report ke sini
Bisa beberapa file sekaligus · kolom yang dibaca: Purchase Date, Purchase Number, Supplier, Product Name, Product Code, Category, Unit, Original Price
Data Tersimpan — Pricelist History
Entitas
File
Baris
Periode
Diunggah
Materialitas
Setiap kartu menunjukkan rentang hasil yang jatuh ke Nilai 2, 1, dan 0. Pakai “Coba hitung” untuk melihat Nilai yang keluar dari suatu hasil Kertas Kerja, lalu ubah ambangnya bila perlu.
Perubahan hanya berlaku untuk Kertas Kerja yang belum diklik “Simpan Nilai”. Yang sudah tersimpan tetap memakai ambang saat itu.
Memuat…
Memuat…
Memuat…
Memuat…
Memuat…
Riwayat perubahanSemua siklus, terbaru di atas
Logo yang diunggah di sini dipakai otomatis di halaman masuk, kertas kerja, dan pilihan brand. Setiap entitas harus milik satu brand.
Brand
Entitas
Control Activities
Status
Memuat…
Target penjualan dipakai halaman Financial Highlight → Analisa Pendapatan sebagai pembanding Total Sales. Isi manual hanya target per bulan untuk tiap entitas dan tahun. Target kuartal dan target tahunan terisi otomatis dari jumlah target bulanannya: kuartal bila ketiga bulannya sudah diisi, tahunan bila ke-12 bulannya sudah diisi. Bulan yang dikosongkan berarti target bulan itu belum ada.
Target per bulan
Isi dalam rupiah penuh, tanpa titik atau koma (pemisah ribuan ditambahkan otomatis).
Target per kuartal otomatis
Jumlah target tiga bulan dalam kuartal itu. Tidak perlu diisi.
Target tahunan otomatis
Jumlah target 12 bulan dalam tahun itu. Tidak perlu diisi.
Isi realisasi pax per paket (Starter, Regular, Premium) dan target pax total per bulan; keduanya diisi manual. Kolom Total realisasi terisi otomatis dari jumlah paket, tetapi bisa juga diketik langsung (mis. bila rincian paket belum ada); kosongkan untuk kembali otomatis. Total kuartal dan tahun dihitung otomatis, begitu juga target kuartal (bila ketiga bulannya terisi) dan target tahun (bila ke-12 bulannya terisi). Dipakai halaman Financial Highlight → Analisa Pendapatan. Bulan yang dikosongkan berarti datanya belum ada.
Atur modal kasir (uang awal yang tersedia di kasir) per entitas. Nilai ini dipakai Control Activity Cash Opname Kasir (Siklus Lain-lain): uang yang seharusnya di kasir = penjualan cash + modal kasir. Entitas yang modalnya belum diatur belum bisa dinilai di Control Activity itu. Isi 0 bila kasir memang tidak memakai modal.
Centang brand yang memakai tiap Control Activity. Satu kontrol boleh dipakai beberapa brand. Kontrol yang hanya dicentang satu brand adalah kontrol khusus brand itu. Pilihan brand di halaman Control Activities hanya muncul bila minimal dua brand punya kontrol.
Mulai brand baru lebih cepat: salin semua centang Kakkoii, lalu hapus yang tidak berlaku.
Control Activity baru yang khusus satu brand tetap dibuat oleh tim pengembang, karena setiap kontrol punya cara hitung sendiri. Setelah tersedia, kontrolnya muncul di tabel ini untuk dicentang.
Log Report Persediaan — Memastikan Form SR Sistem Telah Diotorisasi
Satu section per entitas (otomatis bertambah begitu ada entitas baru), berisi dua pengaturan yang sama2 terisi otomatis dari Transaction Log Report yang sudah diunggah untuk entitas itu (tab Kertas Kerja): Pemetaan Origin/Destination Location ID (pilih nama Gudang lewat dropdown utk tiap ID yang muncul — begitu dipetakan, kolom Location ID di tabel Kertas Kerja otomatis menampilkan nama Gudang) dan Matriks Kewenangan Created By/Authorize By (centang username yang berwenang — begitu diatur, kolom Kesesuaian di tabel Kertas Kerja otomatis terisi Sudah Sesuai/Belum Sesuai, dan itulah yang menentukan Nilai).
Memuat...
Waktu Maksimal Pengambilan per Gudang — utk "Memastikan Form SR ERP Telah Diapproval Sesuai dengan Waktunya"
Berlaku GLOBAL (sama utk semua entitas, BUKAN per-entitas spt section di atas) — dipakai utk menentukan Overtime (Yes/No) otomatis per baris: Authorized Date SR dibandingkan thd waktu maksimal ini. Gudang Basah py DUA jadwal pengambilan (mis. pagi & siang) — Overtime = No kalau Authorized Date ≤ salah satu dari keduanya.
Memuat...
Log Report Pembelian — Memastikan Form PR Diotorisasi
Terpisah dari Log Report Persediaan (Memastikan Form SR) di sub-tab sebelah -- matriks kewenangan di sini KHUSUS Siklus Pembelian, TAK ADA hubungannya dgn kewenangan SR. Satu section per entitas, daftar username Created By/Authorize By terisi otomatis dari Transaction Log Report (Purchase Request) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Form PR Diotorisasi") — centang username yang berwenang, begitu diatur kolom Kesesuaian & Keterangan di tabel Kertas Kerja otomatis mengikuti, dan itulah yang menentukan Nilai.
Memuat...
Log Report Pembelian — Memastikan Form PO Diotorisasi
Terpisah dari matriks kewenangan PR di atas -- kewenangan di sini KHUSUS Purchase Order, TAK ADA hubungannya dgn kewenangan PR ataupun SR. Satu section per entitas, daftar username Created By/Authorize By terisi otomatis dari Transaction Log Report (Purchase Order) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Form PO Diotorisasi") — centang username yang berwenang, begitu diatur kolom Kesesuaian & Keterangan di tabel Kertas Kerja otomatis mengikuti, dan itulah yang menentukan Nilai.
Memuat...
Log Report Pembelian — Memastikan Form GR Diotorisasi
Terpisah dari matriks kewenangan PR/PO di atas -- kewenangan di sini KHUSUS Goods Receipt, TAK ADA hubungannya dgn kewenangan PR, PO, ataupun SR. Satu section per entitas, daftar username Created By/Authorize By terisi otomatis dari Transaction Log Report (Goods Receipt) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Form GR Diotorisasi") — centang username yang berwenang, begitu diatur kolom Kesesuaian & Keterangan di tabel Kertas Kerja otomatis mengikuti, dan itulah yang menentukan Nilai.
Memuat...
Log Report Pembelian — Memastikan Pembelian Diotorisasi dan di TTD Manager
Terpisah dari matriks kewenangan PR/PO/GR di atas -- kewenangan di sini KHUSUS Release Payment. Satu section per entitas, daftar username Released By terisi otomatis dari Transaction Log Report (Release Payment) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Pembelian Diotorisasi dan di TTD Manager") — centang username Manager yang berwenang, begitu diatur kolom Approval Sesuai/Approval Belum Sesuai di tabel Kertas Kerja otomatis mengikuti, dan itulah yang ikut menentukan Nilai.
Memuat...
Log Report Pembelian — Memastikan Uang Muka Pembelian Sesuai Kebutuhan & Diotorisasi Manager
Terpisah dari matriks kewenangan CA lain di atas -- kewenangan di sini KHUSUS Advance Purchase dan DIPAKAI BERSAMA dua CA: "Memastikan bahwa Uang Muka Pembelian untuk Kebutuhan Perusahaan" & "Memastikan uang muka pembelian yang dikeluarkan telah diotorisasi oleh manager" (satu pengaturan, tidak perlu diisi dua kali). Satu section per entitas, daftar username Authorized By terisi otomatis dari Transaction Log Report (Advance Purchase) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan bahwa Uang Muka Pembelian untuk Kebutuhan Perusahaan") — centang username Manager yang berwenang, begitu diatur kolom Authorized Sesuai/Authorized Tidak Sesuai di tabel Kertas Kerja otomatis mengikuti, dan itulah yang ikut menentukan Nilai.
Memuat...
Log Report Pembelian — Memastikan Item Journal Diapprove Hanya Dilakukan oleh Manager
Terpisah dari matriks kewenangan CA lain di atas — kewenangan di sini KHUSUS approval Item Journal. Satu section per entitas, daftar username Authorized By terisi otomatis dari Transaction Log Report (Approve Item Journal) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Item Journal Diapprove Hanya Dilakukan oleh Manager") — centang username Manager yang berwenang, begitu diatur kolom Sudah Sesuai/Belum Sesuai di tabel Kertas Kerja otomatis mengikuti, dan itulah yang ikut menentukan Nilai.
Memuat...
Log Report Biaya — Memastikan Biaya Diotorisasi dan di TTD Manager
Terpisah dari matriks kewenangan Siklus Pembelian — kewenangan di sini KHUSUS Release Payment biaya. Satu section per entitas, daftar username Released By terisi otomatis dari Transaction Log Report (Release Payment) yang sudah diunggah untuk entitas itu (tab Kertas Kerja "Memastikan Biaya Diotorisasi dan di TTD Manager" atau CA Pembelian yang setara — datanya sama) — centang username yang berwenang (Manager) lalu simpan. Approval Sesuai kalau Released By-nya tercentang di sini, Approval Belum Sesuai kalau tidak.
Memuat...
Log Report Pendapatan — Memastikan User Deposit dan Rekonsiliasi Member Deposit dengan Rekening Sesuai
Kewenangan di sini KHUSUS penginput Member Deposit. Satu section per entitas (otomatis bertambah begitu ada entitas baru); daftar username terisi OTOMATIS dari kolom User pada transaksi Deposit di file Member Deposit & Usage Report yang sudah diunggah. Baris Deposit yang diinput user yang tidak dicentang berwarna ungu di tabel Kertas Kerja.
Memuat...
Log Report Pendapatan — Memastikan Change Payment Mendapatkan Approval dari Manager
Tandai Edit By yang berwenang meng-approve change payment (Manager). Satu section per entitas (otomatis bertambah begitu ada entitas baru); daftar username terisi OTOMATIS dari kolom Edit By pada file Change Payment Report yang sudah diunggah di tab Kertas Kerja. Change payment yang Edit By-nya tidak dicentang dinilai Tidak Sesuai pada kolom Approval Manager.
Memuat...
Log Report Pendapatan — Memastikan Pembatalan Transaksi Harus Mendapatkan Approval dari Atasan
Tandai Cancel / Void By yang berwenang meng-approve pembatalan transaksi (atasan). Satu section per entitas (otomatis bertambah begitu ada entitas baru); daftar username terisi OTOMATIS dari kolom Cancel / Void By pada file Cancel Menu Detail Report yang sudah diunggah di tab Kertas Kerja. Pembatalan yang Cancel / Void By-nya tidak dicentang dinilai Tidak Sesuai pada kolom Approval Atasan.
Memuat...
Log Report Pendapatan — Memastikan Nama Customer, No Meja Bukan Fiktif (Sesuai Lay Out Resto) saat Transfer Table dan Harus Mendapatkan Approval dari Atasan
Tandai Created By yang berwenang meng-approve pindah meja (transfer table) (atasan). Satu section per entitas (otomatis bertambah begitu ada entitas baru); daftar username terisi OTOMATIS dari kolom Created By pada file Move Table Report yang sudah diunggah di tab Kertas Kerja. Pindah meja yang Created By-nya tidak dicentang dinilai Tidak Sesuai pada kolom Approval Atasan.
Memuat...
Log Report Pendapatan — Memastikan bahwa Pemakaian Voucher dan Kode Referral yang Terbit Merupakan Asli dari Perusahaan dan Pemakaiannya Sesuai dengan Aturan Perusahaan
Tandai Cashier yang berwenang meng-approve pemakaian voucher (atasan). Sales Recapitulation tidak punya kolom "edit by", jadi pihak pemroses transaksi (Cashier) yang dicocokkan. Satu section per entitas (otomatis bertambah begitu ada entitas baru); daftar username terisi OTOMATIS dari Cashier pada bill pemakai voucher di Sales Recapitulation yang sudah diunggah. Cashier yang tidak dicentang dinilai Tidak Sesuai pada kolom Approval Atasan (informasi saja, tidak mempengaruhi Nilai).
Memuat...
Belum ada Control Activity di Siklus Lain-lain yang memakai matriks kewenangan Log Report.
Kunci Approval
Atasan (Coordinator / Ast. Manager / Head) yang punya Report menunggu giliran-nya melewati tenggat di bawah tidak bisa menulis/membuka fitur lain sampai Report itu di-Approve atau diminta Revisi (alasan wajib & tercatat). Tetap terbuka: Dashboard Approval, Report yang menunggu, SOP, IM. Sebelum tenggat hanya ada banner & popup peringatan. Berlaku juga untuk Report yang sudah lama dikirim. Status Admin tidak otomatis dibebaskan — pengecualian diatur per akun di Kelola Pengguna (kolom Kunci Approval).
Tema tampilan
Sama dengan pilihan tema di sidebar. Disimpan di perangkat ini saja.
Change Password
Ganti password akun Anda sendiri. Setelah berhasil, semua sesi login (termasuk yang sedang Anda pakai sekarang) akan diputus — Anda perlu login ulang memakai password baru.
Minimal 12 karakter. Kalimat pendek yang mudah diingat lebih baik daripada satu kata dengan simbol.
Kelola Pengguna
Tambah akun auditor dan atur peran & akses per entitas. Auditor bisa mengunggah data dan mencentang checklist, tapi tidak bisa menghapus data yang sudah diunggah.
Tambah Pengguna Baru
Minimal 12 karakter. Kalimat pendek yang mudah diingat lebih baik daripada satu kata dengan simbol.
