span - sakti

DAFTAR ISI
Halaman Judul
Daftar Isi
I.
PENDAHULUAN
A. Latar Belakang
B. Tujuan Pembelajaran
C. Sistematika dan Ruang Lingkup
D. Metode Pembelajaran
II.
GAMBARAN UMUM
A. Sistem Perbendaharaan dan Anggaran Negara (SPAN)
B. Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI)
C. Koneksitas SPAN DAN SAKTI
III. PROSES BISNIS SPAN DAN SAKTI
A. Penganggaran
B. Pelaksanaan Anggaran
C. Pertanggungjawaban
IV. PERSIAPAN KEMENTERIAN / LEMBAGA DALAM MENYONGSONG IMPLEMENTASI
SPAN DAN SAKTI
V.
PENUTUP
REFERENSI
ii
BAB I
PENDAHULUAN
A. LATAR BELAKANG
Reformasi birokrasi yang sedang dilaksanakan oleh Pemerintah Indonesia sejak bergulirnya
paket Undang-Undang Keuangan Negara pada tahun 2003, terjadi pada saat dunia sedang
mengalami transformasi menuju era masyarakat informasi. Kemajuan teknologi informasi
yang demikian pesat dengan potensi pemanfaatannya yang sangat luas, membuka peluang
bagi pengaksesan, pengelolaan, dan pendayagunaan informasi dalam volume yang besar
secara cepat dan akurat. Hal tersebut telah menunjukkan bahwa penggunaan media
elektronik merupakan faktor yang sangat penting dalam berbagai transaksi internasional,
terutama dalam transaksi perdagangan.
Ketidakmampuan menyesuaikan diri dengan
kecenderungan global tersebut akan membawa suatu negara ke dalam jurang digital
divide, yaitu keterisolasian dari perkembangan global karena ketidakmampuan dalam
memanfaatkan informasi, sehingga reformasi birokrasi yang saat ini tengah kita laksanakan
harus pula diarahkan untuk mendorong bangsa Indonesia menuju masyarakat informasi.
Pemerintah melalui Instruksi Presiden Republik Indonesia No. 3 Tahun 2003 tanggal 9 Juni
2003, melaksanakan proses transformasi menuju e-government. Untuk mewujudkan
terbentuknya e-government di lingkup Kementerian Keuangan dan memungkinkan
tercapainya profesionalitas dan kualitas pengelolaan keuangan negara, maka pemerintah
melaksanakan sebuah proyek penyempurnaan manajemen keuangan dan administrasi
penerimaan pemerintah yang dikenal dengan nama Government Financial Management
and Revenue Administration Project (GFMRAP). GFMRAP meliputi 4 bidang besar, yaitu
Manajemen Keuangan Publik, Administrasi Pendapatan, Tata kelola dan Akuntabilitas, dan
Tata kelola Proyek dan Implementasi.
Dalam bidang Manajemen Keuangan Publik, perubahan yang terbesar adalah dalam hal
modernisasi anggaran dan perbendaharaan negara, yang diwujudkan dalam bentuk
implementasi SPAN. SPAN, yang merupakan singkatan dari Sistem Perbendaharaan dan
1
Anggaran Negara adalah komponen terbesar GFMRAP dan selanjutnya akan menjadi
pondasi untuk reformasi manajemen keuangan negara. SPAN akan diimplementasikan
dengan menggunakan Treasury Reference Model (TRM) atau Model Referensi
Perbendaharaan sebagai dasar atau acuan, dengan modifikasi sesuai dengan kebutuhan
Pemerintah Indonesia. TRM tersebut menggarisbawahi pentingnya integrasi pengelolaan
keuangan negara sebagai dasar bagi tata kelola dan akuntabilitas keuangan negara.
Sebagai pondasi manajemen keuangan publik, SPAN akan memfasilitasi arah kebijakan
penganggaran, mendukung
pertanggungjawaban
dari
para
pengguna
anggaran,
meningkatkan efisiensi pengelolaan perbendaharaan, memfasilitasi reformasi akuntansi
dan pelaporan, mengurangi biaya pinjaman dan memperkuat keamanan dan kredibilitas
data keuangan.
Pada dasarnya, SPAN adalah bagian dari Integrated Financial Management Information
System (IFMIS) yaitu Sistem Informasi Pengelolaan Keuangan Negara yang Terintegrasi,
sehingga pengembangan SPAN merupakan langkah awal menuju implementasi IFMIS.
IFMIS merupakan paket pengelolaan keuangan negara yang terintegrasi dan
terkomputerisasi yang dimaksudkan untuk meningkatkan efektifitas dan transparansi
dalam pengelolaan keuangan negara.
IFMIS terdiri dari beberapa unsur, mulai dari
perencanaan, penganggaran, pelaksanaan
anggaran, hingga pertanggungjawaban
keuangan negara. Dalam implementasi IFMIS tersebut, terdapat perbedaan antara satu
negara dengan negara lainnya sehingga diperlukan adaptasi atas prinsip dasar IFMIS, yaitu
integrasi pengelolaan keuangan negara, dengan prinsip dasar pengelolaan keuangan yang
merupakan ciri yang dimiliki suatu negara.
Di Indonesia, pengelolaan keuangan negara dimulai dengan adanya transaksi keuangan di
lingkup Satuan Kerja di Kementerian Negara/Lembaga. Dalam lingkup satuan kerja
tersebut, implementasi IFMIS diwujudkan dalam bentuk beberapa penyempurnaan proses
bisnis pengelolaan keuangan negara dengan menggunakan aplikasi yang terintegrasi.
Perubahan yang akan dilaksanakan meliputi penyederhanaan aplikasi yang saat ini
jumlahnya sangat banyak pada satuan kerja dengan data base yang terpisah-pisah,
2
menjadi satu aplikasi dengan data base yang terintegrasi. Penyederhanaan sistem aplikasi
ini bertujuan untuk mengurangi terjadinya duplikasi pekerjaan dan pengulangan entry
data.
Duplikasi pekerjaan dan entry data pada prakteknya seringkali menyebabkan
terjadinya perbedaan data antara satu aplikasi dengan aplikasi lainnya sehingga informasi
yang dihasilkan pun menjadi tidak akurat. Penggabungan aplikasi dan data base pada
tingkat satuan kerja akan diwujudkan dalam suatu sistem aplikasi di lingkup Satuan kerja
yang dinamakan Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI).
SAKTI yang akan dikembangkan meliputi penggabungan fungsi-fungsi dalam penyusunan
anggaran, pelaksanaan APBN, hingga penyusunan laporan keuangan. Dalam penyusunan
anggaran, fungsi yang akan digabung meliputi penyusunan RKAKL, penyusunan DIPA dan
revisi DIPA. Dalam pelaksanaan APBN, akan terdapat beberapa proses bisnis yang baru,
yaitu manajemen data supplier, manajemen data kontrak, Resume Tagihan dan Surat
Perintah Membayar. Dalam penyusunan laporan keuangan, penyempurnaan yang akan
dilakukan meliputi aplikasi akuntansi keuangan, akuntansi barang milik negara, rekonsiliasi
SAI, penyusunan LPJ bendahara, dan akuntansi persediaan.
Untuk memfasilitasi
pengiriman data dari aplikasi SAKTI yang ada di lingkup Satuan Kerja ke aplikasi SPAN yang
ada pada Kementerian Keuangan, juga dikembangkan aplikasi pendukung yang meliputi
Portal SPAN dan SPAN SMS.
SAKTI akan digunakan oleh Satuan Kerja yang tersebar di seluruh Indonesia, yang memiliki
karakteristik yang beragam, mulai dari yang memiliki fasilitas infrastruktur yang sangat
lengkap sampai dengan fasilitas infrastruktur yang sangat minim.
SAKTI merupakan
gabungan beberapa aplikasi yang akan digunakan oleh mereka yang memiliki fungsi
perbendaharaan di Satuan Kerja, seperti Kuasa Pengguna Anggaran, Pejabat Pembuat
Komitmen, dan Pejabat Penandatangan SPM, serta Bendahara dengan didasarkan pada
peran dan tupoksi masing-masing, sehingga akses terhadap aplikasi SAKTI akan diberikan
untuk mereka yang menjalankan fungsi Perbendaharaan yang berbeda-beda tersebut.
Dengan adanya aplikasi SAKTI tersebut, SAKTI memfasilitasi kewajiban penyusunan
laporan keuangan di tingkat Satuan Kerja sebagai entitas akuntansi, yaitu unit pemerintah
3
Pengguna Anggaran atau Pengguna Barang yang berkewajiban untuk menyelenggarakan
kegiatan akuntansi dan menyusun laporan keuangan untuk digabungkan pada entitas
pelaporan.
B. TUJUAN PEMBELAJARAN
Tujuan Pembelajaran Umum :
Modul SPAN dan SAKTI ini merupakan salah satu bahan ajar dalam program pelatihan yang
ditujukan untuk Satuan Kerja Kementerian Negara/Lembaga, yaitu Program Percepatan
Akuntabilitas Keuangan Pemerintah. Setelah mengikuti pelatihan ini, diharapkan peserta
mampu:
1. Memperoleh pemahaman tentang arah pengembangan dalam reformasi pengelolaan
keuangan negara baik ditingkat Bendahara Umum Negara maupun pada tingkat satuan
kerja/Kuasa Pengguna Anggaran.
2. Mengimplementasikan
pemahaman
tersebut
dalam
melakukan
persiapan
menyongsong implementasi SPAN pada masing-masing satuan kerja di lingkungan
Kementerian/Lembaga dan Bendahara Umum Negara (BUN).
Selain tujuan umu sebagaimana tersebut di atas, tujuan pembelajaran khusus yang
diharapkan dari peserta setelah mengikuti pelatihan ini adalah
1. Memahami visi dan misi dalam SPAN;
2. Memahami latar belakang dan strategi SPAN;
3. Memahami SPAN dan kaitannya dengan siklus pengelolaan keuangan pemerintah;
4. Memahami perkembangan SPAN terkini;
5. Memahami ruang lingkup SAKTI;
6. Memahami karakteristik SAKTI;
7. Memahami desain struktur SPAN dan SAKTI;
8. Memahami koneksitas SPAN dan SAKTI;
9. Memahami proses bisnis SPAN dan SAKTI;
10. Memahami persiapan-persiapan yang diperlukan menyongsong implementasi SPAN
dan SAKTI.
4
C. SISTEMATIKA DAN RUANG LINGKUP
Modul ini disusun dengan sistematika dasar menjelaskan definisi SPAN dan SAKTI,
bagaimana penyempurnaan yang dilakukan dalam SPAN dan SAKTI, pihak yang terkait
dengan implementasi SPAN dan SAKTI, kapan implementasi SPAN dan SAKTI akan
dilaksanakan, keunggulan SPAN dan SAKTI kepada penggunanya, proses bisnis
penganggaran, pelaksanaan anggaran dan pertanggungjawaban pada SPAN dan SAKTI
serta persiapan Satuan Kerja dalam menyongsong implementasi SPAN dan SAKTI.
D. METODE PEMBELAJARAN
Metode pembelajaran dalam pelatihan ini dilakukan dengan cara pemaparan konsep dan
teori oleh fasilitator yang diikuti sesi tanya jawab dan diskusi. Keberhasilan proses
pembelajaran ini sangat tergantung kepada partisipasi aktif dari seluruh peserta pelatihan
dalam diskusi dan tanya jawab.
5
BAB II
GAMBARAN UMUM
A. SISTEM PERBENDAHARAAN DAN ANGGARAN NEGARA (SPAN)
1. Latar Belakang Strategis
Pemerintah Indonesia melalui Kementerian Keuangan melakukan Reformasi Manajemen
Keuangan Negara yang dimulai sejak tahun 2003. Sebagai langkah awal dalam perwujudan
reformasi tersebut, maka dibentuklah program Government Financial Management and
Revenue Administration Project (GFMRAP). Tujuan dari program GFMRAP adalah untuk
memperkuat efisiensi dan integritas dalam manajemen keuangan negara dan administrasi
pendapatan, terutama melalui penguatan tatakelola, akuntabilitas dan transparansi
keuangan negara.
Program reformasi keuangan negara berupa program GFMRAP diwujudkan dalam bentuk
modernisasi anggaran dan perbendaharaan negara. Modernisasi anggaran dan
perbendaharaan tersebut diimplementasikan dalam bentuk Sistem Perbendaharaan dan
Anggaran Negara (SPAN). SPAN merupakan suatu sistem pengelolaan keuangan negara
yang mengintegrasikan pengelolaan keuangan ke dalam satu sistem terintegrasi, yang
meliputi fungsi penganggaran, pelaksanaan anggaran dan pertanggungjawaban keuangan
negara. SPAN merupakan program transformasi berskala besar di bidang keuangan negara
yang bertujuan meningkatkan efisiensi, efektivitas, akuntabilitas dan transparansi dalam
pengelolaan anggaran dan perbendaharaan negara melalui penyempurnaan proses bisnis
dan pemanfaatan teknologi informasi yang terintegrasi.
Dengan adanya SPAN, maka fungsi-fungsi pengelolaan keuangan yang ada pada beberapa
unit yang berbeda seperti perencanaan dan penganggaran di Direktorat Jenderal Anggaran
(DJA), manajemen DIPA dan pembayaran serta penyusunan laporan keuangan di
Direktorat Jenderal Perbendaharaan (DJPB) dan fasilitasi dukungan teknologi informasi di
6
Pusat Sistem Informasi dan Teknologi Keuangan (Pusintek) dapat terintegrasi ke dalam
suatu sistem yang sama.
Dengan mengacu pada Model Referensi Perbendaharaan yang digunakan di beberapa
negara,
SPAN
memfasilitasi
arah
kebijakan
penganggaran,
mendukung
pertanggungjawaban dari para pengguna anggaran, meningkatkan efisiensi pengelolaan
perbendaharaan, memfasilitasi reformasi akuntansi dan pelaporan, mengurangi biaya
pinjaman dan memperkuat keamanan dan kredibilitas data keuangan.
Implementasi SPAN yang merupakan bagian dari Program Reformasi Pengganggaran dan
Perbendaharaan dalam lingkup Kementerian Keuangan dilaksanakan melalui 3 (tiga)
komponen utama yaitu : reformasi Proses Bisnis, reformasi Sistem Teknologi Informasi,
dan Tata Kelola Perubahan. Dengan mendasarkan pada program tersebut, SPAN dibangun
dengan menggunakan tiga pilar, yaitu penyempurnaan proses bisnis, dukungan teknologi
informasi dan manajemen komunikasi dan perubahan.
Penyempurnaan proses bisnis dikembangkan melalui beberapa modul yang ada pada SPAN
yaitu perencanaan anggaran (Budget Preparation), manajemen DIPA (Management of
Spending Authority), Manajemen Komitmen (Commitment Management), Manajemen
Pembayaran (Payment Management), Manajemen Kas (Cash Management), Manajemen
Penerimaan (Governement Receipt), Buku Besar dan Bagan Akun Standar (General Ledger
and Chart of Account), dan Pelaporan (Reporting), serta modul SAKTI. SPAN digunakan
dalam lingkup Kementerian Keuangan selaku Bendahara Umum Negara, sedangkan SAKTI
digunakan oleh Kementerian/Lembaga selaku Pengguna Anggaran.
Penyempurnaan proses bisnis merupakan dasar dari perubahan yang didukung oleh
teknologi informasi. Selanjutnya, diperlukan perubahan pola pikir pengguna aplikasi yang
didukung oleh adanya pelatihan penggunaan aplikasi kepada para penggunanya. Dengan
adanya ketiga pilar tersebut, maka perubahan proses bisnis dapat diterima dan digunakan
oleh para penggunanya baik dalam lingkup Satuan Kerja Kementerian Negara/Lembaga
7
selaku Pengguna Anggaran ataupun Kementerian Keuangan selaku Bendahara Umum
Negara.
Selain itu, tujuan Program Reformasi Sistem Perbendaharaan dan Anggaran Negara,
adalah sebagai berikut:
a. Mengendalikan anggaran negara, asset, dan kewajiban Pemerintah Pusat;
b. Menyediakan informasi yang komprehensif, dapat dipercaya, dan tepat waktu tentang
keuangan pemerintah;
c. Memudahkan pengambilan keputusan dalam manajemen keuangan pemerintah.
Dengan mendasarkan pada tujuan seperti yang tercantum di atas, maka sasaran yang ingin
dicapai dengan adanya implementasi SPAN meliputi :
a. Otomasi proses operasional penganggaran dan pegelolaan kas, asset dan utang
pemerintah;
b. Peningkatan keandalan proses penganggaran dan pengelolaan kas, asset dan utang
pemerintah;
c. Peningkatan efisiensi layanan kepada kementrian Negara/lembaga, masyarakat dan
perbankan;
d. Peningkatan akuntabilitas melalui penyusunan dan penyajian laporan keuangan yang
lebih komprehensif, akurat dan tepat waktu;
e. Penyediaan fasilitas rekonsiliasi yang andal, akurat, serta tepat waktu antara
pemerintah dan perbankan;
f. Penyediaan jejak audit (audit trail) untuk memfasilitasi proses audit akun pemerintah;
g. Mengintegrasikan data pada berbagai subsistem manajemen keuangan pemerintah.
Dengan adanya sasaran yang jelas, maka manfaat yang ingin dicapai dengan adanya
implementasi SPAN adalah :
a. Tersedianya sistem pengendalian alokasi dan pelaksanaan anggaran yang efektif;
b. Tersedianya sistem pengelolaan kas yang terpercaya;
8
c. Tersedianya sistem pelaporan manajerial tentang tentang operasi keuangan pemerintah
yang komprehensif, dapat diandalkan dan realtime;
d. Terwujudnya tahapan transisi penerapan sistem akuntansi dari berbasis kas ke berbasis
akrual, dan;
e. Terlaksananya pelayanan kepada public yang lebih efisien.
Dengan adanya kejelasan tujuan, sasaran dan manfaat dari pelaksanaan reformasi
pengelolaan keuangan Negara melalui SPAN, program SPAN dapat menghasilkan output
berupa sistem pengelolaan keuangan Negara yang dapat mewujudkan pengelolaan
keuangan Negara yang professional, transparan, dan akuntabel sebagaimana amanat
Undang-Undang Keuangan Negara.
2. Visi dan Misi
Visi SPAN adalah “Terwujudnya pengelolaan dan pertanggungjawaban keuangan Negara
yang transparan dan akuntabel, aman dan mudah diterapkan dengan dukungan system
informasi manajemen keuangan yang terintegrasi “. Untuk mewujudkan visi tersebut,
SPAN mempunyai misi. Misi SPAN adalah sebagai berikut :
a. Mengembangkan proses bisnis secara berkelanjutan dengan mendasarkan pada
praktek penyelenggaraan yang sesuai dan terbaik.
b. Menerapkan paket solusi yang terintegrasi untuk mendukung system yang aman,
akurat dan handal.
c. Memastikan diterimanya perubahan oleh pemangku kepentingan dan memberikan
solusi lengkap terhadap dampak perubahan.
Untuk mendukung visi dan misi SPAN, maka motto yang digunakan adalah “dengan SPAN
banyak hal bisa diselesaikan”.
3. Manfaat
Sistem Perbendaharaan dan Anggaran Negara (SPAN) merupakan sistem yang
mengintegrasikan data dari siklus pengelolaan keuangan Negara, yang dimulai dari
penyusunan anggaran sampai dengan pelaporan yang akan membawa perubahan
9
terhadap prosedur kerja, sistem aplikasi yang dipergunakan dan organisasi ke arah yang
lebih baik. Dengan mendasarkan pada manfaat tersebut, maka manfaat dari SPAN dapat
diuraikan sebagai berikut:
1. Integrasi data
Data yang ada di SPAN merupakan satu-satunya data yang dipergunakan untuk
berbagai kebutuhan. Data hanya dilakukan satu kali entry dan data yang terkumpul
secara terpusat.
2. Secara online
Siapa pun yang memiliki akses terhadap data tersebut dapat mengambil data tersebut
dari mana pun, dengan terhubung dengan internet.
3. Perubahan prosedur kerja
Adanya penyempurnaan mekanisme kerja yang menyederhanakan proses bisnis yang
ada.
4. Perubahan sistem aplikasi
Adanya penyempurnaan sistem aplikasi dengan penggunaan aplikasi yang terintegrasi.
5. Perubahan organisasi
Adanya penyempurnaan proses bisnis dan aplikasi, maka akan berdampak pada
penyempurnaan organisasi, baik secara struktur maupun sumber daya manusia (SDM).
Dengan didasarkan pada penyempurnaan proses bisnis, maka proses bisnis pada SPAN
dapat dikelompokkan dalam tiga proses yaitu :
a. Penganggaran, yang terdiri atas Penyusunan Anggaran dan Manajemen DIPA
b. Pelaksanaan Anggaran, yang terdiri dari :
i. Manajemen Komitmen
ii. Manajemen Pembayaran
iii. Manajemen Penerimaan
iv. Manajemen Kas
c. Pertanggungjawaban, terdiri atas :
10
i. Akuntansi
ii. Pelaporan
4. Pilar Utama
Terdapat 3 (tiga) pilar dalam pengembangan SPAN, yaitu :
a. Penyempurnaan dan Perbaikan Proses Bisnis
Penelahaan dan perbaikan Model Referensi Perbendaharaan yang mengacu pada praktekpraktek yang digunakan di negara lain dengan modifikasi kesesuaian pada Kementerian
Keuangan. Hal ini bertujuan menyelaraskan antara proses bisnis penganggaran hingga
pertanggungjawaban agar menjadi landasan untuk pelaksanaan Commercial Off The Shelf
(COTS) solution SPAN
b. Teknologi Informasi
Solusi COTS (Commercial Off The Shelf) menfasilitasi dan mengotomasi implementasi
Model Referensi Perbendaharaan. Program aplikasi berbasis COTS adalah program aplikasi
yang dibuat secara khusus oleh perusahaan penyedia software berdasarkan ‘best practices
of business process’ pada bidang bersangkutan, sehingga program aplikasi tersebut dapat
digunakan secara umum oleh semua institusi untuk menangani bidang bersangkutan.
Dalam pengelolaan keuangan, salah satu contoh COTS adalah Oracle E Business Suite, yaitu
software berbasis Oracle yang dapat diaplikasikan secara umum oleh banyak institusi
untuk menangani pengelolaan keuangan.
c. Manajemen Perubahan dan Komunikasi (CMC)
Merupakan upaya untuk mempersiapkan organisasi dan sumber daya manusia untuk
menerima cara berpikir (mindset) dan prosedur kerja baru. Kegiatan manajemen
perubahan dan komunikasi SPAN meliputi:
i. Menganalisa dampak terhadap organisasi dan SDM yang diakibatkan perubahan dalam
bisnis proses dan IT karena diterapkannya SPAN.
11
ii. Mengidentifikasi tingkat kesiapan dari organisasi (DJPBN, DJA dan Pusintek) serta K/L
yang terpilih sebagai pilot project untuk menghadapi perubahan dalam tiap tahapan
SPAN dan memastikan persiapan yang diperlukan dilaksanakan.
iii. Meningkatkan kemampuan para change agent melalui pelatihan.
iv. Mempersiapkan strategi pengelolaan perubahan dan komunikasi serta rencana kerja
yang komprehensif.
v. Mengidentifikasi risiko perubahan dan mempersiapkan rencana mitigasi terhadap
kemungkinan risiko tersebut.
vi. Mempersiapkan pelatihan dan workshop yang dibutuhkan untuk mendukung
pelaksanaan SPAN.
5. Organisasi dan Ruang Lingkup
Pihak-pihak yang terlibat dalam pengembangan SPAN dalam Kementerian Keuangan
adalah Sekretariat Jenderal Kementerian Keuangan, Direktorat Jenderal Anggaran dan
Direktorat Jenderal Perbendaharaan. Cakupan pengguna SPAN ada pada Direktorat
Jenderal Perbendaharaan (DJPBN), Direktorat Jenderal Anggaran (DJA), Pusat Informasi
dan Teknologi Keuangan (Pusintek) Sekretariat Kementrian Keuangan, Satuan Kerja yang
berjumlah lebih dari 25 ribu, Unit Eselon I yang terkait dengan BA 999, Bank Indonesia/
Perbankan, dan pihak-pihak sebagai pengguna database SPAN.
Gambar 1.1. menunjukkan struktur organisasi SPAN dari Menteri Keuangan sampai dengan
unit yang bertanggung jawab yang ada di Direktorat Transformasi Perbendaharaan. Unit ini
berkoordinasi dengan Project Support and Service Unit (PSSU), sebagai suatu organisasi di
bawah Sekretariat Jenderal Kementerian Keuangan, yang bertugas memantau
perkembangan program dan juga bertugas sebagai penghubung antara pihak Kementerian
Keuangan dengan pihak Bank Dunia.
Para pemangku kepentingan/stakeholders dari SPAN adalah unit yang termasuk dalam
struktur organisasi SPAN, yaitu Menteri Keuangan, Sekretariat Jenderal Kementerian
Keuangan/Pusintek, DJA beserta unit di bawahnya, DJPB beserta unit di bawahnya. Selain
12
stakeholder yang ada di dalam susunan struktur organisasi SPAN, masih ada Satuan Kerja
(SatKer), unit eselon I lain yang terkait dengan Bagian Anggaran (BA) 999, Bank Indonesia
dan Perbankan serta pihak-pihak sebagai pengguna database SPAN. Unit yang ada di
bawah DJA, DJPB dan unit eselon I terkait BA 999 disebut sebagai business owner, artinya
mereka yang selama menjalankan proses bisnis sehingga proses bisnis yang sedang
dikembangkan oleh SPAN nantinya akan dijalankan oleh masing-masing business owner
tersebut.
Project
Sponsorship
Minister of Finance
DG Treasury
Secretary
General
DG Budget
Project
Ownership
Treasury
Transformation
PUSINTEK
Budget Systems
Project
Execution
Tim RPPN
Tim Koordinasi
Teknis SPAN
Business Process
DG Treasury
Change Mgt
DG Treasury
SPAN Contractor
IVV Services
FM & BPI Consultancy
Change management
& Comms Consultancy
Other Advisor(s) &
Consultans
Business Process
DG Budget
Change Mgt
DG Budget
IT
IT
IT
DG Treasury
Pusintek
DG Budget
Sekretariat/ Treasury
PIU
PSSU
Gambar 1.1. Struktur Organisasi SPAN
B. SISTEM APLIKASI KEUANGAN TINGKAT INSTANSI (SAKTI)
1. Latar Belakang
Reformasi dalam bidang keuangan terutama dalam hal penyediaan Laporan Keuangan
yang akurat selalu menjadi perhatian bagi Kementerian Keuangan khususnya Ditjen
Perbendaharaan. Kenyataan bahwa meningkatnya opini BPK untuk Laporan Keuangan
Pemerintah Pusat (LKPP) menjadi “Wajar Dengan Pengecualian” (WDP) pada 2009 menjadi
13
cambuk bagi Kementerian Keuangan dan Kementerian/Lembaga untuk meraih opini lebih
tinggi yaitu Wajar Tanpa Pengeculian. Reformasi yang terus dilakukan salah satunya adalah
dengan melakukan perbaikan baik dari segi proses bisnis maupun teknologi informasi. Dari
sisi teknologi informasi, telah dipersiapkan suatu sistem baru di dalam pengelolaan
keuangan negara yang akan mengacu pada penyempurnaan proses bisnis yang akan
ditetapkan. Sebagai dasar dan arahan dalam reformasi keuangan tersebut, dibentuklah
Program Reformasi Penganggaran dan Perbendaharaan Negara.
Program Reformasi Penganggaran dan Perbendaharaan Negara yang diwujudkan melalui
implementasi SPAN tidak akan terlepas dari sistem keuangan yang ada pada Satuan kerja
(Satker). Satker merupakan unit terkecil dalam lingkup Kementerian Negara/Lembaga yang
melakukan pengelolaan dana APBN dalam rangka melaksanakan pembangunan Nasional
melalui DIPA. Dengan demikan, penyempurnaan aplikasi keuangan SATKER harus sesuai
dengan aplikasi SPAN mengingat kualitas data SPAN sangat bergantung pada kemampuan
Sistem Aplikasi Keuangan di Satker yang akan dikembangkan.
Saat ini terdapat dua Eselon I Kementerian Keuangan yang mendistribusikan beberapa
aplikasi ke Satker. Pertama, Direktorat Jenderal Perbendaharaan yang mendistribusikan
aplikasi-aplikasi dibagi ke dalam dua kelompok besar yaitu Pelaksanaan (Aplikasi SPM, Gaji,
dan Perencanaan Kas) dan Pelaporan (Aplikasi SAK, SIMAK BMN, dan Persediaan). Masingmasing aplikasi tersebut bersifat terpisah (stand alone) dan memiliki database terpisah,
namun interakasi data baik input maupun outputnya saling berkaitan satu sama lain.
Kedua, Direktorat Jenderal Anggaran, yang mendistribusikan Aplikasi RKAKL DIPA. Aplikasi
ini juga bersifat stand alone dan memiliki database terpisah. Dengan demikian sejalan
dengan usaha untuk menyelaraskan aplikasi-aplikasi Satker agar sesuai dengan SPAN,
perlu juga dilakukan pengintegrasian aplikasi-aplikasi di atas ke dalam satu aplikasi Satker
yang terintegrasi dengan data base yang tersentralisasi. Hal ini dimungkinkan karena
kebutuhan penggabungan tersebut akan memudahkan Satker dalam menggunakan dan
meningkatkan akurasi data transaksi keuangannya.
14
Dalam lingkup Satuan Kerja, perubahan yang akan dilaksanakan meliputi penyederhanaan
aplikasi yang sangat banyak pada satuan kerja dengan database yang terpisah-pisah,
menjadi satu aplikasi dengan data base yang terintegrasi. Penyederhanaan sistem aplikasi
ini untuk mengurangi terjadinya duplikasi pekerjaan dan pengulangan entry data.
Duplikasi pekerjaan dan entry data seringkali menyebabkan terjadinya perbedaan data
antara satu aplikasi dengan aplikasi lainnya sehingga informasi yang dihasilkan pun
menjadi tidak akurat. Penggabungan aplikasi dan database pada tingkat satuan kerja akan
diwujudkan dalam suatu Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI).
SAKTI meliputi seluruh proses pengelolaan keuangan negara pada Satker dimulai dari
proses penganggaran, pelaksanaan anggaran dan pelaporan keuangan.
SAKTI akan
digunakan oleh satuan kerja yang tersebar di seluruh Indonesia yang memiliki karakteristik
yang beragam, mulai dari yang memiliki fasilitas infrastruktur dan teknologi informasi yang
sangat lengkap sampai dengan fasilitas yang sangat minim. SAKTI merupakan gabungan
beberapa aplikasi yang keberadaan sebelumnya tersebar pada beberapa kewenangan,
seperti bendahara, KPB, PPK, dan PPSPM. Dengan adanya Sakti, maka Satker difasilitasi
untuk menyusun laporan keuangan tingkat Satker.
Dalam penyusunan anggaran, fungsi yang akan digabung meliputi penyusunan RKAKL,
penyusunan DIPA dan revisi DIPA. Dalam pelaksanaan anggaran, akan dikenal beberapa
proses bisnis yang baru, yaitu manajemen data supplier, manajemen data kontrak, Resume
Tagihan dan Surat Perintah Membayar.
Dalam penyusunan laporan keuangan,
penyempurnaan yang akan dilakukan meliputi aplikasi akuntansi keuangan, akuntansi
barang milik negara, rekonsiliasi SAI, penyusunan LPJ bendahara, dan akuntansi
persediaan, penyusutan dan pelaporan akuntansi berbasis akrual. Selain aplikasi SAKTI,
juga akan dikembangkan aplikasi pendukung yang meliputi Portal SPAN dan SPAN SMS.
Portal SPAN merupakan aplikasi berbasis web yang memfasilitasi SATKER dalam mengirim
dan menerima Arsip Data Komputer (ADK) dari/atau ke SPAN, sehingga SATKER dapat
menghemat waktunya untuk tidak perlu ke KPPN. Sedangkan SPAN-SMS merupakan
aplikasi yang dapat dipergunakan SATKER dalam memonitor data keuangannya. SATKER
15
cukup mengirimkan SMS dengan format tertentu ke SPAN-SMS Service, yang dalam waktu
tidak terlalu lama mengatahui status data keuangannya. Aplikasi Portal SPAN dan SPANSMS tersebut akan ditempatkan pada Kantor Pusat Ditjen Perbendaharaan.
Dengan beroperasinya aplikasi Satker dan aplikasi–aplikasi pendukungnya, diharapkan
dapat meningkatkan pelayanan Kementerian Keuangan terhadap Satker dan Satker dapat
menyajikan laporan keuangannya secara akurat, transparan dan bertanggungjawab.
Pengembangan aplikasi-aplikasi tersebut akan dilakukan dengan memanfaatkan pihak
ketiga yang akan mengembangkannya sesuai dengan kebutuhan pengguna atau dikenal
dengan software requirement specification (SRS) yang disusun oleh Direktorat Tranformasi
Perbendaharaan sebagai salah satu unit di lingkut Ditjen Perbendaharaan.
2. Ruang Lingkup
Ruang lingkup pekerjaan pengembangan aplikasi ini mencakup 3 (tiga) pekerjaan utama,
yaitu Sistem Aplikasi Keuangan Tingkat Instansi, Aplikasi Portal dan Aplikasi SMS Gateway.
Idealnya, pengembangan aplikasi SPAN diarahkan agar dapat diakses oleh seluruh satuan
kerja dari seluruh kementerian dan lembaga. Akan tetapi, pengembangan jaringan sistem
informasi dengan melibatkan satuan kerja yang mencapai lebih dari 24 ribu satuan kerja
tentu membutuhkan ketersediaan infrastruktur yang sangat besar. Selain itu, penggunaan
aplikasi untuk pengguna yang sangat banyak, tentu saja membutuhkan investasi yang
sangat besar, terutama dalam hal lisensi penggunaan aplikasi yang akan membutuhkan
biaya sangat besar.
Berdasarkan pertimbangan tersebut, maka dikembangkanlah aplikasi SAKTI yang pada
dasarnya merupakan aplikasi SPAN mini. Hal ini disebabkan adanya prinsip mirror berupa
kesesuaian antara aplikasi SAKTI dan SPAN yang bertujuan agar aplikasi SAKTI dan SPAN
tidak mengalami kesulitan dalam transfer data antar aplikasi.
Aplikasi SAKTI menjadi jawaban terhadap tantangan dalam reformasi pengelolaan
keuangan publik, namun dengan tetap memperhatikan kapasitas jaringan infrastruktur
16
pada satuan kerja sehingga aplikasi tersebut tetap efektif namun efisien. Sedangkan untuk
meningkatkan kualitas pelayanan dan memberi kemudahan kepada satuan kerja, maka
dikembangkan pula Aplikasi Portal SPAN dan Aplikasi SMS Gateway. Ketiga aplikasi yang
dikembangkan tersebut merupakan satu kesatuan dan menjadi bagian dari reformasi
pengelolaan keuangan sektor publik pada tingkat satuan kerja.
Dengan demikian fasilitas pengiriman, konfirmasi, dan pengambilan data dapat dilakukan
melalui kurir, ekspedisi, internet dan SMS. Proses pengiriman data kontrak, Supplier,
resume tagihan dapat dilakukan tidak hanya dengan dokumen namun juga secara
elektronik dan pengurangan penggunaan kertas.
Sejalan dengan fasilitas pengiriman tersebut, aplikasi SAKTI juga memfasilitasi beragam
Satker. Menurut jenisnya, Satker terdiri atas 3 kelompok utama, yaitu Satker biasa, Satker
Bendahara Umum Negara (BUN) dan Satker Badan Layanan Umum (BLU). Satker BUN tidak
masuk dalam cakupan SAKTI mengingat Satker BUN sudah terintegrasi dengan dan akan
menggunakan SPAN. Tetapi, khusus untuk Satker BUN Belanja Subsidi dan Belanja Lainnya
akan menggunakan SAKTI dengan pertimbangan jumlah Satker yang relatif lebih banyak
dari BUN yang lain.
3. Komponen
Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI) mencakup seluruh proses pengelolaan
keuangan negara pada Satker dimulai dari proses Penganggaran, Pelaksanaan, sampai
dengan Pelaporan. Masing-masing proses pengelolaan keuangan diperankan oleh modulmodul aplikasi sebagai berikut:
a. Proses penganggaran diperankan oleh modul Penganggaran.
b. Proses pelaksanaan diperankan oleh beberapa modul, yaitu modul Komitmen, modul
Bendahara, dan modul Pembayaran.
c. Proses akuntansi pelaporan diperankan oleh modul Aset Tetap, modul Persediaan,
modul GL dan Pelaporan.
d. Pengelolaan referensi yang diperankan oleh modul administrasi
17
Untuk berkomunikasi dengan SPAN, perlu dibuat aplikasi-aplikasi pendukung sebagai
media untuk mengirimkan, menerima, dan memonitor data transaksi keuangan, yaitu
modul Portal dan SMS Gateway. Secara garis besar, gambar Sistem Aplikasi Keuangan
Tingkat Instansi dan model integrasinya serta interkoneksi dengan SPAN dapat dilihat pada
Gambar 2.2.
Gambar 2.2. Garis Besar Flow Sistem Aplikasi Keuangan Tingkat Instansi
Terkait dengan hierarki organisasi, beberapa Satker mempunyai fungsi tambahan sebagai
koordinator pengumpul data (data pooling centre). Satker tersebut akan mengonsolidasi
data tersebut dan mengirimkannya ke level di atasnya (tingkat eselon I atau kementerian/
18
lembaga). Data tersebut meliputi data general ledger (GL) hasil rekonsiliasi Satker-KPPN
dan data konsolidasi kertas kerja RKAKL dan data Aset tetap.
C. Koneksitas SPAN dan SAKTI
Satuan Kerja tidak dapat mengakses sistem SPAN secara langsung, melainkan dengan
menggunakan interkoneksi antara aplikasi SAKTI dengan aplikasi SPAN. Sebagai sebuah
aplikasi SPAN mini, Aplikasi SAKTI pada satuan kerja akan terhubung dengan aplikasi SPAN
pada KPPN dengan menggunakan beberapa metode, baik dengan menggunakan ADK
seperti yang telah dilaksanakan selama ini, dengan dikirim oleh kurir maupun ekspedisi,
atau melalui jaringan internet.
Untuk memperlancar koneksitas Aplikasi Satker, maka perlu dibuat aplikasi-aplikasi
pendukung yang bertujuan memudahkan SATKER dalam mengirimkan dan memonitor
data transaksi keuangannya. Beberapa aplikasi pendukung yang dibutuhkan antara lain
Portal SPAN dan SPAN-SMS Service. Secara umum koneksitas ketiga aplikasi di atas dengan
SPAN dapat digambarkan dalam Gambar 2.3.
Dengan demikian fasilitas pengiriman, konfirmasi, dan pengambilan data dapat dilakukan
melalui kurir, ekspedisi, internet dan SMS. Kemudahan-kemudahan yang ditawarkan oleh
SAKTI dalam berkoneksi dengan SPAN bersifat optional dalam arti satuan kerja yang
berada di daerah terpencil dan memiliki hambatan dalam komunikasi internet, tetap diberi
kesempatan untuk melakukan interaksi dengan KPPN melalui cara dan sistem lama.
19
Gambar 2.3. Interaksi SAKTI dengan SPAN
20
1. Portal SPAN
Portal SPAN merupakan aplikasi berbasis web yang mendukung Sistem Aplikasi Keuangan
Tingkat Instansi dimana ADK dapat dikirimkan ke portal SPAN melalui media internet.
Penentuan keputusan Subdit TSA, Ditjen Perbendaharaan dalam membuat Portal SPAN ini
didasarkan pada karakteristik, lokasi, kondisi sarana dan prasarana SATKER yang beragam.
Pengguna dapat memanfaatkan fasilitas portal ini setelah terlebih dahulu melakukan login
dengan memasukkan nama user dan password yang sudah terdaftar.
Arsitektur Komunikasi Data
Antara Aplikasi Satker dan SPAN Melalui Portal
Aplikasi Satuan Kerja
SPAN
KPPN
Portal SPAN
Application
Firewall
Modem
Internet
Router
Portal
N
VP
Internet
Network
Membuka Portal
dgn Login KPPN
Firewall
Browser
Portal
Server
Operator
di KPPN
Membuka Browser
Akses dengan Login satker
Membuka Aplikasi
SPAN dgn Login FO
Portal SPAN
Application
Operator di
SATKER
Firewall
VPN
SPAN
Server
Firewall
Router
SPAN
Gambar 2.4. Arsitektur Aplikasi Portal SPAN
Beberapa pengguna yang akan memanfaatkan aplikasi ini antara lain:
a. Satker
Satker memanfaatkan aplikasi ini untuk :
- meng-upload data RKAKL satker, data DIPA, data RFC, data resume tagihan, data
SPM, dan data rekonsiliasi. Khusus untuk pengumpulan data RKAKL, Portal SPAN
akan menyediakan link khusus;
- mengunduh nomor register supplier, CAN, nomor register invoice, nomor SP2D,
data supplier, nomor register supplier, dan hasil rekonsiliasi beserta berita
acaranyadan data referensi.
21
- Selain itu, Portal SPAN akan menyediakan link ke Service Desk untuk memfasilitasi
satker menyampaikan gangguan atas AplikasiSatker.
b. KPPN
- Meng-upload data hasil rekonsiliasi beserta berita acaranya ;
- mengkonfirmasi penolakan terhadap data RFC, data supplier, dan data resume
tagihan.
c. Kantor Pusat Ditjen Perbendaharaan (Admin SPAN)
Untuk keamanan, admin Portal SPAN akan di-handle Kantor Pusat Direktorat
Perbendaharaan. Admin Portal juga bertugas :
- Memelihara konten Portal SPAN;
- Memonitor Portal SPAN dari serangan hacker, virus, malware, dan hal lainnya yang
akan mengganggu operasional Portal SPAN;
- Meng-upload update data referensi dan memberikan informasi tersebut melalui
Portal SPAN;
- Mengumpulkan saran-saran yang disampaikan melalui SPAN-SMS untuk di kaji
pihak-pihak yang berkepentingan lebih lanjut.
Secara teknis Portal SPAN harus mempunyai beberapa hal penting yang harus
diperhatikan, antara lain:
a. Memiliki tingkat keamanan data yang mamadai, seperti :
b. Penggunaan captcha setiap transaksi;
c. Tidak diperkenankan penggunaan multi session ;
d. Adanya end session secara otomatis apabila aplikasi idle dalam jangka waktu 2 menit;
e. Interface aplikasi harus menarik dan user friendly;
f. Adanya koneksitas dengan database SPAN-SMS terkait dengan pengiriman data melalui
SMS;
g. Adanya koneksitas dengan Database SPAN terkait dengan data transaksi yang diupload
melalui Portal SPAN dan sinkronisasi data OLAP Database SPAN terkait dengan data
yang akan diunduh oleh Satker.
22
2. SPAN-SMS Gateway
Selain melalui Portal SPAN, fasilitas lain yang disediakan untuk pengiriman data yaitu
melalui SMS. SPAN-SMS merupakan aplikasi yang dapat dipergunakan Satker dalam
memonitor data keuangannya. SATKER cukup mengirimkan SMS dengan format tertentu
ke SPAN-SMS Service, yang dalam waktu tidak terlalu lama mengatahui status data
keuangannya. Aplikasi Portal SPAN dan SPAN-SMS gateway akan ditempatkan pada Kantor
Pusat Ditjen Perbendaharaan.
Arsitektur Komunikasi Data
Antara Aplikasi Satker dan SPAN Melalui SMS Gateway
Mobile Network
Operator
Aplikasi Satuan Kerja
SMS
Gateway
Satker
SPAN
Langsung
Kirim dari
Komputer
SMS Gateway
SPAN
Application
GSM/CDMA
Modem Instaled
To Computer
Satker
Application
Menu Kirim
Lewat SMS
SMS Gateway
SPAN
Ketik
Manual
Database
SMS
Gateway
Portal
SPAN
Notification
HP
Database
Portal
SPAN
Database
Aplikasi Satker
SPAN
Server
Gambar 1.5. Arsitektur Aplikasi SPAN-SMS Service
Permintaan yang diterima melalui SMS, akan direspon secara cepat. Keuntungan
penggunaan SMS adalah SMS lebih sederhana, pengiriman SMS lebih cepat, dan sangat
populer di masyarakat. Sedangkan kelemahannya adalah mempunyai keterbatasan
karakter huruf/ angka, sehingga penggunaan SPAN-SMS lebih diutamakan untuk proses
konfirmasi, ketimbang transaksi dimana user harus teregistrasi terlebih dahulu.
Satu-satunya transaksi yang dapat di-cover dengan aplikasi ini adalah data SPM. Kendala
yang timbul adalah sampai dengan saat ini SPM lebih menggunakan dokumen sebagai
23
dasar pencairan dana ketimbang data elektronis SPM. Dengan demikian, implementasi
pengiriman data SPM melalui SMS belum bisa dilakukan saat ini hingga peraturan yang
mendasarinya disetujui. Selanjutnya untuk pengembangan aplikasinya, fasilitas pengiriman
data SPM tetap disertakan untuk mengantisipasi kebutuhan ke depan.
Berikut beberapa transaksi yang dapat dilakukan melalui fasilitas SPAN-SMS:
a. Konfirmasi Register Supplier;
b. Konfirmasi nomor Nomor Register Kontrak;
c. Konfirmasi nomor Invoice;
d. Konfirmasi status SPM yang diajukan;
e. Konfirmasi SP2D;
f. Transaksi data SPM;
g. Pengecekan sisa pagu;
h. Pembatalan Invoice;
i.
Menyampaikan saran.
Untuk memperlancar koneksitas Aplikasi Satker, maka perlu dibuat aplikasi-aplikasi
pendukung yang bertujuan memudahkan Satker dalam mengirimkan dan memonitor data
transaksi keuangannya. Beberapa aplikasi pendukung yang dibutuhkan antara lain: Portal
SPAN dan SPAN-SMS Service. Portal SPAN merupakan Aplikasi berbasis web yang
memfasilitasi SATKER dalam mengirim dan menerima Arsip Data Komputer (ADK) dari atau
ke SPAN, sehingga Satker dapat menghemat waktunya untuk tidak perlu ke KPPN.
24
BAB III
PROSES BISNIS SPAN DAN SAKTI
A. PENGANGGARAN
1.
Pengertian dan Konsep Dasar
SPAN adalah proyek jangka panjang yang menempatkan Direktorat Jenderal
Perbendaharaan dan Direktorat Jenderal Anggaran sebagai leading institutions, meliputi
pembangunan sistem perbendaharaan dan anggaran negara yang sesuai dengan best
practices yang diharapkan, dengan didukung oleh sistem informasi yang modern, baik yang
terkait dengan software maupun hardware, melibatkan dan menghubungkan sistem
informasi perbendaharaan dan anggaran di beberapa Eselon I di Departemen Keuangan,
lima kementerian/lembaga negara di pusat, DPR, seluruh KPPN dan institusi pemerintah
lainnya yang ditetapkan.
Sistem pelaksanaan anggaran harus memenuhi sasaran dari Manajemen Keuangan Publik
yaitu pengawasan pengeluaran secara menyeluruh, alokasi strategis dan efisiensi
pelaksanaan. Dalam sistem pelaksanaan anggaran sebelumnya mengacu pada fokus pada
kepatuhan dan meyakinkan penerapan disiplin fiskal.
Perubahan dalam proses perencanaan dan pelaksanaan anggaran berpengaruh terhadap
proses penyusunan dokumen DIPA yang memuat satuan-satuan terukur yang berfungsi
sebagai dasar pelaksanaan kegiatan bagi satker dan jaminan dari BUN atas sejumlah dana
yang diperlukan bagi satker tersebut. Proses penyusunan dokumen DIPA dimulai dari
penyusunan RKAKL. DIPA adalah dokumen pelaksanaan anggaran yang disusun oleh
Pengguna Anggaran/Kuasa Pengguna Anggaran dan disahkan oleh Direktur Jenderal
Perbendaharaan atas nama Menteri Keuangan selaku Bendahara Umum Negara (BUN).
DIPA berlaku untuk satu tahun anggaran dan memuat informasi satuan-satuan terukur
yang berfungsi sebagai dasar pelaksanaan kegiatandan penggunaan anggaran. Disamping
itu, DIPA dapat dimanfaatkan sebagai alat pengendali, pelaksanaan, pelaporan,
pengawasan dan sekaligus merupakan perangkat akuntansi pemerintah. Pagu dalam DIPA
25
merupakan batas pengeluaran tertinggi yang tidak boleh dilampaui dan pelaksanaannya
harus dapat dipertanggungjawabkan.
DIPA merupakan kesatuan antara rincian rencana kerja dan penggunaan anggaran yang
disusun oleh Kementerian Negara/Lembaga dan disahkan oleh BUN. DIPA berlaku mulai
tanggal 1 januari sampai dengan 31 Desember tahun anggaran berkenaan. Dokumen
pelaksanaan anggaran yang disusun oleh Menteri/Pimpinan Lembaga dirinci menurut
sasaran yang hendak dicapai, fungsi, program dan rincian kegiatan, anggaran yang
disediakan untuk mencapai sasaran tersebut, dan rencana penarikan dana tiap-tiap satuan
kerja, serta pendapatan yang diperkirakan (UU 1/2004 Pasal 14 ayat 2 dan 3). DIPA diatur
lebih rinci yaitu menjadi fungsi/sub fungsi, program, sasaran program, rincian kegiatan/sub
kegiatan, jenis belanja, kelompok mata anggaran/akun dan rencana penarikan dana serta
perkiraan penerimaan. Konsep DIPA yang telah disusun oleh Menteri/Pimpinan Lembaga
kemudian disampaikan ke DJPB untuk ditelaah. Khusus untuk DIPA BLU harus dilampirkan
rencana kerja dan anggarannya (UU 1/2004 Pasal 14 ayat 4).
2.
Proses Bisnis Penganggaran
Proses bisnis Modul Penganggaran terdiri dari 3 aktivitas utama yaitu penyusunan RKAKL,
pengesahan DIPA, dan revisi DIPA. Ketiga proses tersebut di bagi lagi kedalam beberapa
alur kerja sesuai dengan cakupan masing-masing. Alur kerja untuk tiap-tiap bisnis proses
adalah sebagai berikut :
1. Penyusunan RKAKL
2. Pengesahan DIPA
3. Revisi DIPA
Berdasarkan Peraturan Menteri Keuangan Nomor 32 tahun 2013 mengenai tata cara revisi
anggaran tahun anggaran 2013, revisi anggaran terdiri atas:
a. Perubahan rincian anggaran yang disebabkan penambahan atau pengurangan pagu
anggaran belanja termasuk pergeseran rincian anggaran belanjanya.
b. Perubahan atau pergeseran rincian anggaran dalam hal pagu anggaran tetap; dan/atau
26
c. Perubahan/ralat karena kesalahan administrasi
2
KPA/Eselon I
-
Kanwil DJPBN
Surat Usulan Revisi
SPTJM
ADK RKA K/L DIPA Revisi
Surat Pernyataan Penggunaan
HO dan Sisa Anggaran Swakelola
- Meneliti Surat Usulan Revisi
Anggaran dan Kelengkapan
Dokumen Pendukung
3
4
N
- Surat Penolakan Revisi
Y
Revisi DIPA Setuju?
4
- Upload ke Server RKA-K/l-DIPA
1
6
5
7
KPA
Surat pengesahan revisi,
dilampiri notifikasi
Notifikasi dari sistem :
- pengesahan revisi
- Kode digital stamp yang baru
Gambar 3.1. MEKANISME PENYELESAIAN REVISI ANGGARAN PADA KANWIL DITJEN
PEBENDAHARAAN
Keterangan:
1. KPA/Eselon I menyiapkan usulan revisi anggaran yang menjadi kewenangan Kanwil
Ditjen Perbendaharaan dengan dilengkapi dokumen pendukung.
2. Kanwil Ditjen Perbendaharaan meneliti usulan revisi anggaran dan kelengkapan
dokumen pendukung.
3. Dalam hal revisi anggaran ditolak, Kanwil Ditjen Perbendaharaan akan menerbitkan
surat penolakan revisi anggaran.
4. Dalam hal revisi anggaran diterima, Kanwil Ditjen Perbendaharaan akan melakukan
upload ADK RKA-K/L DIPA ke server.
5. Setelah ADK RKA-K/L DIPA divalidasi oleh sistem, secara otomatis akan diterbitkan
notifikasi dank ode digital stamp baru sebagai tanda pengesahan revisi anggaran.
6. Kanwil Ditjen Perbendaharaan menyampaikan surat persetujuan yang dilampiri
notifikasi pengesahan revisi anggaran.
7. KPA melaksanakan kegiatan berdasarkan pengesahan revisi anggaran dari Kanwil Ditjen
Perbendaharaan.
27
3
KPA menyiapkan:
- Surat usulan Revisi
- Download ADK RKA-K/L
untuk
menyusun matriks SemulaMenjadi
- Update ADK RKA-K/L
- Dokumen Pendukung
- SPTJM
2
KPA
Y
1
DIPA Petikan
Berubah?
Melakukan Revisi Anggaran
N
3
- Update ADK RKA K/L
Cetak POK
Menetapkan POK
4
Y
KANWIL
DJPBN
Satker BLU
N
5
Eselon I
Y
N
Pagu Satker Berubah
Gambar 3.2. MEKANISME PENYELESAIAN REVISI ANGGARAN PADA KUASA PENGGUNA
ANGGARAN
Keterangan:
1. KPA melakukan revisi anggaran sesuai dengan kewenangannya.
2. KPA meneliti apakah revisi anggaran yang dilakukan KPA mengubah DIPA Petikan atau
tidak.
3. Dalam hal DIPA Petikan tidak berubah, KPA meng-update ADK RKA-K/L DIPA serta
mencetak dan menetapkan POK. Dalam hal revisi anggaran mengakibatkan perubahan
DIPA Petikan, KPA menyiapkan usulan revisi anggaran beserta dokumen pendukungnya.
4. Dalam hal satker yang direvisi merupakan satker BLU dan pagu satker tidak berubah,
Kanwil Ditjen Perbendaharaan akan langsung menyelesaikan revisi RKA-K/L DIPA.
5. Dalam hal yang direvisi bukan merupakan satker BLU dan pagu satker berubah, revisi
RKA-K/L DIPA diteruskan ke Eselon I untuk diproses lebih lanjut.
28
2
KPA
Eselon I
3
Melampirkan
- Surat Usulan Revisi
- SPTJM
- ADK RKA K/L DIPA-Revisi
- TOR dan RAB
- Surat Pernyataan Penggunaan HO
dan Sisa Anggaran Swakelola
1
- Meneliti Surat Usulan Revisi
- Mengecek Kewenangan
- Memastikan Kelengakapan
Dokumen Pendukung
Eselon I menyiapkan:
- Surat Usulan Revisi
- Update ADK RKA- K/L
- SPTJM
- Surat Pernyataan Penggunaan HO
dan Sisa Anggaran Swakelola
4
DJA
Gambar 3.3. MEKANISME PENYELESAIAN REVISI ANGGARAN PADA UNIT ESELON I
KEMENTERIAN/LEMBAGA
Keterangan:
1. KPA menyiapkan usulan revisi anggaran yang menjadi kewenangan Eselon I beserta
data pendukung.
2. Eselon I menerima usulan revisi anggaran, meneliti surat usulan, mengecek
kewenangan revisi anggaran, serta memeriksa kelengkapan dokumen pendukung.
3. Eselon I menyiapkan surat usulan revisi anggaran yang dilengkapi dokumen pendukung
sebagai dasar bagi DJA untuk mengesahkan dan meng-update sistem database.
4. Berdasarkan usulan revisi anggaran Eselon I, DJA melakukan update database RKA-K/L
DIPA dan mengesahkan revisi anggaran.
Dengan mendasarkan pada proses bisnis tersebut, maka pencatatan jurnal anggaran
didasarkan pada dokumen sumber berupa DIPA dan dokumen lain yang dipersamakan
dengan DIPA. Pada Sakti, jurnal anggaran dicatat pada modul anggaran dengan
mendasarkan pada data DIPA yang ada pada masing-masing Satker. Pencatatan jurnal
anggaran tersebut dilakukan atas akun pendapatan, belanja, transfer dan pembiayaan
sesuai dengan yang tercantum dalam DIPA dengan penyesuaian pada pola Encumbrance
accounting yang digunakan pada SPAN dan SAKTI.
29
Secara garis besar, berikut gambaran interaksi proses bisnis antara SPAN dan SAKTI :
Bisnis Proses Penganggaran SPAN – SAKTI 2013
Eselon I Satker
Satker
Penyusunan Anggaran
RUH Kertas
Kerja
Pagu Anggaran
Aktif
Kertas
Kerja
DIPA
Petikan
Revisi Anggaran
Satker
RUH Revisi
Kertas Kerja
Pagu Anggaran
Aktif
Jenis Revisi
Konsolidasi
Kertas Kerja
Cetak dan Buat
ADK RKAKL
Usulan
Kertas Kerja
Revisi
Konsolidasi
Kertas Kerja
Revisi
Menandatangani
DIPA Induk
RKAKL
DJA
DJPB
Usulan
DIPA
Revisi
DIPA
Revisi
Cetak dan Buat
ADK RKAKL
Revisi
RKAKL
Menandatangani
DIPA Induk
DJPB
Cetak DIPA
Induk
Penelahaan
RKAKL
Cetak DIPA
Petikan
Penelahaan
RKAKL
Cetak DIPA
Petikan
Penelahaan
RKAKL
DIPA
Induk
DIPA
Induk
DJA
Validasi
DIPA Induk
Approval
Proses
Cetak DIPA
Induk
Cetak SP
DIPA Induk
Approval
Proses
Validasi
DIPA Induk
Approval
Proses
Cetak DIPA
Induk
Cetak SP
DIPA Induk
Gambar 3.4. Penganggaran SPAN-SAKTI
Modul Penganggaran pada SAKTI
Pada Satker, modul penganggaran merupakan semua proses penyusunan rencana kerja
dan anggaran termasuk perencanaan realisasi anggaran bulanan dalam jangka waktu 1
(satu) tahun anggaran. Proses yang terdapat pada modul penganggaran mencakup:
1. Penyusunan Standar Biaya Kegiatan (SBK),
2. Penyusunan RKA-K/L,
3. Penyusunan DIPA, dan
4. Perencanaan Realisasi Anggaran.
Setiap user pada modul penganggaran memiliki Level user dan peran User yang akan
mempengaruhi lingkup kerja dan hak aksesnya terhadap fungsi- fungsi teknis yang
30
terdapat pada modul penganggaran. Level user yang terlibat dalam Modul penganggaran
adalah :
a. Level Satuan Kerja , sebagai pemberi usulan anggaran
b. Level Unit/ Eselon I, sebagai konsolidator
Dimana masing – masing Level user dapat menentukan peran user yang terdiri dari:
a. Operator Penganggaran : pelaksana teknis penganggaran yang melakukan fungsi teknis
atas data transaksi terkait penganggaran;
b. Checker/Validator Penganggaran: pelaksana/pejabat penganggaran yang diberikan
kewenangan dan tanggung jawab untuk memvalidasi semua proses teknis yang
dilakukan oleh operator ;
c. Approver Penganggaran: pejabat penganggaran yang diberikan kewenangan dan
tanggung jawab untuk menyetujui semua data transaksi penganggaran yang sudah
divalidasi .
Dalam penerapannya, peran user sebagai operator nantinya dapat dirangkap oleh
validator, sementara validator tidak dapat dirangkap oleh approver.
Proses penyusunan RKA-K/L terdiri dari 2 (dua) tahapan proses yaitu :
1. Tahap penyusunan Kertas Kerja di Level Satker
Pada tahap penyusunan Kertas Kerja di Level Satker, terdapat beberapa proses yang
dilalui yaitu Review Baseline, Penyusunan Kertas Kerja dan Penyusunan Rencana
Realisasi Anggaran yang dilakukan oleh user sebagai operator/ validator, kemudian
dilanjutkan dengan proses memvalidasi data Kertas kerja dan rencana realisasi
anggaran. Setelah semua data tervalidasi baru kemudian dilakukan approval oleh peran
user sebagai approver.
2. Tahap konsolidasi di Level Unit Eselon I .
Setelah Kertas Kerja dan Rencana Realisasi Anggaran tersebut diapprove di level satker,
data kertas Kerja tersebut dikirimkan ke unit Eselon I masing – masing Satker untuk
kemudian dilakukan konsolidasi Kertas Kerja menjadi RKA-K/L. Pada Level unit Eselon I ,
Kertas kerja yang sudah dikonsolidasikan, dapat direview kembali oleh Eselon I yang
juga melalui tahapan
validasi dan approval level Eselon I.
Setelah itu RKA-K/L
31
dikirimkan ke DJA Kementerian Keuangan melalui Portal untuk kemudian diproses
dalam SPAN.
Setelah dilakukan penelaahan di DJA,
RKA-K/L kemudian dijadikan dasar dalam
penyusunan Keputusan Presiden tentang Rincian Anggaran Belanja Pemerintah Pusat.
Selanjutnya
penyusunan dan pengesahan Daftar Isian Pelaksanaan Anggaran (DIPA)
dilakukan dengan berdasarkan pada Keppres RABPP yang sudah ditetapkan tersebut.
Adapun DIPA yang dihasilkan oleh DJA adalah DIPA induk dan DIPA petikan. Namun di level
satker akan menerima DIPA Petikan yang sudah disahkan. DIPA Petikan yang sudah
disahkan tersebutlah yang akan menjadi dasar Pagu Anggaran yang akan digunakan dalam
pelaksanaan anggaran pada modul lainnya dalam SAKTI.
Terkait dengan proses revisi anggaran, pada SAKTI menyediakan juga fitur penyimpanan
data histori revisi, dan juga pemberlakukan pembatasan pagu anggaran terkait realisasi
yang sudah dilaksanakan sebelum anggaran direvi.
Dalam menyusun anggaran juga diperlukan SBK (Standar Biaya Keluaran) dan SBM
(Standar Biaya Masukan) sebagai acuan dalam perhitungan kebutuhan anggaran. Standar
biaya keluaran diperlukan untuk menghasilkan sebuah keluaran yang standar atas kegiatan
yang dilaksanakan oleh Kementerian Negara/Lembaga tertentu dan/atau di wilayah
tertentu. Usulan SBK dapat diajukan oleh masing – masing Eselon 1 untuk kemudian
dilakukan penelaahan dan penetapan oleh Kemenkeu cq. Direktorat Jenderal Anggaran.
Oleh karena itu, Modul Penganggaran juga mengintegrasikan fungsi penyusunan SBK di
level Eselon I. Proses penyusunan SBK juga dilakukan dari tahapan penyusunan oleh
Operator/ validator, dilanjutkan dengan proses validasi oleh validator dan approval oleh
approver.
Selain itu modul Penganggaran SAKTI juga mengintegrasikan fungsi penyusunan Rencana
Realisasi Anggaran di level satker yang terdiri dari Rencana Penarikan Dana, Rencana
Penerimaan dan Pergerakan Informasi Perencanaan Kas Bulanan/AFP (Annual Financial
32
Plan). Fungsi penyusunan Rencana Penarikan Dana dimulai dari penyusunan POK (Petunjuk
Operasional Kegiatan) dimana proses penyusunannya beracuan pada Kertas Kerja satker
yang dilakukan oleh user operator/ validator. Yang kemudian dilakukan validasi oleh
validator dan approval oleh approver. Setelah POK diapprove, maka sistem akan
melakukan kalkulasi secara otomatis perhitungan Rencana Penarikan Dana Bulanan yang
informasinya digunakan pada Hal III DIPA ,acuan dalam penyusunan Perencanaan Kas
Harian dan Mingguan serta acuan dasar Perhitungan Nilai AFP . Setelah mendapatkan
data perencanaan penarikan bulanan dari POK tersebut, maka selanjutnya satker
melakukan penyusunan rincian
perencanaan kas Harian.
Setelah itu sistem akan
melakukan perhitungan akumulasi otomatis ke dalam perencanaan kas mingguan.
Gambaran umum fitur – fitur Modul Penganggaran pada SAKTI dapat dilihat pada gambar
berikut ini:
Modul Penganggaran SAKTI
Approval
SBK
Kirim Usulan
SBK ke
SPAN
Terima
Usulan SBK
Perencanaan Realisasi Anggaran
Kirim Usulan
RKAKL ke
SPAN
Approval
RKAKL
Validasi
RKAKL
RUH SBK
Review
Baseline
Konsolidasi
Kertas Kerja
Approval
Kertas Kerja
Review
RKAKL
Kirim Kertas
Kerja
Validasi
Kertas Kerja
RUH Usulan
SBK
Kirim Usulan
SBK
Review
Baseline
RUH Kertas
Kerja
Approval
Rencana
Penerimaan
Approval
POK
Approval
Penerimaan
Validator
Satker
Operator
Satker
Penyusunan Anggaran
Validasi
SBK
Approver
Satker
Operator ES 1 Validator ES 1 Approval ES 1
Penyusunan SBK
Validasi
Penerimaan
Approval
Renkas
Validasi POK
Validasi
Renkas
RUH Renkas
RUH
Penerimaan
RUH POK
Terima ADK
DIPA dari
SPAN
Pagu
Anggaran
Aktif
Kirim
Renkas
Validasi
Rencana
Penerimaan
RUH Prencana
Penerimaan
Bulanan
Tayang Hal III
DIPA
Tayang AFP
Gambar 3.5. Gambaran umum fitur – fitur Modul Penganggaran pada SAKTI
33
Fitur – fitur yang terkait dengan proses penganggaran adalah sebagai berikut :
i.
Penyusunan Anggaran
Menyediakan
fitur
–
fitur
Review
Baseline
Satker,RUH
kertas
kerja,
RUH
Penerimaan/Pendapatan, Konsolidasi Kertas Kerja menjadi RKAKL, Pengiriman ADK RKAKL ,
Penerimaan ADK DIPA, Penguncian Pagu Anggaran (Fund Blocking), Penentuan Status
History Anggaran (RKAKL, DIPA, Revisi, dll), Pencetakan report terkait RKAKL, DIPA, dll
ii. Penyusunan SBK
Menyediakan fitur RUH Usulan SBK (Standar Biaya Keluaran)
iii. Perencanaan Realisasi Anggaran
Menyediakan fitur – fitur RUH POK, RUH Renkas (Perencanaan Kas), RUH Rencana
Penerimaan, Perhitungan otomatis halaman III DIPA, Perhitungan Otomatis AFP (Annual
Financial Plan) dan Pencetakan report terkait POK, Hal III DIPA dan Realisasi Penyerapan
Anggaran.
B. PELAKSANAAN ANGGARAN
a.
Modul Pelaksanaan Anggaran pada SAKTI
Pada Satker, modul Pelaksanaan Anggaran memuat keseluruhan proses yang terkait
dengan pelaksanaan anggaran. DIPA yang telah disahkan menjadi dokumen sumber bagi
proses pencairan dana APBN. Satker melakukan serangkaian kegiatan yang terkait dengan
proses pencairan dana APBN meliputi pertama, penetapan pejabat pengelola keuangan
satker (Kuasa pengguna Anggaran (KPA), Pejabat Pembuat Komitmen (PPK), Pejabat
Penandatangan Surat Perintah Membayar (PPSPM), dan Bendahara).
Kedua, penunjukan pihak ketiga sebagai penyedia barang dan jasa melalui pelelangan atau
penunjukan. Ketiga, pembuatan komitmen pencairan dana dengan membuat berita acara
serah terima barang. Terakhir, mengajukan permintaan pencairan dana (Surat Perintah
Membayar (SPM)) ke KPPN terkait dengan tagihan belanja yang diterima oleh Bendahara.
Saat ini semua proses yang dijalankan SATKER tersebut, diotomasi melalui aplikasi SPM
dan aplikasi Peran. Khusus untuk pembayaran gaji, proses yang di-cover dalam modul ini
hanya meliputi proses pengajuan permintaan dana gaji ke KPPN. Sedangkan pengelolaan
34
data gaji dan pegawai, dilakukan secara terpisah oleh sistem yang ada saat ini, berupa
Aplikasi GPP.
Terdapat beberapa tambahan proses terkait dengan implementasi SPAN pada SAKTI.
Pertama, proses mendaftarkan supplier barang dan jasa, baik yang dilakukan pihak ketiga
atau pun swakelola, dimana SPAN akan memberikan register supplier sebagai bukti bahwa
data supplier tersebut telah tercatat. Kedua, proses menyampaikan data elektronis resume
kontrak ke KPPN yang selama ini hanya berupa hardcopy. SPAN akan memberikan
Comitment Application Number (CAN) yang menyatakan bahwa data kontrak telah
tercatat di SPAN. Ketiga, proses menyampaikan data elektronis resume tagihan ke KPPN,
yang selanjutnya SPAN akan mengeluarkan nomor Invoice. Nomor ini menjadi acuan
SATKER dalam proses pencairan dana (SPM).
Untuk mengantisipasi agar SATKER tidak terbebani akibat bertambahnya proses tersebut,
maka ketiga proses tambahan diatas dapat dilakukan secara virtual, dimana SATKER tidak
perlu datang ke KPPN, cukup mengirimkan data elektronis tersebut melalui sarana
elektronis, yaitu Portal SPAN. Dari penjelasan tersebut diatas maka Aplikasi Satker harus
dapat mencakup semua proses pelaksanaan anggaran dengan mempertimbangkan
koneksitas kebutuhan data SPAN.
Gambaran umum mengenai proses pelaksanaan anggaran ada pada Gambar 2.4 sebagai
berikut:
35
Gambar 3.6. Koneksitas Modul Pelaksanaan Anggaran Aplikasi Satker -SPAN
Kerangka Koneksitas Proses Bisnis Satker dengan DJPBN
Spending Unit
Contract
Acquisition
Create SPM
RFC
Allotment
(DIPA)
AFP
DIPA Page III
Substantif
Test
(ceiling test)
Treasury
Create SPP
Verify CAN
Long Term Cash
Planning
Liabilities
record
Short Term
Cash Planning
Commitment
Record
(CAN)
Formal &
Substantif Test
(tes akun)
Create SP2D
ALUR MNJ. KOMITMEN
ALUR MNJ PEMBAYARAN
ALUR MNJ. KAS
ALUR MNJ. DIPA
Proses bisnis terkait dengan proses pelaksanaan anggaran dijelaskan sebagai berikut :
i. Manajemen Supplier
Modul Aplikasi harus dapat menyediakan interface perekaman data supplier,
Pembuatan ADK Supplier, dan upload data register supplier.
iii. Manajemen Komitmen
Modul Aplikasi harus dapat menyediakan interface perekaman data kontrak (RFC) untuk
specific commitment dan invoice untuk continuing commitment, pembuatan ADK
resume kontrak, pengecekan rencana penarikan dana dan upload data CAN
iv. Manajemen Pembayaran
Modul Aplikasi harus dapat menyediakan interface perekaman data resume tagihan,
perekaman data potongan SPM, pencetakan resume tagihan, pembuatan ADK resume
tagihan, dan upload data invoice.
36
Selain itu, Modul Aplikasi juga harus dapat menyediakan interface approval SPM,
pencetakan SPM, pembuatan ADK SPM, upload data SP2D, pengecekan ketersediaan
dana, pencetakan realisasi belanja.
v. Manajemen Penerimaan dan Uang Persediaan
Modul Aplikasi harus dapat menyediakan interface perekaman data penerimaan (BLU
dan PNBP), penayangan dan pencetakan data realisasi penerimaan. Modul aplikasi
yang mengelola transaksi masuk keluarnya kas di Satker atas transaksi penerimaan dan
pengeluaran, termasuk menghasilkan Laporan Pertanggungjawaban Bendahara adalah
modul Bendaraha. Modul ini juga menyuplai data pembayaran yang dilakukan melalui
mekanisme Uang Persediaan kepada Modul Pembayaran. Apabila pembayaran
mengakibatkan
diperolehnya
barang/asset,
maka
Modul
Bendahara
harus
mengirimkan informasi ini ke Modul Persediaan/Aset Tetap.
Bendahara Penerimaan membutuhkan interface perekaman data penerimaan (BLU dan
PNBP Fungsional), penayangan dan pencetakan data realisasi penerimaan, Interface
pembuatan berita acara serah terima Bendahara Penerimaan, pencatatatan Kas Tunai
dan Bank, interface perekaman data honor,
dan Laporan Pertanggungjawaban
Bendahara Penerimaan.
Bendahara Pengeluaran membutuhkan interface perekaman data penerimaan pajak
dan PNBP umum, interface perekaman bon, interface pencatatan bon, interface
perekaman kuitansi, interface pencatatan kuitansi, Interface penghitungan Usul UP,
Interface penghitungan Usul GUP, Interface rincian penggunaan TUP dan Laporan
Pertanggungjawaban Bendahara Pengeluaran.
vi. Interface Gaji
Modul Aplikasi harus dapat menyediakan interface upload data gaji, penayangan dan
pengecekan data gaji Satker.
37
Modul Pelaksanaan anggaran pad SPAN terdiri dari manajemen komitmen, manajemen
pembayaran, manajemen penerimaan dan manajemen kas.
MANAJEMEN KOMITMEN
1.
Pengertian dan Konsep Dasar
Pelaksanaan manajemen komitmen memiliki dua tujuan utama yang masing-masing
memiliki orientasi yang berbeda tetapi saling melengkapi. Pelaksanaan manajemen
komitmen
terutama
ditujukan
untuk
mengelola
tindakan-tindakan
awal
yang
menimbulkan kewajiban negara dalam rangka disiplin anggaran (ketaatan terhadap batas
pengeluaran). Di samping itu, manajemen komitmen juga ditujukan untuk mendukung
terwujudnya perencanaan kas yang berorientasi ke depan (forward cash planning) yang
berbeda dengan perencanaan kas berdasarkan data trend dari periode sebelumnya
(historical data trend). Dengan mencatatkan komitmen ke dalam sistem perbendaharaan,
maka institusi perbendaharaan dapat membuat perencanaan kas yang berorientasi ke
depan berdasarkan perkiraan arus kas yang akan menyertai pelunasan sebuah komitmen
(Radev & Khemani, 2007; Potter & Diamond, 1999).
2.
Proses Bisnis Manajemen Komitmen
Kerangka Integrasi dan Koneksitas Proses Bisnis Manajemen Komitmen dengan proses
bisnis perbendaharaan lainnya :
38
Integrasi dan Koneksitas Proses Bisnis Manajemen Komitmen dengan proses bisnis perbendaharaan lainnya
Spending Unit
Contract
Acquisition
Create SPP
Create SPM
Resume
tagihan
RFC
Allotment
(DIPA)
Treasury
Substantif
Test
Long Term Cash
Planning
Verify CAN
Liabilities
record
Short Term
Cash Planning
Commitment
Record
(CAN)
Create SP2D
ALUR MNJ. KOMITMEN
ALUR MNJ PEMBAYARAN
ALUR MNJ. KAS
Formal &
Substantif
Test
ALUR MNJ. DIPA
Gambar 3.7. Koneksitas Proses Bisnis Manajemen Komitmen dengan proses bisnis lain
Sumber : Modul Manajemen Komitmen
Dalam rangka SPAN secara garis besar komitmen dibagi menjadi 2, yaitu
a. Spesific commitment:
Komitmen yang menimbulkan kewajiban pembayaran atau serangkaian pembayaran
dalam jangka waktu tertentu. Termasuk dalam komitmen khusus adalah penerbitan
kontrak pengadaan barang dan jasa. Satker akan membuat dan menyampaikan dokumen
Resume Kontrak atau Request for Commitment (RFC) yang selanjutnya akan dicatat oleh
KPPN. Dokumen RFC ini pada dasarnya memuat ringkasan data kontrak sebagaimana
model Resume Kontrak (Perdirjen 66/PB/2005 Lampiran V) yang digunakan pada proses
bisnis saat ini.
Dokumen RFC dibuat atas dasar kontrak dan diperlakukan sebagai Purchase Order (PO)
dalam sistem perbendaharaan di KPPN. Sebuah transaksi akan termasuk specific
commitment apabila memenuhi syarat aktivitas pembuatan perikatan (establishment of
commitment) yang mudah di identifikasi dan/atau informasi atas rencana pengeluaran
yang andal (reliable) sebagai salah satu dasar perencanaan kas.
39
Jenis pengeluaran yang termasuk ke dalam specific commitment antara lain meliputi:
No
Jenis Pengeluaran
1
Pengadaan barang/jasa dengan pihak ke-3
2
Penyaluran penerusan pinjaman
3
Penyaluran Pinjaman Luar Negeri
4
Transaksi dalam rangka pembayaran dan pengesahan menggunakan Tambahan
Uang Persediaan
b. Continuing commitment:
komitmen yang pembayarannya bersifat berkelanjutan, tidak dibatasi oleh jangka waktu
tertentu dan tidak didasarkan pada adanya kontrak tersendiri. Pembayaran untuk gaji,
tunjangan dan sejenisnya termasuk dalam continuing commitment. Pengakuan dan
pencatatan atas komitmen yang termasuk dalam jenis belanja ini dilakukan bersamaan
dengan aktivitas yang berkaitan dengan tahap verifikasi dan pembayaran. Jenis
pengeluaran yang termasuk ke dalam continuing commitment meliputi:
No
Jenis Pengeluaran
1
Pembayaran gaji
Pembayaran menggunakan Uang Persediaan (UP) dan pertanggungjawabannya
(GUP)
Pembayaran jasa bank terkait penerusan pinjaman
Pembayaran jasa bank selaku bank persepsi
Penyaluran subsidi
Penyaluran transfer ke daerah
Pembayaran kelebihan pajak (SPM KP/KC)
Pembayaran imbalan bunga (SPM IB)
Pembayaran askes, taspen, taperum
2
3
4
5
6
7
8
9
40
Kerangka pelaksanaan manajemen komitmen adalah sebagai berikut :
KPPN
Satker
Purchase Requisition
(PR)
Penerbitan Purchase
Requisition oleh unit
yang menggunakan
barang dan jasa
Purchase Order (PO)
Verifikasi PR,
pemilihan supplier
dan penerbitan
Purchase Order
Penerimaan barang
dan jasa, verifikasi
terhadap PO dan
pembuatan Berita
Acara
Resume Kontrak (*)
Pembayaran
Tagihan
Penerimaan tagihan,
verifikasi terhadap PO,
dan Pembayaran
Verifikasi terhadap
PO terhadap BA
Penerimaan dan
Penerbitan invoice
SPP / SPM
(*)
Komitmen (*)
Hutang (*)
SP2D(*)
Belanja
Bagian dari proses bisnis manajemen komitmen yang dikelola oleh KPPN
Daftar Rekanan
Sumber : Modul Manajemen Komitmen
Catatan:
(*) Penyampaian dokumen Resume Kontrak adalah dalam rangka pencatatan informasi
yang dibuat oleh Satker kepada KPPN.
(**) Pencatatan kewajiban dilakukan atas dasar invoice yang valid yang merujuk pada
penerbitan SPP atau SPM.
PR = permintaan untuk pengadaan barang/jasa atas kebutuhan tertentu
PO = Kontrak
Manajemen komitmen menghendaki adanya pengakuan dan pencatatan atas dibuatnya
sebuah perikatan. Dalam rangka penerapan pendekatan penganggaran, komitmen diakui
pada saat penandatanganan kontrak dan dicatat ke dalam sistem informasi
perbendaharaan. Namun demikian, sifat pencatatan bukanlah pencatatan akuntansi
keuangan dalam bentuk kewajiban atau hutang (liability). Pencatatan yang dilakukan lebih
ditujukan untuk menginformasikan adanya “reserve of fund” atau pencadangan, bahwa
sebagian dari pagu anggaran telah terikat pada kontrak tertentu dan menjadi “committed
41
budget balance”. Konsisten dengan pendekatan penganggaran, maka pengakuan liability
atau hutang baru dilakukan setelah pemenuhan perikatan/komitmen, misalnya setelah
penerimaan barang dan jasa atau penerimaan tagihan yang valid. Data hutang (liability)
tersebut diharapkan dapat menjadi input bagi perkiraan kebutuhan kas dalam rangka
pelunasan tagihan atas pemenuhan komitmen tertentu.
Status pagu setelah pencatatan encumbrance adalah sebagai berikut:
Pagu
Cadangan
Realisasi
=
Sisa Pagu
Penerapan manajemen komitmen dapat memberikan manfaat dan nilai tambah dari halhal berikut ini:
1. Adanya pengujian atas ketersediaan dana atas komitmen secara lebih dini pada tahap
pelaksanaan anggaran oleh treasury sebagai bagian dari mekanisme control dan check
and balance dalam pelaksanaan dan pertanggungjawaban keuangan negara.
2. Pemberian nomor referensi atas data kontrak yang telah diuji validitasnya, yang
bermanfaat sebagai salah satu referensi dan verifikasi pada tahap pembayaran kepada
pihak ke-3.
3. Adanya pencadangan pagu yang dapat menginformasikan status pagu anggaran yang
dikelola Satker yang dapat membantu proses pengambilan keputusan, misalnya untuk
kepentingan revisi anggaran dalam tahap pelaksanaan anggaran.
4. Adanya fasilitas untuk melakukan perencanaan kas yang lebih ideal, baik dalam jangka
panjang melalui penggunaan proyeksi arus kas dalam kontrak.
5. Adanya catatan atas komitmen dan kontrak-kontrak yang dibuat pemerintah untuk
pelaksanaan pekerjaan selama jangka waktu tertentu dalam periode pelaksanaan
anggaran yang dapat menjadi referensi bagi kebijakan pemerintah, misalnya dalam
penggunaan data komitmen sebagai potential obligation dalam rangka penetapan
kebijakan fiskal terkait perubahan dan revisi anggaran secara keseluruhan.
6. Adanya integrasi atas proses bisnis yang dilakukan sebagai bagian dari pelaksanaan
tugas dan fungsi Ditjen Perbendaharaan, yang setidaknya meliputi manajemen
komitmen, manajemen DIPA, manajemen pembayaran dan manajemen kas.
42
7. Adanya data badan usaha yang valid selaku rekanan pemerintah yang dapat digunakan
untuk menjadi referensi bagi penyusunan kebijakan terkait dengan keuangan negara
[misalnya untuk keperluan perpajakan] maupun pengembangan dunia usaha pada
umumnya.
Untuk mendukung Manajemen Komitmen, manajemen supplier menjadi salah satu
komponen utama yang harus dikembangkan. Manajemen supplier menyediakan master
data berupa data pihak-pihak penerima pembayaran, dimana nantinya digunakan oleh
proses pencairan sebagai rujukan arah tujuan pembayaran. Lebih jauh lagi manajemen
supplier dikembangkan dalam rangka meningkatkan
validitas data
supplier
yang
memiliki perikatan dengan negara.
Manajemen supplier merupakan suatu kegiatan untuk mengelola data-data detail
terkait supplier, berupa Satker, Pihak ketiga, Pengguna dana, Lender atau pegawai.
Data ini digunakan untuk sebagai arah tujuan pembayaran, meningkatkan validitas data
supplier, evaluasi kinerja supplier, rekonsiliasi dengan data customer maupun dalam
rangka memenuhi kebutuhan laporan manajerial terkait supplier.
Proses registrasi data supplier dimulai dengan tahap validasi data yang disampaikan oleh
Satker dengan master data yang ada di SPAN. Validasi tersebut dilakukan terhadap
keberadaan data supplier di master data. Data yang belum ada di master data akan
membentuk data baru. Data yang valid akan diberikan nomor register supplier apabila
belum memiliki nomor register. Hasil update data supplier akan disampaikan ke Satker
sebagai bukti pencatatan data di SPAN dan untuk menjadi acuan apabila akan melakukan
perikatan atau pembayaran dengan supplier yang sama.
Data Supplier dicatat dan digunakan dengan menggunakan beberapa prinsip tertentu
sebagai berikut:
a. Prinsip umum
– Data supplier merupakan bagian dari thumb rules proses pembayaran
43
– Penyampaian data supplier baru (belum pernah didaftarkan sebelumnya)
dilakukan bersamaan dengan data RFC untuk transaksi spesific commitment atau
bersama dengan data Resume Tagihan untuk transaksi Continuing Commitment
b. Prinsip proses validasi
– Validasi awal data supplier dilakukan oleh Satker dengan menggunakan Form
Registrasi Supplier yang dikonfirmasi oleh pihak-pihak terkait, diantaranya oleh
Bank untuk data rekening dan oleh KPP untuk data NPWP (misalnya dengan
adanya fotokopi buku tabungan atau lampiran kartu NPWP)
– Validasi Data Supplier di KPPN hanya untuk mencegah pencatatan kembali data
yang sama
– Validasi dilakukan pada primary key data supplier.
c. Prinsip konfirmasi dan kehandalan data
– Kebenaran data yang disampaikan ke KPPN menjadi tanggung jawab KPA
– KPPN hanya menggunakan data supplier dari Satker (tidak melakukan konfirmasi
terhadap sumber data (KPP/Bank))
– KPPN harus memproses pembayaran terhadap penerima/rekening sebagaimana
tercantum dalam RFC / Resume Tagihan yang sesuai dengan Data Supplier.
Pencatatan supplier pada dasarnya dilakukan berdasarkan pihak yang menerima
pembayaran (beneficiaries). Prinsip tersebut sejalan dengan mekanisme pencatatan yang
digunakan dalam software pendukung (COTS). Meskipun demikian, dengan menimbang
kemudahan penggunaan, pemenuhan kebutuhan laporan manajerial, pembagian jenis
komitmen dan jenis entitas, maka pengelompokan supplier dalam rangka implementasi
SPAN dilakukan customisasi sebagai berikut:
Kode
1
2
3
Tabel Pengelompokan supplier
Tipe
Jenis Komitmen
- Permintaan dan penggunaan UP (CC)
Satker
- Permintaan dan penggunaan TUP (SC)
Penyedia barang dan - Kontraktual (SC)
jasa
- Pembayaran daya dan jasa (CC)
Pegawai
- Pembayaran gaji (CC)
44
4
BA 999
selain Penerusan
Pinjaman
5
6
Transfer Daerah
Penerusan Pinjaman
7
Lain-lain
-
Honor (CC)
Lembur (CC)
Investasi Pemerintah (SC)
Hibah ke daerah (CC)
Subsidi (CC)
Kredit Program (CC)
Loan Repayment (CC)
pembayaran terkait SBN (CC)
Jasa Bank penatausaha PP (CC)
jasa Bank Persepsi (CC)
Pengembalian PFK (CC)
Lain-lain (SC/CC)
Transaksi transfer daerah ke Pemda
Pembayaran Penerusan Pinjaman (SC)
Pengembalian pajak/PBB/BPHTB/BM-C (CC)
pengembalian PNBP (CC)
pengembalian setoran uang pensiun (CC)
Lain-lain (SC/CC)
Suatu RFC atau Resume Tagihan dapat di proses lebih lanjut apabila dalam data Resume
Kontrak atau Resume Tagihan tersebut merujuk pada supplier tertentu dalam master
data supplier. Wewenang melakukan perekaman dan modifikasi data supplier terletak
pada responsibility KPPN sebagai operating unit (OU) dalam implementasi SPAN. KPPN
yang melakukan perekaman data supplier disebut OU creator. Sedangkan KPPN yang
menggunakan data yang sudah direkam sebelumnya oleh OU creator disebut OU User.
Selain OU user dan OU creator terdapat juga satu unit khusus yang akan melakukan
pengelolaan terhadap data supplier, unit khusus tersebut berada di kantor pusat
Ditjen Perbendaharaan.
Gambar Ilustrasi Penyampaian antara data supplier dengan RFC dan Resume tagihan
45
Keterkaitan Data Supplier dengan RFC dan Resume Tagihan
KPPN
Satker
Supplier Management
Resume Kontrak (RFC)
(Data supplier & Data
Kontrak)
Registrasi dan
Validasi Data
Supplier
Commitment Management
Payment Management
Verifikasi Data
Proses RFC
Resume Tagihan
(Data Supplier dan Data
Tagihan)
Registrasi dan
Validasi data
supplier
Verifikasi data
Proses Resume
Tagihan
Gambar 3.8. Keterkaitan Data Suplier dengan RFC dan Resume tagihan
Sumber: Manajemen Komitmen
MANAJEMEN PEMBAYARAN
1.
Pengertian dan Konsep Dasar
Manajemen Pembayaran atau Payment Management (PM) merupakan salah satu modul
yang berperan sebagai gerbang utama pengeluaran pemerintah dalam rangka menunjang
program pembangunan nasional. Manajemen Pembayaran akan memproses tagihan
(dalam bentuk Resume Tagihan dan Surat Perintah Membayar) yang diajukan oleh Satuan
Kerja (Satuan Kerja) dan melakukan proses pencairan dana dari Rekening Pengeluaran
Pemerintah kepada pihak yang berhak melalui proses penerbitan SP2D/SPT.
Secara umum, penyempurnaan proses bisnis dalam manajemen pembayaran diarahkan
untuk menciptakan proses penyelesaian dan pembayaran tagihan atas beban APBN yang
cepat, aman, dan tetap berpegang kepada kaidah-kaidah pengelolaan keuangan negara
yang transparan dan akuntabel sehingga dapat mendukung penciptaan pelaksanaan
anggaran yang efektif, efisien, dan optimal. Sebagai prasyarat agar hal tersebut dapat
dicapai diperlukan hal-hal sebagai berikut:
46
1. Integrasi data pembayaran dengan data yang dihasilkan oleh modul SPAN lainnya;
2. Penerapan accrual accounting dalam manajemen pembayaran;
3. Otomatisasi sistem dengan pemanfaatan teknologi informasi untuk meminimalkan
pemrosesan secara manual;
4. Perluasan penggunaan dokumen elektronik (e-document) sekaligus minimalisasi
hardcopy dalam manajemen pembayaran.
Sebagai dampak dari Penerapan dari hal-hal tersebut di atas diperlukan penyempurnaan
atas proses bisnis dan koneksitas antara institusi-insitusi yang terkait dengan manajemen
pembayaran yakni: Satker, KPPN, dan perbankan.
2. Koneksitas Proses Bisnis Satker dan KPPN
Penyempurnaan proses bisnis manajemen pembayaran pada SPAN berdampak cukup
signifikan terhadap perubahan interaksi Satker dan KPPN saat ini. Perubahan interaksi
antara antara Satuan Kerja dan KPPN dapat dilihat pada gambar dibawah ini:
Payment Management
PPK-Satker
PPSPM-Satker
FO-Seksi PD
MO-Seksi PD
Kasi PD
C.
Penerusan
Informasi
Tagihan
C.
Persetujuan
Tagihan
Staff Bank
Kasi Bank
D.
Pengelompokan
Tagihan
E.
Pembayaran
Tagihan
BO
Penerimaan dan
Pengujian
Tagihan Suplier
A.
Pendaftaran RT,
Upload, Validasi
Penerbitan SPP
dan RT
Penerimaan
SPP dan
Pengujian SPP
Penerbitan SPM
B.
Pendaftaran
SPM, Upload,
Initiate
Payment (Due Date)
Invoicing
Penerimaan
Nomor Tagihan
dari SPAN
F.
Pengiriman
Data
Pembayaran
M.
Penerimaan
SP2D dan
Transfer ke
Suplier
Gambar 3.8.Proses Bisnis Manajemen Pembayaran dalam SPAN
Sumber: Manajemen Pembayaran
47
Gambar 3.9.Perubahan Interaksi antara Satuan Kerja dan KPPN
FUTURE
Gambar 3.10
Proses Bisnis Manajemen Pembayaran pada saat implementasi SPAN secara penuh
Sumber:Modul Manajemen Pembayaran
48
Dalam manajemen pembayaran saat ini, interaksi utama antara Satker dan KPPN terjadi
pada waktu penyampaian SPM oleh Satker dan penerbitan SP2D oleh KPPN. Manajemen
pembayaran pada saat SPAN diimplementasikan secara penuh membawa perubahan yang
mendasar pada proses bisnis penyelesaian tagihan APBN di internal Satker dana sekaligus
interaksinya dengan proses pengujian dan pembayaran tagihan di KPPN. Perubahanperubahan tersebut dijelaskan dalam Gambar 3.10 di atas.
Penjelasan Proses Bisnis Pembayaran pada saat implementasi SPAN secara penuh:
1) Satker mendaftarkan penerima pembayaran ke KPPN. Khusus untuk belanja yang
mempergunakan kontrak, data kontrak tersebut wajib daftarkan ke KPPN.
2) Atas pendaftaran penerima pembayaran, KPPN memberikan Nomor Register Suplier
(NRS). Untuk kontrak, KPPN memberikan Nomor Register Kontrak (NRK).
3) Data NRS dan NRK yang diperoleh satker tersebut kemudian dipergunakan oleh
Pejabat Pembuat Komitmen (PPK) sebagi salah satu input (masukan) dalam pembuatan
Resume Tagihan (RT). Resume Tagihan adalah data SPP yang dikirimkan ke KPPN untuk
dicatatkan dalam SPAN. Proses ini digunakan dalam SPAN sebagai penerapan akuntansi
akrual, dimana tagihan yang dikirimkan
dicatatkan atau diakui sebagai hutang
(liability). RT yang telah dilengkapi dengan data NRS dan atau NRK (khusus untuk
kontrak), kemudian disampaikan ke KPPN. Dalam RT tersebut, Satker juga wajib
mencantumkan waktu jatuh tempo tagihan (payment term).
4) Berdasarkan Resume Tagihan dari Satker, KPPN melakukan pengujian kebenaran
keabsahan tagihan dan memberikan Nomor Tagihan (NT). NT tersebut selanjutnya
dipergunakan sebagai input (masukan) dalam pembuatan Surat Perintah Membayar
(SPM) oleh PP-SPM.
5) Satker menyampaikan menyampaikan SPM ke KPPN. Penyampaian SPM Tersebut wajib
dilakukan sebelum waktu jatuh tempo tagihan. Jatuh tempo tagihan ditetapkan oleh
Satker. Jatuh tempo tagihan merupakan norma waktu yang bersifat spesifik dan
terukur yang menyertakan informasi kapan suatu tagihan harus dibayar ke KPPN. Jatuh
tempo tagihan tersebut merupakan informasi yang dipergunakan oleh BUN dalam
penyusunan perencanaan kas jangka pendek sekaligus berfungsi sebagai norma waktu
49
kapan suatu permintaan pembayaran (SPM) harus disampaikan ke KPPN. Jatuh tempo
tagihan juga dilengkapi dengan mekanisme pembatalan otomatis oleh sistem. Jika
penyampaian permintaan pembayaran oleh Satker ke KPPN melampaui norma waktu
yang ditetapkan maka sistem secara otomatis akan membatalkan tagihan tersebut.
6) KPPN menerima dan melakukan pengujian secara sistem, data SPM dengan data
Resume Tagihan dengan mempergunakan NT yang tertera pada SPM.
7) Atas SPM yang lolos pengujian, KPPN menerbitkan Surat Persetujuan Pembayaran
Tagihan (SPPT) pada hari yang sama atau satu hari setelah penyampaian SPM ke KPPN.
Penerbitan Surat Perintah Pencairan Dana (SP2D) oleh KPPN dilakukan pada saat
tagihan jatuh tempo.
Proses bisnis manajemen pembayaran dalam kerangka SPAN tampak lebih kompleks jika
dibandingkan dengan yang ada saat ini. Pandangan tersebut relatif sesuai jika proses bisnis
tersebut dianalogikan dengan kondisi saat ini dimana penyampaian data-data ke KPPN
disampaikan secara langsung oleh Satker ke KPPN. Namun, implementasi SPAN didukung
oleh penggunaan teknologi informasi (internet network) serta infrastruktur jaringan yang
memadai pandangan tersebut menjadi tidak relevan.
Untuk mendukung penerapan SPAN, modul manajemen pembayaran dilengkapi dengan
fitur auto respon. Fitur auto respon tersebut berupa notifikasi dan dokumen elektronik
dikirimkan kepada Satker melalui e-mail. Notifikasi dan dokumen elektorinik hanya dapat
dikirimkan jika data tagihan yang dikirimkan ke KPPN dilengkapi dengan alamat email.
Notifkasi akan dikirimkan secara otomatis oleh server SPAN kepada email Satker saat:
1) Pembatalan tagihan yang gagal melalui proses pengujian/validasi
2) Pembatalan tagihan otomatis oleh sistem karena melewati jatuh tempo;
Sedangkan dokumen elektronik yang dikirimkan kepada e-mail satker adalah:
1) Daftar resume tagihan yang telah berhasil/gagal melaui proses pengujian;
2) Daftar resume tagihan dibatalkan secara otomatis oleh sistem karena melewati jatuh
tempo;
3) Daftar SPM yang telah berhasil melalui proses pengujian;
50
4) Daftar resume tagihan/SPM yang disetujui;
5) Daftar SP2D.
Gambar 3.11. Proses Bisnis Manajemen Pembayaran pada masa Transisi SPAN
Pada masa transisi, dimana Satker masih menggunakan aplikasi legacy dan KPPN
menggunakan SPAN, Satuan Kerja mengirimkan ADK SPM secara langsung ke KPPN. ADK
SPM tersebut akan dikonversi dengan menggunakan Aplikasi Konversi yang ada di KPPN.
Selanjutnya file hasil konversi akan diproses dalam SPAN. SP2D akan diterbitkan pada hari
yang sama saat SPM diterima oleh KPPN.
MANAJEMEN PENERIMAAN
1.
Pengertian dan Konsep Dasar
Pengelolaan penerimaan negara saat ini telah dikembangkan melalui pengupayaan
integrasi antara beberapa sistem yang menatausahakan penerimaan negara antara lain
melalui penyempurnaan MPN-G2 dan SPAN (Modul GR).
51
Sehubungan dengan hal tersebut di atas, Penatausahaan penerimaan negara dalam SPAN
dikelompokkan menjadi 3 bagian yaitu penerimaan negara melalui Bank Indonesia, Bank
Persepsi dan KPPN. Adapun terkait dengan penatausahaan penerimaan negara melalui
bank persepsi, SPAN akan melakukan interface (data base to data base) dengan sistem
MPN-G2. Sistem MPN-G2 tersebut merupakan feeder data penerimaan bagi SPAN yang
terhubung melalui Government Receipt Module. Adapun penatausahaan penerimaan
melalui SPAN dan MPN-G2 secara garis besar dapat digambarkan dijelaskan dalam gambar
berikut:
Gambar 3.11. Interkoneksi SPAN dengan MPN, MPN-G2, Bank Indonesia dan DJP
Sumber : Modul Manajemen Penerimaan
Adapun penerimaan melalui bank persepsi (MPN-G2) terkait dengan satker adalah sebagai
berikut:
 PNBP Umum
 PNBP Fungsional
 PFK
52
 Penerimaan Pengembalian Sisa UP
 Penerimaan Pengembalian Belanja
 Penerimaan Pengembalian Pendapatan
Beberapa penerimaan melalui aktivitas tersebut di atas saat ini sedang dibuatkan sistem
billing yang nantinya akan dijadikan menghasilkan kode tagihan bagi para wajib setor
sebagai dasar pembayaran ke bank/pos persepsi. Adapun sistem billing tersebut sedang
dikembangkan oleh Direktorat Jenderal Anggaran yang nantinya akan terhubung dengan
sistem Settlemen, switcher, dan collecting agent yang terintegrasi dalam sistem MPN-G2.
Adapun konfigurasi utuh sistem MPN-G2 yang telah dikembangkan adalah sebagai berikut:
Gambar 3.12. Konfigurasi sistem MPN-G2
Sumber : Modul Manajemen Penerimaan
Secara umum pengembangan sistem MPN-G2 ditujukan untuk mewujudkan sistem
penerimaan negara yang terintegrasi dalam satu database, di mana sebelumnya
penatausahaan penerimaan negara dilakukan secara terpisah oleh Direktorat Jenderal
Pajak, Direktorat Jenderal Bea dan Cukai serta Direktorat Jenderal Perbendaharaan.
53
Adapun untuk penerimaan dari potongan SPM, data penerimaan perpajakan yang
bersumber dari potongan SPM akan disampaikan secara sistem oleh sistem SPAN ke dalam
sistem MPN-G2.
Sejalan dengan pembengunan sistem MPN-G2 terkait dengan setoran penerimaan melalui
bank persepsi telah disempurnakan dilakukan dengan pembangunan sistem billing dan
switching untuk mempermudah penyetoran maupun penatausahaan penerimaan negara.
Dengan konfigurasi sistem MPN-G2 sebagaimana digambarkan tersebut diatas,
penyetoran penerimaan negara dengan sistem biling dapat dilakukan di beberapa chanel
pembayaran antara lain: via teller bank, internet-banking, phone-banking, sms-banking,
ATM, dan lain-lain.
Secara umum, beberapa
pokok perubahan atau penyempurnaan proses bisnis
penatausahaan penerimaan negara dalam rangka implementasi Sistem Perbendaharaan
dan Anggaran Negara (SPAN) seperti yang terlihat pada tabel berikut ini.
No
Pokok-Pokok Perubahan (improvement)
1. Sentralisasi penatausahaan penerimaan negara melalui single database dalam SPAN
2. Sentralisasi pengelolaan Modul Penerimaan Negara melalui MPN G2 untuk
setoran penerimaan negara yang disetor pada bank/pos persepsi.
3. Restrukturisasi rekening penerimaan (rekening kas negara) pada bank/pos
persepsi terkait penerapan MPN G2, terutama terkait dengan pemusatan
rekening kas negara untuk masing-masing bank/pos persepsi (BP Pusat).
4. Pembayaran setoran penerimaan negara pada bank/pos persepsi dapat
dilakukan pada lintas (luar) wilayah kerja KPPN yang bersangkutan. Untuk itu
dilakukan jurnal intra-entity (antar satker) pada setiap setoran yang dilakukan.
5. Penerimaan terkait pajak dan bea cukai dicatat (diakui) sebagai penerimaan
masing-masing Satker (KPP/KPBC) bersangkutan. Sehingga proses rekonsiliasi data
dapat
dilakukan di tingkat
dan KPPN.berjalan
Untuk dapat
itu setiap
transaksi
6. penerimaan
Penerimaan dari
pengembalian
belanja Satker
tahun anggaran
mengembalikan
padapagu
datayang
MPNdidahului
harus dapat
di mapping
sebagai penerimaan
KPP/KPBC
selaku
sisa
dengan
surat pengajuan
pengembalian
sisa pagu
oleh Satker.
Satker.
7. Penyampaian LHP dan rekening koran dari bank persepsi/BI secara elektronik
dan terstandarisasi.
54
8. Tidak ada proses konsolidasi laporan (LKP) ditingkat pusat karena menggunakan
single database dan laporan dapat di-generate pada setiap level kewenangan
yang diberikan.
9. Dapat dilaksanakan proses audit trail terhadap data transaksi, karena setiap
adanya perubahan/perbaikan hanya dapat dilakukan dengan mekanisme jurnal
sehingga setiap
akanpenggunaan
tercatat. kertas (less
10. reversal/pembalik,
Penatausahaan penerimaan
negaraperubahan/perbaikan
dengan meminimalisasi
paper).
Tabel Pokok Perubahan Dalam Manajemen Penerimaan
Selama masa peralihan dari MPN existing menjadi MPN-G2, SPAN masih mengakomodir
untuk melakukan pencatatan penerimaan melalui bank/pos persepsi dengan menyediakan
menu unggah ADK dari bank/pos persepsi.
Proses unggah ADK bank/pos persepsi ke dalam SPAN hampir sama dengan proses unggah
ADK bank/pos persepsi yang dilakukan oleh KPPN selama ini. Proses unggah ADK kedalam
SPAN menggunakan form SPGR Data Penerimaan dari Bank Persepsi sebagaimana
ditunjukkan dengan gambar berikut:
55
Adapun aktivitas pencatatan penerimaan melalui bank/pos persepsi meliputi beberapa
aktivitas sebagai berikut:
 Unggah dan validasi ADK yang telah terunggah oleh Staff Seksi Bank/Giro Pos
 Kepala Seksi Bank/Giro Pos melakukan persetujuan (interface) terhadap ADK yang telah
tervalidasi.
Konfirmasi setoran (Reviu transaksi penerimaan)
Untuk melakukan konfirmasi setoran yang telah dicatatpada modul penerimaan. dapat
dilakukan dengan menggunakan menu user Staff dan Kepala Seksi Bank/Giro Pos di KPPN.
Proses reviu transaksi penerimaan dilakukan dengan membuka form inquiry receipt
kemudian lakukan pencarian berdasarkan parameter tertentu, misalnya berdasarkan
tanggal penerimaan, tanggal buku, atau berdasarkan nomor penerimaan.
Terkait dengan penerimaan Retur SP2D, Penerimaan Retur dicatat sebagai penerimaan
transito di dalam SPAN. Penerimaan Retur terjadi jika ada transaksi debit di rekening retur
di KPPN bersangkutan. Dasar pencatatan penerimaan retur adalah rekening Koran yang di
unggah melalui modul Manajemen kas (CM).
Namun sehubungan dengan adanya sentralisasi bank operasional, Penerimaan retur SP2D
juga akan dilakukan secara terpusat pada Direktorat Pengelolaan Kas Negara melalui form
SPGR Data Penerimaan Retur. Dalam hal ini KPPN hanya akan dapat mencetak laporan
terkait dengan penerimaan retur SP2D yang yang ada di wilayah kerja KPPN-nya saja.
56
Permintaan laporan
Laporan manajerial yang disediakan dalam SPAN dan dapat diakses oleh KPPN terdiri atas
5 (lima) jenis Laporan, yakni:
- Laporan Daftar Penerimaan
- Laporan Daftar Pelimpahan PBB ke BO III
- Laporan Daftar Pembagian Pembagian DBH PBB
- Laporan Realisasi Penerimaan, Pembagian, dan Penyaluran PBB
- Laporan Daftar Retur SP2D
Laporan Manajerial ini dapat diakses dengan membuka form jalankan permintaan, lalu
memilih nama laporan apa yang akan di buat. Setiap Laporan memiliki parameter berbeda
yang harus diisi oleh pembuat laporan. Sebagai contoh, Laporan Daftar Retur SP2D
memiliki parameter periode dan Nomor Rekening Retur.
57
Gambar : Ilustrasi permintaan laporan
MANAJEMEN KAS
1.
Pengertian dan Konsep Dasar
Manajemen kas pada SPAN yang merupakan sistem terintegrasi dengan konsep database
tunggal sehingga data-data dari modul-modul lain seperti terlihat pada gambar diatas
dapat dijadikan dasar bagi manajemen kas untuk melakukan transaksi dan pelaporan. Data
dari manajemen DIPA (Management of Spending Authority), manajemen komitmen
(Budget Commitment), manajemen pembayaran (Payment Management), dan manajemen
penerimaan negara (Government Receipt) merupakan sumber data bagi manajemen kas
untuk transaksi maupun pelaporan.
Salah satu penyempurnaan proses bisnis yang terdapat pada manajemen kas SPAN adalah
sentralisasi rekening pengeluaran untuk menggantikan Bank Operasional I. Dengan konsep
tersebut, proses settlement untuk pihak ketiga langsung dilakukan oleh bank yang sama
dengan rekening penerima. Dana akan ditransfer dari RKUN ke RPK BUN P, yang kemudian
58
ditransfer overbooking kepada pihak ketiga pada bank yang sama, sehingga mengurangi
lalu lintas SKN atau RTGS antar bank. Hal tersebut juga dapat mengurangi retur, mengingat
proses settlement hanya menggunakan proses overbooking seperti pada gambar dibawah
ini.
Dit. PKN
Perintah Transfer
RPKBUNP A
(BO A)
Pihak ke-3
(BO A)
Pihak ke-3
(BO A)
RPKBUNP B
(BO B)
Pihak ke-3
(BO B)
Pihak ke-3
(BO B)
RPKBUNP C
(BO C)
Pihak ke-3
(BO C)
Pihak ke-3
(BO C)
Gambar 3.13. Sentralisasi Rekening Pengeluaran
Sumber: Manajemen Kas
2.
Proses Bisnis Manajemen Kas
Penyempurnaan proses bisnis pada modul manajemen kas SPAN, antara lain:
a.
Pencatatan rekening baru (entry new bank account)
Proses tersebut dilakukan untuk registrasi rekening bank yang akan dilakukan untuk
transaksi. Proses registrasi bank dilakukan secara terpusat di Direktorat PKN mengingat
adanya konsep kombinasi BAS (segment bank, akun kas) untuk manajemen kas pada SPAN.
Setiap rekening bank yang didaftarkan pada SPAN kedalam segment bank yang
disesuaikan/diwakili menjadi lima digit (digit 1 untuk tipe rekening, 4 digit berikutnya
merupakan nomor urut).
b. Transfer antar rekening (bank account transfer)
Transfer antar rekening dapat dilakukan oleh KPPN maupun Direktorat PKN sesuai dengan
user login masing-masing. User login tersebut juga berguna untuk mengakses SPAN sesuai
responsibility yang telah ditetapkan, dan juga dapat digunakan sebagai audit trail.
59
c. Rekonsiliasi bank secara otomatis (auto reconcile)
Rekonsiliasi bank digunakan untuk mencocokkan data yang ada pada SPAN dengan
transaksi yang ada di bank (ADK rekening koran bank). Proses rekonsiliasi dilakukan secara
harian oleh sistem dan terjadwal. ADK rekening koran yang diterima dari bank harus sesuai
dengan requirement SPAN, sehingga proses otomatis tersebut dapat berjalan lancar.
d. Rekonsiliasi bank secara manual (manual reconcile)
Proses rekonsiliasi bank secara manual dilakukan jika ada perbedaan antara transaksi yang
ada di SPAN dengan ADK rekening koran bank, dan juga pada rekening yang bersifat
dummy seperti rekening transito untuk BLU, dll.
e. Non-aktifasi rekening (closing existing bank account)
Proses tersebut dilakukan untuk menutup rekening yang sudah tidak aktif, sehingga tidak
dapat digunakan untuk transaksi.
f. Perencanaan kas (cash forecasting)
Perencanaan kas pada SPAN didasarkan pada data atau transaksi yang terjadi pada modul
lain, sehingga dapat diketahui berapa kebutuhan kas secara harian, mingguan, dan
bulanan.
Berikut adalah jenis-jenis laporan perencanaan kas pada SPAN:
a. Laporan Perencanaan Pengeluaran Kas Harian
b. Laporan Perencanaan Pengeluaran Kas Mingguan
c. Laporan Perencanaan Kas Bulanan
d. Laporan Perencanaan Kas Bulanan BUN berdasarkan AFP
e. Laporan Monitoring Ketersediaan Pagu DIPA
f. Laporan Perencanaan Pendapatan Bulanan
60
C. PERTANGGUNGJAWABAN
Modul Akuntansi dan Pelaporan pada SAKTI
Pada Satker, modul Akuntansi dan Pelaporan memuat keseluruhan proses yang terkait
dengan akuntansi dan pelaporan. Sistem akuntansi yang dipakai dalam SAKTI adalah
berbasis akrual. Namun dengan adanya penganggaran berbasis kas dan akuntansi berbasis
akrual, maka model pencatatan yang digunakan akan memfasilitasi kebutuhan laporan
keuangan yang harus dihasilkan sesuai dengan amanat Peraturan Pemerintah No. 71 tahun
2010 mengenai Standar Akuntansi Pemerintah.
Seluruh kegiatan atau transaksi keuangan yang dilakukan oleh 2 (dua) modul sebelumnya,
yaitu modul penganggaran dan modul pelaksanaan anggaran, harus dicatat dalam masingmasing sub ledger. Sub ledger adalah istilah yang digunakan untuk aplikasi yang digunakan
dalam pencatatan transaksi keuangan pada proses penganggaran dan pelaksanaan
anggaran. Semua data yang ada pada Subledger akan dikirim ke General Ledger sehingga
semua jurnal akuntansi termasuk pencetakan laporan keuangan akan melalui modul
akuntansi dan pelaporan atau yang dikenal dengan nama General Ledger.
Terdapat dua keuntungan yang diperoleh dengan adanya pemisahan tersebut, yaitu
pertama, memudahkan pengecekan histori terhadap data-data yang berubah. Kedua,
memudahkan proses pelaporan dimana tidak diperlukan lagi proses posting ke buku besar,
mengingat telah secara otomatis dihasilkan pada saat transaksi berjalan. Semua
pencatatan transaksi keuangan tersebut didasarkan pada elemen Chart of Account (COA).
Elemen COA tersebut meliputi: Satker, KPPN, Akun, Kewenangan, Program, Output, Lokasi,
Bank, Anggaran, Dana, Antar Entitas dan Cadangan. Dasar dari penetapan 12 kode
tersebut menjadi struktur Bagan Akun Standar adalah untuk pengecekan pagu anggaran
dan dasar penyusunan laporan keuangan.
Terkait dengan akuntansi dan pelaporan, terdapat tiga aplikasi yang berjalan saat ini, yaitu:
SIMAK-BMN, aplikasi persediaan, dan aplikasi SAK. Ketiga aplikasi tersebut akan
menghasilkan Laporan Keuangan Pemerinta Pusat (LKPP) tingkat Satker/KPA dimana
61
laporan ini terlebih dahulu harus di rekonsiliasi dengan KPPN sebelum diterbitkan atau
dikirimkan ke Kantor Pusat Kementerian/Lembaga untuk dikompilasi. Aplikasi Satker yang
akan dibangun akan mengintegrasikan ketiga fungsi aplikasi di atas untuk selanjutnya
dilakukan pencetakan laporannya. Laporan yang dihasilkan tidak hanya Laporan Keuangan
tingkat Instansi, tetapi juga Laporan Bendahara Pengeluaran sehingga terdapat integrasi
antara laporan keuangan dengan laporan pertanggungjawaban bendahara.
Disamping itu, terdapat juga fasilitas ‘pooling’ untuk satker yang bertugas mengumpulkan
Laporan Keuangan Satker yang menjadi cakupan di wilayahnya. Aplikasi Satker juga
diberikan proses tambahan yaitu konsolidasi data kiriman hasil rekonsiliasi tingkat Satker,
tingkat wilayah, tingkat Eselon I dan tingkat Kementerian/Lembaga. Konsolidasi laporan
tersebut digabung secara hierarkis dimulai dari akun, kelompok akun, dan kelompok
belanja.
Dari penjelasan tersebut diatas, maka Aplikasi Satker harus dapat mencakup semua proses
akuntansi dan pelaporan, sehingga proses bisnis yang terkait dengan akuntansi dan
pelaporan dijelaskan sebagai berikut :
ii. Akuntansi dan Pelaporan
 Aplikasi Satker harus menyediakan interface konsolidasi dan penutupan buku besar;
 Aplikasi Satker harus menyediakan interface pembuatan ADK rekonsiliasi;
 Aplikasi Satker harus menyediakan interface penyesuaian data rekonsiliasi;
 Aplikasi Satker harus menyediakan interface pembuatan Laporan Keuangan Tingkat
Instansi;
 Aplikasi Satker harus menyediakan interface pembuatan ADK Laporan Keuangan
Tingkat Instansi.
iii. Pencatatan dan penatausahaan Barang Milik Negara
 Aplikasi Satker harus menyediakan interface perekaman barang persediaan;
 Aplikasi Satker harus menyediakan interface pencatatan sata asset ;
62
 Aplikasi Satker harus menyediakan interface konsolidasi BMN dalam neraca;
 Aplikasi Satker harus menyediakan interface perekaman Kartu Inventasis Barang;
 Aplikasi Satker harus menyediakan interface pengecekan asset tetap yang
dihapuskan;
 Aplikasi Satker harus menyediakan interface KIB, DBR, dan DBL.
iv. Pelaporan
 Aplikasi Satker harus menyediakan interface upload data LKPP satker, wilayah, dan
eselon I;
 Aplikasi Satker harus menyediakan interface kompilasi data LKPP satker, wilayah, dan
eselon I;
 Aplikasi Satker harus menyediakan interface pencetakan laporan keuangan wilayah,
eselon I, dan kementerian/ lembaga;
 Aplikasi Satker harus menyediakan interface pembuatan ADK wilayah, eselon I, dan
kementerian/lembaga.
b. Modul Manajemen Referensi
Modul Manajemen Referensi mencakup pengelolaan seluruh referensi yang terkait dengan
Sistem Aplikasi Keuangan Tingkat Instansi. Modul ini perlu dikelola secara khusus
mengingat dinamisnya perubahan data-data referensi. Beberapa data referensi yang
sering mengalami perubahan adalah sebagai berikut :
i. Referensi satker, bagian anggaran dan eselon I yang dikelola oleh Ditjen Anggaran ;
ii. Referensi akun yang dikelola oleh Ditjen Perbendaharaan ;
iii. Referensi loan dan hibah yang dikelola oleh Ditjen Pengelolaan Utang ;
iv. Referensi perbankan yang dikelola oleh Bank Indonesia;
v. Referensi Program, Kegiatan, Output, lokasi dan lain – lain.
Selanjutnya proses update data referensi dilakukan setelah terlebih dahulu diunduh dari
Portal SPAN, dimana proses update tersebut dilakukan pada masing-masing Satker. Untuk
63
memastikan bahwa satker telah memakai update versi terakhir, pada menu utama aplikasi
Satker harus dicantumkan ‘status versi update referensi’. Dengan demikian diharapkan
satker dapat mendeteksi lebih dini status update referensi terakhirnya. Apabila terdapat
satker yang belum melakukan update referensinya maka aplikasi akan memberikan pesan
berupa notifikasi bahwa update referensi belum dilakukan.
Karakteristik SAKTI
a. Sistem Aplikasi Keuangan Tingkat Instansi (SAKTI) meliputi seluruh proses pengelolaan
keuangan negara pada SATKER dimulai dari proses Penganggaran, Pelaksanaan dan
Pelaporan.
b. SAKTI akan digunakan oleh satuan kerja yang tersebar diseluruh Indonesia yang
memiliki karakteristik yang beragam, mulai dari yang memiliki fasilitas yang sangat
lengkap sampai dengan fasilitas yang sangat minim.
c. SAKTI merupakan gabungan beberapa aplikasi yang keberadaan sebelumnya tersebar
pada beberapa kewenangan, seperti bendahara, KPB, PPK, dan PPSPM
d. Kewajiban membuat laporan ada pada sisi satuan kerja karena merupakan salah satu
entitas akuntansi, yaitu unit pemerintah pengguna anggaran atau pengguna barang
yang berkewajiban untuk menyelenggarakan kegiatan akuntansi dan menyusun laporan
keuangan untuk digabungkan pada entitas pelaporan
AKUNTANSI DAN PELAPORAN pada SPAN
1. Pengertian dan Konsep Dasar
General Ledger merupakan inti dari sistem kerangka pengelolaan keuangan Negara yang
terintegrasi. Seluruh transaksi keuangan yang diinput ke dalam sistem akan diposting ke
dalam General Ledger sesuai dengan siklus pengelolaan keuangan Negara sehingga GL
merupakan sumber data bagi penyusunan laporan keuangan pemerintah. Penyempurnaan
proses bisnis GL di dalam SPAN adalah GL terintegrasi terpusat, sehingga transaksi
subledger di tiap-tiap KPPN selaku operating units akan terposting ke dalam GL yang
terintegrasi.
64
Berkaitan dengan proses bisnis akuntansi dan pelaporan, dalam kerangka SPAN, proses
penyusunannya dilakukan oleh aplikasi tunggal sehingga diperlukan suatu teknologi
informasi dan database terpusat yang dapat diandalkan untuk mencapai tujuan
pengelolaan keuangan negara, agar dapat menyediakan data transaksi keuangan yang
lengkap, dapat diakses setiap saat, dan terpadunya sistem operasional akuntansi dan
pelaporan. Di samping itu, dilakukan juga restrukturisasi Bagan Akun Standar (BAS) yang
menjadi backbone bagi proses pengelolaan keuangan, sehingga pengembangan proses
bisnis akuntansi dan pelaporan sebagai bagian dari program SPAN dimaksudkan untuk
mencapai tujuan reformasi pengelolaan keuangan negara secara menyeluruh.
Bagan Akun Standar
(BAS) digunakan untuk
penjurnalan saat terjadi
transaksi pada Subledger
Transaction sehingga
transaksi dicatat pada
Subledger accounting
akrual dan kas yang
kemudian akan diposting
ke kedua GL.
2. Proses Bisnis Akuntansi dan Pelaporan
Secara umum, penyempurnaan proses bisnis di bidang akuntansi dan pelaporan pada
SPAN meliputi hal-hal sebagai berikut:
1. Penggunaan dua pencatatan dalam satu sistem akuntansi, berupa catatan akrual
dan kas.
2. Struktur Bagan Akun Standar memasukan informasi output.
65
3. Menerapkan manajemen komitmen
4. Laporan keuangan berbasis akrual
5. Laporan Manajerial disusun dari satu database
6. Inisiasi laporan keuangan berbasis GFS
7. Rekonsiliasi berbasis internet
8. Integrasi Laporan keuangan dengan laporan kinerja
9. Penggunaan single database dalam pelaporan BUN.
Berdasarkan poin-poin penyempurnaan di atas, maka implementasi akuntansi akrual
dengan menggunakan aplikasi SPAN akan membahas hal-hal sebagai berikut:
a. Basis Penganggaran dan Akuntansi
Dalam siklus pengelolaan keuangan negara, penganggaran yang didahului dengan
perencanaan, merupakan tahapan penting yang mendasari kegiatan Pemerintah. Basis
anggaran yang digunakan saat ini adalah penganggaran berbasis kas, yang berarti setiap
anggaran yang dilaksanakan didasarkan pada penerimaan dan pengeluaran kas.
Penganggaran berbasis kas merupakan estimasi atau taksiran penerimaan dan
pengeluaran negara yang dalam APBN menggunakan terminologi pendapatan, belanja dan
pembiayaan, sehingga penganggaran berbasis kas dapat mengukur realisasi anggaran
dengan adanya pelaporan berbasis kas dalam bentuk laporan realisasi anggaran dan
laporan perubahan saldo anggaran lebih (SAL). Basis kas dalam penganggaran akan tetap
digunakan dengan beberapa pertimbangan antara lain lebih mudah digunakan
dibandingkan basis akrual, lebih sederhana penyajian informasinya, dan persetujuan DPR
atas anggaran berbasis kas, walaupun Undang-Undang keuangan negara mengindikasikan
kemungkinan penggunaan anggaran berbasis akrual dalam beberapa pasal-pasalnya,
seperti pada penjelasan penerimaan, pengeluaran, pendapatan dan belanja.
Perubahan fundamental di bidang penganggaran dapat dilihat dari adanya perubahan
kebijakan
penganggaran
dari
pengganggaran
berbasis
masukan
(input)
menjadi
penganggaran berbasis kinerja (performance based budgeting). Penganggaran berbasis
66
kinerja ini merupakan suatu model penganggaran yang bertujuan untuk menghubungkan
antara alokasi sumber daya dalam bentuk anggaran dengan kinerja untuk mencapai tujuan
organisasi (Diamond, 2003). Hal ini disebabkan bahwa penganggaran berbasis input tidak
dapat menyediakan informasi yang diperlukan Pemerintah mengenai efisiensi dan efektivitas
operasional Pemerintah (Van der Hoek, 2005). Dengan demikian, penganggaran berbasis
kinerja akan memberikan dampak yang lebih baik berupa adanya informasi mengenai
kegiatan operasional Pemerintah berupa realisasi kegiatan dengan alokasi sumber daya yang
dibutuhkan dalam melaksanakan kegiatan tersebut.
Penganggaran berbasis kinerja merupakan amanat Undang-Undang Keuangan Negara.
Berdasarkan UU Nomor 17 tahun 2003 tentang Keuangan Negara, struktur anggaran belanja
negara dirinci menurut Fungsi, Sub-fungsi, Organisasi, Program, Kegiatan, dan Jenis Belanja.
Selain itu, dalam Undang-Undang tersebut juga diamanatkan adanya transparansi dan
akuntabilitas keuangan negara yang diwujudkan melalui penjabaran prestasi kerja dari
setiap Kementerian Negara/Lembaga.
Laporan Realisasi Anggaran masing-masing Kementerian/Lembaga selain menyajikan realisasi
pendapatan dan belanja, juga menjelaskan prestasi kerja Kementerian Negara/Lembaga
sehingga pelaporan keuangan akan disertai dengan pelaporan kinerja sesuai dengan
pasal 27 Pertauran Pemerintah nomor 8 tahun 2006 tentang Pelaporan Keuangan dan
Kinerja Instansi Pemerintah. Implikasi dari regulasi tersebut dalam restrukturisasi
program dan kegiatan adalah pengelolaan dan pelaksanaan anggaran yang berbasis
kinerja. Dalam restrukturisasi program dan kegiatan, seluruh program dan kegiatan
dilengkapi dengan indikator kinerja beserta anggarannya, untuk digunakan sebagai alat
ukur pencapaian tujuan pembangunan yang efektif dan efisien secara teknis operasional
serta dalam pengalokasian sumber dayanya.
Terkait dengan penganggaran, maka terdapat perubahan dalam basis akuntansi
pemerintah yang digunakan. Basis akuntansi merupakan salah satu prinsip akuntansi untuk
menentukan periode pengakuan dan pelaporan suatu transaksi ekonomi dalam laporan
67
keuangan. Ada dua basis utama dalam pencatatan transaksi keuangan untuk menghasilkan
laporan keuangan, Basis Kas dan Basis Akrual. Basis kas akan mencatat transaksi keuangan
pada saat kas diterima/dikeluarkan. Sementara itu, basis akrual mencatat transaksi pada
saat terjadinya pendapatan atau belanja walaupun kas belum diterima/dikeluarkan. Basis
ini sangat umum digunakan dalam praktek bisnis di sektor swasta. Namun demikian, basis
akrual dalam sektor publik juga sudah banyak digunakan oleh beberapa negara, antara lain
Australia, New Zealand, dan Inggris.
Dalam konteks akuntansi pemerintah berdasarkan UU No. 17 tahun 2003 tentang
Keuangan Negara, penerimaan diakui pada saat kas diterima/masuk ke Kas Negara,
sebaliknya pengeluaran diakui pada saat kas keluar dari Kas Negara. Basis Kas tersebut
yang selama ini digunakan dalam Sistem Akuntansi Pemerintah kita saat ini, khususnya
untuk transaksi penerimaan dan pengeluaran dalam rangka penyusunan Laporan Realisasi
Anggaran (LRA) maupun Laporan Arus Kas (LAK). Sedangkan dalam penyusunan Neraca
digunakan basis akrual, berdasarkan data transaksi kas yang terjadi. Basis akuntansi
gabungan semacam inilah yang akhirnya dikenal dengan Basis Kas Menuju Akrual.
Dalam SPAN, pengembangan proses bisnis akuntansi dan pelaporan di masa mendatang
akan menggunakan basis akrual, dimana transaksi akan diakui dan dicatat pada saat
terjadinya walaupun kas belum masuk ke rekening kas negara atau keluar dari kas negara.
Hal ini merupakan implementasi dari amanat Undang-Undang Keuangan Negara. UndangUndang Nomor 17 tahun 2003 pasal 1 menyebutkan bahwa “keuangan negara adalah
semua hak dan kewajiban negara yang dapat dinilai dengan uang, serta segala sesuatu baik
berupa uang maupun berupa barang yang dapat dijadikan milik negara berhubung dengan
pelaksanaan hak dan kewajiban tersebut”. Pasal tersebut secara tersirat mengamanatkan
konsep akrual karena adanya pengakuan terhadap hak dan kewajiban yang dapat dinilai
dengan uang ke dalam keuangan negara.
Dengan demikian, tujuan penerapan basis akuntansi akrual pada dasarnya untuk
memperoleh informasi yang tepat atas jasa yang diberikan pemerintah dengan lebih
68
transparan. Hal ini juga didukung dengan alasan-alasan penggunaan basis akrual
diantaranya adalah sebagai berikut:
1. Akuntansi berbasis kas tidak menghasilkan informasi yang cukup – misal transaksi non
kas - untuk pengambilan keputusan ekonomi misalnya informasi tentang hutang dan
piutang, sehingga penggunaan basis akrual sangat disarankan.
2. Hanya akuntansi berbasis akrual menyediakan informasi yang tepat untuk
menggambarkan biaya operasi yang sebenarnya (full costs of operation), misalnya
keputusan apakah suatu pekerjaan harus dikontrakkan atau dilakukan secara swa
kelola.
3. Hanya akuntansi berbasis akrual yang dapat menghasilkan informasi yang dapat
diandalkan dalam informasi aset dan kewajiban.
4. Hanya akuntansi berbasis akrual yang menghasilkan informasi keuangan yang
komprehensif tentang pemerintah, misalnya penghapusan hutang yang tidak ada
pengaruhnya di laporan berbasis kas.
b. Kebijakan Akuntansi
Kebijakan akuntansi akrual mengacu pada basis penganggaran dan basis akuntansi yang
digunakan oleh Pemerintah Pusat. Berdasarkan urutan pencatatan, kebijakan akuntansi
tersebut secara garis besar dibedakan atas:
1. Anggaran
Pencatatan anggaran dibedakan atas pencatatan saat anggaran disahkan dan anggaran
dialokasikan. Pada pencatatan anggaran yang disahkan, UU APBN menjadi dasar
pencatatan. Rincian atas APBN yang memuat detail dari anggaran serta dokumen yang
dipersamakan, seperti rincian APBN-P merupakan dokumen sumber yang digunakan
sebagai dasar pencatatan APBN. Rincian APBN tersebut diakui pada saat dokumen
tersebut dicatat oleh unit yang memiliki fungsi perbendaharaan.
Setelah pencatatan anggaran saat APBN, dilakukan pencatatan atas anggaran yang
dialokasikan. Mekanisme pencatatan anggaran yang dialokasikan menggunakan DIPA dan
69
dokumen yang dipersamakan, seperti revisi atas DIPA, sebagai dasar pencatatan DIPA.
Data anggaran yang dialokasikan diakui pada saat dokumen tersebut dicatat oleh
pengguna anggaran.
2. Komitmen
Komitmen dibedakan atas transaksi keuangan yang memerlukan kontrak dan tidak
memerlukan kontrak. Dokumen sumber yang menjadi dasar pencatatan kontrak adalah
nomor registrasi kontrak yang dikeluarkan oleh unit yang memiliki fungsi perbendaharaan.
Nomor tersebut juga menjadi dasar pencatatan komitmen pada pengguna anggaran,
sehingga pencatatan kontrak dilakukan sebelum adanya realisasi anggaran. Transaksi yang
memerlukan pencatatan kontrak meliputi belanja modal yang menghasilkan aset tetap,
belanja barang yang menghasilkan persediaan dan lain-lain.
Sedangkan pada transaksi yang tidak memerlukan kontrak, dokumen sumber yang
digunakan sebagai dasar pencatatan adalah nomor register nonkontrak yang dikeluarkan
oleh unit yang memiliki fungsi perbendaharaan. Nomor tersebut juga menjadi dasar
pencatatan komitmen pada pengguna anggaran, sehingga pencatatan nonkontrak
dilakukan sebelum adanya realisasi anggaran. Contoh dari transaksi nonkontrak adalah
belanja gaji.
3. Pendapatan
a. Pendapatan LO
Berdasarkan basis akuntansi yang digunakan, pendapatan dibedakan atas pendapatan
yang diakui secara akrual dan pendapatan secara kas. Pendapatan akrual merupakan hak
pemerintah yang diakui sebagai pendapatan dalam tahun anggaran yang bersangkutan.
Pendapatan yang diakui secara akrual terdiri dari pendapatan diterima dimuka dan
pendapatan LO. Pendapatan diterima dimuka adalah pendapatan atas suatu transaksi yang
telah diterima oleh Pemerintah, namun wajib setor belum menerima manfaat dari
Pemerintah. Pendapatan LO merupakan pendapatan yang diakui secara basis akrual,
sedangkan pendapatan LRA adalah pendapatan yang diakui secara basis kas. Pendapatan
70
LO merupakan pendapatan yang diakui pada saat timbulnya hak untuk menagih
pendapatan dan/atau adanya aliran masuk sumber daya ekonomi.
Pendapatan LO dibedakan atas pendapatan yang diperoleh berdasarkan peraturan
perundang-undangan dan pendapatan yang diperoleh sebagai imbalan atas pelayananyang
telah diselesaikan. Pendapatan LO yang diperoleh berdasarkan peraturan perundangundangan diakui pada saat timbulnya hak untuk menagih pendapatan, sedangkan
pendapatan-LO yang diperoleh sebagai imbalan atas suatu pelayanan yang telah selesai
diberikan berdasarkan peraturan perundang-undangan, diakui pada saat timbulnya hak
untuk menagih imbalan. Selain itu, terdapat pendapatan-LO yang diakui pada saat
direalisasi adalah hak yang telah diterima oleh pemerintah tanpa terlebih dahulu adanya
penagihan.
Pendapatan LO dicatat berdasarkan azas bruto. Azas bruto merupakan pencatatan dengan
membukukan pendapatan secara bruto, yaitu nilai yang diakui sebagai pendapatan dan
tidak mencatat jumlah netto, yang merupakan nilai setelah dikompensasikan dengan
pengeluaran.
Untuk pengembalian pendapatan, pengembalian yang sifatnya normal dan berulang atas
pendapatan-LO pada periode penerimaan maupun pada periode sebelumnya dibukukan
sebagai pengurang pendapatan, misalnya pada pengembalian pajak.
Sementara itu, untuk koreksi dan pengembalian yang sifatnya tidak berulang atas
pendapatan LO yang terjadi pada periode penerimaan pendapatan dibukukan sebagai
pengurang pendapatan pada periode yang sama, sedangkan koreksi dan pengembalian
yang sifatnya tidak berulang atas pendapatan-LO yang terjadi pada periode sebelumnya
dibukukan sebagai pengurang ekuitas pada periode ditemukannya koreksi dan
pengembalian tersebut.
71
Pendapatan LO akan menjadi komponen dari Laporan Operasional yang merupakan bagian
dari laporan pertanggungjawaban yang menggunakan basis akrual. Pendapatan LO
dibedakan atas:
1.
Pendapatan pajak
2.
Pendapatan bukan pajak
3.
Pendapatan hibah
Pendapatan yang sifatnya tidak rutin perlu dikelompokkan tersendiri dalam kegiatan non
operasional. Termasuk dalam pendapatan/beban dari kegiatan non operasional antara lain
surplus/defisit penjualan aset non lancar, surplus/defisit penyelesaian kewajiban jangka
panjang, dan surplus/defisit dari kegiatan non operasional lainnya
Transaksi pendapatan LO dalam bentuk barang/jasa harus dilaporkan dalam Laporan
Operasional dengan cara menaksir nilai wajar barang/jasa tersebut pada tanggal transaksi.
Selain itu, transaksi ini harus diungkapkan sedemikian rupa pada Catatan atas Laporan
Keuangan sehingga dapat memberikan semua informasi yang relevan mengenai bentuk
dari pendapatan LO.
b.
Pendapatan LRA
Pendapatan LRA merupakan pendapatan yang diakui secara basis kas, sehingga
pendapatan LRA diakui pada saat kas diterima pada kas negara. Dokumen sumber yang
digunakan sebagai dasar pencatatan pendapatan LRA adalah bukti penerimaan negara
yang mencatat pendapatan LRA pada saat diterimanya kas. Pendapatan LRA akan menjadi
komponen dari Laporan Realisasi Anggaran yang merupakan bagian dari laporan
pertanggungjawaban yang menggunakan basis kas.
Pendapatan LRA dibedakan atas:
1.
Pendapatan pajak
2.
Pendapatan bukan pajak
3.
Pendapatan hibah
72
Pendapatan LRA dicatat berdasarkan azas bruto. Azas bruto merupakan pencatatan
dengan membukukan pendapatan secara bruto, yaitu nilai yang diakui sebagai pendapatan
dan tidak mencatat jumlah netto, yang merupakan nilai setelah dikompensasikan dengan
pengeluaran.
Pengembalian pendapatan yang sifatnya sistemik dan berulang atas penerimaan
pendapatan LRA pada periode penerimaan maupun pada periode sebelumnya dibukukan
sebagai pengurang pendapatan LRA. Sementara itu, koreksi dan pengembalian yang
sifatnya tidak berulang atas pendapatan LRA yang terjadi pada periode penerimaan
pendapatan LRA dibukukan sebagai pengurang pendapatan LRA pada periode yang sama,
sedangkan koreksi dan pengembalian yang sifatnya tidak berulang atas pendapatan LRA
yang terjadi pada periode sebelumnya dibukukan sebagai pengurang Saldo Anggaran Lebih
pada periode ditemukannya koreksi dan pengembalian tersebut.
Transaksi pendapatan LRA dalam bentuk barang dan jasa harus dilaporkan dalam Laporan
Realisasi Anggaran dengan cara menaksir nilai barang dan jasa tersebut pada tanggal
transaksi. Selain itu, transaksi ini harus diungkapkan pada Catatan atas Laporan Keuangan
sehingga dapat memberikan semua informasi yang relevan mengenai bentuk dari
pendapatan, belanja, dan pembiayaan yang diterima. Contoh transaksi pendapatan LRA
dalam bentuk barang dan jasa adalah hibah dalam wujud barang, barang rampasan, dan
jasa konsultansi.
4. Belanja
a. Beban
Berdasarkan basis akuntansinya, belanja dibedakan atas Beban dan Belanja. Beban adalah
pengakuan adanya pengeluaran pemerintah yang timbul pada saat adanya kewajiban
untuk membayar, terjadinya konsumsi aset, dan terjadinya penurunan manfaat ekonomis
atau potensi jasa. Saat timbulnya kewajiban adalah saat terjadinya peralihan hak dari pihak
lain ke pemerintah tanpa diikuti keluarnya kas dari kas umum negara/daerah. Contohnya
73
tagihan rekening telepon dan rekening listrik yang belum dibayar pemerintah termasuk
kategori kewajiban karena telah timbul kewajiban, walaupun kas belum keluar dari kas
negara.
Yang dimaksud dengan terjadinya konsumsi aset adalah saat pengeluaran kas kepada
pihak lain yang tidak didahului timbulnya kewajiban dan/atau konsumsi aset nonkas dalam
kegiatan operasional pemerintah. Sedangkan terjadinya penurunan manfaat ekonomis
atau potensi jasa terjadi pada saat penurunan nilai aset sehubungan dengan penggunaan
aset bersangkutan/berlalunya waktu. Contoh penurunan manfaat ekonomis atau potensi
jasa adalah penyusutan aset tetap atau amortisasi aset tak berwujud.
Klasifikasi ekonomi pada prinsipnya mengelompokkan berdasarkan jenis beban. Klasifikasi
ekonomi untuk pemerintah pusat yaitu beban pegawai, beban barang, beban penyusutan
aset tetap/amortisasi, beban bunga, beban subsidi, beban hibah, beban bantuan sosial,
dan beban lain-lain. Klasifikasi ekonomi untuk pemerintah daerah terdiri dari beban
pegawai, beban barang, beban penyusutan aset tetap/amortisasi, beban bunga, beban
subsidi, beban hibah, beban bantuan sosial, dan beban tak terduga.
Beban Transfer adalah beban berupa pengeluaran uang atau kewajiban untuk
mengeluarkan uang dari entitas pelaporan kepada suatu entitas pelaporan lain yang
diwajibkan oleh peraturan perundang-undangan, yang diakui secara akrual. Beban transfer
ini berbeda dengan Transfer, yang merupakan pengakuan pengeluaran uang secara kas
dari Pemerintah Pusat ke Pemerintah Daerah.
Koreksi atas beban, termasuk penerimaan kembali beban, yang terjadi pada periode beban
dibukukan sebagai pengurang beban pada periode yang sama. Apabila diterima pada
periode berikutnya, koreksi atas beban dibukukan dalam pendapatan lain-lain.
74
b. Belanja
Belanja diakui pada saat terjadinya pengeluaran dari Rekening Kas Umum Negara/Daerah.
Khusus pengeluaran melalui bendahara pengeluaran pengakuannya terjadi pada saat
pertanggungjawaban atas pengeluaran tersebut disahkan oleh unit yang mempunyai
fungsi perbendaharaan. Sedangkan, koreksi
atas
pengeluaran belanja (penerimaan
kembali belanja) yang terjadi pada periode pengeluaran belanja dibukukan sebagai
pengurang belanja pada periode yang sama. Apabila diterima pada periode berikutnya,
koreksi atas pengeluaran belanja dibukukan dalam pendapatan-LRA dalam pos
pendapatan lain-lain
Transaksi pendapatan-LRA, belanja, dan pembiayaan dalam bentuk barang dan jasa harus
dilaporkan dalam Laporan Realisasi Anggaran dengan cara menaksir nilai barang dan jasa
tersebut pada tanggal transaksi. Di samping itu, transaksi semacam ini juga harus
diungkapkan sedemikian rupa pada Catatan atas Laporan Keuangan sehingga dapat
memberikan semua informasi yang relevan mengenai bentuk dari pendapatan, belanja,
dan pembiayaan yang diterima. Contoh transaksi berwujud barang dan jasa adalah hibah
dalam wujud barang, barang rampasan, dan jasa konsultansi.
5. Pembiayaan
Pembiayaan adalah seluruh transaksi keuangan pemerintah, baik penerimaan maupun
pengeluaran, yang perlu dibayar atau akan diterima kembali, yang dalam penganggaran
pemerintah terutama dimaksudkan untuk menutup defisit dan atau memanfaatkan
surplus anggaran. Pembiayaan dibedakan atas Penerimaan Pembiayaan dan Pengeluaran
Pembiayaan. Penerimaan pembiayaan antara lain dapat berasal dari pinjaman, dan hasil
divestasi. Sementara, pengeluaran pembiayaan antara lain digunakan untuk pembayaran
kembali pokok pinjaman, pemberian pinjaman kepada entitas lain, dan penyertaan modal
oleh pemerintah.
Penerimaan pembiayaan adalah semua penerimaan Rekening Kas Umum Negara/Daerah
antara lain berasal dari penerimaan pinjaman, penjualan obligasi pemerintah, hasil
75
privatisasi perusahaan negara/daerah, penerimaan kembali pinjaman yang diberikan
kepada fihak ketiga, penjualan investasi permanen lainnya, dan pencairan dana cadangan.
Penerimaan pembiayaan diakui pada saat diterima pada Rekening Kas Umum
Negara/Daerah. Akuntansi penerimaan pembiayaan dilaksanakan berdasarkan azas bruto,
yaitu dengan membukukan penerimaan bruto, dan tidak mencatat jumlah netonya
(setelah dikompensasikan dengan pengeluaran).
Pengeluaran pembiayaan adalah semua pengeluaran Rekening Kas Umum Negara/Daerah
antara lain pemberian pinjaman kepada pihak ketiga, penyertaan modal pemerintah,
pembayaran kembali pokok pinjaman dalam periode tahun anggaran tertentu, dan
pembentukan dana cadangan. Pengeluaran pembiayaan diakui pada saat dikeluarkan dari
Rekening Kas Umum Negara/Daerah
c. Teknik Akuntansi
Di dalam SPAN dikenal penerapan akuntansi komitmen. Akuntansi komitmen tersebut
bertujuan sebagai kontrol terhadap budget sehingga dapat diketahui fund availability dan
hal tersebut tidak mempengaruhi Laporan Keuangan. Hal ini merupakan suatu usaha
pencatatan yang dilakukan Pemerintah terhadap suatu kontrak ke dalam siklus akuntansi
pemerintah saat ini. Dalam teknik akuntansi Encumbrance dalam Oracle, terdapat 3 (tiga)
tipe jurnal, berupa jurnal anggaran, jurnal komitmen, dan jurnal realisasi. Dengan tipe
jurnal yang berbeda tersebut, maka suatu transaksi, seperti belanja, akan dicatat pada
ketiga tipe jurnal tersebut dengan menggunakan kode akun yang sama. Hal ini akan
membuat jumlah kode akun menjadi lebih sedikit dibandingkan dengan kode akun dalam
budgetary accounting, namun tetap dapat menggunakan kode akun yang sama seperti
pada aplikasi saat ini.
Encumbrance accounting digunakan dalam teknik pencatatan akuntansi dengan
didasarkan pada beberapa pertimbangan antara lain:
76
a). Model encumbrance accounting sesuai dengan struktur akun yang ada saat ini,
sehingga pencatatan APBN, DIPA, komitmen dan realisasi menggunakan akun yang
sama dengan uraian akun yang berbeda.
b). Adanya keterkaitan antara penganggaran, komitmen dan realisasi anggaran.
Selain encumbrance accounting, di dalam SPAN dikenal konsep due to (Ditagihkan ke
entitas lain) dan due from (Ditagihkan dari entitas lain). Hal ini didasarkan pada prinsip
dalam UU Keuangan Negara bahwa Kementerian Negara/Lembaga selaku pengguna
anggaran tidak memegang kas, sehingga pencairan dana/pembayaran dilakukan oleh
Kuasa Bendahara Umum Negara, yaitu Dit Pengelolaan Kas Negara dan KPPN, selaku
pemilik rekening. Akun Ditagihkan ke entitas lain_KPPN dan Ditagihkan dari entitas
lain_Satker merupakan akun sementara (temporary) karena pengguna anggaran tidak
berwenang untuk mengotorisasi pembayaran. Ditagihkan ke entitas lain KPPN merupakan
tagihan satker ke KPPN sehingga seolah olah timbul tagihan kepada negara, sedangkan
Ditagihkan dari entitas lain_Satker merupakan utang Pemerintah kepada satker yang harus
dibayar, baik melalui Dit. PKN maupun KPPN. Hal ini berdampak pada timbulnya jurnal
pengakuan tagihan ke KPPN pada pencatatan satker, dan jurnal pengakuan utang yang
harus dibayar kepada satker pada pencatatan KPPN.
d. Sistem Akuntansi Pemerintah Pusat
Penggunaan sebuah sistem akuntansi dalam penyusunan laporan keuangan pemerintah
sangatlah penting. Hal ini juga sejalan dengan amanat peraturan perundangan, yaitu
Peraturan Pemerintah Nomor 8 tahun 2006 Pasal 6 ayat 2 yang menyebutkan bahwa
laporan keuangan dihasilkan dari suatu sistem akuntansi keuangan pemerintah. Sistem
akuntansi juga merupakan suatu alat dalam sebuah sistem pengendalian intern. Sistem
akuntansi diciptakan sebagai salah satu upaya konkrit untuk mewujudkan transparansi dan
akuntabilitas
pengelolaan
keuangan
negara
sehingga
dihasilkan
laporan
pertanggungjawaban pengelolaan keuangan negara yang andal, dan tepat waktu. Sistem
akuntansi disusun dengan mengikuti standar akuntansi pemerintah.
77
Pada dasarnya sistem akuntansi yang akan dikembangkan dengan berbasis akrual adalah
sistem akuntansi dengan dua sudut pandang, yaitu sistem akuntansi dari sudut pandang
pengguna dana APBN (cash user) yakni kementerian/lembaga dan sistem akuntansi dari
sudut pandang pemilik dana APBN (cash owner) yang dalam hal ini adalah kementerian
keuangan sebagai pemilik rekening Kas Umum Negara (KUN). Dua sub sistem ini tetap
diperlukan sepanjang masih ada pemisahan entitas pengguna dana dan entitas pemilik
dana, sehingga akan terdapat Sistem Akuntansi Keuangan Tingkat Instansi (SAKTI) dan
Sistem Akuntansi Bendahara Umum Negara (SA-BUN). Secara umum, sistem akuntansi
pemerintah pusat akan terdiri dari SAKTI dan SABUN, dimana SABUN akan terdiri dari
Sistem Akuntansi Pusat dan Sistem Akuntansi BUN. Output dari dua sistem akuntansi
tersebut selanjutnya akan dikonsolidasi menjadi satu Laporan Keuangan Pemerintah Pusat
(LKPP).
SAKTI ditujukan untuk membantu Kementerian/Lembaga dalam melakukan penyusunan
laporan keuangan. UU No. I/2004 Pasal 55 ayat 2 (a) menyebutkan bahwa
Menteri/Pimpinan Lembaga selaku pengguna anggaran menyusun laporan keuangan
disampaikan ke Presiden melalui Mneteri Keuangan. Disamping itu, pasal 54 ayat 1
menyebutkan bahwa Pengguna anggaran bertanggung jawab formal material kepada
presiden atas pelaksanaan kebijakan anggaran yang berada dalam penguasaannya,
sehingga diperlukan penyelenggaraan sistem akuntansi di KL untuk membukukan
transaksi-transaksi yang terjadi di KL sebagai pengguna dana APBN. Sementara itu, sistem
akuntansi BUN diperlukan karena Kementerian Keuangan merupakan pemilik dana kas
pemerintah (KUN). Disamping itu, Kementerian Keuangan merupakan kuasa BUN yang
bertugas menyusun laporan keuangan pemerintah pusat.
e. Model Pencatatan
Berdasarkan kebutuhan pelaporan keuangan berbasis akrual dank as tersebut, maka
model sistem akuntansi pada SPAN akan berupa satu sistem akuntansi yang memiliki 2
(dua) pencatatan (dual recording), secara akrual dan secara kas.
78
Sistem akuntansi dengan dual recording ini akan mencatat transaksi berdasarkan
pemisahan dokumen sumbernya. Pada saat pengakuan akrual, maka transaksi, misalnya
pengakuan beban akan dicatat pada buku akrual, namun pada saat pembayaran, maka
akan dicatat pada kedua buku, buku kas dan buku akrual untuk mengakui adanya kas
keluar, sehingga walaupun beban telah diakui pada buku akrual, namun buku kas
mengakui belanja pada saat terjadi pembayaran.
Dampak dari integrasi sistem akuntansi pusat ini adalah adanya pemisahan informasi
berbasis akrual dan berbasis kas. Informasi berbasis akrual akan mengakomodir basis
akrual, sesuai dengan full accrual accounting yang diterapkan. Sedangkan basis kas akan
digunakan untuk menghasilkan informasi berbasis kas yang berguna untuk penyusunan
laporan keuangan berbasis kas seperti laporan realisasi anggaran.
Dampak dari perubahan tersebut adalah diperlukan metode pencatatan yang dapat
mengakomodir berbasis kas dan akrual. Oracle yang digunakan oleh SPAN akan
memfasilitasi penggunaan sub ledger accounting (SLA). SLA merupakan metode yang
memungkinkan penyesuaian jurnal pencatatan transaksi di subledger (seperti modul
pembayaran) untuk diposting ke modul GL. Dengan adanya SLA, maka kebutuhan
informasi berbasis akrual dank as akan menggunakan akun yang sama sehingga tidak
dibutuhkan BAS berbasis akrual dan BAS berbasis kas, melainkan cukup satu BAS berbasis
akrual (single BAS).
Perubahan tahapan penjurnalan akuntansi
Tahapan penjurnalan akuntansi terkait implementasi akuntansi akrual akan menjadi:
a. APBN
b. DIPA
c. Komitmen
d. Realisasi
e. Penyesuaian
f. Penutup
79
g. Koreksi
h. Konsolidasi
i. Koreksi setelah audit
Poin perubahan pada tahapan penjurnalan adalah adanya pencatatan komitmen, guna
memastikan ketersediaan dana atas kontrak-kontrak yang telah ditandatangani. Selain
itu, pada tahap realisasi akan terdapat saat pencatatan BAST, Resume tagihan dan SP2D.
Pada tahap BAST, Satker akan mengakui Aset Tetap dan/atau Persediaan, sedangkan pada
tahap Resume tagihan, Satker akan mencatat akrual atas pengakuan adanya Beban dan
Utang kepada Pihak Ketiga. Pada tahap SP2D, Satker akan mengakui adanya Belanja atas
pembayaran kepada pihak ketiga.
f. Bagan Akun Standar
Di dalam Integrated Financial Management and Information System (IFMIS) disebutkan
bahwa pendekatan dari pengelolaan keuangan Negara secara menyeluruh dapat
digambarkan dengan adanya proses bisnis dan sistem yang saling terhubung dan terkait
satu sama lain. Tahapan tersebut dimulai dengan adanya perencanaan penganggaran,
pencairan dana, akuntansi dan pelaporan, audit, dimana peraturan prosedur dan
kewenangan menghubungkan tahapan-tahapan tersebut. Implikasi dari integrasi sistem ini
adalah adanya komunikasi data, memastikan konsistensi dan mengurangi pengulangan.
Integrasi ini juga didukung dengan kemajuan teknologi informasi sehingga pilihan bentuk
teknologi informasi juga akan menentukan integrasi sistem tersebut.
Seperti yang diuraikan sebelumnya bahwa elemen kunci dalam mengintegrasikan
beberapa komponen tersebut di atas ada pada Chart Of Account (COA). COA merupakan
merupakan daftar kode yang digunakan suatu sistem untuk menelusuri transaksi. Setiap
akun didesign dengan kode yang unik, dan mewakili informasi tertentu. COA merupakan
informasi dan data yang digunakan untuk proses akuntansi, manajemen, dan penyediaan
laporan tertentu lainnya.
80
Di dalam SPAN, transaksi yang terekam di dalam Subledger Transaksi otomatis akan
terbentuk jurnal pada Subledger Accounting menggunakan Bagan Akun Standar yang telah
didefinisikan. Jurnal pada Subledger Accounting tersebut akan di posting ke General
Ledger. Hal ini menunjukkan bahwa kunci di dalam sistem berada pada Chart of Account
(COA) atau Bagan Akun Standar (BAS). BAS merupakan daftar akun yang digunakan sistem
untuk menelusuri transaksi keuangan. Setiap akun akan didesain dengan kode yang unik,
dan mewakili informasi tertentu. BAS juga merupakan informasi dan data yang digunakan
untuk proses akuntansi, manajemen, dan penyediaan laporan tertentu lainnya.
Secara khusus, Bagan Akun Standar berguna sebagai dasar laporan keuangan dan
pelaporan manajerial, merupakan inti dari sistem pengelolaan keuangan dimana terdapat
aliran data seluruh modul dan interface, menyediakan landasan dan ruang untuk
pengembangan sekaligus sebagai media penyimpanan baik current maupun historical
information, mendukung disiplin fiskal melalui pengaturan pengendalian dan kerangka
struktur pelaporan, dan mendukung proses pengambilan keputusan yang lebih baik
Di dalam SPAN, fungsi Bagan Akun Standar adalah menghubungkan beberapa modulmodul transaksi dengan akun-akun melalui terbentuknya jurnal-jurnal transaksi ketika
terjadi transaksi pada tiap-tiap modul. SPAN akan mengadopsi satu Bagan Akun Standar
(BAS) untuk Ledger akrual dan Ledger kas. Selain itu, terdapat pemisahan antara struktur
dan DFF (descriptive flexfield).
Pada struktur BAS, Oracle menempatkan kode-kode BAS menjadi suatu struktur dengan
pertimbangan bahwa kode-kode yang ada pada struktur BAS akan menjadi dasar bagi
pengecekan anggaran dan penyusunan laporan keuangan. Struktur BAS ini dikenal dengan
istilah segment, sedangkan kode-kode yang ada dalam suatu segment disebut value.
Selain segment dan value, juga terdapat DFF yang merupakan kode-kode yang ada dalam
setiap modul SPAN, namun penggunaannya terbatas hanya di modul tersebut, dan tidak
dapat digunakan oleh modul lain. Penggunaan DFF ini akan disesuaikan dengan kebutuhan
81
masing-masing modul SPAN. Hal ini berbeda dengan kode-kode dalam struktur BAS,
dimana kode-kode dalam struktur BAS dapat digunakan oleh setiap modul.
Selain itu, dalam Oracle juga digunakan konsep balancing segments, yang merupakan
segmen penyeimbang dalam struktur BAS. Balancing segment dalam struktur BAS adalah
kode satker, sehingga nantinya laporan keuangan dapat dihasilkan per satker.
Struktur Bagan Akun Standar beserta digitnya disajikan dalam table di bawah ini:
No
KLASIFIKASI
Digit
TUJUAN
ATRIBUT PELAPORAN
1
SATKER
6
LK PER KL
BA, Eselon1, Konsolidasi
Satker
2
KPPN
3
LK PER KPPN
3
AKUN
6
KLASIFIKASI EKONOMI
4
PROGRAM
3+2+2
KLASIFIKASI PROGRAM
5
OUTPUT
4+3
LAPORAN KINERJA
Kegiatan, Fungsi, Subfungsi,
Satuan
6
DANA
2+1+8
KLASIFIKASI DANA
No Register Utang dan Hibah
7
Bank
1+4
Bank, Arus Kas
KPPN
8
Kewenangan
1
Jenis Kewenangan
9
Lokasi
2+2
Tempat kegiatan
10
Anggaran
1
11
Antar entitas
6
12
Cadangan
6
Due-To and Due-From
Sumber: Modul Buku Besar dan BAS
g. Jurnal Standar Akuntansi Akrual
82
Terkait dengan penerapan accrual accounting di Indonesia, penyusunan jurnal akuntansi
akan mengacu pada peraturan perundangan yang ada. Sesuai dengan perdirjen Per01/PB/2005 tentang pedoman jurnal standar dan posting rule pada sistem akuntansi
pemerintah pusat, jurnal standar terdiri dari jurnal standar anggaran, saldo awal, realisasi,
dan penutup. Secara rinci, jurnal standar dapat dikelompokkan menjadi jurnal standar
APBN, jurnal standar DIPA, jurnal standar saldo awal, jurnal standar realisasi dan jurnal
standar penutup. Jurnal standar ini merupakan dasar pencatatan dan pemrosesan
transaksi anggaran, realisasi dan transaksi non anggaran, sedangkan posting rule
merupakan dasar perlakuan akuntansi atas suatu transaksi keuangan yang bertujuan untuk
menghasilkan laporan keuangan.
Untuk menghasilkan laporan keuangan, maka jurnal akuntansi akan mengacu pada sistem
akuntansi yang telah diintegrasikan. Pengkategorian jurnal akuntansi juga didasarkan pada
pembagian Sistem Akuntansi Pemerintah Pusat, sehingga jurnal akuntansi terdiri dari
jurnal akuntansi untuk SA BUN dan SAKTI.
h. Rekonsiliasi Laporan Keuangan
Penyempurnaan proses bisnis dalam Modul Pelaporan meliputi penyempurnaan
mekanisme pelaporan melalui penggunaan SPAN single database. Database yang
terintegrasi dalam lingkup Kementerian Keuangan sebagai Bendahara Umum Negara
(BUN) ini akan menghindarkan adanya information discrepancy
yang dihasilkan oleh
entitas‐entitas yang berbeda dalam lingkup BUN sebagaimana yang sering terjadi saat
ini. Selain itu, konsep ini akan mempercepat alur pelaporan karena entitas yang lebih
tinggi tidak lagi harus menunggu dari entitas di bawahnya untuk menerima laporan,
melainkan entitas tersebut bisa memenuhi sendiri laporan yang dibutuhkan dengan
langsung mengakses ke database. Dampak positif lainnya dari penggunaan single database
adalah adanya simplifikasi dalam proses rekonsiliasi laporan keuangan (penyederhanaan
level rekoniliasi). Namun demikian, konsekuensinya adalah perlunya penyempurnaan
prosedur rekonsiliasi di level terendah (KPPN‐Satker) yakni perlunya dilakukan reformulasi
prosedur rekonsiliasi.
83
Pengembangan lainnya dalam Modul Pelaporan adalah penyempurnaan format laporan
keuangan itu sendiri. Dalam konteks pengembangan SPAN, akan dihasilkan laporan
keuangan yang lebih lengkap. Disamping laporan keuangan berbasis kas yang
merupakan statutory report yaitu Laporan Realisasi Anggaran, juga akan dihasilkan laporan
keuangan berbasis akrual yang akan memberikan informasi keuangan yang lebih
komprehensif sehingga lebih relevan dan lebih bermanfaat untuk pengambilan keputusan.
Disamping itu, Modul Pelaporan juga akan menfasilitasi disusunnya sebuah laporan
keuangan pemerintah yang dapat menghasilkan statistik keuangan yang mengacu
kepada manual Statistik Keuangan Pemerintah (Government Finance Statistics atau
GFS). Laporan keuangan berbasis Sistem GFS ini dapat digunakan untuk memenuhi
kebutuhan analisis kebijakan dan kondisi fiskal, pengelolaan dan analisis perbandingan
antarnegara (cross country studies), kegiatan pemerintahan, dan penyajian statistik
keuangan pemerintah. Sebuah terobosan dalam penyusunan laporan internal juga menjadi
concern dan pemikiran dalam pengembangan proses bisnis Pelaporan. Konsep “User
Defined Reporting” merupakan sebuah gagasan yang layak dipertimbangkan untuk
memenuhi kebutuhan ini.
Untuk memperoleh laporan keuangan yang berkualitas, valid, andal dan tepat waktu,
diperlukan penyempurnaan proses pelaporan baik dari faktor data input maupun
proses pengolahan datanya. Selama ini sering terjadi adanya perbedaan laporan
antara KL dengan BUN baik di level terendah (KPPN & satker), level wilayah maupun level
teratas (kantor pusat). Salah satu penyebabnya adalah karena laporan dihasilkan dari dua
database yang berbeda. Meskipun telah dilakukan proses verifikasi dan rekonsiliasi antar
keduanya, namun hasilnya belum maksimal untuk menihilkan perbedaan.
Salah satu upaya menghilangkan perbedaan tersebut, laporan dari dua entitas tersebut di
atas (KL & BUN) diupayakan untuk bisa dihasilkan dari satu database yang sama. Dengan
single database, perbedaan laporan kedua enititas tersebut tidak akan terjadi lagi. Namun
sebenarnya dengan menggunakan satu database pun ada dua kemungkinan yang terjadi,
84
benar kedua-duanya atau salah kedua-duanya karena tidak adanya prosedur cross-check
antar dua laporan tersebut. Oleh karena itu, penggunaan single database juga harus
dibarengi dengan ketelitian dan kejelian mulai dari awal perekaman data.
Gambar 3.15 Rekonsiliasi saat ini
Sumber : Modul Pelaporan
Gambar 3.16 Rekonsiliasi setelah implementasi SPAN
Sumber: Modul Pelaporan
85
Dalam penyempurnaan proses bisnis pelaporan khususnya terkait dengan reformulasi
prosedur rekonsiliasi, ada beberapa hal yang perlu mendapat perhatian khusus, antara lain
penghapusan (tidak diharuskan) rekonsiliasi di tingkat wilayah dan eselon 1 memaksa
penyempurnaan pada prosedur rekonsiliasi di tingkat KPPN.
i. Konsolidasi Laporan Keuangan
Sejalan dengan penggunaan single database untuk Kantor Pusat Direktorat Jenderal
Anggaran, Kantor Pusat Direktorat Jenderal Perbendaharaan, Kanwil dan KPPN, modulmodul yang ada pada aplikasi SPAN akan menggunakan satu database sebagai pusat data.
Hal ini akan memudahkan proses pelaporan karena penggunaan single database sebagai
sumber data dapat mengurangi risiko ketidakakuratan data yang berpengaruh pada
keandalan informasi keuangan yang disajikan dalam laporan keuangan. Selain itu,
penggunaan single database akan mempercepat proses konsolidasi pelaporan karena
laporan dihasilkan dari satu sumber data sehingga waktu yang dibutuhkan untuk validitas
data akan lebih cepat.
j. Laporan Kinerja Instansi Pemerintah
Gambaran secara umum struktur sistem akuntansi ke depan menggunakan bagan Sistem
Akuntansi Pemerintah Pusat. Yang membedakan adalah pada SPAN akan menggunakan
dua pencatatan berupa catatan akrual dan catatan kas. Ledger akrual akan menghasilkan
Laporan Operasional (LO), Neraca, Laporan Arus Kas (LAK), dan Laporan Perubahan Ekuitas
(LPE); sedangkan ledger kas akan menghasilkan Laporan Realisasi Anggaran (LRA) dan
Laporan Perubahan Saldo Saldo Anggaran Lebih (LPSAL). Selain 7 (tujuh) laporan tersebut,
juga terdapat Laporan kinerja instansi pemerintah.
Dalam penyusunan laporan kinerja ini, SPAN akan menggunakan sistem akuntansi dan
database yang sama dengan penyusunan laporan keuangan. Hal ini dimaksudkan untuk
mempermudah Satker dalam penyampaian Laporan keuangan sehingga validitas data yang
digunakan dalam penyusunan laporan kinerja akan terjaga. Laporan kinerja yang dihasilkan
akan menghasilkan informasi hasil capaian dalam bentuk keluaran (output).
86
Proses integrasi laporan keuangan dan laporan kinerja dilaksanakan pada setiap Satker
dengan melakukan input atas data output dan transaksi keuangan ke dalam aplikasi SAKTI.
Laporan kinerja ini dihasilkan setiap akhir bulan dan disampaikan oleh Satker ke KPPN pada
saat yang bersamaan dengan periode rekonsiliasi laporan keuangan dengan KPPN. Laporan
kinerja baru dapat dihasilkan setelah terjadi rekonsiliasi dengan KPPN, sehingga laporan
kinerja bulan berjalan baru dapat dihasilkan pada bulan berikutnya karena proses
integrasinya pada akhir bulan dan setelah periode rekonsiliasi selesai dilaksanakan.
87
BAB IV
TEKNOLOGI DAN INFORMASI SPAN
SPAN dalam operasionalisasinya melibatkan tiga unit eselon I di lingkungan
Kementerian Keuangan yaitu Direktorat Jenderal Anggaran terkait dengan proses
Perencanaan Anggaran, Direktorat Jenderal Perbendaharaan terkait dengan Pelaksanaan
Anggaran, serta Sekretariat Jenderal melalui Pusat Sistem Informasi dan Teknologi
Keuangan (Pusintek), terkait dengan infrastruktur Teknologi Informasi.
Bagan 1
Ruang Lingkup Pengembangan Teknologi Informasi SPAN
Adapun ruang Lingkup Pengembangan Teknologi Informasi SPAN terdiri dari:
1. Penyediaan Pusat Data dan Pusat Pemulihan Data
2. Pemasangan Instalasi Kabel Komunikasi Data
3. Instalasi Wide Area Network dalam rangka Komunikasi Data
4. Penggunaan Aplikasi berbasis COTS
5. Penggunaan Collabortion Environment dengan aplikasi perkantoran
88
Terkait dengan aplikasi SPAN sendiri, yang digunakan adalah aplikasi dengan
menggunakan platform Enterprise resource planning (ERP) dan berbasis commercial offthe-shelf (COTS). COTS adalah program aplikasi yang dibuat secara khusus oleh
perusahaan penyedia software berdasarkan ‘best practices of business process’ pada
bidang bersangkutan, sehingga program aplikasi tersebut dapat digunakan secara umum
oleh semua institusi untuk menangani bidang bersangkutan. Dalam implementasi SPAN,
Aplikasi COTS yang digunakan adalah Oracle Financials yang merupakan bagian dari Oracle
Financial Management. Oracle Financial Management sendiri adalah salah satu produk
dari Oracle E-Business Suite Release 12.1.3. Database yang digunakan pada implementasi
SPAN ini adalah Oracle Database 11g.
Bagan 2
Tampilan Oracle E-Business Suite
Aplikasi SPAN terdiri atas modul-modul yang dapat dikelompokkan dalam tiga proses
yaitu:
a. Perencanaan Anggaran, yang terdiri atas Modul Penyusunan Anggaran (Budget
Preparation)
b. Pelaksanaan Anggaran, yang terdiri atas :
i. Modul Manajemen DIPA (Management of Spending Authority)
ii. Modul Manajemen Komitmen (Commitment Management)
89
iii. Modul Manajemen Pembayaran (Payment Management)
iv. Modul Penerimaan Negara (Government Receipt )
v. Modul Manajemen Kas (Cash Management)
c. Akuntansi dan Pelaporan, terdiri atas :
i. Modul Buku Besar dan Bagan Akun Standar (General Ledger and Chart of Accounts)
ii. Modul Pelaporan (Reporting)
Seperti penggunaan aplikasi pada umumnya, aplikasi SPAN juga memiliki user
management yang berfungsi untuk mengelola pengguna yang melakukan akses pada
aplikasi SPAN. Username Aplikasi SPAN adalah NIP pegawai yang memiliki hak dan
kewenangan masuk kedalam sistem dan Nama yang bersangkutan akan dijadikan sebagai
deskripsi pengguna.
Berdasarkan lingkupnya, maka pengguna aplikasi SPAN, terdiri dari:
1. Direktorat Jenderal Anggaran
2. Direktorat Jenderal Perbendaharaan (Kantor Pusat, Kanwil DJPBn dan KPPN)
3. BA 999 selaku konsolidator laporan keuangan BUN
Masih terkait dengan user management, salah satu prinsip keamanan sistem Informasi
adalah dengan menerapkan mekanisme Maker dan Checker, dimana dalam melakukan
sebuah transaksi setidaknya dibutuhkan dua orang untuk menyelesaikan transaksi
tersebut. Individu pertama bertugas untuk membuat transaksi sedangkan Individu yang
lain terlibat dalam melakukan otorisasi/ persetujuan. Disini pemisahan wewenang
memainkan peranan yang penting. Mekanisme ini dilakukan juga dalam Aplikasi SPAN,
dimana dalam menyelesaikan sebuah transaksi dibutuhkan tiga Individu yang terlibat,
yaitu:
90
a. Individu yang membuat transaksi (Maker)
b. Individu yang melakukan otorisasi (Checker)
c. Individu yang menyetujui transaksi dilakukan (Approval)
Approval
Checker
Maker
Kepala Kanwil
Kabid Aklap
FO Kanwil
Kabid PA
Kabid SKKI
Tabel 1
Pemisahan Kewenangan Pada Kanwil DJPBN
Approval
Checker
Maker
Kepala KPPN
MO PD
BO Bank
Kasi Bank
MO PD1
BO Bendum
Kasi Bendum
MO PD2
BO Bendum
Kasi PD
MO PPPHLN I
BO Vera
Kasi PD I
MO PPPHLN II
BO Vera
Kasi PD II
MO PPPHLN III
FO Bendum
Kasi PPHLN I
FO KPPN
Kasi PPHLN II
FO Pencairan Dana
Kasi PPHLN III
FO Vera
Kasi Verak
Tabel 2
Pemisahan Kewenangan Pada KPPN
91
Gambar 4.1. Interface SPAN
Dalam pelaksanaannya aplikasi SPAN tidak berdiri sendiri tetapi juga melakukan interaksi
dengan eksternal sistem menggunakan interface. Interface yang disediakan pada SPAN,
terdiri dari:
1. Interface SPAN dengan Legacy System (sistem yang sedang berjalan)
2. Interface SPAN dengan Perbankan (Bank Indonesia dan Bank Operasional)
3. Interface SPAN dengan Hyperion (Aplikasi Penyusunan Anggaran yang dikelola oleh
DJA)
4. Interface SPAN dengan SAKTI
92
BAB V
PERSIAPAN KEMENTERIAN / LEMBAGA
DALAM MENYONGSONG IMPLEMENTASI SPAN DAN SAKTI
Berdasarkan jadwal waktu yang telah ditetapkan, implementasi SPAN direncanakan akan
dilaksanakan secara bertahap. Pada tahap pertama, bulan Juni 2013, yaitu tahap piloting
1, SPAN akan diimplementasikan pada seluruh kantor pusat Kementerian Keuangan, yang
meliputi 4 unit organisasi, 5 Bagian Anggaran 999, Kantor Wilayah Direktorat Jenderal
Perbendaharaan Jakarta, KPPN Jakarta II dan KPPN Jakarta VI. Pada tahap piloting 3, bulan
Juli 2013, kantor daerah yang akan mengimplementasikan SPAN akan bertambah menjadi
4 KPPN. Pada bulan September 2013, akan dimulai tahapan selanjutnya, yaitu tahapan roll
out yang akan dilaksanakan secara bertahap sehingga pada bulan November 2013, SPAN
akan diimplementasikan pada KPPN dan Kanwil di seluruh Indonesia.
Berdasarkan jadwal waktu yang telah ditetapkan tersebut, implementasi SAKTI
direncanakan akan dimulai secara bertahap. Khusus untuk Modul Penganggaran, aplikasi
SAKTI akan mulai dipergunakan pada bulan Mei 2014 dalam rangka penyusunan RKAKL
tahun anggaran 2015. Penggunaan aplikasi SAKTI untuk Modul Pelaksanaan Anggaran dan
Modul Akuntansi serta Pelaporan Keuangan akan diimplementasikan mulai bulan Januari
2015.
Dalam rangka menyongsong implementasi SPAN dan SAKTI tersebut, ada beberapa hal
yang dapat dipersiapkan oleh Kementerian / Lembaga dan satuan kerja agar pada saat
implementasinya, dapat bejalan dengan lancar. Beberapa hal yang perlu diperhatikan
adalah sebagai berikut :
B.
ASPEK TEKNOLOGI INFORMASI
1.
Tersedianya jaringan internet dan infrastruktur TI yang memadai, seperti jaringan
Local Area Network (LAN) sebagai kebutuhan minimal.
Hal ini diperlukan agar
pelaksanaan masing-masing fungsi pengelola keuangan dapat dilaksanakan dengan
93
baik sesuai tugas pokok, fungsi dan beban tanggung jawab masing-masing pejabat.
Untuk kantor-kantor kecil yang tidak memiliki PC dalam jumlah yang cukup, tetap bisa
menyediakan sarana ini yang disesuaikan dengan kondisi masing-masing kantor.
Untuk fasilitas infrastruktur yang perlu dipersiapkan adalah untuk Personal Computer
(PC) yang memiliki spesifikasi yang cukup bagus, sambungan listrik yang cukup baik,
dan hal-hal yang bersifat teknis dalam menjaga kestabilan jaringan.
2.
Persiapan dalam instalasi aplikasi SAKTI sebagai satu-satunya aplikasi keuangan di
masing-masing unit kementerian/lembaga dan satuan kerja. Instalasi aplikasi SAKTI
pada masing-masing unit satuan kerja akan dilaksanakan sebelum implementasi SAKTI
yang akan difasilitasi oleh KPPN setempat.
C.
ASPEK SUMBER DAYA MANUSIA (SDM)
1.
Persiapan para para operator dan pengguna aplikasi SAKTI.
Untuk mengoperasikan aplikasi SAKTI, idealnya dibutuhkan minimal 5 orang yang
masing-masing memiliki tugas dan tanggung jawab yang berbeda. Tidak disarankan
untuk merangkap jabatan karena adanya masalah keamanan dan pelacakan audit
(audit trail), meskipun dalam prakteknya akan disesuaikan dengan kondisi pada
masing-masing satuan kerja. Kelima pengguna aplikasi SAKTI tersebut adalah :
a. Kuasa Pengguna Anggaran (KPA);
b. Pejabat Pembuat Komitmen (PPK);
c. Pejabat Pembuat SPM (PP-SPM);
d. Bendahara;
e. Operator/supervisor.
2.
Meningkatkan kemampuan SDM di masing-masing Kementerian/Lembaga di bidang
teknologi informasi.
Teknologi yang ada pada saat ini akan dapat memberikan
kemudahan dalam pelaksanaan pekerjaan. Pengembangan penggunaan teknologi
komunikasi dalam SPAN akan memungkinkan satuan kerja untuk menyampaikan SPM
ke KPPN, atau komunikasi data lainnya dengan melalui portal SPAN (Arsip Data
94
Komputer-ADK) dengan bantuan jaringan internet atau SMS gateway dengan bantuan
jaringan telepon seluler. Kedua mekanisme yang dikembangkan tersebut, baik portal
SPAN (ADK) maupun melalui SMS gateway, tentu saja membutuhkan adanya
pengetahuan baru para pegawai dalam hal penggunaan teknologi internet dan
komputer.
3.
Meningkatkan kesadaran para pengguna aplikasi SAKTI terhadap keamanan user ID
dan password/PIN agar tidak terjadi penyalahgunaan data keuangan. Masing-masing
pengguna aplikasi SAKTI yang terdiri dari 5 orang pejabat/fungsi tersebut akan
memiliki password/PIN yang dapat dipergunakan untuk mengesahkan dokumen SPM
sehingga jika disalahgunakan oleh orang yang tidak bertanggung jawab akan sangat
merugikan para pengguna yang secara formal ditunjuk.
C. ASPEK PELATIHAN APLIKASI.
1. Untuk mempersiapkan SDM Kementerian/Lembaga dan Satker secara teknis, yaitu
penguasaan aplikasi, maka akan dilaksanakan pelatihan kepada para pejabat di
Kementerian/Lembaga dan Satker yang terlibat dalam SAKTI oleh Kementerian
Keuangan melalui nara sumber dari KPPN atau nara sumber lain;
2. Materi akan diberikan sebelum pelaksanaan pelatihan untuk dipelajari/dibaca terlebih
dahulu oleh para peserta pelatihan sehingga pada saat pelatihan nanti dapat lebih
memahami materi yang diberikan;
3. Mengikuti pelatihan SAKTI dengan baik agar pada saat implementasi dapat berjalan
dengan lancar.
Dengan adanya persiapan-persiapan yang akan dilakukan oleh Kementerian/Lembaga dan
satuan kerja, maka diharapkan agar implementasi SPAN dan SAKTI pada satuan kerja dapat
berjalan dengan lancar.
95
BAB VI
PENUTUP
Salah satu tujuan pengembangan sistem SPAN adalah semakin mempermudah proses
penganggaran yang dimulai dari perencanaan sampai dengan pelaporan. Dalam sistem
SPAN proses penyusunan dokumen pelaksanaan anggaran akan semakin terintegrasi
sehingga meningkatkan efektivitas dan efisiensi pengelolaan keuangan Negara.
Sejalan dengan reformasi di bidang keuangan Negara, reformasi penganggaran dan
perbendaharaan negara mengagendakan sejumlah penyempurnaan terutama di bidang
penganggaran dan perbendaharaan. Dalam penyempurnaan ini, pengintegrasian
fungsi-fungsi sistem penganggaran dan perbendaharaan menjadi dasar bagi upaya
pencapaian akuntabilitas pertanggungjawaban keuangan Pemerintah yang dapat
diandalkan. Sistem pengelolaan keuangan negara yang modern, transparan dan akuntabel
menjadi tujuan yang akan dicapai dalam reformasi dimaksud.
Dalam pelaksanaan APBN, akan dikenal beberapa proses bisnis yang baru, yaitu
manajemen data supplier, manajemen data kontrak, manajemen data tagihan dan Surat
Perintah Membayar. Dalam penyusunan laporan keuangan, penyempurnaan yang akan
dilakukan meliputi aplikasi akuntansi keuangan, akuntansi barang milik negara, rekonsiliasi
SAI, penyusunan LPJ bendahara, dan akuntansi persediaan. Selain aplikasi SAKTI, juga akan
dikembangkan aplikasi pendukung yang meliputi portal SPAN dan SPAN SMS.
96
REFERENSI
Islam, Saiful, Purnomo Bungkus dkk, 2010, Modul Manajemen DIPA, Direktorat
Transformasi Perbendaharaan.
Islam, Saiful, Setiawan Iwan dkk, 2010, Modul Manajemen Pembayaran, Direktorat
Transformasi Perbendaharaan.
Islam, Saiful, Puspita Ingelia dkk, 2010, Modul Buku Besar dan Bagan Akun Standar,
Direktorat Transformasi Perbendaharaan.
Islam, Saiful, Mulyono Slamet dkk, 2010, Modul Manajemen Pelaporan, Direktorat
Transformasi Perbendaharaan.
Luthfi, MS, Zamachari Faried dkk, 2012, Modul Sakti, Direktorat Transformasi
Perbendaharaan.
Sudarto, Setiawan Adi, 2010, Modul Manajemen Satker, Direktorat Transformasi
Perbendaharaan.
Sudarto, Setiawan Adi, 2010, Modul Manajemen Komitmen, Direktorat Transformasi
Perbendaharaan.
Sudarto, Hemidon, 2010, Modul Manajemen Penerimaan, Direktorat Transformasi
Perbendaharaan.
Sudarto, Purnomo Nugroho Juli, 2012, Update Modul Manajemen Penerimaan, Direktorat
Transformasi Perbendaharaan.
Sudarto, Hutabarat Dodi, 2010, Modul Manajemen Kas, Direktorat Transformasi
Perbendaharaan.
Suliantoro, Irwan dkk, 2012, Modul Penyusunan Anggaran, Direktorat Jenderal Anggaran.
Tim Penyusun Modul SPAN, 2012, Pengenalan Proses Bisnis SPAN, Direktorat Transformasi
Perbendaharaan.
97