Empat toko dapat menghasilkan enam angka omzet yang sama-sama tampak masuk akal. Dashboard marketplace menunjukkan gross merchandise value. Admin mencatat pesanan selesai. Finance memakai settlement. Bank menunjukkan pencairan bersih. Tim pajak mengekspor dokumen tagihan. Owner masih menambahkan penjualan toko fisik.
Pertanyaan “omzet kita berapa?” akhirnya dijawab berbeda tergantung siapa yang membuka laptop.
Untuk seller yang memiliki beberapa akun di Tokopedia, Shopee, Lazada, atau Blibli, persoalan ini makin penting sejak keempat perusahaan ditunjuk Direktorat Jenderal Pajak sebagai pemungut PPh Pasal 22 pada 1 Juli 2026. Selain menentukan dasar pencatatan, seller orang pribadi perlu mengetahui kapan total peredaran bruto tahun berjalannya melewati Rp500 juta. Batas itu dihitung atas keseluruhan usaha, bukan per toko.
Tujuan konsolidasi bukan menjumlahkan semua file. Tujuannya membentuk satu populasi transaksi yang setiap barisnya unik, dapat ditelusuri, dan hanya dihitung sekali.
Langkah nol: tentukan siapa pemilik omzet
Sebelum menggabungkan data, pastikan empat toko benar-benar milik subjek pajak yang sama. Kesamaan owner operasional belum tentu berarti kesamaan pihak yang mengakui penghasilan.
Toko A dan B mungkin atas NIK pendiri, toko C atas NPWP PT, sedangkan toko D memakai rekening pasangan. Menjumlahkan semuanya ke satu angka dapat salah. Sebaliknya, memisahkan toko yang sebenarnya seluruhnya dimiliki orang pribadi yang sama juga dapat mengecilkan omzet.
Buat matriks identitas dengan kolom: nama akun, platform, nama hukum pemilik, NIK atau NPWP, rekening pencairan, pihak pemilik stok, pihak penerbit invoice, serta buku besar tempat penjualan dicatat. Setiap perbedaan harus diselesaikan atau setidaknya didokumentasikan sebelum perhitungan pajak.
Untuk Wajib Pajak orang pribadi, DJP menjelaskan bahwa satu surat pernyataan mengenai peredaran bruto dapat digunakan untuk semua akun dan disampaikan ke semua marketplace. Logikanya konsisten: yang diuji adalah satu pedagang, bukan banyak nama toko.
Pilih satu unit terkecil: transaksi, bukan settlement
Settlement adalah kumpulan banyak transaksi yang sudah dipotong biaya dan pajak. Satu order dapat masuk settlement minggu berikutnya, sedangkan satu settlement dapat mencakup order dari beberapa hari. Menggabungkan omzet berdasarkan settlement membuat transaksi mudah hilang atau berpindah bulan.
Gunakan ID pesanan sebagai unit terkecil. Bila marketplace memiliki order induk dan item order, tentukan level yang benar untuk menghindari penggandaan. Satu order dengan tiga produk dapat muncul sebagai satu nomor pembayaran, tiga nomor item, dan satu nomor pencairan. Menjumlahkan level order dan level item sekaligus akan menghitung penjualan dua kali.
Buat kunci unik yang mencakup kode platform, kode toko, dan ID pesanan atau item sesuai level data. Contohnya: SHP-TOKO1-ORDER123. Penambahan kode toko penting karena dua platform atau dua akun dapat memakai format nomor yang kebetulan sama.
Jangan gunakan nama pembeli, tanggal, dan nominal sebagai kunci utama. Dua orang dapat membeli barang dengan nilai sama pada detik yang berdekatan. Kunci berbasis transaksi jauh lebih kuat.
Tentukan peristiwa yang disebut omzet
Dashboard dapat menampilkan pesanan dibuat, dibayar, dikirim, selesai, atau dana dilepas. Agar empat toko dapat dibandingkan, pilih definisi operasional yang konsisten sesuai kebijakan pembukuan dan fakta transaksi.
Untuk PPh Pasal 22 marketplace, DJP menjelaskan saat terutang ketika pembayaran diterima pihak lain. Untuk pengakuan pendapatan, bisnis perlu mengikuti standar dan kebijakan akuntansi yang relevan. Kedua tanggal dapat berbeda. Karena itu, simpan beberapa tanggal, jangan paksa satu kolom mengerjakan semua fungsi.
Minimal rekam tanggal order, pembayaran diterima platform, transaksi selesai, refund, dan settlement. Laporan omzet internal dapat memakai tanggal yang telah diputuskan, sedangkan rekonsiliasi pungutan memakai tanggal relevan menurut PMK. ID transaksi menjadi jembatan ketika keduanya berada di bulan berbeda.
Bangun tabel fakta tunggal
Empat file marketplace sebaiknya dinormalisasi ke struktur yang sama. Tabel utama dapat memuat:
platform dan toko; ID transaksi unik; tanggal-tanggal utama; status pesanan; nilai barang atau jasa; diskon yang ditanggung seller; diskon atau subsidi platform; PPN dan PPnBM bila ada; refund atau retur; dasar pungut PPh Pasal 22; nilai PPh yang dipungut; biaya platform per kelompok; nilai settlement; nomor dokumen tagihan; status rekonsiliasi.
Nama kolom sumber boleh berbeda, tetapi hasil normalisasinya harus konsisten. Simpan file asli secara terpisah. Jangan menimpa data mentah dengan rumus karena saat platform mengubah format, tim membutuhkan sumber untuk menelusuri perubahan.
Aturan double count yang paling sering dilanggar
Kasus pertama adalah menggabungkan laporan order dengan laporan settlement sebagai dua sumber omzet. Laporan settlement digunakan untuk kas, biaya, dan pajak, bukan ditambahkan lagi sebagai penjualan jika order yang sama sudah ada di tabel transaksi.
Kasus kedua adalah pesanan pindah status. Data 31 Juli menunjukkan “dikirim”, sedangkan unduhan 3 Agustus menunjukkan order sama “selesai”. Jika kedua snapshot ditumpuk tanpa kunci unik dan aturan pembaruan, transaksi terhitung dua kali. Gunakan versi terbaru untuk status, tetapi pertahankan histori perubahan bila diperlukan.
Kasus ketiga adalah refund parsial. Seller menghapus seluruh omzet padahal hanya sebagian nilai dikembalikan, atau mempertahankan seluruh omzet dan mencatat refund sebagai biaya. Perlakuan harus mengikuti fakta transaksi serta kebijakan akuntansi, dengan nilai awal dan koreksi disimpan terpisah.
Kasus keempat adalah kanal perantara. Order dibuat melalui live streaming tetapi checkout berlangsung di marketplace. Jangan mencatat angka dari dashboard live dan transaksi marketplace sebagai dua penjualan. Dashboard live adalah sumber atribusi pemasaran, sedangkan transaksi checkout menjadi sumber nilai penjualan.
Kasus kelima adalah penjualan grosir yang dibayar dalam beberapa termin atau beberapa order yang digabung satu invoice. Tetapkan hubungan induk-anak agar invoice tidak ditambahkan di atas seluruh order pembentuknya.
Uji dengan formula kontrol
Setelah tabel transaksi bersih, hitung tiga total yang berbeda.
Total pertama adalah peredaran bruto sesuai definisi pajak dan dokumen transaksi yang relevan. Jangan menguranginya dengan biaya platform hanya karena biaya langsung dipotong.
Total kedua adalah penjualan bersih menurut kebijakan pembukuan setelah koreksi yang sah. Angka ini dapat berbeda dari peredaran bruto pajak karena definisi serta timing.
Total ketiga adalah kas settlement. Angka ini terbentuk setelah biaya, PPh Pasal 22, refund, saldo tertahan, dan penyesuaian.
Jangan memaksa ketiganya sama. Buat jembatan yang menjelaskan perbedaan. Jika peredaran bruto Rp600 juta, biaya platform Rp45 juta, PPh dipungut Rp3 juta, serta ada penyesuaian bersih Rp2 juta, kas dapat berbeda jauh. Selama setiap komponen memiliki dokumen dan transaksi, perbedaan bukan masalah.
Masukkan toko offline tanpa menciptakan transaksi kembar
DJP menyatakan peredaran bruto orang pribadi untuk batas Rp500 juta mencakup seluruh toko online dan offline serta penghasilan usaha atau jasa yang termasuk cakupan perhitungan. Penjualan offline perlu masuk konsolidasi, tetapi sumbernya harus jelas.
Masalah muncul ketika pembeli memesan di marketplace lalu mengambil barang di toko. Kasir mungkin membuat struk baru, sehingga satu transaksi muncul di marketplace dan POS. Solusinya, wajibkan pencantuman ID marketplace pada transaksi pengambilan. POS memberi tanda “fulfilment marketplace” dan tidak menambahkannya sebagai penjualan baru bila penjualan sudah diakui dari marketplace.
Hal serupa berlaku untuk pesanan WhatsApp yang kemudian diarahkan checkout ke marketplace. Pilih sumber transaksi final. Chat menjadi bukti komunikasi, bukan sumber omzet kedua.
Meteran Rp500 juta yang tidak menipu
Wajib Pajak orang pribadi sampai Rp500 juta dapat tidak dipungut oleh marketplace setelah menyampaikan surat pernyataan sesuai PMK 37 Tahun 2025. Meteran internal perlu menjumlahkan omzet kumulatif seluruh kanal yang relevan sejak awal tahun.
Jangan mengurangi angka meteran dengan fee, ongkir yang bukan pendapatan seller, atau pencairan yang belum masuk bank tanpa memahami karakter komponen. PMK dan penjelasan DJP menggunakan konsep peredaran bruto sebelum pengurangan potongan tertentu sebagaimana ketentuan. Bila ada kategori yang meragukan, dokumentasikan dan minta telaah, bukan memilih angka yang paling rendah.
Pasang tiga alarm, misalnya pada 70 persen, 90 persen, dan 100 persen dari batas. Alarm pertama untuk memeriksa kualitas data, alarm kedua untuk menyiapkan administrasi, dan alarm ketiga untuk memperbarui pernyataan kepada marketplace sesuai tenggat. Ambang internal ini bukan ketentuan pemerintah, melainkan kontrol agar bisnis tidak terkejut pada akhir bulan.
Rekonsiliasi PPh per toko lalu konsolidasi per subjek
Periksa pungutan pada level toko karena dokumen dan settlement berasal dari akun masing-masing. Setelah cocok, gabungkan PPh pada level NIK atau NPWP untuk melihat total pelunasan atau kredit pajak.
Urutannya penting. Jika langsung menjumlahkan PPh empat toko, selisih kecil di satu akun akan tersembunyi oleh total besar. Rekonsiliasi per toko menunjukkan transaksi hilang, refund belum terkoreksi, atau identitas berbeda. Konsolidasi per subjek kemudian menunjukkan posisi pajak keseluruhan.
Gunakan daftar dokumen yang belum lengkap. Satu baris PPh tanpa nomor atau file dokumen jangan langsung dianggap siap digunakan. Beri status “menunggu dokumen”, “sesuai”, “dikoreksi”, atau “perlu tindak lanjut”.
Siapa mengerjakan apa?
Admin toko bertanggung jawab menjaga identitas akun, mengunduh data, dan memberi konteks promo atau refund. Finance menormalisasi transaksi, memisahkan biaya, serta mencocokkan settlement dengan bank. Tim pajak menentukan dasar, perlakuan PPh, dan konsolidasi per NIK atau NPWP. Owner menyetujui struktur kepemilikan serta kanal yang masuk.
Pada usaha kecil, satu orang dapat memakai empat topi tersebut. Tetap lakukan secara berurutan dan beri jejak tinjauan. Data mentah tidak boleh diubah ketika sedang menilai pajak.
Hasil akhir yang layak dipercaya
Konsolidasi berhasil bila satu transaksi hanya memiliki satu kunci, setiap perpindahan status memperbarui baris yang sama, refund tercatat sebagai koreksi, settlement dapat dijembatani ke bank, PPh dapat ditelusuri ke dokumen, dan seluruh toko berada di bawah subjek pajak yang tepat.
Empat toko bukan berarti empat batas omzet. Ia juga bukan alasan menjumlahkan setiap angka yang muncul di empat dashboard. Yang dicari adalah satu gambaran usaha berdasarkan transaksi unik. Ketika tabel fakta itu sudah terbentuk, seller tidak hanya menghindari double count. Seller juga bisa melihat kapan omzet melewati batas, platform mana menghasilkan margin sehat, dokumen mana belum lengkap, dan berapa PPh yang benar-benar telah dipungut atas nama pihak yang benar.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Entitas: Pajak UMKM
- Entitas: Pajak E-Commerce
- Pertanyaan terkait: Konsultan Pajak untuk E-Commerce
- Pertanyaan terkait: Konsultan Pajak untuk UMKM
- Topik: Registrasi Wajib Pajak
- Evidence: Identity Source Map
- Artikel terkait: Seller dengan Omzet Kecil: Dokumen Apa yang Perlu Disiapkan agar Mekanisme Pemungutan Marketplace Tidak Membingungkan?
