What Happens When You Delete a Bank Account With 500 Transactions Behind It?

In a personal finance app, deleting an individual transaction is a minor recalculation.

Deleting an entire account, however, is the financial equivalent of detonating a structural support beam inside a building.

Consider what an account actually represents:

• It holds an opening balance and a running balance.
• It is referenced by hundreds or thousands of historical transactions spanning multiple years.
• It may have acted as the source or destination for dozens of inter-account transfers to other bank accounts.
• It may have linked active investment holdings, recurring bill schedules, or credit card billing statements.

If your application allows a user to delete an account with a single unverified DELETE FROM accounts WHERE id = ?, your database will either crash due to SQLite foreign key constraint failures or leave behind severed counter-party balances.

Here is how FinLedger designs account deletion safety through a multi-step defense-in-depth pipeline.

The Archival Alternative: Why You Rarely Want to Delete

Before discussing deletion, the most important product decision is offering Account Archival.

In 90% of real-world scenarios, a user does not want to destroy an account's history; they simply closed a bank account or canceled a credit card:

• They switched from Bank A to Bank B.
• They closed an old credit card to avoid an annual fee.

flowchart TD
    subgraph ArchivalVsDeletion["Archival vs Deletion"]
        direction TB
        UserAction["User Closed a Bank Account"]

        subgraph SafeArchival["Option A: Archive Account (Recommended)"]
            A1["Set isArchived = true"]
            A2["Hide from Daily Account Pickers & Transfer Dropdowns"]
            A3["Preserve 100% Historical Statements & Past Tax Reports"]
            A4["Retain Relational Foreign Key Integrity Forever"]
        end

        subgraph PermanentDeletion["Option B: Permanent Deletion (Danger Zone)"]
            D1["Double Confirmation Dialog"]
            D2["Verify No Active Dependencies (Loans, Portfolios)"]
            D3["Recalculate All Counter-Party Accounts from Past Transfers"]
            D4["Cascade Delete Transactions, Attachments, and Statements"]
        end

        UserAction --> SafeArchival
        UserAction --> PermanentDeletion
    end

When an account is archived:

1. The isArchived flag is set to true.
2. The account is immediately hidden from active transaction entry pickers, transfer dropdowns, and daily dashboard cards.
3. Crucially, all historical transactions, past annual tax statements, and carried-forward ledger mathematics remain 100% intact.

Permanent Account Deletion: The Safety Pipeline

When a user insists on permanent deletion (located inside the Settings "Danger Zone"), FinLedger executes a strict four-stage safety sequence:

flowchart LR
    subgraph DeletionStages["Account Deletion Safety Pipeline"]
        direction TB
        Stage1["1. Dependency Inspection:
Check for Active Portfolio Holdings or Linked Loans"] --> Stage2["2. Double-Confirmation Guard:
Explicit Warning Dialog Requiring Confirmation"]
        Stage2 --> Stage3["3. Counter-Party Recalculation:
Refund all external accounts involved in past transfers"]
        Stage3 --> Stage4["4. Atomic Cascade Cleanup:
Purge transactions, disk attachments, and statements"]
    end

Stage 1: Dependency Check (BlockedByDependencies)

Before allowing deletion, AccountRepository.deleteAccount() inspects relational dependencies:

• Does this account have active portfolio investment holdings?
• Is this account linked to outstanding loan repayments? If active dependent records exist, the operation is blocked: AccountDeletionResult.BlockedByDependencies. The user is instructed to close or transfer their active holdings first.

Stage 2: The Double-Confirmation Guard

Account deletion is quarantined behind a multi-step confirmation dialog:

• The dialog explicitly lists the consequences: the exact number of transactions that will be purged and the total balance that will be eliminated.
• The user must explicitly confirm the action.

Stage 3: Counter-Party Recalculation

What happens to past transfers?
Suppose Account A transferred 10,000 rupees to Account B four months ago. If Account A is deleted, what happens to Account B?

• If you simply delete the transfer record, Account B's balance will become invalid upon the next historical ledger recalculation.
• FinLedger's deletion engine iterates through all past transfer records involving the deleted account, recalculates the running balances of all counter-party accounts atomically, and posts compensating ledger adjustments where required.

Stage 4: Resolving SQLite Foreign Key Constraints (Commit fd19ad0)

In early versions, deleting an account that had linked credit card statements or vault records could trigger an immediate SQLite FOREIGN KEY constraint failed exception.

• In commit fd19ad0, we audited the exact cascade deletion order inside AppDatabase.withTransaction:
  1. Unlink and delete child statement records.
  2. Prune linked receipt photo attachments from device disk.
  3. Delete child transaction entities.
  4. Finally, remove the parent account entity.

Preserving the Single Primary Account Invariant

FinLedger enforces a strict invariant: there must always be exactly one primary account.

When a user deletes an account that was currently marked as the primary account (isPrimary = true):

• The repository's atomic transaction automatically selects the next available liquid account (such as the default Cash Wallet) and elevates it to primary (clearPrimaryAccounts() followed by setPrimaryAccount()).
• The application is never left in an invalid state where zero primary accounts exist.

Key Takeaway

Deleting financial accounts requires comprehensive architectural defensive programming.

By prioritizing non-destructive archival, inspecting dependencies before execution, recomputing counter-party transfer balances, and respecting SQLite foreign key cascade order, FinLedger guarantees that even destructive actions never corrupt your ledger.

---

FinLedger is a privacy-first, offline-first personal finance application for Android that models bank accounts, credit cards, and cash without double-counting.

Explore FinLedger on Google Play: https://play.google.com/store/apps/details?id=com.devanshufinance.app