Bug Fix: computeBusiness Was Mixing Property and Self-Employment Transactions
Bug Fix: computeBusiness Was Mixing Property and Self-Employment Transactions
Release: v1.0.460
Severity: Medium
Affected area: Quarterly summary calculations (/dashboard/quarterly)
What happened
When the platform computed quarterly summary figures for a business — either a property business or a self-employment (SE) business — it called an internal function, computeAggregates, without telling it which type of transactions to restrict to. Specifically, it passed null for propertyId, which the aggregation query interpreted as "fetch every transaction for this organisation".
This meant that for any organisation running both a property business and an SE business side-by-side, the quarterly summary calculation for one business type was reading transaction data belonging to the other.
Why it mostly didn't cause obvious errors (but still could)
The category-to-column mapping tables — INCOME_CATS for property and SE_CATEGORY_TO_COLUMN for SE — act as a natural filter after the fact: a category key that doesn't appear in the relevant mapping simply contributes zero to the total. This meant:
- SE categories like
se_turnoverpassed through a property business computation but summed to zero viasumCategories(agg, INCOME_CATS). - Property categories like
rental_incomepassed through an SE business computation but found no match inSE_CATEGORY_TO_COLUMN.
In the common case, the totals remained correct.
However, the aggregate record built from all transactions was larger than it needed to be, and the normaliseCategoryKey step (which converts raw DB category strings to camelCase lookup keys) could, in edge cases, produce a collision between an SE category name and a property camelCase key — or vice versa. If such a collision occurred, a transaction from the wrong business type would be silently counted in the summary.
The underlying inconsistency
This bug had already been identified and fixed in a different part of the same file. The listBusiness function — which powers the running-totals shown alongside the quarterly summary — was given a dedicated categoryFilter parameter precisely to avoid this cross-contamination. computeBusiness, which drives the actual submission-ready figures, was inadvertently left without the same guard.
What changed in v1.0.460
computeBusiness in src/lib/routers/quarterly-summary.ts now passes an explicit business-type category filter when calling computeAggregates:
- Property business: only transactions with property-income/expense category prefixes are aggregated.
- SE business: only transactions with
se_-prefixed category keys are aggregated.
This aligns computeBusiness with the existing behaviour of listBusiness and ensures that quarterly summary figures are always computed from the correct, isolated transaction set.
Who is affected
Organisations that have both a property business and a self-employment business registered under the same account. Single-business organisations would not have encountered cross-contamination because there were no transactions of the other type to bleed across.
Action required
No action is required from users. The fix is applied server-side. Quarterly summary figures for mixed property/SE organisations will now be correctly isolated. If you previously noticed unexplained discrepancies in your quarterly totals and you operate both types of business, we recommend reviewing your most recent quarterly figures after updating to v1.0.460.