End 0f Financial Year Behaviour
BrightPay publishes different BrightPay applications for each financial year. Around the beginning of the financial year (both just before and just after) the API may be unsure of which financial year to get data from or which financial year to load data into. This is because employee's pay periods may not exactly match the financial year.
For example, the financial years starts on the 6th April for the UK. If you are paid per calendar month then any time worked from the 1st-5th of April is technically in the previous financial year. Whilst the days 6th-30th of April are in the next financial year. Your last pay period for the previous financial year will run until the 31st of March. Your first pay period for the next financial year will run from the 1st-30th April. This means that if the API is loading data for the 1st-5th of April it needs to be loaded into the payslip of the next financial year (even though technically the time was worked in the previous financial year). Different employers may have pay periods of different lengths with different start and end dates. The API will try to transparently deal with this issue, or if that is not possible then the API will provide hints to help the user.
At the end of a financial year most BrightPay customers clone the last years settings and data (Employers, Employees and Hourly Pay Rates etc.). Therefore, the data returned from the API for either year will be very similar (the same identifiers, names etc are returned). However, from one year to the next a customer could set up their BrightPay application from scratch. In which case the employerId & employeeIds could differ along with name spellings etc.
Furthermore, some employers will have multiple pay schedules (e.g. some employees are paid monthly others every two weeks). This can make it complex for the API to know which financial year to get or load data into. Therefore, around the turn of the financial year the API may try to perform an action on the BrightPay applications connected to both financial years.
There are 3 main scenarios to consider:
1) BrightPay has been cloned between financial years
BrightPay has been cloned between financial years and no significant changes have been made to Employers, Employee or Hourly Rates. In this scenario the integration will work in a transparent manner. Very similar Employers, Employees and Hourly Rates will be returned (no matter the date).
2) BrightPay has been manually set up between financial years
Within BrightPay the customer has not cloned the year before but has decided to set up the BrightPay application for the next year manually from scratch. In this scenario if there was a single Employer set up in BrightPay in both financial years called "Tech Help" then:
Up to a few weeks before the end of the financial year if data is requested from the API, the API will connect to the earlier BrightPay application (24/25) and return in the Employer list a single item "Tech Help" (with an employerId reflecting the earlier BrightPay application (24/25))
For a few weeks before and after the end of the financial year the API will contact both the earlier (24/25) and newer (25/26) BrightPay applications to get results. As each employer has been set up manually in each year and are unconnected, when the list of employers is returned two entries are included ("Tech Help 24/25" and "Tech Help 25/26"). On selecting one of these employers and requesting data, the employees and hourly rates for that employer will be provided. Note the Employee names may be the same but the employeeIds will be different.
A few weeks after the end of the financial year if data is requested from the Payroll API, the Payroll API will connect to the newer BrightPay application (25/26) and return in the Employer list a single item "Tech Help" (with an employerId relating to the newer BrightPay application (25/26))
3) BrightPay has been cloned between financial years but there are some changes
BrightPay has been cloned between financial years but some changes have been made to Employees or Hourly Rates. In this scenario a single Employer will be returned no matter the date. However, there may be changes in the Employee and Hourly Rate data returned.
For example, lets say
There are two employees (Ashok Green, Jane Smith) in both BrightPay applications (copied across when the financial year was cloned so each retains the same employeeId etc.)
Then just before the end of the financial year John Jones joins the company and is manually added in BrightPay to both years (24/25 & 25/26).
Finally, Lisa Bailey joins the company and is added to BrightPay for the new financial year only (25/26)
In this scenario in the BrightPay application:
Ashok Green has the same employeeId for both years
Jane Smith has the same employeeId for both years
John Jones has different employeeIds in each year
Lisa Bailey has a single employeeId in one year (25/26)
If a list of employees is requested from the API on various dates the API will return:
Ashok Green
Ashok Green
Ashok Green
Jane Smith
Jane Smith
Jane Smith
John Jones
John Jones (24/25)
John Jones
John Jones (25/26)
Erika Bailey
Lisa Bailey (25/26)
Hourly rates do not have an id but behave similarly.
Standard rate
Standard rate
Standard rate
Sat overtime rate
Sat overtime rate (24/25)
Saturday overtime rate
Saturday overtime rate (25/26)
Finally, when uploading Hourly Payments around the financial end of year the API will try to load the data into an open current payslip in the earlier BrightPay application (24/25). However, if it cannot find an open current payslip it will try and load the data into the newer BrightPay application (25/26).
Last updated