Loan payment allocation is the rule that distributes a repayment across principal, interest, fees and other components of a loan. A servicing platform can support several allocation orders, called waterfalls, alongside settings for excess and early payments. Product teams need to verify the selected rule for each loan product and the result recorded for each payment.
Separate the payment method from the allocation rule
A payment method describes how money reaches the lender. Allocation describes what the servicing system does with that amount. In LoanPro’s payment defaults documentation, these are separate settings.
That distinction belongs in the product specification. “Accept a bank-account payment” describes a collection capability; it leaves unanswered how the amount changes the borrower’s balances. The team implementing collection and the team configuring servicing need a shared expected result.
The four examples on this guide’s cover are principal, interest, fees and escrow. They are components named in LoanPro’s documentation, not an exhaustive list or an order prescribed for every loan.
Review the actual waterfall
LoanPro’s installment-loan waterfall guide lists a Regular type that applies money to fees, interest and principal, as well as principal-only and other payment types. It also supports configured application orders.
Use the chosen vendor’s documentation to establish what its labels mean. A familiar word such as “regular” does not define a universal servicing rule. The approved product terms and servicing policy still need to determine the configuration.
For a hypothetical test account with $10 in due fees, $20 in due interest and $70 in due principal, a $50 payment under a fees-then-interest-then-principal rule would allocate $10, $20 and $20 respectively. This arithmetic example illustrates a specified order; it is not a recommendation for a lending product or a report of a live account.
Make defaults visible at the API boundary
LoanPro states that payment defaults also apply to API fields omitted from a payload. It describes defaults specific to the combination of loan class and loan type, with options that a servicer can change when logging a payment.
A useful integration review therefore compares the outgoing request with the account’s configuration. If the request omits an allocation setting, record which default supplies it. Otherwise a configuration change can alter the result of an apparently unchanged request.
| Test case | Suggested evidence |
|---|---|
| Repayment below the amount due | Expected allocation to each component |
| Repayment above the amount due | Selected excess-payment behavior |
| Payment before its due date | Applicable early-payment setting |
| Manual change by a servicer | Selected override and the resulting allocation |
| API request with omitted options | Defaults used for that loan product |
These are proposed acceptance tests. They do not imply that the same controls or field names exist in every servicing platform.
Check excess payments separately
LoanPro documents different excess-payment options depending on the loan’s interest-application setting. Its payment values reference distinguishes options that affect the next due date from principal-only treatment that does not.
Ask a vendor to demonstrate both the balance result and the schedule result for the selected configuration. A reduction in principal alone does not explain what a borrower should next pay or when. Keep those expected outputs together in the test record.
A returned payment also needs a defined servicing outcome. Track its collection status separately from the allocation already recorded, then establish how the product handles the subsequent reversal. Do not infer a settled collection from a successful request.
Preserve a reproducible explanation
For each allocation exception, retain enough information to reproduce the calculation: payment amount, effective date, component balances, selected payment type and any override. This is an implementation recommendation, not a claim that every vendor supplies an identical audit record.
When comparing loan servicing platforms, include these examples in the evaluation alongside loan servicing migration. A migration needs to preserve the information required to explain prior allocations as well as the opening total.
