Modul SPAN PDF

DAFTAR ISI
Daftar Isi …………………………………………………………………............... i

BAB I Pendahuluan ……………………………………………………................ 1
A. Latar Belakang....………………………………………................ 1
B. Gambaran Umum SPAN dan SAKTI....................................... 2
1. Latar Belakang Strategis SPAN.......................................... 2
2. Visi dan Misi SPAN............................................................... 4
3. Keunggulan SPAN.............................................................. 5
4. Pilar pada Pengembangan SPAN ................................. 5
5. SAKTI................................................................................... 7
BAB II Proses Bisnis SPAN…………........................................................... 9
A. Manajemen DIPA............................................................ 9
1. Pengertian dan Konsep Dasar.......................................... 9
2. Proses Bisnis Manajemen Komitmen................................. 9
B. Manajemen Komitmen............................................................ 11
3. Pengertian dan Konsep Dasar.......................................... 11
4. Proses Bisnis Manajemen Komitmen................................. 12
C. Manajemen Pembayaran....................................................... 18
1. Pengertian dan Konsep Dasar........................................... 18
2. Proses Bisnis Manajemen Pembayaran............................. 19
D. Manajemen Penerimaan......................................................... 24
1. Pengertian dan Konsep Dasar............................................ 24
2. Proses Bisnis Manajemen Penerimaan............................... 27
E. Manajemen Kas........................................................................ 29
1. Pengertian dan Konsep Dasar........................................... 29
2. Proses Bisnis Manajemen Kas.............................................. 30
F. Manajemen Pelaporan............................................................ 32
1. Pengertian dan Konsep Dasar............................................ 32
2. Proses Bisnis Manajemen Pelaporan.................................. 33
G. SAKTI ........................................................................................... 41
1. Ruang Lingkup SAKTI ............................................................ 41
2. Koneksitas SPAN – SAKTI ....................................................... 42
BAB III Teknologi dan Informasi SPAN.......................................................... 44
BAB IV Penutup ............................................................................................. 47
REFERENSI ......................................................................................................... 48
Pengenalan Tingkat Dasar Proses Bisnis SPAN 1

BAB I
PENDAHULUAN
3.8.1. Latar Belakang
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
(Government Financial Management and Revenue Administration Project atau
GFMRAP) yang meliputi 4 bidang besar, yaitu Public Financial Management,
Revenue Administration, Governance and Accountability dan Project Governance
and Implementation.
Dalam bidang Public Financial Management, perubahan yang
terbesar adalah dalam hal budget and treasury modernization dimana
bentuk riilnya adalah dengan adanya implementasi SPAN. SPAN adalah
komponen terbesar GFMRAP dan selanjutnya akan menjadi pondasi untuk
reformasi PFM (Public Financial Management). SPAN akan
diimplementasikan menggunakan Treasury Reference Model (TRM) sebagai
dasar atau acuan, dimodifikasi sesuai dengan kebutuhan khas Indonesia.
Sebagai pondasi PFM, SPAN akan memfasilitasi arah kebijakan
penganggaran, mensuport 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 IFMIS ( Integrated Financial
Management Information System). Diharapkan pengembangan SPAN
merupakan langkah awal menuju implementasi IFMIS. IFMIS merupakan
paket pengelolaan keuangan yang terintegrasi dan terkomputerisasi yang
dimaksudkan untuk meningkatkan efektifitas dan transparansi dalam
pengelolaan keuangan negara. IFMIS terdiri dari beberapa unsur dimana
terdapat perbedaan antara satu negara dengan negara lainnya.

(1) Gambaran Umum SPAN dan SAKTI
1. Latar Belakang Strategis SPAN
Pemerintah melalui Kementerian Keuangan melakukan Reformasi
Manajemen Keuangan Negara (Government Financial Management
Reform), langkah awal adalah dengan melakukan kerja sama dengan
Bank Dunia melalui program Government Financial Management and
Revenue Administration Project (GFMRAP). Tujuan dari program GFMRAP
adalah untuk memperkuat efisiensi dan integritas dalam manajemen
keuangan publik dan administrasi pendapatan, terutama melalui
penguatan tatakelola, akuntabilitas dan transparansi.
SPAN merupakan sub-program dari program reformasi keuangan publik
terbesar dalam sejarah di Indonesia yakni Government Financial Management
and Revenue Administration Project (GFMRAP). Untuk Reformasi Sistem
Manajemen Keuangan dalam konteks penerapan IFMIS, pada tahap awal
difokuskan pada reformasi penganggaran dan perbendaharaan negara
(Budget and Treasury Modernization), rkegiatan-kegiatan yang akan dilakukan
di Direktorat Jenderal Anggaran (DJA) dari sisi persiapan anggaran (Budget
Preparation) dan Direktorat Jenderal Perbendaharaan (DJPB) dari sisi
pelaksanaan anggaran dan pertanggungjawaban akuntansi (Budget Execution
and Responsibility Accounting). 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.
Kementerian Keuangan Kementerian Keuangan (KPPN) SPAN dimplementasikan
dengan Budget & Treasury Reference Model (TRM) sebagai dasar dan acuan,
dimodifikasi sesuai kebutuhan Indonesia. SPAN dibangun menggunakan tiga

pilar sekaligus, yang membedakan dengan cara membangun dengan era
sebelumnya. Kita terapkan sekaligus beberapa komponen mulai dari proses,
people, dan teknologi. Termasuk, skillful dan mindset dari orang yang akan
menjalankan proses bisnis perlu dirubah. Proses yang kita improve kepada
publik akan berjalan baik kalo dari sisi IT dan human side juga baik.
Berdasarkan PMK No 276 tahun 2008 program reformasi SPAN
dilaksanakan melalui tiga komponen utama yaitu : reformasi Proses Bisnis,
reformasi Sistem Teknologi Informasi, dan Tata Kelola Perubahan.
Reformasi Proses Bisnis dikembangkan melalui beberapa modul yaitu
perencanaan anggaran (budget preparation), manajemen DIPA
(management of spending authority), Manajemen Komitmen
(commitment management), Manajemen Pembayaran (payment
management), Manajemen Kas (cash management), Akuntansi (general
ledger and chart of account), dan Pelaporan (reporting).
PMK Nomor 276 tahun 2008 tentang Program Reformasi Sistem Perbendaharaan
dan Anggaran Negara menyebut secara jelas tentang tujuan dilaksanakan
program tersebut, yaitu :
1. Mengendalikan anggaran Negara, asset, dan kewajiban Pemerintah
Pusat;
2. Menyediakan informasi yang komprehensif, dapat dipercaya, dan tepat
waktu tentang keuangan pemerintah;
3. Memudahkan pengambilan keputusan dalam manajemen keuangan
pemerintah.
Sasaran yang ingin dicapai meliputi :
1 Otomasi proses operasional penganggaran dan pegelolaan kas, asset
dan utang pemerintah;
2 Peningkatan keandalan proses penganggaran dan pengelolaan kas,
asset dan utang pemerintah;
3 Peningkatan efisiensi layanan kepada kementrian Negara/lembaga,
masyarakat dan perbankan;
4 Peningkatan akuntabilitas melalui penyusunan dan penyajian laporan
keuangan yang lebih komprehensif, akurat dan tepat waktu;

5 Penyediaan fasilitas rekonsiliasi yang andal, akurat, serta tepat waktu
antara pemerintah dan perbankan;
6 Penyediaan jejak audit (audit trail) untuk memfasilitasi proses audit akun
pemerintah;
7 Mengintegrasikan data pada berbagai subsistem manajemen keuangan
pemerintah.
Sedangkan manfaat yang ingin dicapai adalah :
1 Tersedianya system pengendalian alokasi dan pelaksanaan anggaran
yang efektif;
2 Tersedianya system pengelolaan kas yang terpercaya;
3 Tersedianya system pelaporan manajerial tentang tentang operasi
keuangan pemerintah yang komprehensif, dapat diandalkan dan
realtime;
4 Terwujudnya tahapan transisi penerapan system akuntansi dari berbasis
kas ke berbasis akrual, dan;
5 Terlaksananya pelayanan kepada public yang lebih efisien.
Dengan adanya kejelasan tujuan, sasaran dan manfaat dari pelaksanaan
reformasi pengelolaan keuangan Negara melalui SPAN, diharapkan program
SPAN menghasilkan output berupa system pengelolaan keuangan Negara yang
bisa diimplementasikan demi terwujudnya pengelolaan keuangan Negara yang
professional, transparan, dan akuntabel sebagaimana amanat Undang-Undang
Keuangan Negara.
i. Visi dan Misi SPAN

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 :
2 Mengembangkan proses bisnis secara berkelanjutan dengan
mendasarkan pada praktek penyelenggaraan yang sesuai dan terbaik.

3 Menerapkan paket solusi yang terintegrasi untuk mendukung system yang
aman, akurat dan handal.
4 Memastikan diterimanya perubahan oleh pemangku kepentingan dan
memberikan solusi lengkap terhadap dampak perubahan.
Untuk mendukung visi dan misi SPAN, mottonya adalah “dengan SPAN banyak hal bisa
diselesaikan”.
ii. Keunggulan SPAN.

Sistem Perbendaharaan dan Anggaran Negara (SPAN) merupakan system yang
mengintegrasikan data dari siklus pengelolaan keuangan Negara (mulai dari
penyusunan anggaran sampai dengan pelaporan) secara online yang akan
membawa perubahan terhadap prosedur kerja, sistem aplikasi yang
dipergunakan dan organisasi kearah yang lebih baik. Karateristik SPAN dapat
dijelaskan sebagai berikut :
a. 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.
b. Secara Online
Siapa pun yang memiliki akses terhadap data tersebut dapat
mengambil data tersebut dari mana pun, asalkan bisa terhubung
dengan internet.
c. Perubahan prosedur kerja
Adanya penyempurnaan prosedur kerja.
d. Perubahan system aplikasi
Adanya penyempurnaan sistem aplikasi.
e. Perubahan organisasi
Adanya penyempurnaan organisasi, baik secara struktur maupun
sumber daya manusia (SDM).
SPAN terdiri atas modul-modul yang dapat dikelompokkan dalam tiga proses
yaitu :

1) Perencanaan Anggaran, yang terdiri atas Modul Penyusunan Anggaran
(Budget Preparation)
2) Pelaksanaan Anggaran, yang terdiri atas :
i. Modul Manajemen DIPA (Management of Spending Authority)

ii. Modul Manajemen Komitmen (Commitment Management)
iii. Modul Manajemen Pembayaran (Payment Management)
iv. Modul Penerimaan Negara (Government Receipt )
v. Modul Manajemen Kas (Cash Management)
3) Akuntansi dan Pelaporan, terdiri atas :
i. Modul Buku Besar dan Bagan Akun Standar (General Ledger and
Chart of Accounts)
ii. Modul Pelaporan (Reporting)
iii. Pilar SPAN

Terdapat 3 (tiga) pilar dalam pengembangan SPAN, yaitu :
1. Business Process Improvement (BPI)
Penelahaan dan perbaikan Treasury Model yang mengacu pada best
practices dan kekhasan pada Kementrian Keuangan. BPI bertujuan
menyelaraskan antara bisnis proses di DJA dan di DJPBN sehingga
menjadi landasan untuk pelaksanaan Commercial Of The Shelf
(COTS) solution SPAN
2. Information Technologie (IT)
Solusi COTS (Commercial Off The Shelf) menfasilitasi dan mengotomasi
implementasi Trasury Model. 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. Didunia keuangan, salah satu
contoh COTS adalah Oracle Finance (Orafin).
3. Change management and Communications (CMC)

Berperan mempersiapkan organisasi dan sumber daya manusia untuk
menerima mindset dan cara 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.
ii. Mengidentifikasi tingkat kesiapan dari organisasi (DJPBN, DJA dan
Pusintek) serta K/L 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.
iv. Sistem Aplikasi Keuangan Tingkat Instansi ( SAKTI )Di luar Modul SPAN,
dikembangkan Modul Manajemen Satker yang mengatur tugas
dan kewenangan Satker dalam mengelola APBN, yang meliputi
proses persiapan penganggaran, pelaksanaan anggaran,
pelaporan dan pertanggungjawaban.
Dalam lingkup satuan kerja, perubahan yang akan dilaksanakan meliputi
penyederhanaan aplikasi yang sangat banyak pada satuan kerja
dengan data base yang terpisah-pisah, menjadi satu aplikasi dengan
data base yang terintegrasi. Penyederhanaan sistem aplikasi ini untuk
mengurangi terjadinya duplikasi pekerjaan dan 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 Keuangan Tingkat Instansi
(SAKTI).
SAKTI meliputi seluruh proses pengelolaan keuangan negara pada
SATKER dimulai dari proses Penganggaran, Pelaksanaan dan Pelaporan.
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. SAKTI merupakan gabungan beberapa aplikasi yang
keberadaan sebelumnya tersebar pada beberapa kewenangan, seperti
bendahara, KPB, PPK, dan PPSPM. 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.
Aplikasi tingkat satuan kerja 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 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.
Ruang Lingkup SAKTI

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 kurang lebih 24.000 satuan kerja tentu
membutuhkan ketersediaan infrastruktur yang sangat besar. Selain itu,
penggunaan aplikasi COTS (commercial off the self) untuk user/client sebanyak
itu, 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”. Aplikasi SAKTI
menjadi jawaban terhadap tantangan dalam reformasi pengelolaan keuangan
publik, namun dengan tetap memperhatikan kapasitas jaringan infrastruktur
pada satuan kerja sehingga 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 RFC,
Supplier, resume tagihan dapat dilakukan tidak hanya dengan dokumen (paper
base) namun juga secara elektronik dan tanpa dokumen (paperless).
Koneksitas SPAN-SAKTI
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. 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.
SAKTI mencakup seluruh proses pengelolaan keuangan negara pada
Satker, yangdimulai dari proses Penganggaran, Pelaksanaan Anggaran sampai
dengan Pelaporan. 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 mengingatSatker BUN
sudah terintegrasi dengan SPAN, kecuali untuk Belanja Subsidi dan Belanja
Lainnya.
Bagan 4
Flowchart SAKTI
BAB II
Proses Bisnis SPAN
A. MANAJEMEN DIPA
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
kementrian/lembaga negara di pusat, DPR, seluruh KPPN dan institusi
pemerintah lainnya yang ditetapkan.
Sistem pelaksanaan anggaran harus memenuhi sasaran dari Public
Expenditure Management (PEM) yaitu pengawasan pengeluaran secara
menyeluruh, alokasi strategis dan efisiensi pelaksanaan. Dalam sistem
pelaksanaan anggaran sebelumnya mengacu pada : fokus pada
kepatuhan dan meyakinkan penerapan disiplin fiscal.
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 juga disesuaikan dengan kewenangan DJPB dalam kaitannya
dengan tugas sebagai BUN antara lain apabila terjadi kesalahan dalam
pencantuman kode kantor bayar, cara penarikan dan sebagainya oleh
satker.
2. Proses Bisnis Manajemen DIPA
Proses bisnis manajemen DIPA Future terdiri dari 3 aktivitas utama

(bisnis domain) yaitu penerbitan DIPA, revisi DIPA, dan pelaksanaan
penggunaan dana. Secara ringkas, proses bisnis DIPA kedepanya adalah
:
a. Pengesahan DIPA

Pengesahan DIPA pada dasarnya dibagi menjadi beberapa
alur kerja (workflow) yaitu, Pengesahan DIPA biasa, pengesahan DIPA
Sementara, carry forward dan Vote on Account.
1. Pengesahan DIPA biasa

2. Pengesahan DIPA sementara
3. Pengesahan DIPA Vote on Account
4. Pengesahan DIPA Format Khusus
Gambar 1. Umum Proses Pengesahan DIPA
b. Revisi DIPA
Revisi DIPA kedepan akan terdiri dari terdiri dari revisi DIPA akibat
Perubahan Rincian Anggaran Belanja Pemerintah Pusat (RABPP), Revisi
DIPA tanpa perubahan RABPP dan revisi ambang batas BLU. Revisi
DIPA pada dasarnya adalah semua perubahan yang terjadi pada
DIPA atas usulan satker. Berikut akan dijelaskan mengenai bisnis proses

revisi DIPA yang dimulai dari revisi akibat perubahan RABPP. Revisi DIPA
ini dibagi menjadi :
1. Revisi DIPA tanpa perubahan RABPP

2. Revisi DIPA dengan perubahan RABPP
3. Revisi DIPA lintas kanwil oleh DJPBN cq Dit Pelaksanaan Anggaran
4. Updating Pagu DIPA BLU
5. Updating Komponen Input
6. Revisi halaman III secara manual
Gambar 2. Umum Flowchart Revisi DIPA
B. MANAJEMEN KOMITMEN
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 :3
Dalam rangka SPAN secara garis besar komitmen dibagi menjadi 2, yaitu
b. 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.
Jenis pengeluaran yang termasuk ke dalam specific commitment antara
meliputi 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
4
Tambahan Uang Persediaan
c. 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
2
pertanggungjawabannya (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
Kerangka pelaksanaan manajemen komitmen adalah sebagai berikut :

4
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(*)

(*)
Bagian dari proses bisnis manajemen komitmen yang dikelola oleh KPPN
Komitmen (*) Hutang (*) Belanja
Daftar Rekanan
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 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
- - =
Detail dari aktivitas yang dilakukan di KPPN pada saat registrasi data
komitmen melalui upload data Resume Kontrak adalah sebagai berikut:
Step Status OtoritasdanAktivitas Notes
FO FO FO FO
I II III IV
1 In-complete Masing-masing petugas di Front Office dapat meng-upload RFC No PO dihasilkan
untuk Satker 100001 s.d 100020
2 Incomplete Aktivitas “Check Fund”, Status PO berubah menjadi Incomplete Pagu
dicadangkan
3 In-process Penyampaian PO (status incomplete) kepada pejabat dengan
kewenangan masing-masing berdasarkan parameter yang
dalam system aplikasi
Kasi PB 1 Kasi PB II
Approvial RFC for Satker Approval RFC for Satker
(100001 s.d 100010) (100011 s.d. 100020)

--aloksiditentukandalam --aloksiditentukandalam
parameter sistem-- parameter sistem--
4 Approved/ Menerima report hasil check fund, dan melakukan approval Approved:
Rejected atau rejection No PO
berlakusebagai
No CAN
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.

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.
5Gambar Ilustrasi Penyampaian antara data supplier dengan RFC dan Resume
tagihan

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

A. MANAJEMEN PEMBAYARAN
Cakupan Proses Manajemen Pembayaran:

- Proses Pendaftaran Tagihan sampai dengan Pembayaran
-- Pembayaran Langsung
-- Pembayaran Uang Persediaan
-- Pembayaran yang berasal dari Pinjaman dan Hibah
-- Pembayaran Satuan Kerja PNBP
- Proses Pengesahan Pendapatan dan Pengeluaran dengan menggunakan
Modul Pembayaran.
-- Pengesahan BLU
-- Pengesahan Hibah Langsung
Konsep dasar manajemen pembayaran:
- Integrasi sistem
- Accrual dan penerapan payment term
- Lesspaper
- Otomatisasi Sistem Pengujian Tagihan
- Perbaikan Pola Hubungan satuan kerja, KPPN dan Perbankan

Proses Bisnis Manajemen
PembayaranG67
Gambar Proses Bisnis Manajemen Pembayaran SPAN System
2 Pendaftaran Resume Tagihan

Pengguna Aplikasi :
1. Front Office KPPN, Staff Seksi Pencairan Dana
Untuk tagihan dengan mekanisme Langsung (LS), Uang Persediaan
(UP), Satuan Kerja PNBP, Pengesahan BLU, Pengesahan Hibah
Langsung, dan Reksus.
2. Front Office KPPN Khusus Jakarta VI,
Untuk tagihan dengan sumber dana Pinjaman dan Hibah.
3. Staff dan Pejabat Pembuat Komitmen,
Untuk tagihan dengan Bagian Anggaran 999 (Bendahara Umum
Negara).
Proses Pendaftaran Resume Tagihan :
Proses Pendaftaran Resume Tagihan dalam aplikasi dikenal secara
luas sebagai invoicing. Proses ini digunakan dalam SPAN sebagai
perekaman tagihan kepada database baik untuk keperluan
pembayaran, penyaluran uang persediaan, pengesahan, maupun
pembayaran yang bersumber dari pinjaman dan hibah.
Dalam proses ini selain sebagai perekaman tagihan, juga berfungsi
sebagai perekaman jatuh tempo tagihan yang dihitung dengan

menggunakan payment term. Payment term ditentukan oleh Pejabat
Pembuat Komitmen (PPK), yaitu pihak yang mengetahui secara pasti
kapan pembayaran harus dilakukan. Payment term dihitung
berdasarkan tanggal diterimanya Resume Tagihan sampai dengan
pembayaran akan dilakukan menggunakan jumlah hari kerja.
Proses pertama Pendaftaran Resume Tagihan adalah melakukan
perekaman data yang dapat dilakukan dengan beberapa cara :
B. Unggah
Proses unggah dilakukan oleh pengguna dengan meng-
unggah data berupa file excel melalui menu upload di aplikasi
yang berisi field-field yang diperlukan untuk perekaman
Resume Tagihan.
Untuk keperluan data legacy (peralihan aplikasi saat ini
dengan aplikasi SPAN), file ini akan dihasilkan oleh aplikasi
konversi yang dibangun oleh Direktorat Sistem
Perbendaharaan (DSP) sebagai pengembang aplikasi saat ini.
Aplikasi konversi akan menghasilkan tiga fisle untuk keperluan
pembayaran ini, yaitu file untuk modul manajemen suplier
(penerima pembayaran), file untuk modul manajemen
komitmen (apabila tagihan bersifat kontraktual), dan ketiga
adalah file untuk tagihan itu sendiri. Ketiga file ini akan
didaftarkan ke database SPAN.
Saat menjalankan legacy system bersandingan dengan SPAN,
Proses bisnis di satuan kerja (satker) tidak berubah. Satker
hanya perlu mengirimkan data SPM-nya kepada KPPN (tagihan
yang telah mendapatkan persetujuan PPSPM) sesuai peraturan
yang berlaku. Hal ini juga berlaku untuk “Pengesahan”, baik di
legacy system maupun full SPAN, yaitu mendaftarkan
pengeluaran dan penerimaan satker kepada Bendahara
Umum Negara (BUN) seperti misalnya pada BLU. Proses selain
pengesahan maka akan menggunakan proses seperti gambar
di atas.

Proses unggah Resume Tagihan ini akan melakukan
pengecekan terhadap beberapa hal yang antara lain Pejabat
Pembuat Komitmen (PPK) atau Pejabat Pembuat Surat
Permintaan Pembayaran (PPSPP), Pejabat Pembuat Surat
Perintah Membayar (PPSPM), Data DIPA, Data Supplier
(penerima pembayaran), Data Komitmen (Kontrak-apabila
ada), dan beberapa field lainnya.
1. Rekam Manual
Rekam manual digunakan hanya untuk staff PPK dari satker Bagian
Anggaran 999 (BUN), seperti halnya DJPU dan DJA.
2. Unggah dari Portal
Untuk melakukan hal ini, satker akan melakukan akses ke Portal SPAN
untuk melakukan upload data. Front Office KPPN akan menangkap data
upload tersebut dan memprosesnya lebih lanjut.
Proses kedua adalah melakukan validasi terhadap masing-masing Resume

Tagihan. Proses validasi ini akan mencocokan dan menghitung ketersediaan
dana DIPA serta mencocokan dan menghitung kontrak. Apabila proses validasi
berhasil maka Resume Tagihan akan mendapatkan Nomor Tagihan yang
berupa respon balik dari SPAN terhadap Pendaftaran Resume Tagihan ini.
Untuk legacy system dan pengesahan maka akan dilanjutkan dengan memulai
persetujuan yang akan membawa informasi tagihan ke Midle Office staff
pencairan dana untuk pengecekan tagihan. Untuk BA 999, maka validasi akan
dilakukan oleh Staff PPK dan memulai persetujuan akan dilakukan oleh PPK
untuk mengalirkan data kepada PPSPM. Dalam hal belanja menggunakan
pinjaman dan hibah terutama Luar Negeri (PHLN), maka Front Office KPPN
Khusus Jakarta VI, tidak melakukan validasi, hanya akan melakukan perekaman
data untuk kemudian dicetak cover letter withdrawl application. Validasi akan
dilakukan setelah mendapatkan NOD dari lender.
Proses validasi terhadap tagihan akan menciptakan jurnal dasar Belanja pada
Hutang dan Penerimaan.

3 Pendaftaran Surat Perintah Membayar
Pengguna Aplikasi:
4. Front Office KPPN , Staff Pencairan Dana
5. Front Office KPPN Khusus Jakarta VI
6. PPSPM, untuk BA 999.
Proses Pendaftaran Surat Perintah Membayar:
Telah dijelaskan pada proses pendaftaran Resume Tagihan, bahwa untuk
legacy dan pengesahan, data SPM didaftarkan bersamaan dengan
perekaman Resume Tagihan. Namun untuk tagihan normal akan melalui proses
pendaftaran Surat Perintah Membayar. Pendaftaran Surat Perintah Membayar
dilakukan sebelum tagihan jatuh tempo. Sehingga PPSPM mengirimkan data
SPM harus senantiasa memperhatikan payment term yang telah dibentuk oleh
PPK dalam pendaftaran Resume Tagihan.
Senin Selasa Rabu Kamis Jumat Sabtu Minggu
2 feb 3 feb 4 feb 5 feb 6 feb 7 feb 8 feb
RT SPM SP2D
segera 1 hari 2 hari 3 hari 4 hari
Keterangan
Payment term yang didaftarkan di Resume Tagihan
Pembayaran dilakukan
SPM Diterbitkan dan disampaikan
Resume Tagihan didaftarkan
Ilustrasi penggunaan payment term

Proses Pendaftaran Surat Perintah Membayar (SPM) dilakukan dengan cara:
- Unggah
Proses unggah dilakukan untuk memulai pengujian dan persetujuan di KPPN.
Proses unggah ini akan meng-update data tagihan yang telah didaftarkan
melalui pendaftaran Resume Tagihan terutama di bagian SPM dan
authorisasi SPM. Tagihan tidak akan dapat dibayarkan tanpa data-data
SPM.
- Persetujuan

Persetujuan disini hanya terkait dengan BA 999 dimana sebelumnya (proses
pendaftaran Resume Tagihan) telah dilakukan validasi dan dimulai
persetujuan oleh PPK. Persetujuan ini dilakukan oleh PPSPM. Dengan
dilakukan persetujuan oleh PPSPM, maka data tagihan terkait telah menjadi
SPM dan diteruskan ke KPPN untuk diuji dan dibayarkan.
- Unggah di Portal
Untuk melakukan hal ini, satker akan melakukan akses ke Portal SPAN untuk
melakukan upload data. Front Office KPPN akan menangkap data upload
tersebut dan memprosesnya lebih lanjut.
Setelah melakukan unggah data, maka Front Office staff pencairan dana,
dalam proses normal akan melakukan mulai persetujuan untuk mengirimkan
data ke Midle Office staff pencairan dana. Lain hal-nya dengan legacy dan
pengesahan yang mulai persetujuannya telah dilakukan sebelum tahap ini
yang berarti data sudah terkirim ke Midle Office.
4 Persetujuan Pengujian Surat Perintah Membayar

Pengguna Aplikasi:
7. Midle Office, Staff Pencairan Dana
8. Kepala Seksi Pencairan Dana
Midle Office ataupun Kepala Seksi Pencairan Dana akan melihat
daftar kerja di halaman beranda-nya pada aplikasi. Daftar kerja ini
akan berisikan tentang hal-hal yang harus dilakukan oleh Midle
Office ataupun Kepala Seksi Pencairan Dana.
Proses persetujuan pengujian SPM dilakukan berjenjang dari Midle
Office ke Kepala Seksi Pencairan Dana. Midle Office berfungsi
sebagai pengecekan layer kedua setelah Front Office. Pengecekan
dilakukan semi manual karena beberapa hal memang harus dicek
secara manual seperti uraian di tagihan terhadap akun yang
dipakai, pengecekan lampiran apabila ada, dan sebagainya.
Midle Office akan melakukan tindakan terhadap tagihan yang telah
diperiksanya untuk diteruskan ke Kepala Seksi Pencairan Dana atau

ditolak oleh Midle office apabila tidak memenuhi pengujian untuk
dibayarkan.
Kepala Seksi akan menerima data tagihan yang telah diuji oleh Midle
Office untuk kemudian diperiksa dan disetujui atau ditolak. Apabila
Kepala Seksi menyetujui tagihan maka dapat diterbitkan Surat
Persetujuan Pembayaran Tagihan (SPPT).
Dari mulai diterimanya SPM di KPPN sampai dengan penerbitan SPPT
ini akan dilakukan dalam waktu kurang dari atau sama dengan satu
jam. Setiap satu jam, sistem aplikasi akan memeriksa proses dan
mengirimkan hasilnya kepada satuan kerja melalui email. Status
tagihan yang akan dikirimkan kepada satker adalah:
9. Status penolakan Resume Tagihan (dalam proses
pendaftaran Resume Tagihan)
10. Status Persetujuan Resume Tagihan (dalam proses
pendaftaran Resume Tagihan)
11. Status SPPT
5 Pengelompokan Tagihan Untuk Pembayaran
Pengguna Aplikasi:
12. Staff Seksi Bank Giro Pos
Melalui menu, Staff Seksi Bank Giro Pos akan melakukan permintaan
terhadap database untuk menarik data tagihan yang akan dibayarkan
sesuai dengan kondisi yang diberikan oleh pengguna. Kondisi ini antara
lain tanggal jatuh tempo dan bank operasional.
System akan memberikan daftar tagihan yang diminta, Staff Seksi Bank
Giro Pos memeriksa hasil dari system dan apabila telah sesuai maka akan
dikirimkan ke Kepala Seksi Bank Giro Pos.
6 Pembayaran terhadap Tagihan
Pengguna Aplikasi:
- Kepala Seksi Bank Giro Pos
Kepala Seksi Bank Giro Pos akan mendapatkan notifikasi melalui tabel
tindakan dalam aplikasi terhadap permintaan pembayaran yang
dikirimkan oleh staff-nya. Kepala Seksi Bank Giro Pos memeriksa dan

dapat melakukan pembayaran terhadap permintaan pembayaran
tersebut atau dapat menghentikan pembayaran tersebut.
7 Pengiriman Data Pembayaran ke Perbankan

Pengguna Aplikasi :
13. System
14. Kepala Seksi Bank Giro Pos
System akan terhubung langsung kepada bebera perbankan sehingga
pengiriman data pembayaran dapat dilakukan secara otomatis. Namun
apabila pengiriman data otomatis ini gagal maka Kepala Seksi Bank Giro Pos
dapat melakukan overide system secara manual dengan mengunduh file kirim
untuk dikirimkan secara manual ke bank.
Untuk legacy system dan perbankan yang tidak memiliki hubungan langsung
dengan SPAN akan dikirimkan manual daftar SP2D dan ADK-nya. Daftar SP2D
dan ADK ini dihasilkan oleh sistem atas permintaan Kepala Seksi Bank Giro Pos.
B. MANAJEMEN PENERIMAAN
Salah satu wujud dari kegiatan administrasi keuangan negara
adalah penatausahaan atas penerimaan negara (Government
Receipt). Pengelolaan penerimaan n egara saat in i
bertumpu pada Sistem MPN (Modul Pen erimaan Negara)
yan g di kel ol a oleh Ditjen Pajak. Permasal ah an utama
dari pen gelol aan negara saat in i adal ah integrasi antara
sistem i nformasi yang belu m baik. Hal ini terjadi karen a
ada pen erim aan negara yang diterima ti dak melalui
MPN, seperti penerimaan n egara yang diteri ma melalui
Bank In don esia (contoh : Penerimaan pem biayaan,
Penerimaan P NB P M ig as.
Pengelolaan Penerimaan Negar a dal am SPAN lebih pada
pen gelol aan back offi ce penerimaan negar a, den gan front
offi ce berada di Si stem Informasi MPN, Penerimaan di BI,

serta Pen eri maan Retur. Pol a umum pen gelol aan
penerimaan n egara dal am SPAN dapat digambar kan
sebagai beri kut ini:
8
Interkoneks i SPAN d en gan M PN, MPN-G 2, Ban k Indonesia dan DJP
Hingga saat ini Indonesia belum mempunyai sistem baku yang

terintegrasi dalam pengelolaan Government Receipt.
Secara umum penatausahaan penerimaan negara melalui MPN diharapkan
mampu untuk menciptakan suatu sistem penerimaan negara yang
terintegrasi dalam satu database, di mana sebelumnya penatausahaan
penerimaan negara dilakukan secara terpisah oleh Direktorat Jenderal Pajak,
Direktorat J enderal Bea dan Cukai serta Direktorat J enderal
Perbendaharaan.
2. Proses Bisnis Manajemen Penerimaan

Proses bisnis Manajemen Penerimaan SPAN yang dilakukan oleh KPPN terdiri atas 3
aktivitas utama yakni :
4.4.1 Unggah penerimaan
Penerimaan Negara yang masih dikelola oleh KPPN terdiri atas tiga jenis yakni
Penerimaan dari Bank/Pos Persepsi (MPN), Penerimaan BLU, Penerimaan Retur
SP2D. Proses unggah penerimaan ini dapat dijelaskan sebagai berikut ini :
B. Unggah Penerimaan 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. Bedanya hanya jika
pada saat ini, ADK Bank/Pos Persepsi di unggah kedalam SISPEN, dengan
SPAN, maka ADK tersebut akan diunggah kedalam SPAN.
Proses unggah ADK kedalam SPAN menggunakan form SPGR Data
Penerimaan dari Bank Persepsi. Proses unggah ini dilakukan oleh Staff
Seksi Bank/Giro Pos, sedangkan persetujuan proses unggah
dilakukan oleh Kepala Seksi Bank/Giro Pos.
C. Penerimaan BLU. Penerimaan BLU diunggah setiap triwulan. Prosesnya
menungguh proses unggah ADK SPM pengesahan BLU yang dilakukan di
Modul Pengeluaran SPAN. Jika di dalam ADK SPM Pengesahan BLU
terdapat data Pendapatan BLU maka, akan ada pemberitahuan ke seksi
Bank/Giro Pos untuk melakukan proses unggah pendapatan BLU tersebut.
Seksi Bank/Giro Pos hanya tinggal melakukan pengecekan di form SPGR
Data Penerimaan BLU, per tanggal buku dan Satker BLU apa, jika ada maka
akan muncul di form tersebut. Jika ada, maka Seksi Bank/Giro Pos harus
melakukan proses interface, dan membentuk transaksi penerimaan di SPAN.
D. 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). Jika dari rekenig retur tersebut ada transaksi debit, maka di form SPGR
Data Penerimaan Retur akan ada transaksi yang harus diproses di form SPGR
Data Penerimaan Retur.
Gambar : unggah-peenerimaa-bank

4.4.2 Reviu transaksi penerimaan
Proses selanjutnya setelah proses unggah penerimaan adalah reviu terhadap
transaksi penerimaan. Proses ini tidak harus dilakukan oleh Staff KPPN, akan
tetapi disediakan sebagai sarana proses pengecekan kembali terhadap
transaksi-transaksi penerimaan yang telah dilakukan.
Proses reviu transaksi penerimaan dilakukan dengan membuka form Ikhtisar
Penerimaan kemudian lakukan pencarian berdasarkan parameter tertentu,
semisal berdasarkan tanggal buku, atau berdasarkan nomor penerimaan.
4.4.3 Permintaan laporan
Laporan manajerial yang disediakan dalam SPAN dan dapat diakses oleh
KPPN terdiri atas 5 (lima) jenis Laporan, yakni
a. Laporan Daftar Retur SP2D
b. Laporan Daftar Pembagian Pembagian DBH PBB
c. Laporan Daftar Penerimaan
d. Laporan Realisasi Penerimaan, Pembagian, dan Penyaluran PBB
e. Laporan Daftar Pelimpahan PBB ke BO III
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 di isi oleh
pembuat laporan. Sebagai contoh, Laporan Daftar Retur SP2D memiliki
parameter periode dan Nomor Rekening Retur.
Gambar : permintaan laporan
Pokok-pokok Perubahan (Improvement) Penatausahaan Penerimaan Negara
Beberapa pokok perubahan atau penyempurnaan proses bisnis

penatausahaan penerimaan negara dalam rangka implementasi Sistem
Perbendaharaan dan Anggaran Negara (SPAN) seperti yang terlihat pada
table berikut :
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. Reposisi kewenangan pengelolaan Modul Penerimaan Negara pada penerapan
MPN G2 oleh DJ PB (Dit. PKN), terutama terkait sistem pembayaran (settlement)
setoran penerimaan negara melalui bank/pos persepsi.
4. 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).
5. Penerimaan negara terkait Rekening Pemerintah Lainnya (RPL) sudah dicatat
pada saat uang masuk pada rekening (RPL) yang bersangkutan.
6. Penerimaan pembiayaan terkait Reksus dicatat pada saat dana initial deposit
dan/atau pada saat replenishment masuk pada Reksus yang bersangkutan.
7. 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.
8. Penerimaan terkait pajak dan bea cukai dicatat (diakui) sebagai penerimaan
masing-masing Satker (KPP/KPBC) bersangkutan. Sehingga proses rekonsiliasi
data penerimaan dapat dilakukan di tingkat Satker dan KPPN. Untuk itu setiap
transaksi pada data MPN harus dapat di mapping sebagai penerimaan KPP/KPBC
selaku Satker.
9. Memungkinkan pencatatan dan akuntansi penerimaan negara dilakukan secara
akrual maupun kas sejalan dengan yang diamanatkan dalam undang-undang.
10. Penerimaan dari pengembalian belanja tahun anggaran berjalan dapat

mengembalikan sisa pagu yang didahului dengan surat pengajuan pengembalian
sisa pagu oleh Satker.
11. Sebagian besar pencatatan penerimaan negara dilakukan melalui metode
interface/upload data (ADK) terutama terkait j umlah data transaksi yang relatif
banyak (batch / bulk) temasuk untuk pencatatan penerimaan yang berasal
dari setoran langsung pada Bank Indonesia melalui ADK rekening koran.
12. Pembuatan daftar rincian dana bagi hasil PBB berdasarkan data transaksi
penerimaan dapat dilakukan secara sistem untuk membantu proses
pembayaran/transfer ke daerah oleh KPPN ke BO III.
13. Penyampaian LHP dan rekening koran dari bank persepsi/BI secara elektronik
dan terstandarisasi.

14. Rekonsiliasi secara sistem antara pencatatan penerimaan negara dengan kas
yang diterima pada Modul Cash Management berdasarkan informasi (ADK)
rekening koran dari bank, termasuk proses rekonsiliasi antara ADK rekening
koran dari bank persepsi dengan data penerimaan ADK LHP/DNP). Untuk itu
rekening koran harus diformat dalam bentuk ADK yang terstandarisasi dan setiap
transaksi yang muncul dalam Daftar Nominatif Penerimaan (DNP) harus muncul
pada ADK rekening korannya, sehingga Bank Persepsi harus mengkreditkan
15. Rekening
Tidak adaKas Negara
proses pada setiap
permintaan NTPNtransaksinya.
(e-paypoint) pada MPN selain setoran melalui
bank/pos persepsi (contoh: penerimaan melalui potongan SPM, penerimaan
melalui Bank Indonesia).
16. Tidak ada proses konsolidasi laporan (LKP) ditingkat pusat karena menggunakan
single database dan laporan dapat di-generate pada setiap level
kewenangan yang diberikan.
17. Mendukung pelaksanaan Treasury Single Account (TSA) secara penuh dalam
rangka pengelolaan kas.
18. Dapat dilaksanakan proses audit trail terhadap data transaksi, karena setiap
adanya perubahan/perbaikan hanya dapat dilakukan dengan mekanisme jurnal
reversal/pembalik, sehingga setiap perubahan/perbaikan akan tercatat.
19. Penatausahaan penerimaan negara dengan meminimalisasi penggunaan kertas
(less paper).
4.5 MANAJEMEN KAS

1.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.
9
1.2. Proses Bisnis Manajemen Kas
Skenario dasar pada modul manajemen kas SPAN, antara lain:
3.1. 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.
Berikut adalah kombinasi BAS dalam SPAN:
KLASIFIKASI DALAM
KLASIFIKASI SEMULA DIGIT TUJUAN ATRIBUT PELAPORAN
SPAN
BA, Eselon 1,
Organisasi Satker 6 LK per satker
Konsolidasi Satker
KPPN 3 LK per KPPN
Jenis Kewenangan 1 Jenis Kewenangan
Fungsi
Subfungsi
Program Program 3+2+2 BA+Eselon 1+Program
Kegiatan, Fungsi,
Kegiatan Output 4+3 Kegiatan+Output
Subfungsi, Satuan
Sumber dana+cara No Register utang
Dana 1+1+8
tarik+no register dan hibah
Lokasi 2+2 Tempat kegiatan
Sub Kegiatan
Ekonomi Anggaran 1
Akun 6 Klasifikasi Ekonomi
Jenis rekening+no
Bank 1+4 rekenning bank KPPN
(mapping)
Antar Entitas 6 Due-to dan Due-from
Cadangan 6
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).
3.2. 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.
3.3. 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.
3.4. 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.
3.5. Non-aktifasi rekening (closing existing bank account)
Proses tersebut dilakukan untuk menutup rekening yang sudah tidak aktif,
sehingga tidak dapat digunakan untuk transaksi.
3.6. 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:
1) Laporan Perencanaan Pengeluaran Kas Harian
1 KEMENTERIAN KEUANGAN REPUBLIK INDONESIA 2
DIREKTORAT JENDERAL PERBENDAHARAAN 3
4 < LOCATION DESCRIPTION >

< Address 1 > 5
6 < Address 2 >
7 8
Telephone : <Phone 1> Faximile <Phone2>
LAPORAN PERENCANAAN PENGELUARAN KAS HARIAN 9
PERIODE : MON - YYYYY 10

Tipe Laporan : XXXXXXXX 11
12 14
KPPN : 999 - XXXXXXXXXXXX Bag. Anggaran : 999 - XXXXXXXXXXXX
13 15 16
Satker : 123456 - XXXXXXXXXXXX Eselon1 : 12345 - XXXXXXXXXXXX (ZZZZZZZ)
1 20
2 3 4 … 28 29 30 31 TOTAL
Tipe Transaksi : Kontrak 22
17
520000
530000
Subtotal Kontrak
19
Tipe Transaksi :
18
Resume Tagihan
410000
420000
510000
520000
610000
Subtotal Resume Tagihan

19
Total Rencana Pengeluaran

21
Harian
24 DD-MON-YYYY hh:mm:ss
23 25 Page 1 of Y
Printed by : User Name

2) Laporan Perencanaan Pengeluaran Kas Mingguan

< Address 1 > 5
6
< Address 2 >
7 Telephone : <Phone 1> Faximile <Phone2> 8
LAPORAN PERENCANAAN PENGELUARAN KAS MINGGUAN 9

PERIODE : MON - YYYYY 10

12
KPPN : 999 - XXXXXXXXXXXX Bag. Anggaran : 999 - XXXXXXXXXXXX 14
16
Satker : 123456 - XXXXXXXXXXXX 13 Eselon1 : 12345 - XXXXXXXXXXXX 15 (ZZZZZZZ)
Minggu 1 Minggu 2 Minggu 3 Minggu 4 TOTAL
20
Tipe Transaksi : 22
Kontrak 17
520000
530000
Subtotal Kontrak
19
Tipe Transaksi :
18
Resume Tagihan
410000
510000
520000
550000
610000
Subtotal Resume
19
Tagihan
Total Rencana 21
Pengeluaran Mingguan
Printed by : User Name 23 25 Page 1 of Y
3) Laporan Perencanaan Kas Bulanan


< Address 1 > 5
6
< Address 2 >
LAPORAN PERENCANAAN PENGELUARAN KAS BULANAN 9

TAHUN : YYYY 10
12 14
KPPN : 999 - XXXXXXXXXXXX Bag. Anggaran : 999 - XXXXXXXXXXXX
15 16
Satker : 123456 - XXXXXXXXXXXX 13 Eselon1 : 12345 - XXXXXXXXXXXX (ZZZZZZZ)
JAN FEB MAR APR … SEP OKT NOV DES TOTAL
20
Tipe Transaksi : Kontrak
17 520000 22
530000
Subtotal Kontrak
19
Tipe Transaksi :
18
Resume Tagihan
410000
510000
520000
550000
610000
Subtotal Resume Tagihan
19
Total Rencana Kas Bulanan

21
Printed by : User Name 23
25 Page 1 of Y
4) Laporan Perencanaan Kas Bulanan BUN berdasarkan AFP


< Address 1 > 5
6 < Address 2 >
LAPORAN PERENCANAAN KAS BULANAN BUN BERDASARKAN AFP 9

TAHUN : YYYY 10
14
KPPN : 999 - XXXXXXXXXXXX 12 Bag. Anggaran
: 999 - XXXXXXXXXXXX
16
Januari Februari Maret April Mei Juni Juli Agustus September Oktober November Desember TOTAL
20
AFP PENERIMAAN 22
17
410000
420000
430000
440000
710000
TOTAL AFP
19
PENERIMAAN
AFP PENGELUARAN
18 510000
520000
530000
550000
610000
TOTAL AFP 19
PENGELUARAN
SELISIH 21
PERENCANAAN KAS
24
DD-MON-YYYY hh:mm:ss
Printed b y : User Name 23 25 Page 1 of Y
5) Laporan Monitoring Ketersediaan Pagu DIPA

2
KEMENTERIAN KEUANGAN REPUBLIK INDONESIA
1
< Address 1 > 5
6 < Address 2 >
LAPORAN MONITORING KETERSEDIAAN PAGU DIPA 9

TAHUN : YYYY 10
14
KPPN : 999 - XXXXXXXXXXXX 12 Bag. Anggaran
16
22
Tipe Transaksi : 24
AFP 17
510000
530000
610000
SUB TOTAL 21
AFP PENGELUARAN
Tipe Transaksi :
Kontrak 18
520000
530000
21
SUB TOTAL KONTRAK
Tipe Transaksi :
19
Resume Tagihan
510000
610000
SUB TOTAL 21
RESUME TAGIHAN
Tipe Transaksi :
SP2D 20
510000
610000
SUB TOTAL
21
SP2D
Dana yang Tersedia:

23 510000
530000
610000
*) Informasi perencanaan kas pada bulan tertentu harus ditambahkan nilai kontrak pada periode-periode sebelumnya
25
*) Rencanan Pengeluaran Kas yang bersifat non kontraktual akan muncul pada Tipe Transaksi Resume Tagihan setelah diinput kedalam sistem
27
DD-MON-YYYY hh:mm :ss
28
Printed by : User Nam26
e Page 1 of Y
6) Laporan Perencanaan Pendapatan Bulanan

2
1 KEMENTERIAN KEUANGAN REPUBLIK INDONESIA
< LOCATION
4 DESCRIPTION >
< Address
5 1>
< Address 2 > 6
7
Telephone : <Phone 1> Faximile <Phone2> 8
LAPORAN PERENCANAAN PENERIMAAN BULANAN 9

TAHUN : YYYY 10
12 14
KPPN : 999 - XXXXXXXXXXXX Bag. Anggaran
16
13 15
Satker : 123456 - XXXXXXXXXXXX Eselon1 : 12345 - XXXXXXXXXXXX (ZZZZZZZ)
Tipe Transaksi : 22
17 24
AFP PENERIMAAN
410000 1500
420000
710000
SUBTOTAL
21
AFP PENERIMAAN
Tipe Transaksi : Penerimaan

(Non Potongan Resume
Tagihan / SP2D) 18
410000 900
430000
21
SUBTOTAL PENERIMAAN
Tipe Transaksi :
Potongan dari Resume
Tagihan 19
410000 800
SUB TOTAL
21
Tipe Transaksi :
20
Potongan dari SP2D
410000
SUB TOTAL
21
SELISIH:
23
AFP PENERIMAAN dengan
Realisasi
410000
420000
710000
*) Potongan dari Resume Tagihan merupakan potongan SPM yang belum dibayarkan
25
*) Potongan dari SP2D merupakan Realisasi potongan SPM
27
DD-MON-YYYY hh:mm:ss
26 28
Printed by : User Name Page 1 of Y
Salah satu konsep usulan 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 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.

4.6 MANAJEMEN PELAPORAN
i. 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 akan terposting ke dalam GL yang terintegrasi. Terdapat 2 GL di
dalam SPAN, yaitu; GL akrual dan GL cash untuk mengakomodir penerapan
penganggaran berbasis kas dan penerapan akuntansi full akrual.10
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.

Sumber : Direktorat Transformasi Perbendaharaan
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. Gambaran umum SPAN secara garis besar
digambarkan pada berikut:
Gambaran Umum SPAN
Sumber : Direktorat Transformasi Perbendaharaan

Pengembangan proses bisnis akuntansi (GL dan COA) sebagai bagian dari
program SPAN dimaksudkan untuk mencapai tujuan reformasi pengelolaan
keuangan negara secara menyeluruh.
b. Proses Bisnis dan Gambaran Umum Sistem Akuntansi Pemerintah
Menggunakan SPAN
Gambaran secara umum struktur sistem akuntansi ke depan

masih sesuai dengan SAPP. Yang membedakan adalah pada SPAN
akan menggunakan dua GL; GL akrual dan GL kas. Ledger akrual
sama dengan praktik SAU dan ledger kas sesuai dengan SAKUN.
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).
Modul di dalam SPAN terdiri dari 7 modul utama yang

mengakomodir seluruh transaksi sistem akuntansi. Modul-modul
tersebut adalah : Budget Preparation (BP), Management of Spending
Authority (MoSA), Business Commitment (BC), Cash Management
(CM), Payment (PM), Government Receipt (GR), dan General
Ledger, Chart of Account and Reporting. Sedangkan sistem
akuntansi di satker akan menggunakan SAKTI (Sitem Akuntansi Tingkat
Instansi).
Kebijakan Akuntansi
Basis akuntansi yang digunakan dalam laporan keuangan pemerintah

adalah basis akrual, untuk pengakuan pendapatan, beban, aset, kewajiban,
dan ekuitas dana. Dalam hal peraturan perundangan mewajibkan disajikannya
laporan keuangan dengan basis kas, maka entitas wajib menyajikan laporan
demikian.
1. Basis Akrual

Pengakuan dan pengukuran berdasarkan basis akrual meliputi
pencatatan pendapatan, beban, aset, kewajiban dan ekuitas yang akan
disajikan dalam laporan keuangan pemerintah. Namun setiap entitas akuntansi
dalam penerapan SAP berbasis akrual penuh akan menggunakan 2 basis
dalam pelaksanaannya karena hal ini terkait dengan kebutuhan penyajian
laporan keuangan.
2. Basis Kas Menuju Akrual
Untuk pencatatan berdasarkan basis kas menuju akrual maka pencatatan
transaksi pendapatan, belanja, transfer dan pembiayaan diakui dan diukur
secara kas. Kemudian untuk pencatatan aset, kewajiban, dan ekuitas
berdasarkan basis akrual. Sedangkan untuk entitas yang selama masa transisi
masih menggunakan basis CTA maka dalam akan menggunakan Standar yang
ada selama ini dan telah diadopsi dalam PP 71 tahun 2010.
Dengan menerapkan penganggaran berbasis kas, memang
tetap harus dilakukan pencatatan akuntansi dengan basis kas pada
transaksi penerimaan dan belanja negara. Basis kas baru benar-
benar mengakui pendapatan sebagai benar-benar pendapatan
ketika terjadi aliran kas masuk ke kas negara, dan mengakui belanja
benar-benar sebagai belanja ketika terjadi aliran kas keluar dari kas
negara. Sehingga dasar pengakuan basis kas tidak memperhatikan
hak dan kewajiban yang terjadi atas suatu transaksi, namun
berdasarkan realitas aliran kas yang terjadi di dalam suatu transaksi.
Pada transaksi akrual, peristiwa pengajuan Surat Perintah
Membayar belanja oleh satker mewujudkan kewajiban/liability
terhadap Negara untuk melunasi kewajiban tersebut dengan
menerbitkan Surat Perintah Pencairan Dana (SP2D). Dengan basis
akrual, akuntansi pada general ledger akrual terjadi pengakuan
terjadinya beban dan kewajiban terhadap utang tersebut. Transaksi
payment/pembayaran akan berpengaruh baik kepada general
ledger akrual maupun general ledger kas.
Dengan pelaksanaan akrual penuh dapat disajikan berapakah
pendapatan dan berapakah belanja negara yang sesungguhnya

yang mempengaruhi kekayaan bersih pada saat pelaporan tersebut.
Selain itu, akuntansi berbasis akrual dapat menghasilkan informasi
keuangan yang komprehensif, misalkan berkaitan dengan
penghapusan hutang yang tidak ada pengaruhnya pada laporan
yang dihasilkan dari basis kas. Dengan basis kas, tidak dapat
mencerminkan kemungkinan belanja dan pendapatan di masa
mendatang, sehingga informasi yang dihasilkan hanya berdasarkan
kas yang masuk dan yang keluar pada saat tersebut.
Bagan Akun Standar
Di dalam SPAN, fungsi Bagan Akun Standar adalah

menghubungkan beberapa modul-modul transaksi dengan akun-
akun melalui terbentuk nya jurnal-jurnal transaksi ketika terjadi
transaksi pada tiap-tiap modul. SPAN akan mengadopsi satu Bagan
Akun Standar (BAS) untuk Ledger akrual dan Ledger kas.
Pada struktur BAS yang diakomodir SPAN, akan disesuaikan dengan

fitur General Ledger di Oracle. 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 (descriptive flexfield) 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
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
Teknik Akuntansi
Pencatatan menggunakan basis akrual, pencatatan

pendapatan dan beban dicatat saat terjadinya transaksi. Hal ini
berdampak dengan adanya akun baru kelompok Liability (kelompok
Belanja-Belanja yang masih harus dibayar dan kelompok
Pengeluaran-Pengeluaran yang masih harus dibayar), Beban
Penyusutan, Pendapatan-Pendapatan Yang Ditangguhkan, Beban
Dibayar Dimuka, Piutang Yang Akan Diterima, Piutang Perhitungan
Fihak Ketiga (PFK), dan akun-akun komitmen.
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.
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.
Oleh karena kebijakan penganggaran menggunakan basis kas dan

transaksi menggunakan basis akrual, pada saat terjadi transaksi dan
pencatatan, penjurnalan di dalam SPAN mengakomodir pencatatan
pada dua ledger, yaitu; ledger akrual dan ledger kas.
Pelaporan
Pelaporan (Reporting) merupakan salah satu
proses bisnis dalam rangka pertanggungjawaban pelaksanaan
kegiatan dan pengelolaan keuangan oleh entitas akuntansi dan
pelaporan. Penyempurnaan proses bisnis Pelaporan pada dasarnya
dilakukan dalam rangka mewujudkan terciptanya transparansi,

efektivitas dan akuntabilitas dalam pelaporan keuangan
pemerintah.
Business Process Improvement 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.
Pengembangan lainnya dalam Modul Pelaporan adalah
penyempurnaan 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 .
Penerapan Integrated Database (Single Database)

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, 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.
Proses Bisnis Pelaporan di KPPN – Seksi Verifikasi dan Akuntansi

Pengembangan proses bisnis Pelaporan di tingkat KPPN
akan banyak terkait dengan seksi Verifikasi dan Akuntansi (Vera) di
KPPN. Ada beberapa sub aktivitas utama dalam proses pelaporan
di tingkat KPPN khususnya Seksi Vera yaitu Prosedur Rekonsiliasi,
prosedur pembuatan Berita Acara Rekonsiliasi (BAR), prosedur
pemberian sanksi yang Belum Rekonsiliasi, dan Prosedur
Penyusunan LKPP tingkat KPPN.
11
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.
Sistem Pendukung pada Kementerian Lembaga ()23BAB III
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.4
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
Terkait dengan aplikasi SPAN sendiri, yang digunakan adalah aplikasi

dengan menggunakan platform Enterprise resource planning (ERP) dan
Pengenalan Tingkat Dasar Proses Bisnis SPAN i
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)
iii. Modul Manajemen Pembayaran (Payment Management)
Pengenalan Tingkat Dasar Proses Bisnis SPAN ii
iv. Modul Penerimaan Negara (Government Receipt )
v. Modul Manajemen Kas (Cash Management)
c. Akuntansi dan Pelaporan, terdiri atas :
Modul Buku Besar dan Bagan Akun Standar (General
Ledger and Chart of Accounts)
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.
Pengguna aplikasi SPAN, terdiri dari:
1. Lingkup Direktorat Jenderal Perbendaharaan (Kantor Pusat,
Kanwil DJPBn dan KPPN)
2. BA 999
Pengenalan Tingkat Dasar Proses Bisnis SPAN iii

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:
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 Pemb. Perbendaharaan 1
Kabid Pemb. Perbendaharaan 2
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 Verak
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
5Tabel 2
Pengenalan Tingkat Dasar Proses Bisnis SPAN iv

Pemisahan Kewenangan Pada KPPN
Bagan 3
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
BAB IV
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
Pengenalan Tingkat Dasar Proses Bisnis SPAN v

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.
Pengenalan Tingkat Dasar Proses Bisnis SPAN vi

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.
Sudarto, Setiawan Adi, 2010, Modul Manajemen Komitmen, Direktorat
Sudarto, Hemidon, 2010, Modul Manajemen Penerimaan, Direktorat
Sudarto, Hutabarat Dodi, 2010, Modul Manajemen Kas, Direktorat Transformasi
Perbendaharaan.
Tim Penyusun Modul SPAN, 2012, Modul SPAN Manajerial, Direktorat
Pengenalan Tingkat Dasar Proses Bisnis SPAN vii

Modul SPAN PDF

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modul SPAN PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

DAFTAR ISI

Daftar Isi …………………………………………………………………............... i

Pengenalan Tingkat Dasar Proses Bisnis SPAN 1

Pemerintah melalui Instruksi Presiden Republik Indonesia No. 3 Tahun 2003

Pengenalan Tingkat Dasar Proses Bisnis SPAN 2

Pengenalan Tingkat Dasar Proses Bisnis SPAN 3

Pengenalan Tingkat Dasar Proses Bisnis SPAN 4

i. Visi dan Misi SPAN

Pengenalan Tingkat Dasar Proses Bisnis SPAN 5

ii. Keunggulan SPAN.

Pengenalan Tingkat Dasar Proses Bisnis SPAN 6

i. Modul Manajemen DIPA (Management of Spending Authority)

iii. Pilar SPAN

Pengenalan Tingkat Dasar Proses Bisnis SPAN 7

Pengenalan Tingkat Dasar Proses Bisnis SPAN 8

Ruang Lingkup SAKTI

Pengenalan Tingkat Dasar Proses Bisnis SPAN 9

Pengenalan Tingkat Dasar Proses Bisnis SPAN 10

1. Pengertian dan Konsep Dasar

2. Proses Bisnis Manajemen DIPA

Proses bisnis manajemen DIPA Future terdiri dari 3 aktivitas utama

Pengenalan Tingkat Dasar Proses Bisnis SPAN 12

1. Pengesahan DIPA biasa

Gambar 1. Umum Proses Pengesahan DIPA

Pengenalan Tingkat Dasar Proses Bisnis SPAN 13

1. Revisi DIPA tanpa perubahan RABPP

Gambar 2. Umum Flowchart Revisi DIPA

Pengenalan Tingkat Dasar Proses Bisnis SPAN 14

atau serangkaian pembayaran dalam jangka waktu tertentu. Termasuk

Pengenalan Tingkat Dasar Proses Bisnis SPAN 15

c. Continuing commitment: komitmen yang pembayarannya bersifat

Pengenalan Tingkat Dasar Proses Bisnis SPAN 16

Kerangka pelaksanaan manajemen komitmen adalah sebagai berikut :

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

Catatan: (*) Penyampaian dokumen Resume Kontrak adalah dalam

Pengenalan Tingkat Dasar Proses Bisnis SPAN 17

Pagu Cadangan Realisasi Sisa Pagu

Pengenalan Tingkat Dasar Proses Bisnis SPAN 18

Penerapan manajemen komitmen dapat memberikan manfaat dan nilai

Pengenalan Tingkat Dasar Proses Bisnis SPAN 19

Untuk mendukung Manajemen Komitmen, manajemen supplier menjadi

Pengenalan Tingkat Dasar Proses Bisnis SPAN 20

Pengenalan Tingkat Dasar Proses Bisnis SPAN 21

Cakupan Proses Manajemen Pembayaran:

Pengenalan Tingkat Dasar Proses Bisnis SPAN 22

Gambar Proses Bisnis Manajemen Pembayaran SPAN System

2 Pendaftaran Resume Tagihan

Pengenalan Tingkat Dasar Proses Bisnis SPAN 23

Pengenalan Tingkat Dasar Proses Bisnis SPAN 24

Proses kedua adalah melakukan validasi terhadap masing-masing Resume

Pengenalan Tingkat Dasar Proses Bisnis SPAN 25

Ilustrasi penggunaan payment term

Pengenalan Tingkat Dasar Proses Bisnis SPAN 26

4 Persetujuan Pengujian Surat Perintah Membayar

Pengenalan Tingkat Dasar Proses Bisnis SPAN 27

Pengenalan Tingkat Dasar Proses Bisnis SPAN 28

7 Pengiriman Data Pembayaran ke Perbankan

Pengenalan Tingkat Dasar Proses Bisnis SPAN 29

Interkoneks i SPAN d en gan M PN, MPN-G 2, Ban k Indonesia dan DJP

Hingga saat ini Indonesia belum mempunyai sistem baku yang

2. Proses Bisnis Manajemen Penerimaan

Pengenalan Tingkat Dasar Proses Bisnis SPAN 31

Resume Kontrak () SPP / SPM SP2D()