Why are payroll systems so complex?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

People on the business side never seem to realize the true costs of complicated business rules.

I once thought payroll was simple too. It turns out that it is essentially complex, because of all the special deals and weird practices that have been set up over years of union negotiations and HR people with strange ideas.

For example, these are pretty accurate:

  • People in Dayton get paid differently from people anywhere else.
  • Ex-Jeep employees accrue certain benefits six months out of phase with everyone else – or is it a year?
  • There are five people whose union dues are different from anyone else. No, really.
  • There are about seven unions, each with different dues rules.
  • The UPGWA (you-pig-wa) United Plant Guard Workers of America have two tiers of workers, based on time of hire. The old guard (sorry) get a better deal than the new ones.
  • There are something like 5 different savings plans, with accounts before and after taxes, matched and unmatched, each with maximum and minimum contribution based on company and government policy.
  • Health insurance includes one of those menu deals where you can pick all kinds of combinations. And there’s FLEX, where they give you money you can use for all kinds of medical stuff.
  • The wage attachment system is a separate knowledge-based system that must be talked to over sockets.
  • The Human Resources information (wage base, hiring dates, etc) is a separate relational database that must be queried as the payroll runs.
  • There are several hundred unique transactions that can come into the system. Each must be done in order, and must be separately accounted for. They all can be wrong so each must have unique validation.
  • If the employee doesn’t get enough money to pay all his deductions (something we’ve all worried about as we look at the tax items), there is a special order in which things must be taken. Some are totally taken, some partially, some have to be skipped. There is no logic to this. The employee is last on this list, of course. I am not making this up.
  • Everything has to generate transactions for the general ledger. The general ledger keeps accounts completely differently from payroll, so they’re all special calculations.
  • There are approximately 3,000 unique fields of information produced for each paycheck, going downstream to various COBOL programs. Most of these fields are complex, i.e. they are some strange calculation like (base pay unless the guy is on sick leave, in which case it’s his number of children) (well, almost). They are variously output in EBCDIC, COMP-3, etc. The program runs on an ASCII machine.
  • There are approximately 50 states and 300 communities’ taxes to be dealt with, including reciprocity. (If you work in A and live in B, you can pay the lower of the two communities’ taxes. But if you live in B and work in A …).
  • There’s profit-sharing, which is calculated based on a formula made up days before the checks come out, and having little relationship to anything previously computed.
  • There’s the Disability program. After being sick for 3 days (when your pay comes from your normal account), you go on disability, where your pay continues but comes from another account. After N days you only get 60% of your pay, unless you come back and go out on a different disability. Payroll is never informed when someone comes back from disability until after at least one check has gone out based on the wrong account. So the payroll has to back out the figures from the disability account and apply them to the regular. Then it turns out the guy isn’t back after all.
  • Transfers to and from this payroll to one of the other six (6) occur at random. You have to accept whatever useless input they give you and simulate the guy being in your better payroll from the beginning. If he leaves, you have to pack up your info and stuff it into the few smashed-together fields the other old program wants. If the guy transfers back, they want to use any good data you may have but to simulate the rest.
  • Sometimes they get two copies of the same individual in the system for a while, sometimes in the same payroll, sometimes in different ones. You have to sort it out.
  • 2 paychecks, woohoo!

Post external references

  1. 1
    http://c2.com/cgi/wiki?WhyIsPayrollHard
Source