This maintenance release introduces a host of enhancements aimed at boosting accuracy and alignment across systems. As always, this release also includes various optimizations and minor bug fixes for integrations with Acumatica, CMiC, Sage 300, Sage 100, Spectrum, Vista, and Sage Intacct, ensuring a smoother experience for all users.
Enhancements
Integrations Module
- Introduced the ability for users to hide unused syncs by adding an “Only Enabled Syncs” filter and visual indicators for disabled syncs. Updated the Add/Edit, Sync List, Sync History, and Sync History Details pages to respect the new IsEnabled property, show a red “Disabled by Default” icon instead of run/delete actions for inactive syncs, and ensure the Sync Manager prevents execution of disabled syncs.
- Use Cases:
- Admins or integration managers can now temporarily disable syncs they no longer need without deleting them, helping maintain a cleaner and more manageable list.
- This allows teams to focus on active syncs, avoid accidental runs, and still retain configuration details for later reactivation.
- Impacted Users: Arcoro customers and application admins managing integrations who want more control over which syncs are active or visible in their environment.
- Use Cases:
- This release fixes an issue where Sync History did not display correctly for Company Administrators when a sync’s associated company was changed by an admin. The system now filters Sync History based on the execution CompanyId instead of the sync’s original CompanyId, ensuring accurate visibility of company specific syncs. Additionally, to improve traceability, if a mismatch between the execution CompanyId and the sync’s stored CompanyId is detected, the company name will display with the suffix “[Changed]”.
- Use Cases:
- When Company Administrators view Sync History in Integrations, they will now see only syncs relevant to their own company.
- Any syncs that have been reassigned or modified administratively will be clearly marked with “[Changed]” to indicate the company association was altered. Backend logic also now prevents changing a sync’s company assignment to maintain data integrity and prevent confusion in audit trails.
- Impacted Users: Company Administrators, implementation teams, and integration support staff managing syncs within the Integrations platform, ensuring accurate, company-specific sync visibility and consistent tracking across all environments.
- Use Cases:
Providers:
Acumatica:
- This update corrects how rehire data is synced from Core HR to Acumatica. When a previously terminated employee is rehired, the sync will now use the hire date (not the termination date) as the rehire start date, and it will correctly update the employee's status to active in Acumatica.
- Use Cases:
- An HR admin rehires a previously terminated employee in Core HR and expects the rehire date to reflect accurately in Acumatica, regardless of whether the termination date remains on the record.
- A payroll team relies on an employee’s active status in Acumatica for pay processing and needs the sync to update the employee’s status from inactive to active automatically.
- A customer with seasonal or recurring employees frequently rehires individuals and wants consistent, reliable reactivation and rehire behavior in the Acumatica integration.
- Impacted Users: Arcoro customers using the Core HR to Acumatica integration who manage employee rehires, particularly those with overlapping termination and rehire dates.
- Use Cases:
- Added validation to prevent use of the FEDWIRE payment method as a default payroll payment method in the connector, aligning with Acumatica’s deprecation of FEDWIRE. Users will now see the error message “The Default Payroll Payment Method must be Check, Cash, or ACH” when attempting to save invalid configurations.
- Use Cases:
- A payroll admin configuring an Acumatica connector selects FEDWIRE as the default payment method and is clearly alerted that only Check, Cash, or ACH are valid options, preventing sync errors and ensuring compliance with current Acumatica standards.
- Impacted Users: Arcoro customers using the Core HR to Acumatica integration, particularly payroll administrators managing default payroll payment method connector configuration settings.
- Use Cases:
- When running a Core HR to Acumatica sync, the system incorrectly triggers a Direct Deposit validation error for terminated employees. The Acumatica writer currently checks whether an employee has at least one active Direct Deposit marked as Gets Remainder, and raises an error if none exist. However, this validation is being applied even when the employee is terminated in Core HR. Terminated employees are not expected to have active DD accounts, and should never trigger this error. The validation should only run for active employees with active DD records.
- Use Cases:
- If an active employee is missing a Gets Remainder DD account, an error should appear as usual.
- If a terminated employee with only inactive DD accounts, the sync should not validate DD requirements and should not fail.
- Admins troubleshooting sync results should no longer see terminated employees incorrectly flagged with missing “Gets Remainder” errors.
- Impacted Users: Payroll and integration admins using the Core HR to Acumatica sync, support teams investigating failed Acumatica writes, and implementation teams validating DD setup during customer onboarding.
- Use Cases:
CMiC:
New functionality ensures the "TxpExcludeFlag" is set to "Y" when an employee is exempt from federal tax, aligning with CMiC requirements for accurate tax exemption processing.
- Use Cases:
- Ensuring accurate tax exemption data is critical for payroll compliance and avoiding manual corrections. By explicitly setting the "TxpExcludeFlag" to "Y", we align with CMiC’s data requirements and eliminate discrepancies that could cause errors in downstream payroll processing.
- This update reduces the risk of misclassified exemptions and minimizes the need for support intervention or manual data fixes.
- Impacted Users: CMiC integration users and application admins who are attempting to pass exempt federal tax records.
- Use Cases:
- A user-friendly warning message will now be logged when a termination date has changed in the source system (Core HR), but the employee is already marked as terminated in CMiC. This prevents confusion around sync behavior and avoids repeatedly sending unrecognized termination date changes.
- Use Cases:
- An admin updates an employee’s termination date in Core HR after they’ve already been terminated in CMiC and needs clarity on why the change isn’t syncing.
- A user can troubleshoot a failed or incomplete sync sees the warning and can confidently explain the behavior to the customer.
- Impacted Users: CMiC integration users and application admins running syncs that attempt to terminate a previously terminated employee.
- Use Cases:
- The CMiC writer now includes validation to exclude non-US addresses from sync payloads and introduces proper truncation for postal codes exceeding CMiC’s 13-character limit.
- Use Cases:
- A company attempting to operate internationally now has a properly formatted message generated notifying them that CMiC supports US payroll only.
- Implementers want to ensure that long zip codes do not block full employee syncs during rollout or data migrations.
- Impacted Users: This update impacts Arcoro customers using the Core HR to CMiC integration, specifically those syncing employees with international addresses or long postal codes. It primarily affects HR admins and support teams by preventing sync failures and improving visibility into address related issues.
- Use Cases:
This update corrects CMiC FLSA Type mapping by ensuring the value reflects the actual Overtime Exempt status from Core HR. Previously, all employees were incorrectly defaulted to Non-Exempt ("N"), regardless of their Core HR setting. With this change, IsOvertimeExempt = true will now use the EmpFlsaType field to map to "E" (Exempt) with false mapping to "N" (Non-Exempt), ensuring accurate payroll classification.
- Use Cases:
- An employee marked as overtime-exempt in Core HR must appear as Exempt in CMiC for proper labor costing, reporting, and compliance.
- Implementation and support teams reviewing mismatches between Core HR and CMiC FLSA types will now see consistent, correct values.
- Impacted Users: Payroll admins, implementation specialists, and support teams managing Core HR to CMiC integrations who rely on accurate exempt/non-exempt status for payroll processing, job costing, and compliance reporting.
- Use Cases:
- The integration currently passes Boolean.FalseString (“False”) as the fallback/error value when retrieving the Use Legacy Deduction/Benefit Endpoints config setting, which is misleading and not an appropriate error message. The writer now uses the correct missing-setting error string so that fallback behavior reflects actual configuration issues rather than defaulting to “False.”
- Use Cases:
- Admins diagnosing missing or misconfigured connector settings will see accurate error messaging instead of a silent Boolean fallback.
- Integrations relying on the legacy endpoints toggle will now behave predictably when the configuration is missing.
- Impacted Users: Integration admins, implementation teams, and support engineers responsible for managing connector configuration and troubleshooting Core HR to CMiC or related payroll/benefits sync behavior.
- Use Cases:
- This change fixes an issue where Occupation/Trade updates sent to CMiC used an incorrect effective date, often one day ahead, due to UTC-based timestamp handling. The integration now uses the appropriate local modified date when determining the effective date of demographic changes, ensuring updates reflect the actual day the change occurred in Core HR.
- Use Cases: An employee’s trade or occupation is updated in Core HR, and CMiC must also reflect the local date.
- Impacted Users: Core HR to CMiC users, payroll admins, and support teams troubleshooting demographic sync timing issues, especially when effective dating affects payroll, compliance, or costing.
- Core HR to CMiC syncs currently error when an employee’s hire/rehire date matches the compensation record’s effective start date. This logic was originally added because older CMiC versions didn’t expose compensation effective dates. Since CMiC Patch 21 introduced proper effective-date visibility, the error is now obsolete for Patch 21+ environments. Cloud customers should always assume Patch 21+, while Enterprise customers should only bypass the error when the “Is on patch 21” setting is enabled.
- Use Cases:
- Core HR to CMiC syncs should no longer falsely block compensation records for customers on Patch 21+.
- Ensures compensation effective dates are pulled correctly from Core HR instead of defaulting to hire/rehire dates.
- Prevents unnecessary support escalations caused by outdated validation logic in up-to-date CMiC environments.
- Impacted Users: CMiC Cloud customers (all default to Patch 21+), CMiC Enterprise customers with Patch 21 enabled, and implementation/support teams handling compensation syncs who require accurate effective-date handling without avoidable sync failures.
- Use Cases:
- When syncing state tax records from Core HR to CMiC, the integration currently allows records with effective dates that match an employee’s existing CMiC state tax override dates to pass through to CMiC. This leads to unhandled CMiC database errors, resulting in failed syncs and no clear feedback to the customer. Federal tax records already have proper duplicate-date validation, but state taxes do not. The fix introduces consistent pre-sync validation so that duplicate effective dates for state taxes are caught early and communicated clearly to users.
- Use Cases:
- Implementation or support teams reviewing failed syncs will now see a clear, user-friendly validation error instead of a cryptic CMiC exception.
- Impacted Users: Integration admins, implementation specialists, and support teams working with Core HR to CMiC tax syncs. This fix prevents dead-end CMiC DB errors, reduces troubleshooting time, and aligns state tax validation behavior with the existing federal tax logic.
- Use Cases:
Sage 300:
- Prevent sending expired state tax records from Core HR to Sage 300. The writer now filters out state tax entries whose end date is in the past, so only active/valid tax data is written.
- Use Cases:
- An HR/Payroll admin syncing to Sage 300 avoids pushing historical/expired state tax entries reducing rejections and cleanup.
- Implementers/support can troubleshoot faster since only active tax records appear in the destination.
- Impacted Users: Arcoro customers using the Sage 300 integration, particularly payroll admins and implementation/support teams managing employee tax setups.
- Use Cases:
- Resolved an issue where the Sage 300 integration occasionally made duplicate requests for the final page of data during large syncs. Paging logic now stops cleanly after retrieving the last page, eliminating unnecessary API calls and improving performance consistency.
- Use Cases:
- When syncing large Sage 300 datasets to Core HR or a file destination, the system now processes each page exactly once, ensuring faster, cleaner data transfers without duplication or redundant calls.
- Impacted Users: Arcoro customers using the Sage 300 integration, especially HR and payroll admins managing large data imports or exports who benefit from reduced runtime and greater sync reliability.
- Use Cases:
- Arizona State Tax records with a 2% rate are currently mapped to the wrong CMiC calculation code (ID 19 instead of ID 24), causing CMiC to reject the record with the error “TXP_ALT_CALC_CODE – Not Applicable for Taxid or Work Location.” This misalignment breaks Core HR to CMiC syncs whenever a 2% AZ rate is used.
- Use Cases:
- A payroll admin syncing employee state taxes for Arizona needs the 2% rate to correctly map to CMiC’s expected code (ID 24) so the record can be accepted without errors.
- Implementation or support teams validating AZ state taxes in QA or production can rely on consistent, accurate mapping that matches CMiC’s configuration.
- Impacted Users: Payroll admins, implementation teams, and support engineers working with Core HR to CMiC integrations who must sync Arizona state tax configurations without encountering mapping-related failures.
- Use Cases:
Sage 100:
- City field truncation is now applied based on the destination system’s requirements. Specifically, the Sage 100 writer will only truncate city values exceeding 50 characters, avoiding unnecessary truncation inherited from Sage 300 limits.
- Use Cases:
- A customer using Sage 100 enters a city name longer than 15 characters and expects the full value to be saved unless it exceeds Sage 100’s 50-character limit.
- Impacted Users: Sage 100 customers and application admins running syncs to update employee addresses.
- Use Cases:
- This update corrects an issue in the Sage 100 reader where the paging logic made redundant API requests for the final page of results during multi-page syncs. Previously, the system would fetch the last page multiple times, leading to unnecessary processing and potential inconsistencies in downstream data. The paging sequence now terminates cleanly after retrieving the last page exactly once.
- Use Cases:
- When running a Sage 100 to Core or File sync with large datasets (over 1000 records), the final page of API calls now executes only once, eliminating duplicate reads.
- Improves performance, reduces API load, and ensures data alignment between Sage 100 and Core HR.
- Impacted Users: Integration admins, implementation teams, and support staff managing large Sage 100 data syncs. This change increases efficiency, accuracy, and reliability of Sage 100 integrations by preventing duplicate API calls and unnecessary data processing.
- Use Cases:
Spectrum:
- Accurate filtering of employee records is essential to ensure only relevant data is processed during syncs. Filtering has been enhanced to improve data integrity and flexibility by allowing organizations to define filtering logic based on their preferred company code structure, reducing the risk of syncing incorrect or incomplete employee data.
- Use Cases:
- An organization with multiple company codes wants to ensure only employees from specific codes are included in syncs.
- A customer uses Facility 1 Code instead of UDFL1 to represent Company Codes and needs the system to respect that structure.
- Impacted Users: Spectrum customers and application admins updating connectors to filter certain facility/company codes.
- Use Cases:
- When syncing data to Spectrum, employees who have a union class (wage code) populated in UDFL14 but do not have a union assigned should trigger a warning. This helps identify incomplete or invalid union setup before it results in downstream issues. The warning should appear in the sync logs but must not block the record from syncing, since the employee may already have a valid union assignment in Spectrum.
- Use Cases:
- Surface bad or incomplete union configuration so admins can correct missing union assignments before they cause Spectrum errors.
- Allow syncs to continue without interruption even when a union class exists without a corresponding union.
- Impacted Users: Integration admins and support teams running Core HR to Spectrum syncs who need visibility into union data inconsistencies without blocking successful data transmission.
- Use Cases:
Vista:
- Ensure the Vista writer maps N (Not applicable) in Core HR to null in file output without noise: downgrade NotSupportedFilingStatusError to info and suppress warnings/errors when N or null is valid for the state; all other filing-status behaviors remain unchanged.
- Use Cases:
- Admins syncing to Vista for states where N is appropriate get clean runs without false-positive warnings.
- Users can focus on actionable issues, and maintain backward compatibility for other filing statuses while still seeing informational context in logs when needed.
- Impacted Users: Arcoro customers using the Core HR to Vista integration; especially payroll admins, implementers, and support teams managing state tax filing status mappings.
- Use Cases:
- Fix defaulting for override calculations: when a flat override amount is entered and no calculation type is chosen, automatically default the calculation type to “A” (amount). Any manual selection by the user will be honored, and the logic will continue defaulting to “R” (rate/percent) when the override is percentage-based per Trimble guidance.
- Use Cases:
- An admin enters a flat dollar override but forgets to pick a calculation type; the system now defaults to A to prevent miscalculation.
- When the admin explicitly chooses a type, that selection is respected.
- Percentage-based overrides still default to R to match expected payroll behavior.
- Impacted Users: Arcoro customers and application admins configuring payroll overrides in the connector, especially teams following Trimble-recommended settings.
- Use Cases:
- Now, only the active direct deposit method is written for each employee in the 2_DD_PREHArc2 export file, ensuring exactly one valid record per employee that represents the full-amount direct deposit.
- Use Cases:
- When multiple direct deposits exist for an employee in Core HR, the system now correctly writes just the currently active full-amount method to 2_DD_PREHArc2.
- Impacted Users: Arcoro customers using the Vista integration, especially payroll and HR administrators managing employees with multiple direct deposit configurations.
- Use Cases:
Payroll Module:
- This release delivers broad stability and functional improvements. Fixes include correcting invalid mappings (e.g., rate codes, tax codes, earning types), improving handling of inactive rate codes, tightening labor-classification/union logic, ensuring cost code + project validation for Intacct time syncs, fixing facility-code mismatches after Hub migrations, resolving supplemental tax-rate calculation issues, improving contractor field support, updating reader/writer scope enforcement, enhancing caching and metadata behavior, and preventing cross-company data exposure. Several UI/UX updates improve clarity, editing workflows, field availability, and logging across Payroll and Hub. Collectively, these changes prevent data loss, invalid writes, sync errors, or downstream failures while ensuring all products stay aligned with Hub and Intacct data contracts.
- Use Cases:
- Prevent incorrect tax, rate code, job, labor class, or cost code mappings during syncs.
- Block unintended writes (example: inactive rate codes).
- Ensure projects + cost codes are valid before Payroll to Intacct sync.
- Maintain consistency between Hub and Core HR after facility migrations.
- Fix supplemental tax and off-cycle earning calculations.
- Support correct labor classification + union assignments across systems.
- Improve ExakTime to Payroll rate code and earning-type validation.
- Enhance UI workflows for Payroll (GL Comp Share, dropdowns, edit modals, tooltips).
- Ensure contractors retain departments/locations during ET to Payroll to Hub flows.
- Strengthen provider scope enforcement and caching reliability.
- Impacted Users: Integration admins, payroll processors, implementation teams, and support engineers who rely on accurate cross-system data movement (Payroll, Hub, Core HR, Intacct, CMiC, ExakTime). These updates reduce sync failures, ensure correct payroll/tax behavior, prevent bad data from reaching downstream systems, improve auditability, and provide clearer, more actionable validation and logging.
- Use Cases:
- The “Payroll for Sage Intacct” product configuration is renamed to “Payroll for Sage Intacct Construction.” This naming update provide greater clarity and consistency across customer environments and documentation.
- This release includes a change to update the Employee reader to honor defined Employee Scopes, Employee Type, Location, and Pay Group, for preload filtering, impact validation rules, and execution of mapping expressions so only in-scope employees are processed (for ExakTime).
- Use Cases:
- Admins can selectively enable or disable Employee Type, Location, and Pay Group scopes to control which employees are preloaded and validated for the ExakTime sync.
- This will reduce noise, preventing out-of-scope updates, and ensuring mapping expressions only run for intended records.
- Impacted Users: Arcoro customers using the ExakTime/Payroll integration, especially implementation teams, application admins, and support staff who manage employee scope filters for targeted, predictable sync behavior.
- Use Cases:
- This release updates Payroll’s off-cycle check logic to ensure federal income tax is calculated at the supplemental rate when the “Tax all earnings as supplemental earnings” option is enabled. Previously, off-cycle earnings were incorrectly taxed using each employee’s individual withholding setup instead of the IRS-mandated 22% supplemental rate.
- Use Cases: When processing off-cycle payrolls (e.g., bonuses, adjustments, retro pay), enabling the supplemental earnings option will now correctly apply the 22% federal rate. This ensures tax accuracy and compliance with IRS supplemental wage regulations.
- Impacted Users: Payroll admins and accountants processing off-cycle checks where the supplemental tax option is enabled, as well as support and implementation teams validating federal tax calculations for off-cycle earnings.
- This release addresses an issue where a false SignalR notification (“Company was modified by External System”) appeared when attempting to sign Company documents (e.g., Alabama Form 2848A) in Payroll. The message displayed even when no external updates or CheckHQ API calls occurred.
- Use Cases: When users access and sign Company-level documents, the system will no longer trigger the misleading SignalR “external modification” message. Only genuine external updates will prompt a refresh notification.
- Impacted Users: Payroll admins, compliance teams, and implementation staff managing Company setup and required forms within the Payroll module.
- This release enhances the Payroll earnings interface by replacing the free-form Cost Center field with a Hub-bound searchable control (combo box or list, determined with Tom). The new control supports selecting valid cost codes retrieved from Hub, improving accuracy, consistency, and reporting alignment across Payroll and GL. Legacy data remains supported through backward compatibility with existing costCodeName metadata.
- Use Cases:
- Payroll admins can now search and select cost codes directly from Hub when editing earnings. Saved cost codes persist on reload, and non-required records can still be saved without a cost code.
- Related reports, General Ledger, Job Costing, and Certified Payroll, will correctly group and display results whether they reference legacy metadata or the new CostCodeID field.
- Impacted Users: Payroll admins, accountants, and reporting users who manage cost allocations and rely on Job Costing or GL reporting for Payroll data validation and reconciliation.
- Use Cases:
- This release enhances employee synchronization logic to ensure labor classification assignments are written and maintained consistently across systems. During sync, all labor classification assignments from the source are written, with the primary assignment correctly designated. Matching occurs by Hub ID first, then by name, with user-friendly logs detailing assignment changes. The sync does not remove assignments already in Hub to prevent unintended data loss when sources (like Intacct) support only a single assignment. When syncing to Payroll, the employee’s labor classification now reflects the source’s primary assignment, improving consistency between Hub, Payroll, and source systems.
- Use Cases:
- Admins running employee syncs between systems such as Intacct to Hub or Core/ET to Payroll will see accurate labor classification alignment.
- Changes or updates to primary classifications in the source system will now correctly propagate across integrations without overwriting existing Hub data. Logs will clearly display before-and-after assignment names to improve traceability and auditability.
- Impacted Users: Integration admins, implementation teams, and support staff managing employee data syncs involving labor classifications across Hub, Payroll, and connected HR systems.
- Use Cases:
- This release fixes a misleading error that appeared when deleting records such as Company Benefits or related entities. Previously, deleting a benefit (under Company Details to Benefits) triggered the message “Delete Failed: RestConnectorProvider Delete requires a return object or a data object,” even though the deletion completed successfully. This update ensures the system now reflects the correct result, showing a success confirmation or no message if the deletion is successful.
- Use Cases:
- Admins and support users can now confidently delete Company Benefits, Person Benefits, Deductions, Bank Accounts, and Payroll related line items without confusion.
- The system will correctly indicate the outcome, improving trust and usability during data cleanup or configuration updates.
- Impacted Users: Implementation and support teams managing company and employee setup data in Payroll and related modules, as well as admins performing maintenance in the Company Details to Benefits section.
- Use Cases:
- This release adds a cost code validation layer for time syncs from ExakTime (ET) to Payroll to prevent invalid data from reaching Intacct after payroll completion. When a company is flagged as a Sage Intacct customer via a new Company Setting, the Payroll Time Writer will now verify that each time record’s project has a valid cost code and that the project–cost code combination exists in Intacct. If a mismatch or missing cost code is detected, the sync will be blocked and a clear, descriptive error message will be returned. This ensures that completed payrolls do not contain invalid records that would later be rejected by Intacct.
- Use Cases:
- For Intacct customers syncing time from ET to Payroll, the system now enforces pre-validation before payroll completion.
- Time records associated with Intacct projects lacking cost codes will be prevented from syncing, with detailed errors identifying the record, project, and validation failure.
- Non-Intacct customers are unaffected; the validation only runs when the Sage Intacct Company Setting is enabled.
- Impacted Users: Implementation teams, support staff, and payroll admins managing ET/ Payroll/Intacct integrations. This change protects Intacct-connected customers from post-payroll sync failures and improves overall data integrity between Payroll, ET, and Intacct.
- Use Cases:
- This release updates Payroll’s reader and writer logic to support saving and resolving Hub IDs for cost codes, jobs, and labor classifications on time record metadata. The writer now attempts to match each time record’s cost code (by ID and name), labor class (by name), and job (by code) with corresponding Hub records. When a match is found, the Hub ID is stored and a custom context message is logged for user visibility. If no match is found, the sync will fail with a clear, descriptive error. The reader performs the reverse operation, matching Hub IDs back to their corresponding cost code, job, and labor class names when reading records into Payroll.
- Use Cases:
- When running time syncs between ET to Payroll or Payroll to Sage Intacct, cost codes, jobs, and labor classifications are now fully resolved against Hub IDs for reliable cross-system mapping.
- Users receive contextual log details confirming successful matches, while mismatches or missing references are flagged with actionable errors.
- Records without job, cost code, or labor class assignments will continue to sync successfully.
- Impacted Users: Integration admins, implementation specialists, and support teams managing ET/Payroll/Intacct syncs who rely on accurate Hub-based mapping for cost codes, jobs, and labor classifications to maintain end-to-end data integrity across connected systems.
- Use Cases:
- This release enhances Payroll handling for auto-generated salaried hourly earnings to support Intacct integrations. When a payroll is created, all salaried employees are automatically added with hourly earnings that initially have a blank Job and their primary Labor Class prefilled. Users can now edit both the Job and Labor Class fields on these earnings while the payroll is in Draft status. Payrolls cannot be moved to Review if any salaried hourly earnings are missing a Job, ensuring Intacct-required project data is always present before export. Non-Intacct companies retain existing behavior, where these fields remain non-editable.
- Use Cases:
- For Intacct customers, this update ensures that salaried hourly earnings include valid Job (Project) and Labor Class values prior to review and export.
- Users can save drafts even if Jobs are missing but cannot submit for approval until all Job fields are completed. Once approved, these values are exported to Intacct for accurate project and labor classification mapping.
- Impacted Users: Payroll admins, accountants, and integration teams managing Intacct-connected payrolls, ensuring salaried earnings comply with Intacct project requirements. Implementation and support staff will benefit from improved error clarity and prevention of failed Intacct exports due to missing Job assignments.
- Use Cases:
- This release improves error handling for contractor syncs into Payroll by replacing the generic “An error has occurred” message with specific validation error messages. When a validation failure occurs during contractor sync, the system will now surface clear, contextual details indicating the cause of the failure (missing required field, invalid data format) instead of a non-descriptive error.
- Use Cases: When syncing contractors from connected systems into Payroll, admins and support staff can now quickly identify and resolve validation issues without needing to review raw logs or escalate. This reduces troubleshooting time and improves visibility into data quality issues during integrations.
- Impacted Users: Implementation teams, support staff, and integration admins overseeing contractor imports and syncs to Payroll, particularly those managing external system integrations or handling contractor onboarding data validation.
- This release updates the Payroll line item model and data pipeline to include and persist Wage Determination specific fields, Job ID, Labor Classification Code, and Labor Classification Name, ensuring accurate data flow to the UI and reporting systems. These fields are now sourced and bound to Hub data: the Job ID comes from the associated time record (or Hub dropdown), while Labor Classification Code and Name are populated via Hub dropdown selections. This enhancement supports downstream compliance and prevailing wage reporting by correctly labeling wage overrides and cash fringe supplements.
- Use Cases:
- When processing payroll, if a time record matches a Wage Table entry, the resulting line item will automatically include Job ID, Labor Classification Code, and Labor Classification Name. If no match is found, only the Job ID is retained while Labor Class fields remain blank.
- When users manually add hourly earnings, these fields are now visible and editable with Hub-driven dropdowns for Job and Labor Class, filtering out inactive records while maintaining backward compatibility for existing items linked to deactivated entities.
- Impacted Users: Payroll admins, compliance officers, and reporting analysts who rely on Wage Determination data for certified payroll and compliance reporting. Implementation and integration teams also benefit from consistent field mapping across Payroll, Hub, and ExakTime for accurate job and labor classification tracking.
- Use Cases:
- This release adds a Type dropdown to the Non-Hourly Earnings entry screen, allowing users to select one of the ten supported Payroll Engine earning types. Each type maps directly to its corresponding backend value, ensuring the correct tax treatment for each earning. The selected type is stored and displayed consistently across the UI and API, resolving prior issues where the type value returned incorrectly in the GET request.
- Use Cases:
- When creating or editing Non-Hourly earnings (Bonus, Commission, Severance), users can now select the earning Type from a predefined dropdown list.
- The chosen type ensures accurate taxation logic during payroll processing and consistent data representation across Payroll and reporting APIs. Validation has been added to require a Type selection before saving.
- Impacted Users: Payroll admins and accountants entering or reviewing Non-Hourly earnings in Payroll. This update ensures all non-hourly earnings are categorized correctly for tax calculation, reporting, and integration with downstream payroll systems.
- Use Cases:
- This release enforces inactive Rate Code validation in the Compensation workflow to prevent assigning inactive codes to new employee earnings. Once a Rate Code is marked inactive, it can no longer be selected or assigned when creating new compensations. Existing compensations that reference inactive Rate Codes remain visible for historical and audit purposes but will now display a warning indicator. This ensures inactive Rate Codes cannot be used going forward while preserving past payroll and reporting integrity.
- Use Cases:
- When adding a new compensation to an employee profile, only active Rate Codes appear in the selection dropdown. If a Rate Code becomes inactive after being assigned, it remains visible but flagged with a warning.
- Attempts to assign or import an inactive Rate Code will trigger a validation error and block the action. When a Rate Code is reactivated, it becomes selectable again for new compensations and visible in dropdowns as expected
- Impacted Users: Payroll admins, HR specialists, and implementation teams managing employee compensations and earning rates within Payroll. This update ensures clean data entry, accurate Rate Code management, and compliance with payroll integrity requirements without disrupting historical visibility.
- Use Cases:
- This release adds Department, Location, and Labor Classification fields for Contractors in Payroll to ensure complete data consistency across ExakTime (ET), Hub, and Sage Intacct. Previously, these fields existed for employees but not contractors, causing data loss when syncing contractor records from ET to Payroll and from Payroll to Intacct. With this enhancement, contractors now maintain their associated Department, Location, and Labor Classification assignments end to end.
- Use Cases:
- When syncing a contractor from ET to Payroll, their Department, Location, and Labor Classification will now populate correctly in Payroll and display in the contractor’s profile. These fields are editable in the UI while the payroll is in draft, ensuring proper visibility and validation.
- During outbound syncs Payroll to Intacct, the same fields are now included in the data payload to preserve the contractor’s full assignment context across systems.
- Impacted Users: Implementation teams, integration admins, and payroll managers working with Sage Intacct and ExakTime contractor syncs. This update ensures that contractor profiles and payroll records remain fully aligned with employee data standards for Department, Location, and Labor Classification mappings.
- Use Cases:
- Update the Payroll post-deploy DB scripts to enable the new caching feature in production. The scripts should persist the required configuration for caching, initialize any needed metadata, and be idempotent so repeated runs are safe. This supports faster reads for common Payroll lookups used by our integrations and reduces external round-trips during sync and payroll processing.
- Use Cases:
- Improve performance and stability for Payroll UI and integration writers/readers by serving frequent lookups from cache.
- Reduce latency and load when running payroll syncs.
- Impacted Users: Payroll admins and implementation/support teams running ET/Core/Hub/Intacct syncs and payroll processing; end users benefit from quicker page loads and more reliable runs.
- Use Cases:
- This release updates the Employee Writer to fully respect Employee Scopes during preload, validation, and mapping execution. Previously, these scope settings did not affect the Employee Writer, resulting in unnecessary data inclusion regardless of selected configuration. The update ensures that when specific scopes, such as Demographics, Location, Pay Group, or Employee Type, are disabled, their corresponding data fields are excluded from outbound syncs, validation rules, and mapping expressions.
- Use Cases:
- When running Payroll syncs, admins can now fine-tune which employee data categories are included by enabling or disabling scopes in the sync setup. For example, disabling Demographics and Location ensures those fields are excluded from the outbound payload and logs, while enabling them restores full data flow. This provides greater control, allowing more efficient and secure syncs by limiting data movement to relevant employee dimensions.
- Impacted Users: Integration admins, implementation specialists, and support teams managing Payroll syncs who need granular control over employee data handling. This change ensures consistent scope-based filtering, aligns validation behavior across entities, and reduces unnecessary data transmission during employee syncs.
- Use Cases:
- This enhancement adds support for syncing an employee’s Union, Union Local, and Union Class assignments from Core HR to Payroll. These assignments are now stored in Check metadata using Hub IDs, allowing them to display correctly in the Payroll UI and sync seamlessly with downstream systems. The update ensures that adds, updates, and removals of union-related data in Core are fully reflected in Payroll, with clear before-and-after context logged for traceability.
- Use Cases:
- When an employee is assigned or updated with a union, union local, or union class in Core HR, the corresponding Hub IDs and names now sync automatically to Payroll.
- Admins can confirm changes directly in Payroll or review detailed logs showing previous and updated union assignments.
- When unions are removed in Core (set to “Not Assigned”), Payroll metadata is cleared and logs reflect the reset accurately.
- Impacted Users: Implementation teams, integration admins, and payroll managers who manage unionized workforces. This ensures Payroll reflects the most current union data from Core HR, improving compliance, reporting, and multi-system consistency across the Arcoro ecosystem.
- Use Cases:
- This update implements UX-driven improvements to the Payroll GL Compensation Share screen for better usability and consistency. The Add button is now repositioned and restyled for visibility, launching a modal for data entry instead of inline row editing. The grid replaces row-level edit/delete icons with checkboxes for multi-select actions, and confirmation dialogs now provide clear, contextual messaging about affected records.
- Use Cases:
- The Add button remains visible regardless of scroll position and opens a modal for easier data entry.
- Users can select one or multiple rows via checkboxes, enabling bulk edit or delete actions.
- Delete confirmation now specifies how many rows will be deleted (e.g., “You are about to delete 3 rows”).
- Multi-row edits retain the existing modal and show a confirmation summary of updated fields and record counts.
- Single-row edits follow the same modal workflow but skip the confirmation step for speed and simplicity.
- Impacted Users: Payroll admins and accountants managing GL Compensation Share configurations. These changes enhance workflow efficiency, prevent lost actions due to hidden controls, and align the UI with Arcoro’s modern design standards for multi-select grid interactions.
- Use Cases:
Sage Intacct:
- Several Sage Intacct integration issues were corrected, including missing Labor Class persistence, location fallback failures for cross-entity assignments, missing validations for REST-7001/7002 employee errors, inconsistent IsActive handling between labor classifications and departments, and removal of the noisy “Sage Intacct Key” from reader logs to improve clarity and prevent incorrect sync behavior.
- Use Cases:
- Labor Class now persists correctly when syncing contractors to Sage.
- Employees assigned to locations owned by another entity no longer lose their location in Hub.
- Invalid employee data (example: start date before birthdate, termination type without termination date) is caught before sending to Intacct.
- Department reader now maps “Active non-posting” the same as “Active.”
- Sync logs no longer include the confusing “Sage Intacct Key” line.
- Impacted Users: Integration admins and support teams working with Sage Intacct who need accurate employee/location data, consistent status mapping, cleaner sync logs, and early detection of invalid employee information.
- Use Cases:
- This release updates product naming conventions for Sage Intacct integrations to better align with the construction-specific offering. The “Sage Intacct” product and related configuration options are renamed to “Sage Intacct for Construction.”
- This release establishes Intacct entity-level business rules for supported customers with a single entity structure. The integration now enforces consistent read/write behavior across Payroll to Intacct and Intacct to Hub syncs: employee and contractor data is written and read only at the top-level, while GL transactions and time records are handled strictly at the entity-level. Dimensions such as locations, departments, and projects follow Intacct’s ownership model to ensure data integrity between Hub, Payroll, and Intacct.
- Use Cases:
- For Intacct customers configured with a single entity, the sync will now correctly respect Intacct’s dimension ownership rules.
- Employees and contractors created in Hub or Payroll will be written at the top-level, while GL and time entries post to the entity level.
- When reading data from Intacct, only records at their valid ownership level (top vs. entity) are included, preventing invalid or duplicate data reads. This ensures predictable, compliant, and auditable behavior across Intacct integrations.
- Impacted Users: Implementation teams, integration admins, and support staff managing Payroll–Intacct–Hub connections for single-entity Intacct customers, particularly those responsible for validating dimension mapping, employee creation, GL posting, and time record syncing.
- Use Cases:
- Adds contractor write support from Sage Intacct to Hub using Hub’s Employee endpoints with the new immutable IsContractor flag (set only at create). The writer mirrors Employee logic: matches by Intacct key first, then Contractor Identifier; maps Department/Location/Labor Classification by Intacct key, then name (warn on unmatched); enforces required fields/lengths (truncate with info, or error/skip where specified); and prevents flipping an existing Hub worker between contractor/non-contractor. A Hub product config switch enables the feature, and the writer performs granular updates (collection-only changes issue a single collection update call, not a full employee update).
- Use Cases:
- Intacct customers can onboard contractors via sync: new contractors create Hub Employees with IsContractor=1; employees create with IsContractor=0.
- Data hygiene: attempts to change a person’s contractor status after creation are blocked with a clear error; invalid or over-length fields follow the defined validation/truncation rules; unmatched Dept/Location/Labor Class log warnings but do not stop the contractor record from syncing.
- Efficient updates: modifying only phone/email/address/IDs triggers just that collection’s API call.
- Impacted Users: Implementation teams and integration admins running Intacct to Hub workforce syncs; Hub admins and support staff verifying contractor records and troubleshooting validation/matching outcomes in single-entity Intacct environments.
- Use Cases:
- This release corrects an issue where employee and contractor statuses from Sage Intacct were not properly carried into Hub during the initial sync, causing all imported records to appear as inactive. The sync now reads and maps the Status value from Intacct and sets the IsActive property accordingly in Hub when new employees or contractors are created. After the initial import, subsequent syncs will no longer update the status field, ensuring that any intentional status management within Hub remains intact.
- Use Cases:
- When performing an initial sync from Intacct to Hub, employees and contractors now retain their correct active or inactive status from Sage Intacct. For example, an active employee in Intacct will appear as active in Hub, while an inactive contractor will remain inactive.
- Any later changes to status in Intacct will not overwrite Hub’s value, maintaining control and consistency within Arcoro.
- Impacted Users: Implementation and integration teams onboarding Sage Intacct customers to Arcoro modules, as well as support staff verifying employee and contractor activation states during initial data migration and system setup.
- Use Cases:
- This release fixes an issue where Location deactivation changes from Sage Intacct were not reflected in Hub, even though the sync logs and update files correctly showed isActive = false. The system now properly updates the corresponding Location record in Hub when it is deactivated in Intacct, ensuring data alignment between systems.
- Use Cases:
- When a Location is deactivated in Sage Intacct, the Hub record will now accurately reflect this change by setting isActive = false.
- Additionally, business rule checks ensure integrity when deactivating a Location: if any employees or contractors in Check have that Location assigned as their Primary Work Location, an error is logged; if it appears in their Locations[] list, it is automatically removed to allow the Location update to proceed successfully.
- Impacted Users: Integration admins, implementation teams, and support staff managing Sage Intacct to Hub syncs who need accurate Location activation status and clean dependency handling across employees and contractors in Check.
- Use Cases:
- This release streamlines connector configuration and sync behavior across Arcoro, Payroll, and Sage Intacct integrations. The Location scope is removed from ExakTime (ET) and Core HR to Payroll syncs, as Hub now manages Payroll location alignment directly. In addition, the two existing Sage Intacct connectors (read/write) are merged into a single unified connector per company simplifying setup, improving maintainability, and reducing configuration redundancy.
- Use Cases: Customers integrating with Sage Intacct now only require one connector that supports both read and write operations. This unified connector, named “Sage Intacct for Arcoro”, replaces the prior dual configuration model. The Payroll for Sage Intacct configuration is now disabled for use as a source or destination and hidden from new connector creation. ET and Core HR syncs will now exclude the Location scope, relying on Hub to maintain Payroll location syncs.
- Impacted Users: Implementation and integration teams managing Intacct/Hub/Payroll connections, as well as customers configuring Sage Intacct integrations. This change simplifies connector setup, ensures consistency across data flows, and removes unnecessary configuration overhead for location and multi-connector setups.
- This release enforces business rules around inactive Rate Codes to prevent their use in new payroll processing while maintaining historical visibility. Once a Rate Code is marked inactive, it can no longer be selected or assigned in Payroll line items, time entries, or adjustments, ensuring data accuracy and compliance. The system now validates Rate Code activity across all payroll states (Draft, Save, Review) and provides user-facing errors or warnings when inactive codes are referenced. Historical payroll data and prior checks that used the inactive Rate Code remain fully visible and auditable.
- Use Cases:
- When a Rate Code is set to inactive:
- It no longer appears in dropdowns (Rate selection on Add Earning).
- Users cannot create or edit payroll entries using inactive Rate Codes.
- Existing draft line items that reference an inactive Rate Code will remain visible but cannot be saved or submitted until corrected.
- During payroll review, any inactive Rate Code reference triggers a validation error and blocks submission.
If a Rate Code is later reactivated, it becomes available again in dropdowns and can be reassigned to new entries.
- When a Rate Code is set to inactive:
- Impacted Users: Payroll admins and accountants managing earning rates and payroll processing within the system. This update ensures that inactive Rate Codes cannot be mistakenly used for new payroll activity while preserving historical integrity for reporting, auditing, and compliance.
- Use Cases:
- This release enhances the Sage Intacct Cost Code reader and its related automation to validate that all Cost Codes are properly associated with a Project before being processed. Since Intacct enforces this relationship during Time and GL data writes, the reader now filters out any Cost Codes that are not linked to a valid Project, ensuring that only compliant records are read and synced forward.
- Use Cases:
- When syncing Cost Codes from Intacct, only Cost Codes that have an associated Project will be included. This prevents downstream sync failures or rejections during Time and GL posting to Intacct, improving data integrity and reliability across the integration.
- Impacted Users: Integration admins, implementation teams, and support staff managing Intacct Cost Code syncs for customers using Payroll or Hub. This update ensures clean data input from Intacct, reducing troubleshooting and maintaining compliance with Intacct’s project-based Cost Code validation rules.
- Use Cases:
- This release introduces Job data synchronization from Sage Intacct to Payroll via Hub, enabling end-to-end visibility and consistency of project/job structures across systems. Since CheckHQ (Payroll) does not natively handle Job entities, the integration now reads Job data from Sage Intacct and writes it into Hub through the new Job Reader and Writer components. The ICheckHqProvider interface has been extended to include Get, Create, and Update methods to support Job synchronization with audit tracking and duplicate detection based on the ArcoroModel.Code property for backward compatibility.
- Use Cases:
- When syncing Job data from Intacct to Hub, the system now supports add, update, and no-change detection, including full handling of Job hierarchies (parent-child relationships).
- Validation ensures data integrity - Code and Name fields will error if they exceed database length limits, and Description fields will truncate with a warning. Duplicate detection prevents redundant job creation, and audit calls are triggered on every update for traceability.
- Sync fallback logic also ensures updates function correctly even when the source system isn’t Intacct or when the intacctIdentifier does not match.
- Impacted Users: Integration administrators, implementation teams, and developers managing Sage Intacct data flows. This change enables accurate job data propagation from Intacct into the Arcoro ecosystem, providing a foundation for future UI support and downstream reporting across Payroll and Hub.
- Use Cases:
- This release enhances the Hub Job Writer by adding contextual logging to improve transparency and traceability when syncing parent job relationships. Previously, logs only displayed the parentJobId, which made it difficult to interpret hierarchy updates. With this change, logs now include the parent job name alongside the ID, providing clearer context in both the sync and audit trails.
- Use Cases:
- When running an Intacct to Hub sync, any job creation or update that includes a parent job will now display detailed context in the sync log.
- For example, “Parent Job updated to Highway Expansion (ID: 12345)” instead of only listing the numeric ID. This allows admins to easily verify correct parent-child relationships during testing and troubleshooting without needing to manually query Hub data.
- Impacted Users: Integration admins, implementation specialists, and support engineers working with Sage Intacct to Hub job syncs who need visibility into hierarchical job relationships for data validation, audit review, or debugging parent-child updates.
- Use Cases:
- This update modifies the Sage Intacct to Arcoro sync behavior to prevent employee and contractor status changes (active/inactive) from being written to Arcoro. Status updates are now intentionally ignored to support operational differences between ERP and HR systems, ensuring that HR retains control over employment lifecycle tracking even when Finance marks records inactive in Intacct.
- Use Cases:
- When an employee transfers between entities, remains on unpaid leave, or is inactive for payroll purposes, their HR record in Arcoro remains active for compliance, benefits, or credential tracking.
- Prevents unintended deactivations of employees or contractors who are still managed in Core HR but inactive in Intacct.
- Eliminates timing conflicts where Finance closes payroll before HR completes offboarding or reporting tasks.
- Impacted Users: Integration admins, implementation teams, and HR/payroll managers using Sage Intacct and Arcoro. This ensures accurate HR data continuity while allowing Finance to independently manage payroll and accounting activity.
- Use Cases:
- Adds Sage Intacct to Hub Cost Code sync with a new Hub writer and product config support. Maps fields as: identifier to ID, name to Name (with Project prefix), isActive to IsActive, intacctIdentifier to sourceSystemId (when source is Intacct). Cost Code Names are made unique in Hub by prefixing the Project ID to the Name (e.g., “[24-002S-M] 00 00 00”), enabling 1:1 Intacct to Hub mapping and easy project identification in Connect. Includes duplicate detection (e.g., ${Id}-${Name}), length validation per Hub Swagger, and no write to Hub “id” (pass-through on edits). Adds validation in the Intacct GL writer to ensure the selected Project matches the Cost Code’s project prefix (name match). Adds validation in the Payroll Time writer to ensure Job and Cost Code prefixes match (blocked if mismatched).
- Use Cases:
- Intacct customers can sync Cost Codes into Hub with project-aware names, avoiding collisions and clarifying which Cost Codes belong to which project.
- Connect users can confidently select Cost Codes without losing project context.
- GL exports to Intacct are protected by validation that the Project and Cost Code belong together; time-writing validations prevent bad Job/Cost Code combinations.
- Impacted Users: Implementation teams, integration admins, and payroll/accounting staff using Intacct and Hub who need unique, project-scoped Cost Codes in Hub, clearer selection in Connect, and stronger validation on GL/time flows back to Intacct.
- Use Cases: