Help → Report Bug (fills in system info automatically) docs.kde.org

[VIOLETA ESPINOZA]

Below is a *formal, ready-to-submit bug report* for *KMyMoney*.
Bug Report: Reconciliation fails with bank-side card movements + CC payment
+ partial reimbursement

*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.*
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20251221/ca7262a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20-12.qif
Type: text/qif
Size: 1234 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20251221/ca7262a1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19-12.qif
Type: text/qif
Size: 1249 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20251221/ca7262a1/attachment-0001.bin>