Hello, On Sonntag, 21. Dezember 2025 14:46:13 CET VIOLETA ESPINOZA via KMyMoney-devel wrote:
> Below is a *formal, ready-to-submit bug report* for *KMyMoney*. > Bug Report: Reconciliation fails with bank-side card movements + CC payment > + partial reimbursement Unfortunately, this report is NOT *a formal, ready-to-submit bug report*. (It appears to be written by AI.) Reconciliation is for a single account, and multiple accounts are listed. You do not state whether each transaction is marked as Cleared or left unmarked. You do not state the expected ending reconciliation balance. Can you produce a sample .kmy file with only the accounts and transactions needed to demonstrate the problem? Thank you in advance. Thomas > > *Product:* KMyMoney > *Component:* Reconciliation / Transaction Matching / Transfers > *Severity:* Major (incorrect reconciliation result) > *Reproducibility:* Always (with provided data) > *Account types involved:* Bank + Credit Card (CCard) > ------------------------------ > Summary > > Reconciliation reports an incorrect balance difference when a bank account > contains: > > 1. > > A *credit card payment (bank → credit card transfer)* > 2. > > A *bank-side card settlement movement* (same card) > 3. > > A *partial reimbursement/refund* > 4. > > A *credit card charge recorded on the previous day* > > Even though all transactions are correct and balanced, KMyMoney reports a > non-zero reconciliation difference. > > Other finance applications reconcile the same data correctly. > ------------------------------ > Description > > KMyMoney fails to reconcile a bank account when the following conditions > occur together: > > - > > A credit card charge is recorded in a *CCard account* on day *N* > - > > A payment from a *Bank account to that CCard account* occurs on day *N+1* > - > > The Bank account also contains a *bank-side card movement* related to > the same card > - > > A *partial reimbursement/refund* occurs on the same day in the Bank > account > - > > Amounts are symmetrical (e.g. 36 / 18) > > The reconciliation engine appears to apply matching in an order-dependent > way and does not re-evaluate transfer consistency after automatic matching > of opposite-signed transactions. > > This leads to an incorrect reconciliation difference even though the ledger > is balanced. > ------------------------------ > Steps to Reproduce (minimal, deterministic) 1. Create accounts > > - > > Bank account: INTERBANK SOLES > - > > Credit card account: TARJETA OH PLAZA VEA (type: CCard) > > ------------------------------ > 2. Enter credit card charge (previous day) > > *Account:* TARJETA OH PLAZA VEA > *Date:* 2025-12-19 > > Payee: Inversiones Heng Xin DaAmount: -36Category: Dining Out > > ------------------------------ > 3. Enter bank-side card movement > > *Account:* INTERBANK SOLES > *Date:* 2025-12-20 > > Payee: Tarjeta Oh. Op 176627534426854Amount: -18 > > ------------------------------ > 4. Enter partial reimbursement > > *Account:* INTERBANK SOLES > *Date:* 2025-12-20 > > Payee: Pago pollo a la brasa de AlejandroAmount: +18Category: Devolucion > > ------------------------------ > 5. Enter credit card payment > > *Account:* INTERBANK SOLES > *Date:* 2025-12-20 > > Payee: Op 31380092Amount: -36 > Transfer to: TARJETA OH PLAZA VEA > > ------------------------------ > 6. Reconcile INTERBANK SOLES > ------------------------------ > Expected Result > > - > > Reconciliation completes successfully > - > > Reconciliation difference = *0.00* > - > > Ledger remains balanced > > ------------------------------ > Actual Result > > - > > Reconciliation reports a *non-zero difference* (e.g. –18.00) > - > > User is forced to manually re-enter or reorder transactions > - > > Manual re-entry of the same data resolves the issue > > ------------------------------ > Analysis / Suspected Cause > > - > > Automatic matching of +18 / –18 occurs *before* transfer consistency is > validated > - > > Transfer resolution is not re-run after matching > - > > Bank-side card movements are treated ambiguously when a CCard payment > exists > - > > Reconciliation result depends on transaction creation order > > This appears to be a *state-order dependency bug* in reconciliation logic > involving Bank ↔ CCard interactions. > ------------------------------ > Why this is a bug (not user error) > > - > > All transactions are valid and correctly modeled > - > > Transfer is explicit and uses a real CCard account > - > > Same modeling works correctly in many other cases > - > > Failure only occurs with this specific but realistic combination > - > > Manual re-entry (changing order only) fixes the issue > > ------------------------------ > Suggested Fix (high-level) > > One or more of the following: > > 1. > > Re-evaluate transfer consistency *after* auto-matching > 2. > > Delay matching when a linked CCard payment exists > 3. > > Improve handling of bank-side card movements related to CCard accounts > 4. > > Make reconciliation order-independent > > ------------------------------ > Workaround > > - > > Manually re-enter transactions in a different order > - > > Or manually convert bank-side card movements into explicit transfers > before reconciliation > > This is error-prone and should not be required. > ------------------------------ > Attachments > > - > > QIF extract available (can be provided on request) > > ------------------------------ > > *Thank you for your work on KMyMoney. This issue affects real-world credit > card workflows and reconciliation reliability.* > ------------------------------ > -- Regards Thomas Baumgart ------------------------------------------------------------- Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert Heinlein -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
