Payroll Posting Strategies

Overview

Payroll entries update the General Ledger when Pay Period is posted. These postings are controlled or limited by posting codes assigned during the posting process. The posting codes are assigned to the transaction based on the General Ledger Posting Preferences definitions (GLUTSPPP). Posting Preferences are defined under subsystem and ledger. EP (Earnings Register), CP (Contributions Register) and DP (Deductions Register) and a specific ledger code. In these examples we will be using ledger GL.

There are also three General Ledger Subsystem Interface (GLUTSPSI) screens. They are GL / PY / EREG, GL / PY / CREG, and GL / PY/ DREG. Typically, hours post with the EREG, Contributions post with the CREG and Deductions post with the DREG. However, direct Contributions (" + " in Gross / " + " in Net) may post with the EREG and the background portion of deductions is cash, and that posts with the EREG if the employee is paid by check or the DREG if the employee is paid by EFT. The basic, theoretical, posting logic is:

Where the debit to Expense with the EREG is Gross wages and the credit to Cash is Net Pay. The difference between these is Deductions, and they post with the DREG. Therefore, the EREG is typically out of balance by the amount of the Deductions.

Unlike the other subsystems, payroll does not post a set or batch, but rather distributes to the General Ledger the records in the employee history. The employee history records are the result of the force calc process, which brings together the information from the Employee Pay Assignments and Timecards, which determine what the employee is to be paid.

Base Setup

Before presenting the details of posting definitions, it may be helpful to outline the relationship of various coding structures to the Payroll History records, the CDH definitions, and the distribution process. During the posting process, Posting Preferences may be used to assign the Posting Code based on user-defined logic for each subsystem, although in Payroll a posting code is not required. The Posting Code will be used during the batch posting process to direct the specific balancing entries.

Payroll Distribution Process

The complexity of Payroll setup is related to how the postings to be created differ from this "Base" setup. Answers to the following questions will help to determine if changes are needed:

Is Pooled cash being used? If it is, it will be necessary to set up interfund entries between the pool and the fund where gross is being posted.

Does gross always follow the org key on the paystring? If not, we will need to use the PCi field or Mapping to redirect the posting to the correct org key. The PCi might be a posting code from Posting Preferences or the actual CDH code.

Do the pay periods have different Post and Check Dates? If yes, it will be necessary to debit gross and credit wages payable at post date and debit wages payable and credit cash at check date.

Is Direct Deposit (EFT) set up as a deduction? If so, special setup is needed to post the deduction to wages payable at "P" date and reverse it to cash at "C" date.

Do benefits expenses always follow the org key on the paystring? If not, we will need to use the PCi field or Mapping to redirect the posting to the correct org key. The PCi might be a posting code from Posting Preferences or the actual CDH code.

Are contributions being used that add to net pay (Direct Contributions)? If yes, do they add to wages being posted on the EREG?
If yes, put a " + " in gross and net and "NOPOST" "NOPOST" on the contribution.
If not, DON'T put a " + " in gross and put the object it should post to in the debit object field and "NOPOST" in the credit object field.
If Common Code PYFG/PY101C exists and has "DIRECT-CNT-AS-PAY" in the first Associated Description, set up the contribution as you would an hour and ignore the above setup.

Do benefits and withholdings always credit the Fund administration org key or the paystring org key? If not, we will need to use the PCi field or Mapping to redirect the posting to the correct org key. The PCi might be a posting code from Posting Preferences or the actual CDH code (This will include using a payroll fund). If yes, does it post to the Fund key or the org key?

Are JL accounts being posted? If so, do they always follow the paystring? If not, it will be necessary to set up Posting Mapping, since the JL does not post through GLUTSPSI.

Are expenses to be posted by employee name or ID? If yes, set up Level in GLUTSPSI as "E" and account as "TRNS TRNS." If the Payroll system uses the Work Order or Job Ledger attributes they need to be defined into the Pay String. The Work Order information will then update the WO subsystem with the payroll information. The Job Ledger account numbers and amounts will then distribute during the posting process. Job Ledger does not get its own posting strategies, but the entries can be overridden with Posting Mapping.
The BusinessPlus Payroll module offers an optional data set called PYG-GLT-DTL. This data set will record all the employee history information with the account numbers that were used during the posting process. This can then be a valuable tool for CDD, or another reporting tool. When this table is turned on (PYUPGN, Interface Switches tab), PYPAxx will update the table with detailed postings. PYTPxx can also update the table if common code PYFG/PY560C has a Long Description of "POST=PYG-ON-TRIAL."
Using "@" in CDH Debit or Credit Object field can be useful if there is a relationship in the account numbers for hours and benefits. For example, if the benefit should post to the same object as the hour except the first two characters of the benefit should always be "XY" the debit object on the benefit can be defined as "XY@@." This will tell the system to substitute "XY" for the first two characters of the pay object to derive the benefit object.