Lima perusahaan dalam satu grup memakai satu shared service center. Tagihan tahunan pusat layanan Rp10 miliar. Cara paling cepat membaginya adalah Rp2 miliar per entitas.
Secara matematika, pembagiannya sempurna. Secara transfer pricing, belum tentu.
Shared service center lahir untuk efisiensi. Finance, HR, IT, procurement, legal operations, atau fungsi administratif tertentu dikonsolidasikan agar grup tidak membangun tim yang sama di setiap entitas. Model ini bisa sangat masuk akal secara bisnis. Tetapi ketika biayanya dialokasikan ke pihak afiliasi, ada dua pertanyaan yang tidak boleh tercampur: biaya apa yang memang layak dibebankan, dan bagaimana biaya tersebut seharusnya dibagi.
Pembagian rata langsung menjawab pertanyaan kedua sebelum pertanyaan pertama selesai.
Bersihkan cost pool lebih dulu
Bayangkan shared service center membukukan gaji staf, lisensi software, sewa kantor, biaya konsultan, perjalanan, biaya board meeting induk, dan proyek integrasi grup. Semua biaya dimasukkan ke satu cost pool lalu dialokasikan berdasarkan revenue.
Kelihatan praktis, tetapi cost pool semacam ini terlalu kasar.
PMK 172 Tahun 2023 mengatur tahapan pendahuluan untuk transaksi jasa afiliasi. Wajib pajak perlu membuktikan jasa benar-benar diberikan dan diperoleh, dibutuhkan penerima, serta memberikan manfaat ekonomis. Jasa itu juga harus bukan shareholder activity, bukan manfaat karena passive association, bukan duplikasi aktivitas penerima, dan bukan manfaat insidental.
Konsekuensinya, cost pool shared service center perlu dipilah sebelum dialokasikan.
Biaya yang murni untuk kepentingan pemegang saham atau entitas induk tidak semestinya disamarkan sebagai layanan kepada anak perusahaan. Biaya untuk rapat pemegang saham induk, penerbitan saham induk, kewajiban pelaporan induk, perlindungan kepemilikan modal induk, atau tata kelola grup secara keseluruhan termasuk contoh yang secara khusus disebut dalam PMK 172 terkait shareholder activity.
Kalau biaya seperti itu masuk ke pool dan dibagi ke anak perusahaan, masalahnya tidak diselesaikan dengan allocation key yang canggih. Pool-nya sendiri sudah perlu diperiksa.
Satu pusat layanan bisa memiliki banyak jenis jasa
Kesalahan berikutnya adalah memperlakukan shared service center seolah memberikan satu jasa tunggal.
Padahal dalam satu kantor bisa ada accounts payable processing, payroll support, cyber monitoring, procurement analytics, master data management, tax reporting support, dan legal contract administration.
Konsumsi setiap layanan berbeda.
Entitas dengan 1.000 pegawai mungkin sangat banyak memakai HR platform, tetapi hanya memiliki sedikit vendor. Entitas lain hanya punya 100 pegawai tetapi memproses ribuan invoice per bulan. Entitas ketiga hampir tidak memakai shared procurement karena pembeliannya dilakukan sendiri.
Jika seluruh cost pool dibagi berdasarkan revenue, hasilnya bisa terlihat rapi tetapi kehilangan hubungan dengan konsumsi jasa.
Karena itu, desain yang lebih defensible biasanya memisahkan cost pool berdasarkan service line sejauh datanya memungkinkan.
Allocation key bukan masalah selera
Dasar alokasi seharusnya memiliki hubungan ekonomis dengan manfaat atau konsumsi jasa.
Untuk payroll processing, jumlah karyawan atau slip gaji dapat relevan.
Untuk accounts payable, jumlah invoice atau transaksi dapat lebih mencerminkan volume kerja.
Untuk IT user support, jumlah user, device, atau ticket mungkin lebih masuk akal.
Untuk procurement, nilai pembelian, purchase order, atau aktivitas sourcing bisa dipertimbangkan.
Untuk legal contract support, jumlah kontrak atau jam kerja mungkin lebih representatif.
Ini bukan daftar wajib. Setiap grup dapat memiliki model berbeda. Yang perlu dijaga adalah logika antara biaya dan penerima manfaat.
Pembagian rata mungkin tetap wajar jika kelima entitas memang memiliki konsumsi yang kurang lebih sama. Namun kesimpulan itu harus datang dari fakta, bukan dari kenyamanan spreadsheet.
Direct charge dan indirect allocation jangan dicampur
Sebagian biaya dapat ditelusuri langsung ke satu entitas.
Jika tim shared service menghabiskan 120 jam untuk migrasi ERP perusahaan A, membagi biaya proyek tersebut ke semua entitas bisa sulit dijelaskan. Direct charge sering lebih mencerminkan transaksi aktual jika data tersedia.
Sebaliknya, biaya platform yang benar-benar digunakan bersama mungkin perlu dialokasikan.
Memisahkan direct charge dan indirect allocation membantu menjaga cost pool tetap bersih. Ini juga membuat penerima jasa memahami mengapa mereka membayar jumlah tertentu.
Kalau semua biaya dilempar ke satu formula, perusahaan kehilangan transparansi.
Benefit test tetap datang sebelum markup
Diskusi shared services sering cepat melompat ke pertanyaan, “Markup lima persen cukup tidak?”
Pertanyaan itu terlalu dini.
Sebelum menguji tingkat imbalan, perusahaan harus membuktikan bahwa jasa yang mendasari charge memang memenuhi tahapan pendahuluan. PMK 172 bahkan menyatakan bahwa jika transaksi tertentu tidak dapat dibuktikan melalui tahapan pendahuluan yang dipersyaratkan, transaksi tersebut tidak memenuhi Prinsip Kewajaran dan Kelaziman Usaha.
Untuk memperluas konteks pada bagian ini, lihat Pinjaman Antarperusahaan: Bunga Wajar Tidak Bisa Ditentukan dari Perasaan.
Jadi markup yang tampak rendah tidak menyelamatkan jasa yang keberadaan atau manfaatnya sendiri tidak dapat dibuktikan.
Setelah transaksi lolos, barulah perusahaan memilih metode penentuan harga transfer yang sesuai dengan karakter jasa, fungsi, aset, risiko, dan data pembanding yang tersedia. Untuk penyedia jasa yang tidak menanggung risiko bisnis signifikan dan tidak mempunyai kontribusi unik dan bernilai, metode biaya-plus termasuk metode yang secara regulasi dapat sesuai dalam kondisi tertentu.
Tetapi penerapan tetap harus berdasarkan analisis fakta, bukan aturan praktis universal.
Risiko duplikasi sering tersembunyi
Shared service center dapat membangun fungsi yang juga sudah ada di entitas lokal.
Contohnya, pusat regional memberikan “finance support”, sementara perusahaan Indonesia memiliki finance team penuh. Apakah ada duplikasi?
Belum tentu. Finance lokal mungkin menjalankan statutory accounting dan cash management, sedangkan shared service memproses invoice atau menjaga master data. Fungsi berbeda bisa hidup berdampingan.
Yang menjadi masalah adalah ketika tidak ada yang bisa membedakan pekerjaan mereka.
Cara mengujinya adalah membuat service map. Tulis aktivitas shared service di satu sisi dan aktivitas lokal di sisi lain. Tandai yang berbeda, saling melengkapi, dan berpotensi overlap.
Kalau overlap muncul, cari apakah ada alasan bisnis. Bisa jadi selama masa transisi memang ada pekerjaan paralel. Bisa jadi sistem lokal belum ditutup. Bisa jadi regional team hanya melakukan quality control.
Penjelasan seperti itu harus didukung bukti waktu dan fakta, bukan dibuat setelah pemeriksaan dimulai.
Perubahan bisnis harus mengubah alokasi
Allocation key yang masuk akal pada 2024 belum tentu masuk akal pada 2026.
Perusahaan bisa menjual satu unit bisnis, menambah ribuan pegawai, memindahkan sistem, mengotomasi proses, atau mengubah struktur procurement. Jika model alokasi tidak pernah direview, biaya dapat terus mengikuti struktur yang sudah tidak ada.
Karena itu shared service charge sebaiknya memiliki annual refresh.
Periksa service catalogue. Bersihkan cost pool. Bandingkan actual usage. Review allocation key. Rekonsiliasi dengan general ledger. Pastikan kontrak antarperusahaan masih menggambarkan layanan aktual.
Review ini bukan hanya pekerjaan tax. Finance, HR, IT, procurement, dan legal perlu ikut karena mereka memahami konsumsi jasa.
Dokumentasi harus dapat direkonsiliasi
Salah satu titik lemah yang sering muncul bukan di teori transfer pricing, tetapi di angka.
Cost pool dalam perhitungan regional tidak sama dengan general ledger. Total allocation tidak kembali ke angka awal. Ada biaya yang dialokasikan dua kali. Kurs berbeda dipakai di invoice dan working paper. Headcount menggunakan angka akhir tahun untuk layanan yang berubah setiap bulan.
Hal-hal seperti ini membuat model yang secara konsep baik menjadi sulit dipercaya.
Sebuah shared service allocation sebaiknya bisa ditelusuri dari biaya awal, proses cleansing, service pool, allocation key, porsi penerima, markup jika relevan, sampai invoice akhir. Jejak itu membuat analisis dapat direproduksi.
Threshold bukan izin untuk pembagian bebas
PMK 172 memiliki ambang tertentu untuk kewajiban menyelenggarakan dokumen induk dan dokumen lokal. Untuk transaksi afiliasi tahun sebelumnya, nilai lebih dari Rp5 miliar berlaku untuk masing-masing penyediaan jasa, pembayaran bunga, pemanfaatan barang tidak berwujud, atau transaksi afiliasi lainnya. Ada pula kriteria lain berdasarkan peredaran bruto dan lokasi pihak afiliasi.
Namun jika transaksi afiliasi berada di bawah threshold dokumentasi, Prinsip Kewajaran dan Kelaziman Usaha tetap harus diterapkan.
Jadi perusahaan tidak sebaiknya menggunakan threshold sebagai alasan untuk memilih allocation key sembarang.
Model yang kuat bisa dijelaskan ke orang operasional
Ada tes sederhana untuk menilai kualitas model shared service.
Tunjukkan tagihan kepada kepala fungsi penerima. Tanyakan apakah ia memahami layanan yang dibeli dan dasar pembagiannya.
Jika jawabannya, “Ini pokoknya charge dari regional,” modelnya terlalu jauh dari realitas operasional.
Shared service center yang sehat bukan sekadar mekanisme memindahkan biaya grup. Ia seharusnya merepresentasikan layanan yang nyata, berguna, dan dapat ditelusuri.
Biaya dibagi rata bisa benar. Revenue key bisa benar. Headcount bisa benar. Ticket count bisa benar. Tidak ada satu formula yang menang untuk semua situasi.
Yang menentukan kewajaran adalah hubungan antara aktivitas, manfaat, cost pool, dan dasar alokasi.
Begitu empat hal itu selaras, spreadsheet berhenti menjadi sekadar tabel pembagian. Ia berubah menjadi representasi ekonomi yang bisa dipahami oleh manajemen dan dipertanggungjawabkan dalam transfer pricing.
Perhatikan pula biaya teknologi yang menumpuk di shared service center. Lisensi enterprise, platform keamanan, cloud workspace, dan software regional sering dibeli terpusat lalu dialokasikan. Untuk biaya semacam ini, perusahaan perlu membedakan apakah pusat layanan benar-benar menyediakan jasa, hanya meneruskan biaya pihak ketiga, atau menggabungkan keduanya. Struktur faktanya dapat memengaruhi bagaimana charge dianalisis dan metode harga diterapkan.
Jangan mengasumsikan setiap rupiah dalam cost pool harus mendapat perlakuan yang sama. Ada biaya tenaga kerja internal, biaya vendor eksternal, biaya proyek khusus, dan biaya yang manfaatnya hanya untuk entitas tertentu. Memisahkan kategori tersebut membuat model lebih akurat dan memudahkan rekonsiliasi.
Governance juga perlu jelas. Siapa yang menyetujui service catalogue? Siapa menilai apakah layanan masih dibutuhkan? Siapa mereview allocation key? Siapa memastikan entitas penerima tidak membayar fungsi yang sudah dilakukan sendiri? Tanpa pemilik proses, model alokasi cenderung menjadi warisan spreadsheet yang diteruskan setiap tahun.
Perusahaan dapat menambahkan kontrol sederhana berupa review tahunan lintas fungsi. Minta setiap service owner mengonfirmasi layanan yang diterima, perubahan volume, indikator manfaat, dan apakah dasar alokasi masih representatif. Jika ada perubahan besar, dokumentasikan alasan sebelum invoice tahun berjalan selesai.
Shared service center seharusnya menghasilkan efisiensi. Jika perusahaan tidak mampu menjelaskan siapa menerima layanan apa dan mengapa ia membayar porsi tertentu, efisiensi operasional justru berubah menjadi risiko dokumentasi. Kewajaran tidak lahir dari formula yang sama untuk semua, tetapi dari formula yang mengikuti cara layanan benar-benar dikonsumsi.