Documentation

Recurring Expenses Documentation

Recurring expense templates that post ledger rows on a schedule — with an optional approval mode that asks before each occurrence.

Audience: Household members who manage repeating spending. · 5-page PDF · v6.26.1

Logo header · watermark · generation date · multi-page

How to read this document

Sections move from purpose → concepts → calculation process → worked examples → edge cases. Formula boxes use plain mathematical notation for clarity; they are conceptual summaries, not API contracts.

  • Point lists call out operator-visible behaviour.
  • Callouts mark warnings, limitations, or important qualifications.
  • Worked examples use round numbers so you can reproduce the arithmetic by hand.

Purpose

A recurring expense is a template plus a schedule. When an occurrence falls due, AccountHouse creates the actual expense row in the household ledger — you do not re-type the rent every month. Patterns you want eyes on can instead ask for approval before each occurrence posts.

  • Templates carry the full expense shape: amount, category, card, notes
  • Occurrences post automatically on their scheduled date, or after your approval
  • Generated rows are ordinary ledger expenses — editable and deletable like any other
  • Managing recurring patterns requires the recurring-management permission (household admins by default)

Schedules

Cadence options cover the common household shapes: daily, weekly, monthly, yearly, and custom days of the week (for example, every Tuesday and Friday).

  • Each pattern has a next-run date derived from its cadence.
  • Patterns can be edited, paused, resumed, or stopped at any time.
  • You can change just the amount without touching the rest of the template.
  • The Calendar shows upcoming occurrences alongside payables and reminders.

Backfill preview

When creating a pattern with a start date in the past, a backfill preview lists exactly which historical occurrences would be created. Nothing is written until you confirm the preview.

How occurrences become expenses

On its scheduled date, an occurrence creates a real expense row using the template's fields. The row lands in the ledger, counts against budgets, and appears in analytics like any manually entered expense.

Posted occurrence

Template fields + scheduled date → one ledger expense row

  • Generated rows are attributed and categorised from the template.
  • Budgets see the spend on the day the occurrence posts.
  • Deleting a pattern stops future generation; already-posted rows remain in the ledger.

Approval mode

Switch a pattern to approval mode and each occurrence asks before posting instead of assuming. Three answers cover real life:

  • Approve — the expense posts on its scheduled date.
  • Decline — the prompt hides for 24 hours, then asks again. Decline means 'ask me later', not 'delete'.
  • Skip this month — the prompt stops until the next calendar month.
  • Pay now — covers 'I skipped this month but ended up paying it anyway'; posts the expense immediately.

A gym membership under review

  1. The membership pattern is set to approval mode while you decide whether to keep it.
  2. On the 1st, the occurrence asks instead of posting.
  3. You tap Skip this month while you think it over.
  4. Mid-month you go anyway and pay at the desk — Pay now records it.

The ledger reflects what actually happened, and nothing posted without you.

Deferred prompts are recoverable

Declined and skipped prompts are hidden by default but not gone — they can be listed again if you want to review what is waiting.

Recurring versus payables and reminders

  • Recurring expenses generate ledger rows on a schedule.
  • Payables track obligations with due dates, reminders, and an execution history — executing a payable is what creates its expense.
  • Calendar reminders are notes with notifications; a reminder never creates an expense by itself.
  • Use payables for bills you confirm, recurring for spending that should book itself.

Privacy, advice limits, and what we do not publish

AccountHouse is a household tracking and organisation tool. It is not a bank, payment processor, tax advisor, or investment advisor. Forecasts, health scores, balances, and alerts are informational.

  • Household data is scoped to your household; other families cannot see your ledger.
  • Public documentation explains product behaviour and calculation concepts, not proprietary internals.
  • Exact scoring weights, anomaly thresholds, cryptography parameters beyond high-level algorithms, and operational detection rules are reserved.
  • Approval decisions (approve, decline, skip) are recorded per occurrence for the household's own history.

Intellectual property boundary

This document describes what AccountHouse calculates and which inputs matter. It does not disclose source algorithms, secret constants, or implementation details sufficient to reconstruct proprietary systems.