Educational product-design advice for Philippine money lenders and small MFIs — not legal counsel. Confirm disclosure wording with your compliance lead against your current BSP-facing practices before you change policy.
If a borrower only learns the full repayment schedule after cash leaves the desk, every later dispute starts from a weak position. An amortization preview before disburse is the product screen that shows principal, interest method, fees, and due dates in one place—and requires a clear acknowledge step—before the loan is booked. Fix that screen, and you cut schedule arguments before they become collections noise.
This guide is for Philippine money lenders and small MFIs who still close many loans at a branch or multi-branch desk. You will get a seven-field acceptance checklist, a structure-only worked example for a ₱15,000 weekly market float, who should build this now versus who can wait, the traps that fake a “preview,” and a ship order you can run in one sprint cycle. Soft note: a lending LMS such as PesoLend already supports loan products, interest methods, schedule generation, schedule view/print, and a disburse path with maker-checker — use those as the home for the preview, not a second spreadsheet.
What “amortization preview before disburse” actually means
It is not a PDF printed after the fact. It is a read-only summary the officer and borrower both see while the loan is still in draft. At minimum a solid loan schedule preview Philippines desks can trust should show:
- Loan product name and version (so you know which fee stack applies)
- Principal amount and term (number of installments and frequency)
- Interest method in plain words: flat, diminishing, or interest-only—plus the rate used
- Itemized fees that hit at disbursement vs fees that ride on installments
- First due date and the full installment table (or a clear “view all dues” expand)
- Total amount repayable if every installment is paid on time
If any of those fields can still change after the acknowledge click, you do not have a preview. You have a draft that keeps moving. That distinction matters when a borrower later says the installment table before cash out looked different from the SMS reminder they received in week three.
Think of the preview as the last shared truth before money moves. Disburse disclosure for PH lenders is not a marketing brochure — it is the moment both sides agree on the same pesos, dates, and method. Paper alone is fragile when officers re-key schedules in Excel. Screen alone is fragile when the receipt screen uses a different fee rule. The preview must be the same calculator collections will use.
Why field and desk teams skip it today
Most skips are not laziness. They are product friction:
- Preview is buried. Officers must open a second menu or regenerate a schedule after saving the draft loan.
- Numbers disagree. The schedule screen and the receipt screen use different fee rules, so officers stop trusting the preview and invent a side calculator.
- Round-trips feel slow. Branch close happens under queue pressure; if preview needs a long server wait every time, it gets skipped for “I’ll print later.”
- No borrower-facing copy. The screen shows LMS codes (“INT_DIM_2.5”) instead of words a market vendor understands.
- Print equals false consent. Some desks treat a printed schedule as done, then disburse while the officer still edits fees on another tab.
Fix the product path, and adherence rises without another memo. Training cannot outrun a screen that lies or hides.
Original element: 7-field amortization preview checklist
Use this as a product acceptance checklist before you call the feature “done.” Every row must be true on the same screen, same session, before disburse is enabled. This is design advice for your schedule + disburse path — not a claim that a branded “Amortization Preview Module” ships as a separate SKU.
| # | Field | Pass rule |
|---|---|---|
| 1 | Product + version | Matches the product selected on the draft loan; version ID visible to auditors |
| 2 | Principal & term | Editable only before acknowledge; locked after |
| 3 | Interest method | Human label + rate; matches how installments are computed |
| 4 | Fee stack | Each fee labeled “due at disburse” or “per installment”; sum matches totals |
| 5 | Installment grid | Due date, principal, interest, fees, installment total for every period |
| 6 | On-time total | Single number: sum of all installment totals if paid on schedule |
| 7 | Acknowledge | Officer + borrower confirmation timestamped; disburse button disabled until set |
If your LMS can print a schedule but cannot lock fields 1–6 after acknowledge, treat that as a gap—not a finished product. Store a frozen snapshot (JSON or PDF) on the loan file when acknowledge fires. Memory is not an audit trail, and a later product-version change must not rewrite yesterday’s preview.
Worked example structure: ₱15,000 weekly market float
Imagine a weekly market-float loan: ₱15,000 principal, 12 weekly installments, diminishing interest, a documentary fee due at disburse, and no per-installment service fee. Do not invent a rate or a total in training materials. Pull every peso figure from the live product calculator for that product version, then screenshot the preview for your ops playbook. The point of the example is the structure of the screen, not a published rate card.
The preview should make three things obvious before cash moves:
- Cash the borrower receives today — principal minus fees collected at disburse, if you net them; otherwise show gross principal and fees side by side
- Each week’s due amount and date — the installment table before cash out, not a single “average weekly” blur
- Total pesos if every week is paid on time — one on-time total, clearly labeled as excluding late penalties
Walk the officer script in plain Filipino or English the borrower uses at the market: product name, principal, how interest is computed in one sentence, fee that leaves today, first due date, and on-time total. Then ask the borrower to confirm they see the same numbers. Only after acknowledge should maker-checker release cash.
Desk habit that pairs with this example: after you upgrade a product’s fee stack, open one draft loan on the old version and one on the new version. If the preview cannot show which version is pinned, your versioning is theater. Related cash-to-ledger habits sit next to this screen — see collection receipt discipline so the first repayment does not reopen the same argument.
Who this is for — and who should skip
Build this now if: you disburse at a desk or in the field, you already fight “I didn’t know the total” complaints, officers re-key schedules in Excel because they do not trust the LMS, or multi-branch desks use slightly different fee explanations for the same product name.
Deprioritize if: every loan is already funded only after the borrower scrolls and accepts a schedule that is frozen to the same calculator collections uses — and your audit trail stores that acceptance with timestamps. Your next problem is probably repayment posting or complaint intake, not preview UX. For dispute trails after cash moves, use a field complaint log rather than bolting more text onto a weak preview.
Field-heavy money lenders should treat the preview as part of the close ritual, not an optional report. Multi-branch shops should pin product versions centrally so Branch A and Branch B cannot show different fee stacks under the same product nickname.
Common traps that fake a preview
- Preview uses yesterday’s fee table. Product versioning must pin fees to the version on the loan, not “whatever is active today.”
- Acknowledge with no snapshot. Store a frozen copy of the preview on the loan file. Without it, week-six disputes become he-said-she-said.
- Penalty text inside on-time total. Late fees belong in a separate disclosure block. Mixing them into “on-time total” confuses borrowers and officers.
- Auto-disburse after print. Printing is not consent. Keep disburse disabled until acknowledge is recorded, then run maker-checker.
- Schedule screen ≠ receipt screen. If documentary fees appear on one and vanish on the other, officers will abandon the preview.
- Codes instead of words. “DIM 2.5” is for configuration; the borrower-facing line should say diminishing interest in plain language.
- Editing after acknowledge. Any change to principal, term, method, or fees must clear acknowledge and force a new preview.
When preview friction collides with end-of-day rush, officers skip steps to protect float timing. Pair this work with clean desk close habits from end-of-day float reconciliation so “we were closing the till” is not an excuse to skip disclosure.
Decision framework: ship order
- Reconcile the calculator. Schedule, receipt, and collections must use one fee and interest engine for the same product version.
- Ship the 7-field preview on draft loans with lock-after-acknowledge and a frozen snapshot.
- Gate disburse. Maker-checker cannot release cash until acknowledge is set; no silent override for “VIP” loans without a logged exception.
- Borrower-facing labels. Replace internal codes on the preview; keep codes for auditors on a secondary line if needed.
- Train one script. “We read this screen together, then we release cash.” Fifteen seconds of shared reading beats a three-page memo.
- Measure for four weeks. Track complaint codes tied to “amount / schedule misunderstanding” and compare to your baseline. Do not invent industry benchmarks — use your own log.
If step 1 fails, stop. A beautiful preview that lies is worse than no preview. If step 1 passes but officers still print from Excel, your UX is buried — move the preview onto the critical path before disburse, not into a reports menu.
How this maps to a lending LMS (claim-safe)
Stay inside what a Day-20 lending LMS should already do well: define loan products and interest methods, generate a schedule, let staff view and print that schedule, and run disburse with maker-checker. The seven-field checklist is your acceptance test for that path. It is not a promise of an offline field app, AI scoring, native mobile rails, e-sign, a float module, a renewal engine, or a collections BI suite.
When you trial software, open a draft loan and ask: can I see product version, principal, method, fees, full grid, on-time total, and a hard acknowledge before disburse unlocks? If the answer is “we can export Excel,” keep shopping or keep building. Soft CTA: teams already on PesoLend can walk the schedule and disburse path in the app and mark which checklist rows pass today.
FAQs
Is an amortization preview the same as a Truth-in-Lending form?
Not automatically. A preview is a product control that aligns officer, borrower, and LMS on the same schedule before cash moves. Formal disclosure forms and BSP-facing wording belong with your compliance lead. Use the preview to make the numbers honest; do not treat the screen as a substitute for required documents.
Can we acknowledge on paper and disburse in the LMS?
You can, but then you must store the paper (or a scan) against the loan and ensure the paper numbers match the LMS schedule byte-for-byte. Most desks fail that match under volume. Prefer on-screen acknowledge that freezes the same record collections will use.
What if the borrower wants a lower installment after seeing the grid?
That is a product or underwriting change — new principal, term, or product version — not a quiet edit after acknowledge. Clear acknowledge, rebuild the draft, show the new preview, acknowledge again, then disburse.
Should penalties appear on the preview?
Show that late payment may incur penalties in a separate disclosure line. Do not fold estimated penalties into the on-time total. Borrowers deserve one clean number for “if I pay every due date.”
How do multi-branch desks stay consistent?
Pin product versions centrally. Branch nicknames for products are fine; branch-local fee stacks under the same name are not. The preview should display the version ID so a supervisor can spot drift in under a minute.
What to do next
Open one recent loan that drew a schedule complaint. Compare the signed paper (if any) to what the LMS shows today. If they differ, your next sprint is calculator consistency—not another collections script. When the numbers match, put the amortization preview on the critical path so disburse cannot fire without the seven fields and a timestamped acknowledge. Then train the one-line script and watch your schedule-misunderstanding complaint codes for four weeks.
Ready to walk the schedule and disburse path on a draft loan? Log in to PesoLend and run the seven-field checklist against a real product version — no second spreadsheet required.