Release Notes 26.8.1

Revision Date: August 05, 2026

Important:

This document summarizes the changes to NetSuite for Government between 26.8.1 and the previous release. These release notes are subject to change every week.

The 26.8.1 enhancements and changes listed in this document are not available to customers until they are upgraded to NetSuite for Government 26.8.1. Your access to these features and SuiteApps is subject to the terms of service in your NetSuite for Government contract.

Please also review the NetSuite general release notes for a comprehensive view of changes to the release. During this release period, NetSuite version 2026.1 is released. The general NetSuite release notes are accessible at this link:

https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/book_N3865324.html

NetSuite for Government Version 26.8.1 – Release Date August 05, 2026

Finance:

Quick Code Authorization:
- Authorized Quick Code Department Access
  - A new Quick Code authorization feature is now available to control which department-based Quick Codes each user can view and use. If this feature is not in use, the Approved Quick Code List button is still available on supported transaction screens to allow enhanced searching capabilities.
  - The initial release supports the following transaction types:
    - Purchase Orders
    - Vendor Bills
    - Bill Credits
  - Support for Requisitions, Journals, Accounts Receivable and Cash Receipt workflows is planned for a future release.
    Overview
    - This feature extends the existing NetSuite single-department security model. In the standard model, an employee is assigned to one department, and access is enforced through the Restrictions tab on the role definition for the Account permissions.
    - The new functionality allows an employee to be authorized for Quick Codes associated with multiple departments. Authorized Quick Codes can be displayed through the "Authorized Quick Codes" button and search functionality on supported transaction records.
    Employee Configuration
    - Three new fields are available on the Employee record:
      
      Financial Transactions Authorized Quick Code Departments:
      Use the "Financial Transactions Authorized Quick Code Departments" field to assign an employee to one or more departments. The selected departments determine which Quick Codes are available through the "Authorized Quick Codes" button and search functionality on supported transaction screens.
      
      Enforce Quick Code Department Validation:
      Enable the "Enforce Quick Code Department Validation" checkbox to prevent an employee from using a Quick Code that is not authorized for one of their assigned departments. The Quick Code selection list remains unfiltered. Validation occurs when the transaction is saved. If an unauthorized Quick Code is selected, the transaction cannot be saved until an authorized Quick Code is used.
      
      When this checkbox is disabled, users may still receive a filtered list of Quick Codes for their assigned departments, but they are not prevented from selecting and saving other available Quick Codes.
      
      Allow Specific Quick Code Access:
      Enable the "Allow Specific Quick Code Access" to verify the allowable Quick Code list against the Quick Code record Department Access field. If this box is not checked, then all Quick Codes assigned to the Department(s) on the employee record will be authorized.
    Quick Code Configuration
    - Quick Codes are available for a transaction when the applicable transaction type is included in the "Show In" field on the Quick Code record. By default, all Quick Codes assigned to a department may be available to users authorized for that department.
    - For more detailed access control, enable the “Allow Specific Quick Code Access” checkbox on the Employee record. When enabled, authorization is determined by the "Department Access" multi-select field.
    - A user is authorized to use the Quick Code when at least one department assigned to the employee matches a department selected in the Quick Code’s "Department Access" field.
    Supported Access Scenarios
    - Grant access to all Quick Codes for a department: Assign the department to the employee. This provides access to the department’s Quick Codes without requiring updates to each individual Quick Code.
    - Exclude selected Quick Codes from departmental access: Enable the checkbox for specific Quick Code access and leave the applicable department out of the Quick Code’s "Department Access" field. For example, to prevent a department from using a Legal Expenses Quick Code, do not add that department to the Quick Code’s Department Access list.
    - Make a non-departmental Quick Code available to all departments: Add all applicable departments to the Quick Code’s "Department Access" field. For example, a Miscellaneous Revenue Quick Code can be made available organization-wide by assigning all department codes to it.
    - Give one department access to Quick Codes across multiple departments: Add the department to the Department Access field on each applicable Quick Code. For example, to allow the IT department to use IT-related expense Quick Codes across the organization, add the IT department to each relevant Quick Code.
    - Provide unrestricted access while retaining a department-focused list: Super users may be assigned one or more departments so that their Authorized Quick Code search remains focused on the most relevant Quick Codes. Leave "Enforce Quick Code Department Validation" disabled to allow those users to select and save any available Quick Code, including Quick Codes outside their assigned departments.
    Important Considerations
    - The initial release applies only to Purchase Orders, Vendor Bills and Vendor Credits.
    - The standard Quick Code list is not filtered when validation is enabled.
    - Authorization is enforced when the transaction is saved.
    - The Quick Code must be configured for the applicable transaction type through the "Show In" field.
    - Department-level access can be granted broadly or refined at the individual Quick Code level.
Balancing Segments:
- Support for Customer Deposit Applications using Bank Accounts.
  - Deposit Applications now support balancing for invoices paid with a Customer Deposit through a Customer Payment.
  - When the Customer Deposit posts to a specific bank account:
    - Transaction method: The bank account associated with the Customer Deposit is used to move the cash to the transaction funds. The receivable account on the Customer Payment/ Deposit Application transaction is used to reduce the receivable balance.
    - Specify method: The applicable cash account is determined from the Deposit Application row in Balancing Exceptions. The receivable account on the Invoice row of the Exceptions tab in NS4G System Setup is used to reduce the receivable balance.
  - Customer Deposits posted to an Undeposited Funds account are not yet supported. Support for this scenario is planned for the September release.
- Fund Balancing Support for Sales Tax in Accounts Receivable:
  - NetSuite for Government Balancing Segments now supports fund balancing for sales tax in the Accounts Receivable workflow when using the Specify method.
  - This enhancement ensures that sales tax liability is posted to the line-item transaction fund. It also creates the appropriate due to/due from entries for the sales tax amount associated with the transaction and mainline funds.
  - For Invoices, Credit Memos, Cash Sales, and Refund Cash Sales, the original transaction accrues the sales tax liability from the transaction. Other transactions in the workflow continue to collect the receivable or due to/from amounts, along with the cash collected.
- Fund Balancing Support for Accounts Receivable and Cash Receipts multiple Due To/Due From Accounts:
  - Implemented support for multiple sets of Due to / Due from accounts for the Specify Option for Accounts Receivable Invoices, Cash Sales and Credit Memos. After this change, the balancing lines will read the applicable Invoice, Cash Sale or Credit Memo configuration to obtain the Due to / Due from account to be used in the next step of the workflow such as the Customer Payment, Deposit or Customer Refund.
- New Warning Message for NetSuite for Government Balancing Segment Transaction Updates:
  - A new warning message is now displayed when key information is changed on an Invoice or Customer Payment after the NetSuite for Government Balancing Segment workflow has been completed.
  - The warning identifies whether later transactions in the payment workflow must be opened, edited, and saved to refresh their balancing segment information. This helps prevent downstream transactions from retaining outdated fund balancing values after an earlier transaction is changed.
  - This release supports Invoice and Customer Payment records. Additional transaction types will be supported in future releases.
Utility Billing Integration:
- Automated Utility Billing to NS4G General Ledger Interface:
  - Utility Billing Journal Entry and Vendor Bill files can now be transferred automatically to NS4G, removing the need for manual file uploads. The scheduled process retrieves eligible General Ledger and AP files from OCI Object Storage, saves them to the NetSuite File Cabinet for downstream processing, and moves successfully transferred files(in OCI bucket) to prevent duplicate imports. The process runs daily before the existing Utility Billing import and records file-level failures to support reliable processing.
  - Setup required: Before enabling the integration, an administrator must configure a dedicated OCI service user with Object Storage access, create and upload an OCI API-signing certificate in NetSuite, and populate the scheduled script deployment with the required OCI connection details. At least one source bucket, GL or APAY, must be configured.

Various Fixes and Performance Improvements

Corrected an issue where the PO# was not consistently populated on Vendor Bill lines. Now, the PO# will always be populated when paying the Bill against a purchase order.
New Report: Grant (Segment) Statement of Activity:
- A new "Grant (Segment) Statement of Activity" report is now available. The report displays general ledger revenue and expense activity by the new Grant accounting segment, including item override lines that use grant coding.
- This report provides improved visibility into grant-related financial activity and supports accurate grant reporting and analysis.
Corrected an issue where journal entries did not generate balancing lines when the Balancing Account field was empty. Journal entries now balance correctly even when no Balancing Account is specified.
Corrected an issue where Balancing Segments was running unnecessarily on Deposits when a single fund is used in the mainline and transaction lines for Cash Sales. The balancing lines were not inaccurate, just unnecessary and impacting to the bank reconciliation. An edit and save of the Deposit record will remove the extra lines.
Vendor Prepayment Screen Access Restored:
- An issue that prevented users from accessing the Vendor Prepayment screen has been resolved. Previously, attempting to open the screen could result in the following SuiteScript error:
  - UNEXPECTED_ERROR: An unexpected SuiteScript error has occurred.
  - The Vendor Prepayment screen now opens successfully and can be used to apply vendor prepayments.
- Important: The vendor prepayment must be defined for the same fund to which the prepayment will be applied. The NS4G Balancing Segment process does not currently support vendor prepayments across different funds.
Corrected an issue with the Fixed Asset Management disposal process under the type of Sale using a Quick Codes environment. Previously, an error message stating "Fund, Department, or Account cannot be blank" was presented and the Invoice was not generated. Now, the Invoice will generate successfully without error.

Note:

Custom Employee Center roles will now need access to a new script "NS4G SL Get Record Data" to access Employee Center Requisitions and Purchase Requests. Ensure the Script Deployment record Audience tab has the External Roles field to contain any custom Employee Center roles.

Human Resources and Payroll:

Payroll Batch – Calculate Payroll:
- A new Calculate Payroll button is available on the Payroll Batch when the batch meets the same status criteria currently used for the Recalculate button. Selecting Calculate Payroll opens the Calculate Payroll Suitelet and automatically carries over the pay period from the Payroll Batch where the action was initiated.
  What changed?
  - Adds a Calculate Payroll button to the Payroll Batch.
  - Opens the Calculate Payroll Suitelet when selected.
  - Prepopulates the Suitelet Pay Period field with the originating Payroll Batch pay period.
  - Uses the same batch-status display criteria as the existing Recalculate button.
  User Guide
  1. Open the Payroll Batch for the pay period you want to calculate.
  2. When the batch status makes the existing Recalculate button available, select Calculate Payroll.
  3. On the Calculate Payroll Suitelet, confirm that the Pay Period field is prepopulated with the Payroll Batch pay period.
  4. Continue with the normal Calculate Payroll process.
  Expected Behavior
  - The Calculate Payroll button is not displayed when the Payroll Batch does not meet the same status criteria used for Recalculate.
  - The action retains the pay-period context of the Payroll Batch from which it was launched.
  Verification
  - For a Payroll Batch where Recalculate is displayed, confirm Calculate Payroll is also displayed.
  - Select Calculate Payroll and confirm the Calculate Payroll Suitelet opens.
  - Confirm the Suitelet Pay Period matches the originating Payroll Batch pay period.
  - For a Payroll Batch where Recalculate is not displayed, confirm Calculate Payroll is also not displayed.
Payroll Register – File Cabinet folder selection:
- The Payroll Register Suitelet now limits File Cabinet folder choices to the unique folders configured in Payroll and HR Preferences for all entities. This reduces the folder list evaluated by the Suitelet and improves report-load performance for agencies with large File Cabinet folder counts.
  Background
  
  After the introduction of the new File Cabinet selection logic, the Payroll Register Suitelet could take approximately 90 seconds to load for customers with a large quantity of File Cabinet folders.
  What changed?
  - For every entity, the Suitelet evaluates the configured Payroll Temporary File Folder ID and Pay Period File Folder ID preference values.
  - The Suitelet collects all configured folder IDs, removes duplicates, and displays only the resulting unique folders for selection.
  - The available-folder list is not filtered by the user's employee entity, role, or entity permissions.
  Configuration and User guide
  1. For each entity, open Payroll and HR Preferences > Entity > General.
  2. Review Payroll Temporary File Folder ID and Pay Period File Folder ID and enter the intended File Cabinet folder IDs where applicable.
  3. Open the Payroll Register Suitelet and select a folder from the available File Cabinet folder list.
  4. Ensure File Cabinet folder permissions are configured so users who save reports to a selected folder can also retrieve reports from that folder.
  Folder-Selection Example Entity:
  Entity: Entity 1 | Payroll Temporary File Folder ID: Folder A | Pay Period File Folder ID: Folder B
  
  Entity: Entity 2 | Payroll Temporary File Folder ID: Folder A | Pay Period File Folder ID: Folder B
  
  Entity: Entity 3 | Payroll Temporary File Folder ID: Folder C | Pay Period File Folder ID: Folder D
  
  The Suitelet presents four unique folders for user selection: Folder A, Folder B, Folder C, and Folder D.
  Entity and Permission handling
  - Do not filter the available folders based on the user's employee entity, role, or entity permissions, because these configurations vary across agencies.
  - Assume the administrator has configured File Cabinet folder permissions appropriately.
  - Users who save reports to a selected folder must also have permission to retrieve reports from that folder.
  Verification
  - Configure overlapping Payroll Temporary File Folder ID and Pay Period File Folder ID values across multiple entities, then confirm each folder appears only once.
  - Confirm the Suitelet shows only folders configured through the two Payroll and HR Preferences fields across all entities.
  - Confirm the folder list is not reduced based on the user's employee entity, role, or entity permissions.
  - Confirm the Payroll Register Suitelet load time is improved in an environment with a large quantity of File Cabinet folders.
Payroll Register — Employee Detail Pay Period Mode:
- Employee Detail Pay Period mode now provides a condensed report header on every page, uses Payroll Totals for recalculation-sensitive summary values, and applies Pay Period-specific time-off balance logic. When subtotals are selected, each subtotal page appears before the detail it summarizes.
Report content
- Each PDF page displays a condensed header with the report name, Run by, run date/time, and Pay Period. The header is designed to remain compact and preserve body-content space.
- Employee Detail continues to show employee and payroll information, earnings, deductions, employer-paid benefits, time off, checks and direct deposits, and Pay Summary information.
- Net Pay, Gross Pay, and federal, Social Security, Medicare, and state taxable-wage values use Employee Payroll Totals for the selected pay period so the report reflects post-recalculation values.
- Deduction detail remains sourced from Payroll Audit and item-line data because a corresponding line-level Payroll Totals bucket is not available.
- YTD amounts are evaluated across payroll history so imported or historical activity is included in the register.
Time-off balance logic
- Previous Balance includes payroll totals in Commit Submitted, Committed, and Committed-Historical status from inception through the processed pay period, excluding the current pay period.
- Only payroll totals or payroll item lines with a pay-period payment date on or before the processed pay-period payment date are included in the Previous Balance calculation.
- Earned and Used logic remains unchanged. • Balance is calculated as Previous Balance + Earned - Used.
Example: If Previous Balance is 40 hours, Earned is 8 hours, and Used is 6 hours, the ending Balance is 40 + 8 - 6 = 42 hours.
Subtotals
- When subtotals are enabled, each subtotal summary page precedes the employee detail pages it summarizes so managers and auditors can review rolled-up totals before reviewing detail.
User guide
- Open the Payroll Register Suitelet and select Pay Period.
- Select the applicable pay period and any available filters, sorting, and subtotal options.
- Generate Employee Detail and review the condensed page header, employee detail, Pay Summary, time-off balances, and any selected subtotal pages.
- When reconciling recalculated payroll, use the Gross Pay, Net Pay, and taxable-wage values shown in Pay Summary, which are sourced from Employee Payroll Totals.
Verification
- Confirm the condensed header appears on every PDF page and includes report name, Run by, run date/time, and Pay Period without materially reducing report body space.
- After recalculation, confirm Pay Summary Net Pay, Gross Pay, and taxable wages match Employee Payroll Totals for the selected period.
- Test Time Off before and after payroll commitment; confirm Previous Balance excludes the current pay period, includes only eligible committed statuses, and Balance equals Previous Balance + Earned - Used.
- When subtotals are enabled, confirm each subtotal page appears before the corresponding employee detail pages.

Tax Updates — Georgia State Income Tax:
- The Employee State Income Tax Table has been revised to incorporate Georgia's 2026 state income-tax brackets.
  User Guide
  - No configuration change is required. The revised Employee State Income Tax Table is used when Georgia state income tax is calculated for 2026 payroll activity.
  Verification
  - For a Georgia employee with 2026 payroll activity, confirm state income tax is calculated using the revised 2026 table.
  - Confirm the Georgia tax calculation remains available through the standard payroll process.
Year-End Reporting — 2026 W-2 Form:
- Report 8 now supports the 2026 W-2 form. The new form adds box 14b, Treasury Tipped Occupation Code(s), and renames the existing Other field to box 14a Other.
  Form changes
  - Box 14b Treasury Tipped Occupation Code(s) is added beneath box 12d in the right-hand code column.
  - Box 14b provides one entry line divided into two fill spaces by a center divider.
  - Boxes 9 through 12d are compressed to accommodate box 14b within the existing right-hand column footprint.
  - Box 14 Other is renamed box 14a Other and spans the full left-hand block.
  Form selection
  - For W-2 reporting years 2025 and earlier, the existing W-2 form remains in use.
  - For W-2 reporting years 2026 through 2099, the new 2026 W-2 form is used.
  - When a W-2 Reporting Period is created for 2026 or later, the 2026 W-2 form is selected by default. For years before 2026, the existing form is selected by default.
  User Guide
  - Create or open the W-2 Reporting Period for the intended reporting year.
  - For reporting years 2026 through 2099, confirm the 2026 W-2 form is selected for Report 8.
  - Review box 14a Other and, when applicable, enter the Treasury Tipped Occupation Code(s) in box 14b using the two available fill spaces.
  - Generate the W-2 and confirm the resulting PDF uses the appropriate form for the selected reporting year.
  Verification
  - Create Reporting Periods for 2025 and 2026 and confirm the existing form defaults for 2025 while the 2026 form defaults for 2026.
  - Confirm the 2026 form remains the default for a future reporting year through 2099.
  - Confirm box 14a Other spans the left block and box 14b appears under box 12d in the right-hand column with two fill spaces and a center divider.
  - Confirm the revised layout retains boxes 9 through 12d and renders cleanly in the generated W-2 PDF.
Maine PERS — Electronic Payroll Filing:
- Maine Public Employees Retirement System (MainePERS) reporting is now supported. The module creates MainePERS Employee Retirement Reporting Records and generates the monthly Electronic Payroll File (EPF) for submission through the Employer Self-Service portal.
What is included?
- MainePERS is available when Payroll and HR Preferences > State is Maine.
- The module supports the MainePERS fixed-width ASCII EPF: 256 characters per record, plus a carriage return and line feed.
- For each employer location, the generated file contains one Header record, one or more Detail records, and one Summary record.
- The generated file uses the MainePERS original-filing naming pattern: [EmployerCode][MM][YY]O.txt.
- Multiple entities are supported within one Reporting Period. File metadata is sourced from the selected entity with the lowest internal ID when more than one entity is included.
- The Reporting Period Frequency value is now used for MainePERS reporting.
Employer and reporting-period setup
1. Set Payroll and HR Preferences > State to Maine and select Maine Public Employees Retirement System for the applicable employer configuration.
2. On the Reporting Period, enter the MainePERS Location Code assigned to the employer. This value is required for MainePERS file generation and is reported on each Detail and Summary record.
3. Create or update active Employee Retirement records using the NS4G Maine PERS Retirement System form. The record must overlap the Reporting Period dates.
4. For each applicable employee, enter the required Personnel Status Code, Position Classification Code, Retirement Plan Participation Status, Benefit Plan Class, and Rate Schedule Number. Enter Time Unit Code and Payroll Cycle when applicable.
5. Map Maine PERS Earnable Compensation, Maine PERS Employee Retirement Contributions, and Maine PERS Payback Contributions (SCP) to the appropriate pay codes. For teacher employers, also map the Maine PERS grant-funded compensation and employer-contribution buckets when applicable.
Reporting Period Frequency
- The Frequency field is hidden by default on the Reporting Period in View mode.
- In both Edit and View modes, display Frequency only when the selected State Retirement System is Public Employee Retirement System of Idaho (PERSI) or Maine Public Employees Retirement System (MainePERS).
- For MainePERS, select the applicable Frequency because the value is used for MainePERS reporting.
- The field description is: Pay cycle reporting frequency.
Calculate and file process
1. Create the monthly MainePERS Reporting Period with the applicable entities, reporting dates, and Location Code.
2. Select Calculate to create reporting records for employees with qualifying pay activity and an active, overlapping Employee Retirement record.
3. Review payroll totals and the MainePERS configuration values on the reporting records.
4. Generate the EPF and confirm Header, Detail, and Summary order for each employer location.
5. Upload the .txt file to MainePERS ESS, then complete Import, Validate, and Process.
Processing details
- Employees with valid matching pay activity are included even when their wage total is zero. Employees with no pay activity in the Reporting Period are not included.
- An employee may receive multiple Detail records in a month when multiple position classification codes apply.
- Detail records use uppercase, left-justified alphanumeric values; numeric fields use the required zero-filled and implied-decimal formatting.
- Summary totals aggregate the Detail records for each employer loation. Retiree Returned to Work (Personnel Status Code 53) earnable compensation is excluded from the total earnable-compensation summary amount.
Verification
- Confirm Maine-specific forms, values, and pay buckets are available only when Maine is active.
- Confirm Frequency is hidden in Edit and View modes unless PERSI or MainePERS is selected; for MainePERS, confirm the value is used and the description reads Pay cycle reporting frequency.
- Confirm file generation is blocked with a clear error when the MainePERS Location Code is missing.
- Confirm the EPF is fixed-width ASCII, has 256 characters before CR/LF, and uses the expected filename pattern.
- For a multi-entity Reporting Period, confirm each location has its own Header, Detail, and Summary sequence and that file-level metadata uses the selected entity with the lowest internal ID.
- Confirm Detail and Summary amounts reconcile, including multiple position-code records, zero-wage employees with qualifying activity, employer-paid participation, and Personnel Status Code 53 handling.
Florida Retirement System — 415 Limit:
- Florida State Retirement System reporting now applies the Internal Revenue Code §415 eligible-compensation limit based on the Reporting Period year.
Calculation logic
- During Reporting Period calculation, evaluate Year-to-Date 415 Eligible Compensation (custrecord_ns4g_empsrr_415elig) against the limit for the Reporting Period year.
- When custrecord_ns4g_empsrr_415elig exceeds the applicable limit, set the reported amount to that limit.
- The reporting-year parameter allows the limit to change in future years without applying the same amount to every reporting year.
2026 Limit Schedule
- Reporting Period Year: 2025 and Earlier | 415 Eligible Compensation Limit: $70,000.00 • Reporting Period Year: 2026 through 2099 | 415 Eligible Compensation Limit: $72,000.00
Examples
- For a 2025 Reporting Period with Year-to-Date 415 Eligible Compensation of $72,500.00, the reported amount is capped at $70,000.00.
- For a 2026 Reporting Period with Year-to-Date 415 Eligible Compensation of $73,500.00, the reported amount is capped at $72,000.00.
User Guide
1. Create or open the Florida State Retirement System Reporting Period for the applicable reporting year.
2. Run Calculate using the standard Reporting Period process.
3. Review Year-to-Date 415 Eligible Compensation (custrecord_ns4g_empsrr_415elig) on the Employee Retirement Reporting Record.
4. When the calculated amount exceeds the limit for the Reporting Period year, confirm the reported value is capped at the applicable limit.
Verification
- For a 2025 or earlier Reporting Period, confirm a value above $70,000.00 is capped at $70,000.00.
- For a 2026 Reporting Period, confirm a value above $72,000.00 is capped at $72,000.00.
- For either reporting year, confirm a value at or below the applicable limit is unchanged.
- Confirm the limit selected for each calculation is based on the Reporting Period year rather than the current calendar year.
Vermont DC Retirement File:
- The Vermont Municipal Employee Retirement System Defined Contribution (VMERS DC) file now uses the Reporting Period Reporting Date in its filename, creates one reporting record and file line per qualifying Employee Payroll Totals record, and defaults the employee and employer contribution rates.
File naming
- The generated file name is DC1MMDDYY.txt, where MMDDYY is derived from Reporting Period > Reporting Date.
Employee selection and record creation
- Using the Reporting Period selected in Define Data, search Employee Payroll Totals whose related Pay Period Retirement Date (Pay Period > custrecord_ns4g_payperiod_persdate) matches the Reporting Period Date.
- Include Employee Payroll Totals only when the employee has a Vermont Municipal Employee Retirement System DC retirement record (Payroll ID: ns4g_vmersdc_retire) that overlaps the Reporting Period.
- An Employee Retirement record overlaps when its Begin Date is on or before the Reporting Period End Date and its End Date is blank or on or after the Reporting Period Begin Date.
- Create a unique Employee Retirement Reporting Record for every qualifying Employee Payroll Totals record, and sum and group hour and pay buckets by that corresponding total record.
- Create one unique file line for each Employee Retirement Reporting Record.
Multiple payroll batches
- For a weekly payroll client reporting biweekly, each qualifying payroll batch produces its own Employee Retirement Reporting Record. For example, when an employee is paid in both a regular and supplemental pay period and each Pay Period Retirement Date matches the Reporting Period Date, the system creates two Employee Retirement Reporting Records and two corresponding file lines for that employee.
Contribution-rate defaults
- Employee Rate defaults to and is set as .050000.
- Employer Rate defaults to and is set as .060000.
User Guide
1. Create or open the VMERS DC Reporting Period and confirm the Reporting Date.
2. In Define Data, select the Reporting Period and run Calculate.
3. Review the Employee Retirement Reporting Records generated for each qualifying Employee Payroll Totals record and confirm the employee and employer rates.
4. Generate the retirement file and confirm the DC1MMDDYY.txt filename and one file line per reporting record.
Verification
- Confirm the file name uses the Reporting Period Reporting Date in MMDDYY format.
- Confirm Employee Payroll Totals are selected only when their Pay Period Retirement Date matches the Reporting Period Date and the employee's active VMERS DC retirement record overlaps the Reporting Period.
- For a weekly payroll employee paid in regular and supplemental batches with matching Retirement Dates, confirm two reporting records and two file lines are created.
- Confirm Employee Rate defaults to .050000 and Employer Rate defaults to .060000.
- Confirm hour and pay buckets are summed and grouped independently for each Employee Payroll Totals record.
Idaho PERSI Arrivos Transmittal File:
- The Idaho PERSI Arrivos Transmittal file is now supported. The module generates the pipe-delimited wage and contribution file required for submission through the Arrivos Employer Reporting Portal.
What is included?
- Each Transmittal file contains one Header record (format ID 1), one or more Detail records (format ID 4), and one Footer record (format ID 9).
- The Transmittal file is pipe-delimited ASCII text. Numeric values use two decimal places, dates use MMDDYYYY, and pipe characters in alphanumeric values are replaced with a space.
- The file name follows PERSI[Reporting Period Date], for example PERSI12022025 for a December 2, 2025 Reporting Date.
- At file generation, Detail records are sequenced in order and the Footer summarizes compensation, other pay, non-pensionable compensation, employee contributions, and the Detail record count.
Employer and reporting-period configuration
- Set Payroll and HR Preferences > State to Idaho and activate the Idaho PERSI State Compliance Setup values, including the applicable Retirement Plan and Member Type values.
- Use the NS4G Idaho Retirement System form for Employee Retirement records. Complete the Idaho PERSI field group for each participating employee, including the applicable plan and Member Type.
- Create the Idaho PERSI Reporting Period with Entity, Begin Date, End Date, Reporting Date, and Frequency. Frequency (custrecord_ns4g_reportingperiod_frequency) is sourced from Pay Cycle values and is required when Idaho PERSI is selected.
- Map Idaho Compensation, Other Pay, Non-Pensionable Compensation, Employee Contributions, and applicable worked-hours buckets to the correct pay codes.
Calculate and file process
- Run Calculate for the Reporting Period. The process selects Employee Pay Period Totals whose Pay Period Retirement/PERS Reporting Date matches the Reporting Period Reporting Date.
- Confirm the employee has an active, overlapping Employee Retirement record for Public Employee Retirement System of Idaho. When multiple records overlap, the record with the greatest End Date is used.
- Review the Employee Retirement Reporting Records. Active employees with a qualifying Idaho retirement record are included even when unpaid in the reporting cycle, with zero Compensation and Contributions when applicable.
- Generate the file and confirm the Header, Detail, Footer record order and the PERSI[Reporting Period Date] filename.
Submission order
- Submit the Enrollment file first for new employees, then submit a Class and Status Change file when changes occurred and submit the Transmittal file last.
Verification
- Confirm the Idaho PERSI Frequency field is required on the Reporting Period and appears only when Idaho PERSI is selected.
- Confirm eligible paid employees with matching Reporting Dates are included and relevant pay and hour buckets are summed on their reporting records.
- Confirm an active employee with a qualifying Idaho retirement record is included even with no pay activity, with zero Compensation and Contributions when applicable.
- Confirm the generated file contains one Header, Detail records, and one Footer; uses pipe delimiters; and has the expected PERSI[Reporting Period Date] filename.
- For a multi-entity Reporting Period, confirm the Header employer code and pay-cycle schedule name are sourced from the selected entity with the lowest internal ID.
Payroll Calculations and Fund Balancing:
- FLSA Regular Rate Overtime with Additional Pay:
  - A new Hour Code calculation rule calculates an FLSA regular-rate overtime premium by combining eligible additional pay converted to an hourly amount with average overtime-cycle earnings.
  Setup
  - Create an Hour Code with the calculation rule FLSA Regular Rate OT Premium (Hourly Add Pay Rate) and Payroll ID ns4g_hc_otflsamultpaddpay.
  - Set the Hour Code Default Amount to the overtime multiplier to apply to the calculated regular rate.
  - For each eligible Additional Pay record, classify the Pay Code as Additional Pay and select Include in Add Pay Rate.
  - Confirm the employee Position and Pay Record associated with the timecard entry has the appropriate Annual Hours value.
  Calculation behavior
  - Eligible Additional Pay records must start on or before the Pay Period End Date and end on or after the Pay Period Begin Date.
  - For each eligible record, the Add Pay Cycle Hourly Rate is (Amount × Payouts Per Year) ÷ Annual Hours. The amount uses the employee Pay Code Amount, or the Hour Code Default Amount when the employee amount is blank.
  - A percentage employee amount or percentage Default Amount produces a processing error. Precision is applied after the calculation is complete.
  - The system sums each eligible Add Pay Cycle Hourly Rate, then calculates Regular Rate = Add Pay Hourly Rate + (Total Base Wages ÷ OT Cycle Hours).
  - Base wages use the primary pay bucket and cycle hours use the primary hour bucket defined on the Overtime Cycle. The overtime Hour Code is processed with priority to prevent recursive calculation loops.
  - The adjusted overtime rate is Regular Rate × the Hour Code Amount or Multiplier field (custrecord_ns4g_hourcode_defaultrate). The total overtime amount is the adjusted rate × hours.
  Worked example
  - Assume eligible Additional Pay is $50.00, Payouts Per Year is 26, Annual Hours is 2,080, overtime-cycle wages are $1,500.00, overtime-cycle hours are 40, the Hour Code multiplier is 1.5, and 5 overtime hours are paid.
  - Add Pay Hourly Rate = ($50.00 × 26) ÷ 2,080 = $0.625.
  - Base hourly rate = $1,500.00 ÷ 40 = $37.50; Regular Rate = $0.625 + $37.50 = $38.125.
  - Overtime rate = $38.125 × 1.5 = $57.1875; overtime amount = $57.1875 × 5 = $285.9375 before the applicable final precision is applied.
- Fund Balancing — Option A:
  - Payroll can now add explicit inter-fund Due To and Due From lines to balance an employee's payroll by fund when earnings are posted to a fund other than the employee's default fund.
    Configuration
    - In Payroll and HR Preferences, select Payroll Balancing Segments. The balancing logic runs only when this preference is selected.
    - Select the Balancing Segment Account. This field is sourced from the Account list, appears after Payroll Balancing Segments, and is enabled only while Payroll Balancing Segments is selected.
    - Confirm NS4G System Setup > Balance Sheet Department is configured. Every balancing line defaults to this Department.
    Processing behavior
    - Only the Fund dimension is evaluated. An earnings line is treated as overridden when its posting Fund differs from the employee's Default Fund Allocation; Department, Account, and Subledger differences are ignored.
    - Existing earnings, deductions, employer liabilities, and net-pay lines retain their current amounts and funds. Net pay and deductions are not split across funds.
    - For each fund on the employee record, the system calculates total Debits − total Credits after the real payroll lines are posted.
    - For a net-credited fund, the system adds a Due From debit; for a net-debited fund, it adds a Due To credit. No line is added for a fund that is already balanced.
    - Each balancing line posts to the configured Balancing Segment Account, defaults to the Balance Sheet Department, appears on the Employee Posting Detail, and flows to the Payroll GL transaction.
    - One balancing line is created per unbalanced fund as needed. The combined Due From debits always equal the combined Due To credits.
    - When Payroll Balancing Segments is not selected, no explicit balancing lines are created and NetSuite's native balancing behavior continues.
    Worked example
    - Assume $1,000.00 of salary posts to default Fund 10 and $100.00 of stipend posts to override Fund 20. Taxes, deductions, and net pay totaling $1,100.00 credit Fund 10.
    - Fund 20 has a $100.00 debit and no credit, so it receives a $100.00 Due To credit.
    - Fund 10 has $1,000.00 of salary debit and $1,100.00 of credits, so it receives a $100.00 Due From debit.
    - After the balancing lines, Fund 10 has $1,100.00 of debits and credits, Fund 20 has $100.00 of debits and credits, and the $100.00 Due From debit equals the $100.00 Due To credit.
    Verification
    - Confirm a fund with a debit surplus receives a Due To credit and a fund with a credit surplus receives a Due From debit.
    - Confirm every affected fund balances to zero and total Due From debits equal total Due To credits.
    - Confirm multiple override funds receive their own balancing lines and an override equal to the default fund does not create a balancing line.
    - Confirm disabling Payroll Balancing Segments produces no explicit lines and retains current posting behavior.
Payroll Register — Employee Summary and Warnings:
- Pay Period Mode now includes an Employee Summary and Warnings page that highlights zero-net-pay employees, employees excluded by pay-period preferences, and Social Security or Medicare withholding variances.
  Availability and employee summary
  - Employee Summary and Warnings is available only in Payroll Register Pay Period Mode; it is not available in Payment Date Range Mode.
  - The Employees with Zero Net Pay summary lists employees with a $0.00 Net Pay for the selected pay period who have an associated payroll item.
  - The zero-net-pay list displays Employee Name, Employee ID, Entity, and Net Pay. Employees not included in the payroll batch or excluded from processing are not listed.
  - The warning label is Employees Excluded Due to Zero or Negative Net Pay. It identifies employees removed by the pay-period preference setting and excludes employees with zero or negative net pay.
  Social Security mismatch
  - The Social Security Mismatch display includes Employee, Employee ID, Social Security Wages, EE Calculated, EE Withheld, EE Variance, ER Calculated, ER Paid, and ER Variance.
  - Social Security Wages, employee withholding, and employer-paid amounts are sourced from Pay Stub Details. EE Calculated and ER Calculated equal Social Security Wages × 0.062.
  - EE Variance equals EE Calculated − EE Withheld. ER Variance equals ER Calculated − ER Paid.
  - Display an employee only when the absolute value of either variance is greater than $0.03, allowing normal one- or two-cent rounding differences.
  Example:
  - With $2,000.00 in Social Security Wages, calculated tax is $2,000.00 × 0.062 = $124.00. If EE Withheld is $123.95, EE Variance is $124.00 - $123.95 = $0.05, so the employee is displayed.
  Medicare mismatch
  - The Medicare Mismatch display includes Employee, Employee ID, Medicare Wages, EE Calculated, EE Withheld, EE Variance, ER Calculated, ER Paid, and ER Variance.
  - Medicare Wages, employee withholding, and employer-paid amounts are sourced from Pay Stub Details. ER Calculated equals Medicare Taxable Wages × 0.0145.
  - EE Calculated uses the Medicare tax calculation described below. EE Variance equals EE Calculated − EE Withheld; ER Variance equals ER Calculated − ER Paid.
  - Display an employee only when the absolute value of either variance is greater than $0.03. Only prior payment dates are included in the Additional Medicare calculation.
  Medicare tax calculation
  - For the reporting pay period, retrieve Payroll Totals with the same Pay Period year and a Payment Date before the Reporting Pay Period Payment Date. Exclude the reporting pay period.
  - Sum the Medicare Taxable Wage Bucket (ns4g_mcaretx_pay) from those records to determine year-to-date Medicare taxable wages before the reporting payroll, then obtain the current-period amount from the same bucket.
  - Compare prior year-to-date Medicare taxable wages plus current-period wages to the $200,000 Additional Medicare Tax threshold, splitting current wages between amounts under and over the threshold when needed.
  - Calculate wages under $200,000 at 1.45% (0.0145) and wages over $200,000 at 2.35% (0.0235), which includes 1.45% Medicare plus 0.9% Additional Medicare Tax.
  - Use only the Medicare Taxable Wage Bucket amount in this calculation, not total gross pay.
  Example:
  - If prior year-to-date Medicare taxable wages are $199,900.00 and current-period Medicare taxable wages are $1,500.00, $100.00 is taxed at 1.45% and $1,400.00 is taxed at 2.35%. EE Calculated = ($100.00 × 0.0145) + ($1,400.00 × 0.0235) = $1.45 + $32.90 = $34.35.
  User Guide
  - Open Payroll Register and select Pay Period Mode, then select the applicable pay period.
  - Generate the report and review the Employee Summary and Warnings page for zero-net-pay and exclusion warnings.
  - Review Social Security and Medicare mismatch rows when a displayed variance exceeds $0.03.
  Verification
  - Confirm Employee Summary and Warnings does not appear in Payment Date Range Mode.
  - Confirm employees with an associated payroll item and $0.00 Net Pay appear with the specified columns, while employees omitted from the batch or excluded from processing do not appear.
  - Confirm a $0.03 or smaller absolute Social Security or Medicare variance is not displayed, while a variance greater than $0.03 is displayed.
  - Test Medicare taxable wages below, crossing, and exceeding $200,000 to confirm the 1.45% and 2.35% calculations and prior-payment-date selection.

Various Fixes and Performance Improvements

1 Release Notes 26.8.1