Moneylender Pro: payment history, curtailments & the Ledger Transactions register

Which Moneylender export to use, why a Ledger Transactions register can't rebuild a payment history, and how principal-only rows are treated when importing a seasoned loan.

Updated August 1, 2026

Moneylender Pro exports several different reports, and they are not interchangeable. Which one you have decides what NoteHarbor can rebuild.

Which export to use

  • A loan-list CSV — the whole book at once, through the ordinary column-mapping wizard (see Importing your loans).
  • A Payment History export — one loan's payments with the interest/principal split. This is the one that reconstructs a seasoned loan's real position.
  • A Ledger Transactions register — one loan's running ledger. It prints date, amount, balance and description, and never prints how each payment split between interest and principal.

The Ledger Transactions register

Upload one as a PDF through Import a statement PDF and NoteHarbor recognizes it, reads the header and transaction table, and creates the loan from its confirmed terms — but it will not invent a payment history out of it, and it says so. Record payments after the loan is created, or bring in a Payment History export.

It reports what it noticed rather than absorbing it quietly: lines it couldn't read, a running balance that doesn't chain, a report starting mid-life rather than at the first transaction, rows that are Moneylender's projection of future finance charges rather than payments that happened, multiple rate periods, multiple draws, and the case where the report prints two different balances.

Hand it the CSV version of the same register and NoteHarbor stops you at the door — "This is one loan's ledger transactions, not a list of loans" — and names the export to pull instead.

Curtailments in a seasoned import

Importing a Payment History for a loan that is behind raises one question above all others: does a principal-only payment catch the loan up?

No. A principal-only payment goes straight to principal, exactly as its name says, and does not advance the due date. If the balance was past due, the delinquency keeps running through it. A curtailment reduces what's owed; it does not buy a month.

The preview shows which rows were read that way and why — "All principal, no interest, on a note that does charge interest — the shape of a curtailment rather than an installment" — and totals how much went straight to principal without covering an installment.

Overriding a row

Every row has a Counts as control (repeated as Treat as on the flagged rows): Regular payment, Principal only, Before the note funded, or Escrow or fees only. Change one and the whole position recalculates on the spot; Import stays disabled for that moment, because the figures you approve must be the figures that get created.

Overrides that would contradict the record are refused out loud, not silently dropped — a row that actually applied interest cannot be recorded as principal-only, and NoteHarbor says exactly that.

Before it commits

The import re-checks itself at the last moment. If the loan's position moved while your preview was open — another payment falling due, for instance — nothing is imported and you're asked to preview again. Importing the same report twice is caught too.

Was this article helpful?

Still stuck? Ask our AI

Ask in plain English — we'll answer from the NoteHarbor help guides and point you to the right articles.

Moneylender Pro: payment history, curtailments & the Ledger Transactions register · NoteHarbor Help