Ledger Entry Accounting Model#

Sure uses a dual-entry accounting system built on three core models: Entry, Transaction, and Transfer. Every monetary event — income, expense, or movement between accounts — is stored as one or more Entry rows, each carrying a signed amount that encodes direction.

Amount Sign Convention#

The Entry#classification method encodes the rule directly 1:

• Negative amount → "income" (inflow / credit)
• Positive amount → "expense" (outflow / debit)

This convention is enforced at the controller layer: TransactionsController#entry_params converts the unsigned form value to a signed amount based on the hidden nature field — "inflow" maps to negative, "outflow" to positive 2.

Entry Structure#

Entry belongs to an account and delegates its domain type to one of three entryable types via Rails delegated_type:

Each Entry holds amount, currency, date, name, and optional transfer (via belongs_to :transfer) and parent_entry (for splits) associations 3.

How Transfers Pair Two Entries#

A Transfer is a join record linking exactly two Transaction rows: an outflow (positive amount) on the source account and an inflow (negative amount) on the destination account 4.

Transfer
 ├── outflow_transaction → Entry (amount > 0) on source account
 └── inflow_transaction → Entry (amount < 0) on destination account

The model enforces balance via transfer_has_opposite_amounts: the inflow must be negative, the outflow positive, and for same-currency transfers they must sum to zero 5.

Additional constraints :

• Accounts must be different and belong to the same family
• Entry dates must be within 4 days (pending) or 30 days (confirmed) of each other

Creating a Transfer: Transfer::Creator#

Transfer::Creator is the sole factory for new transfers. It accepts family, source_account_id, destination_account_id, date, amount, and optional exchange_rate, source_fee_amount, and destination_fee_amount.

Calling #create inside a single DB transaction:

1. Builds the outflow transaction with amount (positive) on the source account 7
2. Builds the inflow transaction with net_inflow * -1 (negative) on the destination account, currency-converting if needed 8
3. Appends optional standard-kind fee transactions to either side 9
4. Saves the Transfer, then calls sync_later on both accounts 10

Outflow kind Assignment#

The outflow transaction's kind controls how the transfer leg flows through budget and income-statement analytics. Transfer::Creator#outflow_transaction_kind picks the kind based on the destination account type:

The inflow transaction always receives kind: "funds_movement" regardless of account type 11.

When kind == "investment_contribution", the outflow is also auto-assigned the family's Investment Contributions category 12.

The class-level Transfer.kind_for_account mirrors this routing for display and matching use cases, but only accepts a single account — it lacks the !source_is_investment? guard present in Creator, which causes a known misclassification bug for investment-to-investment transfers 13.

Budget & Reporting Exclusion#

Two constants on Transaction determine analytics inclusion 14:

• TRANSFER_KINDS = [funds_movement, cc_payment, loan_payment, investment_contribution] — identifies all transfer legs for search filter splits.
• BUDGET_EXCLUDED_KINDS = [funds_movement, one_time, cc_payment] — dropped from budget/income-statement queries.

loan_payment and investment_contribution are intentionally absent from BUDGET_EXCLUDED_KINDS — they represent real cash outflow and appear as expenses in Reports.

Destroying a Transfer#

Transfer#destroy! resets both linked transactions' kind back to "standard" before destroying the join record, preventing orphaned transactions from retaining transfer-specific kinds. reject! additionally creates a RejectedTransfer record to suppress re-detection of the same pair.

Key Files#