1 ポイント 投稿者 GN⁺ 2024-01-04 | 1件のコメント | WhatsAppで共有
  • カナダで外部の給与サービスを使わずに給与控除を自分で計算するには、CRA の Payroll Deductions Formulas にある CPP、EI、所得税の式を実装する必要がある
  • 2024年には Canada Pension Plan に基本・追加保険料だけでなく second additional premiums まで含まれるようになり、既存のスプレッドシートを最初から書き直す必要があった
  • CRA の文書では、値を計算する場所とそれを使う場所が前後に散らばっているため、まず計算項目を把握するために GraphViz の依存関係チャート を作成した
  • チャートは 2024年の “Year's Annual Maximum Pensionable Earnings” $73,200 のような入力値から “Total payroll deductions” までつながる79個のノードで構成されている
  • 式そのものは除外し、値どうしの依存関係だけを記録しており、コミッション従業員、CPP の加入・脱退者、Quebec・Nova Scotia・Yukon・Ontario の居住者は対象外とした

CRA の給与控除を自力で計算するときの複雑さ

  • Canada Revenue Agency は給与控除計算用の Payroll Deductions Formulas 文書を定期的に発行しており、現在は第119版まで出ている
  • この文書には CRA が徴収する給与控除の計算に必要な式がまとめられている
    • Canada Pension Plan
    • Employment Insurance
    • Income Tax
  • カナダで小規模事業を運営しながら外部の給与プロバイダーを使わないのであれば、これらの式を スプレッドシートに直接実装 する必要がある
  • 税制のほかの部分と同様に給与控除の計算もますます複雑になっており、2024年には CPP に second additional premiums が追加されたことでスプレッドシートの再作成が必要になった

GraphViz で整理した計算順序

  • CRA の文書は、どの値を先に計算すべきかを一目で追いにくい
    • 必要な値が使われる前後どちらにも計算式が現れることがあり、文書内を何度も行き来しなければならない
  • これを整理するために GraphViz で依存関係チャートを作成した
  • チャートには79個のノードがあり、代表的な流れは次のとおり
    • “Year's Annual Maximum Pensionable Earnings”: 2024課税年度時点で $73,200
    • 最終ノード: “Total payroll deductions”
  • チャートには式そのものは入れず、各値がどのほかの値に依存するかだけを記録している
  • 計算範囲を単純化するため、次のケースは除外した
    • コミッション従業員
    • Canada Pension Plan に加入または脱退する従業員
    • Quebec、Nova Scotia、Yukon、Ontario の居住者
  • 全体サイズの画像は payroll.png で提供されており、画像サイズは 5627x2033 である

1件のコメント

 
GN⁺ 2024-01-04
Hacker Newsの意見
  • 政府が公開された数式をコードの形で提供していないのは残念
    信頼して処理する方法は、CRAが提供するWebフォームを使うことだけだと理解している: https://www.canada.ca/en/revenue-agency/services/e-services/...
    手計算はつらく、ミスもしやすい

    • ドイツではかなり前から、少なくとも1970年代以来、給与計算用の標準フローチャートを名前付き変数と数式つきで公開している: https://www.bundesfinanzministerium.de/Content/DE/Downloads/...
    • 住宅ローン計算にも同じようなものがあればいいのにと思う
      たとえばTD Canadaは、各返済額のうちいくらが元本に充てられるのか毎回教えてくれない。自分で計算すると合っているように見えるのに、支払い後に銀行が表示する残高と数十ドルずれることがよくある
      カナダでは口座詳細や明細を取得するAPIすら使えないのももどかしい
    • 政府がコード形式の公開数式を出すべきだという意見にはまったく同意しない
      そうすると、できるだけ複雑にする手段を政府に渡すことになる。税金は、納税者が完全に理解できるほど単純であるべきだ
      政府が予算均衡に失敗したからといって、給与天引きのような基本的なことを把握するのにソフトウェアが必須になるのは不当だ
      手計算がつらくて誤りが多いなら、政府に手作業でも扱えるよう強制する法律がないことのほうが問題だ
    • フランスは税務向けに独自DSLまで作った: https://github.com/MLanguage/mlang
    • すべての法律はコードで表現されるべきだ
      そうすれば、互いに衝突したり一貫していなかったりする法律がどれほど多いか、すぐに明らかになるだろう
  • 税法を少しかじった立場からすると、税の複雑化の循環はだいたいこうだと思う
    税法が成立し、賢い会計士や税務弁護士が合法的に税を減らす方法を見つけ、税務当局がその抜け道をふさぐために規則を出す
    政権が変わると、票を集めたり景気を調整したりするために一部の税を下げたり控除を追加したりし、次の政権は政治的理由から前政権の政策を選別的に元に戻す
    国際課税になると、複数の管轄をまたぐ節税スキーム、多国籍企業を誘致するための各国のインセンティブ、OECDの標準化の試み、二国間租税条約まで加わる
    例: Double Irish With a Dutch Sandwich https://www.investopedia.com/terms/d/double-irish-with-a-dut...

    • この複雑さは税の抜け道をふさごうとして生まれたものではない。大半は政治家が名前を付けたがるから生じる
      カナダには昔から“personal amount”税額控除があったが、「最初の$Xの所得には課税しない」とはせず、最低税率 × $Xの非還付型税額控除として処理している
      その後、「高所得の上位1%減税は避けつつ personal amount を増やそう」となり、今では所得に応じて変わる personal amountができた
      BCの“BC Tax Reduction”も、おおむね$22k〜$36kの所得者に追加の税額控除を与える仕組みだ。どちらも単に税率区分で実装できたはずだが、有権者は新しい税率区分より“Tax Reduction”という名前のほうに反応する
    • 第1段階で単一税率にしてしまえば、こうした問題は防げる。すべてに同じように適用すればいい
      投資所得優遇、不動産優遇、法人優遇、洪水地帯に住む三本脚の妖精優遇のような例外をなくすべきだ
      そうすれば市場は人間の努力を最も価値のある仕事へ配分できる
      このテーマに浪費されている生産性はばかげている。何百万人もの人が複雑な謎を作り、解き、操作することに張り付いているのに、その複雑さが有益だという証拠はない
    • 明示的な例外、特定項目の指定、控除や税額控除を抜け道と呼ぶことには問題がある
      こうした項目は、課税を避けるために使うよう意図されていることが多い。団体・個人・組織は、自分たちが関心を持つ項目を例外・控除・税額控除として入れてもらうよう政府にロビー活動をする
      会計士や税務弁護士がそれを適切に活用するのは、「合法的に税を回避する」ことではなく、そもそも支払うべき税金ではなかったということだ
      法律に従って正確に owed tax だけを払うことを「抜け道で節税する」と呼ぶには、すべての所得は政府のものだという前提が必要になるが、その前提は受け入れられない
  • カナダで小さな給与処理会社を運営していたことがあり、全部Railsで作っていた
    ルールが変わるたびにCRAの計算機をスクレイピングして、複数の州と給与レンジについて計算し、その結果を rspec で出力するようにしていた
    そうすれば、規定を正しく反映しているか、ルールを見落としていないか、値の入力を誤っていないかをテストできた

  • 数年前にIRS向けに似たようなものを作ったことがある: https://nampas.github.io/tax-map/

    • 円形配置の有向グラフを指す呼び名があるのか気になる
      すべての辺が単方向なのか、それとも双方向の辺もあるのかも気になる。双方向はないことを願うが
  • こういう図表こそが給与処理プロバイダーが存在する理由だ
    関連記事は Bits About Moneyhttps://www.bitsaboutmoney.com/archive/payroll-providers-pow... を参照

    • それでも結局は数学であり、給与処理プロバイダーが提出した内容が正しいかを確認する標準も政府が検証している
      だとすれば、政府はその標準を提供できるはずだ
  • 投稿者に拍手
    ここまで来たら、CRA はすべての数式の参照実装を公開して、中小事業者が活用できるようにすべき

    • LibreOffice のスプレッドシートを公開してくれたら本当にありがたい
      公開しないとしても、せめて内部で作ってみてほしい。自分たちで文書を読まなければならないなら、文書もずっとよく書かれるようになるはず
    • なぜそんなことをする? 全部公開したら、みんながバグや問題を見つけてしまい、その対応を CRA がしなければならなくなる
      罰金で得ている収入もかなり失うかもしれない
      大学時代に寮監をしていて、「無料」の食事と住居を受けていたが、20歳で初めてカナダの税申告をしたときに約 $1,000 を過少申告した。米国市民として初めてカナダで税申告をした状況だった
      数年後に約 $5,500 の罰金が科され、パートタイムで働く大学生にはとてつもない額だった。BC が CRA の罰金をそのまま上乗せできることを、そのとき知った
      今思えば、その仕事はしないほうがよかったのかもしれない。カナダに住んでいた残りの期間は CPA を雇った
      比べてみると IRS は温かくて穏やかに見えるほどだ。少なくとも、ミスをした場合の罰金は過少申告額に比例する。超富裕層でなければの話だが
    • CRA はやらないだろう。明確な答えを提供する義務がない
    • 別の返信でこの Web フォームが挙げられていた: https://news.ycombinator.com/item?id=38843556
      ダウンロード可能なシートではなさそうだが、それでも何かはある
  • フランスでは、こうしたルールがウェブサイト、API、NPM パッケージ、そして https://publi.codes 言語のプリミティブなルールとして提供されている
    https://mon-entreprise.urssaf.fr/développeur

  • 「ケベック、ノバスコシア、ユーコン、オンタリオ居住者は除く」とは、実質的にカナダの 75% ということだ

    • 公平に言えば、ノバスコシア、ユーコン、オンタリオは、それぞれノードを数個追加するだけで済む
      単に自分が BC にいるので、そこまで気にしたくなかっただけ
      ケベックはまったく別問題だ。あそこは給与控除の計算がはるかに複雑だ
    • ケベックは実質的に別の国に近い
      QC にだけ適用される奇妙な人事ルールや要件が本当にたくさんある
  • 米国にいるが、こうしたことが私のLLCで従業員を雇っていない理由の半分くらいを占めていると断言できる。
    雇いたくても、実質的には会計士まで一緒に雇うようなものになる

    • リモートワークの流れを考えると、従業員を雇おうとしている州と会社が所在する州との関係を非常に重視すべき。
      本当に厄介な州もある。たとえばNJ、CA、NY、OH。
      ある州に登録すると、その従業員が別の職場へ去った後でも、その州が認識した各種のコンプライアンス不備によって会社が追跡対象になり続けることがある。
      たとえば、その州に従業員がいなくなったという届出をしなかったことを理由に高額の罰金を科されることもある。
      対応しやすかった州はID、TN、TXだった。
      一般的には、こうした理由から自分の州の従業員だけを雇うのがよい。本当に必要でなければ雇わない
    • 開発者を雇う、あるいは研究・実験に関わる人を雇うつもりなら、Section 174をよく理解しておくべき。
      開発者の費用を5年にわたって償却しなければならないため、高額の税額通知を受ける可能性がある。従業員でも契約者でも同じ。
      廃止されてほしいが、そうならないのなら、Senator Wydenの表現を借りれば「stupid」なのに誰もそんな条項が存在するとは思わないようなものだ。
      https://www.law.cornell.edu/uscode/text/26/174
      修正: 廃止はされないだろう。ただし、将来の特定日までは無視するようにする法律は作れるかもしれない。いったん帳簿に載ると、会計処理のため税法を取り除くのは非常に難しい
    • 他の返信が述べているように、給与処理会社が存在するのには理由があり、最近はコンプライアンス対応まで簡単にしてくれるサービスも多い。
      たとえば、私の知る中小規模企業の多くはGustoを使っている。契約者や従業員を追加しやすくしてくれるからだ。
      Gustoを特定して宣伝したいわけではなく、検索すれば競合サービスも多い。無料ではないが、SaaSモデルなので従業員1人あたりの料金から始められ、会社とともに拡張できる利点がある
    • 問題が追加コストから生じる会計上の複雑さではなく給与計算なら、国内雇用でもremote.comやdeel.comを通じて雇用できる。
      従業員が給与制であるか、独立契約者として働く場合に限る。ただしその場合、実際の従業員ではない。
      雇用代行業者は現地法への準拠を保証し、従業員の総コストにサービス手数料を上乗せして請求する形になる
    • 連邦および各州の機関に対して給与を計算し送金することが問題なら、それはまったく障壁である必要はない。
      従業員1人あたり月$30〜$50で計算と送金をしてくれる給与サービス会社は無数にある。通常の給与処理に会計士は必須ではない
  • これはソフトウェアかどうかに関係なく、どんなアルゴリズムが機能するのかを示している。
    望ましい、あるいは必要なものから始めて複雑さを積み増していくと、恣意的な結果を生み、部外者を発狂させ、呪文のように唱えると下級悪魔まで召喚できそうな大混乱に行き着く。
    解決策として真っ先に思い浮かぶのは、もちろんリファクタリングだ。政治家が選挙で約束し、ジュニア開発者が新しいコードベースに出会うと要求する、あの作業である。
    しかし実際にはほとんど実現しない。どの機能や複雑さが不要で、どれが意図されたものなのかを、誰も明確に見分けられないからだ。
    2つ目の解決策は、静的型付け言語や定理証明器のような、より形式的な枠組みできれいに実装することだ。だが、システム自体がすでに矛盾しているなら、この試みもよく失敗する。
    幸いにも、誰も「変な境界ケース」には気を配らず、誰かが100万ドルほど持ち逃げするまでそのまま放置される

    • 実際、CRAと最近の連邦政府はカナダの税制を簡素化しようとかなり努力してきた。今ではずっと単純になっている。もちろん、この給与まわりは例外だ。
      10〜15年前には、票を買うためのような各種の特別控除が山ほどあった。
      今では、自営業や海外投資のようなものがなく、一般的な給与所得者であれば、税申告は些細でほぼ自動化されている。
      上の図の複雑さの大半は、カナダが強い連邦制の国であり、州ごとに関連権限や例外があることによるものに見える。そこに連邦の雇用保険と年金制度まで加わる