Release Notes 26.5.1

NetSuite for Government 26.5.1 Release Notes

Revision Date: May 06, 2026

Important:

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

The 26.5.1 enhancements and changes listed in this document are not available to customers until they are upgraded to NetSuite for Government 26.5.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.5.1 – Release Date May 06, 2026

Finance:

GL Inquiry Screen:
- The General Ledger Summary report now supports Transaction Date as an additional date range option. Previously, users could run the report based on Posting Period only. With this enhancement, users can now choose between Posting Period and Transaction Date when defining the report date range. This provides greater flexibility and more detailed reporting by allowing users to analyze general ledger activity based on the actual transaction date, rather than only the accounting period in which the transaction was posted.
- Key Benefit:
  - Users can generate more precise General Ledger Summary results by filtering transactions according to the date the activity occurred.
- The GL Summary Report now includes additional account type filtering options using the GASB Category field on the account record. These filters make it easier for users to narrow report results to the specific account categories they need, reducing manual review and improving report accuracy. By using the standard GASB Category field, reporting behavior is more consistent across accounts and less dependent on custom configuration. Customers who previously used a custom field for this filtering should update their account setup to use the standard GASB Category field.
GL Summary Screens:
- The Revenue & Expenses account drop-down has been updated to show only accounts that are applicable to revenue and expense reporting. The drop-down now includes only the following account types:
  - Revenue, Other Income, Expense, Other Expense, and COGS.
  - Previously, retained earnings accounts could also appear in this list. Those accounts are no longer shown, helping users select the correct accounts more easily and reducing the risk of reporting setup errors.
Balancing Segments:
- Balancing segments for bank deposits created from Cash Sales and Refund Cash Sales using the Specify method now use the configured Balancing Cash Account and Due To/From Account, rather than the mainline Cash and Undeposited Funds accounts. For previously posted deposits, edit and save the Deposit record to apply the updated balancing segment values where needed.
- Balancing Segments for bank deposits created from Customer Payments now use the latest payment amount when the payment amount is changed after the initial save. For previously posted deposits, edit and save the Deposit record to apply the updated balancing segment amounts where needed.
- Fund balancing for Sales Tax is now supported in NetSuite for Government Balancing Segments for certain transaction types. This enhancement primarily applies to Accounts Receivable transactions, where sales tax is collected from the customer and posted to a separate liability account. This differs from Accounts Payable transactions, where sales tax is typically included in the vendor payment and AP liability account. The sales tax balancing is related to the "Post to Item Cost" checkbox on the tax code, which directs the system whether to include sales tax in the existing mainline account or utilize a separate account.
- Sales tax fund balancing support has been added for the following Accounts Receivable transactions:
  - AR Invoice
  - Cash Sale
  - Refund Cash Sale
- Support for the following transactions will be available in the next release:
  - Customer Payment
  - Refund Customer Payment
  - Deposits
- For transactions that required sales tax balancing before this enhancement, users may use the edit and save procedure to update fund balancing. Once support is released for Customer Payment, Refund Customer Payment, and Deposits, those transactions may also be updated using the edit and save procedure. Please contact Support with any questions or for guidance on using sales tax balancing for Accounts Receivable with NetSuite for Government Balancing Segments.

Item Code Account Override:
- Item Account Override Clearing Account Validation:
  - Item Codes used as clearing accounts for Item Account Override can no longer have their expense or income accounts changed when open transactions exist. This validation helps preserve general ledger accuracy and prevents out-of-balance posting scenarios.
  - Previously, if the expense or income account was changed while related transactions were still pending approval, clearing transactions could reference both the previous and updated account values, resulting in a mismatch.
- Action Needed:
  - To prevent this item account mismatch issue, select the Item Clearing Account checkbox on any Item Codes used as override clearing accounts. This ensures the accounts are properly protected from changes while open transactions exist.
Purchasing Change Order:
- Change Order encumbrances now use a snapshot of the remaining purchase order line balance at the time the Change Order is created when generating the disencumbrance entry. Previously, the remaining balance could change between Change Order creation and approval if vendor bills or bill credits were processed during that period. Using the creation-time balance snapshot ensures the disencumbrance entry reflects the intended balance and helps maintain accurate encumbrance accounting.
- Purchase Change Order numbering now automatically resets to the configured Initial Number value whenever the Prefix is updated on the System Setup screen.
Department Restrictions for Quick Codes:
- Department Restrictions Now Available for Quick Codes:
  - Department-based restrictions are now supported for Quick Codes, giving organizations greater control over which Quick Codes users can access during transaction entry.
  - When this feature is enabled, the system defaults the user’s department into the transaction line Department field and filters the available Quick Code list based on that department. The Quick Code list continues to honor existing Show In filters, with department restrictions applied in addition to those existing criteria.
  - To enable this feature, update the applicable custom role in Manage Roles. On the Restrictions tab, set:
    - Segment: Department
    - Restriction: Own
  - After this setup is complete, users assigned to the updated role will only see Quick Codes available for their own department, helping ensure accurate coding and reducing the risk of selecting Quick Codes outside their departmental scope.

Various Fixes and Performance Improvements

Users can now run the GL Summary Report using Transaction Date as the reporting basis. This gives finance teams more flexibility when reviewing general ledger activity and helps them analyze balances based on when transactions actually occurred, rather than relying only on posting period ranges. This is especially useful for period review, reconciliation, audit support, and reporting scenarios where transaction timing is important.
Improved performance when opening and working with supported transactions by optimizing how sublist fields are disabled. Previously, fields were disabled one at a time, which required additional processing for each sublist line. Now, multiple fields are disabled during each line pass, reducing the number of sublist iterations and helping transaction pages load and respond more efficiently. This performance improvement applies to all supported transaction types for item, expense, and line sublists.
Corrected an encumbrance issue for purchase order lines with negative amounts. Previously, when a negative PO line was closed or updated to a $0 amount, the related encumbrance line incorrectly showed $0. The encumbrance line now correctly reflects the reversal debit, ensuring the encumbrance amount is accurate when closing or updating negative purchase order lines.
The Change Order transformation process now captures error messages for display on the process page in addition to the email notification sent to users.
Corrected an error for the Parent Level Budgeting feature when copying a Purchase Order. Error stated "Cannot read property 'account' of undefined".
Quick Code warning messages are now displayed in a banner instead of a pop-up when a transaction contains more than 40 lines. This change supports server-side processing improvements that help enhance transaction performance while still keeping Quick Code warning information visible to users.
The PayPal integration dependency has been removed from NetSuite for Government releases. Customers can now configure PayPal integration as needed without impacting release deployment. To enable or disable PayPal integration, go to Setup > Company > Enable Features > Transactions tab > Payment Processing and toggle the PayPal integration setting on or off.

Human Resources and Payroll:

Overtime Cycle:
OT: FLSA Regular Rate Multiplier — Self-Inclusive

Rule Name OT: FLSA Regular Rate Multiplier — Self-Inclusive

Type Hour Code

Payroll ID ns4g_hc_otflsamultp_si

Alternative to ns4g_hc_otflsamultp
- When to use it?
  - Apply this rule to any overtime hour code that should pay at the FLSA Regular Rate of Pay using the multiplier entered in the Default Amount field. It extends the existing FLSA Regular Rate Multiplier rule and is designed for situations where the OT code's own wages and hours need to be automatically folded into the regular rate calculation — rather than relying on those hours and wages having already been posted to the Overtime Cycle Primary Pay Bucket through prior processing.
- How the calculation works?
  - Before the regular rate is calculated, the system builds a temporary wage amount for the current hour code using the employee's base hourly rate. Rates are sourced line-by-line from the Position and Pay Record that was active on each timecard entry's date, so mid-cycle rate changes are handled correctly — pre-change hours use the old rate and post-change hours use the new rate. The temporary wages and hours are added to the Overtime Cycle Primary Pay Bucket and Primary Hours Bucket totals for this calculation only; no new bucket entries are written and the hour code's Pay/Hour Bucket + and − configuration is not modified.
  - The system then computes: Regular Rate = (Base Wages + Add Pay Cycle Amount) ÷ OT Cycle Hours, OT Rate = Regular Rate × Default Multiplier, and OT Amount = OT Rate × OT Hours Worked. Using the requirements example — 40 regular + 17 OT hours at $39.03/hr base plus $28.11 differential and $20.00 OIT — Regular Rate = $2,272.82 ÷ 57 = $39.87, OT Rate = $59.81, and OT Amount = $1,016.77.
- Configuration notes and edge cases
  - On the hour code, set Calculation Rule to this rule and enter the overtime multiplier (typically 1.5) in Default Amount. If the current hour code is not assigned to the OT Cycle Primary Pay Bucket, the self-inclusion step is skipped and the rule behaves identically to the standard FLSA multiplier rule. Processing errors are raised if the employee's hourly rate is null or zero, if any applicable add pay amount is configured as a percentage, or if total OT Cycle Hours are zero after the self-inclusion step. The system also guards against double-counting when the current code's wages were already posted to the bucket earlier in the cycle.
California-Government Compensation in California:
- Enhancement: Position Record – Elected Official Field
- Overview:
  - A new field, Elected Official, has been added to the Position record to support reporting requirements, including California-specific compliance.
- Details:
  - Field Name: Elected Official
  - Field Type: Checkbox
  - Field ID: custrecord_ns4g_position_elected
  - Required: No
- Behavior:
  - The field can be displayed on the Position record and across all forms.
  - It is optional and may be used by all customers for reporting purposes.
- Placement:
  - The field is located immediately after the Position Type field.
- Usage:
  - Indicates whether a position is an elected office.
  - For California agencies, this field maps to the “Elected Position” column in the Government Compensation in California (GCC) report.
  - The field is used for reporting purposes only and does not impact system processing.
Utah Retirement System (URS) - Benefit Program and 457b and R457b updates:
This section covers URS-specific State Compliance Setup updates, the new 457b DC Loan reporting record, and handling for employees whose URS Tier is set to Ineligible.
- Background:
  - The URS integration is case-sensitive on several compliance values, so the stored values in NS4G were tightened to match URS's expected casing. This release also introduces a distinct 457b Benefit Program entry so Utah can default the non-Roth 457(b) plan separately from the existing R457b (Roth) entry, which is being repurposed for upcoming URS R457b work.
- Renamed values:
  - The following State Compliance Setup values have been renamed for URS case-sensitivity (payroll IDs are unchanged):
    - Benefit Program R401K → R401k (ns4g_benefitprogram_r401k)
    - Benefit Program 401K → 401k (ns4g_benefitprogram_401ksavings)
    - Transaction Type C Loan → DC Loan, updated in both Name and Description (ns4g_transactiontype_dcln)
- New 457b program and R457b remap:
  - A new Benefit Program value has been added — Code 457b, Description "457b – 457(b)", Savings Plan Payroll ID ns4g_benefitprogram_457b. It ships inactive and is activated when Utah state preferences are assigned. The Tier default logic from SLERP-14084 has been remapped to default this new 457b value in the Tier instead of the prior default (R457b | 457b – 457(b) Savings Plan | ns4g_benefitprogram_r457b). Separately, the existing R457b description has been updated to "R457b – Roth 457(b) Savings Plan" (ns4g_benefitprogram_r457b) for use by the future URS R457b work.
  - Action required:
    - No manual updates are required in most environments — the renames, new value, and remap are applied via the release. After upgrade, confirm Utah-assigned employees on 457(b) plans are defaulting to the new 457b Tier entry rather than R457b, and review any saved searches, reports, or integrations that previously referenced the old uppercase values (R401K, 401K, C Loan) so they pick up the new casing.
Utah Retirement System (URS) 457b DC Loan:
- 457b — DC Loan Employee Retirement Reporting Record:
  - When is the record created?
    - During the URS Calculate step, the system evaluates the URS 457b Installment Loan Employee Post-Tax pay bucket (ns4g_urs457bloaneeposttax_pay) for each otherwise-eligible employee. If the bucket total is not equal to zero for the reporting period and the employee meets the existing criteria for URS inclusion, a new Employee Retirement Reporting record is created specifically for the 457b loan activity. This record may be generated in addition to any existing 457b contribution record and Defined Benefit record for the same employee. Internally it is referred to as the 457b Loan record, but there is no explicit "loan" indicator on the employee record — the primary identifier is that the Benefit Program on the record is set to 457b.
  - Field defaults on the new record:
    When the 457b Loan record is calculated, the system populates it as follows:
    - Benefit Program → 457b (custrecord_ns4g_empsrr_benefit)
    - Tier → null (DC Benefit Programs have no Tier; custrecord_ns4g_empsrr_tier)
    - Sub Tier → null (DC Benefit Programs have no Sub Tier)
    - Transaction Type → DC Loan (code DCLN); sourced from State Compliance Setup record Name "DC Loan", Code "DCLN"; stored in custrecord_ns4g_empsrr_transtype
    - Employee Pre-Tax Contributions → null (not applicable; custrecord_ns4g_empsrr_eepretaxcont)
    - Employee Post-Tax Contributions → sum of the URS 457b Installment Loan Employee Post-Tax pay bucket across payroll totals whose payment date falls on or within the Reporting Period Begin and End dates (custrecord_ns4g_empsrr_eeposttaxcont)
    - Employer Pre-Tax, Additional, and Pickup Contributions → all null (not applicable)
  - Header grouping:
    - After all Employee Retirement Reporting records are generated for the reporting period, the system evaluates every record and creates a header for each unique combination of Benefit Program, Tier, and Sub Tier; detail records are grouped beneath the matching header. Because 457b Loan records carry Benefit Program = 457b with null Tier and null Sub Tier, they roll up under a single 457b header — separate from tiered Defined Benefit headers such as PE Tier1, PS Tier1, or PE INEL.
Utah Retirement System (URS) Ineligible employees:
- URS — Ineligible Tier: Clear Retirement Salary
  - When it applies?
    - An employee's URS Tier may be set to Ineligible — either temporarily or permanently — due to a change in employment status, while the employee is still required to be reported to URS for that reporting period. This update handles the Ineligible case on the reporting record without requiring changes to pay bucket configuration on the payroll side.
  - What changed?
    - When an employee's Tier on the Employee Retirement Reporting record is set to Ineligible (Name: Ineligible, Code: INEL, payroll ID ns4g_tier_inel), the Retirement Salary field on the record is cleared and set to zero during Calculate. All other fields on the record continue to follow the standard URS calculation logic — the Ineligible handling is scoped specifically to the Retirement Salary field.
  - Why not change the pay bucket?
    - Rather than reconfiguring pay bucket mappings in payroll when an employee becomes Ineligible, the system zeroes the Retirement Salary value directly on the reporting record. This keeps payroll processing unchanged for Ineligible employees and confines the Ineligible handling to the URS reporting layer, where it can be reversed simply by changing the employee's Tier back to an eligible value.
2026 New Mexico State Tax Calculation:
- New Mexico Tax Updates – 2026:
  - Overview:
    - This release introduces updated New Mexico state tax tables for 2026, including revised deduction rate tables for:This release introduces updated New Mexico state tax tables for 2026, including revised deduction rate tables for:
      - Single
      - Married
      - Head of Household filing statuses
  - Enhancements:
    - New Mexico Deduction Rate Tables – 2026:
      - Updated annual tax tables have been implemented to ensure accurate withholding calculations based on employee filing status.
        
        Single Filing Status
        Income Range Base Tax Rate Over Amount
        
        0 – 8,050 0 0% 0
        8,050 – 13,550 0 1.5% 8,050
        13,550 – 20,550 82.50 3.2% 13,550
        
        20,550 – 24,550 306.50 3.2% 20,550
        
        24,550 – 33,550 434.50 4.3% 24,550
        
        33,550 – 41,550 821.50 4.3% 33,550
        
        41,550 – 58,550 1,165.50 4.7% 41,550
        
        58,550 – 74,550 1,964.50 4.7% 58,550
        
        74,550 – 218,050 2,716.50 4.9% 74,550
        
        218,050+ 9,748.00 5.9% 218,050
        
        Married Filing Status
        Income Range Base Tax Rate Over Amount
        
        0 – 16,100 0 0% 0
        
        16,100 – 24,100 0 1.5% 16,100
        
        24,100 – 32,100 120.00 3.2% 24,100
        
        32,100 – 41,100 376.00 3.2% 32,100
        
        41,100 – 57,100 664.00 4.3% 41,100
        
        57,100 – 66,100 1,352.00 4.3% 57,100
        
        66,100 – 102,100 1,739.00 4.7% 66,100
        
        102,100 – 116,100 3,431.00 4.7% 102,100
        
        116,100 – 331,100 4,089.00 4.9% 116,100
        
        331,100+ 14,624.00 5.9% 331,100
        
        Head of Household Filing Status
        Income Range Base Tax Rate Over Amount
        
        0 – 12,075 0 0% 0
        
        12,075 – 20,075 0 1.5% 12,075
        
        20,075 – 28,075 120.00 3.2% 20,075
        
        28,075 – 37,075 376.00 3.2% 28,075
        
        37,075 – 53,075 664.00 4.3% 37,075
        
        53,075 – 62,075 1,352.00 4.3% 53,075
        
        62,075 – 98,075 1,739.00 4.7% 62,075
        
        98,075 – 112,075 3,431.00 4.7% 98,075
        
        112,075 – 327,075 4,089.00 4.9% 112,075
        
        327,075+ 14,624.00 5.9% 327,075
2026 Vermont State Employee Tax Calculation:
- Vermont Tax Updates – 2026:
  - Overview:
    - This release introduces updates to Vermont state tax handling for 2026, including:
      - Support for Head of Household (HoH) filing status.
      - Updated Vermont Deduction Rate Tables.
      - Updated Withholding Allowance Table.
  - Enhancements:
    - Head of Household Filing Status Support
      - Employees with Vermont state tax setup can now select Head of Household.
      - Vermont continues to allow the use of the federal W-4 in place of a state W-4.
  - Calculation Behavior:
    - When Head of Household is selected, tax calculations will use the Single filing status deduction rate table.
    - Vermont Deduction Rate Tables – 2026
      - Updated annual deduction rate tables have been added.
      - Single Filing Status (also used for Head of Household):
        Income Range Base Tax Rate Over Amount
        
        0 – 3,925 0 0% 0
        
        3,925 – 54,675 0 3.35% 3,925
        
        54,675 – 126,775 1,700.13 6.60% 54,675
        
        126,775 – 260,225 6,458.73 7.60% 126,775
        
        260,225+ 16,600.93 8.75% 260,225
      - Married Filing Status:
        Income Range Base Tax Rate Over Amount
        
        0 – 11,775 0 0% 0
        
        11,775 – 96,475 0 3.35% 11,775
        
        96,475 – 216,525 2,837.45 6.60% 96,475
        
        216,525 – 323,825 10,760.75 7.60% 216,525
        
        323,825+ 18,915.55 8.75% 323,825
  - Vermont Withholding Allowance – 2026
    - Annual Allowance Amount: $5,400
Payroll Postings Fund Validation – Mandatory and Block Logic:
Fund Validation on Employee Posting Detail records is controlled by "Use Fund Validation in Employee Postings" under Payroll and HR Preferences > Fund Allocation. The setting supports three configuration paths — off, match-only, and mandatory-and-block — each of which changes how fund validation quick codes are assigned to posting lines. Pick the configuration that matches how strictly your organization enforces fund validation.
- Fund Validation: None/Do not assign
  - When to use it?
    - Select this configuration when your organization does not want fund validation applied to Employee Posting Detail records. Clients who do not use the Mandatory and Block feature or the quick code assignment can opt out entirely to avoid any performance overhead the matching logic would otherwise add to payroll posting generation.
  - How it works and configuration?
    - In Payroll and HR Preferences > Fund Allocation > Use Fund Validation in Employee Postings, select None / Do not assign. If all three radio buttons in the setting are null (no option selected), the system treats the configuration the same as None. In either case, the fund validation matching logic is skipped and Employee Posting Detail records are created using the current-state logic only — no Fund Validation value is written and no fund validation records are searched.
  - Switching modes later:
    - Enabling one of the other modes (Assign on Match, or Mandatory and Block) later does not require restructuring existing posting data. New payroll runs after the change will apply the selected logic to newly generated Employee Posting Detail records.
- Fund Validation: Assign Fund Validation Values on Exact Match
  - When to use it?
    - Use this mode when you want the system to automatically stamp the Fund Validation field on Employee Posting Detail lines whenever a matching fund validation record exists, but you do not want posting generation to warn or block when a line has no match. It is the standard "match-when-possible" configuration.
  - How the logic works?
    - With Assign Fund Validation on Match selected, posting generation searches all fund validation records for an exact match on the main segments of each posting line's GL string — fund, department, and account. If a match is found, the corresponding quick code is assigned to the Fund Validation column on the Employee Posting Detail line. If no match is found, the Fund Validation field remains null/blank on that line; no error or warning is raised, and the posting generates successfully.
  - Relationship to Mandatory and Block?
    - Assign on Match is the matching engine that feeds the Mandatory and Block behavior described in the next section. Enabling Assign on Match by itself populates fund validation on matching lines and silently leaves non-matching lines empty — useful when fund validation is available for reporting but not enforced.
- Fund Validation: Mandatory and Block
  - When to use it?
    - Enable Mandatory and Block when your organization requires fund validation on all Employee Posting Detail lines and wants the system to surface an explicit error on any line where a fund validation record cannot be matched. This mode pairs with Assign on Match and flags unmatched lines for review without stopping record creation.
  - How it works?
    - When the Fund Validation Mandatory and Block setting is enabled for the corresponding Payroll Batch Entity: during posting generation, if a GL string has no associated fund validation record, the Employee Posting Detail record is still created and the Fund Validation field is left null on the unmatched line. When one or more lines on a Payroll Item have an empty Fund Validation field, the system writes "Unmatched Fund Validation" to the Processing Error Message field on the related Payroll Item, surfacing the unmatched lines for follow-up.
  - Performance considerations:
    - Fund validation matching adds overhead to posting generation. The feature was performance-tested at 2,000 employees with 4–5 concurrency; during upgrade or initial rollout, compare measured posting runtime with the feature enabled against a baseline run with fund validation off so you can size the expected impact for your own batch volumes.
Hour Code: Regular Rate and Enhancements:
- $/hr Employee's Hourly Rate x Multiplier:
  - When to use it?
    - Use this rule when you need to pay a shift or assignment at a multiple of the employee's base hourly rate without triggering overtime or blended-rate logic. This is a rate-only adjustment — the hours logged on the timecard are not changed. Unlike the existing Differential and Hour Code Multiplier rules, which adjust the number of hours, this rule adjusts only the pay rate, making it suitable for things like double-time holiday pay, hazard-pay premiums, or any flat rate-based uplift handled through a single hour code.
  - How the calculation works?
    - For each timecard line using the hour code, the system retrieves the employee's hourly rate from the Position and Pay Record tied to that specific line and multiplies it by the value in the Amount or Multiplier field. Example: an employee with a base rate of $20.00/hr on a code configured with a multiplier of 1.5 is paid $30.00/hr for the hours on that line. If the employee has multiple position/pay records, the system uses the one assigned to the specific timecard entry, so the correct rate is always applied.
  - Configuration:
    - On the hour code, set Calculation Rule to "$/hr Employee's Hourly Rate x Multiplier" and enter the multiplier (e.g., 2 for double time, 1.5 for time-and-a-half style premium) in Amount or Multiplier. The derived rate flows through to the paystub and payroll item so employees can see the uplifted rate clearly. No secondary hour code line is required and no overtime or blended-rate logic is triggered by this rule.
- $/hr Employee's Hourly Rate + Flat Amount $/hr:
  - When to use it?
    - Use this rule when a shift differential should add a flat dollar amount to the employee's base hourly rate — for example, a $2.00/hr night-shift premium or a $1.50/hr bilingual premium. Like the multiplier version, it adjusts only the rate and not the hours, and it keeps the differential inside a single hour code so timekeepers do not need to enter a second line to capture the premium.
  - How the calculation works?
    - For each timecard line using the hour code, the system pulls the employee's hourly rate from the Position and Pay Record tied to that line and adds the flat amount in the Amount or Multiplier field. Example: a base rate of $20.00/hr on a code configured with Amount = $2.00 pays $22.00/hr for all hours on that line. Hours are not recalculated, and the derived rate displays on both the paystub and the payroll item.
  - Configuration:
    - On the hour code, set Calculation Rule to "$/hr Employee's Hourly Rate + Flat Amount $/hr" and enter the flat premium in dollars per hour in Amount or Multiplier. Use this rule in place of the older two-line differential setup when you want a simpler single-entry experience on the timecard.
ACA Reporting:
- ACA SSN Retrieval — Performance Refactor:
  - Background:
    - ACA XML and file generation was taking approximately 2–4 hours to complete when the Commit step processed a population of roughly 4,000 records. Profiling traced the bottleneck to SSN retrieval: because SSNs are stored encrypted, pulling and decrypting them during XML assembly was the dominant cost and scaled poorly with record volume.
  - What changed?
    - This release applies Option 3 from the ACA XML Generation Optimization design plan to restructure how SSNs are retrieved during Commit. The behavior, schema, and output content of the generated ACA files are unchanged — the same records, fields, and values are produced for filing. Only the end-to-end processing time of the Commit step is affected.
  - Action required and validation:
    - No user configuration changes are needed to realize the improvement. During upgrade validation, run a representative ACA Commit at or near the ~4,000-record volume that previously hit the 2–4 hour range and compare end-to-end runtime against the prior release baseline. Capture timing on at least one production-scale client so performance gains can be confirmed before broad rollout.

Various Fixes and Performance Improvements

1 Release Notes 26.5.1