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
