canada payroll

[Adrien Monteleone]

AN additional problem is legal interpretation for even one jurisdiction not to mention hundreds of them. (once you start including cities and other localities)

It is not as simple as calculate deduct rate X for tax Y, even for say 2-3 rates or more per jurisdiction. Start adding in rules for personal exemptions, 401k and other benefits and this quickly grows into a monster.

Now take all of those rules—those are based in laws somewhere. You’ll need legal counsel to determine how to implement those, and that’s no guarantee someone relying on this code won’t run afoul of some law.

I’d suspect Intuit has a legal team and maybe even enrolled agents looking over the results of their code to determine if their payroll system will produce paychecks and reports that are legally compliant. Too many businesses rely on them not to. It would be wonderful to find that sort of support for an open source project, but I’m not going to hold my breath. Certainly, I doubt it would be a cost free project.

I work with a small business that pays about $250 a year for payroll service. They used to do it by hand. (well, they used an adding machine, but other than that, I mean really, by hand, not even a spreadsheet) That’s less than $5 a week (which for them is a pay period) to have the calculations done for them reliably and get an instant report so they can then file payroll taxes—it’s quite a bargain. What use to take someone 4 hours or so to do now takes 15 minutes. I pondered moving them to GnuCash and doing payroll in a spreadsheet when I moved their systems to Linux, but thought better of it when I considered the time it would take to research tax law changes periodically.

If someone had the seed money to float a company selling an open source package (well, selling the service of making sure it was legally compliant for all jurisdictions at all times) I’d be all for it. But you’d need a strategy for building a customer base quickly to cover the legal and accounting consulting costs on an ongoing basis and you’d need a competitive advantage over Intuit and many of the online players.

 
> On May 9, 2017, at 7:56 AM, Mike or Penny Novack <stepbystepfarm at dialup4less.com> wrote:
> 
> On 5/8/2017 10:24 PM, R. Victor Klassen wrote:
>> Having written a perl module that handles only a subset of the cases for only one jurisdiction, and knowing how complex they make it, I have no reason to believe no other jurisdiction is more complex yet,
>> and possibly in very different ways.  For a given jurisdiction, handling the year-to-year changes is <mostly> a matter of changing a few parameters.  Unless they change the laws in a way that forces the formulae to be changed, and not just the constants used as thresholds and multipliers.   For more than one jurisdiction, potentially very different from each other, to say that it would be a lot of work is to put it mildly.
>> 
>> R. Victor Klassen
>> rvklassen at gmail.com
>> 226-792-0733
> The real issue here is not how hard to do for ONE jurisdiction. The issue is the sheer number of different jurisdictions involved (for example, in the US one federal plus large number of states have state income tax and some cities do)
> 
> That is why usually "payroll" is handled not within the main bookkeeping package but as a separate system that feeds (interacts with) the main bookkeeping package.
> 
> And payroll is not the only such "subsystem" possible. IMHO the first step might be for gnucash to be modified so that it can send and receive batch feeds. THEN we look for teams to create the interacting "payroll", "inventory", "point of sales", etc. << these teams would start out with a defined interface for sending or receiving feeds >> Maybe we could even find a team to do the extra stuff an non-profit would like << unified statement, pledge accounting, etc. >>
> 
> Of course being able to send or receive batch feeds also solves some of the importing problems.
> 
> Michael D Novack
> 
> PS: It is MUCH harder to debug monolithic systems. Break things apart when possible to isolate problems.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.