Remove interest calculation and posting logic from go-luca #4

New issue

Open

opened 2026-08-07 14:21:58 +00:00 by hum3 · 0 comments

hum3 commented

2026-08-07 14:21:58 +00:00

Owner

Summary

Interest calculation, posting, and application are product-dependent concerns that belong in the product layer (e.g. gobank-products), not in the ledger.

go-luca should provide per-account storage for accrued interest and live balance, but should not own any interest logic.

What to remove

CalculateDailyInterest — computes and posts interest
postInterest — records interest movements (Expense:Interest → account)
computeInterest / defaultInterest — calculation logic
RunDailyInterest — batch daily interest
RunInterestForPeriod — batch period interest
EnsureInterestAccounts — creates Expense:Interest / Income:Interest system accounts

What to keep / expose

Per-account InterestAccumulator field (get/set) — products use this for sub-unit fraction storage
GrossInterestRate field on Account — products read this for their own calculation
Live balance queries (Balance, BalanceAt, GetLiveBalance)
Movement recording (RecordMovement) — products post their own interest entries

Why

Different products need different interest models:

Commodity type for accrual (e.g. GBPFrac at extended precision vs GBP)
Posting direction and accounts (e.g. Liability:Savings:Alice:Accrual → Expense:Interest)
Application schedule (e.g. day 1 of month: sweep accrual → savings balance)
Calculation method (simple daily, compound, etc.)

These are all product decisions, not ledger decisions.

Migrated from Codeberg: originally #4, opened 2026-03-25.

## Summary Interest calculation, posting, and application are product-dependent concerns that belong in the product layer (e.g. gobank-products), not in the ledger. go-luca should provide **per-account storage** for accrued interest and live balance, but should not own any interest logic. ## What to remove - `CalculateDailyInterest` — computes and posts interest - `postInterest` — records interest movements (Expense:Interest → account) - `computeInterest` / `defaultInterest` — calculation logic - `RunDailyInterest` — batch daily interest - `RunInterestForPeriod` — batch period interest - `EnsureInterestAccounts` — creates Expense:Interest / Income:Interest system accounts ## What to keep / expose - Per-account `InterestAccumulator` field (get/set) — products use this for sub-unit fraction storage - `GrossInterestRate` field on Account — products read this for their own calculation - Live balance queries (`Balance`, `BalanceAt`, `GetLiveBalance`) - Movement recording (`RecordMovement`) — products post their own interest entries ## Why Different products need different interest models: - Commodity type for accrual (e.g. GBPFrac at extended precision vs GBP) - Posting direction and accounts (e.g. `Liability:Savings:Alice:Accrual → Expense:Interest`) - Application schedule (e.g. day 1 of month: sweep accrual → savings balance) - Calculation method (simple daily, compound, etc.) These are all product decisions, not ledger decisions. --- *Migrated from Codeberg: originally [#4](https://codeberg.org/hum3/go-luca/issues/4), opened 2026-03-25.*

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

hum3/go-luca#4

No description provided.

Rows
Columns