Want to be on the release mailing list? Send an email to support@ason.ch to subscribe.
Release 04.11.2026
| Environment | Date |
|---|---|
| Sandbox | 04.11.2026 |
| Ason Production | 04.11.2026 |
| Own instances | 04.11.2026 |
Added
Insurance cases - table view via groupId (optional, no action required)
- New optional property
groupIdon case fields. Fields of a case with the samegroupIdbelong together and can be shown as one row of a table, for example one contribution code with all its values. Fields without grouping havegroupIdnull - Frontend: the Ason frontend already shows these groups as a table (example implementation). A partner frontend can do the same by grouping the fields of a case by
groupId, in the order oforder - No action required: if
groupIdis not evaluated, everything works as before and the fields are listed one below the other
Converted cases: the social insurance cases on company level - accident insurance (UVG), supplementary accident insurance (UVGZ), daily sickness allowance insurance (KTG) and occupational pension (BVG), including their onboarding cases. Examples: Manage accident insurance (one row per operating part) and Manage sickness daily allowance insurance (one row per contribution code).
Release 15.10.2026
Show release details
| Environment | Date |
|---|---|
| Sandbox | 06.10.2026 (evening) - test the changes in advance |
| Ason Production | 15.10.2026 |
| Own instances | as per separate communication |
Changed
AccountingStartDate - new rule (behavior change)
- Only January 1 is permitted as
accountingStartDate - Exception: if the new payroll property
foundedDuringYearistrue, the first day of any month is permitted (e.g. June 1). A date within a month (e.g. June 25) is never possible - Why: payroll accounting runs monthly and on a calendar-year basis, so starting mid-month is not correct. A company founded during the year is the only case where another start date than January 1 makes sense from a payroll standpoint - it is mapped explicitly via
foundedDuringYear, always on the first day of a month
Period closing only with complete data
- The accounting voucher (Buchungsbeleg) and the chart of accounts must be stored as a Regulation
- If a report can't be generated because data is incomplete or incorrectly entered, the Payrun Period can't be closed. First examples:
| Report | Blocking condition |
|---|---|
| Accounting voucher | Missing or incorrect account assignment |
| Withholding tax statement | Missing or incorrect SSL number |
| Withholding tax statement | Missing employment of the partner, for employees subject to withholding tax with code "C" |
| Withholding tax statement | Missing residence type, for cross-border commuters subject to withholding tax |
| Statistics notification | Missing information when the wage type changes |
| EMA notification | Missing family compensation fund (FAK) in a canton in which a place of work is registered |
| ELM transmission | No place of work recorded at company level |
New error codes are added on an ongoing basis - the cases above are only the first examples.
If an error message appears
- Check the error code and error message in the attributes of the report document
- Correct or complete the affected data (e.g. account assignment or SSL number)
- Regenerate the report
- Close the period
API - DELETE endpoints removed (behavior change)
- Seven DELETE endpoints were removed from the API. They allowed payrolls, divisions, case values and case documents to be deleted directly
- These endpoints were never intended for use by partners. We do not expect that any partner uses them or has used them, so no action is required
- Why: deleting data directly via the API bypasses the controlled processes of the payroll. It can lead to data loss, inconsistent payroll results or manipulated history. This is not in the interest of Ason - payroll data must stay complete, traceable and auditable
| Operation | Endpoint |
|---|---|
DeletePayroll | DELETE /api/tenants/{tenantId}/payrolls/{payrollId} |
DeleteDivision | DELETE /api/tenants/{tenantId}/divisions/{divisionId} |
DeleteDivisionAttribute | DELETE /api/tenants/{tenantId}/divisions/{divisionId}/attributes/{attributeName} |
DeleteCompanyCaseChange | DELETE /api/tenants/{tenantId}/companycases/changes/{caseValueId} |
DeleteCompanyCaseDocument | DELETE /api/tenants/{tenantId}/companycases/{caseValueId}/documents/{documentId} |
DeleteEmployeeCaseChange | DELETE /api/tenants/{tenantId}/employees/{employeeId}/cases/changes/{caseValueId} |
DeleteEmployeeCaseDocument | DELETE /api/tenants/{tenantId}/employees/{employeeId}/cases/{caseValueId}/documents/{documentId} |
Correcting data
Mistakes in payroll data are not corrected by deleting records. Instead, a new corrected value is entered, so the full history stays intact. If a deletion is really required, contact support@ason.ch.
CaseChangeSetup/CaseSetup/CaseValueSetup created field (behavior change)
POST /api/tenants/{tenantId}/payrolls/{payrollId}/cases/sets
- Providing a
createdvalue for a CaseChangeSetup/CaseSetup/CaseValueSetup will no longer take effect. We will always use the current datetime for this field - Why:
createdis the system's record of when a value was entered. It must not be controlled by the caller, because otherwise the history of payroll data could be backdated or manipulated and could no longer be traced reliably