Rekening Digital, E-Wallet, dan Data Pajak: Mengapa jejak keuangan makin sulit dipisahkan
Satu owner dapat menerima pembayaran di rekening bank, QRIS, marketplace, dan e-wallet. Refund pelanggan masuk ke saldo platform. Uang pribadi dipakai menutup biaya iklan. Sebagian saldo ditarik ke bank, sebagian langsung dipakai membayar vendor. Pada akhir bulan, rekening bank terlihat rapi tetapi pendapatan usaha tersebar di lima tempat. Masalah pajaknya bukan karena dompet digital itu baru. Masalahnya karena cerita transaksi terpotong-potong.
Jejak keuangan kini makin mudah dihubungkan melalui identitas, perangkat, rekening pencairan, laporan platform, invoice, dan data pihak ketiga. PMK 108 Tahun 2025 memperbarui kerangka akses informasi keuangan, termasuk produk uang elektronik tertentu dalam Amended Common Reporting Standard. Namun aturan pelaporan data tidak berarti setiap top-up atau saldo otomatis menjadi objek pajak. Sumber dan substansi arus tetap menentukan.
Saldo bukan penghasilan, mutasi bukan selalu omzet
Top-up dari rekening sendiri hanya memindahkan dana. Refund mengembalikan uang. Pinjaman menambah kas tetapi bukan pendapatan. Setoran modal berbeda dari penjualan. Sebaliknya, pembayaran pelanggan tetap merupakan penerimaan usaha meskipun tidak pernah masuk rekening bank dan langsung dibelanjakan dari e-wallet.
Kesalahan muncul ketika semua mutasi masuk dianggap omzet atau ketika hanya pencairan ke bank yang dicatat sebagai omzet. Pendekatan pertama membesar-besarkan pendapatan karena menghitung top-up dan transfer internal. Pendekatan kedua menghilangkan saldo yang belum ditarik, fee, refund, dan pembayaran yang langsung digunakan.
Solusinya adalah kode sumber dana. Setiap arus masuk diberi kategori: penjualan, top-up sendiri, transfer antar-akun, refund, pinjaman, setoran modal, cashback, atau lainnya. Arus keluar juga diberi tujuan. Kategori tidak dipilih otomatis hanya dari nama lawan transaksi; bukti order, invoice, dan kontrak tetap diperlukan.
Satu transaksi dapat meninggalkan empat angka
Pelanggan membayar Rp100.000 melalui platform. Merchant menerima saldo Rp97.000 setelah fee. Platform menyetor Rp97.000 ke bank beberapa hari kemudian. Dashboard promosi mungkin menampilkan nilai lain setelah subsidi. Jika accounting hanya membaca bank, pendapatan dan fee tercampur.
Catatan yang benar mempertahankan nilai bruto transaksi, diskon siapa yang menanggung, fee platform, refund, pajak yang dipotong atau dipungut bila ada, serta nilai bersih. Settlement ID menghubungkan banyak order ke satu transfer bank. Tanpa settlement mapping, satu pencairan besar tidak bisa ditelusuri ke transaksi pelanggan.
Untuk QRIS atau payment gateway, pahami siapa penyedia jasa, siapa merchant of record, dan kapan transaksi dianggap selesai. Laporan harian dan laporan settlement dapat memakai zona waktu atau cut-off berbeda. Selisih 31 Desember sering bukan transaksi hilang, melainkan settlement yang masuk Januari.
Cashback dan subsidi perlu pemilik ekonomi yang jelas. Diskon yang ditanggung merchant mengurangi nilai yang berbeda dari promosi yang ditanggung platform. Cashback kepada pembeli bukan otomatis potongan pendapatan merchant. Voucher, koin aplikasi, dan gratis ongkir dapat menghasilkan kolom-kolom yang tampak kecil tetapi material ketika volume tinggi. Baca settlement rule dan kontrak kampanye sebelum membuat mapping pajak.
Saldo mengendap pada marketplace juga perlu masuk rekonsiliasi meskipun belum dapat ditarik karena masa tunggu. Pisahkan dana tersedia, dana tertahan, reserve sengketa, dan refund pending. Jangan mengakui seluruh dashboard sebagai kas bebas atau mengabaikannya sampai pencairan. Status hak merchant menentukan bagaimana saldo dijelaskan dalam pembukuan.
PPN atas uang berbeda dari PPN atas jasa
Uang elektroniknya bukan barang kena pajak. Pengisian saldo tidak otomatis dikenai PPN atas nilai uang yang dimasukkan. Namun jasa penyelenggaraan, biaya administrasi, atau fee dapat mempunyai perlakuan PPN tersendiri sesuai ketentuan. Demikian pula, barang atau jasa yang dibeli menggunakan e-wallet tetap mengikuti karakter pajaknya.
Pisahkan tiga lapis: transaksi dasar antara penjual dan pembeli, jasa pembayaran dari penyedia, serta pergerakan dana settlement. Ketika lapisan ini dicampur, merchant dapat salah menghitung omzet atau mengklaim pajak masukan tanpa dokumen yang tepat.
Bukti dari aplikasi juga perlu dinilai. Tangkapan layar saldo bukan faktur pajak. Notifikasi pembayaran bukan selalu bukti potong. Unduh invoice fee, laporan settlement, faktur pajak elektronik jika diterbitkan dan memenuhi syarat, serta kontrak layanan. Nama legal penyedia pada dokumen dapat berbeda dari nama merek aplikasi.
Apa yang berubah dengan PMK 108/2025?
PMK 108/2025 memperbarui petunjuk teknis akses informasi keuangan untuk kepentingan perpajakan. Dalam Amended CRS, Produk Uang Elektronik Tertentu atau Specified Electronic Money Products masuk cakupan rekening simpanan sesuai definisi dan syaratnya. Materi teknis DJP menunjukkan threshold saldo lebih dari USD10.000 untuk produk tersebut dalam konteks pelaporan yang relevan.
Ambang itu bukan batas bebas pajak dan bukan tarif. Penghasilan Rp1 juta yang terutang pajak tidak menjadi bebas hanya karena saldo e-wallet di bawah threshold. Sebaliknya, saldo di atas threshold yang berasal dari top-up dana sendiri tidak otomatis menjadi penghasilan. Threshold menentukan aspek pelaporan informasi, bukan substansi pajak setiap rupiah.
Jangan pula memecah saldo ke banyak akun hanya agar masing-masing terlihat kecil. Ketentuan due diligence, agregasi, identitas, dan anti-penghindaran dapat membuat strategi tersebut tidak efektif. Banyak akun justru memperburuk rekonsiliasi dan meningkatkan risiko akun tidak tercatat dalam SPT atau pembukuan.
Prosedur identifikasi untuk produk baru Amended CRS mulai relevan sejak 1 Januari 2026 sesuai transisi PMK. Penyedia dapat meminta self-certification domisili pajak dan data identitas. Jawab sesuai fakta. Nomor ponsel Indonesia, alamat KTP, dan domisili pajak tidak selalu identik bagi orang yang berpindah negara.
Coretax tidak membuka seluruh aplikasi pengguna
DJP telah menjelaskan bahwa Coretax bukan sistem untuk melihat seluruh saldo dan mutasi rekening wajib pajak. Data diperoleh melalui pelaporan, pertukaran, dan kewenangan yang diatur, bukan akses bebas oleh setiap pegawai. Kerahasiaan jabatan dan otorisasi tetap berlaku.
Pernyataan itu tidak berarti data digital tidak pernah sampai ke DJP. Informasi dari lembaga keuangan, penyedia platform, marketplace, instansi, SPT, dan proses pemeriksaan dapat digunakan sesuai kewenangan. SP2DK, misalnya, dapat meminta penjelasan atas data dan informasi. Wajib pajak kemudian mempunyai ruang menjelaskan konteks.
Karena itu, jangan mencoba menebak layar apa yang dilihat otoritas. Siapkan reconciliation pack yang menjawab selisih. Jika platform melaporkan nilai transaksi bruto sementara SPT menampilkan omzet setelah pembatalan sah, tunjukkan laporan refund. Jika saldo besar berasal dari top-up untuk promosi, tunjukkan transfer asal. Penjelasan berbukti lebih kuat daripada klaim “itu cuma e-wallet”.
Pemisahan pribadi dan usaha bukan lagi pilihan estetika
Owner UMKM sering memakai satu e-wallet untuk makan siang, iklan, ongkir, dan pembayaran pelanggan. Akibatnya, bookkeeper harus membaca ratusan transaksi pribadi untuk menemukan transaksi usaha. Privasi berkurang dan risiko salah klasifikasi naik.
Buat akun usaha terpisah bila layanan memungkinkan. Tetapkan rekening pencairan perusahaan, nama merchant yang konsisten, serta pengguna yang berwenang. Hindari berbagi OTP. Jika pegawai perlu melakukan pembayaran, gunakan role dan limit resmi, bukan meminjam ponsel owner.
Untuk badan usaha, saldo yang secara legal berada pada akun pribadi pendiri perlu dibereskan. Apakah dana itu milik perusahaan, piutang kepada pendiri, atau penerimaan yang belum disetor? Keputusan harus tercermin di buku besar dan didukung dokumen. Mengubah nama file menjadi “rekening kantor” tidak mengubah pemilik hukum akun.
Pribadi pun perlu pemisahan kategori. Freelancer yang menerima fee, reimbursements, dan pinjaman teman dalam satu dompet harus mencatat sebab masing-masing. Transfer antar-e-wallet sendiri diberi ID pasangan agar tidak dihitung dua kali.
Bangun rekonsiliasi dari order sampai SPT
Mulailah dengan daftar semua akun: bank digital, e-wallet, marketplace balance, payment gateway, dan akun settlement. Catat nama pemilik, fungsi, mata uang, tanggal aktif, serta rekening tujuan. Tutup akun tidak dipakai setelah laporan historis diunduh.
Setiap bulan, cocokkan order dengan pembayaran. Cocokkan pembayaran dengan settlement. Cocokkan settlement dengan bank. Cocokkan fee dengan invoice penyedia. Cocokkan pajak dengan bukti. Cocokkan saldo awal ditambah masuk dikurangi keluar dengan saldo akhir. Selisih diselidiki per jenis, bukan dihapus.
Gunakan identitas transaksi unik. Nomor order saja bisa berubah saat refund; settlement ID saja menggabungkan banyak order. Relasi keduanya membuat audit trail. Simpan file mentah dan file olahan. Jangan menimpa laporan CSV asli setelah menambah kategori.
Pada akhir tahun, pastikan saldo dan penghasilan tersambung ke daftar harta, pembukuan, serta SPT sesuai status wajib pajak. Rekening luar negeri atau domisili lintas negara memerlukan penilaian tambahan. Untuk transaksi material atau sistem yang kompleks, lakukan review sebelum batas pelaporan, bukan setelah menerima surat.
Data governance untuk bisnis yang sudah besar
Ketika volume naik, masalah berpindah dari spreadsheet ke integrasi. API dapat menarik data lebih cepat tetapi tetap dapat menggandakan transaksi, melewatkan pagination, atau mengubah timezone. Simpan log impor, versi mapping, dan kontrol jumlah record serta total nilai. Rekonsiliasi API dengan laporan resmi penyedia secara berkala.
Batasi akses ke data pelanggan dan saldo. Terapkan approval untuk perubahan rekening settlement. Monitor transaksi anomali, akun dorman, dan refund berulang. Rencana insiden harus mencakup cara mempertahankan bukti ketika platform tidak dapat diakses.
Tim tax perlu dilibatkan saat produk menambah metode pembayaran. Pertanyaan sederhana seperti “siapa menanggung diskon?” atau “kapan merchant memperoleh hak?” dapat mengubah pencatatan. Product metric gross merchandise value tidak selalu sama dengan omzet pajak. Finance metric cash received juga tidak selalu sama dengan penyerahan.
Dokumentasikan definisi setiap metric dalam data dictionary. Satu kolom “revenue” di dashboard bisa berarti nilai order sebelum batal, nilai setelah voucher, atau settlement bersih. Tanpa definisi dan pemilik data, tiga tim dapat melaporkan angka berbeda dengan nama sama. Rekonsiliasi dimulai dari bahasa yang disepakati.
Jejak keuangan makin sulit dipisahkan bukan karena satu sistem mengetahui segalanya. Penyebabnya adalah semakin banyak titik memakai identitas yang sama dan semakin standar laporan pihak ketiga. Rekening bank, e-wallet, marketplace, dan SPT tidak lagi aman dikelola sebagai pulau terpisah.
Ini bukan alasan untuk takut memakai pembayaran digital. Ini alasan untuk berhenti menjadikan saldo aplikasi sebagai pembukuan. Jika setiap arus mempunyai sumber, setiap settlement kembali ke order, akun pribadi dipisahkan, dan angka SPT dapat dijembatani ke laporan, transparansi menjadi lebih mudah dikelola. Yang menimbulkan risiko bukan banyaknya jejak, melainkan banyaknya jejak yang bercerita berbeda.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: Data Wajib Pajak
- Entitas: Tax Compliance
- Topik: Pelaporan SPT
- Indeks: SPT
- Evidence: Identity Source Map
- Artikel terkait: QDMTT, IIR, dan UTPR: Cara memahami tiga singkatan tanpa kehilangan gambaran besar
- Artikel terkait: PMK 108/2025 dan Akses Informasi Keuangan: Mengapa data aset digital makin masuk radar transparansi?
