Testing the UKG Payroll-to-Bank-File Process
UKG payroll bank file testing verifies the business process that turns confirmed net pay into an actual movement of money — building the direct-deposit ACH file in NACHA format, producing check and positive-pay files for the remainder, footing control totals to the pay register, honouring prenotes, transmitting to the bank, and reconciling the bank's confirmation back to the run. SyntraFlow is an AI-powered UKG payroll and workforce assurance platform, Oracle-native and expanding to UKG, whose architecture is designed to prove the bank file is complete, correctly formatted and reconciled before a single dollar leaves the account.
File generation
Confirm net pay produces a valid NACHA ACH file plus check and positive-pay files.
Control totals
Foot batch and file totals so what the bank debits equals the net pay register.
Prenote & routing
Validate routing and account numbers, prenote status and the account hash total.
Confirm & reconcile
Match the bank acknowledgement and returns back to the run before close.
Process overview
Payroll-to-bank file is the last mile of a pay run. Once payroll has been calculated and confirmed, net pay for every worker is split by payment method — most into direct deposit, some into printed checks, occasionally across multiple accounts — and a file-generation step assembles the bank instructions. For ACH direct deposit that means a NACHA-formatted file with a file header, batch headers, entry detail records carrying each employee's routing number, account number, amount and transaction code, batch and file control records, and a block count. For checks it means a check register and a positive-pay file the bank uses to authorise each cheque presented. This is the moment a pay register becomes money in employees' accounts.
Testing this process matters because it is irreversible and public. A calculation error can be caught before confirmation; a bank-file defect is felt the morning of payday. A transposed routing number, an amount off by a decimal, a prenote ignored, a duplicate batch, or a control total that no longer foots does not error inside UKG — it surfaces as a returned deposit, a rejected file, an overdrawn funding account, or a wave of employees who were not paid. Proving the file is complete, correctly formatted and reconciled to the register before transmission is the difference between a routine payday and a payroll incident with a public face.
This page describes the happy-path flow, the preconditions and test data it needs, the positive and negative scenarios that give real coverage, and where the process crosses into the bank and other systems. It sits downstream of the generate payroll extract and calculate payroll processes, and complements the module-level UKG payroll interface testing capability; here the focus is the bank file as a discrete, testable business process.
Preconditions
The bank file only produces a trustworthy result when the state upstream of it is correct. Before the process runs, a test environment needs the following in place.
- ▸Payroll calculated and confirmed. The pay run is complete and confirmed, so net pay is final and locked; the file is generated from confirmed results, never from an open or in-progress run.
- ▸Direct-deposit elections and prenotes. Each worker's bank instructions — routing number, account number, account type, allocation split and prenote status — are on file, and new or changed accounts are in their expected prenote state.
- ▸Bank profile and file format configured. The company's ODFI details, immediate origin, company identification, offset and settlement rules and the NACHA layout are defined and point at the correct bank and funding account.
- ▸Check and positive-pay setup. Check stock, numbering and the positive-pay file layout the bank expects are configured for the non-direct-deposit population.
- ▸Transmission channel and credentials. The delivery path to the bank — secure SFTP, bank portal or connector — is reachable, and the bank is ready to accept a file for the target settlement date.
User roles
The bank file sits at the end of a chain of hand-offs, and each role owns a checkpoint the test should reflect.
| Role | Responsibility in the process |
|---|---|
| Employee | Enters and maintains direct-deposit elections and account splits that become the entry detail records. |
| Payroll administrator | Confirms the pay run, generates the bank file, reviews control totals and releases it for transmission. |
| Payroll manager | Approves funding and the net-pay total, and signs off the file before money moves. |
| Treasury / banking | Funds the settlement account, receives the file at the bank and returns acknowledgements and returns. |
| Integration / IT owner | Maintains the bank profile, NACHA and positive-pay layouts and the transmission channel. |
Required test data
A meaningful bank-file test needs employee profiles that exercise every payment method, allocation and prenote path the file must survive. A representative data set includes:
- ▸Single-account direct deposit. An hourly hospital employee with all net pay to one checking account, the mainstream ACH entry detail case.
- ▸Multi-account allocation. A retail employee splitting net pay by fixed amount and remainder across checking and savings, testing that allocations sum exactly to net pay.
- ▸New account on prenote. A manufacturing worker whose newly entered account is still in prenote, so this run pays by check rather than to an unverified account.
- ▸Check-only worker. An employee with no direct-deposit election, to confirm the check register and positive-pay file carry them and the ACH file does not.
- ▸Union employee with an off-cycle amount. A supplemental or retro net amount added to a run, confirming it lands in the file at the correct total.
- ▸Employee working across locations. A worker paid from one company but charged to two legal entities, testing that the correct originating batch and offset carry the payment.
- ▸Zero-net and reversal cases. A worker whose net pay is zero after deductions and one requiring a prior-deposit reversal, to confirm each is handled per policy rather than sent in error.
Main process steps
The happy-path flow for a scheduled or on-demand bank-file run follows a predictable sequence. A test asserts the correct outcome at each step, not just the final file.
- 1Confirm the pay run. The process selects only confirmed net pay for the target pay group and settlement date; open or unconfirmed runs are excluded.
- 2Split by payment method. Net pay routes to direct deposit, check or a mix, and multi-account elections are allocated by fixed amount and remainder rules.
- 3Apply prenote logic. Accounts still in prenote are paid by check or held per policy; verified accounts flow into the live ACH entry detail records.
- 4Build the NACHA file. File and batch headers, entry detail records, batch and file control records, entry hash, and debit/credit totals are assembled to the bank's layout.
- 5Generate check and positive-pay files. The non-direct-deposit population produces a check register and a positive-pay file matching the bank's format.
- 6Foot control totals. The run tallies entry count, entry hash, total credits and total debits and reconciles them to the confirmed net-pay register before release.
- 7Review and release. The payroll manager confirms funding and the net total and, when they foot, releases the file for transmission.
- 8Transmit and reconcile. The file is delivered to the bank, the acknowledgement is captured, and any returns or NOCs are matched back to the run at reconciliation.
Positive test scenarios
Positive scenarios confirm the bank file generates, formats, foots and transmits correctly for realistic UKG variations. All examples are illustrative and would be tuned to your configuration.
| # | Scenario | Expected outcome |
|---|---|---|
| P1 | Hourly hospital employee with all net pay to one checking account | One credit entry detail record with correct routing, account and amount; totals foot |
| P2 | Retail employee splitting net pay across checking and savings | Fixed amount and remainder allocate correctly; the split sums exactly to net pay |
| P3 | Manufacturing worker with a new account still in prenote | Prenote account is not paid live; the worker is paid by check this run per policy |
| P4 | Check-only employee with no direct-deposit election | Worker appears in the check register and positive-pay file, not the ACH file |
| P5 | Union employee with an off-cycle supplemental net amount | Supplemental amount lands in the file at the correct total and settlement date |
| P6 | Employee paid across two legal entities | Correct originating batch and offset carry the payment; the file still foots |
| P7 | Full pay group generated on the scheduled settlement date | Entry count, entry hash, credits and debits match the confirmed net-pay register |
| P8 | Bank returns a confirmation and one prenote notification of change | Acknowledgement reconciles to the run; the NOC updates the account for next cycle |
Negative test scenarios
Negative scenarios prove the process refuses, holds or flags bad data rather than moving money it should not — where a mistake becomes a returned deposit or a funding shortfall.
| # | Scenario | Expected outcome |
|---|---|---|
| N1 | Invalid routing number that fails the ABA check digit | Record is rejected and reported before build, not written into the ACH file |
| N2 | Allocation split that does not sum to net pay | Mismatch is flagged; the file is held rather than under- or over-paying the worker |
| N3 | File control total does not foot to the net-pay register | Out-of-balance run is blocked before release, not transmitted silently |
| N4 | Duplicate transmission of a file already sent | Duplicate is detected by file ID or hash and blocked to prevent double payment |
| N5 | Prenote account paid live before verification completes | Prenote status is enforced; the unverified account is not sent a live credit |
| N6 | NACHA field or block-count drift after a format change | Layout validation fails fast; a malformed file is not delivered to the bank |
| N7 | Positive-pay file missing a check that was printed | Register and positive-pay file are reconciled; the gap is surfaced before release |
| N8 | Settlement date on a bank holiday or non-business day | Effective date is validated against the banking calendar and corrected, not sent late |
Rule variations
The same run produces different bank files depending on the payment, banking and security rules behind net pay. Coverage must account for how each rule reshapes the output.
- ▸Allocation rules. Fixed-amount, percentage and remainder elections across multiple accounts must sum exactly to net pay; a rounding or ordering error leaves a worker short or over-paid.
- ▸Prenote and account status. New, changed and failed-prenote accounts follow different paths — held, paid by check, or activated live — and each must be honoured for the run's effective date.
- ▸Multi-bank and multi-entity. Different pay groups, ODFIs or legal entities produce distinct batches, company identifications and offsets, so each combination needs its own header, funding and total checks.
- ▸Off-cycle and reversals. Supplemental runs, manual checks and reversal or reclaim entries change transaction codes and totals, and must reconcile without disturbing the on-cycle file.
- ▸Security and banking data. Access to routing and account numbers is sensitive, so masking, encryption in transit and role-based visibility are considerations to confirm, and mis-scoped access can expose or omit a population.
Integration checkpoints
The bank file is by definition an integration point — it is where UKG hands off to a financial institution — so it sits alongside the boundaries that UKG integration testing covers across the estate. The checkpoints that matter most for this process are these.
- ▸Payroll to bank. Confirmed net pay leaving UKG must arrive at the bank complete and correctly formatted; this is the same class of file boundary the payroll interface testing capability validates in depth.
- ▸Bank acknowledgement and returns. The bank's accept response, returns and notifications of change are checkpoints: a file that transmits but is rejected or partly returned is not a successful run until it is reconciled.
- ▸General ledger and treasury. The net-pay debit and its offset must agree with the payroll-to-general-ledger posting and the funding entry, so cash and the ledger reconcile after payday.
- ▸Cross-application payroll. Where employees are paid from Workday or Oracle payroll alongside UKG, following net pay across systems with different keys and calendars to confirm the totals agree is a genuine SyntraFlow differentiator.
Expected outcome & evidence
A correct run ends with a NACHA file the bank accepts, a check register and positive-pay file that reconcile, and file control totals — entry count, entry hash, total credits and debits — that foot exactly to the confirmed net-pay register, with every routing and account number valid and every prenote honoured. Just as important as the outcome is the evidence a test captures to prove it — the audit trail a treasury lead, a payroll manager or an auditor can review after the fact.
- ▸Control-total reconciliation. A side-by-side of the net-pay register and file totals — entry count, entry hash, credits, debits — showing they foot on both sides of the hand-off.
- ▸Format and field validation log. Confirmation the NACHA file matched the layout, with headers, entry detail, batch and file control records and block count correctly populated.
- ▸Prenote and account audit. Evidence that every routing number passed its check digit and every prenote account was routed per policy, with none paid live prematurely.
- ▸Check and positive-pay reconciliation. Proof the check register and positive-pay file agree, so every printed cheque is authorised and none is missing.
- ▸Transmission, acknowledgement and returns. Proof of delivery, the bank's accept response, and any returns or NOCs matched back to the run, closing the loop on the money movement.
SyntraFlow automation approach
SyntraFlow is designed to turn bank-file testing into a reusable, data-driven assertion rather than a manual eyeball of a file the morning of payday. A single master scenario models the process end to end — confirm, split by method, apply prenote logic, build the NACHA file, generate check and positive-pay files, foot control totals, release and reconcile — and is exercised against many employee permutations from a data set, so single-account, multi-account, prenote, check-only and multi-entity cases run from one maintained test.
Because the bank file is highly structured data, it suits automated validation especially well. The platform is designed to parse the generated NACHA file, verify each entry detail record's routing check digit, account and transaction code, recompute the entry hash and batch and file control totals, and reconcile them to the confirmed net-pay register before anything is transmitted. It can diff allocations against elections, confirm prenote accounts were held or paid by check per policy, and reconcile the check register to the positive-pay file. Self-healing execution is intended to keep those checks running as UKG screens and bank layouts evolve, so regression after a configuration or version change is a reviewable difference rather than a payday scramble. Every run captures the reconciliation, validation and acknowledgement evidence described above.
AI is designed to assist and recommend — profiling a NACHA or positive-pay layout, drafting validation rules from a sample and a specification, and flagging the accounts and fields most likely to break on a change. It accelerates analysis; it never approves a pay run, funds an account or transmits a file. Payroll and treasury owners remain responsible for approving payroll, releasing the file and moving money, and banking and compliance dimensions such as NACHA rules, account privacy and multi-state wage payment are considerations to confirm with your accountable teams, not legal certification. These capabilities reflect design intent for an early, roadmap-stage UKG offering and are available for demonstration and proof-of-concept validation.
Frequently asked questions
What is UKG payroll bank file testing?
UKG payroll bank file testing verifies the business process that turns confirmed net pay into a movement of money — building the NACHA direct-deposit file, producing check and positive-pay files, footing control totals to the pay register, honouring prenotes, and reconciling the bank's confirmation. It proves the file is complete, correctly formatted and balanced before any funds leave the account.
How is the bank file different from the payroll extract?
The extract hands payable time from UKG WFM to a payroll engine before pay is calculated. The bank file comes after payroll is calculated and confirmed, turning net pay into ACH, check and positive-pay files for the bank. This page tests that final money-movement step as a runbook; the extract page tests the earlier time-to-payroll hand-off.
Why do control totals matter in the bank file?
Control totals — entry count, entry hash, total credits and total debits — are how a test proves nothing was dropped, duplicated or altered between the net-pay register and the file the bank debits. A file can look right yet mis-total by a decimal; footing it to the register catches that before release, not after employees are underpaid or the funding account is overdrawn.
How should prenotes be handled in a test?
A new or changed direct-deposit account in prenote should be paid by check or held per policy, not sent a live credit before verification. A negative test asserts exactly this, because paying an unverified account risks a returned or misdirected deposit. Once the prenote clears, the account should activate for the next cycle, which the reconciliation step confirms.
Can SyntraFlow reconcile the bank file across UKG and Workday or Oracle?
Yes — cross-application reconciliation is a genuine SyntraFlow differentiator. The architecture is designed to follow net pay across systems that use different keys, calendars and rounding, and confirm the bank totals agree with each source. As with all UKG coverage this is early and roadmap-stage, available for demonstration and proof-of-concept validation.
Does AI approve or transmit the bank file?
No. AI is designed to assist and recommend — profiling NACHA layouts, drafting validation rules and flagging accounts or fields likely to break on a change. It accelerates analysis but never approves a pay run, funds an account or transmits a file. Payroll and treasury owners remain responsible for releasing the file and confirming banking and compliance considerations with their accountable teams.
Where should we start with bank file testing?
Start with an assessment that captures your bank profile, NACHA and positive-pay layouts and highest-risk populations — multi-account, prenote and multi-entity workers. Scope a proof-of-concept that reconciles file totals and validates routing and prenote handling for a recent run, then reuse those checks for regression after each configuration or version change. Schedule a demonstration to begin.
Related UKG testing
Calculate payroll
Confirm net pay is correct before it becomes the bank file's source of truth.
Generate payroll extract
Test the earlier hand-off of payable time from UKG WFM to the payroll engine.
Payroll to general ledger
Verify the GL posting that must agree with the net-pay debit and its offset.
Payroll interface testing
The module-level capability for every file flowing into and out of UKG payroll.
Integration regression
A use case for re-validating the bank file and every interface after a change.
UKG testing overview
The pillar hub for validating UKG Pro and UKG Pro WFM across the estate.
Prove the bank file before it becomes payday
Move from eyeballing a NACHA file to boundary-level assurance designed to confirm your payroll bank file is complete, correctly formatted and reconciled to the register before money moves. Start with an assessment and a proof-of-concept against your highest-risk populations.