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 praktek-
praktek 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.

Minister of Finance Project

Sponsorship

DG Treasury
Secretary
DG Budget Project
Tim RPPN General
Ownership

Treasury
PUSINTEK Budget Systems Project
Transformation
Execution
Tim Koordinasi
Teknis SPAN SPAN Contractor
IVV Services
Business Process FM & BPI Consultancy Business Process
DG Treasury Change management DG Budget
& Comms Consultancy
Other Advisor(s) &
Change Mgt Change Mgt
DG Treasury Consultans 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). Masing-
masing 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 SPAN-
SMS 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 modul-
modul 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
Router
N Portal
Modem VP
Internet Internet Membuka Portal
dgn Login KPPN
Network
Browser Firewall
Portal
Server Operator
di KPPN

Membuka Browser Membuka Aplikasi

Akses dengan Login satker SPAN dgn Login FO

Portal SPAN
Application
Operator di
Firewall VPN Firewall
SATKER Router
SPAN
Server 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
Aplikasi Satuan Kerja SPAN
Operator

SMS Langsung
Gateway Kirim dari
Komputer SMS Gateway
Satker
SPAN
Application
GSM/CDMA
Modem Instaled
To Computer

SMS Gateway Database

Satker Portal
Application Ketik SPAN SMS Notification
SPAN
Menu Kirim Manual Gateway
Lewat SMS
HP

Database
Portal
SPAN
SPAN
Database Server
Aplikasi Satker

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

KPA/Eselon I Kanwil DJPBN

- Surat Usulan Revisi

- SPTJM - Meneliti Surat Usulan Revisi
- ADK RKA K/L DIPA Revisi Anggaran dan Kelengkapan
- Surat Pernyataan Penggunaan Dokumen Pendukung
HO dan Sisa Anggaran Swakelola

3
4
4 N Y

- Surat Penolakan Revisi Revisi DIPA Setuju? - Upload ke Server RKA-K/l-DIPA

6
5
7

Notifikasi dari sistem :

Surat pengesahan revisi,
KPA - pengesahan revisi
dilampiri notifikasi
- 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
2 KPA menyiapkan:
KPA - Surat usulan Revisi
Y
1 - Download ADK RKA-K/L
untuk
DIPA Petikan
Melakukan Revisi Anggaran menyusun matriks Semula-
Berubah?
Menjadi
- Update ADK RKA-K/L
- Dokumen Pendukung
- SPTJM

- Update ADK RKA K/L 4

Cetak POK
Y
Menetapkan POK
KANWIL
Satker BLU
DJPBN

5
Y N
Eselon I 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 1
Eselon I menyiapkan:
- Surat Usulan Revisi
- Meneliti Surat Usulan Revisi - Surat Usulan Revisi
- SPTJM
- Mengecek Kewenangan - Update ADK RKA- K/L
- ADK RKA K/L DIPA-Revisi
- Memastikan Kelengakapan - SPTJM
- TOR dan RAB
Dokumen Pendukung - Surat Pernyataan Penggunaan HO
- Surat Pernyataan Penggunaan HO
dan Sisa Anggaran Swakelola
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

Penyusunan Anggaran Revisi Anggaran
Satker
RUH Revisi Pagu Anggaran
Kertas Kerja Aktif
RUH Kertas Pagu Anggaran
Kerja Aktif
Satker

Jenis Revisi
Kertas DIPA
Kerja Usulan Usulan
Petikan DJA DJPB DIPA
Kertas Kerja DIPA
Revisi
Revisi Revisi

Konsolidasi Konsolidasi Cetak dan Buat

Eselon I Satker

Kertas Kerja Menandatangani Kertas Kerja ADK RKAKL

DIPA Induk Revisi Revisi

Cetak dan Buat RKAKL RKAKL

ADK RKAKL Menandatangani
DIPA Induk

Cetak DIPA
Induk
DJPB

Penelahaan Approval
RKAKL Proses

Cetak DIPA Cetak DIPA

Petikan Petikan
Penelahaan DIPA Penelahaan DIPA
RKAKL Induk RKAKL Induk

Validasi
DJA

Validasi
DIPA Induk DIPA Induk

Approval Cetak DIPA Cetak SP Approval Cetak DIPA Cetak SP

Proses Induk DIPA Induk Proses Induk 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

Penyusunan SBK Penyusunan Anggaran Perencanaan Realisasi Anggaran
Operator ES 1 Validator ES 1 Approval ES 1

Kirim Usulan
Approval
SBK ke Kirim Usulan
SBK Approval
SPAN RKAKL ke
RKAKL
SPAN

Validasi
SBK Validasi
RKAKL

Terima Review Konsolidasi Review

RUH SBK Baseline
Usulan SBK Kertas Kerja RKAKL

Approval
Rencana
Approver

Penerimaan
Satker

Approval Kirim Kertas Approval

Kertas Kerja Kerja POK

Approval Approval Kirim

Penerimaan Renkas Renkas
Validator
Satker

Validasi
Validasi Validasi Validasi
Validasi POK Rencana
Kertas Kerja Penerimaan Renkas
Penerimaan

RUH Renkas RUH Prencana

Review RUH Kertas RUH
Penerimaan
RUH Usulan Kirim Usulan Baseline Kerja Penerimaan
Operator

RUH POK Bulanan

Satker

SBK SBK
Tayang Hal III
Terima ADK Pagu DIPA
DIPA dari Anggaran
SPAN Aktif
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

Contract
Acquisition Create SPP Create SPM
Spending Unit

RFC

Allotment
(DIPA) AFP
DIPA Page III
Substantif
Verify CAN
Test Liabilities
(ceiling test) Long Term Cash record
Planning
Treasury

Short Term
Commitment Cash Planning
Record
(CAN)

Formal &
Create SP2D Substantif Test
(tes akun)

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

Contract
Acquisition Create SPP Create SPM
Spending Unit

Resume
RFC
tagihan

Allotment
(DIPA)
Long Term Cash
Substantif Planning Verify CAN
Liabilities
Test record
Treasury

Short Term
Commitment Cash Planning
Record
(CAN)

Formal &
Create SP2D Substantif
Test

ALUR MNJ. KOMITMEN ALUR MNJ PEMBAYARAN ALUR MNJ. KAS 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
Transaksi dalam rangka pembayaran dan pengesahan menggunakan Tambahan
4
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
2
(GUP)
3 Pembayaran jasa bank terkait penerusan pinjaman
4 Pembayaran jasa bank selaku bank persepsi
5 Penyaluran subsidi
6 Penyaluran transfer ke daerah
7 Pembayaran kelebihan pajak (SPM KP/KC)
8 Pembayaran imbalan bunga (SPM IB)
9 Pembayaran askes, taspen, taperum

40
 Kerangka pelaksanaan manajemen komitmen adalah sebagai berikut :

Satker KPPN
Purchase Requisition Purchase Order (PO) Penerimaan barang Tagihan Pembayaran
(PR) dan jasa, verifikasi
Penerbitan Purchase Verifikasi PR, terhadap PO dan Verifikasi terhadap Penerimaan tagihan,
Requisition oleh unit pemilihan supplier pembuatan Berita PO terhadap BA verifikasi terhadap PO,
yang menggunakan dan penerbitan Acara Penerimaan dan dan Pembayaran
barang dan jasa Purchase Order Penerbitan invoice

Resume Kontrak (*) SPP / SPM SP2D(*)

(*)

Komitmen (*) Hutang (*) 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 hal-
hal 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:

Tabel Pengelompokan supplier

Kode Tipe Jenis Komitmen
- Permintaan dan penggunaan UP (CC)
1 Satker
- Permintaan dan penggunaan TUP (SC)
Penyedia barang dan - Kontraktual (SC)
2
jasa - Pembayaran daya dan jasa (CC)
3 Pegawai - Pembayaran gaji (CC)

44
 - Honor (CC)
- Lembur (CC)
- Investasi Pemerintah (SC)
- Hibah ke daerah (CC)
- Subsidi (CC)
- Kredit Program (CC)
BA 999
- Loan Repayment (CC)
4 selain Penerusan
- pembayaran terkait SBN (CC)
Pinjaman
- Jasa Bank penatausaha PP (CC)
- jasa Bank Persepsi (CC)
- Pengembalian PFK (CC)
- Lain-lain (SC/CC)
5 Transfer Daerah - Transaksi transfer daerah ke Pemda
6 Penerusan Pinjaman - Pembayaran Penerusan Pinjaman (SC)
- Pengembalian pajak/PBB/BPHTB/BM-C (CC)
- pengembalian PNBP (CC)
7 Lain-lain
- 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 Commitment Management Payment Management

Resume Kontrak (RFC) Registrasi dan

(Data supplier & Data Validasi Data Verifikasi Data
Kontrak) Supplier

Proses RFC

Resume Tagihan Registrasi dan

(Data Supplier dan Data Validasi data Verifikasi data
Tagihan) supplier

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 Staff Bank Kasi Bank BO

Penerimaan dan
Pengujian
Tagihan Suplier

A.
Penerbitan SPP
Pendaftaran RT,
dan RT
Upload, Validasi

Penerimaan Penerimaan
Nomor Tagihan SPP dan
dari SPAN Pengujian SPP

B. C.
C.
Pendaftaran Penerusan
Invoicing

Penerbitan SPM Persetujuan

SPM, Upload, Informasi
Tagihan
Initiate Tagihan

D. E.
Pengelompokan Pembayaran
Payment (Due Date)

Tagihan Tagihan

M.
F.
Penerimaan
Pengiriman
SP2D dan
Data
Transfer ke
Pembayaran
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. Perubahan-
perubahan 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
6. penerimaan dapat
Penerimaan dari dilakukan di tingkat
pengembalian belanja Satker dan KPPN.berjalan
tahun anggaran Untuk dapat
itu setiap transaksi
mengembalikan
padapagu
sisa datayang
MPNdidahului
harus dapat di mapping
dengan sebagai penerimaan
surat pengajuan pengembalianKPP/KPBC selaku
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
10. reversal/pembalik, sehingga setiap
negaraperubahan/perbaikan akanpenggunaan
tercatat. kertas (less
Penatausahaan penerimaan 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 RPKBUNP B RPKBUNP C

(BO A) (BO B) (BO C)

Pihak ke-3 Pihak ke-3 Pihak ke-3 Pihak ke-3 Pihak ke-3 Pihak ke-3
(BO A) (BO A) (BO B) (BO B) (BO C) (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 masing-
masing 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. Undang-
Undang 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 perundang-
undangan 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 modul-
modul 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 Due-To and Due-From

12 Cadangan 6
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 Per-
01/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, modul-
modul 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 off-
the-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
 3/16/2013

AGENDA

1 GAMBARAN UMUM

PROSES BISNIS PENGELOLAAN KEUANGAN NEGARA

2
A. PENGANGGARAN
B. PELAKSANAAN ANGGARAN
C. PERTANGGUNGJAWABAN

1
 3/16/2013

1 GAMBARAN UMUM

3
LATAR BELAKANG

Reformasi
PENGELOLAAN Modernisasi
Manajemen KEUANGAN
GFMRAP Anggaran dan
Keuangan NEGARA Perbendaharaan
Pemerintah
• Undang-Undang: • Pengelolaan Keuangan • Penguatan Kapasitas • Program RPPN
• No. 17/2003 tentang Negara Kebijakan • Tim Reformasi
Keuangan Negara • Administrasi • Penguatan dan • Tim Koordinasi Teknis
• No. 1/2004 tentang Pendapatan Penyempurnaan Tata • Implementasi SPAN
Perbendaharaan • Tata Kelola dan Kelola yg Baik atas
Negara Akuntabilitas perencanaan dan
• No. 15/2004 tentang • Tata kelola dan pengembangan anggaran
Pemeriksaan Implementasi Proyek • Modernisasi Anggaran
Pengelolaan dan dan Perbendaharaan
Tanggung Jawab
Keuangan Negara

2
 3/16/2013

Visi & Misi SPAN

Visi Misi
Mengembangkan proses bisnis secara
berkelanjutan dengan mendasarkan pada
praktek penyelenggaraan yang sesuai dan
terbaik
Terwujudnya pengelolaan dan
pertanggungjawaban keuangan
negara yang transparan dan Menerapkan paket solusi yang
akuntabel, aman dan mudah terintegrasi untuk mendukung sistem
diterapkan dengan dukungan sistem yang aman, akurat dan handal
informasi manajemen keuangan
yang terintegrasi.
Memastikan diterimanya perubahan oleh
pemangku kepentingan dan memberikan
solusi lengkap terhadap dampak
perubahan

Apa Itu SPAN?

• Sistem Informasi yang menggabungkan beberapa
fungsi, seperti Perencanaan Anggaran,
Pelaksanaan Anggaran, Manajemen Kas, Akuntansi
& Pelaporan dalam satu sistem aplikasi.
• Sistem Informasi Keuangan Negara yang
Terintegrasi:
– Mendokumentasikan setiap transaksi
keuangan dan mendukung penyajian laporan
keuangan dan manajerial
– Didesain dengan relasi yang baik antara
pemilihan software, hardware, SDM,
prosedur, kontrol, dan data
– Operasi terotomasi secara penuh serta
bermuara pada database yang terpusat

3
 3/16/2013

Otomatisasi dan
jejak audit
Satu database,
rekonsiliasi data
Penggunaan
kertas yang lebih
sedikit
Akuntansi Akrual,
PBK, KPJM
Notification mailler
system / alert system
Laporan sesuai
kebutuhan

7
Pilar Utama SPAN

Manajemen Perubahan&
Komunikasi

Penyempurnaan Proses Bisnis

Teknologi Informasi

4
 3/16/2013

Penyempurnaan Aplikasi Dan Database

Perencanaan Anggaran hingga Pelaksanaan Anggaran
SEMULA Perencanaan Anggaran hingga Pelaksanaan Anggaran

Satker di K/L
Sistem
yang ada
terkotak2
berdasarkan
fungsi RKA-KL-DIPA SPM AFS SIMAK SAKPA

Perencanaan Anggaran hingga Pelaksanaan Anggaran

MENJADI

Satker di K/L
Sistem SPAN
akan lebih SPAN Database
berorientasi
kepada proses Penganggaran Manajemen Manajemen Manajemen Akuntansi dan
Komitmen Pembayaran Penerimaan Pelaporan

Modul Proses Bisnis 9

Pelaporan Admin
SATKER
istrasi

Pelaporan

SPAN BAS
Penerimaan
manajemen

Integrasi Aplikasi IT:

- Single entry point
- Satu Aplikasi
- Secara Elektronik
-Rekonsiliasi per periode antara Satker & KPPN

9
9

5
 3/16/2013

PENYEMPURNAAN PROSES BISNIS

I. PENGANGGARAN
1. Penyusunan Anggaran
2. Manajemen DIPA
I. PELAKSANAAN
1. Manajemen Komitmen
2. Manajemen Pembayaran
3. Manajemen Penerimaan
4. Manajemen Kas

III. PERTANGGUNG JAWABAN

1. Akuntansi
2. Pelaporan
11

6
 3/16/2013

Proses Bisnis PENGANGGARAN

Existing SPAN Dampak

Penelaahan DIPA sampai 4 Penelaahan DIPA hanya
digit sampai 2 digit
Penelaahan Akan Lebih Cepat
Satker mendapatkan
Satker kurang mendapatkan
fleksibilitas lebih banyak
fleksibilitas dalam melakukan
dalam melakukan revisi Revisi DIPA Lebih Cepat
revisi anggaran
anggaran

Belum semua komponen Semua komponen APBN Akuntabilitas Lebih Baik

APBN dimasukan dalam DIPA akan dimasukan dalam DIPA

Belum mengadopsi konsep Efisiensi & Efektivitas Akan

Mengadopsi Penganggaran
penganggaran berbasis Meningkat
berbasis kinerja
kinerja (PBK)

Informasi rencana Informasi rencana Hal. 3 DIPA Dapat Dijadikan

penarikan/ penerimaan dana penarikan/ penerimaan Informasi Awal Perencanaan
pada halaman III tidak di dana pada halaman III ter- Kas
update update

Proses Bisnis
PELAKSANAAN ANGGARAN
Existing SPAN Dampak
Pelaksanaan
Manajemen Komitmen Manajemen Komitmen Peningkatan budget control
belum dilaksanakan termasuk manajemen
terhadap supplier
melalui manajemen komitmen

Penerapan konsep Optimalisasi perencanaan kas

Komunikasi data
paperless/lesspaper melalui pemanfaatan data
dilakukan secara manual
dalam proses
dan paperbased liability
komunikasi data

Desentralisasi proses Sentralisasi proses Mendukung Penerapan

transfer pembayaran transfer pembayaran Accrual Accounting

Penerapan e- Peningkatan kecepatan dan

Pencairan dana
disbursement dalam
dilakukan secara manual
proses pencairan dana
kepastian waktu pencairan
dana

7
 3/16/2013

Proses Bisnis
PELAKSANAAN ANGGARAN
EXISTING SATKER SPAN

Setiap Satker yang akan menyetorkan Dampak

Setoran ke Bank Persepsi PNBP dll, harus membuat kode billing
Saat ini Satker menyetorkan secara terlebih dulu dan dapat dilakukan
tunai kepada petugas teller di Bank melalui berbagai channel pembayaran
Persepsi terkait setoran Pajak, seperti ATM amupun Internet Banking. Data penerimaan
PNBP, Sisa UP, Pengembalian (asumsinya sistem MPN Generasi Kedua dapat lebih cepat
Belanja, dan setoran PFK. telah berjalan) diterima dan lebih
Kebenaran data setoran menjadi reliable
tanggung jawab penyetor sehingga data kebenarannya.
Perencanaan Kas penerimaan negara menjadi lebih Disamping itu,
Satker melakukan perencanaan kas
reliable. dengan perencanaan
am
secara terpisah melalui aplikasi Perencanaan kas yang diinput Satker
kas yang terintegrasi,
tersendiri dan belum sepenuhnya akan terintegrasi dengan database SPAN akan dapat
terhubung dengan kontrak atau membantu BUN
yang akan saling terhubung dengan
komitmen yang telah dibuat dengan
pihak ketiga. manajemen DIPA, manajemen dalam mengelola kas
komitmen dan pembayaran negara.
Koreksi setoran penerimaan negara
Koreksi Pendapatan diajukan oleh Satker ke pemilik data
Satker mengirimkan surat penerimaan yaitu DJP, DJA, maupun Pelaksanaan forward
permintaan perubahan data ke DJBC tergantung jenis setorannya. SPAN cash planning
KPPN terkait kesalahan setoran akan menerima data perbaikan tersebut
yang dilakukan Bank Persepsi. secara sistem melalui MPN-G2.

Proses Bisnis
PERTANGGUNGJAWABAN
EXISTING SPAN DAMPAK

Laporan Berbasis Cash Towards Laporan keuangan lebih komprehensif

Laporan Berbasis Akrual dan informatif
Accrual
Laporan manajerial lebih mudah
User-defined (Managerial) disusun, sesuai kebutuhan user & lebih
Managerial Reports disusun dari
Reports disusun dari single andal
database yang terpisah (berbeda)
database
Mendukung analisis dan evaluasi
Pelaporan Berbasis GFS kebijakan fiskal serta komparasi
Belum ada laporan berbasis GFS (Government Financial Statistic) kegiatan operasi antar negara
System
Memudahkan KL melakukan cross
Web-based Reconciliation check data dengan data BUN sehingga
Rekonsiliasi laporan keuangan
(Proses rekonsiliasi laporan Laporan keuangan lebih cepat, tepat,
secara konvensional (face to face)
keuangan berbasis internet) akuntabel & andal

Dua sistem yang berbeda pada Satu sistem, yaitu Sistem

Sistem Akuntansi Pusat, yaitu SAU Akuntansi Pusat yang Tidak ada perbedaan data antar sistem
dan SAKUN terintegrasi sehingga tidak memerlukan rekonsiliasi
antar sistem
Belum ada output pada Bagan Struktur Bagan Akun Standar
Akun Standar memasukkan output Sejalan dengan PBB, dapat
menghasilkan informasi output

Adaptasi budgetary accounting Encumbrance accounting Tidak ada kode transaksi, jurnal
akuntansi lebih sederhana

8
 3/16/2013

PROSES BISNIS PENGELOLAAN

2 KEUANGAN NEGARA
PENGANGGARAN

PENGANGGARAN

Terdapat 3 proses utama dalam penganggaran:

• Penyusunan RKAKL
• Pengesahan DIPA
• Revisi anggaran

Berdasarkan PMK 32 tahun 2013 mengenai Tata Cara

Revisi Anggaran TA 2013, maka mekanisme revisi
adalah sbb:

9
 3/16/2013

MEKANISME PENYELESAIAN REVISI ANGGARAN PADA

DIREKTORAT JENDERAL ANGGARAN
2

DJA 3
1

Meneliti Surat usulan revisi
Y
Perlu
Eselon I anggaran dan kelengkapan Menteri
persetujuan
Keuangan DPR
Dokumen pendukung; DPR?

Surat usulan revisi;

Update ADK RKA-K/L;

SPTJM. Y

Surat pernyataan
Penggunaan HO dan Dokumen N N
Sisa Anggaran Lengkap? Setuju
Swakelola 4 ?
Y Pagu
Penelaahan berubah?
N 7 Y
5
N DJA
6
Y
Revisi
Pencetakan

Surat peno- DIPA DHP RKA-
lakan revisi. N Setuju? K/L.

12

10 9 8
Eselon I 11

Dalam hal pagu

Surat pengesahan berubah: Notifikasi dari sistem :
Upload ke
KPA revisi, dilampiri
Cetak DIPA Induk
persetujuan revisi; server
Notifikasi.
Pengesahan DIPA
Kode digital stamp yg RKA-K/L-
Induk baru. DIPA
49

MEKANISME PENYELESAIAN REVISI ANGGARAN PADA

KANTOR WILAYAH DITJEN PERBENDAHARAAN

2
1
KPA Kanwil DJPBN

Surat usulan revisi;
Meneliti Surat usulan revisi;

Matriks perubahan
Mengecek kewenangan;
(semula-menjadi);
Memeriksa kelengkapan

ADK RKA-K/L-DIPA Revisi; Dokumen pendukung;

SPTJM KPA;

3 4
4
N Revisi Y
Upload ke server

Surat penolakan revisi. DIPA RKA-K/L-DIPA
Setuju?

7 6 5

Surat pengesahan revisi, Notifikasi dari sistem :
KPA dilampiri Notifikasi.
persetujuan revisi;

Kode digital stamp yg baru.

50

10
 3/16/2013

MEKANISME PENYELESAIAN REVISI ANGGARAN PADA

UNIT ESELON I KEMENTERIAN/LEMBAGA

1 2
KPA Eselon I
3
Melampiran:
Meneliti Surat usulan Eselon I menyiapkan:

Surat Usulan revisi; revisi;
Surat usulan revisi;

SPTJM;
Mengecek kewenangan;
Update ADK RKA-K/L;

ADK RKA-K/L DIPA
Memeriksa kelengkapan
SPTJM.
Revisi; Dokumen pendukung;
Surat pernyataan Penggunaan HO

TOR dan RAB dan Sisa Anggaran Swakelola

Surat pernyataan
Penggunaan HO dan Sisa
Anggaran Swakelola

DJA

51

Validasi DIPA
• Membandingkan Appropriasi dengan ADK satker
(pengesahan)
• Membandingkan Data DIPA (allotment) terupdate di
SPAN dengan data usulan Revisi
• Data yang dibandingkan struktur COA
a. Kesesuaian dengan COA
b. Kewenangan revisi
c. Semua dibandingkan kecuali Lokasi, KPPN,
Kewenangan

11
 3/16/2013

Rencana Penarikan Dana

• Tidak mengikat Perbulan
• Mengikat Pertahun
• Perubahan dari satker
• Dua digit

PROSES BISNIS PENGELOLAAN

2 KEUANGAN NEGARA
PELAKSANAAN ANGGARAN

12
 3/16/2013

24
Manajemen Komitmen dan Pembayaran (Saat Ini)

MANAJEMEN KOMITMEN MANAJEMEN PEMBAYARAN

APLIKASI SATKER APLIKASI KPPN

DATA SUPPLIER / PEMBERIAN

KONTRAK CAN

PENERBITAN PENCATATAN HUTANG

SPP

PENERBITAN SPM PENERBITAN

SPM SP2D
SP2D

25
Manajemen Komitmen dan Pembayaran (Future)

SUPPLIER/
RFC

13
 3/16/2013

26

MANAJEMEN KOMITMEN

Definisi
• Komitmen atau Perikatan
 Tindakan/ keputusan yang dapat mengakibatkan
pengeluaran negara
 Potensi timbulnya kewajiban di masa yang akan
datang
 Diikuti dengan ada/ tidaknya pemenuhan kondisi
tertentu yang diperjanjikan/ disyaratkan
• Belum menjadi kewajiban/ hutang/ liability, sampai
dengan terpenuhinya kondisi tertentu yang
disyaratkan/ serah terima.

14
 3/16/2013

Fungsi-fungsi proses bisnis--Komitmen

Kontrol Anggaran

Budget Encumbrance Actual FA

PAGU PERIKATAN/
PEMBAYARAN
ANGGARAN KOMITMEN

Forecast:
Committed DATA
Jumlah &
Balance KOMITMEN
Waktu

Fungsi Kontrak Fungsi

terkait Total terkait
pagu Angsuran manajeme
Angsuran n kas
Angsuran

Proses Penerbitan
Commitment Application Number (CAN)
SATKER

PIHAK KE-3

RESUME
KONTRAK

PORTAL
CUSTOMER SERVICE SPAN
• Memeriksa ID
• Cek File ADK Kontrak
• Upload Resume Kontrak

VALIDATOR
Checker 1
REVIEWER
Checker 2

CAN/
Nomor Register
KASI PENCAIRAN DANA Kontrak
Approval

SATKER

15
 3/16/2013

30

MANAJEMEN PEMBAYARAN

31

INTERAKSI SATKER DAN KPPN

• Proses Request for Commitment (RfC)

– Perekaman Data Supplier dan Resume Kontrak
– Pencadangan dana DIPA (encumbrance)
• Proses Resume Tagihan
– Perekaman Data Supplier (Khusus untuk Continuing
Commitment)
– Pengakuan pembebanan (accrual accounting)
– Perencanaan Kas (Manajemen Kas)
• Proses SPM
– Approval SPP/Resume Tagihan
– Proses pembayaran/ settlement

16
 3/16/2013

32
Proses Bisnis Manajemen Pembayaran

33

PENGIRIMAN RESUME TAGIHAN DAN SPM

• Resume tagihan : Data SPP yang dikirim ke KPPN.

• Ditentukan jatuh tempo tagihan.
• Fungsi untuk :
- Pengakuan beban
- Perencanaan kas
• Pengecekan Data Supplier, data kontrak dan
Ketersediaan Dana, dll.
• SPM diajukan sebelum tanggal jatuh tempo.

17
 3/16/2013

PENGUJIAN KETERSEDIAAN DANA DIPA

CURRENT BUSINESS PROCESS

FA = pagu DIPA – Realisasi Pengeluaran

FUTURE BUSINESS PROCESS

FA = pagu DIPA– Encumbrances – Realisasi Pengeluaran – Dana TUP

FUTURE BUSINESS PROCESS

(With Cash Limit Case)
FA = pagu DIPA – Cash Limit – Encumbrances – Realisasi Pengeluaran – Dana TUP

PENERAPAN JATUH TEMPO TAGIHAN

• Satker (PPK) menentukan secara fleksibel

tanggal jatuh tempo tagihan sesuai dengan
kebutuhan (1 s/d 14 hari).
• Perhitungan jatuh tempo sejak tanggal resume
tagihan sampai dengan tanggal dikeluarkannya
SP2D.
• Fungsi : Perencanaan Kas Jangka Pendek

18
 3/16/2013

Penerapan Payment Term Dalam Proses Penagihan

SATKER

Proses Penerbitan
CAN/ Nomor Tagihan
Nomor Register
Kontrak
PIHAK KE-3

Tagihan
PPK

Resume
Tagihan

PORTAL
CUSTOMER SERVICE SPAN
Upload

VALIDATOR
Review
Approval

Nomor Tagihan

SATKER

19
 3/16/2013

Nomor Tagihan
Proses Penerbitan
Surat Perintah Pencairan Dana (SP2D)

SPP

SPM

PORTAL
SPAN
CS BANK
Upload

VALIDATOR
Checker 1
REVIEWER
Checker 2

Kasi Pencairan Staff Kasi

Dana SPPT Bank/Giro Pos Bank/Giro Pos SP2D
Approval Select Tagihan Konfirmasi
yang jatuh pembayaran
Tempo

DATA BASE SPAN

39

MODUL MANAJEMEN
PENERIMAAN

20
 3/16/2013

• Data penerimaan negara yang dicatat melalui

modul manajemen penerimaan SPAN berasal
dari:
1.Data penerimaan dari Bank/Pos Persepsi (sistem
MPN);
2.Data penerimaan yang disetor ke rekening Kas
Negara pada BI (RKUN, SubRKUN, RPL, dll).
3.Data penerimaan yang diterima dari modul
pembayaran di SPAN.

Sedangkan yang terkait Satker, penatausahaan penerimaan

negara pada modul manajemen penerimaan meliputi:

1. Penerimaan negara melalui potongan SPM

2. Pengembalian pendapatan melalui SPM-KP, SPM-KC,
SPM-PP, dll.
3. Penerimaan Satker BLU
4. Penerimaan pembiayaan melalui penerbitan SP3 pada
KPPN Khusus Jakarta VI.

21
 3/16/2013

43

MANAJEMEN KAS

22
 3/16/2013

Proses Bisnis
SPAN Pencairan Dana

SURAT PERINTAH
PKN TRANSFER BI
RKUN

TRANSFER

SP2D PEMBAYARAN
PIHAK KE-3

BANK OPERASIONAL
PUSAT
RPKBUN P

PROSES BISNIS PENGELOLAAN

2 KEUANGAN NEGARA
PERTANGGUNGJAWABAN

23
 3/16/2013

PENYEMPURNAAN DALAM SPAN

1. Akuntansi Akrual
2. Restrukturisasi BAS
3. Dua Pencatatan
4. Single Database
5. Mekanisme Rekonsiliasi
6. Mekanisme Konsolidasi

AKUNTANSI AKRUAL PADA SPAN (1)

Mengacu pada PP No. 71 tahun 2010 tentang Standar Akuntansi Pemerintah

No Akuntansi Akrual pada SPAN Poin Perubahan
1. Tahapan penjurnalan: • Terdapat pencatatan komitmen
anggaran, komitmen, realisasi, untuk kebutuhan reserve pagu
penutup, koreksi
2. Sistem akuntansi BUN menggunakan • Tidak menggunakan SAU dan
dua pencatatan: akrual dan kas SAKUN, namun tetap
menghasilkan Lap.Keuangan
sesuai SAP
3. BAS berbasis akrual dan • Terdapat penambahan akun-akun
hanya menggunakan satu BAS untuk akrual, misalnya belanja yang
pencatatan akrual dan kas masih harus dibayar, sewa dibayar
dimuka, dll

24
 3/16/2013

AKUNTANSI AKRUAL PADA SPAN (2)

No Akuntansi Akrual pada SPAN Poin Perubahan

4. Pola hubungan satker dan KPPN • Menggunakan utang dan piutang

menggunakan Due to dan Due from dari KUN sejak realisasi
5. Akrual pada saat transaksi • Akrual saat transaksi
pembayaran menggantikan prosedur akrual
saat ini yang dilakukan pada akhir
tahun
6. Koreksi dengan jurnal balik • Adanya audit trail

Sistem Akuntansi Pusat

dengan Dua Ledger
49

SPAN – Catatan Utama SPAN – Catatan Kedua

Basis Akrual Basis Kas

• Laporan Operasional • Laporan Realisasi Anggaran

• Laporan Perubahan Ekuitas • Laporan Saldo Anggaran Lebih
• Neraca • Laporan Arus Kas

Catatan atas Laporan Keuangan

25
 3/16/2013

KONSEPSI JURNAL AKRUAL

1. Jurnal Anggaran
Transaksi Anggaran dicatat dengan single entry
Debet = Belanja/Transfer/Pengeluaran Pembiayaan
Kredit = Pendapatan/Penerimaan Pembiayaan
2. Jurnal Komitmen
Transaksi Komitmen akan dicatat berpasangan
Debet = Belanja
Kredit = Belanja yang Dicadangkan
3. Jurnal Realisasi
Transaksi Realisasi akan dicatat berpasangan
Debet = Beban
Kredit = Belanja yang masih harus dibayar

Debet = Belanja
Kredit = Kas

Transaksi Dalam SPAN

Ilustrasi Transaksi
No. Transaksi Dokumen Sumber Subledger GL
1 Tipe Anggaran:
1. APBN (B-1) a. RKAKL/ Revisi RKAKL Modul Anggaran
2. DIPA (B-2) b. DIPA/Revisi DIPA Modul DIPA

2 Tipe Komitmen Kontrak dan Revisi Kontrak Modul Komitmen

3 Tipe Realisasi a. Resume tagihan Modul Pembayaran Kirim

b. Pembayaran Modul Pembayaran ke GL
c. Tagihan Penerusan Modul Penerimaan Negara
Pinjaman
d. Penerimaan Perpajakan Modul Penerimaan Negara
e. Penerimaan PNBP Modul Penerimaan Negara
f. Transfer uang Modul Pengelolaan Kas

4 Jurnal Manual Memo Penyesuaian Post ke GL

26
 3/16/2013

Ilustrasi
Reporting Requirement – Accrual Report

Bukti Buku Besar

Transaksi
Jurnal Transaksi
Trial Balance
Laporan

LO
Pendapatan-LO
Beban
Akrual Kas
Beban Pegawai …… XX
Utang Beban Pegawai… XX --- tidak ada jurnal -- LRA
Pendapatan-LRA
Belanja
Utang Beban Pegawai … XX Belanja Pegawai … XX
Kas di KUN … XX Kas di KUN …. XX

PENCATATAN JURNAL
ACCRUAL LEDGER CASH LEDGER
1. Resume Dr. Beban Barang 900.000,- -
Tagihan Cr. B. Barang YMH Dibayar 900.000,-

2. SPM/ Dr. B. Barang YMHDibayar 900.000,- Dr. Belanja Barang 900.000,-

SP2D Cr. Kas BUN 900.000,- Cr. Kas BUN 900.000,-

Intraco Journal : Intraco Journal :

Dr. Due From 900.000,- Dr. Due From 900.000,-
Cr. Due to 900.000,- Cr. Due to 900.000,-

27
 3/16/2013

Periode Akuntansi
Periode Bulan
a. Periode Akuntansi akan
1 Januari
ditutup setelah proses
2 Februari rekonsiliasi periode
3 Maret berikutnya
b. Apabila ada transaksi
4 April
koreksi untuk bulan
5 Mei sebelumnya maka
6 Juni Periode transaksi tersebut tetap
Akuntansi Normal dibukukan pada bulan
7 Juli
ditemukannya koreksi.
8 Agustus
9 September
10 Oktober
11 Nopember
12 Desember
13 T+1 sd T+2 Periode
14 T+3 sd T+4 Subsequent Event

Proses Rekonsiliasi
SP2D Surat Perintah Pencairan Dana (SP2D)

sakti
ADK
REKON

PORTAL
CUSTOMER SERVICE SPAN
Upload ADK REKON

VERIFIKASI

BAR

28
 3/16/2013

Prosedur Rekonsiliasi Eksternal (Saat ini)

REKONSILIASI SAAT SPAN

29
 3/16/2013

• SAKTI adalah sistem aplikasi Satker yang

mengintegrasikan fungsi-fungsi perencanaan dan
penganggaran, pelaksanaan anggaran, dan pelaporan ke
dalam sebuah sistem aplikasi.
• Tujuan:
1. Integrasi database dan single entry point guna
mendukung akurasi dan mengurangi duplikasi data base
2. Mengadopsi penerapan sistem akuntansi akrual

30
 3/16/2013

Basis Akuntansi
Basis Akuntansi CTA
Akrual

Aplikasi RKAKL, DIPA, SPM,

PERAN, SAK, SIMAK-BMN,
Persediaan
SAKTI

Modul Bendahara
dan Manajemen
Komitmen

Topologi Jaringan dan Infrastruktur SAKTI

Multi User
Multi Satker

Single User
Single Satker

Multi User
Single Satker

31
 3/16/2013

SPAN SMS Interkoneksi, Teknologi dan Sistem

PERMINTAAN INF.
TRANSAKSI DAN AKTIFASI PIN SPAN-SAKTI
INF. TRANSAKSI DAN
INF. AKTIFASI PIN

APLIKASI SAKTI

ADMIN ANGGARAN
ADK RKAKL
ADK DIPA
ADK POK
ADK RFC
REALISASI/KOMITMEN/ ADK SUPPLIER
REFERENSI/INF. POSTING
ADK RESUM TGH
& CLOSING
ADK SPM
ADK REKON
PENGATURAN MODUL DAN RKAKL/AFP/DIPA/RDIPA/
REFERENSI SEMUA MODUL
CEK PIN
POK/JURNAL ANGGARAN
JURNAL NERACA/POSTING/ KONTRAK/SUPPLIER/
CLOSING/VALIDATION JURNAL ASET & PERSEDIAAN
GL & P KOMITMEN
JURNAL TERKAIT
ANGGARAN/ DIPA/RDIPA/REALISASI
DB
ASET TETAP/PERSEDIAAN/ KONTRAK/REFERENSI/
BENDAHARA/PEMBAYARAN INF. POSTING & CLOSING
/REFERENSI/INF. POSTING SAKT DB
I
& CLOSING

INF. PERSEDIAAN DARI

SPTB/LPJ BENDAHARA/
PEMBAYARAN/REFERENSI/
SPAN
PERSEDIAAN KOMITMEN & BENDAHARA/ INF. POSTING & CLOSING
REFERENSI/ INF. POSTING & CLOSING BENDAHARA
TRANSAKSI PERSEDIAAN/ KWITANSI/BON PENGELUARAN
JURNAL PERSEDIAAN SSP/SSBP/SSPB/
ADK RKAKL
TRANSAKSI ASET TETAP/ SPP/SPM/ JURNAL BENDAHARA
ADK DIPA
JURNAL ASET JURNAL PEMBAYARAN
ADK POK
CAN
INF. ASET TETAP DARI DIPA/RDIPA/AFP/POK/ NRS
KOMITMEN & BENDAHARA/ KONTRAK/BENDAHARA/ NO. TAGIHAN
REFERENSI/INF. POSTING REFERENSI/INF. POSTING SP2D
& CLOSING & CLOSING
BAR
PIN PEJABAT
ASET TETAP PEMBAYARAN

Platform Aplikasi SAKTI

Bahasa Pemrograman : Java SE

Database : MySQL, Oracle

32
 3/16/2013

User Interface SAKTI

Contoh Form Perekaman Supplier Header

33
 3/16/2013

Contoh Form Perekaman Supplier Site

Contoh Form Perekaman Bank Site

34
 3/16/2013

Definisi dan Ruang Lingkup

Modul Penganggaran memuat proses Penyusunan
Rencana Kerja Anggaran sampai dengan penyusunan
DIPA termasuk didalamnya proses perencanaan
penyerapan anggaran dan penerimaan dalam periode
satu tahun anggaran.
Modul Penganggaran meliputi :

Penyusunan Anggaran: SBK, RKAKL, KPJM, dll

Pelaksanaan Anggaran: DIPA, POK, Perencanaan Kas

35
 3/16/2013

Fitur – fitur Modul Penganggaran

1. Pengelolaan usulan SBK (Standar Biaya Keluaran)
2. Pengelolaan RKAKL
3. Pengelolaan Data Pegawai (Perhitungan estimasi
belanja pegawai)
4. Pengelolaan DIPA
5. Pengelolaan POK
6. Perhitungan AFP
7. Pengelolaan AFS
8. Pengelolaan data revisi transaksi (Penyimpanan
History data Revisi)

Proses Bisnis SAKTI

36
 3/16/2013

Proses Bisnis Pengesahan dan Revisi ANGGARAN

72

Desain Proses High Level

 Penyusunan
Anggaran
Penyusunan
Anggaran

Review Penyusunan
History RKAKL SBK Revisi RKAKL
Baseline RKAKL

SBK Total SBK Index

Biaya Biaya

Rencana Rincian Target KPJM

Kinerja Belanja Pendapatan

37
 3/16/2013

Desain Proses High Level

 Manajemen DIPA dan Perencanaan Kas

Manajemen
DIPA

Penerbitan AFP (Annual Perencanaan Kas

Revisi DIPA POK
DIPA Finansial Plan) (Harian & Mingguan)

Revisi DIPA Revisi DIPA

Biasa BLU

DIPA Biasa DIPA

DIPA VOA DIPA BLU
Sementara

Data Input Modul Penganggaran

• ADK
1. GPP dari aplikasi Gaji/GPP
2. TRPNBP dari aplikasi TRPNBP
• Dokumen
1. SPRKAKL
2. SPDIPA
• Data (Internal SAKTI)
1. Kwitansi/ bon (Modul Bendahara)
2. Kontrak (Modul Komitmen)
3. SPP/ Resume Tagihan (Modul Komitmen)
4. Realisasi /SP2D (Modul Pembayaran)
5. Data Pegawai/suplier (Modul Supplier)
6. Realisasi Pendapatan (Modul Bendahara)

38
 3/16/2013

Data Output Modul Penganggaran

• ADK
1. RKAKLDIPAPOK
2. Data Pegawai
3. SBK
4. AFS
• Dokumen
1. RKAKL
2. DIPA
• Report
1. Lampiran RKA Satker
2. AFP (Annual Financial Plan)
3. Monitoring DIPA
4. Laporan Alokasi Anggaran
5. Laporan Pagu DIPA
6. RPA (Realisasi Penyerapan Anggaran)
7. Laporan Semula-Menjadi (untuk Revisi Anggaran)
• Data
Pagu DIPA (COA)

Fungsi – fungsi baru pada modul

Penganggaran
• Pencatatan History Kertas Kerja dan DIPA
• Pembentukan COA pada saat transaksi DIPA
• Perhitungan FA (Fund Available) yang dipengaruhi oleh
Informasi dari Modul Bendahara, Komitmen dan
Pembayaran
• Proses Locking pagu pada saat proses revisi
• Penerapan Role (Approver, Validator, dan Operator)
• Penggabungan informasi RUH Pendapatan dengan rencana
Penerimaan
• Perhitungan otomatis halaman III DIPA dari POK
• Perhitungan AFP dari POK, dan mengambil informasi
langsung dari modul pembayaran, dan komitmen

39
 3/16/2013

Definisi dan Ruang Lingkup

• Modul Komitmen adalah modul yang memuat
aktivitas terkait pencatatan data perikatan/kontrak
dalam rangka pelaksanaan APBN untuk mendukung
pengelolaan data pagu, perencanaan kas dan
referensi dalam pelaksanaan pembayaran.

• Ruang Lingkup Modul Komitmen meliputi:

– Manajemen Supplier
– Manajemen Kontrak

40
 3/16/2013

Manajemen Supplier
• Merupakan kegiatan mengelola data penerima
pembayaran, untuk kemudian didaftarkan ke SPAN
melalui KPPN.
• Supplier adalah pihak yang menerima pembayaran/
yang menjadi tujuan pembayaran
• Tipe Supplier :
• Satker;
• Penyedia Barang/Jasa;
• Pegawai;
• BA 999;
• Transfer Daerah;
• Penerusan Pinjaman;
• Lain-lain.

Manajemen Kontrak
• Merupakan kegiatan mengelola data
kontrak (perikatan dengan pihak ketiga),
untuk kemudian didaftarkan ke SPAN
melalui KPPN.
• Jenis Kontrak :
• Tahunan,
• Multi Years (Tahun Jamak),
• Release Multi Years.

41
 3/16/2013

Fungsi Utama
• Pendaftaran Supplier
– Perekaman Data Supplier (termasuk Upload Data
Pegawai)
– Pembuatan ADK Supplier
– Upload/Rekam NRS
• Pendaftaran Kontrak
– Perekaman Data Kontrak
– Pembuatan ADK Kontrak
– Upload/Rekam CAN
– Perekaman BAST
– Monitoring Kontrak

Data Supplier yang Direkam

• Supplier Header (antara lain: Nama Supplier,
NPWP)
• Supplier Site (antara lain: alamat, kode tipe
supplier, kode pos, dll)
• Bank Site (antara lain: Nomor rekening, nama
rekening, kode dan nama bank, mata uang,
dll)

42
 3/16/2013

Proses Pendaftaran Supplier

SATKER KPPN
Merekam Data
Supplier

Membuat ADK ADK Menerbitkan

Supplier Supplier NRS

Upload/Rekam NRS
NRS

Data Kontrak yang direkam

• Header Kontrak (antara lain: nomor kontrak,
tanggal kontrak, uraian kontrak, identitas
supplier, dll.
• Line Kontrak (antara lain: Cara penarikan, detil
uang muka, dll)
• Jadwal Pembayaran (antara lain: informasi
per termin, dll)
• Distribusi COA (antara lain: kombinasi COA,
dll)

43
 3/16/2013

Proses Pendaftaran Kontrak

SATKER KPPN
Merekam Data
Kontrak

Membuat ADK ADK Menerbitkan

Kontrak Kontrak CAN

Upload/Rekam CAN
CAN

44
 3/16/2013

Definisi Bendahara
• Bendahara Pengeluaran adalah orang yang ditunjuk untuk
menerima, menyimpan, membayarkan, menatausahakan
dan mempertanggungjawabkan uang untuk keperluan
belanja negara dalam rangka pelaksanaan belanja APBN
pada Kementerian Negara/Lembaga dan/atau Satker.

• Bendahara Penerimaan adalah orang yang ditunjuk untuk

menerima, menyimpan, menyetorkan, menatausahakan,
dan mempertanggungjawabkan uang pendapatan negara
dalam rangka pelaksanaan Anggaran Pendapatan dan
Belanja Negara pada kantor/ satuan kerja Kementerian
Negara/Lembaga.

Ruang Lingkup
• Modul Bendahara merupakan bagian dari
kelompok Modul Pelaksanaan Anggaran yang
fungsinya adalah menitikberatkan pada proses
penatausahaan penerimaan dan pengeluaran
negara di Bendahara.
• Proses Bisnis mencakup :
– Pengelolaan UP dan TUP
– Pengelolaan dana titipan
– Pengelolaan Penerimaan PNBP Fungsional
– Penyusunan LPJ Bendahara Penerimaan atau
Pengeluaran

45
 3/16/2013

Kedudukan Modul Bendahara

AKTIFITAS-AKTIFITAS YANG DAPAT DIAKOMODIR

OLEH MODUL BENDAHARA PADA APLIKASI SAKTI
Aktifitas Pejabat Pembuat Komitmen
No Aktifitas Deskripsi Tugas
1 Uang Persediaan  Melakukan monitoring UP
 Menginformasikan kepada Bendahara terhadap adanya
persetujuan dispensasi nilai UP dari Kanwil Perbendaharaan/ Dit.
Pelaksanaan Anggaran
2 Tambahan Uang  Melakukan monitoring TUP

Persediaan
3 Pengakuan dan  Mengesahkan kwitansi
 Membuat Surat Pernyataan Tanggungjawab Belanja (SPTB)
Pengesahan Belanja
 Membuat Bon Pengeluaran
 Melakukan monitoring Bon Pengeluaran
4 Penyelesaian Sisa UP  Melakukan monitoring UP dan TUP
 Mendapatkan informasi realisasi dan sisa UP/ TUP yang tidak di
dan TUP
belanjakan
5 Dana Titipan  Melakukan monitoring dana titipan
 Mendapatkan informasi dana titipan yang dikembalikan ke kas
Negara

46
 3/16/2013

Aktifitas Pejabat Penandatangan SPM

No Aktifitas Deskripsi Tugas

1 Uang Persediaan  Melakukan monitoring UP

2 Tambahan Uang  Melakukan monitoring TUP

Persediaan

3 Pengakuan dan  Mendapatkan informasi ketersediaan dana UP

 Membuat Perintah Bayar
Pengesahan Belanja
 Melakukan monitoring Perintah Bayar

4 Penyelesaian Sisa UP  Melakukan monitoring UP dan TUP

 Mendapatkan informasi realisasi dan sisa UP/ TUP yang tidak di
dan TUP
belanjakan

5 Dana Titipan  Melakukan monitoring dana titipan

 Mendapatkan informasi dana titipan yang dikembalikan ke kas
Negara

Aktifitas Bendahara Pengeluaran

No Aktifitas Deskripsi Tugas
1 Uang Persediaan  Mengecek program, kegiatan, dan output hingga jenis belanja/ akun
yang dapat dimintakan Uang Persediaan
 Mengusulkan besaran UP yang akan dimintakan PPK ke KPPN .

2 Tambahan Uang  Mendapatkan informasi realisasi dan sisa UP/ TUP yang tidak di
belanjakan
Persediaan
 Membuat Rincian Pembiayaan TUP
3 Pengakuan dan  Membuat kwitansi dan rekap kwitansi

Pengesahan Belanja  Mencatat dan memonitor Uang Muka

 Mencatat dan menyetorkan pungutan pajak
4 Penyelesaian Sisa UP  Mendapatkan informasi sisa UP/ TUP yang tidak di belanjakan

dan TUP  Mencatat dan menyetorkan pengembalian UP atau TUP

5 Dana Titipan  Mendapatkan informasi uang yang masuk berupa dana titipan
 Merekam dan memonitor realisasi pembayaran dana titipan
 Menyetorkan sisa dana titipan ke kas Negara melalui Setoran
Pengembalian Belanja (SSPB)

47
 3/16/2013

Aktifitas Bendahara Penerimaan

No Aktifitas Deskripsi Tugas
1 Penerimaan Fungsional  Mencatat setoran PNBP yang diterima oleh Bendahara Penerimaan

 Mencatat dan meyetorkan PNBP yang diterima langsung atau tidak

langsung

 Memonitor Realisasi Penerimaan

LPJ Bendahara pada aplikasi SAKTI

• LPJ Bendahara yang dibuat di dalam SAKTI merupakan
turunan (Subledger Account) dari akun-akun terkait
bendahara yang disajikan dalam yang Laporan
Keuangan Satker;
• Mengikuti Peraturan Direktur Jenderal
Perbendaharaan No. 47 tahun 2009 dengan
penyesuaian akun SLA
• Tidak diperlukan lagi rekonsiliasi internal antara SAI
dengan LPJ mengingat keduanya disusun dalam
sistem yang sama;

48
 3/16/2013

Laporan Pertanggung Jawaban

Bendahara
• Pos-pos sub akun didefinisikan dari beberapa akun
yang terkait dengan aktifitas Bendahara antara lain :
• Akun 111612 : Kas di Bendahara Pengeluaran UP
• Akun 111613 : Kas di Bendahara Pengeluaran TUP
• Akun 111821 : Kas Lainnya di Bendahara Pengeluaran
• Akun 111711 : Kas di Bendahara Penerimaan
• Akun 219961 : Utang Potongan Bendahara yang belum di setor
• Akun 219962 : Utang Perwalian Bendahara yang belum
disampaikan kepada pihak ketiga
• Akun 219611 : Pendapatan yang ditangguhkan

Kodifikasi Akun SLA Modul Bendahara

Akun Sub Akun Uraian
111612 A0001 Kas UP di Bank
A0002 Kas UP Tunai
A0003 Kwitansi belum di SPJ kan atas dana UP
A0004 Bon Pengeluaran atas dana UP
111613 B0001 Kas TUP di Bank
B0002 Kas TUP Tunai
B0003 Kwitansi belum di SPJ kan atas dana TUP
B0004 Bon Pengeluaran atas dana TUP
111711 F0001 Kas Penerimaan di Bank
F0002 Kas Penerimaan Tunai
111821 C0001 Kas Lainnya di Bank
C0002 Kas Lainnya Tunai
219961 D0001 Potongan PPh Pasal 21
D0002 Potongan PPh Pasal 22
D0003 Potongan PPh Pasal 23
D0004 Potongan PPh Pasal 4 ayat 2
D0005 Potongan PPN
219962 E0001 Titipan utang perwalian pihak ketiga
219611 G0001 Pendapatan PNBP yang ditangguhkan

49
 3/16/2013

Skema Integrasi Pembukuan

Bendahara
BB : UTANG Pihak
Ke-3
-Titipan Gaji
-Titipan Honor

Transfer
BB : KAS UP BB : KAS An.Potg BB : KAS TUP
-Kas Tunai Lainnya -Kas Tunai
-Kas Bank -Kas Tunai -Kas Bank
Transfer
-Kwitansi -Kas Bank -Kwitansi
An.Potg
-Bon -Bon
Pengeluaran Pengeluaran

BB : UTANG Pot
Bendahara
-Pot Pajak PPh Psl xx
-Pot Pajak PPN

50
 3/16/2013

DEFINISI

Modul Pembayaran adalah salah satu modul dalam

Aplikasi SAKTI yang digunakan Satuan Kerja untuk
memproses Resume Tagihan dan Surat Perintah
Membayar (SPM) untuk diajukan ke KPPN.

101

INTERAKSI SATKER DAN KPPN

• Proses Request for Commitment (RfC)

– Perekaman Data Supplier dan Resume Kontrak
– Pencadangan dana DIPA (Encumbrance)
• Proses Resume Tagihan
– Perekaman Data Supplier (Khusus untuk Continuing
Commitment)
– Pengakuan pembebanan (Accrual Accounting)
– Perencanaan Kas (Manajemen Kas)
• Proses SPM
– Approval SPP/Resume Tagihan
– Proses pembayaran/ settlement

51
 3/16/2013

102
PROSES BISNIS MANAJEMEN PEMBAYARAN

103

PENGIRIMAN RESUME TAGIHAN DAN SPM

• Resume tagihan : Data SPP yang dikirim ke KPPN.

• Ditentukan jatuh tempo tagihan.
• Fungsi untuk :
- Pengakuan beban
- Perencanaan kas
• Pengecekan Data Supplier, data kontrak dan
Ketersediaan Dana, dll.
• SPM diajukan sebelum tanggal jatuh tempo.

52
 3/16/2013

PENERAPAN PAYMENT TERMS

• Fungsi : Perencanaan Kas Jangka Pendek

• Satker (PPK) menentukan secara fleksibel
tanggal jatuh tempo tagihan sesuai dengan
kebutuhan (1 s/d 14 hari kerja).
• Perhitungan jatuh tempo sejak tanggal Resume
Tagihan sampai dengan tanggal penerbitan
SP2D dan atau Transfer Dana.

PENERAPAN PAYMENT TERMS

Penerbitan SP2D /
Penerbitan SPP
Transfer Dana

Waktu
1 2 3 4 5 6 7 8 9 10 11 12 13 14

Penerbitan SPM

Payment Terms

53
 3/16/2013

DEFINISI
Adalah salah satu komponen Sistem Aplikasi
Keuangan Tingkat Instansi (SAKTI) yang
dikhususkan untuk menangani pengelolaan
barang persediaan di tingkat satuan kerja dan
satuan kerja pembantu.

54
 3/16/2013

RUANG LINGKUP
Ruang lingkup modul persediaan mencakup:
• Pengelolaan persediaan di satuan kerja (induk)
• Pengelolaan persediaan di satuan kerja
pembantu

FUNGSI
Fungsi utamanya antara lain:
• Migrasi data persediaan
• Transaksi persediaan masuk
• Transaksi persediaan keluar
• Penghapusan
• Opname fisik
• Pelaporan

55
 3/16/2013

ALUR PROSES & KETERKAITAN

DENGAN MODUL LAIN

Komitmen Aset Tetap

Persediaan

Bendahara GL/Pelaporan

 BAST dari komitmen atau  Persediaan melakukan  Summary transaksi

kuitansi dari bendahara pencatatan atas keluar persediaan dipergunakan
menjadi dasar pencatatan masuknya barang oleh aset tetap
barang persediaan persediaan, melakukan
 Jurnal transaksi
opname fisik dan membuat
persediaan dikelola oleh
laporan
GL/pelaporan

FITUR TAMBAHAN
• MIGRASI DATA
memindahkan data persediaan dari aplikasi persediaan ke
database modul persediaan SAKTI
• BAST/KUITANSI
keterkaitan langsung dengan modul bendahara dan modul
komitmen dalam proses pembelian barang persediaan
• SATKER PEMBANTU
mengakomodir adanya peran satker pembantu dengan
dukungan sistem yang antara lain transfer data persediaan
maupun aktivasi persediaan

56
 3/16/2013

Pengelolaan persediaan
di satuan kerja pembantu
• Satuan kerja (satker) pembantu merupakan sub dari satker
induk
• Satker pembantu yang offline dengan satker induknya harus
mempunyai referensi persediaan yang sama dengan satker
induknya
• Satker pembantu yang offline membutuhkan mekanisme
aktivasi dari satker induk untuk bisa menggunakan barang
persediaannya
• Satker pembantu yang offline bertugas untuk mengirimkan
data transaksi persediaannya ke satker induk secara periodik
• Laporan persediaan secara keseluruhan dikelola oleh satker
induk

57
 3/16/2013

Definisi modul aset tetap

Merupakan salah satu modul dalam Aplikasi SAKTI
yang digunakan untuk pencatatan dan
pengakuntansian penambahan, perubahan dan
penghapusan Barang Milik Negara dan konstruksi
dalam pengerjaan serta melakukan perhitungan
penyusutannya.

Fungsi modul aset tetap

1. Penatausahaan Barang Milik Negara, termasuk di
dalamnya Konstruksi Dalam Pengerjaan, Barang
Bersejarah, dan Barang Pihak Ketiga yang
digunakan atau dikelola oleh instansi pemerintah.
2. Penatausahaan dan pencatatan semua transaksi
mutasi BMN, baik itu perolehan, perubahan, dan
penghapusan.
3. Pengakuntansian BMN sebagai aset tetap dengan
basis akrual.
4. Perhitungan dan pengakuntansian penyusutan Aset
Tetap.

58
 3/16/2013

Kaitan modul sakti terhadap modul ASET TETAP

Modul Modul
Administrasi Aset Tetap
INF. ASET TETAP DARI
KOMITMEN DAN BENDAHARA
SUMMARY PERSEDIAAN, REFERENSI,
REFERENSI ASET TETAPINF. POSTING DAN CLOSING

TRANSAKSI ASET TETAP,

JURNAL ASET TETAP,
INF. ASET TETAP CLOSED
JURNAL ASET TETAP &
Modul GL dan INF. ASET TETAP CLOSED Modul
Pelaporan DB ASET TETAP PEMBELIAN
Bendahara
INF. POSTING DAN CLOSINGSAKTI BENDAHARA

TRANSAKSI SUMMARY ASET TETAP PEMBELIAN

PERSEDIAAN KONTRAK

Modul Persediaan Modul Komitmen

BEBERAPA PENAMBAHAN FITUR PADA MODUL ASET TETAP

No. Uraian
1 Pencatatan Barang Hilang
2 Pencatatan Barang Yang Mau Di Hapuskan
3 Transfer Internal
4 Perubahan Elemen Data Penyusutan
5 Perhitungan Penyusutan Data Migrasi
6 Perhitungan Penyusutan Periodik
7 Validasi
8 Persetujuan Transaksi
9 Monitoring Status Transaksi
10 Aktifasi ADK dari UAPKPB
11 Summary Data Base
12 Proses Tutup Transaksi Bulanan

59
 3/16/2013

MIGRASI DATA SIMAK-

SIMAK-BMN KE SAKTI

APLIKASI SIMAK-
SIMAK-BMN SAKTI MODUL
ASET TETAP

ADK MIGRASI
UPLOAD ADK
CREATE ADK SIMAK--BMN
SIMAK MIGRASI
MIGRASI

KETENTUAN MIGRASI

1. Aplikasi SIMAK-BMN CETAK

menghasilkan ADK dalam Bentuk LAPORAN
CSV File BARANG
2. Hanya Level Satker dan
Pembantu Satker yang
melakukan migrasi
3. Konversi dilakukan sekali bersifat
final dan akan masuk periode 12
dalam aplikasi SAKTI PROSES
MIGRASI
4. Apabila ada perubahan hasil
konversi yang dikarenakan
keteledoran saat konversi,
DB Koreksi Unaudited atau Koreksi
Audited dilakukan dengan
SIMAK-BMN
penginputan data pada Aplikasi
SAKTI modul Aset Tetap dengan
periode 13 dan 14

KAITAN PEMBELIAN ASET ANTARA

MODUL BENDAHARA DAN MODUL ASET TETAP/PERSEDIAAN

UAKPB
MODUL
KOMITMEN
MODUL
A. CATAT BAST
ASET TETAP
B. CATAT BARANG
1. KODE SUB-SUB KEL
2. JUMLAH BARANG
3. NILAI BARANG
C. MEMBUAT JURNAL ASET
MODUL
(ASET YANG BELUM TEREGISTER) PERSEDIAAN

A. MEMANGGIL NO. BAST/NO. KWITANSI

B. MELAKUKAN PENDETAILAN ASET
C. MEMBUAT JURNAL ASET
MODUL 1. MEMBALIK ASET YANG BELUM TEREGISTER
BENDAHARA 2.MEMBUAT JURAL ASET DEFINITIFNYA

A. CATAT KWITANSI
B. CATAT BARANG
1. KODE SUB-SUB KEL
2. JUMLAH BARANG
3. NILAI BARANG
C. MEMBUAT JURNAL ASET
(ASET YANG BELUM TEREGISTER)

60
 3/16/2013

Definisi
• Modul GL dan Pelaporan merupakan sub
sistem dari Sistem Aplikasi Keuangan Tingkat
Instansi (SAKTI) yang memuat keseluruhan
proses yang terkait dengan akuntansi dan
pelaporan.
• Metode pencatatan akuntansi yang dipakai
aplikasi berbasis akrual.

61
 3/16/2013

Ruang Lingkup
• Sistem akuntansi yang terintegrasi dengan
modul-modul lain terkait
• Sistem pelaporan manajerial (statistik)
• Sistem rekonsiliasi dan konsolidasi pelaporan

Fungsi
• UAKPA (Unit Akuntansi Kuasa Pengguna Anggaran),
merupakan Satker (satuan kerja) yang berperan sebagai
unit pelaporan hirarki terbawah.
• UAPPA-W (Unit Akuntansi Pembantu Pengguna Anggaran -
Wilayah), merupakan Satker yang berperan sebagai unit
pelaporan level wilayah (propinsi).
• UAPPA-E1 (Unit Akuntansi Pembantu Pengguna Anggaran –
Eselon 1), merupakan Satker yang berperan sebagai unit
pelaporan level Eselon 1 (Direktorat Jenderal pada masing-
masing kementerian/lembaga).
• UAPA (Unit Akuntansi Pengguna Anggaran), merupakan
Satker yang berperan sebagai unit pelaporan level
Kementerian/Lembaga).

62
 3/16/2013

Alur Proses
Proses Bisnis Modul GLP

1 SAKTI
Modul SAKTI
(Sub-Ledger)

Input Data Jurnal Modul

SAKTI (Sub-Ledger)

3 GLP 2 SAKTI 5 GLP 6 GLP

Input Jurnal Datastore

Penyesuaian & Integrasi Data Jurnal Posting Cetak Laporan
Trial Balance
Validasi
Modul GL Pelaporan (GLP)
SAKTI

8 GLP
4 GLP
Unduh ADK
Unggah ADK Konsolidasi
Konsolidasi

7 GLP

Unduh ADK
Rekonsiliasi

Fitur tambahan
• Penjurnalan dari sub modul
• Tutup Periode lebih jelas
• Proses konsolidasi via LAN (SAKTI Online)
• Monitoring penyelesaian rekonsiliasi dan
konsolidasi
• Proses rekonsiliasi dan konfirmasi

63
 3/16/2013

Definisi & Ruang Lingkup

Modul Administrasi adalah suatu modul yang
diperuntukan bagi seorang administrator dalam
mengelola data referensi, data user, user manual, dan DB
SAKTI.

Modul Administrasi meliputi:

1. Pengelolaan Referensi seluruh modul
2. User Management
3. Dokumentasi bantuan
4. Backup / Restore Data (referensi / data transaksi)
5. Security Management.

64
 3/16/2013

Pengguna Modul Administrasi

Pengguna Modul Administrasi adalah:
1. Administrator Pusat
Posisinya berada di Kantor Pusat untuk SAKTI Online. Tugas:
- Mengelola data pengguna dimana versi online ini terdapat
multi user dan multi satker.
- Mengelola data referensi umum & DB Sakti Online.
2. Administrator Satker
Posisinya berada di Unit Instansi Satker tersebut bekerja.
Tugas mengelola:
- Data user lokal
- Data referensi lokal serta DB dimana Sakti itu terinstal.

Security
• Menerapkan metode enkripsi/dekripsi
• Auditrail untuk setiap data transaksi
• Setiap user login akan tercatat

65
 3/16/2013

Pengelolaan Data Referensi

Mengelola Referensi modul di SAKTI
1. Referensi di modul penganggaran
2. Referensi di modul komitmen
3. Referensi di modul bendahara
4. Referensi di modul pembayaran
5. Referensi di modul persediaan
6. Referensi di modul aset
7. Referensi umum untuk banyak modul

66
 3/16/2013

Definisi dan Ruang Lingkup

• Sistem layanan informasi SPAN berbasis Short

Message Service sebagai pendukung dan pelengkap
portal SPAN dalam menjembatani Satuan Kerja
dengan SPAN.

• Tiga tipe pengguna:

– Administrator, sebagai pengelola server SPAN SMS
– KPPN, sebagai operator lokal
– Satker, sebagai pengguna layanan

132 Sabtu, 16 Maret

2013

Fungsi

• Tracking status ADK

• Pesan broadcast dari KPPN ke satker mitra kerja
• Komentar, kritik dan saran
• Aktivasi, ubah dan blokir PIN Pejabat

133 Sabtu, 16 Maret

2013

67
 3/16/2013

Alur Proses

Transaksi
• Cek status ADK
• Ganti PIN
Aktivasi • Aktivasi PIN Pejabat
• Merubah PIN awal • Ubah PIN Pejabat
menjadi PIN baru • Blokir PIN Pejabat
• Otomatis aktif untuk • Komentar, kritik,
PIN Pejabat saran
• dll.
Registrasi
• Mengisi formulir
pendaftaran
• Otomatis terdaftar
dari portal untuk PIN
Pejabat

134 Sabtu, 16 Maret

2013

Hubungan Antar Modul

135 Sabtu, 16 Maret

2013

68
 3/16/2013

Definisi dan Ruang Lingkup

• Portal SPAN adalah sistem yang akan melakukan
integrasi informasi berkaitan dengan
implementasi SPAN.
• Portal SPAN merupakan aplikasi berbasis web
yang mendukung SAKTI, dimana lalu lintas ADK
ke/dari SPAN dilakukan melalui Portal SPAN.
• User dapat memanfaatkan fasilitas portal ini
setelah terlebih dahulu melakukan login dengan
memasukkan username dan password yang
sudah terdaftar.

69
 3/16/2013

Fitur Utama

• Unggah dan Unduh ADK SAKTI

• Status ADK SAKTI
• Update SAKTI dan Data Referensi
• Blokir PIN Pejabat
• Informasi Peraturan, berita dan FAQ terkait
SAKTI dan SPAN

Interkoneksi SAKTI - SPAN

70
 3/16/2013

Interaksi

Portal SPAN berinteraksi dengan Modul lain

pada SAKTI, yaitu:
• Modul Penganggaran
• Modul Komitmen
• Modul Pembayaran
• Modul GL dan Pelaporan
• Modul Admin
• Modul SMS

Pengguna

• Satker
• KPPN
• Kantor Pusat DJPB

71
 3/16/2013

Ack*

• Upload di Portal
• Dikirim ke SPAN
• Proses di SPAN
• Ditolak
• Proses Selesai

* Fungsi yang disediakan pada Portal SPAN untuk mengetahui status ADK SAKTI yang telah
diunggah oleh Satker

TERIMA KASIH

72