Greetings,
Running: 5.1.80-a486847 Build 3606 on Windows
I have 3 loan accounts I’ve created Loan reports for under KMM/Reports/Transactions. These accounts are tied together through refinance, meaning at the end of the term of a loan, I transferred the balance to the next loan.
I have a Loan Transactions report combining all 3 accounts and for some reason, the balance transfer from the first account to the second account appears to be in reverse as per below (all 3 loan accounts showing from the report and I cut the ledger entries to save space):
The first loan account had a closing balance of 199,116.18 which when transferred to the new loan for refinance appears to show reversed in/out entries, leading to doubling the closing balance instead of zeroing it.
Any ideas what could be causing this? I looked up in the XML but could not find any obvious errors.
Thanks for your help!
P.S. I had more images showing the ledger entries which match the report, and report settings, however since I’m a first time poster there is a limitation and could not include them.
There does seems to be something odd about which columns the report uses for the numbers, and whether they are reported as positive or negative. All the routine loan payments show up as negative, and decrease the balance, but that last payment shows up as positive and increases the balance, although the final balance (2024-12-31) does show 0.00. (I found similar issues in my own loan transaction report, although I don’t have any “sequential” loans like yours. I’m going to need some time to dig into this, probably tracing through the logic of the reporting code.
Let me know if I can be of assistance as I’ve spent some time digging through the XML and trying different report parameters to track this down. I’ve also changed around some transactions however the result is always the same.
The assumption was a malformed XML or inconsistency in the Transactions but I’ve pretty much eliminated this possibility at this point.
Please run a regular transaction report, but limit the accounts to only those three loan accounts. If I’m right, they will look OK. I am beginning to suspect an issue in how the transaction loan report specifically assigns values within the transaction to the columns in the report, and whether it might be adjusting sign, possibly incorrectly, possibly depending on how many accounts and how many splits there are in the transaction. I’m hoping I can create a sample data file which demonstrates the problem - possibly with loan accounts which do not use schedules.
Here is what I did:
Using this:
I generated a report with the 3 accounts with the date range ‘all time’ and:
Result:
Which is exactly what we’re expecting vs. what we’re seeing with the loan Roport.
Can you try if updating to at least build 3644 solves the issue?
The issue I saw in one of my three loan accounts is gone with today’s build from git master. Hopefully it also works for tcpsorcerer’s.
Can confirm issue is resolved. Awesome work 
P.S. tested in build 3649
Greetings,
I previously missed this: the Interest column total is blank. Is that a bug or feature? Seems to be present on all builds I have, including 3649 from version 5 all the way back to 4.8.3 stable.
Image from 3649
Speaking of which, I just noticed that in 4.8.3 the Payment column is populated unlike in all the builds I have from v5
Image from 4.8.3 stable
Payment column is fixed with this commit.
Hello @ipwizard @ostroffjh and happy new year.
Looks like this is resolved, I have tested it on
However, the payment column seems to be missing amounts when etra payments are made on the loan:
Ex1:
Ex2:
Can you provide some details what should be read out of Ex1 and Ex2 and what is the hint for the missing information? Thank you.
My apologies, my brain goes too fast sometimes.
Maybe I’m mis-interpreting this, but in column 2 I’m expecting values for each entry, however as you can see for there are blanks. After reviewing some of these transactions, it appears that on the dates where the payment amounts are changed the report no longer shows values in column 2. Examples:
Bank was collecting $24 fees, but then they were reduced to $12 and the report no longer shows the amount in column 2 (Payment $291.51)
Here I can’t explain what happened, since from my pov nothing changed in the loan:
Hope this helps.
Few questions
- did you enter those transactions retro-actively or at the time they were due?
- Can you provide me with the transaction details for the ones at 2014-09-26 and 2014-10-03 as well as 2020-05-21 and 2020-05-28? The master version has the feature “Show transaction details” available in the ledger view in the transaction menu or the context menu of a transaction.
If the data for 2. contains too much personal data to be shown here or you don’t want to disclose it to the public please let us/me know and I will provide alternative ways to transport the information.
Anything before 2016 was retroactive, after that was a mix.
Here are the details of the requested transactions.
@tcpsorcerer Thanks for sharing. The problem seems to be that the newer transactions have two splits marked as Amortization. So we need to find two things:
- why and when does the false action get assigned
- fix existing transactions
Thanks @ipwizard, I manually edited the XML and fixed all the txs that had duplicate action=amortization. This addresses the issue of the historical data on the reports.
Example from xml:
I had quite a few.
Anyway, after fixing all these, I did some testing using the latest build I have:
(this is about a dozen builds old)
I had a master XML saved after the manual updates and did the following:
1-Entered the loan transaction schedule manually
2-Entered the loan transaction using an OFX import and letting the schedule match it.
In both cases after inspecting the xml, the splits have 2 action=Amortization
Manual:
OFX Import:
Of note for point 2 and not sure if related: when I do a manual schedule entry (i.e. 1 above), the schedule calculates the exact amount for splits between the principal and interest, but when I do an OFX import the schedule does not calculate the splits accurately, the principal split is always over the actual principal amount, and the interest split is under (total amount is correct) and I have to adjust them (the difference is around 0.15, varies are it is a variable rate loan).
Not sure if this is related to the double action=Amortization in the tx splits, we see here.
Hope this helps.
The assignment of the type action to both splits seems to be there for a long time, so I don’t want to touch that. The report generation has been fixed to deal with that. So if you take latest master you should see correct values even with both splits containing amortization as action.
Regarding the difference between manual entry and download matching I would like to know a few parameters of your loan:
- interest rate
- date of interest calculation (either due date or date of payment received )
- actual due date of the payment you included above
I have an idea what might causing the difference but want to be sure that it really is what I think before the source gets changed.
Downloaded latest master version:
Tested on historical Kmy archives and can confirm this is fixed.
As for the loan params:
- current rate is 4.35%
- interest calc is based on due date
- the above transaction actual due date was 14th of February 2025
If you need anything else please let me know.
