<div dir="ltr"><p>Below is a <strong>formal, ready-to-submit bug report</strong> for <strong>KMyMoney</strong>.<br></p>
<h2>Bug Report: Reconciliation fails with bank-side card movements + CC payment + partial reimbursement</h2>
<p><strong>Product:</strong> KMyMoney<br>
<strong>Component:</strong> Reconciliation / Transaction Matching / Transfers<br>
<strong>Severity:</strong> Major (incorrect reconciliation result)<br>
<strong>Reproducibility:</strong> Always (with provided data)<br>
<strong>Account types involved:</strong> Bank + Credit Card (CCard)</p>
<hr>
<h3>Summary</h3>
<p>Reconciliation reports an incorrect balance difference when a bank account contains:</p>
<ol>
<li>
<p>A <strong>credit card payment (bank → credit card transfer)</strong></p>
</li>
<li>
<p>A <strong>bank-side card settlement movement</strong> (same card)</p>
</li>
<li>
<p>A <strong>partial reimbursement/refund</strong></p>
</li>
<li>
<p>A <strong>credit card charge recorded on the previous day</strong></p>
</li>
</ol>
<p>Even though all transactions are correct and balanced, KMyMoney reports a non-zero reconciliation difference.</p>
<p>Other finance applications reconcile the same data correctly.</p>
<hr>
<h3>Description</h3>
<p>KMyMoney fails to reconcile a bank account when the following conditions occur together:</p>
<ul>
<li>
<p>A credit card charge is recorded in a <strong>CCard account</strong> on day <em>N</em></p>
</li>
<li>
<p>A payment from a <strong>Bank account to that CCard account</strong> occurs on day <em>N+1</em></p>
</li>
<li>
<p>The Bank account also contains a <strong>bank-side card movement</strong> related to the same card</p>
</li>
<li>
<p>A <strong>partial reimbursement/refund</strong> occurs on the same day in the Bank account</p>
</li>
<li>
<p>Amounts are symmetrical (e.g. 36 / 18)</p>
</li>
</ul>
<p>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.</p>
<p>This leads to an incorrect reconciliation difference even though the ledger is balanced.</p>
<hr>
<h3>Steps to Reproduce (minimal, deterministic)</h3>
<h4>1. Create accounts</h4>
<ul>
<li>
<p>Bank account: <code>INTERBANK SOLES</code></p>
</li>
<li>
<p>Credit card account: <code>TARJETA OH PLAZA VEA</code> (type: CCard)</p>
</li>
</ul>
<hr>
<h4>2. Enter credit card charge (previous day)</h4>
<p><strong>Account:</strong> TARJETA OH PLAZA VEA<br>
<strong>Date:</strong> 2025-12-19</p>
<pre class="gmail-overflow-visible! gmail-px-0!"><div class="gmail-contain-inline-size gmail-rounded-2xl gmail-corner-superellipse/1.1 gmail-relative gmail-bg-token-sidebar-surface-primary"><div class="gmail-@w-xl/main:top-9 gmail-sticky gmail-top-[calc(--spacing(9)+var(--header-height))]"><div class="gmail-absolute end-0 gmail-bottom-0 gmail-flex gmail-h-9 gmail-items-center gmail-pe-2"><div class="gmail-bg-token-bg-elevated-secondary gmail-text-token-text-secondary gmail-flex gmail-items-center gmail-gap-4 gmail-rounded-sm gmail-px-2 gmail-font-sans gmail-text-xs"></div></div></div><div class="gmail-overflow-y-auto gmail-p-4" dir="ltr"><code class="gmail-whitespace-pre!"><span class="gmail-hljs-section">Payee: Inversiones Heng Xin Da</span>
<span class="gmail-hljs-section">Amount: -36</span>
<span class="gmail-hljs-section">Category: Dining Out</span>
</code></div></div></pre>
<hr>
<h4>3. Enter bank-side card movement</h4>
<p><strong>Account:</strong> INTERBANK SOLES<br>
<strong>Date:</strong> 2025-12-20</p>
<pre class="gmail-overflow-visible! gmail-px-0!"><div class="gmail-contain-inline-size gmail-rounded-2xl gmail-corner-superellipse/1.1 gmail-relative gmail-bg-token-sidebar-surface-primary"><div class="gmail-@w-xl/main:top-9 gmail-sticky gmail-top-[calc(--spacing(9)+var(--header-height))]"><div class="gmail-absolute end-0 gmail-bottom-0 gmail-flex gmail-h-9 gmail-items-center gmail-pe-2"><div class="gmail-bg-token-bg-elevated-secondary gmail-text-token-text-secondary gmail-flex gmail-items-center gmail-gap-4 gmail-rounded-sm gmail-px-2 gmail-font-sans gmail-text-xs"></div></div></div><div class="gmail-overflow-y-auto gmail-p-4" dir="ltr"><code class="gmail-whitespace-pre!"><span class="gmail-hljs-section">Payee: Tarjeta Oh. Op 176627534426854</span>
<span class="gmail-hljs-section">Amount: -18</span>
</code></div></div></pre>
<hr>
<h4>4. Enter partial reimbursement</h4>
<p><strong>Account:</strong> INTERBANK SOLES<br>
<strong>Date:</strong> 2025-12-20</p>
<pre class="gmail-overflow-visible! gmail-px-0!"><div class="gmail-contain-inline-size gmail-rounded-2xl gmail-corner-superellipse/1.1 gmail-relative gmail-bg-token-sidebar-surface-primary"><div class="gmail-@w-xl/main:top-9 gmail-sticky gmail-top-[calc(--spacing(9)+var(--header-height))]"><div class="gmail-absolute end-0 gmail-bottom-0 gmail-flex gmail-h-9 gmail-items-center gmail-pe-2"><div class="gmail-bg-token-bg-elevated-secondary gmail-text-token-text-secondary gmail-flex gmail-items-center gmail-gap-4 gmail-rounded-sm gmail-px-2 gmail-font-sans gmail-text-xs"></div></div></div><div class="gmail-overflow-y-auto gmail-p-4" dir="ltr"><code class="gmail-whitespace-pre!"><span class="gmail-hljs-section">Payee: Pago pollo a la brasa de Alejandro</span>
<span class="gmail-hljs-section">Amount: +18</span>
<span class="gmail-hljs-section">Category: Devolucion</span>
</code></div></div></pre>
<hr>
<h4>5. Enter credit card payment</h4>
<p><strong>Account:</strong> INTERBANK SOLES<br>
<strong>Date:</strong> 2025-12-20</p>
<pre class="gmail-overflow-visible! gmail-px-0!"><div class="gmail-contain-inline-size gmail-rounded-2xl gmail-corner-superellipse/1.1 gmail-relative gmail-bg-token-sidebar-surface-primary"><div class="gmail-@w-xl/main:top-9 gmail-sticky gmail-top-[calc(--spacing(9)+var(--header-height))]"><div class="gmail-absolute end-0 gmail-bottom-0 gmail-flex gmail-h-9 gmail-items-center gmail-pe-2"><div class="gmail-bg-token-bg-elevated-secondary gmail-text-token-text-secondary gmail-flex gmail-items-center gmail-gap-4 gmail-rounded-sm gmail-px-2 gmail-font-sans gmail-text-xs"></div></div></div><div class="gmail-overflow-y-auto gmail-p-4" dir="ltr"><code class="gmail-whitespace-pre!"><span class="gmail-hljs-symbol">Payee:</span> Op <span class="gmail-hljs-number">31380092</span>
<span class="gmail-hljs-symbol">Amount:</span> -<span class="gmail-hljs-number">36</span>
Transfer <span class="gmail-hljs-keyword">to</span>: TARJETA OH PLAZA VEA
</code></div></div></pre>
<hr>
<h4>6. Reconcile INTERBANK SOLES</h4>
<hr>
<h3>Expected Result</h3>
<ul>
<li>
<p>Reconciliation completes successfully</p>
</li>
<li>
<p>Reconciliation difference = <strong>0.00</strong></p>
</li>
<li>
<p>Ledger remains balanced</p>
</li>
</ul>
<hr>
<h3>Actual Result</h3>
<ul>
<li>
<p>Reconciliation reports a <strong>non-zero difference</strong> (e.g. –18.00)</p>
</li>
<li>
<p>User is forced to manually re-enter or reorder transactions</p>
</li>
<li>
<p>Manual re-entry of the same data resolves the issue</p>
</li>
</ul>
<hr>
<h3>Analysis / Suspected Cause</h3>
<ul>
<li>
<p>Automatic matching of +18 / –18 occurs <strong>before</strong> transfer consistency is validated</p>
</li>
<li>
<p>Transfer resolution is not re-run after matching</p>
</li>
<li>
<p>Bank-side card movements are treated ambiguously when a CCard payment exists</p>
</li>
<li>
<p>Reconciliation result depends on transaction creation order</p>
</li>
</ul>
<p>This appears to be a <strong>state-order dependency bug</strong> in reconciliation logic involving Bank ↔ CCard interactions.</p>
<hr>
<h3>Why this is a bug (not user error)</h3>
<ul>
<li>
<p>All transactions are valid and correctly modeled</p>
</li>
<li>
<p>Transfer is explicit and uses a real CCard account</p>
</li>
<li>
<p>Same modeling works correctly in many other cases</p>
</li>
<li>
<p>Failure only occurs with this specific but realistic combination</p>
</li>
<li>
<p>Manual re-entry (changing order only) fixes the issue</p>
</li>
</ul>
<hr>
<h3>Suggested Fix (high-level)</h3>
<p>One or more of the following:</p>
<ol>
<li>
<p>Re-evaluate transfer consistency <strong>after</strong> auto-matching</p>
</li>
<li>
<p>Delay matching when a linked CCard payment exists</p>
</li>
<li>
<p>Improve handling of bank-side card movements related to CCard accounts</p>
</li>
<li>
<p>Make reconciliation order-independent</p>
</li>
</ol>
<hr>
<h3>Workaround</h3>
<ul>
<li>
<p>Manually re-enter transactions in a different order</p>
</li>
<li>
<p>Or manually convert bank-side card movements into explicit transfers before reconciliation</p>
</li>
</ul>
<p>This is error-prone and should not be required.</p>
<hr>
<h3>Attachments</h3>
<ul>
<li>
<p>QIF extract available (can be provided on request)</p>
</li>
</ul>
<hr>
<p><strong>Thank you for your work on KMyMoney. This issue affects real-world credit card workflows and reconciliation reliability.</strong></p>
<hr>
<p><br></p></div>