Excluded versus one-time transactions

[oyosounds]

One-time transactions currently appear to be removed from the same analytics and totals as Excluded transactions.

This makes it impossible to distinguish between non-operational / administrative cash movements (Excluded) and real but non-recurring business events (One-time).

As a result, strategic or exceptional business spending disappears entirely from yearly and historical reporting.

Expected Behavior

Excluded transactions

Should NOT appear in:

• totals
• reports
• analytics
• budgets

be treated as operationally irrelevant.

One-time transactions

Should appear in:

• yearly totals
• category totals
• historical spending
• net worth calculations

NOT affect:

• recurring monthly forecasts
• recurring burn-rate calculations
• budget predictions

This would allow users to:

• separate recurring operations from strategic investments
• still retain accurate historical analytics

Current Behavior

Both transaction types disappear from:

• Total expenses
• yearly totals
• operational reports
• budgeting
• do not contribute to aggregate spending metrics

[oyosounds]

@dosu

[dosubot]

Hi @oyosounds! I'm Dosu and I’m helping the sure team.

Thanks for the detailed write-up — this is a valid design gap. After looking through the codebase, I can confirm what you're seeing:

The root cause: All analytics queries (income statements, category stats, reports, exports) filter out one_time transactions using the same BUDGET_EXCLUDED_KINDS constant that also excludes funds_movement and cc_payment [1]. This filtering is applied universally — there's no distinction between "exclude from forecasts/budgets" vs. "exclude from historical totals."

Specifically, the pattern looks like this across the codebase:

WHERE ae.excluded = false
  AND t.kind NOT IN ('funds_movement', 'one_time', 'cc_payment')

This appears in income statement totals [2], category statistics [3], family statistics [4], budget calculations [5], and report exports [6].

Historical context: A migration actually converted previously-excluded entries to kind: 'one_time' but kept excluded: true as well [7], with the comment "They remain excluded as well since users were using excluded as 'one time' before." This suggests the original intent was to give one_time different semantics than excluded, but the analytics queries never differentiated them.

What would need to change: To implement the behavior you described (one-time transactions appearing in yearly totals, category totals, and historical spending, but NOT affecting recurring forecasts/budgets), the analytics queries would need to be split into two categories:

1. Historical/aggregate queries (yearly totals, category breakdowns, net worth) — only filter excluded, not one_time
2. Forward-looking/recurring queries (budget predictions, burn-rate) — filter both excluded and one_time

Currently there's no forecasting module in the codebase, so the distinction only matters for historical reporting today — but the architecture would need this separation regardless.

This is a meaningful feature request. The kind enum infrastructure is already there to support it; it's the query layer that treats one_time too broadly.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[oyosounds]

@dosu What is currently the expected behaviour of one-time and excluded transactions?

[dosubot]

Here's what each is currently designed to do:

Excluded (excluded flag on Entry) — "Remove this from everything"

• Description shown to users: "Excluded transactions will be removed from budgeting calculations and reports." [1]
• Filtered from: budget calculations, reports, income statements, account activity feeds, and uncategorized transaction queries [2] [3]
• Also used automatically by the system for: stale pending transaction cleanup (after 8 days), split parent entries, pending-to-posted reconciliation, and trade conversions [4]
• Protected from provider sync overwrites [5]
• Visual indicator: reduced opacity in transaction lists [6]

One-time (kind: "one_time" on Transaction) — "Real but non-recurring"

• Description shown to users: "One-time transactions will be excluded from certain budgeting calculations and reports to help you see what's really important." [7]
• Part of BUDGET_EXCLUDED_KINDS alongside funds_movement and cc_payment [8]
• Visual indicator: orange asterisk icon with tooltip "One-time [income/expense] (excluded from averages)" [9]
• Still appears in transaction search/lists — only excluded from budget analytics [8]
• NOT classified as a transfer (unlike funds_movement or cc_payment) — it's real income/expense, just non-recurring [10]

The gap you identified: Despite the user-facing description saying "certain budgeting calculations," one-time transactions are currently filtered from all analytics queries using the same BUDGET_EXCLUDED_KINDS filter — income statements, category stats, reports, and exports. There's no query path that includes one-time transactions in historical/yearly totals while excluding them only from recurring forecasts. The wording implies a narrower exclusion than what's actually implemented.

The historical context is also telling: a migration converted all previously-excluded entries to kind: 'one_time' but kept excluded: true as well [11], which suggests the two were treated as equivalent rather than distinct at that point.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.