Perusahaan Indonesia membayar USD 250.000 kepada vendor asing untuk software yang dipakai selama satu tahun. Kontrak memakai istilah “license”. Procurement menyebutnya subscription. User internal merasa hanya membeli akses.
Tax harus menjawab pertanyaan yang lebih sulit: apakah pembayaran tersebut merupakan royalti, jasa, business profits, atau kombinasi beberapa unsur?
Dalam transaksi software lintas negara, nama produk hampir tidak pernah cukup.
Klasifikasi menentukan apakah PPh Pasal 26 berlaku berdasarkan hukum domestik, pasal mana dalam Persetujuan Penghindaran Pajak Berganda yang harus dibaca, apakah beneficial owner menjadi syarat, serta berapa tarif yang dapat digunakan.
Karena itu, satu kata “license” dapat memulai analisis, tetapi tidak boleh menjadi kesimpulan.
Mulai dari hak yang diterima pengguna
Software dapat diberikan dalam banyak model.
Perusahaan bisa membeli salinan standar untuk dipakai internal. Bisa memperoleh hak memperbanyak dan mendistribusikan. Bisa mendapat hak memodifikasi source code. Bisa hanya mengakses aplikasi berbasis cloud tanpa menerima software secara lokal. Bisa juga membeli paket yang mencakup implementasi, maintenance, support, data, dan hak intellectual property.
Perbedaan hak tersebut penting.
UU PPh memasukkan royalti sebagai salah satu jenis penghasilan. Dalam konteks pembayaran kepada WPLN, PPh Pasal 26 dapat relevan atas royalti berdasarkan ketentuan domestik.
Namun ketika P3B tersedia, definisi royalti dalam treaty harus dibaca secara spesifik.
Tidak semua treaty menggunakan rumusan identik, dan tidak semua transaksi software memiliki karakter yang sama.
Copyright dan copyrighted article perlu dibedakan secara konseptual
Salah satu sumber perdebatan klasik dalam software taxation adalah apakah pembayaran dilakukan untuk hak atas copyright atau hanya untuk memperoleh produk yang dilindungi copyright.
Bayangkan perusahaan membeli 500 user license software standar. Pengguna boleh menginstal dan menjalankan aplikasi untuk kebutuhan internal, tetapi tidak boleh memperbanyak untuk dijual, mendistribusikan ke publik, atau mengeksploitasi copyright secara komersial.
Fakta itu berbeda dari perusahaan yang memperoleh hak menggandakan software, membuat derivative product, lalu menjualnya ke pelanggan.
Dari perspektif treaty, pembedaan hak dapat memengaruhi apakah pembayaran lebih dekat ke royalti atau business profits, tergantung definisi P3B dan ketentuan yang berlaku.
Karena itu, tax perlu membaca End User License Agreement, bukan hanya invoice.
SaaS membuat batas semakin rumit
Dalam model Software as a Service, pelanggan sering tidak menerima copy software dalam arti tradisional.
User login ke platform vendor dan menggunakan fungsi aplikasi melalui internet.
Apakah pembayaran SaaS selalu jasa? Tidak aman menyimpulkan demikian.
Apakah selalu royalti karena software dilindungi copyright? Juga tidak aman.
Perlu dibaca apa hak yang diberikan, apakah ada penggunaan intellectual property, apakah payment mencakup hosting, data processing, support, customization, atau komponen lain, serta bagaimana hukum domestik dan treaty mengklasifikasikannya.
Model cloud modern membuat deskripsi “software license” sering terlalu kasar.
P3B dapat menghasilkan posisi berbeda dari hukum domestik
Hukum Indonesia memberikan definisi dan perlakuan domestik atas royalti.
Tetapi jika penerima penghasilan merupakan residen negara mitra P3B dan memenuhi syarat, treaty dapat membatasi hak pemajakan Indonesia atau tarif yang dapat dikenakan.
Karena itu, analisis harus berjalan dua tahap.
Pertama, klasifikasikan pembayaran menurut hukum domestik.
Kedua, baca definisi royalti dan pasal lain dalam treaty yang relevan.
Jangan langsung mengambil tarif treaty dari tabel negara tanpa memastikan pembayaran memang masuk pasal tersebut.
Form DGT tetap menjadi syarat administrasi penting
Sejak PMK 112 Tahun 2025, penerapan P3B menggunakan Formulir DGT sebagaimana diatur dalam regulasi tersebut, dengan administrasi melalui Coretax DJP.
Jika vendor software ingin memperoleh manfaat treaty, perusahaan Indonesia perlu memastikan dokumen itu tersedia dan sesuai periode.
Vendor global sering memiliki banyak contracting entity.
Tahun pertama invoice datang dari entity Singapura. Tahun berikutnya kontrak dipindahkan ke entity Irlandia. Jika finance tetap memakai treaty rate lama karena nama produk sama, hasilnya bisa salah.
Treaty mengikuti legal recipient dan tax residence, bukan merek software.
Beneficial owner juga dapat muncul
Pasal royalti dalam banyak treaty mensyaratkan penerima merupakan beneficial owner untuk memperoleh batas tarif tertentu.
Dalam grup teknologi, IP owner, billing entity, distributor, dan service entity dapat berbeda.
Invoice mungkin diterbitkan distributor regional yang kemudian membayar sebagian besar amount ke IP owner.
Apakah distributor tetap beneficial owner atas seluruh pembayaran? Jawabannya bergantung pada fakta, hak kontraktual, fungsi, risiko, dan ketentuan treaty.
Perusahaan Indonesia perlu memahami setidaknya struktur dasar.
Tidak realistis meminta seluruh corporate secret vendor global, tetapi untuk pembayaran material, informasi mengenai contracting entity dan kapasitasnya sebagai penerima penghasilan perlu cukup jelas.
Kontrak campuran sebaiknya tidak dipaksa menjadi satu kategori
Paket software sering terdiri dari beberapa komponen.
Lisensi inti, implementation service, migration, training, maintenance, premium support, API usage, data storage, dan consulting bisa berada dalam satu kontrak.
Jika setiap komponen mempunyai substansi yang berbeda, tax perlu menilai apakah pemisahan masuk akal dan didukung harga.
Tujuannya bukan mencari komponen dengan tarif terendah.
Tujuannya mencerminkan transaksi sebenarnya.
Jika seluruh harga merupakan satu paket yang tidak dapat dipisahkan secara ekonomis, pemecahan artifisial justru dapat menambah risiko.
Tetapi jika vendor sendiri memberi line item dan deliverable terpisah, mengabaikan perbedaan juga bisa keliru.
Implementation service bukan otomatis bagian dari royalti
Vendor dapat mengirim engineer untuk mengonfigurasi software di Indonesia.
Biaya implementasi perlu dibaca dari scope.
Apakah engineer hanya membantu setup? Apakah ia mengembangkan modul khusus? Apakah hasil development memberikan hak IP tertentu? Apakah personel berada cukup lama untuk memunculkan risiko permanent establishment?
Pembayaran implementasi dapat mempunyai analisis berbeda dari subscription fee.
Jika vendor hadir secara fisik di Indonesia, tax team juga harus mengecek P3B terkait business profits, service PE, atau ketentuan lain yang relevan.
Satu kontrak teknologi dapat memunculkan beberapa pasal treaty.
Maintenance juga perlu dibedakan
Maintenance dapat berarti sekadar hak memperoleh update software.
Bisa juga berarti layanan teknis aktif, troubleshooting, dedicated engineer, atau upgrade khusus.
Deskripsi invoice “annual maintenance” tidak menjelaskan cukup banyak.
Tax sebaiknya meminta service description yang dapat dipahami tanpa menjadi software engineer.
Siapa melakukan apa, dari mana, dengan deliverable apa, dan hak apa yang diterima pelanggan?
Pertanyaan sederhana itu sering lebih berguna daripada nama marketing produk.
PPN berjalan pada jalur yang berbeda
Selain PPh, penggunaan software atau jasa digital dari luar negeri juga dapat menimbulkan PPN Indonesia.
Untuk pelaku PMSE yang telah ditunjuk, PPN dapat dipungut oleh Pemungut PPN PMSE.
Dalam transaksi lain, pemanfaatan Barang Kena Pajak tidak berwujud atau Jasa Kena Pajak dari luar Daerah Pabean di dalam Daerah Pabean perlu dianalisis berdasarkan mekanisme PPN yang berlaku.
Fakta bahwa vendor sudah menagih PPN Indonesia tidak otomatis menentukan klasifikasi PPh.
PPN dan PPh menjawab pertanyaan berbeda.
Finance perlu menghindari logika “sudah ada pajak di invoice, berarti selesai”.
Bukti penggunaan software perlu disimpan
Saat pemeriksaan, tax team mungkin diminta menjelaskan apa yang dibeli tiga tahun sebelumnya.
Pada saat itu procurement manager sudah pindah, vendor portal sudah berubah, dan link ke terms of service lama sudah tidak aktif.
Karena itu, simpan snapshot kontrak dan terms yang berlaku pada periode pembelian.
Dokumen penting meliputi master agreement, order form, EULA, product description, user rights, invoice, purchase order, korespondensi scope, dan bukti pembayaran.
Untuk transaksi material, buat memo satu atau dua halaman yang menjelaskan klasifikasi pajak.
Memo tersebut jauh lebih murah dibanding merekonstruksi transaksi setelah pemeriksaan dimulai.
Standardisasi tax code harus hati-hati
ERP sering memaksa tim memilih satu tax code berdasarkan vendor atau expense account.
Ini praktis, tetapi software vendor dapat menjual beberapa produk dengan karakter berbeda.
Satu invoice untuk SaaS standar. Invoice lain untuk consulting. Invoice berikutnya untuk data license.
Jika seluruh transaksi otomatis memakai tax code “software royalty”, kontrol sistem justru menciptakan kesalahan berulang.
Lebih baik mapping dilakukan berdasarkan payment category dan contract type.
Automation harus mengikuti analisis, bukan menggantikannya.
Tax treaty memo perlu diperbarui ketika produk berubah
Produk teknologi berevolusi cepat.
Vendor yang semula menjual on-premise license dapat beralih ke cloud subscription. Perusahaan yang dulu membeli software kini membeli AI API. Hak akses yang dulu terbatas bisa berkembang menjadi hak mengintegrasikan, melatih model, atau menggunakan output tertentu.
Perubahan model bisnis bisa mengubah analisis pajak.
Karena itu, tax memo lama tidak boleh dianggap berlaku selamanya.
Renewal kontrak harus menjadi trigger untuk review singkat: apakah contracting entity berubah, apakah rights berubah, apakah pricing structure berubah, dan apakah treaty masih sama?
Mengapa perdebatan klasifikasi terus terjadi?
Karena software bukan satu jenis transaksi.
Ia bisa menjadi produk, hak kekayaan intelektual, layanan, infrastruktur, data processing, atau kombinasi semuanya.
Hukum pajak kemudian mencoba mengklasifikasikan pembayaran berdasarkan substansi dan definisi yang kadang berasal dari era teknologi berbeda.
P3B menambah lapisan karena definisi royalti berbeda antarnegara dan antarversi treaty.
Tidak mengherankan jika dua transaksi yang sama-sama disebut software license dapat menghasilkan analisis berbeda.
Cara yang lebih aman adalah mulai dari kontrak, bukan tarif.
Identifikasi legal recipient dan tax residence. Petakan rights yang diberikan. Pisahkan komponen jika substansinya memang berbeda. Tentukan klasifikasi domestik. Baca definisi treaty. Periksa Form DGT dan beneficial owner bila relevan. Cek kehadiran vendor di Indonesia. Setelah itu baru tentukan withholding.
Dalam software taxation, nama produk adalah petunjuk.
Hak yang sebenarnya diperoleh pelanggan adalah bukti yang jauh lebih penting.
Data license menambah satu variasi lagi. Perusahaan dapat membayar akses database, market data, geospatial data, atau model data yang disediakan bersama software. Hak pelanggan mungkin hanya melihat data, mengunduh sebagian, menggunakan untuk analisis internal, atau justru mengintegrasikan dan mendistribusikannya dalam produk sendiri. Hak atas data tersebut perlu dibaca terpisah dari fungsi software jika kontraknya memang membedakan.
Begitu juga dengan API. Pembayaran berdasarkan jumlah request dapat terlihat seperti service fee, tetapi terms dapat memberi hak lain atas software, model, atau dataset. Tax team tidak harus memahami arsitektur teknis secara penuh, namun perlu meminta product owner menjelaskan apa yang diperoleh perusahaan dalam bahasa bisnis: akses, copy, hak modifikasi, hak distribusi, compute, atau hasil layanan.