Anda di halaman 1dari 42

KEMENTERIAN KEUANGAN REPUBLIK INDONESIA

BADAN PENDIDIKAN DAN PELATIHAN KEUANGAN

POLITEKNIK KEUANGAN NEGARA STAN

MAKALAH

PERMASALAHAN PADA MODUL BENDAHARA APLIKASI SISTEM


APLIKASI KEUANGAN TINGKAT INSTANSI

Disusun oleh:

Arief Satrio Putro 1302171249


Nanda Fadillah Daulay 1302171427
Tegar Arryaguna
6-05 1302171478
Yohannes Daniel Paserella Sihaloho 1302171497

Tangerang Selatan,
Maret 2019
DAFTAR ISI

BAB I ...................................................................................................................................................... 2
Pendahuluan .......................................................................................................................................... 2
A. Latar Belakang .......................................................................................................................... 2
B. Rumusan Masalah .................................................................................................................... 3
C. Tujuan Penulisan ...................................................................................................................... 3
D. Metodologi Penelitian ............................................................................................................... 4
E. Ruang Lingkup Pembahasan ................................................................................................... 4
BAB II .................................................................................................................................................... 5
Pembahasan ........................................................................................................................................... 5
A. Dasar Hukum ............................................................................................................................ 5
B. Landasan Teori ......................................................................................................................... 5
C. Arsitektur................................................................................................................................. 16
D. Keterkaitan dengan Modul Lain ........................................................................................... 19
E. Proses Bisnis ............................................................................................................................ 21
1. Pengusulan UP Awal........................................................................................................... 22
2. Mekanisme Pembayaran .................................................................................................... 23
3. Pengajuan GUP ................................................................................................................... 25
4. Pengajuan GUP dengan Uang Muka ................................................................................ 26
5. LS Bendahara ...................................................................................................................... 27
6. Penyampaian Laporan Pertanggungjawaban Bendahara .............................................. 27
F. Permasalahan dan Saran Perbaikan pada Modul Bendahara ........................................... 28
1. Kegiatan Pembuatan Kuitansi ........................................................................................... 28
2. Aplikasi Error pada jam-jam tertentu.............................................................................. 30
3. Kegiatan Pembuatan LPJ .................................................................................................. 31
4. Permasalahan Lainnya ....................................................................................................... 34
BAB III................................................................................................................................................. 37
Penutup ................................................................................................................................................ 37
A. Simpulan .................................................................................................................................. 37
B. Saran ........................................................................................................................................ 37
Daftar Pustaka .................................................................................................................................... 39

1
BAB I

Pendahuluan

A. Latar Belakang

Undang-Undang nomor 17 tahun 2003 tentang Keuangan Negara merupakan salah satu
bentuk reformasi nyata dalam pengelolaan keuangan negara. Undang-undang tersebut
mengamanatkan kepada pemerintah agar keuangan negara dikelola dengan tertib, taat kepada
peraturan perundangan-undangan, efisien, ekonomis, efektif, transparan, dan bertanggung
jawab dengan memperhatikan rasa keadilan dan kepatuhan.

Salah satu bentuk upaya pemerintah untuk melaksanakan amanat tersebut adalah
dengan membuat Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI) sebagai pengganti
aplikasi SAS yang dianggap masih memiliki beberapa kelemahan diantaranya pemasukan
secara berulang dan diharuskannya penyampaian berkas fisik ke kppn (belum online).
SAKTI merupakan sebuah aplikasi pengelolaan keuangan negara yang mengintegrasikan
berbagai aplikasi keuangan yang digunakan secara terpisah oleh satuan kerja (satker). Aplikasi
SAKTI terdiri dari beberapa modul yang saling terintegrasi yaitu modul pembayaran, modul
persediaan, modul bendahara, modul aset tetap, modul pelaporan, dan modul administrator.

Salah satu unsur pelaksana dan pengelola keuangan negara yang disebutkan oleh UU
no 17 tahun 2003 adalah bendahara. Bendahara merupakan setiap orang atau badan yang diberi
tugas untuk dan atas nama negara/daerah, menerima, menyimpan, dan
membayar/menyerahkan uang atau surat berharga atau barang-barang negara/daerah.
Berdasarkan Undang-Undang nomor 1 tahun 2004 tentang Perbendaharaan Negara, bendahara
terbagi dalam dua jenis yaitu Bendahara Pengeluaran dan Bendahara Penerimaan.

Saat ini bendahara yang telah menggunakan aplikasi SAKTI adalah bendahara
pengeluaran, sedangkan bendahara penerimaan masih menggunakan aplikasi yang lama yaitu
Sistem Laporan Bendahara Instansi (SILABI). Salah satu yang fasilitas yang digunakan oleh
bendahara pengeluaran dalam aplikasi SAKTI adalah Modul Bendahara. Modul Bendahara
merupakan bagian Modul Pelaksanaan Anggaran yang menitikberatkan pada proses
penatausahaan penerimaan dan pengeluaran negara di bendahara. Proses bisnis yang ada pada
Bendahara Pengeluaran yang menggunakan Modul Bendahara antara lain pengelolaan Uang

2
Persediaan (UP), Ganti Uang Persediaan (GUP), Tambahan Uang Persediaan (TUP),
Tambahan Ganti Uang Persediaan (TGUP), dan Pengelolaan Dana Titipan/ LS Bendahara.
Sedangkan proses bisnis yang ada pada Bendahara Penerimaan yang menggunaan Modul
Bendahara melingkupi pengelolaan penerimaan Pendapatan Negara Bukan Pajak (PNBP)
Umum dan penerimaan PNBP Fungsional. Output dari modul bendahara adalah laporan
pertanggungjawaban (LPJ) Bendahara.

Perkembangan aplikasi SAKTI saat ini masih dalam tahap uji coba/piloting pada satker
Kementerian Keuangan dan masih ditemukan beberapa permasalahan sehingga perlu
dilakukan perbaikan dan penyempurnaan. Dalam makalah ini, penulis akan membahas aplikasi
SAKTI khususnya tentang modul bendahara pengeluaran. Selain itu, penulis akan mencoba
menguraikan beberapa permasalahan yang ada pada Modul Bendahara, dan memberikan
pendapat untuk menyelesaikan masalah tersebut sehingga diharapkan kedepannya aplikasi
SAKTI akan berjalan semakin efektif dan efisien ketika diterapkan pada seluruh satker.

B. Rumusan Masalah

Seperti yang telah dibahas pada latar belakang penulisan, maka penulis membuat
rumusan masalah sebagai berikut:

1. Bagaimana proses bisnis yang berlangsung pada modul bendahara SAKTI?


2. Apa saja permasalahan dan dampak yang muncul dalam pengoperasian modul
bendahara SAKTI?
3. Bagaimana cara mengatasi permasalahan yang berkaitan dengan Modul Bendahara
SAKTI?

C. Tujuan Penulisan

Berdasarkan latar belakang penulisan dan rumusan masalah yang telah disampaikan
untuk makalah ini, maka dibuatlah tujuan penulisan sebagai berikut:

1. Mengetahui proses bisnis dalam pengoperasian modul bendahara SAKTI.


2. Mengetahui permasalahan dan dampak yang muncul dalam pengoperasian modul
bendahara SAKTI.
3. Mencoba memberikan solusi atas permasalahan yang berkaitan dengan modul
bendahara SAKTI.

3
D. Metodologi Penelitian

Metode pengumpulan data yang digunakan oleh Penulis dalam penyusunan makalah
tetang Modul Bendahara antara lain:

1. Studi Kepustakaan
2. Dalam metode ini penulis mencari sumber referensi dari berbagai artikel, buku
panduan, serta peraturan perundang-undangan yang memiliki keterkaitan dengan
aplikasi SAKTI khususnya modul bendahara. Metode ini digunakan sebagai acuan
dalam mengetahui proses bisnis dan permasalahan.
3. Observasi Lapangan
4. Dengan metode ini, Penulis melakukan observasi secara langsung ke Kantor Bea Cukai
Soekarno Hatta. Observasi lapangan dilakukan agar Penulis dapat mengetahui langsung
wujud dan arsitektur aplikasi SAKTI, serta cara pengoperasiannya.
5. Wawancara
6. Penulis melakukan wawancara baik secara langsung ataupun tidak langsung dengan
Bendahara di beberapa instansi seperti KPU BC Tipe C Soekarno Hatta, KPPBC TMP
C Teluk Nibung, KPP Pratama Kabanjahe dan Kanwil DJKN Papua, Papua Barat, dan
Maluku. Metode ini dilakukan untuk mendapatkan informasi yang diperlukan, sehingga
mendukung pembuatan makalah modul bendahara ini.

E. Ruang Lingkup Pembahasan

Sebagaimana disebutkan dalam latar belakang, saat ini bendahara yang menggunakan
Modul Bendahara pada aplikasi adalah Bendahara Pengeluaran, sedangkan Bendahara
Penerimaan masih menggunakan aplikasi SILABI. Maka dari itu, ruang lingkup pembahasan
penulis pada makalah ini hanya sebatas pada Modul Bendahara yang digunakan oleh
Bendahara Pengeluaran. Adapun Bendahara yang dimaksud dalam makalah ini adalah
Bendahara Pengeluaran.

4
BAB II

Pembahasan

A. Dasar Hukum

1. Undang-Undang Nomor 17 Tahun 2003 tentang Keuangan Negara


2. Undang-Undang Nomor 1 Tahun 2004 tentang Perbendaharaan Negara
3. Peraturan Menteri Keuangan Nomor 162/PMK.05/2013 jo. PMK Nomor
230/PMK.05/2016 tentang Kedudukan dan Tanggung Jawab Bendahara Pada Satuan
Kerja Pengelola APBN
4. Peraturan Menteri Keuangan nomor 190/PMK.05/2012 tentang Tata Cara Pembayaran
dalam rangk Pelaksanaan Anggaran Pendapatan dan Belanja Negara;
5. Peraturan Menteri Keuangan Nomor 159/PMK.05/2018 tentang Pelaksanaan Piloting
Sistem Aplikasi Keuangan Tingkat Instansi;
6. Peraturan Pemerintah nomor 60 tahun 2008 tentang Sistem Pengendalian Intern
Pemerintah;
7. Permendagri No. 13 tahun 2006 tentang Pedoman Pengelolaan Keuangan Daerah

B. Landasan Teori

1. Pengendalian Internal terkait dengan Aplikasi pada Instansi Pemerintah

Peraturan Pemerintah nomor 60 tahun 2008 tentang Sistem Pengendalian Intern


Pemerintah mendefinisikan Sistem Pengendalian Intern (SPI) sebagai proses yang integral
pada tindakan dan kegiatan yang dilakukan secara terus menerus oleh pimpinan dan seluruh
pegawai untuk memberikan keyakinan memadai atas tercapainya tujuan organisasi melalui
kegiatan yang efektif dan efisien, keandalan pelaporan keuangan, pengamanan aset negara, dan
ketaataan terhadap peraturan perundang-undangan. Sistem Pengendalian Internal yang
diterapkan pada Pemerintahan disebut dengan Sistem Pengendalian Internal Pemerintah
(SPIP).
Peraturan Pemerintah nomor 60 tahun 2008 membagi SPIP menjadi beberapa unsur,
diantaranya:
a. Lingkungan Pengendalian

5
Setiap pimpinan instansi pemerintah wajib menciptakan dan memelihara
lingkungan pengendalian yang menimbulkan perilaku positif dan kondusif untuk
penerapan SPI dalam lingkungan kerjanya.
b. Penilaian Risiko
Setiap Pimpinan Instansi Pemerintah wajib melakukan penilaian risiko.
c. Kegiatan Pengendalian
Setiap pimpinan Instansi Pemerintah wajib menyelenggarakan kegiatan
pengendalian sesuai dengan ukuran, kompleksitas, serta sifat dari tugas dan fungsi
Instansi Pemerintah yang bersangkutan.
d. Informasi dan Komunikasi
Setiap pimpinan instansi pemerintah wajib mengidentifikasi, mencatat, dan
mengkomunikasikan informasi dalam bentuk dan waktu yang tepat.
e. Pemantauan Pengendalian Intern
Setiap Pimpinan Instansi Pemerintah wajib melakukan pemantauan Sistem
Pengendalian Intern.

James A. Hall dalam bukunya yang berjudul Sistem Informasi Akuntansi (2007, 496)
mengatakan bahwa salah satu jenis pengendalian yang dapat diterapkan pada Sistem Informasi
Berbasis Komputer adalah pengendalian input berupa pengendalian validasi (validation
control) yang merupakan bagian dari pengendalian aplikasi. Pengendalian validasi bertujuan
untuk memeriksa akurasi data dan mendeteksi kesalahan dalam data sebelum data tersebut
diproses. Beberapa pemeriksaan yang dapat dilakukan sistem informasi dalam rangka
pengendalian validasi adalah sebagai berikut:
a. Pemeriksaan Batas (limit check), di mana sistem akan melakukan interogasi field
apabila nilai dalam field melampaui batasan yang telah ditetapkan.
b. Perbaikan Segera, yaitu ketika sistem informasi mendeteksi adanya kesalahan
keystroke dan relasi yang tidak logis, sistem mampu mengehentikan prosedur entri
data sampai kesalahan tersebut diperbaiki oleh user.
Selain itu pasal 29 Peraturan Pemerintah nomor 60 tahun 2008 menyebutkan bahwa
pengendalian aplikasi terdiri atas pengendalian otorisasi, pengendalian kelengkapan,
pengendalian akurasi, dan pengendalian terhadap pemrosesan dan file data. Lebih lanjut pasal
32 menyebutkan bahwa pengendalian akurasi terdiri dari beberapa aktivitas pengendalian
diantaranya:
a. Penggunaan desain entri data untuk mendukung akurasi data;

6
b. Pelaksanaan validasi data untuk mengidentifikasi data yang salah;
c. Pencatatan, pelaporan, investigasi, dan perbaikan data yang salah dengan seger;
d. Reviu atas laporan keluaran untuk mempertahankan akurasi dan validitas data.
2. Standard Operating Procedures

Menurut Peraturan Menteri Negara Pendayagunaan Aparatur Negara Nomor


PER/21/M.PAN/11/2008 tentang Pedoman Penyusunan Standar Operasional Prosedur (SOP)
Administrasi Pemerintahan, Standard Operating Procedures (SOP) adalah serangkaian
instruksi tertulis yang dibakukan mengenai berbagai proses penyelenggaraan administrasi
pemerintahan, bagaimana dan kapan harus dilakukan, di mana dan oleh siapa dilakukan.
Sedangkan Laksmi (2008, 52) mendefinisikan Standar Operasional Prosedur (SOP) adalah
dokumen yang berkaitan dengan prosedur yang dilakukan secara kronologis untuk
menyelesaikan suatu pekerjaan yang bertujuan untuk memperoleh hasil kerja yang paling
efektif dari para pekerja dengan biaya yang serendah-rendahnya. SOP biasanya terdiri dari
manfaat, kapan dibuat atau direvisi, metode penulisan prosedur, serta dilengkapi oleh bagan
flowchart di bagian akhir.

Indah Puji (2014, 30) dalam bukunya menguraikan tujuan SOP adalah sebagai berikut:

a. Untuk menjaga konsistensi tingkat penampilan kinerja atau kondisi tertentu dan
kemana petugas dan lingkungan dalam melaksanakan sesuatu tugas atau pekerjaan
tertentu.
b. Sebagai acuan dalam pelaksanaan kegiatan tertentu bagi sesama pekerja, dan
supervisor.
c. Untuk menghindari kegagalan atau kesalahan (dengan demikian menghindari dan
mengurangi konflik), keraguan, duplikasi serta pemborosan dalam proses
pelaksanaan kegiatan.
d. Merupakan parameter untuk menilai mutu pelayanan.
e. Untuk lebih menjamin penggunaan tenaga dan sumber daya secara efisien dan
efektif.
f. Untuk menjelaskan alur tugas, wewenang dan tanggung jawab dari petugas yang
terkait.
g. Sebagai dokumen yang akan menjelaskan dan menilai pelaksanaan proses kerja
bila terjadi suatu kesalahan atau dugaan mal praktek dan kesalahan administratif
lainnya, sehingga sifatnya melindungi rumah sakit dan petugas.

7
h. Sebagai dokumen yang digunakan untuk pelatihan.
i. Sebagai dokumen sejarah bila telah dibuat revisi SOP yang baru.

Dalam buku yang sama, Indah Puji (2014, 35) menyatakan fungsi dari SOP adalah sebagai
berikut:

a. Memperlancar tugas petugas/pegawai atau tim/unit kerja.


b. Sebagai dasar hukum bila terjadi penyimpangan.
c. Mengetahui dengan jelas hambatan-hambatannya dan mudah dilacak.
d. Mengarahkan petugas/pegawai untuk sama-sama disiplin dalam bekerja.
e. Sebagai pedoman dalam melaksanakan pekerjaan rutin.

Sesuai Peraturan MENPAN nomor 21 tahun 2008, pelaksanaan SOP harus memenuhi
prinsip-prinsip sebagai berikut:

a. Konsisten. SOP harus dilaksanakan secara konsisten dari waktu ke waktu, oleh
siapapun, dan dalam kondisi apapun oleh seluruh jajaran organisasi pemerintahan.
b. Komitmen. SOP harus dilaksanakan dengan komitmen penuh dari seluruh jajaran
organisasi, dari level yang paling rendah dan tertinggi.
c. Perbaikan berkelanjutan. Pelaksanaan SOP harus terbuka terhadap
penyempurnaan-penyempurnaan untuk memperoleh prosedur yang benar-benar
efisien dan efektif.
d. Mengikat. SOP harus mengikat pelaksana dalam melaksanakan tugasnya sesuai
dengan prosedur standar yang telah ditetapkan.
e. Seluruh unsur memiliki peran penting. Seluruh pegawai peran-peran tertentu dalam
setiap prosedur yang distandarkan. Jika pegawai tertentu tidak melaksanakan
perannya dengan baik, maka akan mengganggu keseluruhan proses, yang akhirnya
juga berdampak pada proses penyelenggaraan pemerintahan.
f. Terdokumentasi dengan baik. Seluruh prosedur yang telah distandarkan harus
didokumentasikan dengan baik, sehingga dapat selalu dijadikan referensi bagi
setiap mereka yang memerlukan.
3. Pengembangan Sistem Informasi

Menurut Romney dan Steinbart dalam bukunya yang berjudul Accounting Information
Systems (2015, 589) mengatakan bahwa kebanyakan organisasi di dunia menyempurnakan dan
mengganti sistem informasi mereka karena mereka menyadari bahwa mereka hidup di dunia

8
yang sangat kompetitif dan selalu berubah. Beberapa alasan mengapa dilakukan
pengembangan sistem informasi, diantaranya:

a. Perubahan Kebutuhan User dan Bisnis


Untuk menjaga perusahaan agar tetap responsif walaupun adanya kompetisi antar
organisasi yang semakin meningkat, perkembangan bisnis dan merger, rencana
pengecilan operasi, dan adanya perubahan peraturan yang mengubah tujuan dan
struktur perusahaan.
b. Perubahan Teknologi
Adanya perkembangan teknologi yang dapat menekan biaya menjadi lebih murah.
c. Penyempurnaan Proses Bisnis
Untuk mengidentifikasi dan memperbaiki proses bisnis yang tidak efisien.
d. Keunggulan Kompetitif
Meningkatkan kecepatan, kualitas, dan kuantitas informasi yang diperoleh dalam
rangka meningkatkan pelayanan.
e. Keuntungan Produktifitas
Mengurangi waktu pekerjaan dan memberikan pegawai ilmu pengetahuan
khusus.
f. Sistem Integrasi
Menggabungkan sistem agar menggunakan satu database untuk mengatasi
masalah sistem yang tidak kompatibel.
g. Sistem yang ada sudah usang
Organisasi membutuhkan sistem yang lebih canggih untuk mengikuti
perkembangan bisnis saat ini.

Selain itu dalam buku sama, Romney dan Steintbart (2015, 591-592) menjelaskan
tahapan-tahapan dalam pengembangan sistem yang dikenal dengan System Development Life
Cycle, (SDLC) yang terdiri dari:

a. System Analysis
Tahapan ini merupakan tahap pertama di mana informasi yang diperlukan terkait
dengan pembelian, pengembangan, dan modifikasi sistem dikumpulkan. Dalam
tahapan ini dilakukan identifikasi kelemahan dan kekuatan sistem yang ada saat ini
serta dilakukan uji kelayakan terhadap rencana pengembangan sistem. Jika
berdasarkan uji kelayakan dinyatakan bahwa sistem layak, akan dilakukan

9
identifikasi dan dokumentasi kebutuhan informasi oleh user dan manajer
organisasi. Hasil identifikasi dan dokumentasi ini selanjutnya akan digunakan
untuk menyusun dan mengembangkan persyaratan sistem sebagai dasar
pengambilan keputusan dalam pemilihan metode pengembangan sistem.
b. Conceptual Design
Tahap ini merupakan tahapan kedua dalam SDLC, di mana pada tahap ini
organisasi memutuskan bagaimana cara untuk memenuhi kebutuhan user. Dalam
tahap ini organisasi melakukan pemilihan metode pengembangan sistem apakah
membeli software, membangun software sendiri, atau outsourcing pengembangan
sistem kepada pihak ketiga. Dasar dalam pemilihan adalah hasil identifikasi dan
dokumentasi kebutuhan informasi oleh user pada tahapan system analysis
sebelumnya.
c. Physical Design
Tahap ini merupakan tahap ketiga dalam SDLC. Conceptual design yang
dihasilkan pada tahap kedua dikembangkan menjadi physical design. Conceptual
design ini diterjemahkan kedalam spefisikasi terinci yang akan digunakan untuk
melakukan coding dan test program, mendesign input dan output, membuat file dan
database, mengembangkan prosedur, dan membangun kontrol ke dalam sistem
baru.
d. Implementation and Conversion
Tahap ini merupakan tahapan pengujian sistem informasi di mana perangkat keras
dan perangkat lunak baru dipasang dan diuji, adanya pelatihan dan pemindahan
pegawai jika diperlukan, dan prosedur pemrosesan informasi diuji dan
dimodifikasi. Pada tahap ini tejadi proses peralihan dari sistem yang lama menjadi
sistem yang baru serta dilakukan peninjauan pasca implementasi untuk mendeteksi
dan memperbaiki kekurangan desain.
e. Operations and Maintenance
Tahap ini merupakan tahapan yang terakhir dalam SDLC. Tahap ini merupakan
tahap di mana sistem informasi telah digunakan secara rutin dan direview secara
berkala. Review dilakukan untuk menemukan masalah dalam pemakaian sistem
informasi dan dilakukan modifikasi untuk mengatasi masalah tersebut, jika
ditemukan bahwa masalah pada sistem informasi cukup signifikan dan
membutuhkan pengembangan baru, maka siklus SDLC akan kembali dari tahap
awal. Pada dasarnya SDLC merupakan siklus yang berkelanjutan, hal ini

10
dikarenakan bahwa lingkungan global yang sangat kompetitif dan perubahan selalu
terjadi termasuk juga pada sistem informasi.

(Sumber: Romney dan Steintbart: 2015,591)


4. Sistem Database

Dalam mengintegrasikan suatu sistem, Sistem Database merupakan unsur penting agar
sistem tersebut dapat saling terhubung dengan baik karena saat ini hampir semua mainframe
dan server menggunakan teknologi database. Dalam database, terdapat 2 (dua) hal yang
penting, yaitu Data dan Sistem Manajemen Database.

Romney dan Steinbart (2014,39) dalam buku Accounting Information Systems


mendefinisikan database sebagai “seperangkat koordinasi beberapa file data terpusat yang
saling berhubungan yang disimpan dengan sedikit mungkin kelebihan data.”

Dengan menggunakan database di dalam sistem, organisasi maka organisasi


mendapatkan keuntungan-keuntungan sebagai berikut:

a. Integrasi Data
b. Pembagian data
c. Meminimalkan kelebihan dan inkosistensi data
d. Independensi data
e. Analisis lintas fungsional
Untuk menjadi database yang baik diperlukan data yang benar sehingga tidak
mengarahkan pengguna database mengambil keputusan yang buruk dan tidak membuat
pengguna sistem ataupun aplikasi kebingungan.

11
Hal kedua yang penting dalam sistem database adalah sistem manajemen database.
Sistem Manajemen Database merupakan “program yang mengelola dan mengendalikan data
serta menghubungkan data dan program-program aplikasi yang menggunakan data yang
disimpan dalam database”. (Romney dan Steinbart, 2014, 100) Sistem Manajemen Database
inilah yang menerjemahkan database dan menghubungkan data-data sehingga dapat digunakan
oleh pengguna sistem.

Dalam pengelolaan Sistem Database terdapat 3 masalah yang dapat terjadi:

a. Anomali Pembaruan
Mengelola database secara tidak benar di mana item kunci non-utama disimpan
beberapa kali; memperbarui komponen dalam satu lokasi sedangkan lokasi lain
tidak diperbarui akan menyebabkan inkonsistensi data.
b. Anomali Sisipan
Mengelola database secara tidak benar yang menyebabkan ketidakmampuan untuk
menambah catatan pada database.
c. Anomali Penghapusan
Mengelola database secara tidak benar yang menyebabkan hilangnya seluruh data
pada suatu entitas ketika sebuah baris dihapus.

Jika Database dapat dikelola dan disajikan dengan Sistem Manajemen Database yang
benar, maka sistem database akan terintegrasi dengan baik.

5. ERP

Sehubungan mengenai enterprise resource planning Romney dan Steinbart (2015, 41)
menyatakan bahwa:

Sistem enterprise resource planning (ERP system) merupakan suatu sistem yang
mengintegrasikan semua aspek aktivitas organisasi seperti akuntansi, keuangan, pemasaran,
sumber daya manusia, manufaktur, manajemen persediaan ke dalam satu sistem. ERP
memfasilitasi arus informasi antara berbagai fungsi bisnis perusahaan dan mengelola
komunikasi dengan para pemangku kepentingan di luar.

Selain itu, Romney dan Steinbart (2015, 42-43) menyatakan bahwa:

Sistem ERP bersifat modular, dengan setiap modul menggunakan praktik bisnis terbaik untuk
mengotomatisasi proses bisnis standar. Desain modular ini memungkinkan bisnis untuk

12
menambah atau menghapus modul yang diperlukan. Sistem ERP dengan database terpusat,
memberikan keuntungan yang signifikan sebagai berikut:

a. ERP memberikan tampilan tunggal atas data organisasi dan situasi keuangan yang
terintegrasi.
b. Input data diambil atau dikunci sekali, dan tidak berkali-kali, saat dimasukkan ke
dalam sistem yang berbeda. Mengunduh data dari satu sistem ke yang lain tidak
diperlukan.
c. Manajemen mendapatkan visibilitas yang lebih besar ke dalam setiap area
organisasi dan kemampuan memonitor yang lebih besar.
d. Organisasi memperoleh pengendalian akses yang baik. ERP dapat
mengonsolidasikan berbagai perizinan dan model keamanan ke dalam struktur
akses data tunggal.
e. Prosedur dan laporan yang telah distandardisasi antarunit bisnis.
f. Pelayanan meningkat karena pegawai dapat dengan cepat mengakses data,
mengirimkan informasi dan detail transaksi.

Sistem ERP juga memiliki kerugian yang signifikan sebagai berikut:

a. Biaya. Perangkat keras, perangkat lunak ERP, dan biaya konsultasi berbiaya cukup
mahal.
b. Jumlah waktu yang diminta. Hal ini dapat menghabiskan beberapa tahun untuk
memilih dan mengimplementasikan sistem ERP secara penuh.
c. Perubahan proses bisnis. Kecuali organisasi ingin menghabiskan waktu dan uang
untuk menyesuaikan modul, mereka harus beradaptasi untuk menstandardisasi
proses bisnis sebagai lawan dalam mengadopsi paket ERP untuk proses organisasi
yang ada.
d. Kompleksitas. Hal ini berasal dari integrasi berbagai aktivitas dan sistem bisnis
yang berbeda, karena masing-masing memiliki proses, aturan bisnis, semantik data,
hierarki otorisasi, dan pusat keputusan yang berbeda.
e. Resistansi. Pengoperasian ERP memerlukan pelatihan dan pengalaman yang dapat
dipertimbangkan untuk menggunakan sistem ERP secara efektif. Tidak mudah
untuk meyakinkan pegawai agar mengubah cara mereka melakukan pekerjaan,
melatihnya dalam prosedur baru, menguasai sistem baru, dan meyakinkan mereka
untuk membagi informasi sensitif.

13
Romney dan Steinbart (2015, 45) juga menambahkan “Pentingnya pengendalian
internal dalam ERP tidak dapat dinyatakan secara berlebihan ... oleh karena itu, pengendalian
entri data dan pengendalian akses menjadi hal yang penting. Sebagian pegawai hanya melihat
dan memiliki akses untuk sebagian porsi dari sistem. Pemisahan tugas ini memberikan
pengendalian internal. Penting untuk memisahkan pertanggungjawaban penyimpanan aset,
otorisasi aktivitas yang memengaruhi aset tersebut, mencatat informasi mengenai aktivitas dan
status aset organisasi.”

6. Efisiensi dan Efektivitas

Sesuai dengan Permendagri No. 13 tahun 2006, efisiensi merupakan ukuran dalam
penggunaan barang dan jasa oleh organisasi perangkat pemerintah untuk mencapai tujuan
organisasi dan mencapai manfaat tertentu. Indah Susantun (2000) menyatakan bahwa
pengertian efisiensi adalah perbandingan output dengan input berhubungan dengan tercapainya
output maksimum dengan sejumlah input, artinya apabila rasio output/input besar maka
efisiensi dikatakan tinggi. Efisiensi juga sering dikaitkan dengan kinerja suatu organisasi
karena efisiensi mencerminkan perbandingan antara keluaran (output) dengan masukan (input)
(Ritaudin, 2015). Ada tiga faktor yang menyebabkan efisiensi, yaitu 1) apabila dengan input
yang sama dapat menghasilkan output yang lebih besar, 2) dengan input yang kecil dapat
menghasilkan output yang sama, 3) dengan input yang lebih besar dapat menghasilkan output
yang lebih besar lagi (Suswadi, 2007). Input merupakan segala sesuatu yang diperlukan agar
pelaksanaan suatu rencana atau kegiatan dapat berjalan untuk memperoleh output. Sedangkan
output merupakan segala sesuatu yang diperoleh atau dicapai dari suatu kegiatan.

Efisiensi dalam organisasi terdiri dari dua komponen, yaitu efisiensi teknis dan efisiensi
alokatif. Efisiensi teknis menggambarkan kemampuan dari organisasi dalam menghasilkan
output dengan sejumlah input yang tersedia. Adapun efisiensi alokatif menggambarkan
kemampuan organisasi dalam mengoptimalkan penggunaan input-nya, dengan struktur harga
dan teknologi produksinya. Kedua ukuran ini yang kemudian dikombinasikan menjadi efisiensi
ekonomi (economic efficeincy). Suatu organisasi dapat dikatakan efisien secara ekonomi jika
perusahaan tersebut dapat meminimalkan biaya produksi untuk mengahsilkan output tertentu
dengan suatu tingkat teknologi serta harga pasar yang berlaku (Farrel dalam Ascarya dan
Yumanita, 2006).

Menurut Kamus Besar Bahasa Indonesia (KBBI) definisi efektivitas adalah sesuatu
yang memiliki pengaruh atau akibat yang ditimbulkan, manjur, membawa hasil dan merupakan

14
keberhasilan dari suatu usaha atau tindakan, dalam hal ini efektivitas dapat dilihat dari tercapai
tidaknya tujuan instruksional khusus yang telah dicanangkan. Menurut Emerson dalam
Handayaningrat (2006:16), efektivitas adalah “pengukuran dalam tercapainya sasaran atau
tujuan yang telah ditentukan sebelumnya”. Jadi dapat dikatakan bahwa efektivitas merupakan
acuan untuk menentukan apakah sasaran suatu kegiatan sudah tercapai atau belum.

Lubis dan Husseini (1987:55) menyebutkan ada 3 (tiga) pendekatan utama dalam
pengukuran efektivitas, yaitu:

a. Pendekatan sumber (resource approach)

Pendekatan sumber mengukur efektivitas dari input. Pendekatan mengutamakan


adanya keberhasilan organisasi untuk memperoleh sumber daya, baik fisik maupun non
fisik yang sesuai dengan kebutuhan organisasi.

b. Pendekatan proses (process approach)

Pendekatan proses adalah untuk melihat sejauh mana efektivitas pelaksanaan program
dari semua kegiatan orises internal atau mekanisme organisasi.

c. Pendekatan sasaran (goals approach)

Di mana pusat perhatian pada output, mengukur keberhasilan untuk mencapai hasil
sesuai dengan rencana.

Selain itu menurut Campbell dalam Strees (1985:46) pengukuran efektivitas secara
umum dan yang paling menonjol adalah keberhasilan program, keberhasilan sasaran, kepuasan
terhadap program, tingkat input dan output, dan pencapaian tujuan menyeluruh. Efektivitas
sebuah organisasi dapat dipengaruhi oleh beberapa faktor diantaranya yaitu karakteristik
organisasi, karakteristik lingkungan intern dan ekstern, karakteristik karyawan dan kebijakan
praktik manajemen (Sutrisno, 2011: 125).

Sehingga efisiensi dan efektivitas menjadi dua objek yang tidak bisa dipisahkan dalam
menentukan keberhasilan sebuah organisasi. Sebuah organisasi tidak dapat dikatakan berhasil
apabila melakukan suatu kegiatan dengan efisien namun tidak memperoleh outcome yang
efektif, begitu juga sebaliknya.

15
C. Arsitektur

Modul Bendahara merupakan salah satu modul pelaksanaan anggaran pada aplikasi
SAKTI yang berfungsi sebagai alat bantu bendahara untuk penatausahaan penerimaan dan
pengeluaran negara melalui bendahara. Setiap user yang ingin mengakses aplikasi SAKTI
harus terkoneksi dengan jaringan intranet Kementerian Keuangan. Pada umumnya transaksi
yang terkait dengan modul bendahara secara otomatis akan diteruskan ke modul pembayaran
untuk diproses lanjut menjadi ADK SPP hingga menjadi ADK SPM. Setelah melewati proses
pada modul pembayaran, ADK SPM yang tersimpan pada database aplikasi SAKTI
selanjutnya akan ditransfer ke SPAN untuk diproses menjadi SP2D. Portal SPAN dan SMS
Gateway merupakan jembatan komunikasi yang dirancang untuk mendukung interaksi antara
satker dengan KPPN. Satker menggunakan Portal SPAN atau SMS Gateway untuk
memperoleh informasi dari SPAN.

Sumber : Slide End User Training SAKTI

Aplikasi SAKTI memang memiliki keunggulan dibandingkan dengan aplikasi


sebelumnya karena memiliki single database dan akses online yang mengintegrasikan
beberapa modul pelaksanaan anggaran seperti modul penganggaran, modul komitmen, modul

16
pembayaran, modul persediaan, modul aset tetap, modul piutang, serta modul akuntansi dan
pelaporan. Adapun beberapa kemudahan yang diberikan aplikasi SAKTI adalah pemasukan
data yang hanya cukup sekali, dapat diakses kapanpun dan di manapun, mendukung penerapan
check dan balance dalam pelaksanaan anggaran, serta penyampaian dokumen melalui jaringan
online. Selain itu, akses terhadap modul-modul di aplikasi SAKTI hanya dapat diberikan
kepada user sesuai dengan wewenang dan tanggung jawab nya. Beberapa sub modul yang ada
pada aplikasi SAKTI khususnya modul bendahara dapat dilihat pada gambar di bawah ini:

Sumber : Aplikasi SAKTI

1. Submodul Membuat Usulan

Merupakan submodul yang digunakan bendahara untuk mengajukan usulan UP


awal dan mengajukan GUP. Beberapa menu yang dipakai secara rutin adalah
menghitung Usul UP dalam rangka pengajuan UP awal dan membuat DRPP dalam
rangka mengajukan GUP.

17
2. Submodul Transaksi

Merupakan submodul yang biasanya berkaitan dengan transaksi pembayaran


oleh bendahara. Sub modul ini terdiri beberapa yang menu yaitu Merekam Uang Muka,
Membuat Kuitansi, Mencatat Pungutan Pajak, Mencatat Pembayaran Data Titipan,
Mencatat Uang Masuk Bendahara Pengeluaran, Input FA Detail Penerimaan Kas dan
Membuat Kuitansi Hibah.

3. Submodul Setoran

Merupakan submodul yang umumnya berkaitan dengan transaksi penyetoran


dana oleh bendahara seperti setoran pajak, setoran UP/TUP/TUP dan setoran
pengembalian belanja.

4. Submodul Approval Transaksi

Merupakan submodul yang umumnya terkait dengan transaksi pemindahan kas


bendahara baik itu saldo kas bank ataupun kas tunai.

5. Submodul Cetak Laporan

Merupakan submodul yang berkaitan dengan laporan pertanggungjawaban


bendahara setiap bulannya. Ikhtisar dari sekumpulan transaksi dan aktivitas bendahara
selama sebulan dapat diperoleh melalui submodul ini. Berbagai laporan yang dapat
diperoleh dari submodul ini adalah Buku Kas Umum Bendahara Pengeluaran, Buku
Kas Bank, Buku Kas Tunai, dan Buku Pembantu UP/TUP/Pajak.

6. Submodul Monitoring

Merupakan submodul yang membantu bendahara untuk memonitoring


UP/TUP/UPKP, Uang Muka, dan Dana Titipan.

7. Submodul Upload

Merupakan submodul yang digunakan untuk melakukan upload Data


Penerimaan Satker.

8. Submodul Referensi

Merupakan submodul yang berisi data-data yang terkait dengan aktivitas


bendahara pengeluaran seperti Referensi kelompok Akun UP, Referensi Wajib
Pajak/Wajb Bayar, Referensi Variable UP, Referensi Detail Rekening. Data-data yang
18
telah terekam di sini merupakan data-data yang telah di-input sebelumnya baik itu
melalui modul bendahara ataupun melalui modul lainnya, sebagai contoh refrensi data
wajib pajak/bayar merupakan data yang telah di-input sebelumnya melalui modul
komitment.

Perlu diketahui bahwa seluruh submodul yang ada di atas hanya dapat diakses
oleh bendahara, dan oleh karena itu dalam mengakses modul bendahara tidak ada istilah
validator dan approver.

D. Keterkaitan dengan Modul Lain

(Sumber: Slide EUT Aplikasi SAKTI)

1. Modul Pembayaran

Keterkaitan antara modul bendahara dengan modul pembayaran terjadi pada


proses bisnis yang terkait dengan UP/TUP dan GUP/GTUP. Setelah modul bendahara
menghitung usul UP/ rincian TUP, maka operator akan membuat SPP, SPM, dan
mencatat SP2D melalui modul pembayaran. Kemudian nomor SP2D UP/ TUP yang
telah diproses oleh modul pembayaran dicatat ke dalam buku kas bank modul
bendahara.

19
Dalam pengajuan GUP/ GTUP tanpa uang muka, modul bendahara akan
mencatat SPBy, membuat kuitansi, mencatat pungutan pajak, membuat setoran pajak
dan SPTB. Berdasarkan kuitansi yang telah diterbikan sebelumnya, bendahara
menyusun DRPP. Berdasarkan DRPP modul pembayaran akan membuat SPP, SPM,
dan mencatat SP2D. Kemudian, nomor SP2D UP/ TUP yang telah diproses oleh
modul pembayaran dicatat ke dalam buku kas bank modul bendahara.

Begitu juga dengan pengelolaan LS Bendahara. Pertama, modul pembayaran


akan membuat SPP, SPM, dan mencatat SP2D. Kemudian, modul bendahara akan
melakukan pemindahan kas bendahara pengeluaran, mencatat pembayaran dana
titipan, dan menyetor pengembalian belanja.

2. Modul Aset Tetap

Keterkaitan antara Modul Bendahara dan Aset Tetap terjadi pada saat
pembelian aset tetap dengan menggunakan UP. Modul Aset tetap melaksanakan
pembukuan data detail BMN yang diperoleh melalui proses pembelian baik yang
berasal dari modul komitmen (BAST) ataupun yang berasal dari modul bendahara.

3. Modul Persediaan

Keterkaitan antara modul bendahara dan modul persediaan terjadi ketika


transaksi yang menggunakan UP menghasilkan persediaan. Setelah dilakukan analisa
transaksi pembelian dari modul bendahara, maka persediaan tersebut harus dicatat di
modul persediaan melalui menu referensi.

4. Modul General Ledger dan Pelaporan

Bendahara mengakui jurnal General Ledger aplikasi SAKTI pada saat membuat
kuitansi, mencatat pungutan pajak, mencatat NTPN setoran pajak/setoran PNBP
umum/pengembalian sisa UP/pengembalian sisa TUP/setoran pengembalian belanja,
pemindahan kas untuk SP2D LS bendahara, dan menyimpan pembayaran dana titipan/
pengembalian sisa dana titipan.

5. Modul Administrasi

Keterkaitan antara modul bendahara dan modul administrasi terjadi karena data-
data user modul bendahara dan data referensi pada modul bendahara dikelola oleh
modul administrasi.

20
6. Modul Penganggaran
Keterkaitan antara modul bendahara dan modul penganggaran dalam hal realisasi
belanja yang dilakukan dengan menggunakan UP. Realisasi belanja dengan menggunakan
UP secara otomatis aka memperbaharui sisa saldo masing-masing akun anggaran pada
DIPA satker.

E. Proses Bisnis

Secara garis besar, alur data yang terjadi pada proses bisnis yang berhubungan dengan
penggunaan modul bendahara dapat dilihat pada gambar di bawah ini:

Sumber: Diolah Sendiri

21
Beberapa kegiatan dalam proses bisnis ini adalah sebagai berikut:

1. Pengusulan UP Awal

Ket: Kegiatan dilakukan dengan Modul Bendahara


Kegiatan dilakukan dengan Modul Pembayaran
Kegiatan dilakukan tidak menggunakan Modul Bendahara dan Modul Pembayaran

Sumber: Diolah sendiri

Berdasarkan keterangan bendahara pengeluaran KPPBC TMP C Teluk Nibung,


proses bisnis yang terkait dengan pengusulan UP terdiri dari beberapa tahapan kegiatan
sebagai berikut:

a. Tahapan kegiatan pertama dalam proses bisnis pengusulan UP adalah membuat


usulan UP. Bendahara pengeluaran memasukkan hitungan usulan UP dan
nomor DIPA pada menu membuat usulan  menghitung usulan UP. Kemudian
langkah selanjutnya
b. Tahapan kegiatan selanjutnya masuk ke dalam ruang lingkup modul
Pembayaran. Pada modul Pembayaran operator membuat SPP lalu diajukan
kepada PPK untuk dilakukan validasi. Setelah proses validasi selesai kemudian
PPK menyampaikan ADK SPP kepada operator
c. Setelah operator menerima ADK SPP, kemudian membuat SPM pada modul
pembayaran. SPM yang sudah dibuat kemudian diajukan kepada PPSPM untuk
dilakukan persetujuan (approval). Apabila PPSPM menyetujui SPM yang telah

22
dibuat sebelumnya, maka PPSPM menyampaikan ADK SPM kepada operator
untuk dikirim ke database SAKTI untuk diproses oleh KPPN.
d. Berdasarkan pengajuan ADK SPM yang dikirimkan ke database SAKTI, KPPN
akan memprosesan menerbitkan dokumen SP2D. Nomor dokumen SP2D yang
telah diterbitkan oleh KPPN dapat dilihat pada aplikasi SPAN atau pada modul
Pembayaran.
e. Setelah SP2D diterbitkan KPPN, kegiatan selanjutnya adalah melakukan
pemindahan kas bank bendahara pengeluaran. Pemindaha kas tersebut
dilakukan dengan cara memasukkan nomor SP2D pada modul Bendahara
melalui menu approval transaksi  pemindahan kas  kas bank bendahara
pengeluaran. Nomor SP2D

2. Mekanisme Pembayaran

Ket: Kegiatan dilakukan dengan Modul Bendahara


Kegiatan dilakukan dengan Modul Pembayaran
Kegiatan dilakukan tidak menggunakan Modul Bendahara dan Modul Pembayaran

Sumber: Diolah Sendiri

23
Berdasarkan keterangan bendahara pengeluaran KPPBC TMP C Teluk Nibung proses
bisnis yang terkait dengan pembayaran terdiri dari beberapa tahapan kegiatan sebagai berikut:

a. Tahapan kegiatan pertama dalam mekanisme pembayaran adalah membuat Surat


Perintah Bayar (SPBy) pada Modul Pembayaran dengan cara memasukkan invoice atau
tagihan dari supplier dan RKAKL. Selanjutnya SPBy diajukan ke PPK untuk dilakukan
validasi. Adapaun output yang dihasilkan adalah ADK SPBy yang selanjutnya akan
terekam secara otomatis pada modul bendahara dan akan digunakan sebagai dasar
penerbitan kuitansi. Dalam pembuatannya, SPBy bisa di-input oleh PPK ataupun
Operator
b. Tahapan selanjutnya adalah menerbitkan kuitansi pada modul bendahara dengan cara
berdasarkan SPBy yang direkam pada modul Bendahara. Kegiatan dapat ini dilakukan
pada submodul “transaksi” menu “ membuat kuitansi”. Adapun output yang
dihasilkan adalah kuitansi yang nantinya akan dikirim kepada supplier untuk ditanda
tangani, dan ADK kuitansi yang tersimpan dalam database Aplikasi SAKTI. Dalam
kuitansi ada 2 (dua) tanggal yaitu tanggal pembuatan dan pembayaran kuitansi. Namun
pada umumnya uang akan diterima sesuai dengan tanggal pembayaran pada kuitansi.
c. Setelah kuitansi terbit bendahara akan mencatat pungutan pajak. Kegiatan ini dilakukan
dengan cara memilih Submodul “transaksi”  menu “mencatat pungutan pajak”.
Perhitungan pajak harus dilakukan berdasarkan peraturan yang berlaku dan sesuai
dengan data pembayaran pada kuitansi. Adapun output pada tahapan ini adalah ADK
Bukti Potong Pajak yang tersimpan dalam database, cetakan Bukti Potong Pajak yang
diserahkan ke supplier, dan dana masuk yang nantinya akan disetor ke kas Negara.
Dalam beberapa kasus, setoran pajak tidak selalu ada karena tidak semua transaksi
dikenakan pajak.
d. Setelah mencatat pungutan pajak, bendahara akan menyetornya ke kas negara. Dalam
tahapan ini ADK Bukti Potong Pajak dan Kode E-Billing akan dijadikan sebagai dasar
dalam menyetor pajak. Setelah menyetor pajak ke kas negara bendahara akan
memperoleh NTPN.
e. Tahapan kegiatan terakhir dari mekanisme pembayaran adalah mencatat setoran pajak
ke kas negara pada modul bendahara. Bukti potong pajak dan NTPN yang diperoleh
pada tahapan sebelumnya dijadikan sebagai dasar dalam mencatat setoran pajak.
Adapun kegiatan ini dilakukan dengan cara memasukkan pada Submodul “setoran” 

24
“setoran pajak”. Setelah dilakukan penginputan pada menu tersebut, saldo uang kas
tunai pada bendahara akan berkurang.
f. Apabila transaksi dengan menggunakan UP menghasilkan persediaan atau aset tetap,
maka ADK Kuitansi yang sudah direkam sebelumnya akan dikirim ke Modul
Persediaan dan Modul Aset Tetap.

3. Pengajuan GUP

Ket: Kegiatan dilakukan dengan Modul Bendahara


Kegiatan dilakukan dengan Modul Pembayaran
Kegiatan dilakukan tidak menggunakan Modul Bendahara dan Modul Pembayaran

Sumber : Diolah sendiri

Berdasarkan keterangan dari Bendahara Pengeluaran KPPBC TMP C Teluk Nibung proses
bisnis pengajuan Ganti Uang Persediaan (GUP) terdiri dari beberapa kegiatan sebagai berikut:

a. Tahapan pertama yaitu membuat Daftar Rincian Permintaan Pembayaran (DRPP) pada
modul bendahara melalui Sub Modul “Membuat Usulan”  menu “Membuat DRPP”.
Membuat DRPP dilakukan berdasarkan daftar kuitansi yang telah diterbitkan
sebelumya dan kode output anggaran. Output dari pembuatan DRPP adalah ADK
DRPP sebagai dasar pembuatan SPP.

25
b. Tahapan kedua adalah pembuatan SPP GUP pada Modul Pembayaran. Operator
membuat SPP GUP berdasarkan ADK DRPP lalu mengajukan kepada PPK untuk
dilakukan pengecekan dan validasi. Apabila PPK menyatakan SPP sesuai, output dari
kegiatan ini adalah ADK SPP GUP yang disampaikan oleh PPK kepada Operator
sebagai dasar pembuatan SPM.

c. Tahapan ketiga adalah pembuatan SPM GUP pada Modul Pembayaran. Berdasarkan
ADK SPP yang disampaikan oleh PPK, operator membuat SPM GUP lalu mengajukan
SPM GUP kepada PPSPM untuk dilakukan penelitian dan approval. Apabila PPSPM
telah menyetujui SPM GUP, output yang dihasilkan kegiatan ini adalah ADK SPM
GUP yang yang selanjutnya akan dikirim oleh operator ke database SAKTI untuk
diproses oleh KPPN.

d. Tahapan Keempat proses SPM GUP pada KPPN. ADK SPM GUP yang telah
dikirimkan ke database SAKTI kemudian akan dilakukan penelitian oleh KPPN.
Apabila hasil penelitian oleh KPPN menyatakan bahwa SPM GUP sesuai, maka KPPN
akan menerbitkan dokumen SP2D. Output dari kegiatan ini adalah SP2D yang dapat
dilihat pada aplikasi SPAN.

e. Tahapan terakhir dari proses bisnis ini adalah pemindahan kas ke Saldo Rekening Bank
Bendahara. Setelah SP2D terbit dari KPPN, kemudian Bendahara Pengeluaran
memasukkan nomor SP2D pada Modul Bendahara melalui Sub Modul “Approval
Transaksi” Pemindahan Kas  Menu “Kas Bank Bendahara Pengeluaran” sehingga
saldo Kas Bank Bendahara bertambah.

4. Pengajuan GUP dengan Uang Muka

Berdasarkan keterangan Bendahara Pengeluaran KPPBC TMP C Teluk Nibung, pada


dasarnya proses pengajuan GUP dengan uang muka sama dengan pengajuan GUP tanpa uang
muka. Perbedaan mendasar hanya pada jenis transaksinya. Jika sebuah transaksi memerlukan
pengeluaran uang kas sebegai uang muka belanja, bendahara akan melakukan perekaman uang
muka pada modul bendahara melalui Sub Modul “Transaksi”  “ Merekam Uang Muka. Uang
muka yang telah direkam pada modul bendahara dijadikan dasar pembuatan Kuitansi Uang
Muka. Perlu diketahui bahwa kuitansi uang muka sebenarnya belum bisa dianggap sebagai
realisasi belanja sehingga hanya mengurangi saldo kas tunai namun tidak mengurangi saldo
Kas UP. Pada saat dilakukan pelunanasan, bendahara melakukan pembuatan kuitansi pada

26
modul bendahara melalui Sub Modul “Transaksi” menu “Membuat Kuitansi” dengan
mencantumkan nomor referensi uang muka yang telah direkam sebelumnya sehingga angka
pada kuitansi yang diterbitkan hanya sebesar sisa belanja yang masih harus dibayar.

5. LS Bendahara

Berdasarkan keterangan Bendahara Pengeluaran KPPBC TMP C Teluk Nibung. Pada


dasarnya mekanisme pembayaran LS bendahara sama dengan mekanisme pembayaran LS pada
umumnya, hanya saja pencairan dana ditransfer ke rekening kas bank bendahara pengeluaran
untuk diteruskan kepada pihak yang ditentukan (Dana Titipan). Dana yang masuk ke rekening
bendahara selanjutnya akan dilakukan pemindahan kas pada modul bendahara melalui Sub
Modul “Approval Transaksi” Pemindahan Kas  menu “Kas Bank Bendahara
Pengeluaran”. Dasar bendahara dalam melakukan pemindahan kas ada dokumen SP2D yang
dapat dilihat pada aplikasi SPAN, sedangkan output-nya adalah bertambahnya saldo rekening
kas bank bendahara pengeluaran. Pada saat bendahara telah menyalurkan dana LS Bendahara,
selanjutnya bendahara mencatat pembayaran dana tersebut pada modul bendahara melalui Sub
Modul “Transaksi”menu “Mencatat Pembayaran Dana Titipan” sehingga kas bank
bendahara pengeluaran menjadi berkurang. Dalam hal bendahara menyalurkan dana dengan
cara tunai, terlebih dahulu bendahara akan melakukan pemindahan kas bank menjadi kas tunai
pada modul bendahara melalui Sub Modul “Transaksi” “Pemindahan Kas” menu “Kas
Tunai Bendahara Pengeluaran”. Dasar dalam pemindahan dari kas bank ke kas tunai adalah
cek yang diterbitkan oleh bendahara dan bukti penarikan dana dari bank.

6. Penyampaian Laporan Pertanggungjawaban Bendahara

Membuat Laporan Pertanggungjawaban Bendahara merupakan proses bisnis akhir pada


modul bendahara dan merupakan output yang dihasilkan dari modul bendahara. Seluruh proses
bisnis yang dilakukan bendahara akan diikhtisarkan dalam laporan pertanggungjawaban
bendahara. Proses cetak laporan pertanggungjawaban bendahara dapat dilakukan melalui Sub
Modul “Cetak Laporan”menu LPJ Bendahara Pengeluaran. Laporan pertanggungjawaban
yang telah dicetak kemudian diajukan kepada kepala sakter untuk dilakukan approval dan
disampaikan ke KPPN melalui jasa ekspedisi, selain menyampaikan LPJ secara fisik bendahara
juga diwajibkan untuk menyampaikan ADK Laporan Pertanggungjawaban bendahara ke
KPPN melalui aplikasi SPRINT. ADK Laporan Pertanggungjawaban Bendahara dapat
didownload melalui aplikasi MONSAKTI, kemudian diupload ke aplikasi SPRINT untuk
direkonsiliasi dengan KPPN.

27
F. Permasalahan dan Saran Perbaikan pada Modul Bendahara

Berdasarkan Peraturan Menteri Keuangan nomor 159/PMK.05/2018 tentang


pelaksanaan piloting SAKTI, progress pengembangan aplikasi SAKTI saat ini masih dalam
proses piloting atau uji coba. Jika kita hubungkan dengan teori SDLC yang dikemukakan oleh
Romney dan Steinbart, Penulis mengambil kesimpulan bahwa penerapan sistem aplikasi
SAKTI termasuk dalam tahapan yang ke-4 yaitu implementation and convertion. Beberapa
alasan mengapa Penulis menyimpulkan penerapan aplikasi SAKTI masih dalam proses
implementation and convertion karena adanya kesesuaian fakta di lapangan dengan teori SDLC
diantaranya:

1. Adanya kegiatan pelatihan aplikasi SAKTI kepada bendahara satker;


2. Adanya konversi dari aplikasi SAS ke aplikasi SAKTI dan belum semua satker
mengoperasikan aplikasi SAKTI;
3. Masih ditemukannya beberapa masalah pada aplikasi SAKTI yang perlu dilakukan
penyesuaian dan penyempurnaan.

Selain itu pasal 7 ayat (1) PMK 159/PMK.05/2018 menyatakan bahwa piloting aplikasi SAKTI
dilaksanakan sebelum SAKTI diterapkan pada seluruh Satker di Kementerian Negara/
Lembaga.

Sehubungan dengan beberapa masalah yang terjadi pada aplikasi SAKTI saat ini
menurut penulis adalah hal yang wajar dikarenakan masih dalam tahap implementasi, namun
demikian penulis berpendapat bahwa masalah-masalah tersebut perlu dilakukan
penyempurnaan agar kedepannya pada saat aplikasi SAKTI diterapkan pada seluruh satker
dapat berjalan lebih baik. Adapun beberapa masalah yang penulis temukan berdasarkan hasil
wawancara dengan beberapa narasumber akan penulis uraikan berdasarkan jenis kegiatan yang
menggunakan modul bendahara, diantaranya:

1. Kegiatan Pembuatan Kuitansi


Beberapa masalah yang terjadi pada saat pembuatan kuitansi diantaranya:
a. Terjadi Kesalahan Input

Berdasarkan keterangan dari bendahara pada KPPBC TMP C Teluk Nibung, masalah
ini tejadi ketika yang bersangkutan melakukan kesalahan dalam memasukkan tanggal transaksi
saat pembuatan kuitansi, di mana transaksi pada bulan Februari dicatat sebagai transaksi bulan
Januari. Dampak yang timbul atas masalah tersebut adalah terjadinya perbedaan angka saldo

28
pada LPJ Bendahara Pengeluaran telah disampaikan ke KPPN dengan LPJ yang tersimpan di
database SAKTI. Masalah selanjutnya yang muncul adalah kegagalan dalam rekonsiliasi LPJ
bulan februari dengan KPPN yang disebabkan oleh perbedaan saldo pada LPJ Januari. Untuk
mengatasi masalah tersebut Bendahara harus menyusun dan menyampaikan kembali LPJ
Januari dan Februari ke KPPN. Selain itu, kesalahan input ini hanya dapat dideteksi pada saat
pengajuan LPJ dan dapat terjadi juga pada proses pemasukan lainnya.

Menurut pendapat penulis, akar permasalahan di atas terletak pada kurangnya ketelitian
bendahara dalam merekam kuitansi dan kurangnya pengendalian aplikasi khususnya
pengendalian input pada modul bendahara, di mana bendahara masih dapat merekam kuitansi
transaksi bulan februari dengan menggunakan tanggal pada bulan januari. Menurut pendapat
penulis ada 2 hal yang dapat dilakukan untuk mencegah masalah ini terjadi lagi. Pertama,
bendahara disarankan untuk melakukan pengecekan ulang sebelum melakukan penyimpanan
dalam pembuatan kuitansi. Kedua, perlunya diterapkan pengendalian input berupa
pengendalian validasi pada aplikasi SAKTI khususnya modul bendahara. Pengendalian
validasi di sini dapat berupa pemeriksaan batas (limit check) dan perbaikan segera. Dalam
kasus di atas, penerapan limit check ini akan mencegah bendahara dalam melakukan kesalahan
perekaman transaksi bulan februari, karena pada saat perekaman transaksi bulan februari
sistem akan memblokir tanggal selain tanggal pada februari. Penerapan perbaikan segera di
sini maksudnya adalah sistem secara otomtis langsung mendeteksi kesalahan dalam perekaman
dan memberikan peringatan sehingga bendahara dapat langsung melakukan perbaikan.

b. Pembuatan Kuitansi Sekaligus


Berdasarkan hasil wawancara dengan bendahara pengeluaran KPU BC Tipe C
Soekarno Hatta, penulis mendapati bahwa bendahara pengeluaran membuat kuitansi secara
manual menggunakan Microsoft Excel, sedangkan pembuatan kuitansi pada aplikasi SAKTI
dilakukan sekaligus di akhir bulan. Aplikasi SAKTI memungkinkan pemasukan tanggal
kuitansi yang sudah terlewat atau berbeda dengan tanggal saat kuitansi dibuat. Hal tersebut
dilakukan karena kuantitas perekaman SPBy yang berbeda setiap hari. Bendahara pengeluaran
berpendapat bahwa pembuatan kuitansi melalui aplikasi SAKTI yang dilakukan sekaligus pada
akhir bulan dirasa lebih efisien dibandingkan dengan pembuatan kuitansi setiap kali terdapat
perekaman dokumen SPBy di modul pembayaran.
Meskipun tidak ada peraturan yang dilanggar oleh bendahara pengeluaran tersebut,
penulis kurang setuju dengan praktik yang terjadi. Penumpukan volume pekerjaan di akhir
bulan akan meningkatkan risiko-risiko dalam pelaksanaan pembuatan kuitansi, antara lain

29
risiko kesalahan input data dan risiko hilangnya dokumen-dokumen yang berhubungan dengan
kegiatan tersebut. Beberapa tindakan yang menurut penulis perlu dilakukan adalah membuat
SOP yang mengatur khusus agar setiap transaksi dapat dimasukkan dengan segera, sebagai
contoh minimal selambat-lambatnya 3 hari kerja setelah transaksi. Hal ini sesuai dengan
prinsip-prinsip pelaksanaan SOP yang tercantum pada Peraturan MENPAN nomor 21 tahun
2008, yaitu komitment, perbaikan terus menerus, dan terdokumentasi dengan baik. Selain
pembuatan SOP, hal lain yang dapat dilakukan untuk mendukung SOP tersebut adalah dengan
menerapkan pengendalian internal berupa pengendalian validasi berupa limit check pada field
modul bendahara sebagaimana penulis uraikan pada point sebelumnya dan sesuai dengan teori
yang dikemukakan oleh James A. Hall dalam bukunya yang berjudul Sistem Informasi
Akuntansi (2007;496). Penerapan pengendalian limit check dimaksudkan untuk membatasi
bendahara agar segera melakukan perekaman kuitansi. Sebagai ilustrasi penerapan limit check,
misalnya bendahara melakukan transaksi tanggal 26 maret 2019 dan asumsikan SOP
sebelumnya telah dibuat dan mengatur bahwa 2 hari kerja setelah transaksi terjadi wajib
dilakukan perekaman. Dengan adanya pengendalian validasi berupa limit check akan mencegah
bendahara memasukkan transaksi pada waktu lebih dari 2 hari kerja, misalkan jika bendara
memasukkan kuitansi tanggal 31 Maret 2019 maka tanggal 26 maret 2019 sampai dengan 28
Maret 2019 akan diblokir oleh sistem secara otomatis.

2. Aplikasi Error pada jam-jam tertentu


Berdasarkan hasil wawancara dengan Bendahara KPU BC Tipe C Soekarno Hatta ,
masalah lain yang penulis temukan saat melakukan wawancara adalah selalu terjadinya
kesalahan cetak data pada Bukti Setoran Pajak saat dilakukan cetak dokumen. Semua data
setoran pajak yang di-input pada aplikasi SAKTI telah sesuai namun data-data pada output
dokumen tersebut tidak sesuai, sedangkan pada aplikasi sudah tercatat dengan benar. Maka
Bendahara Pengeluaran KPU BC Tipe C Soekarno Hatta mencetak ulang dengan memasukkan
secara manual menggunakan data yang sudah di-input dengan benar.

Setelah penulis berdiskusi operator-operator SAKTI pada beberapa satuan kerja lain,
masalah yang hampir serupa juga kadang terjadi. Seperti pada aplikasi SAKTI di Kantor
Wilayah DJKN Papua, Papua Barat, dan Maluku serta Kantor Wilayah Bea dan Cukai
Sumatera Bagian Timur, aplikasi SAKTI kadang gagal menghasilkan output dokumen padahal
data yang di-input telah benar dan gagal melakukan input. Masalah ini dapat disebabkan oleh
2 hal, yaitu kurangnya kapasitas akses intranet Kementerian Keuangan dan belum
sempurnanya aplikasi SAKTI.

30
Menurut keterangan dari Bendahara Kantor Wilayah DJKN Papua, Papua Barat, dan
Maluku, pihak DJPBn telah mengkonfirmasi bahwa intranet Kementerian Keuangan tidak
hanya diakses oleh aplikasi SAKTI, namun juga dipergunakan oleh aplikasi-aplikasi lain dari
Kementerian Keuangan sehingga pada saat-saat tertentu dapat terjadi gagal input data ataupun
gagal menerima data. Menurut penulis, agar mengurangi kegagalan transfer data pada aplikasi
SAKTI, perlu disediakan server atau jaringan yang dibuat secara khusus untuk aplikasi SAKTI.
Jaringan dan server yang dipergunakan khusus untuk aplikasi SAKTI tersebut diharapkan dapat
menjaga performa aplikasi disaat aplikasi banyak diakses.

Selanjutnya, menurut Romney dan Steintbart (2015; 591) dalam tahap Implementation
and Convertion seharusnya dilakukan penyesuaian pada defisiensi-defisiensi yang ada. Karena
saat ini aplikasi SAKTI berada tahap ini, penulis sependapat dengan Romney dan Steinbart
bahwa sebaiknya diadakan pembaruan yang lebih rutin untuk mengatasi defisiensi seperti
kesalahan cetak dokumen Bukti Setoran Pajak sebagai perbaikan dalam jangka pendek, atau
mempertimbangkan untuk membangun server atau jaringan sendiri khusus untuk Aplikasi
SAKTI sebagai program perbaikan dalam jangka panjang.

3. Kegiatan Pembuatan LPJ


Dalam pembuatan LPJ, penulis mengidetifikasi beberapa masalah, yaitu:
a. Error saat mencetak LPJ

Masalah lain yang muncul terkait dengan modul bendahara berdasarkan hasil
wawancara dengan bendahara KPU BC Tipe C Soekarno Hatta adalah error dalam saat
mencetak LPJ. Adapun kronolgis dari masalah ini adalah ketika bendahara mengajukan GUP
atas kuitansi pada bulan februari dan telah berhasil sampai SP2D, namun pada saat mencetak
LPJ bulan februari ternyata kuitansi tersebut statusnya belum diajukan GUP sehingga terjadi
selisih pembukan UP pada LPJ bulan Februari.

Menurut pendapat penulis masalah tersebut mungkin terjadi karena disebabkan dua hal
seperti aplikasi error pada saat mencetak LPJ ataupun pemasukan pengajuan GUP tidak
tersimpan dalam database aplikasi SAKTI. Masalah ini akan semakin kompleks jika terjadi di
waktu yang dekat dengan hari deadline pengajuan LPJ sehingga akan berdampak pada
terlambatnya pengajuan LPJ ke KPPN. Selain itu dampak negatif lain yang muncul akibat dari
keterlambatan pengajuan LPJ adalah tidak bisa mengajukan SPM dan mempengaruhi IKU
kualitas anggaran satker serta IKU dari bendahara itu sendiri.

31
Beberapa tindakan yang dapat dilakukan untuk mengantisipasi masalah tersebut adalah
dengan menghindari pengajuan LPJ di waktu yang dekat dengan hari deadline dan mencetak
LPJ sesegera mungkin di awal periode pelaporan. Hal ini bertujuan agar memberikan spare
waktu kepada bendahara untuk melaporkan masalah atau error aplikasi SAKTI kepada DJPB.
Selain itu penulis juga menyarankan agar bendahara membuat format LPJ manual dalam
bentuk excel untuk berjaga-jaga jika seandainya bendahara diharuskan membuat LPJ secara
manual akibat error tersebut.

Sebenarnya error yang terjadi pada saat mencetak LPJ sama dengan masalah yang terkait
dengan error saat mencetak NTPN di atas. Oleh karena itu penulis mencoba memberikan
pendapat agar dapat dipertimbangkan untuk membangun server sendiri khusus untuk Aplikasi
SAKTI sebagai program perbaikan jangka panjang.

b. Anomali Data Pembaharuan

Berdasarkan hasil wawancara dengan bendahara pengeluaran KPU BC Tipe C


Soekarno Hatta, salah satu masalah yang ada pada aplikasi SAKTI adalah gagal saat melakukan
rekonsiliasi LPJ pada aplikasi SPRINT dikarenakan adanya perbedaan data nama rekening
antara aplikasi SAKTI dan aplikasi SPRINT. Perbedaan data tersebut terjadi lantaran
sebelumnya bendahara melakukan perubahan nama rekening pada modul bendahara aplikasi
SAKTI.

Menurut pendapat penulis perbedaan data ini mungkin terjadi karena 2 hal, pertama,
database aplikasi SAKTI dan database aplikasi SPRINT berbeda dan tidak terhubung. Kedua,
aplikasi SAKTI dan aplikasi SPRINT menggunakan database yang terintegrasi namun terjadi
masalah Anomali Pembaharuan. Romney dan Steinbart (2015;107) menjelaskan bahwa
anomali pembaruan terjadi ketika melakukan perubahan data pada suatu lokasi namun di lokasi
lain data tersebut tidak mengalami perubahan sehingga menimbulkan inkonsistensi data.

Menurut pendapat penulis adanya perbedaan data antara aplikasi SAKTI dan aplikasi
SPRINT perlu dilakukan perbaikan karena selain menyebabkan inkonsistensi data juga
menimbulkan redundansi data sehingga berdampak negatif pada keakuratan data. Beberapa
cara untuk mengatasi tersebut dapat dilakukan dengan:

1) Mengintegrasikan database SAKTI dengan database SPRINT (jika belum terhubung)

32
2) Menghentikan penggunaan aplikasi SPRINT, sehingga seluruh pekerjaan bendahara yang
berhubungan dengan aplikasi SPRINT dialihkan ke aplikasi SAKTI, sehingga semua data
hanya dikelola dan disimpan pada database aplikasi SAKTI.
Namun dari kedua cara tersebut, menurut penulis cara kedua lebih efektif daripada cara
yang pertama. Menggunakan satu aplikasi namun mampu mengakomodir selueuh pekerjaan
yang saling berhubungan akan lebih efisien dibanding menggunakan dua aplikasi. Selain itu,
apabila menggunakan dua aplikasi dan ternyata salah satu aplikasi sewaktu-waktu rusak maka
secara langsung akan menghambat pekerjaan itu sendiri. Sebagai ilustrasi penulis mengambil
contoh masalah di atas, misalnya bendahara pengeluaran ingin melakukan rekonsiliasi LPJ
yang merupakan output dari aplikasi SAKTI. Jika pada saat itu aplikasi SPRINT error atau
tidak dapat diakses, maka LPJ tersebut tentu tidak dapat dilakukan rekonsiliasi, sehingga
penggunaan dari aplikasi SAKTI sendiri menjadi kurang efektif. Masalah tersebut mungkin
tidak terjadi jika seandainya kegiatan rekonsiliasi tersebut dapat dilakukan langsung pada
aplikasi SAKTI, walaupun sebenarnya gagal akses atau error dapat juga terjadi pada aplikasi
SAKTI namun penulis berpendapat tetap lebih efektif dan efisien jika kita menggunakan satu
aplikasi namun dapat mengakomodir pekerjaan yang saling berkesinambungan.

c. Belum Terintegrasinya Semua Aktivitas Keuangan

SAKTI merupakan integrasi dari berbagai aplikasi keuangan yang terdiri dari beberapa
modul. Seluruh modul yang terdapat pada aplikasi SAKTI memiliki proses bisnisnya masing-
masing dan dapat digunakan mulai dari proses perencanaan, pelaksanaan, hingga proses
pertanggungjawaban.

Romney dan Steinbart (2015, 41) menyatakan bahwa Enterprise Resource Planning
System (ERP system) merupakan suatu sistem yang mengintegrasikan semua aspek aktivitas
organisasi seperti akuntansi, keuangan, pemasaran, sumber daya manusia, manufaktur,
manajemen persediaan ke dalam satu sistem. ERP memfasilitasi arus informasi antara berbagai
fungsi bisnis perusahaan dan mengelola komunikasi dengan para pemangku kepentingan di
luar. Jika mengacu kepada definisi ERP yang dikemukakan oleh Romney dan Steinbart, maka
penulis dapat berpendapat bahwa aplikasi SAKTI memenuhi kriteria sebagai ERP. Dengan
sifat modular yang dimiliki oleh aplikasi SAKTI, diharapkan setiap modul dapat memberikan
kemudahan yang signifikan.

Namun pada praktiknya, berdasarkan hasil wawancara dengan Bendahara KPU Tipe C
Soekarno Hatta, masih terdapat beberapa masalah pada fungsi aplikasi SAKTI sebagai ERP,

33
sebagai contoh pada saat merekonsiliasi LPJ. Pada saat ingin merekonsiliasi LPJ, bendahara
harus melakukan download LPJ terlebih dahulu pada aplikasi MONSAKTI, lalu upload pada
aplikasi SPRINT untuk direkonsiliasi. Menurut pendapat penulis rangkaian aktivitas tersebut
terlihat kurang efisien, karena pada dasarnya data yang didownload pada aplikasi MONSAKTI
itu merupakan data yang direkam pada aplikasi SAKTI sehingga aplikasi SAKTI belum
mengintegrasikan semua aktivitas keuangan dalam satu sistem. Tentunya, hal ini dapat
memperlambat proses bisnis aktivitas keuangan, karena mengharuskan bendahara untuk
membuka aplikasi yang satu dengan yang lainnya secara bergantian. Selain itu, apabila salah
satu dari beberapa aplikasi ini mengalami gangguan, maka akan mempengaruhi proses bisnis
pada aplikasi lainnya, sehingga kegiatan bendahara tidak dapat berjalan dengan efisien dan
efektif.

Harapan penulis, kedepannya fitur pada aplikasi SAKTI mungkin dapat ditambah
seperti seperti dapat melakukan rekonsiliasi langsung dari Aplikasi SAKTI, tidak melalui
proses download dari MONSAKTI dan upload ke aplikasi SPRINT. Apabila aktivitas tersebut
dapat dilakukan, tentu hal ini akan menyebabkan kegiatan bendahara lebih efisien dan efektif.

4. Permasalahan Lainnya
Selain masalah terkait kegiatan-kegiatan di atas, penulis juga mengidentifikasi
masalah-masalah lainnya, sebagai berikut:

a. Penggunaan aplikasi pihak ketiga untuk mengakses VPN Kemenkeu

Seperti yang dijelaskan sebelumnya, aplikasi SAKTI hanya dapat berjalan dengan
menggunakan intranet Kementerian Keuangan yang disediakan oleh PUSINTEK Sekretariat
Jenderal Kementerian Keuangan. Namun saat penulis melakukan wawancara dengan
bendahara KPU BC Tipe C Soekarno Hatta, diketahui bahwa aplikasi SAKTI yang digunakan
oleh bendahara kantor tersebut memerlukan bantuan aplikasi pihak ketiga “Forticlient” untuk
mengakses jaringan milik Kementerian Keuangan dengan koneksi internet, sehingga dapat
terhubung ke intranet Kementerian Keuangan.

Pada dasarnya penggunaan intranet oleh Kementerian Keuangan untuk mengakses


aplikasi SAKTI merupakan bentuk pengendalian internal agar aplikasi SAKTI tidak dapat
diakses bebas dan hanya dapat diakses oleh orang-orang tertentu. Namun pengendalian internal
tersebut terancam tidak efektif jika intranet Kementerian Keuangan dapat diakses dengan
mudah dengan aplikasi pihak ketiga.

34
Penulis menemukan bahwa kemudahan untuk mengakses intranet Kementerian
Keuangan dengan bantuan aplikasi pihak ketiga menimbulkan potensi terjadinya kecurangan
dan penyalahgunaan wewenang pada penggunan aplikasi SAKTI. Kecurangan yang penulis
maksud di sini adalah user dapat mengakses darimana saja sehingga terdapat celah untuk user
tidak masuk kantor. Misalnya seorang operator aplikasi SAKTI bisa melakukan pekerjaannya
di manapun tanpa hadir di kantor sehingga akan memungkinkan operator untuk bolos kerja
atau hanya absen pagi dan absen sore namun tidak berada di kantor. Selain adanya kecurangan,
hal ini juga membuat akses ke aplikasi SAKTI bergantung pada aplikasi pihak ketiga.

Sepengetahuan penulis untuk masuk ke dalam jaringan intranet Kemenkeu harus


memiliki akun VPN Kemenkeu, penulis berpendapat sebaiknya akun ini hanya dimiliki oleh
pejabat di tingkat validator dan approver menimbang tingkat mobilitas pejabat pada umumnya
lebih tinggi daripada operator, sehingga operator tidak akan dengan mudah bebas masuk ke
intranet Kemenkeu. Selain itu penulis memandang perlu agar Kementerian Keuangan
menambah verifikasi tambahan selain akun untuk dapat masuk ke intranet Kementerian
Keuangan seperti misalnya one time password yang hanya diberikan kepada pemegang akun.
Dengan demikian, walaupun seandainya operator mengetahui akun tersebut tetap harus
mendapat izin dari validator atau approver.

Pemasangan aplikasi SAKTI seharusnya dibatasi hanya pada komputer yang digunakan
oleh operator dan tidak diizinkan dipasang di laptop untuk menghindari penggunaan aplikasi
SAKTI di luar kantor. Selain itu, masing-masing kantor terlebih lagi satker pada Kementerian
Keuangan perlu melakukan penyempurnaan jaringan intranet agar setiap kantor dapat
mengakses aplikasi SAKTI tanpa perlu menggunakan VPN. Dengan begitu tujuan pemakaian
VPN menjadi tepat sasaran.

b. Kurangnya Pengetahuan Administrator

Dalam pengoperasiannya, SAKTI yang tergolong aplikasi baru masih sering


menghadapi beberapa masalah. Berdasarkan hasil wawancara dengan Bendahara KPP Pratama
Kabanjahe, yang bersangkutan dan beberapa rekan lainnya sesama bendahara masih sulit untuk
mengatasi masalah-masalah tersebut. Salah satu contoh masalah yang sulit diatasi yakni
kesalahan status SPM dalam rangka pengajuan UP. Untuk mencoba mengatasi beberapa
masalah tersebut, bendahara harus menghubungi administrator aplikasi SAKTI di KPPN secara
manual.

35
Dalam mengatasi beberapa masalah, administrator di KPPN pun masih mengalami
kesulitan juga, sehingga mereka sering menyarankan bendahara untuk menghubungi layanan
HaiDJPb secara langsung. Maka dari itu, hal ini membuat Bendahara harus langsung
menghubungi layanan Hai DJPb ketika mengalami beberapa masalah pada aplikasi SAKTI
daripada menghubungi administrator di KPPN.

Dalam penyampaian masalah, bendahara sering menggunakan fasilitas email ticketing


layanan HaiDJPb. Namun fasilitas ini kurang efisien karena respons yang diberikan tidak
secepat yang diharapkan, sehingga bendahara sering menggunakan fasilitas alternatif lainnya
seperti menghubungi call center haiDJPb. Fasilitas ini lebih efisien dibandingkan fasilitas
email ticketing karena respons yang diberikan lebih cepat. Namun, dalam memanfaatkan
fasilitas call center ini, bendahara masih sering menemukan masalah. Adapun masalah yang
ditemukan yaitu administrator haiDJPb yang menerima panggilan tidak selalu mengetahui cara
untuk mengatasi masalah yang dihadapi bendahara, sehingga administrator tersebut sering
menghimbau bendahara untuk menunggu, agar administrator memiliki kesempatan diskusi
dengan administrator lainnya dalam hal pemecahan masalah yang dihadapi bendahara.

Kurangnya pengetahuan administrator dalam memberikan solusi kepada bendahara


dapat menghambat efisiensi kinerja bendahara itu sendiri. Apabila administrator di KPPN dan
administrator haiDJPb dapat memberikan solusi dengan respons yang cepat kepada bendahara,
maka kegiatan bendahara dapat berjalan efisien.

Penulis berharap pihak DJPb tetap memberikan pelatihan berkelanjutan kepada


bendahara dan juga administrator. Pelatihan berkelanjutan ini sangat penting, selain membantu
bendahara dalam mengoperasikan aplikasi dan mengatasi masalah yang dihadapinya, pelatihan
berkelanjutan juga dapat menambah wawasan administrator mengenai seluk beluk aplikasi
SAKTI, baik itu dari segi arsitektur, permasalahan, dan juga solusinya. Pelatihan berkelanjutan
juga mampu meningkatkan sinergi antara bendahara dengan pihak DJPB, sehingga tercipta
aktivitas keuangan yang lebih efisien dan efektif.

36
BAB III

Penutup

A. Simpulan

Terdapat lima proses yang dapat dilakukan pada modul bendahara Aplikasi SAKTI
antara lain pengajuan UP/TUP, Pembayaran, Pengajuan GUP/GTUP tanpa uang muka,
GUP/GTUP dengan uang muka, LS Bendahara, dan Penyampaian Laporan
Pertanggungjawaban. Dalam menjalankan proses bisnisnya, modul bendahara memiliki
keterkaitan dengan beberapa modul lainnya pada Aplikasi SAKTI seperti modul modul
pembayaran, modul persediaan, modul aset tetap, modul pelaporan, dan modul administrator,
dan modul penganggaran.

Penerapan aplikasi SAKTI saat ini masih dalam tahap uji coba sehingga masih terdapat
beberapa masalah yang perlu diperbaiki agar kedepannnya apabila Aplikasi SAKTI diterapkan
ke seluruh satker dapat berjalan dengan lancar. Beberapa perbaikan yang dapat dilakukan
umumnya berkaitan dengan penyempurnaan atau penyesuaian sistem atas defisiensi design
Aplikasi SAKTI termasuk modul bendahara.

B. Saran

Berdasarkan hasil pembahasan di atas, beberapa saran yang dapat penulis berikan
adalah sebagai berikut:

1. Sebaiknya dilakukan penyempurnaan sistem terkait dengan pengendalian input


berupa pengendalian validasi agar kedepannya sistem dapat mencegah kesalahan
input atau dapat segera mendeteksi kesalahan input, selain itu dapat mencegah
bendahara.
2. Selain perbaikan sistem, sebaiknya dibuat SOP Bendahara terkait dengan
penggunaan Modul Bendahara agar kedepannya perekaman kuitansi tidak
ditumpuk pada akhir bulan
3. Sebaiknya perlu dipertimbangkan agar membangun server dan jaringan khusus
Aplikasi SAKTI.
4. Sebaiknya bendahara menghindari pengajuan LPJ pada waktu yang dekat denga
deadline dan mencetak LPJ sesegera mungkin di awal periode pelaporan.

37
5. Sebaiknya fitur aplikasi SAKTI dapat ditambah agar kegiatan yang terkait dengan
bendahara dan bersifat berkesinambungan dapat seluruhnya dilakukan pada
Aplikasi SAKTI.
6. Sebaiknya seluruh user dan administrator Aplikasi SAKTI diberikan pelatihan
berkelanjutan agar kedepannya mereka mengetahui cara untuk mencegah dan
mengatasi masalah pada Aplikasi SAKTI termasuk modul bendahara.
7. Disarankan agar kedepannya DJPB berkenan untuk mendistribusikan aplikasi
demo ke setiap kampus yang mengajarkan mata kuliah yang berhubungan dengan
akuntansi pemerintahan sehingga proses pembelajaran dan latihan dapat
dipraktekkan secara langsung mengunakan aplikasi.

38
Daftar Pustaka

A. Regulasi
Undang-Undang Nomor 17 Tahun 2003 tentang Keuangan Negara
Undang-Undang Nomor 1 Tahun 2004 tentang Perbendaharaan Negara
Peraturan Pemerintah nomor 60 tahun 2008 tentang Sistem Pengendalian Intern
Pemerintah
Peraturan Menteri Keuangan Nomor 162/PMK.05/2013 jo. PMK Nomor
230/PMK.05/2016 tentang Kedudukan dan Tanggung Jawab Bendahara Pada Satuan Kerja
Pengelola APBN
Peraturan Menteri Keuangan nomor 190/PMK.05/2012 tentang Tata Cara Pembayaran
dalam rangk Pelaksanaan Anggaran Pendapatan dan Belanja Negara
Peraturan Menteri Keuangan Nomor 159/PMK.05/2018 tentang Pelaksanaan Piloting
Sistem Aplikasi Keuangan Tingkat Instansi
Permendagri Nomor 13 tahun 2006 tentang Pedoman Pengelolaan Keuangan Daerah

Peraturan Menteri Negara Pendayagunaan Aparatur Negara Nomor


PER/21/M.PAN/11/2008 tentang Pedoman Penyusunan Standar Operational Prosedur (SOP)
Administrasi Pemerintahan

B. Literatur

Ascarya dan Yumanita. 2006. Analisis Efisiensi Perbankan Syariah di Indonesia


dengan Data Envelopment Analysis. TAZKIA Islamic Finance and Business Review, Vol.1,
No.2. Desember 2006.

Handayaningrat, Soewarno. 2006. Pengantar Studi Ilmu Administrasi dan Manajemen.


Jakarta: Toko Gunung Agung.

Hartatik, Indah Puji. 2014. Buku Praktis Mengembangkan SDM. Jogjakarta. Laksana.

Indah Susantun, 2000. Fungsi Keuntungan Cobb Douglas dalam Perdagangan


Efisiensi Ekonomi Relatif. Jurnal Ekonomi Pembangunan Vol.5 No.2 hal 149– 161.

Hall, J. A. ( 2007). Sistem Informasi Akuntansi. Buku 2. . Jakarta: Salemba Empat.

Laksmi, Fuad Gani, Budiantoro. 2015. Manajemen Perkantoran Modern. Jakarta:


RajaGrafindo Persada.

39
Lubis, S.M. Hari & Huseini, Martani. 1987. Teori Organisasi: Suatu Pendekatan
Makro. Jakarta: Pusat Antar Universitas Ilmu-Ilmu Sosial.

Ritaudin Isnaini. 2015. Analisis Efisiensi dan Produktivitas dari LPTK di Indonesia.
Jurnal Elektronik Pendidikan Teknik Elektronika. Edisi 4, Volume 4, Nomor 7, September -
Oktober 2015

Romney, Marshal B dan Paul Jhon Steinbart. (2015). Accounting Information Systems.

Jakarta: Salemba Empat.

Strees, Richard M. 1985. Efektifitas Organisasi. Jakarta: PPm. Erlangga.

Suswadi. 2007. Analisa Efisiensi Perbankan Syariah Di Indonesia (Metode Stochastic


Frontier Approach / SFA). Yogyakarta: Skripsi Universitas Islam Indonesia.

Sutrisno, Edi. 2011. Budaya Organisasi. Surabaya: Kencana Prenamedia Group.

40
LAMPIRAN
FOTO KUNJUNGAN KE KPU BC TIPE C SOEKARNO HATTA

41