Final Assurance Report Audit of Payroll Validation: Phoenix Database Migration

Internal Audit Office of the Chief Audit, Evaluation, and Risk Executive

On this page

• 1. Executive summary
• 2. Management response
• 3. Background
• 4. Focus of the assurance engagement
  • 4.1 Objective
  • 4.2 Scope
  • 4.3 Line of enquiry, criteria, and methodology
• 5. Detailed observations and lessons learned
  • 5.1 Roles, responsibilities, accountabilities, and authorities
  • 5.2 Gating process
  • 5.3 Payroll validation testing results
  • 5.4 Payroll validation success criteria
• 6. Conclusion
• 7. Acknowledgements
• Appendix:
  • Appendix A: Acronyms and abbreviations
  • Appendix B: Glossary
  • Appendix C: Line of enquiry, criteria, and methodology
  • Appendix D: Payroll validation cycles and their purpose
  • Appendix E: Approved payroll validation success criteria

1. Executive summary

As the pay and pension administrator for the Government of Canada, Public Services and Procurement Canada (PSPC) administers payroll for over 400,000 employees in over 100 departments, agencies and Crown corporations using the Phoenix pay system. It also provides full compensation advisor services and direct client support to approximately 270,000 of these employees as well as end-to-end technical leadership and support for all pay-related applications.

The Phoenix pay system’s vendor support for its database and development platform will be ending by April 2025. Following the end of vendor support, PSPC faces a high risk of security vulnerabilities and service degradation, which could impact PSPC’s ability to produce accurate and timely pay for its employees, and the risk associated with aging information technology systems. To address these operational risks, PSPC initiated the Pay System, Database and PeopleTools Project (hereafter referred to as the Project) under the direction of the Human Capital Management Solutions Branch. This Project, which commenced in April 2022 and was anticipated to span over 2.5 years, entails migrating the pay system from the International Business Machines Corporation (IBM) DB2 database to a new Oracle database and upgrading its PeopleTools development platform. The Project includes governance, stakeholder engagement, and testing. Payroll validation testing is one component of the overall testing process that is intended to provide confirmation that the pay system produces similar results after the migration. The actual deployment date of the Phoenix database migration was October 22, 2024, and there is no ability to revert back from the Oracle database to the DB2 database.

The objective of this assurance engagement was to assess the effectiveness of the payroll validation testing process as well as the results of the reconciliation of the payroll runs carried out on both the current and new databases, prior to migration.

In terms of the payroll validation testing process, roles, responsibilities, accountabilities, and authorities were largely defined, documented, communicated, and understood. That said, while the roles and responsibilities of the individual(s) providing the decision to proceed through each gate of the payroll validation testing cycle as well as escalation procedures to business or governance were not fully documented, they were communicated and understood by the Project team.

Also, the overall gating process was operating as intended, including the provision of approvals in a timely manner that were mainly documented. As well, the payroll validation testing results for all 10 gates in cycle V5 were assessed and reconciled with the Project team’s results in terms of dollar value variances. Furthermore, the Project team’s results in the summary reports for each gate were compliant with its Upgrade Test Plan. Moreover, the Project team’s results in the summary reports for each gate were compliant with its Upgrade Test Plan. Also, internal audit found that this cycle met the success criteria.

As an issue was identified in cycle V5, the Project team created a new environment, cycle V5B, as a validation instance, for which a coding change was applied. While this cycle was the solution recommended by the Project team to proceed to production, they opted not to produce the detailed supporting files required by internal audit due to budget and schedule constraints. As such, internal audit was unable to provide assurance that cycle V5B met the success criteria.

Moreover, the same payroll validation success criteria that was used to successfully deliver the  Phoenix PeopleSoft 9.2 upgrade was approved for use by the Project as both projects were deemed to be of comparable complexity. That said, these criteria were inconsistently reflected in project documents, which could lead to misinterpretation or misapplication of the testing. Additionally, the Project team’s results in the summary reports for each gate were calculated based on differences consistent with the Phoenix PeopleSoft 9.2 upgrade. At that point in time, internal audit assessed the payroll validation testing for the upgrade and had no observations regarding the use of differences in Project team's calculations although  the success criteria is based on variances. As part of the current assessment of the data migration, internal audit has identified this as a discrepancy, as values reflected offsetting amounts rather than depicting the differing figures in their aggregate. While this discrepancy had no impact on success criteria for the database migration, distinguishing between the terms variance and difference would improve clarity. Lastly, the success criteria were last reviewed in November 2020 and would benefit from a periodic review, so that they will continue to be relevant, support continuous improvements, and mitigate risks.

While no recommendations were issued as part of this assurance engagement, lessons learned were identified for consideration when conducting similar projects in the future.

2. Management response

The Pay System, Database and PeopleTools (PSDPT) project was successfully delivered on October 22, 2024. Since go-live, multiple successful pay periods have been delivered that demonstrates the pay system has stabilized.

Management has reviewed this Audit of Payroll Validation: Phoenix Database Migration report and is providing the following response based on our assessment of the internal audit engagement.

Management agrees with the lessons learned suggested in this report. As this report is being finalized after the PSDPT go-live, the lessons learned have been documented, shared and communicated to PSPC’s senior leadership. In addition, they have been included in the PSPC Lessons Learned portal which allows these lessons learned to be reviewed and adopted by others within the department.

For lesson learned C, the terms “variance” and “difference” were defined, documented and shared with Operations for their review and adoption. In 2021, this methodology was conducted and used for the PeopleSoft 9.2 Upgrade, where both the project and the internal audit teams assessed the methodology and results. For PSDPT, “variance” was used for all Pay Validation assessments at the employee level, and “difference” was only used for the Gross-to-net summary totals.  If this audit is yielding different results, then the totals calculated may be based on assumptions by the internal audit team that does not align with the agreed project definitions.

The project has recommended using “variance” for all calculations, as noted in Lessons Learned C. This has been shared with PSPC’s Management, who will promote a common interpretation and application of the calculations, to ensure the definition of results are clearly defined, and consistently documented.

In closing, we would like to thank the internal audit team for their collaboration and lessons learned provided throughout this engagement.

3. Background

As the pay and pension administrator for the Government of Canada, Public Services and Procurement Canada (PSPC) administers payroll for over 400,000 employees in over 100 departments, agencies and Crown corporations using the Phoenix pay system. It also provides full compensation advisor services and direct client support to approximately 270,000 of these employees as well as end-to-end technical leadership and support for all pay-related applications.

Phoenix is currently comprised of the Oracle PeopleSoft 9.2 software, the International Business Machines Corporation (IBM) DB2 database and the Oracle PeopleTools development platform. In IBM announcing that it will no longer support the current version of its database as of March 2022, the Government of Canada negotiated and agreed with IBM to provide extended support until April 2025. Also, Oracle announced it will cease support of PeopleTools beyond the current version on the existing IBM database.

As a lack of vendor support introduces a high risk of security vulnerabilities and service degradation impacting PSPC’s ability to produce accurate and timely pay for its employees, and to mitigate the risk associated with aging information technology systems, PSPC initiated the Pay System, Database and PeopleTools Migration Project (hereafter referred to as the Project) under the direction of the Human Capital Management Solutions Branch. This is a technical project that includes migrating the Phoenix pay system from the DB2 database to a new, supported database platform, Oracle, and upgrading the development platform, PeopleTools. The Project commenced in April 2022 and was anticipated to span over 2.5 years.

The Project includes governance, stakeholder engagement, and testing. Specifically, testing is performed throughout the Project’s life cycle and is comprised of various phases and cycles with each cycle of testing focusing on a pay run that is performed over several weeks. Payroll validation testing, one component of the overall testing process, is intended to provide confirmation that the pay system produces similar results after the migration. In other words, it is testing to ensure that an employee's pay cheque is produced similarly in both databases.

The Project team planned to conduct 4 payroll validation cycles (V1, V2, V3 and V4), with an additional contingency cycle (V5) in case any critical issues were encountered during one of the previous cycles (see Appendix D for cycles and their purpose). All cycles would be assessed based on success criteria that were previously approved as part of the Phoenix PeopleSoft 9.2 upgrade in 2016 (see Appendix E for success criteria).

The Project team procured Gartner, Inc. (Gartner) to provide services related to the Project as a whole, including third-party, independent, benchmark and value assurance support. In particular, Gartner performed benchmarking assessments for 4 payroll validation cycles, which included cycle V1B rather than cycle V1, to ensure that defects in the earlier cycle were resolved. Additionally, while Gartner commenced its assessment of cycle V4, it was unable to complete its work as its contract ended.

The actual deployment date of the Phoenix database migration was October 22, 2024, and there is no ability to revert back from the Oracle database to the DB2 database.

4. Focus of the assurance engagement

As Gartner was unable to complete its benchmarking assessment of cycle V4 due to its contract ending, the Human Capital Management Solutions Branch requested that internal audit provide assurance services for cycle V4^{Footnote 1}. As large variances were identified that were caused by the different ways in which the 2 databases sorted their information, the Project obtained the appropriate governance approval to cancel cycle V4 and proceed with cycle V5, the contingency cycle.

4.1. Objective

The objective of this assurance engagement was to assess the effectiveness of the payroll validation testing process as well as the results of the reconciliation of the payroll runs carried out on both the current and new databases, prior to migration.

4.2. Scope

This assurance engagement assessed whether the payroll validation cycle V5 was executed from July 15, 2024, to October 10, 2024, in accordance with the Project’s Upgrade Test Plan. 

This engagement did not assess the Project’s Upgrade Test Strategy that was used for payroll validation testing as it was previously assessed as part of the internal audit on the Phoenix PeopleSoft 9.2 upgrade. Also, other migration testing, such as system integration, regression, and user acceptance testing, was out of scope for this engagement.

The period covered in this assurance engagement was from July 2024 to October 2024.

4.3. Line of enquiry, criteria, and methodology

This engagement’s line of enquiry, criteria and methodology can be found in Appendix C.

This assurance engagement was conducted in accordance with the International Standards for the Professional Practice of Internal Auditing.

5. Detailed observations and lessons learned

5.1. Roles, responsibilities, accountabilities, and authorities

The roles, responsibilities, accountabilities, and authorities for payroll validation testing were largely defined and documented. PSPC’s Project Navigator concretely outlines those of the business owner, project sponsor, project leader, and project manager. As part of the overall Project, these roles, responsibilities, accountabilities, and authorities were assigned to specific positions and individuals as outlined in various project documents, such as the Project Charter.

Also, roles and responsibilities for all migration testing, including payroll validation testing (for example, test lead, functional lead, and project testers), were described in the Roles and Responsibilities for the Test Plan. These roles and responsibilities were communicated with the Project team in various manners, such as during team meetings, and were generally understood by implicated parties.

For cycle V5, while the roles and responsibilities of the individual(s) providing the decision to proceed through each gate of the payroll validation testing cycle were not documented at the onset of testing, they were communicated and understood by the Project team. In practice, the functional lead or project manager are responsible for gating decisions (consult 5.2 Gating process for additional information). Also, the project manager consults with the Project team on the gating status,’ results, and other relevant matters at Project status meetings that are held approximately 3 times per week. Certain issues, such as a large variances due to differences in processing between both databases, are escalated to the business or governance, as needed. Furthermore, governance escalations are documented in decision notes. That said, project documentation does not fully outline the circumstances that require escalation to business or governance prior to providing a gating decision.

Lessons learned

(A) The roles and responsibilities of the individual(s) providing the decision to proceed through each gate of the payroll validation testing cycle as well as escalation procedures should be documented at the onset of the testing.

5.2 Gating process

The Project’s Upgrade Test Plan outlines the purpose and objectives of the payroll validation testing, the testing approach, and the results validation approach, including the gating process. In particular, the Project team employed the use of gates, a best practice that entails breaking down its testing into smaller stages. At each of these gates, the decision-makers meet to review the testing and decide, based on specific criteria and the information available at the time, whether to continue, stop, hold, recycle, or modify it. Once a decision is made to move past a gate, previous stages are generally not revisited, which emphasizes a linear progression in its design. This approach helps ensure that decisions are made with a clear focus, allowing for structured evaluation, and minimizing the risk of reverting to earlier stages, while streamlining processes and maintaining momentum toward a final goal.

Overall, the gating process for payroll validation testing was operating as intended. Specifically, the payroll validation for cycle V5, similar to previous cycles, was designed to have 10 sequential gates (consult Figure 1: Pay validation cycles V5 and V5B). For cycle V5, no issues were identified for gates 1 through 4, 7 and 8.

The issues and resulting impacts of the remaining 4 control points are as follows:

Gate 5

During gate 5, a production issue was identified in both the DB2 and Oracle databases and, as per procedures, the Phoenix production team took ownership to resolve this issue. As both databases produced similar results and dollar value variances were considered explainable, the Project team proceeded to the next gate. 

Gate 6

At the start of gate 6, another issue was raised that prompted the Project team to open a  service ticket with Oracle. At the same time, a duplicate environment was created; the original environment retained the name cycle V5 and the newly created environment was referred to as cycle V5B. This enabled the Project team to facilitate issue resolution while proceeding through the remaining gates in cycle V5. It also permitted the team the flexibility to return to cycle V5B later to assess, test and validate a solution to the issue. 

Upon further investigation, the Project team discovered that the issue was attributed to a coding error. This resulted in the team no longer pursuing the Oracle service ticket and, instead, applying a coding change at the start of gate 6 in cycle V5B.

Gate 9

As part of gate 9, the Project team identified another coding error that they immediately corrected. Subsequently, the team presented updated gate 9 results, which was referred to as gate 9.2, prior to proceeding to gate 10.

Gate 10

As part of gate 10, the Project team identified an additional coding error that related to the manner in which both databases presented their end of cycle data, which they immediately corrected. Subsequently, the team presented updated gate 10 results that incorporated the updated data and was referred to as gate 10-adjusted.

In terms of cycle V5B, once the coding change was applied at the start of gate 6B, the Project team completed this cycle by proceeding sequentially through gates 6B to 10B. Internal audit was informed by the Project team that no further issues were encountered with cycle V5B. 

Figure 1: Pay validation cycles V5 and V5B

Additionally, verbal or written approvals for each gate in cycle V5 were provided in a timely manner (consult 5.1 Roles, responsibilities, accountabilities, and authorities for additional information). That said, the gating decision was not consistently and formally recorded and retained as an information resource of business value in support of project delivery.

Lessons learned

(B) The decision to proceed through each gate should be formally documented and retained as an information resource of business value in support of project delivery.

5.3. Payroll validation testing results

The Project’s Upgrade Test Plan outlines the results validation approach, which includes the methodology for performing the variance and threshold analysis to meet the success criteria (consult 5.4 Payroll validation success criteria and Appendix E for additional information).

To perform its assessment, internal audit required the detailed supporting files for each gate,  which are point-in-time specific and cannot be automatically reproduced after-the-fact. In terms of cycle V5, the Project team initially produced and provided these files to internal audit for 9 of the 10 gates. Due to the issues encountered at gate 6, the detailed supporting files were not initially produced by the Project team. In early September 2024, internal audit explained to the Project team that this omission would preclude internal audit from providing assurance on cycle V5. After various discussions, the Project team decided to restore both databases to an earlier state, re-ran gate 6, and then produced and provided the detailed supporting files for this gate on October 4, 2024. Given this, internal audit instituted additional procedures to confirm the restoration of the databases, which was found to be accurate and complete.

With all the required detailed supporting files, the cycle V5 payroll validation testing results for all 10 gates were assessed and reconciled with the Project team’s results in terms of dollar value variances. Furthermore, the Project team’s results in the summary reports for each gate were compliant with its Upgrade Test Plan. Also, internal audit found that this cycle met the success criteria. Refer to Tables 1 and 2 for dollar value variances by gate and success criteria results, respectively.

Table 1: Cycle V5 payroll validation testing variances by gate

Gate	Earnings variance	Other earnings variance	Deductions variance	Taxes variance	Net variance
1	$0.00	$354.20	$1,957.41	$1,611.46	$3,923.07
2	$957.71	$2,337.15	$3,409.68	$2,445.51	$9,150.05
3	$0.00	$394.07	$2,735.48	$1,004.25	$4,133.80
4	$0.00	$363.40	$440.98	$128.07	$932.45
5	$0.00	$12,279.65	$2,126.91	$9,377.18	$23,783.74
6	$53,628.21	$187,630.81	$10,927.26	$13,825.82	$266,012.10
7	$53,628.21	$213,712.42	$25,148.38	$20,501.94	$312,990.95
8	$65,379.05	$213,647.60	$28,822.74	$19,558.92	$327,408.31
9.2	$88,880.73	$218,036.85	$29,143.04	$19,836.58	$355,897.20
10 Adj	$53,870.28	$42,819.51	$6,768.48	$14,805.01	$118,263.28

Table 2: Cycle V5 success criteria results

Success criteria	Criteria met?	Percentage of cheques within variance	Number of cheques outside threshold
Gross Pay is within +/- $0.03 variance for 99% of cheques.	yes	99.99%	66 cheques
Net Pay is within +/- $0.03 variance for 95% of cheques.	yes	99.95%	234 cheques
Of the 5% outstanding:	no	n/a	n/a
tax variance is within +/-$3.00 for 4% of the cheques.	yes	99.98%	105 cheques
1% of cheques are outside the threshold and have an explainable difference.	yes	99.97%	129 cheques
deduction variance is within +/-$1.00 for 4% of the cheques.	yes	99.98%	151 cheques
1% of cheques are outside the threshold and have an explainable difference.	yes	99.98%	83 cheques
Unexplained net variance will be tolerated up to 0.01% for cheques.	yes	0.0041%	19 cheques

Moreover, while the  Project team recommended cycle V5B as the solution to proceed to production, they opted to only produce the required detailed supporting files for gate 6B, but not those for the subsequent 4 gates in this cycle (gates 7B through 10B). While additional options were available to the Project team to produce these files, such as a restoration of the databases, they decided not to proceed in this matter due to budget and schedule constraints. In particular, the team deemed the risk of encountering issues for this cycle as low given that their test results were aligned with those of internal audit for cycle V5. Furthermore, as it would take around 8 hours per gate to produce the required files, the Project team decided to allocate its resources to other tasks on the Project’s critical path. As a result, internal audit is unable to provide assurance that cycle V5B met the success criteria.

5.4 Payroll validation success criteria

In May 2023, the Project’s Project Sponsor and Business Owner agreed for the Project to adopt the same payroll validation success criteria that were used to successfully deliver the Phoenix PeopleSoft 9.2 upgrade, as both projects were deemed to be of comparable complexity. Refer to Appendix E for the approved payroll validation success criteria.

The approved payroll validation success criteria were not consistently reflected in project documents. For example, the Project’s Update Test Plan articulates gross and net pay as well as taxes and deduction thresholds differently than the approved success criteria. These inconsistencies could lead to misinterpretation or misapplication of the testing.

Additionally, the Project team’s results in the summary reports for each gate were calculated based on differences consistent with the Phoenix PeopleSoft 9.2 upgrade. At that point in time, internal audit assessed the payroll validation testing for the upgrade and had no observations regarding the use of differences in the Project team’s calculations, although the success criteria is based on variances. As part of the current assessment of the data migration, internal audit has identified this as a discrepancy, as reported values reflected offsetting amounts rather than depicting the differing figures in their aggregate. While this discrepancy had no impact on achievement of the success criteria the database migration, distinguishing between the terms variance and difference would improve clarity as the Project team uses these terms interchangeably.

Lastly, the success criteria have not been reviewed since November 2020. A periodic review of the criteria, such as the established threshold values, would ensure their continued relevance or support continuous improvements, such as data analytics advancements. Also, the criteria should be periodically reviewed to mitigate risks. For example, during gate 7 for cycle V5, the payroll validation testing results exceeded the tolerance for an unexplainable variance. Subsequently, these variances were explained and, in the end, cycle V5 was found to have met the success criteria. Notwithstanding, this demonstrated that while the criteria are designed to assess the overall effectiveness of the cycle as a whole, incorporating periodic assessments may provide valuable insights. In particular, individual gate results may identify risks that may not be apparent when reporting on the success criteria solely at the end of the cycle.

Lessons learned

(C) The payroll validation success criteria should be consistently documented in project documents to promote a common interpretation and application of the testing. Furthermore, project documentation should clarify that results should be calculated based on variances, not differences.

(D) The payroll validation success criteria should be reviewed periodically to ensure their continued relevance, to support continuous improvements, and to mitigate risks.

6. Conclusion

Overall, internal audit concluded that the payroll validation testing process as well as the results of the reconciliation of the payroll runs carried out on both the current and new databases were largely effective for cycle 5. Due to the inability to obtain evidence, internal audit cannot express a conclusion for cycle V5B. 

While no recommendations were issued as part of this assurance engagement, lessons learned were identified for consideration when conducting similar projects in the future.

7. Acknowledgements

In closing, we would like to acknowledge, recognize, and thank the Project team of the Human Capital Management Solutions Branch for the time dedicated and the information provided during this engagement.

8. Appendix

The following elements are appendices to this audit report.

In this section: 

• Appendix A: Acronyms and abbreviations
• Appendix B: Glossary
• Appendix C: Line of enquiry, criteria, and methodology
• Appendix D: Payroll validation cycles and their purpose
• Appendix E: Approved payroll validation success criteria

Appendix A: Acronyms and abbreviations

ADM

Assistant Deputy Minister

Gartner

Gartner, Inc.

IBM

International Business Machines Corporation

OCAERE

Office of the Chief Audit, Evaluation, and Risk Executive

Project

Pay System, Database and PeopleTools Migration Project

PSPC

Public Services and Procurement Canada

Appendix B: Glossary

Absolute value

The distance of a number from zero regardless if that number positive or negative.

Assurance services^{Footnote 2}

An objective examination of evidence for the purpose of providing an independent assessment on governance, risk management, and control processes for the organization. Examples may include financial, performance, compliance, system security, and due diligence engagements.

Difference

A subtraction that takes away a number or amount from another number or amount.

Gating process

A structured approach used in project management that divides a project into distinct phases or stages with decision points (gates) where progress is evaluated to determine whether the project should proceed, modify, or stop the project.

Payroll validation testing

An approach that provides the opportunity to run payroll processing in a test environment using actual payroll data, and to compare the gross-to-net payroll calculation for employees on both the DB2 and the Oracle databases.

Project Navigator

PSPC’s project management framework that is comprised of 5 unique phases with each representing a series of project management activities and deliverables that must be completed. Each phase leads to a gate that acts as a formal project decision point which must be passed before continuing to the next phase.

Development platform

A software used to develop, customize, and configure an application.

Threshold

The point at which something is experienced or starts to happen or change.

Tolerance

An allowable limit or variation in data measurements.

Variance

The absolute value of the difference.

Appendix C: Line of enquiry, criteria, and methodology

The payroll validation process was operating as intended according to the following criteria:

• roles, responsibilities, authorities, and accountabilities, were defined, documented, communicated, and understood
• the gating process was operating as intended, including the provision of approvals in a timely manner
• pay processing results in the future database was within established variances and thresholds

Methodology

• Conducted interviews with project team and pay operations personnel as well as other stakeholders, as required.
• Reviewed and analyzed relevant, available documentation, including test plan, and execution task list as well as payroll processing results.
• Assessed payroll validation testing results for all 10 gates from the current and future database, including categorizing variances, performing a threshold analysis, and comparing with that of the project team.

Appendix D: Payroll validation cycles and their purpose

Payroll validation cycles and their purpose

Cycle	Purpose
V1 and V1B	To ensure that paycheques are accurate.
V2	To ensure that any changes / fixes from system integration testing / Tax Update Release do not impact the accuracy of paycheques.
V3	To ensure that all standard and non-standard release changes do not impact the accuracy of paycheques.
V4	To ensure that all standard and non-standard release changes do not impact the accuracy of paycheques prior to the deployment date.
V5 and V5B	Contingency cycles in case any critical issues were previously encountered that require solutioning and retesting.

Appendix E: Approved payroll validation success criteria

An Assistant Deputy Minister (ADM) Special Committee comprised of representatives from PSPC, Treasury Board of Canada Secretariat, the Employment and Social Development Canada, and the Canada Revenue Agency were specifically tasked, as representatives of the Employer, to set the tolerance levels and thresholds for payroll validation for the Phoenix PeopleSoft 9.2 update. These recommendations were endorsed by a PeopleSoft 9.2 ADM User Acceptance Board on November 5, 2020, and approved for use for the payroll validation testing, by the Project Sponsor and System Business Owner, in May 2023.

The success criteria are as follows:

• gross Pay is within +/- $0.03 variance for 99% of cheques
• net Pay is within +/- $0.03 variance for 95% of cheques
  • of the 5% outstanding, tax variance is within +/-$3.00 for 4% of the cheques, and 1% of cheques are outside the threshold and have an explainable difference
  • of the 5% outstanding, deduction variance is within +/-$1.00 for 4% of the cheques, and 1% of cheques are outside the threshold and have an explainable difference
• unexplained net variance will be tolerated up to 0.01% for cheques

Copyright information

© His Majesty the King in Right of Canada, as represented by the Minister of Public Works and Government Services, 2025.

Audit of Payroll Validation - Phoenix Database Migration.

Cat. No.: P4-171/2025E-PDF (electronic PDF, English)
International Standard Book Number (ISBN) : 978-0-660-77640-8

Cat. No.: P4-171/2025F-PDF (electronic PDF, French)
ISBN: 978-0-660-77641-5