Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Canadian payroll dependency chart

daemonology.net

Post reply on HN
Print view View original

231–240 of 301 posts

Re: A Canadian payroll dependency chart

#231

Post by phpisthebest »

narrator wrote: post #18

Being someone who has some experience with tax law, the cycle of tax complexity goes like this: 1. Tax law is passed. 2. Really smart CPAs and Tax Lawyers figure out ways to legally avoid paying taxes. 3. Tax people issue regulations intended to close those loopholes. 4. Administrations change and they want to win votes and tweak the economy so they lower some taxes and add tax breaks. 5. New administration comes in…

I have a problem with calling explicit exemptions, call outs, and other things as "loop holes" as if they were no intended to be used to avoid taxation.

This is simply incorrect, organizations, people, and groups all lobby the government to include their pet line item as an exemption, deduction, or credit.

These are not "loop holes" and a CPA or tax lawyer having the knowledge to fully utilize all of them is not " legally avoid paying taxes" as those taxes where not owed in the first place.

In order to get to the point where paying the correct amount of taxes you owe by law is "using loophole to avoid taxes" one has to assume 100% of all income is belongs to the government and we are just figuring out how much the government is going to allow us to keep. I reject that

Re: A Canadian payroll dependency chart

#232

Post by crote »

phpisthebest wrote: post #230
ibejoeb wrote: post #224

Earlier quoted context omitted.

I don't understand what you mean. You're beholden to the law regardless of whether you understand it. The government ought to be required to create a reference implementation if for no purpose other than to prove that it is indeed possible to implement.

the government should be barred from implementing a law or regulation that requires "reference implementation " to prove it is "possible to implement" If it needs such a thing it is too complex and should be repealed

Over in The Netherlands we're seeing the opposite happen. Seemingly trivial laws are getting rejected because the responsible Ministry considers it "too difficult". In reality it's most likely just politically inconvenient.

For example, it was deemed "impossible" to adjust student loan interest rates, because the software would take two years to modify. Either they are completely incompetent, or they are deliberately lying for political reasons.

So yeah, refusing a law because it is "too complex" won't work either.

Re: A Canadian payroll dependency chart

#233

Post by ibejoeb »

phpisthebest wrote: post #230
ibejoeb wrote: post #224

Earlier quoted context omitted.

I don't understand what you mean. You're beholden to the law regardless of whether you understand it. The government ought to be required to create a reference implementation if for no purpose other than to prove that it is indeed possible to implement.

the government should be barred from implementing a law or regulation that requires "reference implementation " to prove it is "possible to implement" If it needs such a thing it is too complex and should be repealed

OK, well, in spirit I can see how that sentiment arises. For practical purposes, though, no matter how simple a calculation, if a government requires that I do it, I want to see precisely what it's demanding. It is unreasonable to be put in the position of guessing.

Re: A Canadian payroll dependency chart

#234

Post by cmrdporcupine »

switchbak wrote: post #113
cmrdporcupine wrote: post #52

Earlier quoted context omitted.

In actuality the CRA and recent federal gov'ts have done a lot to simplify taxes in Canada. It's way simpler these days. Though obviously this payroll stuff is an exception. 10-15 years ago there were piles of special exemptions carved out for all sorts of things (mostly to buy votes.) These days, if you don't have self-employment or foreign investments, etc and are just the typical paycheque-receiving wage slave, fi…

"trivial and mostly automatic" - but not so automatic that it's done for you, as in some other countries. And that's by design - Intuit still wants their cash cow providing that sweet sweet revenue every tax season.

I don't see how Intuit has any pull on Canadian tax law or influence with the CRA. And there are plenty of alternatives. I used ufile.ca for years, way cheaper. And honestly, just picking up the form and doing it yourself is all my parents did for years.

I'm pretty sure we'll see what you're asking for within the next 5-10 years. With them already having the T4s, etc. I don't see why they couldn't have you login to their site, confirm everything, and submit.

Re: A Canadian payroll dependency chart

#235

Post by neilv »

cdcarter wrote: post #123
neilv wrote: post #118

Several years ago, I worked through my US IRS tax return forms by coding the data and calculations in Scheme. The representation ended up being that each form line value was a Scheme procedure that called other such procedures, which was one way to enforce dependencies. (Fortunately, there were no cycles in the dependencies, like the article author found in their CRA payroll deductions work.) I don't have the code ha…

Did you take advantage of the homoiconicity of scheme to make this happen?

In this case, I was first seeing what could be done with basic Scheme algorithmic programming language mechanisms (e.g., using procedures and the magic of toplevel definitions).

Then, after seeing how tax form logic ended up that way, one direction would be to define a DSL that makes that easier to work with. For example, if we find everything can be implemented as these procedures, or with maybe with an additional concept (such as to handle cycles like in the article), a simple first step DSL might be another s-expression language that has magic variables that are more akin to spreadsheet cell references, in that the dependencies are evaluated in order. And it might also do things like populate a hashtable with the cached values for application use (e.g., PDF form-filling). That DSL might be implemented as a simple `syntax-case` or `syntax-parse` transformer. If that works and could, we could optimally make it more palatable/marketable/politic by defining a keywords-and-whitespace grammar that parses by transforming those syntax objects to syntax objects in our intermediate s-expression DSL (which transforms to the basic Scheme code approach we worked out originally).

There are other valid ways (say, you want tax law logic to be definable dynamically at run time). Though some involve `eval`, which I discourage. https://lists.racket-lang.org/users/archive/2014-July/063597...

Re: A Canadian payroll dependency chart

#236

Post by Joel_Mckay »

Doing your own taxes is like doing your own dental work.

You will never be able to keep up with the legal, bureaucratic, and financial changes. Whatever a local competent accounting firm charges, they will almost always recover their cost in a commercial return.

If you have under 12 employees, than ADP payroll can work in some situation.

Re: A Canadian payroll dependency chart

#237

Post by cperciva »

MichaelZuo wrote: post #211
burnished wrote: post #204

Earlier quoted context omitted.

Yes, you'd call that the calendar convention if I remember correctly. The one you are referencing is called 30/360 for 30 days in a month, 360 days in a year.

Would different departments within a bank use different calendar conventions?

Absolutely. Even within one department, since accounts often originated from different institutions.

Re: A Canadian payroll dependency chart

#238

Post by jacobr1 »

woodruffw wrote: post #90
jacobr1 wrote: post #47

Earlier quoted context omitted.

Aren't most the contradictions forms of ambiguity? Two overlapping scenarios where some sort of administrative ruling is needed to clarify which dominates. Does that count as contradiction? https://www.irs.gov/irb is full of this kind of stuff.

I don't think so, at least not in the logical sense (an ambiguity means that the terms need to be refined to produce a decision, whereas a contradiction means that no decision exists). (Maybe this distinction is silly, but I think it's important: ambiguity is inevitable, but asserting that the IRS knowingly maintains contradictory rules suggests some kind of sovereign-citizen-adjacent thinking.)

No, I was not proposing such situations are knowingly maintained, explicitly the opposite: there is a whole system to resolve them once discovered. Here is an example I found in the first bulletin I clicked on, but each one is full of examples like this: https://www.irs.gov/irb/2023-50_IRB

In this case, you have ambiguity in a definition of "partner assets and liability" in that, it could be read to include factor X and Not-X, and thus was contradictory. Resolving the definition to be more clear remove the problem inherent in rule.

> regulations provided that, in any taxable year, a partner’s share of each asset and liability of a section 987 aggregate partnership was proportional to the partner’s liquidation value percentage with respect to the aggregate partnership. A partner’s liquidation value percentage was defined as the ratio of the liquidation value of the partner’s interest in the partnership to the aggregate liquidation value of all the partners’ interests in the partnership.

> recommended that §1.987-7 be withdrawn and replaced with the approach of the 2006 proposed regulations under section 987, which provided that a partner’s share of assets and liabilities reflected on the books and records of an eligible QBU held indirectly through the partnership must be determined in a manner consistent with how the partners have agreed to share the economic benefits and burdens corresponding to those partnership assets and liabilities, taking into account the rules and principles of subchapter K. A comment indicated that the liquidation value percentage approach was inconsistent with certain principles of subchapter K, resulting in distortions in the calculation of section 987 gain or loss in certain cases.

So the prior guidance (in different documents, likely authored by different people) suggested two different mechanisms that are in conflict, resulting in different calculations. The latest guidance resolved this favor of an approach that clarifies what is actually allowed (In this case, rescinding the prior rule, but allowing either approach provided that approach was applied with internal consistency)

Re: A Canadian payroll dependency chart

#239

Post by CarRamrod »

cmrdporcupine wrote: post #190
p_j_w wrote: post #135

Earlier quoted context omitted.

>Carbon/emission considerations aside This seems like a massive thing to just throw aside.

He's also neglecting to mention what a mammoth hydroelectric powerhouse Quebec is, because of that, they have a giant surplus of electricity that makes their utility bills extremely cheap relative to anywhere else in North America, helps manufacturing businesses and gives them the ability to export power, to boot. Meanwhile Alberta burns (and leaks) natural gas and coal and gripes because the rest of the country is p…

Well, if Quebec is the economic powerhouse you claim it is, then surely they will be just fine if the equalization payments stop, right?

Re: A Canadian payroll dependency chart

#240

Post by woobar »

maelito wrote: post #9

In France, these rules are available as a website, an API, a NPM package, and raw rules in the https://publi.codes language. https://mon-entreprise.urssaf.fr/développeur

Is this a toy? I get this warning on the English version of that website:

"Calculations are indicative. They are not a substitute for actual statements from Urssaf, the tax authorities or any other organization."

[1] https://mycompanyinfrance.urssaf.fr/developer/iframe?module=...

Post reply on HN