Household accounting and personal-finance workspaces
Overview
Personal and household finance is a valid BusDK use case, but it is not the same thing as Finnish statutory business bookkeeping. Ordinary household money management is not the same reporting problem as KPA- or PMA-shaped annual statements, even when the same repository still benefits from deterministic accounts, journals, attachments, and audit-style traceability.
For this use case, the practical pressure usually comes from tax evidence, receipts, and note-taking obligations for specific income-producing activity such as rental income, investment activity, forestry, or other non-business tulonhankkimistoiminta. Kirjanpitolaki 1336/1997 is still the key boundary because it frames ordinary household use differently from business bookkeeping, while Verohallinnon guidance on luonnollisen henkilön ilmoittamisvelvollisuus and muistiinpanovelvollisuutta koskeva päätös 881/2024 define when records must still be kept in chronological, tax-defensible form.
What a personal workspace should optimize for
A personal workspace should default to reports that answer household questions directly. The normal starting set is monthly budget versus actual, cashflow, net worth, account-movement summaries, and transfer-aware views that keep movement between a user’s own accounts separate from true income and expense. Those outputs are easier to understand in household use than company-style profit-and-loss and balance-sheet layouts.
The category baseline should still be systematic. COICOP 2018 is the strongest general-purpose default for expense categories because it gives a stable structure for spending analysis, while still allowing workspace-specific subcategories for household routines, children, hobbies, or project-like spending.
The same workspace also needs long-lived evidence handling. Verohallinnon receipts guidance makes tax-relevant receipts, deduction evidence, and acquisition-cost documents operationally important even when a user is not running a company. BusDK should therefore treat attachments, tax tags, and retention-oriented evidence links as first-class parts of the household workflow rather than as business-only bookkeeping accessories.
Banking data and imports
The safest default path for household banking data is file import first. ISO 20022 account-report files such as camt.053 and camt.054 fit a repository-based workflow well because they can be imported without immediately taking on the compliance and operating-model burden of a live bank-feed service.
If Bus later offers live household bank feeds, that design must respect PSD2 and the strong-authentication and secure-communication RTS. That means a normal product direction should assume secure API-based consent flows rather than any screen-scraping or credential-sharing model.
Household collaboration and privacy
Household finance is often shared, but not always fully shared. A useful personal workspace therefore needs household members, shared accounts, transaction splitting, and visibility levels that can distinguish summary-only access from row-level access. A family may want one combined cashflow view while still hiding selected transaction details.
That is not only a UX preference. Personal finance data is personal data, and GDPR matters even when the end user is “only” managing household money. The service side should therefore bias toward minimization, explicit retention behavior, exportability, and delete paths rather than assuming that all repository content should be visible to every participant forever.
Workspace defaults and planned BusDK direction
The current BusDK reporting surface is still business-oriented. bus reports can already render useful PDFs from a personal repository, but the terminology, grouping, evidence-package defaults, and metadata remain shaped primarily for business and statutory reporting.
BusDK now has a workspace-level entity-kind value under busdk.accounting_entity. Set it to personal when the repository is a household or natural-person workspace, and keep business for company/statutory-default workspaces. That shared metadata gives downstream modules one deterministic source for switching report families, evidence-pack profiles, metadata expectations, and wording without relying on local wrapper scripts.
The remaining gap is consumer behavior. Today the metadata exists in workspace configuration, but the main reporting defaults are still business-oriented. In practice that means a personal workspace can now declare itself correctly, while bus-reports still needs dedicated household defaults and layouts so personal workspaces stop looking like company filing projects by default.
That design boundary matters because the same repository engine can support both domains while still keeping the defaults honest. A personal workspace should not accidentally look like a company filing project, and a business workspace should not silently fall back to household-style reporting.