Household Expenses Documentation

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 and ledger boundary

The household expense ledger records money spent for household reporting. It preserves record-level context while producing comparable monthly totals.

• Capture amount, date, category, payer or member context, notes, and optional card
• Preserve original currency while reporting converted household values
• Feed budgets, dashboard totals, analytics, and exports from one source

ReceiptVis assisted entry

When ReceiptVis is enabled for your account, you can scan a receipt photo or PDF while adding an expense (including Quick Add). The result is a draft you must review before saving. Attachment-only uploads still work without ReceiptVis.

• Use Scan with ReceiptVis on web or Android when the control is visible.
• Support multi-image long receipts and optional per-image crop.
• Verify amount, merchant, date, category, and tip/tax notes before save.
• See the ReceiptVis documentation module for entitlement, limits, and privacy notes.

Anatomy of an expense

An expense is a dated ledger record. Its amount and currency describe the transaction; category, note, card, and member attribution explain it. Editing the source record can update every downstream summary.

• Transaction date controls period placement.
• Category controls category rollups and category budgets.
• Attribution supports accountability but does not by itself move money.
• Attachments or notes are supporting context, not calculation inputs unless explicitly shown.

Create, review, and edit

• Enter the transaction date rather than the date you remembered it.
• Choose the currency printed by the source.
• Use a stable category and a concise note.
• Review conversion before saving when currencies differ.
• Correct the original row instead of adding an offsetting duplicate unless audit practice requires both.

Original and household currency

Cross-currency expenses retain the original amount and a reporting value in the household currency. Reports add comparable reporting values; they do not add unlike currencies directly.

• Changing a reporting currency or rate basis can affect aggregates.
• Rounding occurs at defined currency precision.
• The original transaction remains the reference for statement reconciliation.

Categories and classification

Categories make reports and budgets useful. Reclassification changes category history but not the transaction amount.

• Prefer a consistent household taxonomy.
• Use notes for detail rather than creating one-use categories.
• Review uncategorised entries before closing a month.
• Category deletion or replacement should preserve an understandable destination.

Cards, payers, and member attribution

A linked card identifies the payment instrument; member attribution identifies who recorded or is associated with the expense. Neither should be confused with Split contribution and share arithmetic.

Budget and dashboard impact

Saving, editing, deleting, moving, or recategorising an expense can change budget usage and dashboard totals. Alerts are consequences of those totals, not additional transactions.

Recurring references and repeated bills

Recurring settings can help organise repeated obligations or reminders, but public documentation does not promise that recurring expenses are silently auto-generated. Confirm each actual ledger record and its date, amount, and status.

Imports, exports, and duplicates

• Map dates, amounts, currencies, and categories before committing an import.
• Preview validation failures and conversion requirements.
• Use stable identifiers where the import workflow offers them.
• Exports reflect the selected scope and current permissions.

Imported data should be reconciled against statements and source files. AccountHouse cannot infer every merchant alias or household intent correctly.

Corrections and reconciliation

• Compare monthly totals to source statements.
• Inspect missing currencies or rates.
• Search for duplicate amount/date pairs.
• Check deleted, excluded, or filtered rows.
• Document unusual corrections in notes.

Permissions and visibility

Role and household permissions govern who can view, add, edit, or remove records. A user who sees a summary may not necessarily have permission to alter every contributing row.

• Administrators manage household-wide policy.
• Members operate within assigned permissions.
• Viewer access is read-oriented.
• Web and mobile access can be constrained independently.

Edge cases

• Refunds and reversals should use the supported correction pattern and clear notes.
• A transaction near midnight can belong to a different local date if the source date is wrong.
• Zero or malformed amounts should be rejected or corrected.
• Partial reimbursements need explicit records; do not hide them in notes.
• Rounding can produce minor display differences while reconciled totals retain currency precision.

Troubleshooting unexpected totals

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.
• Expense notes can contain sensitive merchant or family information; enter only what the household needs.
• Exchange-rate availability and rounding do not guarantee the rate used by a bank or card issuer.