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

Deskripsi Singkat 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).

Daftar Keunggulan di Menu Ini

#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

Detail per Keunggulan

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:

  • Service PelaporanPPNService.GetRingkasanAsync branching by JenisTahunBuku: NORMAL → compute dari invoice; LAMPAU → baca dari tabel tbl_ppn (input manual).
  • Tabel tbl_ppn baru di Booku V2 (tidak ada di Booku Lama) — 12 baris per tahun + kolom Tahun discriminator agar 1 DB cutoff bisa simpan multi-year.
  • Frontend: dropdown tahun dinamis dari availableYears di LAMPAU (vs statis 2 opsi di NORMAL); kolom Aksi ⋮ Input/Edit/Clear hanya muncul di LAMPAU.

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

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:

  • Loop sekuensial Januari → Desember (mandatory — KompensasiSebelumnya bulan N tergantung PPNNKL bulan N−1).
  • Per bulan, query tbl_penjualan_invoice + tbl_pembelian_invoice dengan filter masa pajak yang benar (lihat #3).
  • KompensasiPembetulan di-aggregate dari tbl_pengawasanpelaporanpajak cross-year (mundur 5 tahun) — SPT pembetulan tahun lampau bisa ber-impact ke masa pajak tahun ini.
  • Field RO (Jumlah Keluaran, Jumlah Masukan, PPN NKL, Sisa Hutang) dihitung di service backend — tidak ada formula hardcode di frontend.

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

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

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, Booku Lama, dokumen PIB) bisa input langsung tanpa override formula.

Bagaimana Booku Melakukannya:

  • Schema tbl_ppn punya kolom Peredaran_Lokal baru (sejak 26-04-2026).
  • Form input field Peredaran Lokal jadi IDRInput dengan disable/validation rules — bukan ReadOnly display.
  • Service backend PelaporanPPNRecordService handle field di Update/Clear/Seed. Service utama PelaporanPPNService.BuildRingkasanFromTblPpnAsync baca langsung dari entity (bukan compute).

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

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:

  • AggregatePembayaranLintasTahunAsync loop dari tahunPajak s/d tahunBuku, gabungkan pembayaran dari semua DB.
  • AggregateKompensasiPembetulanAsync loop mundur 5 tahun dari tahunPajak, filter JenisPajak = "PPN" AND N_P = "P" AND JumlahLebihBayar > 0 AND KompensasiKeTahun = tahunPajak.
  • Try-catch per iterasi — DB yang belum ada di-skip tanpa crash.

→ Cross-link: #02 Automatic Everything

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:

  • Frontend PelaporanPPNDrawer.handleBayar panggil useBuktiPengeluaranStore.openAddModal dengan preset payload spesifik.
  • Backend BuktiPengeluaranService.GetOutstandingHutangPajakAsync punya branch BPHPPN- yang compute PPNNKL real-time + sisa hutang untuk bulan target — tabel pembayaran otomatis terisi.
  • Konsisten dengan pattern menu hutang pajak lainnya (PPh 21/23/25/26/4(2)).

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

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:

  • Shared LaporSPTModal dengan extension PPN: conditional render field Lebih Bayar + Kompensasi saat jenisPajak === "PPN" + NP === "P".
  • Backend PelaporanPajakService.CreateAsync/UpdateAsync honor field PPN-specific kalau JenisPajak == "PPN", zero-kan untuk PPh.
  • TW/TL auto-compute di service (akhir bulan berikutnya dari masa pajak, hanya untuk NP=N).
  • 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

Terakhir diperbarui: 26-04-2026