BC Mid-Month Advance Process Overview

BC Mid-Month Advance Process Overview

GOAL: To provide a wholistic overview of the Mid Month Advance process and cover different important aspects as to how these functions and why it is so important within the BC Jurisdiction for ESA (Employment Standards Act). 

Mid-Month Advances

Instead of paying SM or BW, some SDs pay Mid-Month advances on top of Monthly Pay for the entire month due to a central teacher agreement. 

Legislation: Minimum pay frequency is twice a month at least (basically SM or more – doesn’t matter when or how close). 

This process outlines where an amount is advanced mid-month and then clawed back completely in the following regular pay period.

PROCESS OVERVIEW

PAYROLL > GROUP DATA > PAY PERIOD CALENDAR > SPECIAL PAY RUN

**Ensure Special Pay run is configured with Run Type = Advance** 

Note: When determining the Run Class; Group tells the system to look at the PAYROLL > GROUP DATA > ACCUMULATOR SCHEDULE for Advance. Whereas Run Class = Individual ensures the system leverages PAYROLL > EMPLOYEE > ACCUMULATOR SCHEDULE.

Note: Run Type must be Advance for the ADVPAY. 

PAYROLL > GROUP DATA > ACCUMULATOR SCHEDULE > EMP_GROUP

**Each record for mid month advance (ADVANCE//ADVPAY) is then recovered on the following pay run (ADVANCE//RECOVER)**

Note: Once completed, you must have Reset = Y when you have reached full recovery to close the In Amount. 

Note: In mid-month advance pay (Example: 20260101), Advance Pay can run on Net Pay which means the special pay run physically runs the next regular pay (202602) to obtain the Net Pay value, then rolls the next regular pay back – and applies the advance accumulator percentage against the Net Pay value. 

Additional Consideration: A potential trick that you can do ensure boards do not forget to Reset the Accumulators, would be to use a different ‘Code’ value (A1, A2, A3) for each pair of records (ADVPAY > RECOVER PAY). 

This is because the system sees these records as in and out values with two separate trackers, these fields do not consider the value of the other – hence if the RECOVER PAY is not RESET = Y, the ‘in’ amount will continue to grow incorrectly and recover too much in the following Recover Pay. 

The codes A1 through A9 are separate actual monetary accounts. 

PAYROLL > GROUP DATA > SUBJECT ENTITY MAINTENANCE

**Ensure record is defined under SUBJECT = ADVANCE & ENTITY TYPE = AdvPay Future Net Pay**

ENTITLEMENT > EMPGRP > GROUP AUTHORIZATION

**Entitlement and Group Auth completed (for good measure)**

SCHEDULE GROUP > PAY RUN > EMPGRP > 202602

**EMP_GROUP Scheduled and Run**

REPORTS > PROCESS REPORTS > PAY REGISTER

**Recover Pay is there - PAYREG looks good** 

PAY RUN > POST RUN > CONFIRM PAY

**Completed**

PAY RUN > PAY PROCESS > SCHEDULE GROUP

**20260201 is next pay for EMPGRP**

PAY RUN > PAY PROCESS > PAY RUN > SUBMIT

**Submitted and completed**

REPORTS > PROCESS REPORTS > PAY REGISTER

**Advance Pay is paid out**