Keunggulan #13: Buku Pengawasan Penerimaan & Pengeluaran Terintegrasi
Tagline: “Satu form, semua jenis pembayaran — satu kali simpan, tiga data terintegrasi”
1. Ringkasan
Booku memiliki sistem Buku Pengawasan Penerimaan & Pengeluaran yang unik — menggunakan satu form dinamis untuk semua jenis transaksi kas/bank, dengan dua jalur masuk yang fleksibel, dan penyimpanan terintegrasi yang mencatat data pengawasan, bukti transaksi, dan jurnal secara serentak.
2. Masalah di Aplikasi Lain
Kebanyakan aplikasi akuntansi menggunakan pendekatan modular terpisah:
| Masalah | Dampak |
|---|---|
| Menu terpisah per jenis | 15+ menu berbeda untuk tiap jenis pembayaran/penerimaan |
| Satu jalur masuk | Hanya bisa input dari modul AP/AR, tidak dari buku pengawasan |
| Simpan bertahap | Input bukti → simpan → buka jurnal → input manual → simpan lagi |
| Data tidak sinkron | Resiko data pengawasan dan jurnal tidak cocok |
| Learning curve tinggi | User harus hafal lokasi menu masing-masing jenis transaksi |
3. Solusi Booku
3.1 Satu Form Dinamis untuk Semua Jenis Transaksi
┌─────────────────────────────────────────────────────────────────┐│ FORM DINAMIS SINGLE-ENTRY │├─────────────────────────────────────────────────────────────────┤│ ││ Aplikasi Lain: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Menu Pembayaran Hutang Usaha [Form terpisah #1] │ ││ │ Menu Pembayaran Hutang Karyawan [Form terpisah #2] │ ││ │ Menu Pembayaran Hutang Afiliasi [Form terpisah #3] │ ││ │ Menu Pembayaran Hutang Pajak [Form terpisah #4] │ ││ │ Menu Setoran Modal [Form terpisah #5] │ ││ │ Menu Biaya Operasional [Form terpisah #6] │ ││ │ ... dan seterusnya (15+ form) │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Booku: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ SATU FORM: Input Bukti Pengeluaran │ ││ │ │ ││ │ Kategori: [▼ Pembayaran Hutang ] │ ││ │ Peruntukan: [▼ Hutang Usaha ] │ ││ │ ↓ │ ││ │ UI menyesuaikan otomatis! │ ││ │ - Field yang relevan muncul │ ││ │ - Field yang tidak relevan sembunyi │ ││ │ - Validasi sesuai konteks │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ User cukup hafal SATU form, sisanya sistem yang handle! ││ │└─────────────────────────────────────────────────────────────────┘3.2 Klasifikasi Granular: Kategori + Peruntukan
┌─────────────────────────────────────────────────────────────────┐│ DUA LEVEL KLASIFIKASI │├─────────────────────────────────────────────────────────────────┤│ ││ Tingkat 1: KATEGORI (menentukan arah arus kas) ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Bukti Penerimaan: Bukti Pengeluaran: │ ││ │ • Penerimaan Piutang • Pembayaran Hutang │ ││ │ • Investasi Modal • Pencairan Pinjaman │ ││ │ • Pencairan Pinjaman • Pembelian │ ││ │ • Penerimaan Lainnya • Pengeluaran Lainnya │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Tingkat 2: PERUNTUKAN (menentukan detail akun) ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Kategori "Pembayaran Hutang": │ ││ │ • Hutang Usaha → COA: Hutang Usaha │ ││ │ • Hutang Karyawan → COA: Hutang Karyawan │ ││ │ • Hutang Afiliasi → COA: Hutang Afiliasi │ ││ │ • Hutang Pemegang Saham → COA: Hutang Pemegang Saham │ ││ │ • Hutang Pihak Ketiga → COA: Hutang Pihak Ketiga │ ││ │ • Hutang Bank-Leasing → COA: Hutang Bank-Leasing │ ││ │ • Hutang Pajak → COA: Hutang Pajak │ ││ │ • Deposit Operasional → COA: Deposit Operasional │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Kombinasi Kategori + Peruntukan = Logika Jurnal yang TEPAT ││ │└─────────────────────────────────────────────────────────────────┘3.3 Dua Jalur Masuk (Dual Entry Point)
┌─────────────────────────────────────────────────────────────────┐│ FLEKSIBILITAS JALUR MASUK │├─────────────────────────────────────────────────────────────────┤│ ││ JALUR 1: Dari Menu Utama ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Menu → Bukti Pengeluaran → Input Baru │ ││ │ │ ││ │ • User pilih Kategori dan Peruntukan manual │ ││ │ • User pilih Lawan Transaksi manual │ ││ │ • Cocok untuk: Transaksi baru tanpa referensi │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ JALUR 2: Dari Buku Pengawasan ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Buku Pengawasan Hutang Usaha → Klik "Bayar" │ ││ │ │ ││ │ • Kategori: Otomatis "Pembayaran Hutang" │ ││ │ • Peruntukan: Otomatis "Hutang Usaha" │ ││ │ • Lawan Transaksi: Otomatis terisi dari buku │ ││ │ • Invoice: Otomatis terisi (jika bayar per invoice) │ ││ │ • Jumlah: Otomatis terisi dari sisa hutang │ ││ │ │ ││ │ Cocok untuk: Pembayaran dari catatan yang sudah ada │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Jalur berbeda, HASIL SAMA — data tersimpan dengan benar! ││ │└─────────────────────────────────────────────────────────────────┘Keuntungan Dual Entry Point:
| Jalur | Cocok Untuk | Efisiensi |
|---|---|---|
| Menu Utama | Transaksi baru, tidak ada referensi sebelumnya | Manual input |
| Buku Pengawasan | Pembayaran/pencairan dari hutang/piutang yang sudah tercatat | Pre-filled, minimal input |
3.4 Penyimpanan Terintegrasi (3-in-1)
┌─────────────────────────────────────────────────────────────────┐│ SEKALI SIMPAN, TIGA DATA TERINTEGRASI │├─────────────────────────────────────────────────────────────────┤│ ││ Aplikasi Lain: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Step 1: Input bukti pembayaran → Simpan │ ││ │ Step 2: Buka modul jurnal → Input manual │ ││ │ Step 3: Input jurnal → Simpan │ ││ │ Step 4: Update buku pengawasan → Manual/terpisah │ ││ │ │ ││ │ ⚠️ Resiko: Data tidak sinkron jika ada step terlewat │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Booku: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Input Bukti Pengeluaran → Klik SIMPAN │ ││ │ ↓ │ ││ │ ┌──────────────────────────────────────────────────┐ │ ││ │ │ DALAM 1 TRANSACTION (All-or-Nothing): │ │ ││ │ │ │ │ ││ │ │ ✓ Data Bukti Pengeluaran (tbl_pengeluaran) │ │ ││ │ │ ✓ Data Buku Pengawasan (tbl_xxx sesuai jenis) │ │ ││ │ │ ✓ Jurnal Otomatis (tbl_transaksi) │ │ ││ │ │ │ │ ││ │ │ Semua SUKSES atau semua ROLLBACK │ │ ││ │ └──────────────────────────────────────────────────┘ │ ││ │ │ ││ │ ✅ Data PASTI sinkron, tidak mungkin tidak cocok │ ││ └─────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Data yang Tersimpan Serentak:
| Tabel | Isi | Contoh |
|---|---|---|
tbl_pengeluaran / tbl_penerimaan | Bukti transaksi | Nomor KK, tanggal, jumlah, sarana |
tbl_hutang_usaha (atau tabel pengawasan lain) | Update saldo pengawasan | Status jadi “Dibayar”, sisa hutang berkurang |
tbl_transaksi | Jurnal otomatis | Debet/Kredit sesuai peruntukan |
3.5 Sistem Approval & Bundel (Pengeluaran)
Catatan: Fitur ini sudah ada di sistem internal dan akan diterapkan.
┌─────────────────────────────────────────────────────────────────┐│ SISTEM APPROVAL & BUNDEL │├─────────────────────────────────────────────────────────────────┤│ ││ FLOW TANPA APPROVAL: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Input → Simpan → Langsung Posted (status: Dibayar) │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ FLOW DENGAN APPROVAL: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Step 1: Input Pengajuan │ ││ │ Status: "Open" (belum disetujui) │ ││ │ Jurnal: Belum dibuat │ ││ │ │ ││ │ Step 2: Review oleh Atasan │ ││ │ Bisa: Setujui / Tolak / Edit │ ││ │ │ ││ │ Step 3: Bundel (opsional) │ ││ │ Gabungkan beberapa pengajuan dalam 1 bundel │ ││ │ Untuk efisiensi pembayaran │ ││ │ │ ││ │ Step 4: Cetak & Realisasi │ ││ │ Status: "Dibayar" │ ││ │ Jurnal: Otomatis dibuat saat realisasi │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Fleksibel: Perusahaan bisa pilih pakai approval atau tidak ││ │└─────────────────────────────────────────────────────────────────┘4. Perbandingan dengan Kompetitor
| Fitur | Accurate | Zahir | Jurnal.id | SAP/Oracle | Booku |
|---|---|---|---|---|---|
| Form Dinamis Single-Entry | ❌ Menu terpisah | ❌ Menu terpisah | ❌ Menu terpisah | ⚠️ Kompleks | ✅ Satu form |
| Dual Entry Point | ❌ | ❌ | ❌ | ⚠️ | ✅ |
| Klasifikasi Granular | ⚠️ 1 level | ⚠️ 1 level | ⚠️ 1 level | ✅ Multi-level | ✅ 2 level |
| Penyimpanan 3-in-1 | ⚠️ Partial | ⚠️ Partial | ⚠️ Partial | ✅ | ✅ |
| Sistem Bundel | ❌ | ❌ | ❌ | ✅ | ✅ |
| Kompleksitas Setup | Rendah | Rendah | Rendah | Tinggi | Rendah |
Value Proposition:
- Booku memberikan fitur level enterprise (SAP/Oracle) dengan kompleksitas level UKM (Accurate/Zahir)
5. Keunggulan
| Aspek | Aplikasi Lain | Booku |
|---|---|---|
| Jumlah Menu | 15+ menu terpisah | 1 form |
| Learning Curve | Hafal banyak menu | Hafal 1 form |
| Konsistensi Data | Resiko tidak sinkron | Pasti sinkron (transaction) |
| Kecepatan Input | Banyak langkah | Minimal langkah |
| Fleksibilitas Workflow | Satu jalur | Dua jalur |
| Kontrol Approval | Tidak ada / terpisah | Terintegrasi |
6. Target User
| User Type | Manfaat |
|---|---|
| Staff Akuntan | Efisien setelah terbiasa, workflow fleksibel |
| Owner UKM | Tidak perlu hafal banyak menu, cukup pilih kategori/peruntukan |
| Supervisor | Kontrol approval terintegrasi dalam satu alur |
7. Catatan Mitigasi
Karena sistem ini memiliki kompleksitas tersembunyi, perlu investasi di onboarding:
| Strategi | Implementasi |
|---|---|
| Guided Tour | Tooltip saat pertama kali buka form |
| Contextual Help | Ikon (?) di dropdown kategori/peruntukan |
| Visual Feedback | Animasi saat field muncul/hilang |
| Default Cerdas | Pre-select kategori/peruntukan yang paling sering |
| Dokumentasi User | Panduan “Kapan pakai kategori/peruntukan apa?“ |
8. UX Refinement Cerdas
Selain prinsip “satu form dinamis”, Bukti Penerimaan/Pengeluaran punya detail-detail UX cerdas yang bekerja di belakang layar — UI selalu serasi dengan konteks transaksi.
8.1 DJP Override — Section Bank Hide Total
Saat Lawan Transaksi = DJP (Direktorat Jenderal Pajak), seluruh section Bank di-hide — override semua kondisi lain (termasuk saat Sarana Pembayaran = Bank).
Alasan: Pembayaran pajak tidak menggunakan konsep biaya admin, transfer bank, atau rekening penerima dari sisi form ini. Menampilkan section Bank hanya membuat user bingung.
8.2 Daftar Tagihan Reaktif (0/1/>1 Baris)
Tabel “Daftar Tagihan” (panel kanan) menyesuaikan jumlah data:
| Jumlah Baris | Panel Kanan | Baris TOTAL | Tombol Simpan |
|---|---|---|---|
| 0 | Hide (modal lebih sempit) | — | Disabled + tooltip |
| 1 | Tampil | Hide (redundan) | Enabled |
| >1 | Tampil | Tampil (grand total) | Enabled |
Tidak ada baris TOTAL “palsu” yang isinya sama dengan baris satu-satunya. User tidak bisa simpan form kosong.
8.3 Sarana Pembayaran Consolidated (4-in-1 Dropdown)
Dropdown Sarana Pembayaran/Pencairan memuat semua jenis akun kas/bank dalam 1 list:
- Petty Cash (1110x)
- Kas (112xx)
- Bank (113xx)
- Cash Advance (1140x)
Plus range “selipan” 11001-11499 untuk custom COA. User tidak perlu pilih sub-kategori dulu — 1 klik dropdown menggantikan 2 langkah.
8.4 Visibility & State State Reactivity Lain
| Fitur | Perilaku |
|---|---|
| Field Rekening/Atas Nama Penerima | Hide saat LT Internal (8 kode: CUST/INT/DJP/KRY/BPJS-KS/BPJS-TK/KOPKAR/SP) atau Kategori Pemindahbukuan |
| Field Kurs | ReadOnly + auto-fetch dari Master Kurs berdasarkan tanggal & mata uang |
| Field Biaya Admin/Ditanggung Oleh | Reset otomatis ke 0/” saat LT berubah ke DJP |
| Daftar Tagihan | Auto-reset saat modal open atau preset berubah (cegah row tertinggal dari sesi sebelumnya) |
9. Menu yang Merealisasikan Keunggulan Ini
| Menu | Bentuk Realisasi |
|---|---|
| Bukti Penerimaan & Pengeluaran Bank/Cash | Realisasi utama — 1 form universal untuk semua jenis penerimaan & pengeluaran kas/bank, penyimpanan 3-in-1 atomic (bukti + pengawasan + jurnal) |
| Buku Pengawasan Gaji | Tombol Bayar 1-klik membuka form Bukti Pengeluaran yang tagihan & sisa terisi otomatis |
| Buku Pengawasan Turunan Gaji | Tombol Bayar 1-klik membuka form Bukti Pengeluaran preset BPJS/Koperasi/Serikat |
10. Nilai Tambah
“Satu form untuk semua jenis pembayaran dan penerimaan — sistem pintar yang menyesuaikan konteks, bukan user yang harus cari-cari menu.”
“Sekali simpan, tiga data langsung terintegrasi — tidak ada lagi resiko jurnal tidak cocok dengan bukti transaksi.”
“UI yang tidak menampilkan field yang tidak relevan — user fokus pada apa yang penting saat itu.”
Kembali ke: Keunggulan Booku | Detail Menu
Terakhir diperbarui: 21-05-2026