Software Internal yang Dibangun Sendiri: Kapan Menjadi Aset untuk Pajak?

Tim teknologi membangun aplikasi internal selama 18 bulan.

Ada 12 developer.

Product manager.

Cloud infrastructure.

UI designer.

Konsultan keamanan.

Lisensi tool.

Biaya total proyek menurut management report Rp15 miliar.

Ketika sistem go live, CFO bertanya:

“Ini software asset untuk pajak atau seluruh biaya development bisa dibebankan?”

Jawaban tidak bisa diambil hanya dari istilah “dibangun sendiri”.

PMK 72 Tahun 2023 memberikan aturan khusus untuk pengeluaran memperoleh perangkat lunak.

Program Aplikasi Khusus yang dimiliki dan digunakan untuk mendapatkan, menagih, dan memelihara penghasilan serta mempunyai masa manfaat lebih dari satu tahun dibebankan melalui amortisasi harta tak berwujud Kelompok 1.

Kelompok 1 berarti masa manfaat empat tahun.

PMK 72 memberi contoh Program Aplikasi Khusus antara lain aplikasi bidang perbankan, pasar modal, perhotelan, rumah sakit, atau penerbangan.

Pada sisi lain, Program Aplikasi Umum yang dimiliki dan digunakan untuk 3M penghasilan dapat dibebankan sebagai biaya operasional rutin sesuai ketentuan, kecuali jika program umum tersebut termasuk dalam harga pembelian hardware, maka biayanya diperhitungkan dalam penyusutan hardware.

Perusahaan yang membangun software sendiri perlu menentukan dulu:

apa sebenarnya aset atau pengeluaran yang dihasilkan?

Jangan memulai dari total payroll tim IT.

Program Aplikasi Khusus berbeda dari Program Aplikasi Umum

Ini distinction utama PMK 72.

Program Aplikasi Khusus pada dasarnya merupakan software yang secara khusus digunakan untuk tujuan tertentu dan disebut dalam konteks aturan sebagai aset tak berwujud yang diamortisasi Kelompok 1 jika memenuhi syarat.

Program Aplikasi Umum memperoleh treatment berbeda.

Contoh aplikasi umum dapat dipahami dari karakter software yang digunakan secara luas untuk kebutuhan umum, sedangkan aplikasi khusus berkaitan dengan fungsi spesifik usaha.

Tax team harus membuat classification memo.

Internal ERP yang dikembangkan khusus untuk proses manufaktur perusahaan bisa mempunyai karakter berbeda dari pembelian office productivity software umum.

Fraud detection engine bank berbeda dari spreadsheet software.

Hospital information system khusus berbeda dari browser.

Jangan menggunakan satu akun “software expense” untuk semuanya.

Dibangun sendiri menambah kompleksitas cost

Kalau software dibeli dari vendor Rp10 miliar, acquisition cost relatif mudah dilihat.

Kalau dibuat sendiri, cost berasal dari banyak sumber.

Payroll developer.

Konsultan.

Cloud.

Testing.

License tool.

Design.

Security audit.

Project management.

Training.

Maintenance.

Bug fixing.

Tidak semua cost otomatis menjadi basis aset fiskal.

Perusahaan perlu membedakan expenditure yang benar-benar berkaitan dengan memperoleh atau membangun software dan expenditure operasional rutin.

PMK 72 memberikan treatment atas pengeluaran memperoleh perangkat lunak, tetapi tidak berarti seluruh payroll departemen IT otomatis dikapitalisasi.

Tax team harus melihat substansi masing-masing biaya dan dasar pembentukannya.

Buat project cost ledger.

Tanpa ledger, angka Rp15 miliar hanya perkiraan manajemen.

Project phase perlu dibedakan

Software development biasanya punya fase.

Research.

Feasibility.

Design.

Development.

Testing.

Implementation.

Go live.

Maintenance.

Enhancement.

Accounting standard dapat mempunyai aturan sendiri untuk kapitalisasi pada fase tertentu.

Fiskal perlu dianalisis berdasarkan pengeluaran yang membentuk atau meningkatkan Program Aplikasi Khusus dan ketentuan yang berlaku.

Jangan otomatis copy seluruh capitalization schedule accounting.

Tetapi accounting project phase tetap berguna sebagai evidence.

Tax team sebaiknya memahami kapan proyek berubah dari eksplorasi menjadi pembangunan aset yang identifiable.

Untuk memperluas konteks pada bagian ini, lihat Revaluasi Aset: Kapan Pilihan Akuntansi Bertemu Konsekuensi Pajak?.

Kalau setiap aktivitas dicampur, sulit menentukan basis.

Gunakan work breakdown structure.

Setiap cost center diberi project code.

Saat go live, project closeout menentukan final tax basis.

Masa manfaat lebih dari satu tahun adalah trigger penting

PMK 72 menyatakan Program Aplikasi Khusus yang mempunyai masa manfaat lebih dari satu tahun dan digunakan untuk 3M penghasilan diamortisasi dalam Kelompok 1.

Jadi software eksperimen yang hanya digunakan tiga bulan bisa mempunyai analisis berbeda dari core platform yang dipakai bertahun-tahun.

Perusahaan perlu mendokumentasikan expected use.

Business case.

Product roadmap.

Go live approval.

System owner.

Kalau tidak ada bukti software benar digunakan dalam operasi, tax position menjadi lemah.

Jangan hanya punya source code.

Buktikan asset digunakan untuk menghasilkan atau mendukung penghasilan.

Untuk aplikasi internal, hubungan 3M sering jelas, tetapi tetap dokumentasikan.

Go live penting untuk governance walaupun aturan amortisasi punya timing sendiri

PMK 72 secara umum mengatur amortisasi dimulai pada bulan dilakukannya pengeluaran, kecuali bidang usaha tertentu.

Untuk Program Aplikasi Khusus, pengeluaran memperoleh software diamortisasi dalam Kelompok 1.

Perusahaan perlu memahami timing berdasarkan ketentuan tersebut dan jangan otomatis menyamakan dengan accounting go live date.

Ini salah satu area di mana schedule komersial dan fiskal dapat berbeda.

Karena cost internal timbul bulanan selama 18 bulan, tax working paper perlu menelusuri kapan pengeluaran terjadi.

Jangan membuat satu tanggal perolehan Rp15 miliar di hari go live jika fakta dan aturan fiskal menunjukkan expenditure terjadi bertahap.

Untuk proyek material, buat monthly cost rollforward.

Tax team dapat menentukan amortisasi berdasarkan aturan yang berlaku atas masing-masing pengeluaran atau treatment yang dapat dipertanggungjawabkan.

Peningkatan kapasitas juga diatur

PMK 72 mengatur bahwa pengeluaran untuk meningkatkan kapasitas sumber daya Program Aplikasi Khusus ditambahkan ke nilai sisa buku fiskal Program Aplikasi Khusus.

Hasil penjumlahan kemudian diamortisasi dalam Kelompok 1 mulai bulan dilakukan peningkatan kapasitas.

Ini penting setelah go live.

Software tidak berhenti berkembang.

Versi 2.

AI module.

New payment engine.

Additional branch capability.

Mobile channel.

Jangan seluruh development berikutnya otomatis disebut maintenance.

Bedakan:

maintenance routine,
bug fixing,
dan capacity enhancement.

Jika expenditure benar meningkatkan kapasitas sumber daya aplikasi khusus, aturan peningkatan kapasitas perlu diterapkan.

Buat enhancement memo.

Jelaskan apa yang berubah.

Apa manfaat tambahan.

Berapa cost.

Kapan dilakukan.

SaaS internal customization bisa berbeda

Perusahaan memakai cloud ERP dari vendor.

Lalu internal team membuat customization Rp3 miliar.

Apakah seluruhnya software asset sendiri?

Tidak otomatis.

Lihat hak perusahaan.

Apakah customization menjadi milik perusahaan?

Apakah hanya configuration dalam platform vendor?

Apakah source code dimiliki vendor?

Apakah perusahaan mempunyai asset yang identifiable?

Apakah expenditure lebih dekat ke implementation service?

Contract dan IP terms sangat penting.

Internal development di atas SaaS bisa menghasilkan asset, service cost, atau kombinasi tergantung fakta.

Jangan menggunakan treatment yang sama dengan software yang seluruh source code dan haknya dimiliki perusahaan.

Tax dan legal harus membaca ownership.

Hak software menentukan apa yang sebenarnya diperoleh.

Cloud infrastructure jangan otomatis masuk basis software

Developer memakai cloud compute selama development.

Setelah go live, cloud terus dipakai untuk operasi.

Cost development dan cost operational perlu dibedakan.

Kalau seluruh AWS atau cloud bill dimasukkan ke project asset sampai kapan pun, basis software terus membesar tanpa kontrol.

Buat tagging.

Development environment.

Production environment.

Testing.

Shared service.

Hanya cost yang mempunyai basis jelas dikaitkan ke project yang dianalisis sebagai bagian perolehan atau peningkatan software.

Operational hosting setelah go live memiliki karakter berbeda.

Tax team perlu membedakan.

Automation tag di cloud account dapat membantu.

FinOps dan tax ternyata perlu berbicara.

Payroll internal paling membutuhkan policy

Pengeluaran tenaga kerja internal sering menjadi area paling sulit.

PMK 72 tidak mengatakan seluruh gaji developer otomatis masuk amortisasi software.

Perusahaan harus menilai dasar pengeluaran dan hubungan langsung dengan perolehan aset.

Untuk tax position material, dokumentasikan policy:

peran apa yang eligible,
fase proyek,
timesheet,
project allocation,
dan treatment.

Jangan kapitalisasi 100 persen gaji CTO hanya karena CTO ikut rapat proyek.

Jangan juga menganggap seluruh developer payroll pasti operational expense tanpa analisis.

Substansi pekerjaan perlu dilihat.

Kalau perusahaan memilih basis tertentu, konsistensi penting.

Audit trail harus dapat menunjukkan bagaimana angka cost dibentuk.

Tanpa timesheet atau allocation basis, angka internal cost mudah dipertanyakan.

Program aplikasi umum punya treatment lebih sederhana

PMK 72 menyatakan pengeluaran memperoleh dan meningkatkan kapasitas Program Aplikasi Umum yang dimiliki dan digunakan untuk 3M penghasilan diakui sebagai biaya operasional rutin yang dibebankan sekaligus pada tahun bersangkutan.

Jika Program Aplikasi Umum termasuk dalam harga pembelian perangkat keras, biaya tersebut diperhitungkan dalam penyusutan hardware.

Ini membuat classification sangat penting.

Contoh pembelian operating system bundled dalam laptop bisa mengikuti hardware jika termasuk harga pembelian.

Pembelian aplikasi umum terpisah bisa mempunyai treatment biaya operasional sesuai ketentuan tersebut.

Jangan menganggap semua software empat tahun.

PMK 72 justru membedakan aplikasi khusus dan umum.

Tax software register harus mempunyai field:

general atau special.

Buat software asset register terpisah

Kolom minimum:

nama aplikasi,
owner,
purpose,
special atau general,
development model,
IP ownership,
project start,
cost by period,
go live,
tax treatment,
fiscal group,
remaining value,
enhancement history,
dan retirement date.

Untuk aplikasi internal, tambahkan:

repository reference,
business case,
dan project code.

Ini membantu ketika software dihentikan.

Aplikasi bisa obsolete sebelum amortisasi fiskal selesai.

Tax team perlu tahu kapan benar-benar ditarik.

Jangan hanya menonaktifkan server.

Dokumentasikan retirement.

Kalau source code masih dipakai untuk produk lain, situasinya berbeda dari software yang sepenuhnya dihapus.

Internal software adalah asset governance issue

Pertanyaan “aset atau biaya?” seharusnya tidak muncul pertama kali di akhir tahun.

Masukkan tax classification ke project governance.

Ketika project disetujui:

tentukan kemungkinan treatment.

Ketika cost terjadi:

tag.

Ketika scope berubah:

review.

Ketika go live:

closeout.

Ketika enhancement:

update basis.

Ketika retired:

close tax register.

Dengan lifecycle seperti itu, pajak mengikuti project.

Bukan mengejar setelahnya.

Kapan software internal menjadi aset untuk pajak?

Ketika pengeluaran menghasilkan Program Aplikasi Khusus yang memenuhi karakter harta tak berwujud dalam PMK 72, dimiliki dan digunakan untuk mendapatkan, menagih, atau memelihara penghasilan, dan mempunyai masa manfaat lebih dari satu tahun, pengeluaran untuk memperolehnya masuk mekanisme amortisasi Kelompok 1 sesuai ketentuan.

Tetapi total cost tidak boleh ditebak.

Bedakan software khusus dan umum.

Bedakan development dan maintenance.

Bedakan owned software dan SaaS configuration.

Bedakan cost proyek dan operational cloud.

Baca IP ownership.

Bangun audit trail.

Software boleh tidak terlihat secara fisik.

Tax basis-nya harus sangat terlihat.

Leave a Comment

Your email address will not be published. Required fields are marked *