https://bugs.kde.org/show_bug.cgi?id=523555
Bug ID: 523555
Summary: Editing a Newly Created Investment Cash Account
Triggers Transaction Date and Amount Rollback on
Multi-Split Entries with Duplicate Split Lines
Classification: Applications
Product: kmymoney
Version First 5.2.2
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: bugtracker
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Summary
When a user creates a new Investment cash account and references it in multiple
separate split lines within a single transaction (e.g., separate employee
contribution and employer match lines in a paycheck entry), editing the account
via Account > Edit Account causes KMyMoney's consistency validation engine to
fail.
The parser collapses duplicate split entries targeting the same newly indexed
account ID. As a result, the transaction fails the $0.00 balance check, the
primary checking split amount is overwritten by the value of the first
evaluated split line, and the transaction's postdate is forcibly reset to the
Opening Date of the newly created Investment cash account.
Environment
Application: kmymoney-5.2-5888-linux-gcc-x86_64.AppImage
OS: Fedora Workstation (GNOME)
Transaction Type: Multi-split paycheck deposit containing multiple splits
targeting a single destination account
Problem Description & Detailed Analysis
In standard double-entry bookkeeping, it is common to split a single paycheck
across multiple lines targeting the same destination account (e.g., allocating
a $1,200.00 employee contribution and a $300.00 employer match as two distinct
split lines targeting the same Investment cash account).
While existing/mature accounts with established transaction histories can
process duplicate split lines without issue, newly created accounts trigger an
indexing failure when the user edits the account details via Account > Edit
Account:
Key Collision on New Account ID: When a newly built account is referenced
multiple times in a single transaction's split table, KMyMoney's internal
lookup/consistency engine indexes the splits by Account ID rather than a unique
split row index.
Sum Evaluation Failure: During the account re-index (triggered by saving
changes in Account > Edit Account), KMyMoney reads only the first matching
split line (+$1,200.00) and ignores the second (+$300.00). Because the second
split is omitted during evaluation, the internal math no longer balances to
$0.00.
Safety Rollback & Date Fallback Override: To prevent corrupted entries from
persisting, KMyMoney triggers an internal rollback:
The primary checking account line is overwritten with the inverse of the first
evaluated split (e.g., forcibly set to -$1,200.00).
The transaction postdate is stripped and reverts to the Opening Date defined
for the newly created Investment cash account (e.g., 01/01/2026).
Running Tools > Consistency Check reports an unhandled non-zero split sum
error.
Steps to Reproduce
Create a brand-new account under Assets (e.g., Asset:Investments:401k
Investment Cash) with an Opening Date set to 01/01/2026.
Open a Checking account ledger and create a new balanced multi-split
transaction dated 04/15/2026:
Income:Salary : -$5,000.00
Expense:Taxes:Federal : +$1,000.00
Asset:Investments:401k Investment Cash (Line 1 - Employee) : +$1,200.00
Asset:Investments:401k Investment Cash (Line 2 - Match) : +$300.00
Asset:Banking:Checking (Net Deposit) : +$2,500.00
Confirm the Unassigned / Difference box reads $0.00 and save the transaction.
Select the newly created account (Asset:Investments:401k Investment Cash) in
the account list and go to Account > Edit Account.
Make any minor edit (or simply click OK to save the account settings).
Observed Result:
Opening the checking ledger reveals the transaction postdate has reverted from
04/15/2026 to 01/01/2026 (matching the Opening Date of the Investment cash
account).
The Checking split line has been altered from +$2,500.00 to -$1,200.00.
Consistency Check reports: Sum of splits in transaction 'T...' posted on
1/1/2026 is not zero.
Workaround
Combining the duplicate split lines into a single consolidated split line for
that account (Asset:Investments:401k Investment Cash = +$1,500.00) completely
resolves the issue. Editing the account via Account > Edit Account no longer
corrupts the transaction date or amounts.
Suggested Fix
Ensure that the split parser, XML serializer, and account re-indexing routines
(triggered during Account > Edit Account) reference splits using a unique Split
ID or array index rather than hashing solely on Account ID. This will allow
newly created accounts to correctly handle multiple distinct split lines within
the same transaction without defaulting the transaction date to the account's
Opening Date.
--
You are receiving this mail because:
You are watching all bug changes.
