Lewati ke konten
Booku — Dokumentasi Dokumentasi Booku

Keunggulan Booku: Buku Pengawasan Pelaporan PPN

Tier 3 — keunggulan-keunggulan Booku yang muncul saat user memakai menu Buku Pengawasan Pelaporan PPN (rekap SPT Masa PPN per bulan + Lapor SPT + Bayar ke DJP).

📘 Deskripsi user-friendly: deskripsi/pelaporan-ppn.md

1. Identitas Menu

AspekKeterangan
Nama MenuBuku Pengawasan Pelaporan PPN
Lokasi (Tahun NORMAL)Sidebar → Buku Pengawasan → Hutang Pajak → Pelaporan PPN
Lokasi (Tahun LAMPAU)Sidebar → Data Awal → Hutang → Pajak → Pelaporan PPN
Deskripsi User-Facing📘 Deskripsi & tutorial menu

PPN (Pajak Pertambahan Nilai) adalah pajak konsumsi yang dipungut perusahaan PKP setiap kali ada transaksi penjualan, lalu disetorkan ke DJP setelah dikurangi PPN yang dibayar saat pembelian (Pajak Masukan). Menu ini menyajikan rekap SPT Masa PPN per bulan dalam 1 tabel terpadu — Pajak Keluaran, Pajak Masukan, PPN NKL (Kurang/Lebih Bayar), pembayaran, pelaporan SPT, dan peredaran usaha.

Berbeda dengan jenis PPh lain yang fokus pada hutang per-record per-supplier, Pelaporan PPN bersifat aggregate — angka per bulan dihitung dari seluruh transaksi invoice penjualan + pembelian + kompensasi pembetulan. Booku menyediakan dual mode (NORMAL & LAMPAU) supaya perusahaan bisa input data historis sebelum migrasi (LAMPAU) sekaligus pakai aggregator otomatis untuk tahun aktif (NORMAL).

2. Ringkasan Keunggulan

#KeunggulanTier 2 Terkait
1Dual Mode NORMAL/LAMPAU di UI yang Sama (data otomatis vs input historis)#10, #08
2Aggregator Otomatis PPNNKL dari Invoice + Kompensasi Sebelumnya/Pembetulan#02, #04
3Tanggal Kredit Pajak Masukan Sesuai Aturan DJP (Lokal → Tgl Diterima Invoice, Impor → Tgl PIB)#04, #01
4Peredaran Lokal Manual untuk Mixed-Rate (PPN Final / Dibebaskan / 10/11/12%)#04, #12
5Cross-Year Tracking — Pembayaran & Kompensasi Pembetulan Otomatis#02
6Bayar 1-Klik ke DJP — Form Bukti Pengeluaran Preset Otomatis#02, #08
7Lapor SPT Terintegrasi dengan Auto-Tag TW/TL + Field PPN-Specific (Lebih Bayar + Kompensasi Ke)#04, #02
8Bar Saldo Rekonsiliasi — Saldo PPN Otomatis Match dengan COA + AJP, Selisih Audit-Ready#01, #02

3. Detail per Keunggulan

3.1 Dual Mode NORMAL/LAMPAU di UI yang Sama

Apa yang dirasakan user: Sebuah halaman tunggal yang otomatis adaptif terhadap status tahun buku yang sedang dilihat. Saat tahun aktif (NORMAL), tabel terisi otomatis dari transaksi invoice — user tinggal review & bayar. Saat tahun historis (LAMPAU — sebelum migrasi ke Booku), user bisa input manual 12 bulan PPN via form, dengan tombol [+]/[-] untuk tambah/hapus tahun.

Mengapa penting:

  • Perusahaan yang migrasi ke Booku setelah beberapa tahun beroperasi punya data PPN historis yang harus tetap tercatat untuk audit & SPT Pembetulan.
  • Tanpa mode LAMPAU: user kehilangan data historis atau harus pakai 2 sistem terpisah (Excel untuk historis + Booku untuk berjalan).
  • Tanpa mode NORMAL: user harus hitung manual setiap bulan walau sudah punya data invoice lengkap.

Bagaimana Booku Melakukannya:

  • Di tahun NORMAL, Booku menghitung PPN otomatis dari invoice penjualan & pembelian; di tahun LAMPAU, data dibaca dari input manual 12 bulan.
  • Booku menyimpan data PPN historis per tahun pajak — satu tampilan bisa memuat banyak tahun.
  • Dropdown tahun bersifat dinamis (menampilkan tahun yang relevan); kolom Aksi ⋮ Input/Edit/Clear hanya muncul di mode LAMPAU.

→ Cross-link: #10 UI Dinamis, #08 Simple for User

3.2 Aggregator Otomatis PPNNKL dari Invoice + Kompensasi

Apa yang dirasakan user: Buka halaman PPN tahun aktif → 12 baris bulan sudah terisi otomatis dengan angka Pajak Keluaran (per kategori Dibayar/Dipungut/Tidak Dipungut), Pajak Masukan (Impor/Dalam Negeri), Kompensasi Sebelumnya (carry-over dari bulan lalu yang lebih bayar), Kompensasi Pembetulan (dari SPT Pembetulan), dan PPN NKL. Tidak perlu hitung manual.

Mengapa penting:

  • PPNNKL = (Pajak Keluaran − Pajak Masukan) per bulan. Untuk perusahaan dengan ratusan invoice/bulan, perhitungan manual rentan salah & memakan waktu.
  • Aspek kompensasi sangat kompleks: PPN lebih bayar bulan ini boleh dikompensasi ke bulan depan (sebelumnya) atau ke bulan/tahun yang user pilih (pembetulan). Tracking manual hampir mustahil tanpa salah.
  • Tanpa otomasi: akuntan harus buka SPT manual, hitung per bulan, lalu input ulang — banyak ruang error.

Bagaimana Booku Melakukannya:

  • Perhitungan berjalan berurutan Januari → Desember (wajib — Kompensasi Sebelumnya bulan N bergantung pada PPN Kurang/Lebih Bayar bulan N−1).
  • Tiap bulan, Booku membaca invoice penjualan & pembelian sesuai masa pajak yang benar (lihat #3).
  • Kompensasi Pembetulan ikut diperhitungkan lintas tahun (mundur 5 tahun) — SPT pembetulan tahun lampau bisa berdampak ke masa pajak tahun ini.
  • Nilai turunan (Jumlah Keluaran, Jumlah Masukan, PPN NKL, Sisa Hutang) dihitung otomatis oleh Booku — bukan diketik manual.

→ Cross-link: #02 Automatic Everything, #04 Pajak Indonesia

3.3 Tanggal Kredit Pajak Masukan Sesuai Aturan DJP

Apa yang dirasakan user: Pajak Masukan dari pembelian Lokal masuk ke masa pajak sesuai tanggal Faktur Pajak yang diterima (= Tanggal Diterima Invoice — kolom induk Tanggal FP di form input). Pajak Masukan dari Impor masuk sesuai Tanggal PIB (= Tanggal Faktur Pajak yang berbeda dari Tanggal Invoice supplier luar negeri). Tidak campur aduk.

Mengapa penting:

  • Aturan DJP: PM Lokal dikreditkan pada masa pajak Tanggal FP; PM Impor dikreditkan pada masa pajak Tanggal PIB. Banyak sistem hanya pakai 1 tanggal (Tanggal Invoice) yang salah masa pajak, terutama untuk Impor (PIB bisa beda bulan dari invoice supplier).
  • Konsekuensi salah masa pajak: SPT Masa tidak match dengan dokumen sumber → resiko pemeriksaan DJP.

Bagaimana Booku Melakukannya:

  • Form Input Invoice Pembelian sudah meng-enforce algoritma: Tanggal Faktur Pajak induk = Tanggal Diterima Invoice untuk Lokal PKP (validasi keras di form input).
  • Aggregator PPN per bulan filter pakai kolom yang benar per jenis (Lokal Tanggal_Diterima_Invoice, Impor Tanggal_Faktur_Pajak).
  • Fallback ke Tanggal_Invoice kalau kolom utama kosong (defensive untuk data legacy).

→ Cross-link: #04 Pajak Indonesia, #01 Realtime Accuracy

3.4 Peredaran Lokal Manual untuk Mixed-Rate

Apa yang dirasakan user: Kolom Peredaran Lokal (DPP penjualan lokal) bisa diisi manual oleh user di mode LAMPAU. Tidak di-paksa pakai formula hardcode Jumlah Keluaran / 11%. Validasi UX: kalau ada Pajak Keluaran ada (>0), field wajib > 0; kalau tidak ada Pajak Keluaran, field auto-disable & set 0.

Mengapa penting:

  • Realita perpajakan: tarif PPN tidak selalu 11%. Ada PPN Final (Pasal 16D, JKP tertentu) dengan tarif beda, PPN dibebaskan (rate 0%), historical 10% (sebelum 2022) atau 12% transitional, dan mixed-rate dalam 1 bulan untuk perusahaan multi-segment.
  • Rumus hardcode Peredaran = PajakKeluaran / 11% akan menghasilkan angka salah untuk semua kasus di atas → SPT salah → resiko denda.
  • User yang punya catatan DPP eksak dari source asli (SPT Excel lama, sistem internal, dokumen PIB) bisa input langsung tanpa override formula.

Bagaimana Booku Melakukannya:

  • Booku menyediakan field Peredaran Lokal yang bisa diisi langsung (bukan sekadar tampilan baca-saja), lengkap dengan validasi nilai.
  • Nilai yang Anda input tersimpan dan langsung dipakai di ringkasan — tanpa perhitungan ulang yang bisa menyimpang.

→ Cross-link: #04 Pajak Indonesia, #12 Target UKM

3.5 Cross-Year Tracking — Pembayaran & Kompensasi Pembetulan

Apa yang dirasakan user: Pembayaran PPN tahun lalu yang baru dibayar di tahun ini tetap muncul. SPT Pembetulan tahun lalu yang menghasilkan lebih bayar dengan kompensasi ke bulan tahun ini, otomatis muncul di kolom “Komp. Pembetulan” bulan target.

Mengapa penting:

  • Skenario realistis: SPT PPN Desember 2025 lapor bulan Januari 2026, bayar Januari 2026. Pembayaran di DB 2026, tagihan di DB 2025.
  • Skenario kompensasi: SPT Pembetulan Oktober 2025 lebih bayar 5 juta → user pilih kompensasi ke Februari 2026. Saat user buka tahun 2026, kolom Komp. Pembetulan baris Februari otomatis = 5 juta.

Bagaimana Booku Melakukannya:

  • Pembayaran PPN ditelusuri lintas tahun — pembayaran tahun berjalan untuk masa pajak tahun sebelumnya tetap terhitung.
  • Kompensasi Pembetulan ditelusuri mundur sampai 5 tahun — SPT pembetulan lebih bayar tahun lampau yang dikompensasikan ke tahun ini ikut diperhitungkan otomatis.
  • Tahun yang datanya belum tersedia otomatis dilewati tanpa error.

→ Cross-link: #02 Automatic Everything

3.6 Bayar 1-Klik ke DJP — Form Preset Otomatis

Apa yang dirasakan user: Klik baris bulan → drawer terbuka di kanan dengan tombol Bayar PPN. Klik tombol → langsung muncul modal Input Bukti Pengeluaran dengan semua field preset: Kategori = “Pembayaran Hutang”, Peruntukan = “Pembayaran Hutang Pajak”, Lawan Transaksi = “DJP”, Nomor BP = format BPHPPN-{tahun}-{bulan}, Tabel detail tagihan langsung terisi sisa hutang. User tinggal pilih sarana pembayaran + tanggal bayar.

Mengapa penting:

  • Pembayaran PPN ke DJP punya banyak field yang harus konsisten (DJP, format Nomor BP, kategori). Salah satu field salah → pembayaran tidak match dengan tagihan, sisa hutang tidak ter-update.
  • Tanpa preset: user buka Bukti Pengeluaran manual, pilih sarana 11+ field — banyak ruang error.

Bagaimana Booku Melakukannya:

  • Klik Bayar pada baris bulan langsung membuka form pembayaran (Bukti Pengeluaran) yang sudah ter-preset untuk PPN masa tsb.
  • Booku menghitung PPN Kurang Bayar + sisa hutang bulan target secara otomatis, lalu mengisinya di form — user tinggal konfirmasi.
  • Konsisten dengan pattern menu hutang pajak lainnya (PPh 21/23/25/26/4(2)).

→ Cross-link: #02 Automatic Everything, #08 Simple for User

3.7 Lapor SPT Terintegrasi dengan Auto-Tag TW/TL + Field PPN-Specific

Apa yang dirasakan user: Setelah lunas, tombol Lapor SPT aktif di drawer. Klik → modal Lapor terbuka, user pilih Tanggal Lapor + status (N=Nihil / P=Pembetulan). Jika P + Lebih Bayar > 0 → muncul field tambahan Jumlah Lebih Bayar PPN + Kompensasi Ke Bulan + Tahun (khusus PPN, tidak muncul di PPh lain). Save → kolom tabel “TW/TL” otomatis terisi: TW (Tepat Waktu) atau TL (Terlambat) sesuai deadline DJP.

Mengapa penting:

  • Deadline lapor SPT PPN = akhir bulan berikutnya. Hitungan TW/TL manual mudah salah, padahal ini jadi acuan audit DJP.
  • Field Lebih Bayar + Kompensasi PPN-specific — di PPh tidak ada. Sistem yang generic 1-form-untuk-semua-pajak biasanya tidak akomodasi.

Bagaimana Booku Melakukannya:

  • Form Lapor SPT menampilkan field Lebih Bayar + Kompensasi secara kondisional — khusus saat melaporkan PPN pembetulan.
  • Booku menyimpan field khusus PPN hanya saat jenis pajaknya PPN (dinolkan untuk PPh) — satu form, perilaku menyesuaikan jenis pajak.
  • Status TW/TL (Tepat Waktu / Terlambat Lapor) dihitung otomatis dari masa pajak.
  • Hasilnya cross-link otomatis: Lapor PPN dengan kompensasi → bulan target di tabel utama langsung tampil kolom Komp. Pembetulan terisi (lihat keunggulan #5).

→ Cross-link: #04 Pajak Indonesia, #02 Automatic Everything

3.8 Bar Saldo Rekonsiliasi — Saldo PPN Match dengan COA + AJP

Apa yang dirasakan user: Di atas tabel utama, ada bar info saldo yang menampilkan tiga angka penting saat tahun aktif: Saldo Awal Berdasarkan List (sisa hutang PPN dari tahun-tahun historis sebelumnya), Saldo Awal Berdasarkan COA + AJP (saldo akuntansi akun Hutang PPN, termasuk Jurnal Penyesuaian Audit), dan Selisih di antara keduanya. Idealnya selisih = 0 (data finance match dengan akuntansi). Kalau berbeda, user langsung tahu ada gap yang perlu dicek — tanpa harus buka Trial Balance terpisah.

Mengapa penting:

  • PPN adalah kewajiban pajak yang langsung dipantau DJP. Saat audit atau SP2DK, finance vs akuntansi harus sinkron — kalau di catatan finance (sumber pembayaran riil) berbeda dari saldo COA Hutang PPN, itu sinyal kesalahan posting yang harus diluruskan sebelum SPT dikirim atau audit datang.
  • Tanpa bar reconciliation: user harus manual buka 2 laporan (Buku Pengawasan + Trial Balance) lalu hitung selisih di Excel. Selisih kecil sering luput.
  • Saat perusahaan baru migrasi ke Booku setelah pakai sistem lain (atau Excel) selama beberapa tahun, saldo awal PPN harus carry-over dari periode historis. Tanpa otomasi, user input manual lewat AJP — rentan salah angka & tanggal.

Bagaimana Booku Melakukannya:

  • Saldo Awal Berdasarkan List dihitung otomatis dari data PPN historis (mode LAMPAU) yang sudah Anda input — Booku menjumlahkan sisa PPN terutang setiap bulan yang belum dibayar, dikurangi pembayaran yang dilakukan setelah tahun historis ditutup.
  • Hanya berlaku saat tahun NORMAL pertama (transisi LAMPAU → NORMAL); setelah tahun pertama berjalan, saldo awal sudah ter-cover via Tutup Buku reguler — bar otomatis bernilai 0.
  • Saldo COA + AJP diambil langsung dari saldo akun Hutang PPN di Chart of Account, termasuk akumulasi jurnal penyesuaian audit (“Adjusment Saldo Awal”) yang sudah pernah di-input. Tooltip ”ⓘ” menampilkan breakdown: berapa Saldo Awal COA + berapa AJP yang terakumulasi.
  • Ketetapan Pajak (SKP/STP DJP) sengaja DIKECUALIKAN dari Saldo Awal — karena Ketetapan posting ke akun Hutang Pajak terpisah, bukan ke akun Hutang PPN. Pemisahan ini menjaga supaya bar reconciliation bermakna 1:1 dengan COA yang dimaksud.
  • Indikator visual: tampilan ”—” untuk nilai 0 (membedakan dari nilai tidak ter-load), tag warna untuk Selisih > 0 (orange/merah supaya gampang ke-spot).

Catatan untuk perusahaan yang baru migrasi: Bar Saldo memberi gambaran instan apakah catatan PPN historis Anda sudah konsisten dengan akuntansi. Selisih ≠ 0 di tahun NORMAL pertama menunjukkan ada PPN yang belum di-AJP — itu petunjuk yang berguna untuk dijaga sebelum lapor SPT atau audit.

→ Cross-link: #01 Realtime Accuracy, #02 Automatic Everything

4. Nilai Tambah untuk User

“Pusat pelaporan PPN yang mengakomodasi dual mode (NORMAL auto-aggregate dari invoice / LAMPAU input manual historis), dengan tanggal kredit Pajak Masukan DJP-compliant dan Bayar 1-klik ke DJP — siap audit SP2DK kapan saja.”

Pelaporan PPN biasanya jadi titik tersulit di sistem akuntansi karena aturan DJP yang rumit (tanggal kredit Lokal vs Impor berbeda, kompensasi lintas tahun, mixed-rate per produk). Booku menjawab semuanya dalam satu halaman terpadu yang sama dipakai untuk tahun aktif maupun tahun historis sebelum migrasi.

5. Dokumentasi Terkait

Terakhir diperbarui: 08-06-2026