1 poin oleh GN⁺ 2024-01-04 | 1 komentar | Bagikan ke WhatsApp
  • Untuk menghitung potongan gaji sendiri di Kanada tanpa menggunakan layanan penggajian eksternal, perlu menerapkan rumus CPP, EI, dan pajak penghasilan dari Payroll Deductions Formulas milik CRA
  • Pada 2024, Canada Pension Plan tidak hanya mencakup iuran dasar dan tambahan, tetapi juga second additional premiums, sehingga spreadsheet lama harus ditulis ulang dari awal
  • Dokumentasi CRA tersebar maju-mundur antara tempat nilai dihitung dan tempat nilai digunakan, jadi dibuat bagan dependensi GraphViz untuk mengetahui item mana yang harus dihitung terlebih dahulu
  • Bagan terdiri dari 79 node yang mengalir dari nilai input seperti “Year's Annual Maximum Pensionable Earnings” tahun 2024 sebesar $73,200 hingga “Total payroll deductions”
  • Rumusnya sendiri tidak disertakan; yang dicatat hanya hubungan dependensi antar nilai. Karyawan komisi, peserta yang masuk/keluar CPP, serta penduduk Quebec, Nova Scotia, Yukon, dan Ontario dikecualikan dari cakupan

Kompleksitas menghitung sendiri potongan gaji CRA

  • Canada Revenue Agency secara berkala menerbitkan dokumen Payroll Deductions Formulas untuk menghitung potongan gaji, dan saat ini sudah mencapai edisi ke-119
  • Dokumen ini berisi rumus yang diperlukan untuk menghitung potongan gaji yang dipungut CRA
    • Canada Pension Plan
    • Employment Insurance
    • Income Tax
  • Jika menjalankan usaha kecil di Kanada dan tidak ingin memakai penyedia penggajian eksternal, rumus-rumus ini harus diimplementasikan sendiri dalam spreadsheet
  • Seperti bagian lain dari sistem pajak, perhitungan potongan gaji juga makin kompleks. Pada 2024, CPP menambahkan second additional premiums, sehingga spreadsheet perlu ditulis ulang

Mengatur urutan perhitungan dengan GraphViz

  • Dokumentasi CRA sulit diikuti sekilas untuk mengetahui nilai mana yang harus dihitung terlebih dahulu
    • Nilai yang dibutuhkan bisa dihitung sebelum atau sesudah digunakan, sehingga pembaca harus bolak-balik di dalam dokumen
  • Untuk merapikannya, dibuat bagan dependensi dengan GraphViz
  • Bagan memiliki 79 node, dengan alur perwakilan sebagai berikut
    • “Year's Annual Maximum Pensionable Earnings”: $73,200 untuk tahun pajak 2024
    • Node akhir: “Total payroll deductions”
  • Bagan tidak memasukkan rumus itu sendiri, hanya mencatat setiap nilai bergantung pada nilai lain yang mana
  • Untuk menyederhanakan cakupan perhitungan, kasus berikut dikecualikan
    • Karyawan komisi
    • Karyawan yang masuk atau keluar dari Canada Pension Plan
    • Penduduk Quebec, Nova Scotia, Yukon, Ontario
  • Gambar ukuran penuh tersedia sebagai payroll.png, dengan ukuran gambar 5627x2033

1 komentar

 
GN⁺ 2024-01-04
Komentar Hacker News
  • Sayang pemerintah tidak menyediakan rumus terbuka dalam bentuk kode
    Setahu saya, satu-satunya cara untuk memprosesnya secara andal adalah memakai formulir web yang disediakan CRA: https://www.canada.ca/en/revenue-agency/services/e-services/...
    Menghitungnya manual itu menyakitkan dan mudah salah

    • Jerman sudah sejak lama, setidaknya sejak 1970-an, menerbitkan flowchart standar untuk perhitungan gaji dengan variabel dan rumus bernama: https://www.bundesfinanzministerium.de/Content/DE/Downloads/...
    • Saya berharap ada hal serupa untuk perhitungan KPR
      Misalnya TD Canada tidak memberi tahu berapa bagian dari setiap pembayaran yang masuk ke pokok. Saya rasa perhitungan saya sendiri sudah benar, tetapi setelah pembayaran, saldo yang ditampilkan bank sering berbeda puluhan dolar
      Di Kanada, juga menyebalkan karena tidak bisa memakai API untuk mengambil detail akun dan laporan rekening
    • Saya sama sekali tidak setuju bahwa pemerintah harus menerbitkan rumus terbuka dalam bentuk kode
      Itu sama saja menyerahkan kepada pemerintah alat untuk membuatnya serumit mungkin. Pajak seharusnya cukup sederhana untuk dipahami sepenuhnya oleh orang yang membayarnya
      Tidak adil jika kegagalan pemerintah menyeimbangkan anggaran membuat perangkat lunak menjadi wajib hanya untuk mengetahui hal mendasar seperti pemotongan gaji
      Jika perhitungan manual menyakitkan dan sering salah, masalah yang lebih besar adalah tidak adanya hukum yang memaksa pemerintah membuatnya tetap bisa dihitung dengan tangan
    • Prancis bahkan membuat DSL sendiri untuk pajak: https://github.com/MLanguage/mlang
    • Semua hukum harus diekspresikan sebagai kode
      Dengan begitu akan cepat terlihat berapa banyak hukum yang saling bertentangan atau tidak konsisten
  • Dari pengalaman saya sedikit menangani hukum pajak, siklus kompleksitas pajak kira-kira seperti ini
    Undang-undang pajak disahkan, akuntan dan pengacara pajak yang pintar menemukan cara mengurangi pajak secara legal, lalu otoritas pajak menerbitkan aturan untuk menutup celah itu
    Saat pemerintahan berganti, sebagian pajak diturunkan atau keringanan ditambahkan untuk meraih suara dan mengatur ekonomi, lalu pemerintahan berikutnya secara selektif membatalkan kebijakan pemerintahan sebelumnya karena alasan politik
    Jika menyangkut pajak internasional, ditambah lagi teknik penghematan pajak lintas yurisdiksi, insentif berbagai negara untuk menarik perusahaan multinasional, upaya standardisasi OECD, hingga perjanjian pajak bilateral
    Contoh: Double Irish With a Dutch Sandwich https://www.investopedia.com/terms/d/double-irish-with-a-dut...

    • Kompleksitas ini bukan muncul karena upaya menutup celah pajak. Sebagian besar muncul karena politisi suka memberi nama
      Di Kanada sudah lama ada kredit pajak “personal amount”, tetapi alih-alih mengatakan “penghasilan $X pertama tidak dikenai pajak”, itu diperlakukan sebagai kredit pajak yang tidak dapat dikembalikan sebesar tarif pajak minimum × $X
      Lalu ketika menjadi “mari naikkan personal amount sambil menghindari pemotongan pajak untuk 1% berpenghasilan tertinggi”, kini ada personal amount yang berubah sesuai penghasilan
      “BC Tax Reduction” di BC juga pada dasarnya adalah struktur yang memberi kredit pajak tambahan kepada orang berpenghasilan sekitar $22k–$36k. Keduanya sebenarnya bisa diimplementasikan sebagai bracket tarif pajak, tetapi pemilih lebih merespons nama “Tax Reduction” daripada bracket tarif baru
    • Jika pada langkah pertama berhenti di tarif tunggal, masalah seperti ini bisa dicegah. Terapkan saja secara sama untuk semuanya
      Pengecualian seperti perlakuan istimewa untuk pendapatan investasi, properti, perusahaan, atau peri berkaki tiga yang tinggal di daerah banjir harus dihapus
      Dengan begitu pasar bisa mengalokasikan upaya manusia ke pekerjaan yang paling bernilai
      Produktivitas yang terbuang untuk topik ini tidak masuk akal. Jutaan orang sibuk membuat, memecahkan, dan memanipulasi teka-teki rumit, padahal tidak ada bukti bahwa kompleksitas itu bermanfaat
    • Ada masalah dalam menyebut pengecualian eksplisit, penetapan item tertentu, deduksi, dan kredit pajak sebagai “celah
      Item-item seperti ini sering memang dimaksudkan untuk digunakan demi menghindari pajak. Kelompok, individu, dan organisasi melobi pemerintah agar hal yang mereka pedulikan dimasukkan sebagai pengecualian, deduksi, atau kredit pajak
      Ketika akuntan atau pengacara pajak memanfaatkannya dengan benar, itu bukan “menghindari pajak secara legal”; pajak itu memang sejak awal bukan pajak yang harus dibayar
      Jika membayar tepat owed tax sesuai hukum hendak disebut “menghindari pajak lewat celah”, maka harus diasumsikan bahwa semua penghasilan adalah milik pemerintah, dan asumsi itu tidak dapat diterima
  • Saya pernah menjalankan perusahaan pemrosesan gaji kecil di Kanada, dan semuanya dibuat dengan Rails
    Setiap kali aturan berubah, kami men-scrape kalkulator CRA untuk beberapa provinsi dan rentang gaji, lalu membuat hasilnya dicetak oleh rspec
    Dengan begitu kami bisa menguji apakah regulasi sudah tercermin dengan benar, dan apakah ada aturan yang terlewat atau nilai yang salah dimasukkan

  • Beberapa tahun lalu saya pernah membuat sesuatu yang mirip untuk IRS: https://nampas.github.io/tax-map/

    • Saya penasaran apakah ada istilah untuk graf berarah dengan tata letak melingkar
      Saya juga penasaran apakah semua edge satu arah, atau ada juga edge dua arah. Saya berharap tidak ada yang dua arah
  • Diagram seperti ini persis alasan penyedia pemrosesan gaji ada
    Untuk tulisan terkait, lihat https://www.bitsaboutmoney.com/archive/payroll-providers-pow... dari Bits About Money

    • Meski begitu, pada akhirnya ini tetap matematika, dan standardisasi untuk memastikan isi pengajuan penyedia pemrosesan gaji benar juga diverifikasi oleh pemerintah
      Kalau begitu, pemerintah seharusnya bisa menyediakan standar tersebut
  • Tepuk tangan untuk penulisnya
    Pada titik ini, CRA seharusnya memublikasikan implementasi referensi untuk semua rumus agar bisa dimanfaatkan oleh usaha kecil

    • Akan sangat bagus kalau mereka merilis spreadsheet LibreOffice
      Kalaupun tidak dipublikasikan, setidaknya akan bagus jika mereka membuatnya untuk penggunaan internal. Jika mereka sendiri harus membaca dokumennya, kemungkinan besar dokumentasinya juga akan ditulis jauh lebih baik
    • Mengapa mereka mau melakukan itu? Kalau semuanya dibuka, semua orang akan menemukan bug dan masalah, lalu CRA harus menanganinya
      Mereka juga bisa kehilangan banyak pemasukan dari denda
      Saat kuliah, saya menjadi pengawas asrama dan mendapat makan serta tempat tinggal “gratis”, lalu ketika pertama kali melaporkan pajak Kanada pada usia 20 tahun, saya kurang melaporkan sekitar $1.000. Saat itu saya warga negara AS yang pertama kali mengajukan laporan pajak Kanada
      Beberapa tahun kemudian saya kena denda sekitar $5.500, jumlah yang sangat besar bagi mahasiswa yang bekerja paruh waktu. Saat itulah saya tahu bahwa BC bisa menyamai denda CRA secara persis
      Kalau dipikir lagi, mungkin lebih baik saya tidak mengambil pekerjaan itu. Selama sisa masa tinggal saya di Kanada, saya menyewa CPA
      IRS terasa hangat dan nyaman kalau dibandingkan. Setidaknya kalau membuat kesalahan, dendanya proporsional terhadap jumlah yang kurang dilaporkan. Kecuali jika Anda superkaya
    • CRA tidak akan melakukannya. Mereka tidak berkewajiban memberikan jawaban yang jelas
    • Di balasan lain ada yang menunjuk ke formulir web ini: https://news.ycombinator.com/item?id=38843556
      Sepertinya bukan lembar yang bisa diunduh, tapi setidaknya ada sesuatu
  • Di Prancis, aturan semacam ini tersedia sebagai situs web, API, paket NPM, dan aturan mentah dalam bahasa https://publi.codes
    https://mon-entreprise.urssaf.fr/développeur

  • “Tidak termasuk penduduk Quebec, Nova Scotia, Yukon, dan Ontario” — itu pada dasarnya 75% Kanada

    • Agar adil, Nova Scotia, Yukon, dan Ontario masing-masing hanya perlu ditambah beberapa node lagi
      Saya kebetulan berada di BC, jadi tidak ingin repot mengurus sampai sejauh itu
      Quebec adalah persoalan yang sama sekali berbeda. Perhitungan potongan gaji di sana jauh lebih rumit
    • Quebec pada dasarnya hampir seperti negara tersendiri
      Ada banyak sekali aturan dan persyaratan HR aneh yang hanya berlaku di QC
  • Saya berada di AS, tetapi bisa mengatakan dengan pasti bahwa hal-hal seperti ini adalah kira-kira separuh alasan mengapa saya tidak merekrut karyawan di LLC saya
    Bahkan jika ingin merekrut, pada praktiknya itu seperti ikut merekrut akuntan juga

    • Dengan mempertimbangkan tren kerja jarak jauh, hubungan antara negara bagian tempat Anda ingin merekrut karyawan dan negara bagian tempat perusahaan berada harus dianggap sangat penting
      Beberapa negara bagian benar-benar merepotkan. Misalnya NJ, CA, NY, dan OH
      Jika mendaftar di suatu negara bagian, bahkan setelah karyawan itu pindah ke pekerjaan lain, perusahaan bisa terus menjadi target pelacakan karena berbagai ketidakpatuhan yang diakui negara bagian tersebut
      Misalnya, Anda bisa dikenai denda besar hanya karena tidak melaporkan bahwa tidak ada lagi karyawan di negara bagian itu
      Negara bagian yang enak diajak berurusan adalah ID, TN, dan TX
      Secara umum, karena alasan seperti ini, lebih baik hanya merekrut karyawan dari negara bagian sendiri. Kalau tidak benar-benar perlu, saya tidak akan merekrut
    • Jika berencana merekrut developer atau orang yang terlibat dalam riset/eksperimen, Anda harus benar-benar memahami Section 174
      Biaya developer harus diamortisasi selama 5 tahun, sehingga bisa menerima tagihan pajak yang besar. Ini berlaku baik untuk karyawan maupun kontraktor
      Akan bagus jika dicabut, tetapi kalau tidak, seperti kata Senator Wyden, pasal ini “stupid”, namun tidak ada yang menyangka pasal itu akan tetap ada
      https://www.law.cornell.edu/uscode/text/26/174
      Koreksi: sepertinya tidak akan dicabut. Namun undang-undang bisa dibuat agar pasal itu diabaikan hingga tanggal tertentu di masa depan. Begitu sudah masuk pembukuan, sangat sulit menghapus aturan pajak karena perlakuan akuntansinya
    • Seperti balasan lain, ada alasan mengapa perusahaan pemrosesan payroll itu ada, dan sekarang banyak layanan yang juga memudahkan kepatuhan regulasi
      Misalnya, banyak perusahaan kecil-menengah yang saya kenal memakai Gusto, karena memudahkan penambahan kontraktor atau karyawan
      Saya tidak bermaksud mempromosikan Gusto secara khusus; kalau dicari, ada banyak layanan pesaing. Memang tidak gratis, tetapi karena modelnya SaaS, biayanya dimulai per karyawan dan bisa berkembang bersama perusahaan
    • Jika masalahnya bukan kompleksitas akuntansi akibat biaya tambahan, melainkan perhitungan payroll, untuk perekrutan domestik pun Anda bisa merekrut melalui remote.com atau deel.com
      Ini terbatas pada kasus ketika pekerja digaji tetap atau bekerja sebagai kontraktor independen. Namun dalam kasus itu, mereka bukan karyawan Anda yang sebenarnya
      Employer of record memastikan kepatuhan terhadap hukum setempat, lalu menagih total biaya karyawan ditambah biaya layanan
    • Jika masalahnya adalah menghitung dan menyetor payroll ke lembaga federal dan tiap negara bagian, itu sama sekali tidak perlu menjadi hambatan
      Ada tak terhitung perusahaan layanan payroll yang akan menghitung dan menyetor dengan biaya $30–$50 per bulan per karyawan. Untuk pemrosesan payroll umum, akuntan tidak mutlak diperlukan
  • Ini menunjukkan cara kerja suatu algoritma, terlepas dari apakah itu software atau bukan
    Jika Anda mulai dari sesuatu yang diinginkan atau diperlukan lalu terus menambahkan kompleksitas, Anda akan berakhir dengan kekacauan yang menghasilkan keluaran arbitrer, membuat orang luar gila, dan jika dibaca seperti mantra bahkan bisa memanggil iblis rendahan
    Solusi yang jelas terpikir adalah refactoring. Pekerjaan yang dijanjikan politisi saat pemilu dan diminta developer junior ketika berhadapan dengan codebase baru
    Namun dalam praktiknya, itu hampir tidak pernah terjadi. Sebab tidak ada yang bisa membedakan dengan jelas fitur dan kompleksitas mana yang tidak perlu, dan mana yang memang disengaja
    Solusi kedua adalah mengimplementasikannya secara bersih dalam kerangka yang lebih formal, seperti bahasa bertipe statis atau theorem prover. Namun jika sistemnya sendiri sudah kontradiktif, upaya ini juga sering gagal
    Untungnya, tidak ada yang peduli pada “kasus pinggir yang aneh”, dan semuanya dibiarkan begitu saja sampai seseorang membawa kabur kira-kira satu juta dolar

    • Sebenarnya, CRA dan pemerintah federal belakangan ini sudah banyak berupaya menyederhanakan pajak Kanada. Sekarang jauh lebih sederhana. Tentu saja, bagian payroll ini pengecualian
      10–15 tahun lalu ada segunung kredit/potongan khusus untuk membeli suara
      Sekarang, jika Anda tidak punya wirausaha atau investasi luar negeri dan hanya karyawan bergaji biasa, pelaporan pajak itu sepele dan hampir otomatis
      Sebagian besar kompleksitas pada grafik di atas tampaknya karena Kanada adalah negara federal yang kuat, sehingga tiap provinsi punya kewenangan dan pengecualian terkait. Ditambah lagi ada asuransi ketenagakerjaan dan skema pensiun federal