Test
The purpose of this guide is to help you navigate the Blueprint and continue to maintain this document throughout each pay run. In this guide we will cover:
The Blueprint which is also known as the business requirement document outlines how a payroll should run.
Each tab servers a purpose which emphasises the rules on how the system was configured in line with what the client agreed upon during implementation phase.
The Blueprint once signed off by the client, holds Axiomatic responsible for delivering a payroll which aligns to the set standards and methods of calculation as instructed by client. It also holds the client responsible for ensuring that the information provided is correct and will be maintained as such going forward.
In the event that there is a disagreement on how a particular component should be calculated or who should be able to view and sign off payroll for the month, this document is then brought into light as agreed upon by the service level agreement, Axiomatic has with the client. Please note it is legally binding.
It therefore critical that the document reflects the true set up and accuracy of the payroll month on month.
The South African Blueprint caters for 29 Tabs whilst the African Blueprint caters for 27 Tabs, this is because South Africa has Equity and information required to process on the SARS website.
The index tab contains hyperlinks to all tabs located within the Blueprint. Consider this the contents page to a book.
Always ensure that the embedded link works accurately and is referencing the correct tab.
This tab let our client know who we are and what we do.
It refers to the other departments and service offering within the Axiomatic domain. You can use this tab to show clients other services we offer. It’s also useful for client to see who is in charge of the payroll and the contact details for the heads of departments.
This tab is mostly responsible for the level or reporting and the costing in the company. Its Set up on a hierarchy structure. Depending on the company and their specific set up it can be broken down into the following:
Company – Division – Unit – Department – Sub Department – Site – Cost Centre
Example:
Refers to the available positions within a company also known as job titles. In African Countries levels of management within the company also need to be defined on this tab. Grading of the Job function is usually done by HR and can be linked directly to the Job title.
Specifically, within the SA payroll, Equity reporting for occupational level and Position Function would need to be completed.
It is important to ensure that every time a new Job title is uploaded on the system, or a change in function needs to be modified- this tab is updated accordingly.
Headings | Requirement | Purpose |
Number of positions? | List all available positions within the company. Should a position become inactive – ensure this is updated accordingly on the system. | Records all the positions within the company. |
Grades Applicable? | Client to provide the grading system been used and the allocated grade for each job title. | Links salary grade to a job title- this can be set up to automatically link a grade and job title when a job title is selected on the system |
Grade Salary Ranges Applicable? | Salary and Grading bands to be provided. | Used in the event where specific grading platform that only allows a grade to operate within specified salary brackets |
Position link to grade? | If yes, position and applicable grade to be provided | To create automation between grades and positions. |
Other Categories? | Refers to BEE or any other selection category required to be linked to Job title. | If there is additional information required for reporting purposes, this must be provided upfront for configuration. |
Position details required for Recruitment? | If a client is using the recruitment or job coting function this would need to be completed | Apart of the job costing. It also allows larger organisations to forecast and create exact number of positions even if not currently filled. |
This tab is split between Medical Aid and Pension/Provident fund. It outlines the rules that need to be applied when these components of pay are in the payroll. When completing this tab, it’s important to know if the payroll is set up “Total cost to company” or “Basic Plus”
The ratio of payment rules is guided by the package set up.
Medical Aid:
The system cater for a variety of Medical Aid Schemes and the tables are updated yearly, however there may be times when a client is operating outside of the standard rules.
Headings | Requirement | Purpose |
Medical Aid Name | Some clients may have more than 1 scheme e.g. Discovery & Fedhealth we are required to record all medical aid or medical insurances that client is using either through payroll or outside of payroll. | Depending on the country, Medical aid attracts tax reliefs. Therefore, this should be on the payroll. If the company is paying for Medical Aid, then this attracts Fringe benefits which must be considered on the payroll for tax records. |
Employee Contribution | % or fixed amount to be advised. | Depending on package set up this may reduce one net salary. |
Company Contribution | % or fixed amount to be advised. | Depending on package set up this may reduce one net salary. |
Employer Maximum Contributions | The employer may elect to cap the amount paid per scheme. | Should a cap amount be noted then the difference in amount must be paid by the employee. |
Dependency Restrictions | This refers to age of number of persons allowed to form part of dependants. Age limits should also be recorded. | Records restrictions to ensure that there is no overpayments running through payroll. |
Make use of billing upload functionality
| Clients have the option to send us the monthly billing OR provided changes on the change form. | Only one option is allowed. This ensures that the billings is streamlined and we do not take contradictory instructions. |
Pension/ Provident Fund:
In most cases specifically in the African countries we see that there are two types of pension schemes- Statutory and Private.
In South Africa options like Retirement Annuities exist and therefore must be recorded on the payroll if this is paid by the company.
Employees who contribute privately to RA’s may opt to have this recorded on the payroll for rebate purposes, however then the responsibility to monitor and maintain this information
Headings | Requirement | Purpose |
Scheme Name | List the name and number or schemes available on the payroll. | Used for reporting purposes especially if there is more than one scheme. |
Scheme Type (Pension Fund / Provident Fund/Statutory) | Record the scheme. Define Contribution/ Defined benefits – this is required to properly set up taxability. | There are different rules around pension/ provident/RA and Statutory contributions. |
Umbrella Fund/ Stand Alone Fund | Applicable for SA payrolls – the key and most obvious difference between an umbrella and stand-alone fund is that an umbrella fund is a fund whereby multiple employers contribute towards one fund, while the latter serves a single employer. Stand-alone funds may be an appropriate option to an employer with unique operational characteristics | Part of selection criteria on Payspace |
Administrated By | Confirm if this is underwritten by a broker or what which major group. | Underwritten by another company |
Clearance Number | Client to provide policy | Optional information |
Approved/ Unapproved Scheme | Refers to the Risk benefits – its important to note if this is approved o unapproved scheme | Approved is not taxable and can be combined with the pension/provident contributions. If unapproved its taxable and requires to be separated on the payroll under a different SARS code. |
Define Pensionable income | What components are used to calculate pension/provident | This is linked full salary or a % of salary or even calculated on specific components. |
Bonus Calculation/Definition as per the scheme | Optional if the employer chooses to take a % of the seasonal bonus payment made | Optional for calcs of pension/provident. |
Employee Contribution % and of what? | Note the percentage options | Used for variance calcs |
Employer Contribution % and of what? | Note the percentage options | Used for variance calcs |
Group Life Assurance | Note the calculation | Used for variance calcs |
Spouses Insurance | Note the calculation | Used for variance calcs |
Trauma % or fixed amount | Note the calculation /amount | Used for variance calcs |
PHI/Disability Cover | Note the calculation/amount | Used for variance calcs |
Funeral Scheme | Note the calculation /amount | Used for variance calcs |
Arrear Pension Fund Contributions | Is this applicable for backpay on basic? | Used for variance calcs |
AVC Contributions | Are employees allowed to contribute more if so will this be a % or fixed amount | Used for variance calcs |
Pro Rata Rule | Really important to note, what are the rules if the EE joins late in the month or terminates early | Used for variance calcs |
Any other products relating to the Funds /Schemes 1 | Additional information | Optional Information |
This tab notes down the Basic Information required to open a company on the Axiomatic platform.
Company Logo – we require a copy of the company logo as this will be loaded onto the payroll to reflect on the payslips.
It requires the client to confirm if payslips notification should be emailed as well as if the system should automatically provide employee number or if this will be advised by client.
It requires pertained information which is later used in the Annual filing reports or the monthly statutory reports. It is country specific so ensure you list all the numbers required as per outlined in the company information tab on Payspace.
It requires both the Company Physical and Postal Address details which reflect on the payslips and certain closing reports depending on the country.
Contact Person – Critically important – this must be updated and maintained as in terms of the SLA we can only communicate with person whose details appear on this tab.
This tab outlines the security passwords, edition of payroll being used as well as number of frequencies set up to accommodate the client individual needs for each company or frequency.
We set up different frequency when there is a split in reporting or if bank files needs to be separated for payments.
Headings | Requirement | Purpose |
No. Employees | At take on how many active employees were on payroll | Billing per payslip |
Monthly/Weekly/Fortnightly? | This is vital important to note as weekly and fortnightly require different set ups. | Used for determining calendars and timelines. |
Centralized Email Account Details | Client has a dedicated email account | Client is aware of who to contact |
Password | Unique password is created for each client | All documents containing any information must be password protected. |
Frequency Name | Depending on the number of frequencies this is named accordingly | Quickly identify the payroll type. |
Is this a take on run? Or month by Month? – please specify the month | Used for Imps- We note the from which month we are required to take on data | Data taken on from the beginning of the tax year is required for annually filing. |
Country Currency used in Set Up? | Note the currency | If FX Rate conversion are required, this would be the indicator. |
Edition of Configuration | Used for Imps – | Depending on the edition selected the price options for monthly billings differ and so does the limitation in the system. |
Does this Payroll Need to be Grouped? | Grouping allows you to pull reports across multiple frequencies and companies. | Reporting purposes. |
First Pay date | Used for Imps | Live pay date within Imps |
December Pay date | Noted for future planning | Used to set up future calendars runs. |
Pay Day for future runs | Noted for future planning | Used to set up future calendars runs. |
Monthly Cut-off Date for Claims | Noted for future planning | Used to set up future calendars runs. |
Pay Day – If pay day falls on a weekend or public Holiday, do you pay before or after? | Noted for future planning | Used to set up future calendars runs. |
Automatic pay indicator default on employee pay rate screen: | Used to ensure payrate is automatically calculating each month. | In the case of Weekly paid or seasonal paid, this is usually not selected. |
Default hours per day | Client to advise the average days worked in the month. | Used in MOC for leave, overtime, termination pay etc. |
Default hours per month | Client to advise the average days worked in the month. | Used in MOC for leave, overtime, termination pay etc. |
Default working days per month | Client to advise the average days worked in the month. | Used in MOC for leave, overtime, termination pay etc. |
In the case of a monthly frequency: Pro Rate – For New engagements or termination that occur during the month, what is the proration rule for Package? Calendar days or working days? | Client to advise the average days worked in the month. | Used in MOC for leave, overtime, termination pay etc. |
Financial Year End | Additional information required | In the event additional reporting is required in this period. |
Tax run by client (YTD/ MTD) | Required by Imps | Noted for Tax method set up. |
Axiomatic set up (YTD/MTD) | Required by Tax Audit | To ensure the method of calc for tax is applied correctly month on month. |
What system is client currently using? | Additional information required | Used for Imps |
Can a backup be provided? | Additional information required | Used for Imps |
Tax Year | Tax year run within country | Ensure legislatively compliance |
Periods | Tax year run within country | Ensure legislatively compliance |
If Weekly / Fortnightly Frequency selected: | Note used for set up in Weekly and Fortnightly | According to the information provided by client the system will be set up to predefine each run. |
Week start day | Used for Config Purposes | To be managed accordingly in Ops |
Week end day | Used for Config Purposes | To be managed accordingly in Ops |
If the last week ends in the next month, do you deem this week to be part of the current month or the next month? | Used for Config Purposes | To be managed accordingly in Ops |
The importance of this tab is to ensure that the critical information specific to the client and the country is noted down on the blueprint. Basically, what is required to successfully load the new starter – recurring information, lining to specific package information, having all the tax reference data for annually filing. This in turn transpires into the information required on the change form. Therefore it’s important to update this tab specifically in operations as payrolls move around and ensuring the data is transferred across enables the next team to work efficiently and not neglect data that could possible hinder the payroll in future.
As with the termination tab we need to specifically document what is the rules specified per client per country as to successfully terminate the employee.
Questions such as, should a prorate bonus be paid out? If the employee contributes additional tax to compensate for a bonus pay out in December- what happens? Should all loan repayment be recovered? Should leave payment be paid out in the same month of the next month? How should be treat he pension or medical payment if this employee is a mid- month leave? If leave is accrued upfront, or lumpsum payment made in advance should this be recovered?
These types of questions ensure that the probability of overpayment to the employee is eliminated.
We maintain this tab and provide updated version to client along the way so in the event the rules should apply differently in a month it would be because the client instructed us differently on the change form.
Note the blueprint in configuration stages is a basic guideline of what is required as a base point – as the month progress we build on this tab to ensure all the stated rules are being accounted for.
Due to the diverse platforms that PAYSPACE now accommodates for in terms of other systems feeding directly into the payroll platform we have noticed that it is increasingly important to recognize what we catering for in the configuration of the system.
Interface files such as overtime from clocking systems or Integrations files like API files need to be in a certain format and align to framework of the system.
In operations it is important for you to understand what you are checking and where the possible glitches could arise from.
Essentially if this tab is completed then Operations will be held responsible for checking the data files feeding the system.
These tabs are probably the crux of what we do in payroll. It drives the point of why we do payroll.
It is the starting point of how we capture these elements on the system and how we should check them.
To understand how this works you will need to understand what is expected – below is a list of questions we ask to build the foundation of what makes up this Method of calculation.
Headings | Purpose |
Component Name | Refers to the naming convention client uses on the payroll. |
English Definition | In the case of French/Portuguese payrolls, we list the English definition for comprehension. |
Change in Naming Convention | Should the take -on data require a name change – we note down the New Naming convention – which reflects on the system. |
Component Advised/ M.O.C | Here we establish if the component would need a method of calculation set up or if this would be an advised amount from client. |
Client Explanation of how the component is calculated | Refers to how the client request us to set up this component and how it should calculate going forward. Additional information such as why it is necessary or what it would be used for is noted here. |
Axio Pay Comments / Notes | We use this tab to establish if this is going to be set up under a note component as a trigger point or if we will requires tools outside of the system to ensure capturing is done correctly. |
Recurring | If the component is recurring in nature we highlight this here – this then ties back to the recurring tab on the change form and also ensure the component is set up on the system as recurring for month on month variance checks. |
Is this Component Prorated? | Very important to note – there might be instances where a proration of a component is required. If so the rules around this is built into the system, some instances require no proration even though it is a recurring line, where as other instances require the pro-ration rules work differently using another base point. |
Is this Part of Package | If the component is part of package this would need to be completed – example – Medical aid, housing, transport and pension fund are commonly known to be part of package. This would require the system to specifically calc these components as part of the Total Cost to Company. |
Variance/Tax Check | Here we outline who would be responsible for checking this component – if it’s a part of statutory checks this will be done by the Audit team if not, it should then form part of the variance check done by Operations. |
ESS Claim Indicator | Refers to the claim’s module, if any component is marked for claims this would be that the claims module has been set up and other workflows are co-existing I the back end. So, when doing a variance check then additional reports will have to be pulled to verify the information sitting on payroll. |
Category (only employees on a certain category must receive this? | This refers to grouping of employees -rules can be set up in the system to ensure that employees who are for example in sales only receive commission, if data come through and the employee is not a sales person, the system can reject the information provided. |
Component Included/ Excluded: SDL | Ensures the component is marked for statutory calc which is part of the annually filing. |
Component Included/ Excluded: UIF | Ensures the component is marked for statutory calc which is part of the annually filing. |
Component Included/ Excluded: COIDA | Ensures the component is marked for statutory calc which is part of the annually filing. |
Component Included/ Excluded: BCEA | Ensures the component is marked for statutory calc which is part of the annually filing. |
Component Included/ Excluded: ETI | Ensures the component is marked for statutory calc which is part of the annually filing. |
SARS Tax Code | Specific to SARS the tax code represent against this component will determine how this will be taxed. A list of the codes is available on the SARS website- this must be checked annually as codes may change at the beginning of the tax year. |
Tax Monthly or Periodic | This is an indication if the component is to be part of a periodic calc or monthly taxability. |
GL Codes Dr | Refers to the GL accounts -each component on the system must have a GL account code and a contra – account code- when loading new components is imperative we get this from client so that the GL balances at the end of the month. |
GL Codes Cr | Refers to the GL accounts -each component on the system must have a GL account code and a contra – account code- when loading new components is imperative we get this from client so that the GL balances at the end of the month. |
Payslip Action | In African countries specifically – client can request if they want the component hidden on the payslip. Another important point to note especially if new components are being loaded on the system. |
This is specific to South African payrolls. All clients are requested to submit an Equity Report during the year for BEE purposes. Therefore, it is imperative that when loading a New employee, we have all the information required for Equity reporting.
The information is standard information and does not specifically require operations to build this but rather maintain and ensure we have the correct information for the fields required.
A check and balance is done before this is issued to the client, and requires a few reports including the movement report, Dynamic Report and YTD financials to verify the information represented on the EEA2.
This tab is applicable for SA clients. The purpose of this tab is to note down the client Login in details and keep track of any special responsibilities Axiomatic will act out on behalf of the client.
IF the client is using FIHRST for banking, then the EMP 201 will be filed by FIHRST, however Axiomatic will still be responsible for apply for Tax directive and completing the Annually filing.
We would then require access and login details for Easy Filing.
This tab also registers the UIF number and email address that would be used on the system for the monthly UIF Declaration information – If there is any discrepancies and if submission is not filed before or on the 7th the client could face penalties therefore it is very important the information represented her is accurate and true.
Under GL Configuration the Implementation team will outline the format in which the GL should be constructed. Operations is responsible for maintaining the monthly balancing as per the specification set out by the client.
Should there be a new component added, the Payroll Administrator is responsible for ensuring that the debit and credit codes are updated accordingly. This is maintained on the Earning, Deductions, CC & Fringe Benefits tabs.
GL can be set in four ways namely:
Line Item per employees |
Line items total per component |
Line items Total per GL Account number |
Combination of totals per component and GL Account ? |
See training material on Journals to understand how this should be checked.
The maternity tab is separated for the leave policy due to the complication and special rules that follow maternity depending on the company polices and country legislation. On this tab, its important for operation to pay attention to the rules that might require manually intervention.
Headings | Purpose |
Policy | The policy rules will be set up at implementation stage, however Ops is responsible for ensuring the rules are applied correctly. |
Special Method linking’s | Refers to the any linkings such as company contributions that need require suspension during maternity. |
How to treat Medical Aid? | Should this be paid by the EE or suspended |
How to treat Pension/Provident Fund? | Should this be paid by the EE or suspended |
What to do with other earnings? | Should additional earning such as Bonus and incentives be paid? |
What to do with other deductions | Which deductions should go off and which should be suspended? |
If the salary goes into a negative, how must Axio Pay treat this? | This should be deferred to the client |
Must Annual leave accrue during maternity leave | This requires manually intervention |
Pro rata specifications | This requires manually intervention |
Should Normal tax be activated whilst employee is on maternity leave, or should it be left on average tax? | Applicable to SA client. |
The suspended screen does accommodate maternity calculation set up. During handover this must be checked.
The reports tab, documents and provides details as to which reports should be sent to the client at a specific stage.
It is broken down as follows:
Important to note, reports may be pulled in Excel, word, and PDF- all reports issued to client must be issued with a standard password.
Should a client request additional reports which are not stated on the Blueprint – this may be charged additional. All custom reports are charged a setup fee and then operations maintain the reports – should additional work be required- Operations would need to send a quote for additional work required.
Every system has its limitation and using Payspace we can safely say retrospect payments are not possible, in cases like this, manually intervention is the only option.
This tab outlines how prorations for a midmonth new starter or termination should be done. What factors should be considered and how this should be applied to the payslip screen.
There is a drop-down option which needs to be selected, for a Basic plus or TCTC structure.
You would need to specify the recurring contributions.
By inserting the rules, the example provided should be followed and client should agree to the prorated amount.
If the client is using the leave module, this tab is used to specify the rules that should be set up in order to allow employees to successfully apply for leave. At implementation stage the following questions are completed and data provided so that testing to ensure the rules are applied correctly can be checked.
The leave policy is then reviewed, and rules are established with the client by mapping through the following questions for each leave type.
For leave that is being uploaded manually, Ops function is to ensure opening balances + monthly accrual – leave take = closing leave balance.
Workflows are then set up and it’s important to remember that when the leave approver is terminated operations will need to assign a new leave approver to the list of subordinates.
Should at any time the client disagrees on the how leave is calculating, you are able to navigate to the leave set up and view the rules as per the blueprint to verify if there is any discrepancies.
For configuration purposes this tab defines if the employee has access to internet and hold a valid email address.
This tab also outlines for ESS purposes what claims need to be configured and what rules should be applied.
Recent trends show that client now prefer to have an annual calendar, so they are aware of upcoming deadlines months in advance. This helps them with their planning.
Majority of the payrolls handed over from implementation to operations will have a calendar in place, operations will then send reminders to clients as to when payrolls are due in.
In addition, if the payrolls are late, operations will liaise with client on new calendar timelines.
As a manager you will be responsible for ensuring that the calendar accommodates the clients request as outlined in the blueprint whilst considering Axiomatic timelines to work within.
Refer to Wrike training for the payroll process daily breakdown.
This tab explains to client how the change form should be completed. This is a standard format, so If your clients change form works differently than this tab should be updated accordingly.
Mostly used during Implementation stage, this is signed off by the client as confirmation that the format and details showing are as per client request. Going forward should the client which for additional details to be hidden, Operations will need to ensure this tab is updated and notes of new requests are tracked on this tab.
During Implementation stage, the client is responsible for providing a Bank file Spec, this spec defines how the bank file should be built.
Whilst Payspace accommodate for most banking platforms, there are a few countries where the bank file requires a custom build. During handover Operations is informed on which bank file to pull.
Monthly bank file checks are critical and should never be overlooked.
This tab outlines if Axiomatic will file annually returns on behalf of the client or if Axiomatic will send the files for client to file in country.
Most cases South African payrolls are filed by Axiomatic.
Refers to each segment in Payroll and who is ownership responsibility for ensuring the task is completed and the process stays on track.
Responsible persons are documented by Name and email address.
Security Roles can be created for users of the system, each role is defined by the client. The role is then broken down into what the user can have access to. Access rights are granted using – “allow, deny, read only”
Usually provided during scoping of work, this tab reflects the contact details of the person what is responsible for payment on the account. It must be maintained by operations should the main contact leave.
BOD has introduced a specific format in which updating and maintaining Blueprints should follow.
Please see addendum to this guide.
End