Version 5.3.5 (CM) - September 14th 2026

5.3.5 is the release where calculations arrive on the expenditure line. An administrator can now mark an expenditure field as calculated and give it an expression, with ready-made outlay presets for actual, forecast and budget figures, so the metrics you had to compute on the outside now lives in Weissr, per expenditure, and kept up to date. Period close gains a guard against negative future forecasts, and SCIM user provisioning moves into the application. The release also includes a large batch of bug fixes.

Weissr Capex Management

Calculated expenditure fields, computed per line

If you track spend after a decision has been made, the numbers you want per expenditure line have always been in Weissr. What was missing was the arithmetic: nothing was computed per line, so people worked with the data elsewhere. Property expressions already calculated values on the request. From 5.3.5 they run on the expenditures too.

📍 What's new

• Calculated expenditure fields: An administrator creates an expenditure field, marks it calculated, and writes its expression. The field shows as read only on the grid, and every line displays its own computed value.

• Per expenditure calculation: An expenditure is a request in its own right, so expressions behave exactly as they do on the request level, one level down. Same function library, same triggers: saving the expenditure, a change to its data, and the administrator's recalculate action.

• Autocomplete on the expression field: Typing suggests functions and presets with plain language descriptions, so nobody has to memorise syntax or keep the documentation open. The whole existing function library is suggested too, including GetProperty, If, IsEmpty, Sum, the text functions, MapPropertyValue, and the newer Switch, SafeDivide and IfEmpty.

• Derived metrics for free: Variance and percentage consumed need no separate feature. They are expressions that combine outlay functions.

• Values inherited from the parent request: An expression on an expenditure can read a property from its parent request, with no new function and no new syntax. When the parent value changes, the expenditure expressions that use it recalculate.

• Recalculate all: An administrator can trigger a recalculation of the calculated values on every expenditure request, one capex request at a time.

📌 Note: Whether a field is calculated is a permanent choice, fixed when you create the field. See Field behaviour is fixed once a field is created below.

💡 Info: This works in one direction only. An expression on a capex request resolves an expenditure property to empty, because aggregating line values back up to the request is a later phase.

👉 Learn how to create a calculated expenditure field

Outlay functions: actuals, forecast and budget per line

The outlay figures behind every expenditure line are now available to expressions through a single generic outlay function, offered to you as ready-made presets. Pick a preset, save, and the value is there. Each preset comes in a cash and an accrual variant.

📍 What's new

• Presets and functions kept apart: A preset is a ready-made, complete expression. A function is a building block you combine and fill in yourself. The suggestion list shows the two as clearly separated groups.

• Hand-written combinations work too: Any valid combination of outlay data, scenario and time window computes, even one that is not offered as a preset, for example a year to date window over forecast rows. Invalid combinations fail validation with a clear message.

• Pending transactions become visible: Transaction amounts for the current period that have not yet rolled into actuals used to be invisible on the grid. The pending transactions function sums them, in the matching cash or accrual perspective.

• Only what changed is recalculated: A change recomputes the values whose inputs it touched, in dependency order. An actuals import recalculates the cash actual windows and the stitched value. Period close, and a move of the forecast date, recalculate everything that resolves against the forecast date.

📌 Note: The current year is always the fiscal year containing the forecast date, never today's calendar date. Stored values must never depend on the clock, so the forecast date is the single time cursor of the feature. It moves only when period close advances it, or when someone moves it by hand.

💡 Info: Only expenditure lines with an external ID can carry transactions. A line without one shows blank, and a line with an external ID but no pending transactions in the period shows zero. More generally, blank means the function does not apply to that line, and zero means it applies but its window sums to nothing.

👉 Learn about the outlay functions and their presets

👉 Learn how to use the full property expression function library

Field behaviour is fixed once a field is created

Until now a field could quietly become calculated just by having an expression, and deleting the expression turned it back into a field people could type in. An administrator could also change what a field applied to after it had been created. Because values are stored per level, the old values were silently left behind and the field's history stopped making sense. From 5.3.5, the settings that define how a field works are locked once the field exists.

📍 What's new

• Calculated is an explicit choice at creation: You decide when you create the field, and the choice can never be reversed in either direction. Turning it on shows the options that apply to a calculated field and hides the ones that do not.

• Locked settings: Field type, Applicable to request type, and the calculated flag. Any setting whose change would need a value migration behind the scenes is now fixed.

• Everything inside those choices stays editable: Adding codes to a code field, changing the default value, changing the aggregation rule or the expression, plus name, description, ordering and the filter flag. Values recalculate where that matters.

• One way of calculating at a time: While receives value from a model is on, you cannot enter an expression, and the other way around.

• Enforced, not just hidden: A locked setting is greyed out in the interface, and the API rejects an attempt to change it with a validation error rather than ignoring it quietly.

• Clearer options when you create a property: New request properties offer Capex and Expenditure, each with an explanation of what it means, so fields land at the right level from the start.

⚠️ Warning: Applicability is locked for every change, including one that looks harmless such as Capex to Global. One rule, no exceptions. Plan what a field applies to before you create it.

📌 Note: Deleting an expression keeps the last calculated values. Values are recalculated only when the expression changes, or when another way of calculating is chosen.

👉 Learn how request properties are configured

Prevent negative future forecast on period close

When a period closes and the forecast delta adjustment would leave the future forecast negative, overspend gets absorbed into a reduced future forecast and your real budget position disappears from view. A new closure setting stops that happening.

📍 What's new

• New closure setting: Prevent negative future forecast sits with the existing closure settings on the period group, next to Forecast delta adjustment, Use separate expenditure row, and Accrual cash balancing adjustment. It is off by default.

• Zeroing from the forecast start date forward: When the check finds a negative future forecast, the affected values are zeroed in the forecast start date month and forward, so the true budget position stays visible.

• The check follows your delta configuration: If you use a separate delta expenditure row, the check looks at the capex request's total future forecast summed across all expenditure requests, and only the delta row is zeroed. Without a separate row, each expenditure request is checked against its own future forecast and zeroed individually.

• The other expenditure rows keep their forecasts: With a separate delta expenditure row, the forecasts on the individual expenditure rows are left alone, so the request total shows the overspend for the whole project instead of hiding it.

📌 Note: Forecast deltas accumulate onto the value already in the target period, so the check applies to the resulting future forecast rather than to the delta on its own. A later close starts from the zeroed values.

💡 Info: When actuals arrive on an aggregated actual cost row, Weissr cannot tell which expenditures they belong to, typically the ones planned before the decision. Adjusting those forecasts stays your decision to make.

👉 Learn how to configure Prevent negative future forecast

The ERP transactional data import log tells you what happened

The integration log for an ERP transactional data import used to record a final status line and any validation errors, and nothing else. When transactional data later looked wrong or missing, there was nothing to reconstruct the import from. Every ERP transactional data import now writes a proper summary.

📍 What's new

• Import summary in the log: How many rows were received, how many were imported, and for how many requests.

• Periods listed: Each imported period, by fiscal year and month, with its row count.

• Every path covered: Accrual, cash and commitments, through both the ERP API call and the CSV file import.

• Optional payload capture for support: A server-side setting, off by default, stores the received payload as a details entry in the same integration log, so support can see exactly what was sent.

💡 Info: The payload setting is meant for time-limited troubleshooting and is switched on with your Weissr contact. Payload log entries are not cleaned up automatically in this version.

Behind the scenes: entered money values get their own storage

Money values you type in used to share a table with calculated values. The calculation mechanics write to that table by clearing whole scopes of values and re-inserting them. In 5.3.5, money storage is separated by origin.

📍 What's new

• Dedicated storage for entered values: Money values entered by a person, at both request and expenditure level, now live in their own storage, out of reach of any recalculation.

• Lossless migration: Existing entered values are moved in a one-time migration that either completes or does not happen at all. Values keep their request currency amounts.

• Ready for multi-currency: The new storage carries currency information from day one, so nothing has to change structurally when multi-currency within requests arrives.

💡 Info: Nothing to configure and nothing for you to do. FX recalculation behaves exactly as before. Only the storage location changed.

Outlay perspective terminology in the API

The accrual side of the outlay perspective was called "spend" in the API, while the product and this documentation have always said "accrual". The API now uses accrual terminology throughout.

💡 Info: If you send transactional data to Weissr from your ERP system, nothing changes for you. The integration gate endpoint takes accrual as the canonical value and still accepts spend. Ordinary uses of the word spend are untouched, including budget fields and property names where spend simply means spending.

Common

SCIM setup moves into the application

Connecting your identity provider's user provisioning to Weissr used to mean a manual setup on the server with a Weissr technician involved. From 5.3.5 an administrator does it in the product, on the same Administration → Security → SSO configuration tab where SSO providers are already managed, so provisioning and authentication are configured in one place against the same Registration ID.

📍 What's new

• SCIM configured from the interface: SCIM is enabled and configured directly in Administration, with no backend configuration and no Weissr technician needed.

• Attached to an existing SSO provider: You choose which of your configured providers owns user management over SCIM. The link is stored against that provider's Registration ID, matching the way external users are already resolved.

• Service user registered for you: Weissr can create the dedicated SCIM service user as part of the setup and give it the permissions SCIM needs, instead of one being created and wired up by hand.

📌 Note: The SCIM options appear on the tab only once SCIM is switched on in your installation's configuration. That is a server-side setting, so ask your Weissr contact if you do not see them.

👉 Learn how to configure SSO and SCIM in Administration → Security

Bug fixes

This release includes fixes for issues in version 5.3.3 or earlier.

Capex Management

• Creating a request no longer shows an error and creates the request as undefined when an expression property has an invalid formula.

• A modified year cell is now marked with a triangle after an actuals import.

• Expression properties are recalculated on a request when a code property is set by a relation rule with no initial value.

• Money property values are now copied to the new expenditure in the Capex tab when an expenditure is duplicated.

• Transactional data import now deletes only the data in the payload, instead of the cross product of all order ids, periods and fiscal years found in it.

• Actuals import no longer fails with a request-scope error when the import runs on an asynchronous task thread.

• The ERP transactional data API no longer stores rows with year 0 and period 0, which broke the request's transactional data view.

• Cash flow import no longer returns an unhandled error when the import sheet is corrupted and a row key is not found.

• Period close aggregation status is no longer downgraded to "Finished with errors" by transactional rows of unrelated period groups or deleted requests.

• The cash flow model now uses the currency from the correct node.

• The decision version PDF and XLS in final approval now show the correct data.

• The Arimo font now loads in PDF export instead of silently falling back to Helvetica.

• The ERP Export and Import Capex permission now correctly overrides node and property permissions.

• Historical data is no longer deleted when a route switch meets the same route step further down the approval route.

• Assigning a decision maker at the final approval step is no longer possible when the request has already been approved in additional requests.

Administration

• The default value is no longer cleared when Applicable to request type is switched to Expenditure in the request property dialog.

• The tooltip for the first column and row in the permission matrix is no longer covered by other elements.

• Saving a currency with a very long description no longer causes an unhandled error.

• The user group audit log no longer contains duplicated assignment and unassignment records after a user group assignment import.

Common and platform

• Asynchronous capex recalculation no longer keeps a stale FX rate.

• A missing FX rate is no longer cached indefinitely, which caused conversions to fall back silently to a rate of 1.0.

• Error logs now print the real request path.

AI Chatbot

• Chatbot answers are shorter and more precise instead of returning everything found in the documentation and resources.