4 Release Notes 25.10.1

NetSuite for Government 25.10.1 Release Notes

Revision Date: October 08, 2025

Important:

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

The 25.10.1 enhancements and changes listed in this document are not available to customers until they are upgraded to NetSuite for Government 25.10.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 is transitioning from 2025.1 to 2025.2. Customers may be on either release. 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 25.10.1 – Release Date October 08, 2025

Finance:

  • Purchase Change Orders:
    • We are pleased to announce enhancements to how Encumbrance Effective Dates are managed on Purchase Order (PO) and Change Order (CO) lines, providing users with greater flexibility, control, and accuracy in budget tracking.

      Key Enhancements:

      • Editable Effective Date:
        • The Encumbrance Effective Date is now exposed and editable on both Purchase Order and Change Order lines, allowing users to define the date when an encumbrance becomes effective.
      • Intelligent Defaulting Behavior:
        • On creation, the Effective Date defaults to the Purchase Order date for new Purchase Order, regardless of whether this date is in the past or future.
        • On edit, if the PO date is in the future, the Effective Date defaults to the PO date. If the PO date is in the past, the Effective Date defaults to today’s date.
        • If a user selects or changes the date, the system honors the user’s choice and does not override it during save.
        • If the user does not select an Effective Date, during save, the system sets it to the greater of today’s date or the PO date.
      • Encumbrance Transaction Logic:
        • For new Purchase Order encumbrances, the encumbrance date is always the PO date, regardless of the Effective Date specified at creation.
        • For edits and Change Orders, all encumbrance transactions use the specified Effective Date for improved accuracy and auditability.
      • Change Order Line Handling:
        • When a Change Order is created, existing lines inherit the Effective Date from the underlying PO lines. When adding new lines within a Change Order, the Effective Date defaults to the CO date unless the user selects a different date.

      Note:

      Budget checking still occurs at the Transaction Date level on the Purchase Order Date or Change Order Effective Date. An enhancement is planned to allow budget checking to occur on the Effective Date.
    • Implemented an encumbrance type of "Encumbrance" for Change Order update to encumbrances.
  • Multi Subsidiary Support:
    • Standard NetSuite for Government forms now provide a warning message on selection of a fund which does not belong to the subsidiary, and a blocking message if trying to save under this condition.
  • Utility Billing Integration:
    • Added functionality for importing Check Refunds from Utility Billing. For additional information on this integration, please see SuiteAnswers article "Utility Billing Refund Import".
  • Budget Adjustment Budget Periods:
    • A new validation is available on the Government Budget Adjustment which will give a block to users if entering a GL string outside of the existing budget dates. This is to ensure that the government budget is configured without overlapping budget dates.
  • 1099-S Support:
    • A new custom record has been created for 1099-S Real Estate Transactions. This record is not yet attached to the Bill, Bill Credit or Check Forms, but it is available now to add permissions in anticipation of using this functionality.
  • Item Code Account Override:
    • The Item Account Override feature now supports custom segments. Once a custom segment is defined with the GL Impacting posting turned on, the segment value will be mapped to the revenue and expense lines in the Item Override feature.
  • Fund Segment:
    • Updated the "Major / Non-Major" field to indicate that the field is "Major". If checked, this can be used for grouping major funds as well as indicating which funds are "Non-Major" for grouping on financial statements.
    • The Restrict to Department selection on the Fund record is no longer required since it's not applicable to Quick Code forms.
    • Enhanced the user Experience within the Standard NetSuite for Government Fund form by grouping the fields into:
      • Primary Information
      • Reporting Classifications
      • Permissions on Fund Validation
      • Balances
Various Fixes and Performance Improvements
  • Purchase Orders now support the ability to enter a negative line item to support discounts and other use cases.
  • Corrected an issue where the Quick Code on transactions was not set properly when entering in the applicable Quick Code GL Segments.
  • Corrected an issue where the Fiscal Calendar permission was removed after each NetSuite for Government update.
Human Resources and Payroll:
  • Employee Posting Detail Feature:
    • The new Employee Posting Detail record provides enhanced visibility and more detailed tracking of payroll-related transactions. Instead of summarizing amounts by employee and general ledger (GL) string only, this feature adds another level of detail by also grouping and reporting data by pay code or hour code.
      What’s New:
      • Detailed Reporting: Each Employee Posting Detail record is tied to a single employee and separates transactions according to pay code or hour code as well as GL string. This enables more granular analysis and makes it easier to track specific payroll components. This record will be enabled for analytic reports and saved search reports.
      • Record Accessibility: You can view Employee Posting Detail records directly from both the Payroll Item record and, if configured, from related Payroll GL Transaction records.
      • Editable Records: These records are editable, in a future release, you will have the ability to make corrections or override values as needed before posting.

      Note:

      At this time, the Employee Posting Detail is for informational purposes only and does not impact the Payroll GL Transaction Record. You can continue to commit payroll even when errors are shown in the Posting Detail Status, and current commit and posting processes remain unchanged. Additional features and functionality will be made available in a future release.

      How It Works:
      • Automatic Generation: After completing payroll calculations, the system will automatically create Employee Posting Detail records for all employees included in the run. Each record displays individual lines for every combination of employee, pay or hour code, and GL string.
      • Selective Recalculation: If you need to recalculate payroll for a specific employee, the system only updates Employee Posting Detail records for that individual, ensuring accuracy and efficiency. Users can opt out of calculating the Employee Posting Detail record at the time of calculating payroll by unchecking the box. However users will need to recalculate the employee posting detail records prior to generating the Payroll GL Transaction.

        Tip: For a smooth payroll process and accurate reporting, leave the Calculate Employee Posting Detail option selected unless you need to manage this step manually.

      How to Use:
      1. Access the Feature:
        • When running payroll using the Calculate Payroll screen, you’ll find a checkbox labeled Calculate Employee Posting Detail.
        • By default, this option is selected. This means the Employee Posting Detail records will be created automatically after payroll processing.
        • If you prefer to generate these details at a later time, you can uncheck the box.
      2. Viewing Details:
        • After payroll is processed, navigate to the Payroll Batch> Employee Payroll Item record to view the Employee Posting Detail.
        • Related records are accessible from a dedicated Employee Posting Detail subtab on the Payroll Item screen, conveniently located to the right of the Direct Deposit subtab.
      3. Exporting or Grouping Data:
        • When viewing records, you can use analytics or saved search reports to export the data and group by pay code and hour code for reporting purposes. The payment date can be used as a search filter to look at a single period or several pay periods in one report.
      4. Manual Corrections:
        • If further adjustments are needed, you can edit the Employee Posting Detail records directly to ensure accurate reporting prior to GL posting. The Payroll GL Transaction transactions lines will use the Employee Posting Detail records during generation.

      Example:
      • Suppose your organization pays Social Security, Medicare, and several types of benefits and deductions. Previously, these items for each employee could be grouped into a single total under the same GL account. Now, with Employee Posting Detail, each type (such as Social Security Deduction, Social Security Benefit, Medicare Deduction, and Medicare Benefit) appears as a distinct line, allowing you to see amounts broken down by pay code or hour code.

      Here is a user guide version of your requirements, focusing on how the system works and how users can use these new capabilities:

      Using the Posting Detail Status in Payroll Batch:

      The Payroll Batch page now includes a new field called Posting Detail Status. This field helps you track the progress and completion of payroll posting processes for employees. Below you'll find details on what the new field means and how you can use it to monitor and troubleshoot payroll posting.

      What Posting Detail Status Shows:

      The Posting Detail Status field displays the current status of the employee payroll posting process. Here’s what each status means:

      • Pending: The system is preparing to run the posting process.
      • Processing: The posting process is actively running. Please note: The status may only update after the payroll calculation is complete.
      • Complete: The posting process finished successfully with no errors.
      • Complete – Errors Occurred: The posting process finished, but some errors were encountered.
      • Null/Blank: No status is shown for historical periods where no posting was generated.
      • Commit-Submitted: The commit action has been completed, matching the Payroll Batch status.
      • Committed: The related Payroll GL transaction record has been posted, and employee payroll detail records are now locked for editing.

      How the Status Updates:

      • While the process is running, the status updates to Processing.
      • The update might only happen after payroll calculations are finished.
      • If the process finishes successfully, the status changes to Complete.
      • If there are errors during processing, the status will show Complete – Errors Occurred.
      • For historical periods (where there is no related posting), the field remains blank.

      Troubleshooting Errors:

      • The Posting Detail Status will display Complete – Errors Occurred.
      • You can find a description of the error(s) in the Processing Error Message field. This field can be added to a custom view.
      • If both calculation and posting errors exist, both will be visible for your review.
      • An error will also appear if the employee's payroll was calculated and the employee posting detail was not processed and is now out of sync. Future releases will provide additional error guidance in resolving these errors.

      This feature will not yet prevent a user from committing or generating the Payroll GL Transaction. This record is only informational at this time but will be required in a future release.

      Reviewing and Resolving Errors:

      • Use the existing Payroll Item custom Error view to review both calculation and posting detail errors for easy troubleshooting.
        To fix issues:
        • Correct any errors as described under the error message.
        • Recalculate payroll for affected employees. In many cases, rerunning the Posting Detail process (via its Map/Reduce script) will also clear the errors.
        • For a simple workflow, correcting the data and recalculating payroll is usually sufficient.

      Additional Features:

      • You can now manually rerun the Posting Detail process for a specific employee or for the entire batch by using the newly added manual logic options.
      • The system now provides Payroll Batch Internal ID and Employee Internal ID fields to support recalculations for either all employees in a batch or an individual employee.
      If you need further assistance with these features, please consult your system administrator or refer to internal help documentation.
  • W-2 – Agency Contact, Address Updates and Compliance Settings:
    • New W2 Reporting Address Fields

      The following fields have been added, allowing agencies to specify an address for W2 reporting that may be different from the company’s main address. This is especially useful if W2 addresses vary between entities and are not the same as the address set on the company information page.

      For W2 reporting ensure these fields are updated prior to processing W2s.

      Navigation: Payroll and HR Preferences > Compliance > W2
      • W2 Employer Name: custrecord_ns4g_payrollhrprefs_w2legal
      • W2 Location Address: custrecord_ns4g_payrollhrprefs_w2loc
      • W2 Delivery Address: custrecord_ns4g_payrollhrprefs_w2deliv
      • W2 City: custrecord_ns4g_payrollhrprefs_w2city
      • W2 State Abbreviation: custrecord_ns4g_payrollhrprefs_w2state
      • W2 ZIP Code: custrecord_ns4g_payrollhrprefs_w2zip
    • W‑2 Compliance Fields — What’s Used and From Where changing source of information.

      These updates control how the RA (Submitter) and RE (Employer) records are populated in the W‑2 file.

      Overview:
      • These updates control how the the RA (Submitter) and RE (Employer) records are populated in the W‑2 file.
      Which entity’s preferences are used in the system?
      • Use Parent Entity Payroll and HR Preferences for the RA Submitter Record = Checked:
        • Uses the Parent Entity’s Payroll and HR Preferences for all RA fields listed below.
      • Use Parent Entity = Unchecked and you select a different entity:
        • Uses the selected entity’s Payroll and HR Preferences for all RA fields listed below.
      • RE record:
        • Always use the Payroll and HR Preferences of the entity associated with that RE (per entity on the Reporting Period).

      RA record field sources:

      • User Identification (positions RA 12–19)
        • Payroll and HR Preferences > Compliance > BSO User ID
        • Field ID: custrecord_ns4g_payrollhrprefs_w2bso
      • Resub Indicator (RA 29)
        • Reporting Period > Record Is Resubmission
        • Field ID: custrecord_ns4g_reportingperiod_isresub
        • Map true = 1, false = 0
      • Resub Wage File Identifier (WFID) (RA 30–35)
        • Reporting Period > Resubmission Wage File Identifier
        • Field ID: custrecord_ns4g_reportingperiod_wfid
      • Company Name (RA 38–94)
        • Payroll and HR Preferences > W2 Employer Name
        • Field ID: custrecord_ns4g_payrollhrprefs_w2legal
      • Location Address (RA 95–116)
        • Payroll and HR Preferences > W2 Location Address
        • Field ID: custrecord_ns4g_payrollhrprefs_w2loc
      • Delivery Address (RA 117–138)
        • Payroll and HR Preferences > W2 Delivery Address
        • Field ID: custrecord_ns4g_payrollhrprefs_w2city
      • City (RA 139–160)
        • Payroll and HR Preferences > W2 City
        • Field ID: custrecord_ns4g_payrollhrprefs_w2city
      • State Abbreviation (RA 161–162)
        • Payroll and HR Preferences > W2 State Abbreviation
        • Field ID: custrecord_ns4g_payrollhrprefs_w2state
      • ZIP Code (RA 163–167)
        • Payroll and HR Preferences > W2 ZIP Code
        • Field ID: custrecord_ns4g_payrollhrprefs_w2zip
      • ZIP Code Extension (RA 168–171)
        • From same W2 ZIP Code; parse digits after “-” as extension
        • Field ID: custrecord_ns4g_payrollhrprefs_w2zip
      • Contact Name (RA 396–422)
        • Payroll and HR Preferences > Compliance > W2 Contact Name
        • Field ID: custrecord_ns4g_payrollhrprefs_w2contact
      • Contact Phone Number (RA 423–437)
        • Payroll and HR Preferences > Compliance > W2 Contact Phone Number
        • Field ID: custrecord_ns4g_payrollhrprefs_w2phone
      • Contact Email Address (RA 446–485)
        • Payroll and HR Preferences > Compliance > W2 Contact Email Address
        • Note: Original doc referenced phone; ensure this is the email field in your config
      • Preparer Code (RA 500)
        • Payroll and HR Preferences > Compliance > Preparer Code
        • Field ID: custrecord_ns4g_payrollhrprefs_w2prepare
        • Only allow letters: A, L, S, P, or O

      RE record field sources:

      • Terminating Business Indicator (RE 26)
        • Payroll and HR Preferences > Compliance > Terminating Business (Checkbox)
        • Field ID: custrecord_ns4g_payrollhrprefs_w2term
      • Employer Name (RE 40–96)
        • Payroll and HR Preferences > W2 Employer Name
        • Field ID: custrecord_ns4g_payrollhrprefs_w2legal
      • Location Address (RE 97–118)
        • Payroll and HR Preferences > W2 Location Address
        • Field ID: custrecord_ns4g_payrollhrprefs_w2loc
      • Delivery Address (RE 119–140)
        • Payroll and HR Preferences > W2 Delivery Address
        • Field ID: custrecord_ns4g_payrollhrprefs_w2city
      • City (RE 141–162)
        • Payroll and HR Preferences > W2 City
        • Field ID: custrecord_ns4g_payrollhrprefs_w2city
      • State Abbreviation (RE 163–164)
        • Payroll and HR Preferences > W2 State Abbreviation
        • Field ID: custrecord_ns4g_payrollhrprefs_w2state
      • ZIP Code (RE 165–169)
        • Payroll and HR Preferences > W2 ZIP Code
        • Field ID: custrecord_ns4g_payrollhrprefs_w2zip
      • ZIP Code Extension (RE 170–173)
        • From same W2 ZIP Code; parse digits after “-” as extension
        • Field ID: custrecord_ns4g_payrollhrprefs_w2zip
      • Kind of Employer (RE 174)
        • Payroll and HR Preferences > Compliance > Employer Type
        • Field ID: custrecord_ns4g_payrollhrprefs_w2emprtyp
        • Return one of:
          • F = Federal government
          • S = State/local non‑501(c)
          • T = 501(c) non‑government
          • Y = State/local 501(c)
          • N = None apply
        • Leave blank if Tax Jurisdiction Code at RE position 220 is P (Puerto Rico)
      • Positions 175–178
        • Blank (fill with spaces)
      • Employment Code (RE 219)
        • Payroll and HR Preferences > Compliance > Employment Code
        • Field ID: custrecord_ns4g_payrollhrprefs_w2emptcde
        • Return one of:
          • A = Agriculture (Form 943)
          • H = Household (Schedule H)
          • M = Military (Form 941)
          • Q = Medicare Qualified Government Employment (Form 941)
          • X = Railroad (CT‑1)
          • F = Regular (Form 944)
          • R = Regular

      Notes and tips:

      • Ensure the chosen entity’s Payroll and HR Preferences > Compliance tab is complete (contact name, phone, email, preparer code, etc.).
      • For ZIP+4, use the part after “-” as the extension.
      • Validation:
        • Preparer Code must be A, L, S, P, or O.
        • If Resubmission is true, include WFID.
      • Multi‑entity runs: RE records are created per entity on the Reporting Period. RA uses either Parent or selected entity per the checkbox behaviour above.
      References:
  • W-2 : Reporting Period – RA (Submitter) Selection and Multi Entity Support:
    • What’s changing:
      • Two fields will now help you select who submits your W‑2 file (the RA/Submitter).
      • W‑2 calculations and file output now cleanly support multiple entities.
    • When you’ll see this:
      • Only when Reporting Period Type = W2.
      • Hidden for ACA and State Retirement.
    • New fields:
      • Use Parent Entity Payroll and HR Preferences for the RA Submitter record
        • Type: Checkbox (default = checked).
        • What it does: If checked, we’ll use the Parent Entity’s Payroll and HR Preferences (Compliance tab) for the RA/Submitter.
        • Where it shows: Right after the Entity field.
      • Use following entity for the RA (Submitter)
        • Type: Single-select list of Entities (can be any entity).
        • What it does: If you don’t want to use the Parent Entity, pick the exact entity to act as the RA/Submitter. We’ll use that entity’s Payroll and HR Preferences (Compliance tab).
        • Where it shows: Right after the checkbox.
    • How RA is created:
      • If checkbox = True: RA uses the Parent Entity’s Payroll and HR Preferences > Compliance tab.
      • If checkbox = False: RA uses the selected entity’s Payroll and HR Preferences > Compliance tab.

  • W‑2: Multi‑entity W‑2 logic:

    • During calculation: The system will only include employees whose Payroll Totals entity matches an entity selected on the Reporting Period. If multiple entities are selected, employees from any of those entities are included.
    • During file creation the system will:
      • Create one RE record per selected entity.
      • Group RW (employee) and RT (totals) records by entity (based on the entity on the payroll totals, or the employee’s entity when applicable).

      Quick steps for users:

      1. Set Reporting Period = W2.
      2. Decide how to pick the RA/Submitter:
        • Keep the checkbox checked to use the Parent Entity’s preferences (simplest).
        • Or uncheck it and pick a specific RA entity in the next field.
      3. If using multiple entities, just select them on the Reporting Period. The system will:
        • Include only employees from those entities.
        • Create one RE per entity and group RW/RT by entity.
      4. Save and run your normal W‑2 process.

      Tips and validations:

      • If you uncheck the checkbox, you must choose an RA entity before saving.
      • If you recheck the checkbox, any chosen RA entity will be cleared and disabled.
      • Make sure the chosen entity (Parent or selected RA) has complete details on Payroll and HR Preferences > Compliance tab to avoid errors.
      What stays the same:
      • ACA and State Retirement reporting periods are unchanged and won’t show these fields.
  • Iowa State Taxes:
    • Previously, the "Spouse has earned income" checkbox was only visible in edit mode and did not appear when viewing a record. For the state of Iowa: The "Spouse has earned income" checkbox now always appears in view mode as well as edit mode.

      This change ensures that when Iowa is selected as the state, you can see whether the "Spouse has earned income" option was selected, even when simply viewing the record. No changes were made to how the checkbox behaves in edit mode.

  • Balancing Segments and Payroll Security:
    • The NS4G - Payroll Administrator role has been granted access to the custom segment "Fund". This permission allows users to print payroll checks correctly when balancing segment functionality is enabled.

      If you are using a custom role, make sure to assign the necessary access as follows:
      1. Navigate to Custom Segments >Fund (cseg_ns4g_fund).
      2. Under the Permissions subtab:
      3. Set your custom role to Edit for Value Management Access Level.
      4. Set it to View for Record Access Level.
      5. Set it to View for Search/Reporting Access Level.

      This will ensure your custom roles have the appropriate access for payroll processing, printing checks, and reporting involving the Fund segment.

      Repeat these steps for additional Custom Segments.
  • Handling State Tax Exempt Employees:
    • Handling State Tax Exempt Employees in Payroll Calculations

      Background: Some employees are classified as exempt from state taxes and should not have any state taxable wages accrued or reported. Previously, if the State field was left blank in the state tax section for these employees, you would encounter processing errors during payroll calculations, and their state taxable wages could be incorrectly reported.

      What’s Improved: If an employee is marked as Exempt from State Taxes, the system will now automatically exclude state taxable wages from both payroll calculations and payroll history calculations. Both the general State Taxable Wage bucket and any specific state wage buckets (such as “Iowa State Taxable Wages”) will be excluded from payline calculations and audit maps for these employees. When an employee has the Exempt from State Taxes flag set, you can safely leave the State field blank, this will no longer trigger a processing error.

      How This Affects You: For employees with the Exempt from State Taxes flag enabled, no state taxable wages will be calculated or reported. The State field in the employee’s tax section can be left empty without causing errors in payroll processing or during historical total recalculations. Regular payroll and historical payroll totals calculations will accurately reflect the exempt status and not include any state wage amounts for these individuals.

      This enhancement ensures proper handling and reporting of state tax exemptions in your payroll processes.
  • Florida Retirement System:
    • When calculating Reporting Periods, if the value in the Year-to-Date 415 Eligible Compensation field (custrecord_ns4g_empsrr_415elig) exceeds the current year’s limit, the amount will be capped automatically at the applicable limit.
      • The compensation limit may change from year to year. A date parameter is used to determine the reporting year and apply the correct limit.
      • For reporting years up to and including 2025, the limit is $70,000.00.
      • For reporting years from 2026 through 2099, the limit remains $70,000.00.
      • The limit for 2026 has not yet been formally announced. The configuration should be able to handle the calculation in 2026 even if the new limit is released partway through the year. The logic will be updated to reflect any new limit once it is published.
  • Employee Race Enhancement for EEO4 Reporting:
    • Specific race categories are mandated for EEO reporting and must be hard coded to ensure accurate reporting on the EEO4 report. Please note, users may currently be using the Ethnicity field, which is a customer-defined list that may not align with the required categories.
    • Field Enablement and Disablement Logic:
      • When the Race field is selected: The "Hispanic or Latino" checkbox will be disabled.
      • When the Race field is cleared or not selected: The "Hispanic or Latino" checkbox will be enabled.
      • When the "Hispanic or Latino" checkbox is checked (set to true): The Race field will be disabled.
      • When the "Hispanic or Latino" checkbox is unchecked (set to false): The Race field will be enabled.
      • On New Record Creation: Both the Race field and the "Hispanic or Latino" checkbox will be enabled by default.

Various Fixes and Performance Improvements

  • Resolved an issue where annual leave hours in the FRS file did not display correctly when decimal values were missing from the Employee Retirement record. The FRS file now ensures that, upon commit, annual leave hour values are consistently padded to display two decimal places (e.g., 20.00 instead of 20), regardless of input format.
  • The W2 Electronic File generation process has been updated to utilize a constant file defined in the code, instead of the Reporting File Template, for generating the W2 electronic file. This ensures accuracy and consistency in reporting.