FAQ

MODUL MANAJEMEN PEMBAYARAN

A. Unggah ADK Resume Tagihan (PMRT)

1. Apa yang dilakukan jika muncul penolakan tagihan dengan alasan "Tidak
ditemukan Data Jadwal Pembayaran"?
Identifikasi alternatif-alternatif penyebab:
Validasi SPAN saat proses unggah menemukan ketidaklengkapan elemen data
dalam ADK resume tagihan (PMRT). Kondisi tersebut disebabkan karena Satker
belum mempergunakan Aplikasi SPM versi terbaru.
Solusi:
Pastikan bahwa ADK SPM yang disampaikan oleh Satker merupakan output dari
aplikasi SPM versi terbaru (14.1.2) dengan menggunakan pengecekan versi SPM
pada aplikasi konversi.
Pada update aplikasi SPM juga terdapat update referensi, pastikan satker
melakukan update referensi. Update referensi ini menambahkan beberapa tabel dan
kolom pada database SPM. Apabila update referensi tidak dilakukan maka aplikasi
konversi tidak dapat menemukan kolom yang dibutuhkan untuk membentuk PMRT.

2. Apa yang dilakukan jika terjadi penolakan saat unggah SPM Koreksi dengan alasan:
"Segment 11 (intraco) belum terdaftar, CVR015: Akun 8111x--8119x dan 8211x--
8219x segmen Intraco tidak boleh nol kecuali PFK non gaji on Segment 11, CVR015:
Akun 8211x--8219x segmen Intraco tidak boleh nol kecuali PFK non gaji on
Segment 11".
Identifikasi:
CVR (Cross Validation Rules) merupakan mekanisme pengujian yang diterapkan
pada modul General Ledger SPAN. Adapun maksud dari penggunaan CVR salah
satunya adalah untuk minimalisasi kesalahan penggunaan akun-akun tertentu
pada saat proses pengajuan tagihan. Terkait perhitungan pihak ketiga (PFK) gaji,
pada CVR diatur bahwa segmen intraco (segmen 11 BAS) harus terisi kode Satker
BUN KPPN Jakarta II (999062) selaku mitra kerja Satker PFK (Dit. Pengelolaan Kas
Negara/440780).
Dengan kondisi bahwa belum keseluruhan 12 segmen Bagan Akun Standar belum
menjadi referensi pada aplikasi SPM, maka untuk kebutuhan pelaporan dalam
SPAN, pengisian segmen intraco dilakukan secara sistem oleh aplikasi konversi
KPPN pada saat proses konversi ADK SPM.
Solusi:
Update terakhir pada aplikasi konversi telah mengakomodasi perbaikan atas
pengisian segmen intraco tersebut.
3. Apa yang dilakukan jika tidak berhasil memvalidasi kembali tagihan yang
sebelumnya dibatalkan dan diupload kembali dengan nomor SPM yang berbeda,
dengan hasil tetap sama yaitu dengan status: perlu divalidasi ulang.

Modul Manajemen Pembayaran Page 1

 Identifikasi alternatif-alternatif penyebab:
perlu validasi ulang merupakan status tagihan yang menjelaskan bahwa tagihan
dimaksud gagal diunggah ke tabel utama SPAN. Status perlu validasi ulang pada
umumnya disertai dengan status HOLD oleh sistem. Terdapat beberapa penyebab
kondisi tersebut:
a. Sisa pagu dana dalam DIPA tidak mencukupi;
b. Nilai tagihan (SPM) lebih besar pada sisa termin kontrak.
Terdapat 2 cara untuk mengidentifikasi alasan yang menjadi penyebab kondisi
tersebut:
a. Lakukan pengecekan status tagihan menggunakan fungsi inquiry invoice, dan
melihat alasan pada tab 3 (TAHAN);
b. Jalankan Daftar Penolakan Substantif dan lihat alasan penolakannya pada
daftar tersebut.
Solusi:
Lakukan pengecekan ketersediaaan dana DIPA menggunakan fungsi inquiry fund dan
pastikan bahwa sisa dana dalam DIPA untuk kegiatan dengan segmen BAS tersebut
mencukupi.
Note:
Apabila terdapat alasan selain pagut dana DIPA atau Kontrak, maka laporkan hal ini
segera untuk ditindaklanjuti.

B. Pemilihan Nomor Register Supplier (NRS)

1. Apa yang dilakukan jika pada saat memproses tagihan tidak muncul kode supplier
pilihan site type 3 padahal telah didaftarkan?
2. Apa yang dilakukan jika pada saat memproses tagihan gaji induk tidak muncul
kode supplier pilihan site type 3 padahal telah ada NRS?
Identifikasi alternatif-alternatif penyebab:
a. Proses pendaftaran supplier belum selesai sepenuhnya saat pemilihan NRS
dilakukan.
b. User salah dalam melakukan pemilihan tipe supplier yang tampil dalam list ov
value (LoV) NRS berkenaan;
c. Terdapat perbedaan data antara penerima pembayaran pada SPM dengan
database supplier SPAN.
Solusi:
a. Pastikan bahwa proses pendaftaran supplier telah selesai sepenuhnya dengan
mencetak dan meneliti data-data supplier berkenaan pada Laporan Informasi
Supplier.
b. Pastikan bahwa tipe supplier yang dipilih pada LoV telah sesuai dengan tipe
supplier sebagaimana dimaksud pada SPM. Laporan informasi Supplier yang
dilampirkan dalam proses pengajuan SPM ke KPPPN dapat dipergunakan

Modul Manajemen Pembayaran Page 2

 sebagai acuan.
c. Lakukan komparasi data secara manual antara data supplier pada ADK
Resume tagihan (PMRT) dengan Laporan Informasi Supplier atau gunakan
Aplikasi Supplier Data Rekonsiliator untuk mengidentifikasi perbedaan data
yang terjadi.

C. Pemilihan Kelompok Bayar (paygroup)

1. Apa yang dilakukan jika terdapat SP2D yang belum terbayar disebabkan kesalahan
pada pemilihan kelompok bayar di FO validasi?
Solusi:
Lakukan perubahan paygroup dengan menggunakan user staf bank dengan syarat
SP2D belum diterbitkan. Selanjutnya, KPPN menginformasikan perubahan
dimaksud kepada Direktorat PKN secara manual.
Implikasi:
Dasar penyediaan dana oleh Direktorat Pengelolaan Kas Negara adalah persetujuan
oleh Kepala Seksi Pencairan Dana. Dengan perubahan paygroup oleh Staf bank
(yang dilakukan setelah persetujuan oleh Kepala Seksi Pencairan Dana)
mengakibatkan penyediaan dana oleh Direktorat Pengelolaan Kas Negara menjadi
tidak akurat karena:
a. Dana yang sudah di dropping ke paygroup semula tidak terutilisasi
b. Diperlukan dropping tambahan dana ke paygroup baru.

D. Pemilihan Nomor Register Kontrak (NRK)

1. Apa yang dilakukan jika CAN tidak muncul pada saat memproses tagihan
kontraktual?
Identifikasi alternatif-alternatif penyebab:
a. Jenis SPM bukan LS Kontraktual (81/Tagihan specific Commitment).
b. Supplier/kontrak belum didaftarkan atau sudah didaftakan namun proses
pendaftaran tersebut belum selesai sepenuhnya saat pemilihan CAN
dilakukan.
c. User salah saat melakukan pemilihan NRS.
d. Segment BAS pada tagihan berbeda dengan kontrak yang sudah didaftarkan.
e. termin kontrak belum terbayar sepenuhnya.
Solusi
a. Pastikan bahwa jenis SPM adalah LS Kontraktual (81/Tagihan specific
Commitment).
b. Proses pendaftaran supplier dan kontrak telah sepenuhnya selesai dengan
mencetak Laporan Informasi Supplier dan Laporan Karwas Kontrak.
c. Pastikan bahwa NRS yang dipilih telah sesuai dengan supplier yang dimaksud

Modul Manajemen Pembayaran Page 3

 pada kontrak. Laporan Informasi Supplier dan Laporan Karwas Kontrak dapat
dijadikan acuan.
d. Pastikan bahwa segment BAS pada tagihan sama dengan kontrak pada
Laporan karwas Kontrak.
e. Keseluruhan termin kontrak belum terbayar. Laporan Karwas Kontrak dapat
dijadikan acuan.
2. Bagaimanakah cara melakukan koreksi atas kesalahan pemilihan data kontrak
pada saat melakukan proses tagihan?
Solusi:
a. Jika pemrosesan tagihan oleh Petugas Validator belum sampai pada proses
unggah ke table utama maka:
1) Lakukan penolakan dan/atau pembatalan tagihan; dan
2) Lakukan konversi dan upload ulang ADK Resume Tagihan (PMRT).
b. Jika pemrosesan tagihan sudah sampai Petugas Review/Kepala Seksi
Pencairan Dana maka:
1) Lakukan pembatalan tagihan; dan
2) Minta kepada satker untuk menyampaikan SPM dan ADK SPM dengan
nomor baru.
Catatan:
Tidak ada mekanisme untuk memperbaiki kesalahan pemilihan NRK apabila SPM
telah diterbitkan SP2D-nya.

E. Error saat SIMPAN

1. Apa yang dilakukan jika pada saat memproses tagihan muncul penolakan "Error
terjadi saat pengecekan nomor DIPA: 05-Des-2013/DIPA-023.04.2.576778/2014,
DIPA tidak ditemukan.
Identifikasi alternatif-alternatif penyebab:
a. User log in ke SPAN bukan menggunakan Bahasa Indonesia
b. Terdapat perbedaan nomor DIPA pada ADK Resume Tagihan (PMRT) dengan
database SPAN
Solusi:
a. Pastikan bahwa log in ke SPAN menggunakan SPAN. Trik termudah adalah
dengan melihat bahasa yang digunakan pada pojok kiri atas adalah KELUAR
bukan LOG OUT.
b. Pastikan bahwa nomor DIPA pada ADK Resume Tagihan sama dengan
database SPAN dengan mengacu pada nomor DIPA pada Karwas DIPA SPAN.

2. Apa yang dilakukan jika pada saat proses upload tagihan muncul penolakan dengan
alasan tidak ada informasi rekening bank untuk tipe supplier . ?

Modul Manajemen Pembayaran Page 4

 Identifikasi alternatif-alternatif penyebab:
a. Proses pendaftaran supplier belum selesai sepenuhnya saat pemilihan NRS
dilakukan.
b. User salah dalam melakukan pemilihan tipe supplier yang tampil dalam list of
value (LoV) NRS berkenaan;
c. Terdapat perbedaan data antara penerima pembayaran pada SPM dengan
database supplier SPAN.
Solusi:
a. Pastikan bahwa proses pendaftaran supplier telah selesai sepenuhnya dengan
mencetak dan meneliti data-data supplier berkenaan pada Laporan Informasi
Supplier.
b. Pastikan bahwa tipe supplier yang dipilih pada LoV telah sesuai dengan tipe
supplier sebagaimana dimaksud pada SPM. Laporan informasi Supplier yang
dilampirkan dalam proses pengajuan SPM ke KPPPN dapat dipergunakan
sebagai acuan.
c. Lakukan komparasi data secara manual antara data supplier pada ADK
Resume tagihan (PMRT) dengan Laporan Informasi Supplier atau gunakan
Aplikasi Supplier Data Rekonsiliator untuk mengidentifikasi perbedaan data
yang terjadi.
3. Apa yang dilakukan jika referensi nomenklatur satker berbeda dengan database
SPAN?
Solusi:
a. Dalam hal berdasarkan penelitian, kesalahan nomenklatur terjadi pada SPAN
maka Satker dapat meminta perbaikan nomenklatur dengan mengajukan surat
permintaan perubahan nomenklatur ke Direktorat Transformasi
Perbendaharaan dengan tembusan Kanwil Ditjen Perbendaharaan setempat.
b. Dalam hal berdasarkan penelitian, kesalahan nomenklatur terjadi pada
aplikasi SPM maka Satker dapat melakukan penyesuaian referensi pada
aplikasi SPM dengan mengacu pada database SPAN.
c. Dalam hal kesalahan nomenklatur berada pada aplikasi konversi, maka
supervisor dapat melakukan update referensi nama satker di database SP2D
yang menjadi rujukan bagi aplikasi konversi.

F. Error saat PROSES UNGGAH

1. Apa yang dilakukan jika tagihan gaji berstatus hold padahal pada umumnya itu
terjadi jika hanya pada tagihan non gaji yang DIPAnya diblokir?
Identifikasi alternatif-alternatif penyebab:
Meskipun untuk belanja gaji, kontrol anggaran (budget control) bersifat advisory
namun jika dalam tagihan tersebut segmen program, kegiatan, output (segmen
lainnya dalam BAS) tidak sama dengan DIPA maka tagihan tetap akan tertolak.
Solusi

Modul Manajemen Pembayaran Page 5

 Pastikan bahwa segment BAS pada tagihan sama dengan database SPAN melalui
inquiry fund dan/atau cetak Karwas DIPA.

2. Apa yang dilakukan jika tagihan masih dalam status tabel utama, bukan
persetujuan awal padahal proses upload tagihan telah selesai dilakukan oleh FO
Validator Tagihan?
Identifikasi alternatif-alternatif penyebab:
Terdapat dua indikator untuk mengetahui bahwa Proses unggah selesai yakni:
a. Seluruh concurrent program telah selesai seluruhnya dengan status normal
(bukan peringatan atau error); dan
b. Status tagihan adalah divalidasi dan status persetujuan adalah dimulai.
Dalam kondisi status adalah tabel utama maka proses unggah belum
sepenuhnya selesai.
Solusi:
a. Dengan menggunakan menu inquiry invoice pastikan bahwa status tagihan
adalah divalidasi dan status persetujuan adalah dimulai.
b. Dalam hal seluruh concurrent program telah selesai seluruhnya namun status
tagihan bukan divalidasi dan status persetujuan bukan dimulai lakukan validasi
dan persetujuan secara manual.
Note:
Perlakuan di atas berbeda dengan HOLD/Tahan. (lihat referensi Hold/Tahan)

3. Bagaimana tindak lanjut penyelesaian SPM yang statusnya HOLD/Tahan?

Identifikasi alternatif-alternatif penyebab:
a. SPM Kontraktual terjadi apabila tagihan yang diajukan satker lebih besar dari
termin kontrak yang telah didaftarkan di SPAN.
b. SPM Non Kontraktual terjadi apabila:
1) Segmen BAS pada tagihan tidak sama dengan database SPAN sehingga
alokasi dana tidak tersedia; atau
2) Nilai tagihan yang diajukan satker lebih besar dari fund available (FA) untuk
Segmen BAS pada SPM berkenaan.

Solusi:
Terdapat 2 cara untuk mengidentifikasi alasan yang menjadi penyebab kondisi
tersebut:
a. Lakukan pengecekan status tagihan menggunakan fungsi inquiry invoice, dan
melihat alasan pada tab 3 (TAHAN);
b. Jalankan Daftar Penolakan Substantif dan lihat alasan penolakannya pada

Modul Manajemen Pembayaran Page 6

 daftar tersebut.
Dalam hal berdasarkan hasil identifikasi, tagihan adalah:
a. SPM kontraktual:
1) Pastikan nilai tagihan tidak melebihi nilai/sisa termin dengan mengacu pada
Laporan Karwas Kontrak;
2) Dalam hal nilai tagihan melebihi karwas kontrak dan status pemrosesan
tagihan oleh Petugas Validator belum sampai pada proses unggah ke table
utama maka:
a) Lakukan penolakan dan/atau pembatalan tagihan; dan
b) Lakukan konversi dan upload ulang ADK Resume Tagihan (PMRT).
3) Dalam hal nilai tagihan melebihi karwas kontrak dan status pemrosesan
tagihan sudah sampai Petugas Review/Kepala Seksi Pencairan Dana maka:
a) Lakukan pembatalan tagihan; dan
b) Minta kepada satker untuk menyampaikan SPM dan ADK SPM dengan
nomor baru.
b. Untuk SPM Non Kontraktual:
1) Pastikan alokasi dana untuk segmen BAS pada tagihan tersedia/cukup
tersedia menggunakan inquiry fund.
2) Dalam hal nilai tagihan untuk segmen BAS tidak tersedia/tidak cukup
tersedia lakukan pembatalan tagihan.

G. Review dan Persetujuan Pertama oleh Petugas Review Seksi Pencairan Dana
Apa yang dilakukan apabila notifikasi Resume Tagihan tidak muncul pada worklist
MO-PD (Petugas Review)?
Identifikasi alternatif-alternatif penyebab:
Proses Unggah tagihan pada Petugas Validator belum selesai sepenuhnya sehingga
belum muncul pada worklist petugas review.
Solusi:
a. Dengan menggunakan menu inquiry invoice pastikan bahwa status tagihan
adalah divalidasi dan status persetujuan adalah dimulai.
b. Dalam hal seluruh concurrent program telah selesai seluruhnya namun status
tagihan bukan divalidasi dan status persetujuan bukan dimulai lakukan validasi
dan persetujuan secara manual.
c. Dalam hal status tagihan adalah HOLD lakukan langkah-langkah seperti pada
huruf F angka 2.

H. Review dan Persetujuan akhir oleh Kepala Seksi Pencairan Dana

1. Apa yang dilakukan jika tanggal dibayarkan lebih awal dari tanggal SPPT?

Modul Manajemen Pembayaran Page 7

 Identifikasi alternatif-alternatif penyebab:
Pada SPPT,:
a. tanggal dibayarkan adalah tanggal jatuh tempo tagihan yang dihitung dari
tanggal upload PMRT ditambah tipe jatuh tempo tagihan. Selain gaji induk, tipe
jatuh tempo adalah segera.
b. tanggal SPPT adalah tanggal Kepala Seksi PD melakukan persetujuan.
Kondisi tanggal dibayarkan lebih awal dari tanggal SPPT dimungkinkan dengan
skenario sebagai berikut:
ADK Resume Tagihan diupload ke SPAN oleh Petugas Validator pada tanggal 2
Maret 2014 namun persetujuan oleh Kepala Seksi Pencairan Dana baru diberikan
pada tanggal 3 Maret 2014.
Implikasi dari kondisi tersebut informasi kebutuhan dana atas tagihan tersebut
tidak dapat terlihat pada laporan monitoring kebutuhan dana yang ada di
Direktorat Pengelolaan Kas Negara karena selain tanggal persetujuan oleh Kepala
Seksi pencairan Dana, dasar penyediaan kebutuhan dana adalah tanggal jatuh
tempo tagihan.
Solusi:
Selain Gaji induk, Kepala Seksi Pencairan Dana harus melakukan persetujuan atas
tagihan yang diupload pada hari berkenaan.

2. Apa yang perlu dilakukan apabila ada SPM yang ditolak oleh Kepala Seksi PD masih
muncul pada Karwas Kontrak?
Identifikasi alternatif-alternatif penyebab:
Tagihan yang muncul pada karwas kontrak adalah tagihan yang masuk di tabel
utama (status tagihan: divalidasi atau HOLD). Apabila tagihan telah ditolak oleh
Kasi Pencairan Dana namun pembatalan tagihan belum dilakukan maka tagihan
tetap muncul pada Laporan Karwas Kontrak.
Solusi:
Lakukan pembatalan tagihan secara manual. Pastikan setelah dilakukan
pembatalan, status tagihan adalah dibatalkan.
I. Pembuatan Permintaan Proses Pembayaran (Payment Process Request/PPR) oleh
Staf Seksi Bank
1. Apa yang dilakukan apabila SPMKP bernilai nol gagal dalam proses pembuatan
PPR?
Identifikasi alternatif-alternatif penyebab:
SPM KP dengan nilai NOL (Nihil), pada aplikasi SPM masih dikelompokan dalam
Transfer Dana Elektronik. Akibatnya, pada saat upload, LoV paygroup yang tampil
adalah LoV untuk TDE. Pada saat pembuatan PPR, tagihan dengan nilai Nihil
tersebut tidak tampil (gagal dengan status "diakhiri") karena pada default template
pembayaran TDE, nilai nol tidak disertakan.

Modul Manajemen Pembayaran Page 8

 Solusi:
Langkah yang harus dilakukan oleh KPPN untuk SPM-KP bernilai Nihil adalah
sebagai berikut:
a. Petugas Validator menggunakan paygroup TDE
b. Staf Bank:
1) membuat PPR dengan mempergunakan paygroup TDE yang telah dipilih oleh
Petugas Valdiator namun pada saat pembuatan PPR, tab Kriteria Seleksi
Pembayaran, option box "sertakan jumlah nol" dicentang.
2) Pada saat pembuatan PPR, SPM KP berkenaan disertakan dengan SPM
lainnya yang ISI, sehingga secara total PPR tidak bernilai NOL.
3) Dalam hal pada hari tersebut, PPR atas template dimaksud tidak ada SPM isi
yang akan dibayarkan, Staf Bank dapat melakukan perubahan ke paygroup
lain yang terdapat SPM isi.

2. Apa yang dilakukan jika pengesahan SP3BLU dengan nilai minus yang telah
diapprove oleh Kepala Seksi Bank namun tidak muncul di level Staf Seksi Bank
sehingga tidak muncul di Daftar Tagihan per jatuh tempo?
Solusi:
Tagihan yang muncul di Daftar Tagihan Disetujui pertanggal jatuh tempo adalah
tagihan yang belum diterbitkan SP2Dnya.

3. Apa yang dilakukan oleh Seksi Bank jika pada saat membuat PPR terdapat tagihan
yang SPPTnya belum diterima dari Seksi Pencairan Dana?
Solusi:
Sesuai SOP, Seksi Bank hanya memproses PPR apabila SPPT atas tagihan tersebut
telah diterima. Dalam hal SPPT belum diterima maka tagihan tersebut harus
dikeluarkan dari PPR (dengan user staf bank atau kasi bank) atau SPPT berkenaan
dimintakan ke Seksi Pencairan Dana.

4. Apa yang dilakukan jika pada saat pembuatan PPR gagal sehingga muncul
status"akhiri pengguna"
Identifikasi alternatif-alternatif penyebab:
Isian parameter kriteria seleksi pembayaran pada template pembayaran yang
digunakan tidak sesuai dengan data tagihan termasuk pemilihan paygroup (yang
dilakukan oleh Patugas Validasi) dan tanggal jatuh tempo tagihan.
Solusi:
Pastikan bahwa parameter template pada seleksi telah sesuai dengan data tagihan
berikut paygroup yang dipilih (oleh Petugas Validasi) dan tanggal jatuh tempo
tagihan.

Modul Manajemen Pembayaran Page 9

J. Persetujuan Pembayaran (Release Payment) oleh Kepala Seksi Bank
Bagaimana tindaklanjut atas penyelesaian SP2D yang telah di void.
Solusi:
a. KPPN menyampaikan surat permintaan "VOID" kepada Dit. TP;
b. Apabila berdasarkan informasi Dit. TP bahwa void dapat dilakukan KPPN:
1) Apabila SP2D tersebut akan dibayarkan kembali, maka seksi Bank membuat
PPR lagi untuk data tagihan yang sama.
2) Apabila SP2D tersebut tidak dibayarkan kembali, Seksi Bank meminta
kepada seksi PD untuk membatalkan invoice dan menjalankan laporan
tolakan substantif untuk dikirimkan kepada Satker bersangkutan

K. Transfer Dana oleh Bank Operasional

Bagaimana mengatasi dana yang belum masuk ke rekening tujuan atas SP2D yang
telah terbit dengan status pengiriman "Created XML" atau "Insufficient Fund"?
Identifikasi:
Create XML atau insufficient fund merupakan informasi status pengiriman
data/uang yang terdapat pada Form Data Kirim Manual (XML) SP2D ke Bank (F17)
pada Kepala Seksi Bank.
a. insufficient fund : Dana pada rekening berkenaan tidak mencukupi
b. Create XML file : File XML terbentuk pada server intermediary dan
sudah ditarik oleh Bank
Solusi:
a. Tindak lanjut atas status Create XML file adalah KPPN segera melaporkan secara
tertulis kepada Direktorat Transformasi Perbendaharaan apabila status tersebut
tidak berubah sampai dengan akhir hari.
b. Tindak lanjut atas status insufficient fund adalah apabila dalam satu hari kerja
setelah muncul status insufficient fund dana belum diterima di rekening
penerima dan tidak disajikan dalam Laporan SP2D Retur pada SPAN, KPPN
berkoordinasi dengan Direktorat Transformasi Perbendaharan untuk
berkoordinasi lebih lanjut.

L. Lain-Lain
Bagaimana cara mengetahui sisa TUP untuk satker yang akan mengajukan TUP
berikutnya?
Solusi:
Desain proses bisnis dan aplikasi SPAN, dilakukan pembedaan akun UP dan TUP
berikut setorannya. Dengan kondisi bahwa saat ini akun UP dan TUP belum

Modul Manajemen Pembayaran Page 10

 dibedakan maka untuk mengetahui besara sisa TUP, KPPN harus melakukan dan
membuat pengawasan secara manual.

Modul Manajemen Pembayaran Page 11