These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Credit Scoring Engine
- Features
- Obligations and repayments
Obligations and repayments
Follow obligations, repayment receipts and principal allocations by case.
OverviewRepayments needing review×
Credit Scoring Engine · Obligations and repayments
New
Repayments needing review
Repayments
| Application | Operation key | Status | Received at | Failure reason | Effect references | |
|---|---|---|---|---|---|---|
| APP-72372 | OK-726 | Needs review | 04 Oct | Needs review rpy-478 | ER-903 | |
| APP-51380 | OK-725 | Needs review | 06 Oct | Needs review rpy-240 | ER-153 | |
| APP-49093 | OK-187 | Needs review | 10 Oct | Needs review rpy-268 | ER-608 | |
| APP-80743 | OK-602 | Needs review | 01 Oct | Needs review rpy-912 | ER-355 | |
| APP-86324 | OK-411 | Needs review | 09 Oct | Needs review rpy-599 | ER-942 |
6 of 6 records
OK-726Repayments · RPY-64128
Needs reviewApplicationAPP-72372
Received at04 Oct
Failure reasonNeeds review rpy-478
Effect referencesER-903
What you can do
Follow the obligation after decision
An approved case can have a linked obligation. The obligation record carries its own status, revision, submission and decision dates, organization and initial deposit amount. Operations Manager can follow that record alongside the application without confusing an obligation approval with the credit application decision. The two status histories answer different questions.
When a provider repayment arrives, Repayments keeps its operation key, application, expected revision, received date and outcome. A confirmed receipt may have an external reference and effect references. A receipt needing review carries a failure reason. Principal allocation records hold an amount and direction with links to an application and provider account record. The receipt and obligation must be compared through the case and evidence; the allocation has no direct link to either record.
How the work is organized
- Obligation. The obligation record holds its status and initial deposit amount under the parent application and organization.
- Receipt. Repayments holds the provider repayment event and verification state.
- Allocation. Principal allocations record direction and amount against the application and provider account record.
What to agree during setup
Agree which team records obligations and which events move their status from draft through submission and review. Decide how provider references are captured, how a repeated event is recognized through its operation key, and who resolves a receipt that needs review. Make the provider’s confirmation evidence available before treating an effect as complete. Do not equate a pending receipt with money applied to an obligation.
A practical example is a confirmed repayment against a case that also has an open obligation. Operations Manager records the receipt and compares its external reference with the provider event. The team checks the principal allocation’s amount and direction against its linked application and provider account, then compares the obligation and receipt separately. If the local effects do not match what the receipt claims, the item belongs in review until the discrepancy is explained.
Check the handoff on an actual case
Start from an authorized application with a linked obligation. Follow the obligation’s submission and decision state. Bring in a provider repayment reference, then inspect the receipt, expected revision and effect references. Compare the principal allocation with the case and account record. Repeat the same provider event and confirm that staff recognize the same operation instead of recording a second effect. Rehearse a mismatch and inspect the resulting review reason.
What your team sees
- Open obligations. See obligations still in draft, submitted or approved state.
- Pending repayments. Review receipts before their effects are verified.
- Repayments needing review. Find discrepancies with a recorded reason.
Follow the work through
See provider follow-up and reconciliation.
What it keeps track of
Data model- Obligations
- Credit obligations scheduled against an application.
- Repayments
- Confirmed repayment receipts with stable operation keys and actual effect references.
- Repayment allocations
- Principal allocations that apply a repayment against an obligation.
- Applications
- Credit applications moving through authorization, submission and confirmation.
- Score models
- Provider-held score models owned by an applicant.
- Assessment evidence
- Provider statements, confirmations, settlement notices and corrections for an application.
Who uses it
Permissions- Operations Manager
- Records and follows operational effects.
- Credit Reviewer
- Examines disputed or inconsistent evidence.
- Auditor
- Reads the obligation and repayment trail.
Set up Credit Scoring Engine your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.