{"id":1110,"date":"2026-11-11T21:12:36","date_gmt":"2026-11-11T21:12:36","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=1110"},"modified":"2026-11-11T21:12:36","modified_gmt":"2026-11-11T21:12:36","slug":"payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/","title":{"rendered":"Payroll Management Software in Kenya: How to Prove a Pay Run Balances"},"content":{"rendered":"<figure><img decoding=\"async\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/11\/zamacore-payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances-flier.webp\" alt=\"ZamaCore guide to checking payroll changes before releasing a pay run\"><\/figure>\n<p>A finance manager opens a pay run on Thursday afternoon. The total is close to last month. The bank file agrees with the payroll summary. Then a supervisor calls about a technician who moved branches halfway through the month. His allowance went to someone with a similar name, and a new starter is missing altogether. A payroll can balance perfectly and still pay the wrong people.<\/p>\n<p>For buyers of payroll management software in Kenya, that distinction changes the demonstration. Ask a supplier to run a fictitious payroll with known exceptions, identify each change and explain what happens after approval. Give the supplier no real employee details. The test should reach beyond the payslip to the payment instruction, accounting entry, rejected payment and correction. Decide what your own team expects before watching the software calculate anything.<\/p>\n<p>The examples below concern controls and buying decisions. Use your payroll professional&#8217;s approved calculations and current official instructions for your actual workforce. Kenya Revenue Authority explains the employer&#8217;s role in deducting and remitting PAYE and publishes guidance on taxable employment income. Use that source when specifying the rules a proposed system must support. <a href=\"https:\/\/www.kra.go.ke\/individual\/individual-pin-registration\/93-tax-obligations\" target=\"_blank\" rel=\"noopener\">KRA employer PAYE guidance<\/a>.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Build_a_payroll_with_five_fictional_people\" >Build a payroll with five fictional people<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Set_a_timetable_people_can_actually_follow\" >Set a timetable people can actually follow<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Make_payroll_inputs_traceable\" >Make payroll inputs traceable<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Understand_the_rule_behind_each_line\" >Understand the rule behind each line<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Review_movement_before_reviewing_totals\" >Review movement before reviewing totals<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Separate_preparation_approval_and_release\" >Separate preparation, approval and release<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Trace_the_payment_instruction_to_the_bank_response\" >Trace the payment instruction to the bank response<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Bring_the_general_ledger_into_the_trial\" >Bring the general ledger into the trial<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Provide_payslips_people_can_understand\" >Provide payslips people can understand<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Correct_a_closed_run_without_losing_its_history\" >Correct a closed run without losing its history<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Know_what_a_suppliers_price_covers\" >Know what a supplier&#8217;s price covers<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Rehearse_the_first_live_month\" >Rehearse the first live month<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Put_recovery_arrangements_through_a_pay_day_rehearsal\" >Put recovery arrangements through a pay day rehearsal<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Give_the_reviewer_a_clean_evidence_pack\" >Give the reviewer a clean evidence pack<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/zamacore.com\/blog\/payroll-management-software-in-kenya-how-to-prove-a-pay-run-balances\/#Ask_for_a_result_the_payroll_team_can_defend\" >Ask for a result the payroll team can defend<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"s1\"><span class=\"ez-toc-section\" id=\"Build_a_payroll_with_five_fictional_people\"><\/span>Build a payroll with five fictional people<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Choose five deliberately different employees. One has the same salary and details as the previous month. One joins partway through the period. One leaves after receiving an advance. One transfers between cost centres. One has overtime approved after timesheets close. Give them stable identifiers and names chosen for the exercise. The first person tests consistency. The other four force the software to explain how dated events enter a run.<\/p>\n<p>Put the expected result on paper before asking the supplier for a demonstration. Your qualified payroll reviewer can prepare an independent expected calculation for each employee using the rates, classifications and period relevant to the trial. Record the intermediate amounts and rounding method. A net pay figure alone gives the supplier little direction when something differs. The reviewer needs to distinguish a different input from a different rule.<\/p>\n<p>Set up two people with nearly identical names. Change the bank account on one record through the approved test procedure. Can the payroll officer tell which person changed, who authorised the instruction and whether the bank file contains the expected destination? Keep the test fictional and restrict the sample output. The objective is to check identity and separation of duties without copying real bank details into a supplier&#8217;s environment.<\/p>\n<p>Include a person who should receive nothing this period. A terminated employee may remain in history for reporting. An unpaid worker may need a recorded explanation under your policy. An empty payslip, an unintended bank line and a correct exclusion produce different outcomes. Write down the one you expect. Inspect the employee list, payment instructions and variance report to see whether that exclusion remains understandable after the run closes.<\/p>\n<h2 id=\"s2\"><span class=\"ez-toc-section\" id=\"Set_a_timetable_people_can_actually_follow\"><\/span>Set a timetable people can actually follow<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Start from the planned payment date and work backwards. Allow time for employees&#8217; submitted hours, supervisor review, HR changes, payroll preparation, independent review and authorised release. Include the time finance needs to resolve unexplained variances. A timetable that assigns every task to the last afternoon leaves the organisation one missing manager away from a rushed decision.<\/p>\n<p>Define what closes at each cutoff. Closing timesheets may stop ordinary submissions while still allowing a documented late correction. Closing payroll calculations may freeze the version for review. Releasing the bank file may create a further boundary beyond which corrections require a separate process. If the tool has a single button labelled close, ask the supplier to show which actions remain possible afterwards and who may perform them.<\/p>\n<p>Give late items a visible destination. Imagine the technician&#8217;s overtime arrives after the payroll officer has produced the variance report. The responsible manager needs to know whether it will be included through a controlled reopening, deferred according to the approved policy or processed through another authorised run. Leaving the item in an inbox transfers the decision to whoever happens to notice it first.<\/p>\n<p>Put named deputies on the calendar. The payroll supervisor might be on leave when finance needs approval. A deputy should have a defined scope and period of authority and should not gain power to approve their own changes. Test the deputy account in the demonstration. After delegation ends, attempt the same approval again. Both successful and denied actions help show whether the timetable can survive normal staff absences.<\/p>\n<h2 id=\"s3\"><span class=\"ez-toc-section\" id=\"Make_payroll_inputs_traceable\"><\/span>Make payroll inputs traceable<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Every amount needs a business explanation. Base salary follows an approved employment record. Overtime may follow a signed shift record. An allowance may follow an assignment. A recovery may follow an authorised advance. During discovery, write the source, owner, effective date and approval requirement next to each pay element. This creates a map that a reviewer can use when a number changes unexpectedly.<\/p>\n<p>Avoid using employee names as the key between systems. Names can vary across rosters and payroll records. Prefer an agreed internal identifier and validate it before importing any values. Test a file with a mistyped identifier, a duplicate row and an inactive employee. Find out whether a bad row blocks the entire file, whether good rows enter a draft and how the person who supplied the file receives the error report.<\/p>\n<p>Make import behaviour explicit. A timesheet file may give total hours for the period or incremental hours since the last upload. Sending the same file twice should produce the result your team expects under the agreed format. A replacement must clearly identify the earlier batch. Ask to see a register of imported batches, their source, counts, rejected items and the payroll version that consumed them.<\/p>\n<p>Keep a route for exceptional manual entries. There will be circumstances in which an approved adjustment cannot arrive through the usual integration. Record the amount, reason, source reference, reviewer and affected period. Require enough evidence to explain it months later. Check whether a manual entry silently recurs next month. A one time reimbursement can turn into a recurring pay error if the default frequency is wrong.<\/p>\n<h2 id=\"s4\"><span class=\"ez-toc-section\" id=\"Understand_the_rule_behind_each_line\"><\/span>Understand the rule behind each line<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A pay element includes more than its display name. It may have a calculation basis, frequency, start and end dates, accounting destination, rounding approach and interaction with other elements. Two allowances with similar names can have different treatment under the employer&#8217;s approved rules. Give each element a clear definition and an owner who is authorised to confirm changes before they reach production.<\/p>\n<p>Ask the supplier to demonstrate a rule change that begins next month. Run the existing period under its original settings, then run the future period under the new setting. Reopen the earlier calculation in a test environment and inspect its history. An updated rule should not silently rewrite the explanation of a paid amount. An authorised correction should identify what changed, why it changed and which period receives the effect.<\/p>\n<p>Ask how an update from the supplier becomes an update in your organisation. Who monitors official announcements? Who verifies applicability to your workforce? Who checks sample calculations and signs off? Who can postpone an update when information is incomplete? A software release notice is one input to that process. The employer still needs a record of the applicable source, effective date, test evidence and approval.<\/p>\n<p>Rounding can create stubborn differences. Two systems may round an intermediate amount at different stages yet display the same headline inputs. Ask the reviewer to retain intermediate values for the test employees. Check whether exports preserve the precision payroll uses and whether accounting totals reconcile to the displayed figures. Agree who decides the treatment of residual differences under the applicable rules before a small discrepancy becomes a monthly unexplained adjustment.<\/p>\n<h2 id=\"s5\"><span class=\"ez-toc-section\" id=\"Review_movement_before_reviewing_totals\"><\/span>Review movement before reviewing totals<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Build a bridge from last period&#8217;s payroll to this one. Begin with the prior total, subtract departures, add joiners and classify changes for continuing employees. Separate overtime, allowances, corrections and other identifiable movements. The bridge helps a reviewer see whether the current result follows from documented changes. It also reveals offsetting errors that disappear when only the grand total receives attention.<\/p>\n<p>Use a deliberately simple illustration with fictional amounts. A KES 8,000 allowance goes to employee B instead of employee A. The total allowance expense stays the same, and both the bank file and ledger can still balance. A review by employee identifier and change reference exposes the error. Add a second test in which two opposite manual adjustments cancel each other. Find both through a list of changes before comparing totals.<\/p>\n<p>Define meaningful review thresholds. A large change in cash terms may deserve investigation for a senior employee. A smaller change may be equally significant for somebody whose pay is usually stable. Agree a combination of amount, percentage and event based checks. Some events, such as a new payment destination, deserve review regardless of value. Ensure each flagged item has an explanation or an owner before approving the run.<\/p>\n<p>Keep the review list short enough to use. If every routine allowance creates a warning, reviewers learn to dismiss warnings reflexively. Group expected recurring changes separately and highlight missing approvals or unusual combinations. Track the items that escape detection and adjust the rules after each cycle. A dashboard that gradually becomes quieter because problems were fixed is different from one made quieter by suppressing inconvenient alerts.<\/p>\n<h2 id=\"s6\"><span class=\"ez-toc-section\" id=\"Separate_preparation_approval_and_release\"><\/span>Separate preparation, approval and release<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A payroll processor needs enough access to prepare the run. A reviewer needs enough information to challenge it. A bank release officer needs an approved payment instruction. Combining all three roles in one account removes an important opportunity to catch a wrong destination or amount. In a small team, agree compensating review with a suitably authorised person and document when that review occurs.<\/p>\n<p>Demonstrate what happens when payroll changes after approval. An employee&#8217;s bank account changes while the payment file awaits release. The earlier approval covered an earlier version. The tool should make the change visible and apply the agreed requirement for renewed review. Simply retaining an approved status after material edits can give the release officer false confidence. Show both the previously approved version and the proposed replacement.<\/p>\n<p>Test access with accounts representing real jobs. A branch supervisor should not gain the national payroll simply because they approve hours for one branch. An administrator managing software settings may not need unrestricted payslip access. Ask a supplier to open an employee record through a saved link and through a report export under the restricted account. Visibility on a menu is only one route to sensitive information.<\/p>\n<p>Review emergency access separately. If the payroll lead is unavailable and a deputy needs temporary authority, record who granted it, what the deputy may do and when it ends. Make sure emergency arrangements do not permit the deputy to both create and release an unreviewed payment. Rehearse the route with the fictitious pay run. During a real deadline, people are more likely to follow a control they have used before.<\/p>\n<h2 id=\"s7\"><span class=\"ez-toc-section\" id=\"Trace_the_payment_instruction_to_the_bank_response\"><\/span>Trace the payment instruction to the bank response<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A bank file records what the employer intends to pay. The bank&#8217;s response records what happened next. Do not equate exporting a file with successful payment. Ask the supplier how your finance team records rejection, partial acceptance, delayed processing and final settlement under your bank&#8217;s actual arrangements. Verify current file specifications directly with the provider involved rather than assuming one format works for every bank.<\/p>\n<p>Give the trial five payment instructions and make one fail using the agreed test method. The system should let finance identify the affected employee without exposing the others&#8217; pay to an unnecessary audience. Find the original instruction, the bank reference where available and the approved correction. Preserve enough evidence to show why a second payment is appropriate and which first attempt it replaces.<\/p>\n<p>Consider the uncertain response. Someone submits a file and the browser connection fails before confirmation appears. Resending the whole file immediately risks duplicate payments if the bank already accepted it. Define how the release officer checks the status through an authorised channel and records the outcome before resubmission. Ask the supplier how the software identifies a repeated batch and whether file versions are distinguishable by a human reviewer.<\/p>\n<p>Reconcile payment amounts by destination and state. The approved net payroll may include an item held for investigation. A bank response may include fees or lines rejected for another reason. Explain the difference between amounts approved, instructed, accepted and settled. A finance officer should be able to produce that explanation after close without asking the original preparer to reconstruct events from memory or screenshots.<\/p>\n<h2 id=\"s8\"><span class=\"ez-toc-section\" id=\"Bring_the_general_ledger_into_the_trial\"><\/span>Bring the general ledger into the trial<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Payroll posts several types of amounts. Finance may need wage expense by department, amounts due to employees, statutory and other liabilities, and records of later settlement. Work with the accountant to map each payroll element to the correct accounts and dimensions. Ask for an example journal and trace a few lines back to identifiable payroll components without circulating employee level details to everyone who sees the ledger.<\/p>\n<p>The technician&#8217;s transfer is a good accounting test. Decide whether salary follows effective dated allocation, a period end department or another approved rule. Then calculate the expected split using an illustrative amount and the agreed allocation basis. Inspect each branch posting as well as the combined total. A journal that balances globally can still charge the entire cost to the wrong location.<\/p>\n<p>Test the handling of an unknown cost centre. Should the export stop, route the item for correction or use a specifically approved suspense process? A hidden default can accumulate months of misallocated expense. Ask who reviews exceptions, how often they are cleared and how the correction reaches the ledger. If suspense is allowed, agree the report and ownership before launch rather than discovering the balance at year end.<\/p>\n<p>Run the journal export twice and inspect the accounting side. Receiving the same totals twice is not harmless when both journals post. Use a stable run identifier, batch reference or approved import control to distinguish a replacement from a new posting. If payroll is reversed, finance needs a clear linked reversal or adjustment path. Have an accountant complete that task in a trial company and keep the observed result with the selection notes.<\/p>\n<h2 id=\"s9\"><span class=\"ez-toc-section\" id=\"Provide_payslips_people_can_understand\"><\/span>Provide payslips people can understand<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A payslip is often the only part of the payroll system an employee sees. Give the fictitious technician a slip containing ordinary pay, an acting allowance, overtime and a single adjustment. Ask a colleague unfamiliar with the configuration to explain which period each item covers and why net pay changed. Labels meaningful only to a payroll analyst will generate questions even when every arithmetic step is sound.<\/p>\n<p>Show how a corrected payslip is identified. If a mistake is discovered after employees download the first version, a replacement must be distinguishable from its predecessor. Decide how the employee learns about the correction and how the payroll team records which version was issued. Avoid displaying sensitive amounts in a general notification when a secure portal can provide the detail through an appropriate access route.<\/p>\n<p>Consider employees without regular computer access. A self service portal may work well for office staff and poorly for field workers who share devices or have intermittent connectivity. Test a modest phone, a forgotten password and the end of a shared session. Ask how employees retain access to appropriate historical information when they leave, consistent with the employer&#8217;s policy and applicable requirements. The answer should be practical for the workforce you actually pay.<\/p>\n<p>Offer a clear route for questions. A payroll enquiry should carry a period, pay element and secure reference rather than requiring the employee to send a full payslip to a group chat. Give the enquiry an owner and a status visible to the employee. A pattern of questions about one label may reveal an unclear policy or a repeated calculation error. Review that pattern while the details of the run remain fresh.<\/p>\n<h2 id=\"s10\"><span class=\"ez-toc-section\" id=\"Correct_a_closed_run_without_losing_its_history\"><\/span>Correct a closed run without losing its history<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A correction has at least three dates. There is the original event, the date the mistake was discovered and the period in which the organisation makes an authorised adjustment. The handling depends on the facts and applicable obligations. The software needs to preserve all three where relevant so reviewers can explain which period was affected and which action eventually resolved the problem.<\/p>\n<p>Return to the misplaced allowance. Identify both affected employees, calculate the differences under the payroll reviewer&#8217;s direction and record the approved treatment. Avoid solving the error by changing the old employee identifier in place and rerunning an already paid period as though nothing happened. Historical instructions and payslips may already have reached employees, banks and finance. The corrected record needs to account for what those parties received.<\/p>\n<p>Ask how a correction reaches statutory reporting and accounting. A revised payroll amount may have consequences beyond the employee&#8217;s net payment. Your qualified reviewer should determine what corrections, notifications or filings apply in the circumstances. The system must give that reviewer a clear list of affected outputs and their status. A lone adjustment on a future payslip does not prove that every related obligation has been addressed.<\/p>\n<p>Practise the reverse case as well. A reviewer suspects an error and later decides the original calculation was correct. Can the organisation document the investigation, close it with a reason and preserve the approved pay run? Good controls allow a question to end without an unnecessary financial transaction. Keep the evidence proportionate and visible only to those who need it. An unresolved flag should not follow an employee indefinitely.<\/p>\n<h2 id=\"s11\"><span class=\"ez-toc-section\" id=\"Know_what_a_suppliers_price_covers\"><\/span>Know what a supplier&#8217;s price covers<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Ask for the full cost of running payroll through the first year and a representative later year. Include configuration, migration, integrations, employee self service, support, routine updates and training. Identify who pays for changes to bank files or accounting interfaces when an external provider changes its specifications. Separate implementation effort from recurring cost so a low subscription cannot disguise a large setup commitment.<\/p>\n<p>Check the unit behind the price. Some offers may count active employees, all stored records or each run. A business with seasonal workers, multiple pay groups or occasional adjustment runs can receive a different bill under each structure. Give the supplier a fictional workforce profile and ask for a worked invoice under the proposed terms. Request an explanation of how a former employee&#8217;s retained record affects billing.<\/p>\n<p>Distinguish a software defect from a paid change. If the software calculates differently from an agreed acceptance example, who investigates and resolves it? If your company adds a new allowance next year, who can configure it and what review is included? Ask both questions using concrete examples. A broad promise of unlimited support says little about response times during payroll week or access to expertise on calculation issues.<\/p>\n<p>Agree how your organisation can leave. Request sample exports for employees, dated rules, closed run results, payslips and audit history in usable formats. Test whether a qualified colleague can interpret those files without the supplier&#8217;s dashboard. An exit plan matters even in a successful relationship because organisations merge, change accounting tools or bring payroll in house. Include the time allowed for retrieval and the handling of remaining copies under the approved arrangements.<\/p>\n<h2 id=\"s12\"><span class=\"ez-toc-section\" id=\"Rehearse_the_first_live_month\"><\/span>Rehearse the first live month<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A parallel run uses the same approved inputs in the old and new process, then compares results before switching responsibility. Select a period containing representative events, including a joiner, a transfer and a late adjustment. Protect the data and define who may see discrepancies. Running two systems can increase exposure if test files are copied freely between personal devices and shared folders.<\/p>\n<p>Compare individual elements before comparing the grand total. Differences may arise from input errors, rule configuration, rounding, effective dates or historical mistakes in the old system. Do not treat the old figure as correct simply because it is familiar. Give each difference a classification, owner and evidence needed for closure. Have the qualified payroll reviewer decide which result represents the approved calculation.<\/p>\n<p>Check downstream actions without sending live payments from the rehearsal. Finance can validate a test bank file through an agreed nonpayment route and post a journal into a trial ledger. HR can verify the employee changes consumed by the run. A representative employee group can review fictional sample slips. These tasks show whether the operating process works after the calculation engine has finished, which is where many expensive surprises occur.<\/p>\n<p>Decide in advance what would delay launch. An unproven bank format, open material variance or unavailable authorised reviewer needs an explicit resolution. A minor cosmetic label may be acceptable with a documented correction date. Separate essential controls from nice improvements and give each decision to a named owner. A deadline has value only when the team knows which evidence justifies proceeding.<\/p>\n<h2 id=\"s13\"><span class=\"ez-toc-section\" id=\"Put_recovery_arrangements_through_a_pay_day_rehearsal\"><\/span>Put recovery arrangements through a pay day rehearsal<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Imagine that a laptop fails after payroll has been approved but before the bank file is released. The team can still reach the hosted application, yet the signed approval is on the failed machine. Recovering software and recovering the evidence needed to act are different tasks. Draw the route from a clean replacement device to the approved run and its supporting record. Identify who can grant access and who can confirm that the replacement file contains the authorised amounts.<\/p>\n<p>Try a second scenario in which the application itself is unavailable. Ask what the provider can restore, from which point in time, and how the employer can determine whether recent changes are missing. A backup taken before two late approvals might be technically sound while representing the wrong payroll version. Keep a controlled register of run identifiers and approval references outside the immediate failure path, with access restricted to the appropriate officers. Use that register to decide what must be reentered and independently checked.<\/p>\n<p>Agree how to communicate a delay. Branch supervisors need a clear update from an authorised person. Employees need a route to ask about their own payments without disclosing private information to colleagues. Finance needs a decision on whether alternative processing is appropriate and who can approve it. A prepared message that states what is known, when the next update is due and where private questions should go is easier to use than a technical outage report copied to the whole workforce.<\/p>\n<p>Measure the recovery rehearsal by completed work. Did an authorised reviewer regain access? Could they reconstruct the correct version, inspect changed inputs and verify the intended payment file? Could the release officer check the bank status without exposing a file to an unapproved device? Record elapsed time, decisions and bottlenecks. The supplier may restore the application quickly while the employer still loses hours waiting for an internal approver or a securely stored reference.<\/p>\n<h2 id=\"s14\"><span class=\"ez-toc-section\" id=\"Give_the_reviewer_a_clean_evidence_pack\"><\/span>Give the reviewer a clean evidence pack<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Before closing the first month, ask the reviewer to assemble the smallest pack another qualified person would need to repeat the review. Include the approved input register, exceptions and resolutions, comparison with the prior run, version approved for payment, bank reconciliation and journal reference. Keep detailed personal data inside the controlled system wherever possible. A portable pack can refer to restricted records by identifier while giving the reviewer enough context to request authorised access.<\/p>\n<p>Read the pack from the perspective of a new finance officer. A note that says a variance was checked gives no indication of which employee, source or rule explains the difference. A dated note identifying the transfer instruction, approved allowance and payment version points directly to the evidence. Use a routine spot check in a later month to see whether those links still open and whether permissions still match the reviewer&#8217;s job.<\/p>\n<h2 id=\"s15\"><span class=\"ez-toc-section\" id=\"Ask_for_a_result_the_payroll_team_can_defend\"><\/span>Ask for a result the payroll team can defend<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>End the supplier meeting with a deliberately awkward question. If the finance director calls three months from now about the transferred technician, what can the payroll supervisor show? Look for the approved input, rule version, calculation, review decision, bank result and ledger posting. Ask a colleague who did not prepare the run to find those records. If the answer depends on one person&#8217;s memory, record that gap in the proposal review.<\/p>\n<p>Include a signed record of any intentionally excluded test employee so a later reviewer can distinguish a correct omission from an accidental missing payment.<\/p>\n<p>The objective is a repeatable month end in which employees receive understandable payments, finance can trace movements, and a reviewer can investigate an exception without reopening every file. Take the five fictional employees, expected calculations and acceptance decisions into your buying brief. For more guides on connecting people, finance and operational records in Kenya, read the <a href=\"https:\/\/zamacore.com\/blog\/\">ZamaCore blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Use five fictional employees to check a Kenyan payroll system from approved input through payslip, bank instruction, ledger and correction.<\/p>\n","protected":false},"author":1,"featured_media":1111,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1110","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1110","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/comments?post=1110"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1110\/revisions"}],"predecessor-version":[{"id":1112,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1110\/revisions\/1112"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media\/1111"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=1110"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=1110"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=1110"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}