One operating system for a lending institution — origination, KYC, the loan book, collections, the general ledger, payroll and the regulatory returns all reading from the same record of clients, loans and money.
60 modules across 10 capability areas. Every module below is a direct link — paste one to point a colleague at the exact answer.
Who gets in, what they can touch, and how the institution is shaped inside the platform. Every other module in this guide is filtered through what is configured here.
01
Accounts & Sign-in
Authentication, password lifecycle, and personal account settings for every staff user.
Where
Where: Login page, then Profile
Access
Access: Every user
Email-and-password sign-in against the user’s organization, with the session held server-side.
Self-service password reset: request a reset link by email, then set a new password from the link.
Invited users receive a temporary password and are forced through a change-password screen on first sign-in.
Password-changed and account-enabled/disabled confirmations are sent automatically and cannot be switched off.
Profile screen updates name, phone and profile photo; email and security settings live alongside it.
Interface language per user — English or Kinyarwanda — saved to the account and applied everywhere.
Installable as a progressive web app, with an update watcher that prompts staff when a new build has shipped.
02
Roles & Permissions
Fine-grained, permission-code-based access control layered over a small set of fixed platform roles.
Where
Where: Users → a user → Permissions
Access
Access: Managing Director, or a user holding MANAGE_USERS
Four fixed platform roles: Super Admin (platform operator), Managing Director (full organization access), BNR Agent (read-only regulator view) and Platform Support (works inside a chosen organization at MD level).
Organizations define their own operational roles on top — Branch Manager, Loan Officer, Finance, HR, Accountant, Board Member and any others they need.
Access is granted by permission code, not by role name: VIEW_CLIENTS, CREATE_LOAN, APPROVE_LOAN, DISBURSE_LOAN, CONFIRM_DISBURSEMENT, RECORD_REPAYMENT, VERIFY_KYC, APPROVE_KYC, VIEW_ACCOUNTING, MANAGE_ACCOUNTING, RUN_PAYROLL, VIEW_AUDIT_LOGS, EXPORT_CRB, RECONCILIATION and the rest of the catalogue.
Per-user overrides sit above the role: an individual permission can be explicitly allowed or explicitly denied for one person without changing the role everyone else shares.
Branch scoping is enforced on top of permissions — a branch-scoped user sees and acts on their own branch only, while Managing Directors work across every branch.
The sidebar itself is filtered by the same rules, so staff never see a menu entry for a screen they cannot open.
Permissions, role, branch and the organization’s feature flags are all checked together. A screen appears only when the role or permission allows it, the branch scope permits it, and the feature is switched on for that organization.
03
Organizations
Platform-level tenancy: onboarding an institution, its lifecycle status, and the features it has bought.
Where
Where: Platform → Organizations
Access
Access: Super Admin only
Onboard a new institution and issue the Managing Director’s credentials in the same step.
Organization status drives access: ACTIVE works normally; SUSPENDED and CLOSED lock the organization out with an explanatory message rather than a silent failure.
Feature flags per organization — CRB reporting, email notifications, loan scoring, AI assistant, reconciliation and multi-branch — turn whole modules on and off per contract.
Branch ceiling per organization, so a single-branch contract cannot quietly grow into a network.
Invite a BNR Agent to an organization for read-only supervisory access.
Platform statistics across every tenant: organizations, users, branches and portfolio totals.
Client-and-loan data wipe is request-and-approve, never a single click: one administrator raises the request with a reason, a second approves it.
04
Branches
The branch network — the unit that scopes almost every operational figure in the system.
Where
Where: Management → Branches
Access
Access: Managing Director, or CREATE_BRANCH / UPDATE_BRANCH
Create branches with name, location and status (ACTIVE or INACTIVE).
A head-office branch anchors organization-level aggregation.
Clients, loans, payments, reconciliations and reports are all branch-tagged, which is what makes branch comparison and branch-level risk reporting possible.
Branch managers are confined to their own branch across every module; the Managing Director sees the consolidated position and can filter down to any branch.
05
User Management
Creating staff accounts, assigning them a role and a branch, and retiring them without breaking the audit trail.
Where
Where: Management → Users
Access
Access: Managing Director, or MANAGE_USERS
Invite a user with a role and a branch; the system issues a temporary password and emails the welcome credentials.
Edit a user’s name, role, branch and contact details as they move around the institution.
Enable or disable an account — a disabled user cannot sign in but every record they touched stays attributed to them.
Permanent deletion is available but deliberately guarded behind an explicit typed confirmation.
Per-user permission overrides are edited from the same screen.
Super Admins can also invite a user directly into a specific organization when standing up a new tenant.
Area 02
Clients & KYC
The borrower master file and the due-diligence trail behind it. Nothing can be lent until a client exists here and their KYC has been through review.
01
Client Directory
The register of every borrower the institution deals with, and the entry point to their whole history.
Where
Where: Operations → Clients
Access
Access: VIEW_CLIENTS, CREATE_CLIENT, or any KYC permission — branch-scoped
Register a client with full name, sex, date of birth, national ID, phone, email and address down to sector, cell and village, plus business details.
Search by name, national ID or phone, and filter by KYC status, client status and branch.
Client status is separate from KYC status: ACTIVE, INACTIVE or BLACKLISTED.
KYC status shows as Incomplete, Pending, Complete or Rejected on every row, so the pipeline is visible without opening records.
The client profile carries personal details, KYC documents, the full loan history, repayment track record and officer notes.
An Insights tab summarises the client base — composition and concentration — rather than making staff export to find it.
Birthdays captured here drive the automated birthday greeting, when that email is enabled.
02
KYC Submissions
The documented due-diligence package that a loan application is attached to.
Where
Where: Clients → a client → KYC
Access
Access: SUBMIT_KYC / VERIFY_KYC
A submission requires a payment slip plus exactly one of each mandatory document type: loan application form, guarantor ID copy, marital status certificate, bank statement, valuation report, CRB report and national ID.
Additional document types are supported for records that need them — ID card, passport, collateral notary agreement and collateral valuation report.
Submission statuses run DRAFT → PENDING → UNDER_REVIEW → APPROVED or REJECTED, with EXPIRED for packages that have aged out.
Rejected submissions can be corrected and resubmitted without starting a new client record.
Collateral is captured on the submission, so every loan referencing it surfaces its security automatically.
Documents are stored in private object storage and streamed only to users authorised against the owning organization.
03
KYC Review Queue
The reviewer’s worklist — everything waiting for a verification decision, in one place.
Where
Where: Operations → KYC Review
Access
Access: VIEW_KYC, VERIFY_KYC, APPROVE_KYC or SUBMIT_KYC
Pending submissions queue up for review; a reviewer moves one to under-review to claim it.
Approve or reject with a recorded reason, and the client’s KYC status follows the decision.
Submitters see their own queue and its outcomes; approvers see the decision queue.
Branch managers review their own branch’s submissions; Managing Directors review across every branch.
Submitted, approved, rejected and resubmitted events each raise a staff email notification when enabled.
04
KYC Requirements
Organization-defined due-diligence items on top of the standard document set.
Where
Where: Settings → KYC Requirements
Access
Access: Managing Director
Define your own requirements — an attachment, a text field, a number, a date or a yes/no answer.
Mark a requirement active or inactive, and required or optional; active required items are enforced at submission.
Captured values are stored against the submission and travel with it through review.
05
Collateral Register
Structured security pledged against lending, valued and evidenced.
Where
Where: Loans → Collateral Register
Access
Access: VIEW_LOANS
Six collateral types: business asset, house, land, vehicle, guarantor and other.
Type-specific fields are captured where they matter — TIN for a business asset, UPI for land, brand and yellow-paper ID for a vehicle, national ID for a guarantor.
Both market value and forced-sale value are recorded, which is what makes coverage meaningful rather than notional.
Each item carries its own supporting document — title, valuation report or guarantor ID.
The register is queryable across the portfolio and per loan.
Guarantors are modelled as a collateral type rather than as a separate register, so guarantor exposure is visible in the same place as every other form of security.
Area 03
Loan Origination
From application to money leaving the account. Every step is permissioned, evidenced, and blocked until its preconditions are genuinely met.
01
Loan Applications
The request, its appraisal, and the approve-or-decline decision.
Statuses run DRAFT → SUBMITTED → UNDER_REVIEW → APPROVED or REJECTED, with CANCELLED, SCORED and DISBURSED for the states that follow.
Save a draft and come back to it, or use the combined flow that registers the client, captures KYC and raises the application in one pass.
Threaded comments on the application let officers and reviewers discuss it in the record instead of over the phone.
Approval creates the loan automatically and carries the agreed terms onto it.
Rejection records the reason and closes the request without deleting the history.
Staff alerts fire on new applications and on stage changes when those emails are enabled.
02
Loan Terms & Repayment Models
How each loan is shaped — the configuration that drives the schedule, the interest and the allocation.
Where
Where: Set on the loan application, copied onto the loan at approval
INTEREST_FIRST_MONTHLY — interest-only for every installment but the last, which carries the whole principal plus that period’s interest.
EQUAL_INSTALLMENT — principal plus total flat interest spread evenly, with principal and interest kept explicit for allocation and reporting.
REDUCING_BALANCE — a fixed annuity instalment, interest computed on the outstanding principal each period and therefore front-loaded.
REDUCING_EQUAL_SPLIT — the annuity total, but with principal and interest each split evenly so recognition is level; rounding residue lands on the final instalment so totals reconcile exactly.
BULLET — no intermediate payments at all: one instalment at maturity for principal plus the whole term’s flat interest.
Interest model is FLAT or REDUCING; the rate is monthly and is accepted either as a percentage or as a decimal.
Term is a value plus a unit — days, weeks or months — and repayment frequency is daily, weekly, biweekly or monthly. Sub-monthly frequencies split the term into proportionally more instalments and scale per-instalment interest down to match.
Payment allocation priority is set per loan: PENALTY_FIRST or INTEREST_FIRST.
Penalty behaviour is set per loan: standard, days-percent, compounding, or weekly-compound.
An optional management fee is chosen at application time, either as a fixed amount or as a percentage.
There is no loan-product catalogue. Every loan carries its own configuration, chosen on the application and copied onto the loan at approval — which is why two loans of the same size can legitimately behave differently.
03
Approval & Committee Governance
Single-signatory approval, or a full board vote for loans above a threshold.
Where
Where: Loans → Committee Approvals; configured in Settings
Access
Access: APPROVE_LOAN; committee voting for Board Members and the Managing Director
Standard mode: an approver with APPROVE_LOAN approves, and the loan moves straight to pending disbursement.
Committee mode: the approved loan is held under review until every board member has voted.
A committee threshold can be set so only loans above a certain amount need the board, while smaller ones stay on the fast path.
Each member votes APPROVE or REJECT with an optional comment, and can change their vote until the loan is decided.
A separate threaded committee discussion runs alongside the votes, visible to everyone on the loan.
Force-approve exists for the Managing Director as a documented override, recorded like any other action.
04
Contract & Key Fact Statement
The paperwork the borrower signs, generated from the loan rather than retyped.
Where
Where: Loans → a loan → Contract Draft / KFS
Access
Access: DISBURSE_LOAN or RECORD_REPAYMENT
A contract draft is prepared at approval with editable contract fields, so wording can be adjusted without touching loan terms.
The Key Fact Statement is generated from the loan’s own figures — principal, rate, term, fees and total payable.
Both the signed KFS and the signed contract are uploaded back onto the loan as evidence.
Uploads accept JPEG, PNG or PDF only.
Contract and loan-status PDFs can be exported from the loan at any time.
05
Disbursement
Releasing the money — a deliberate two-step flow with finance as the second pair of eyes.
Where
Where: Loans → a loan → Disburse
Access
Access: DISBURSE_LOAN, then CONFIRM_DISBURSEMENT for the finance step
The loan must be in PENDING_DISBURSEMENT, and both the signed KFS and the signed contract must already be uploaded — without them the system refuses.
The user must be in the loan’s own branch.
Step one moves PENDING_DISBURSEMENT → DISBURSED. The loan is not yet active.
The system sets the start date and derives the maturity date from the term — neither is chosen by hand.
The repayment schedule is generated automatically from the repayment model, rate, term and frequency.
A CRB record is opened for the borrower at this point.
Step two is finance confirmation, which moves DISBURSED → ACTIVE and posts the disbursement to the general ledger.
The borrower is emailed their schedule where an email address is on file, and staff are notified that a loan is awaiting finance confirmation.
Disbursing does not make a loan active. Finance confirmation does — and that is the moment the ledger is touched.
06
Loan Calculator
Quote a loan before anything is committed.
Where
Where: Loans → Loan Calculator
Enter principal, rate, term, frequency and repayment model to see the resulting schedule and totals.
Uses the same calculation engine as live loans, so a quote and the eventual schedule agree.
Useful at the counter for comparing repayment models against a borrower’s cash flow.
Area 04
Loan Servicing & Portfolio
Everything that happens to a loan after the money has gone out — the schedule, the changes borrowers ask for, and the views that keep the book legible.
01
Loans Workspace
One screen holding the whole book and the tools that act on it.
Where
Where: Operations → Loans
Access
Access: VIEW_LOANS and related loan permissions
All Loans — the full portfolio with status, principal, balance, branch and officer, filterable and sortable.
Applications — the origination pipeline alongside the book it feeds.
Restructured Loans — every loan in a restructure chain, with its lineage visible.
Due Soon — instalments approaching their due date, for proactive collection.
Committee Approvals — the board’s voting queue.
Comments & Notes — discussion across loans in one stream.
Collateral Register and Loan Calculator sit in the same workspace as tools.
Exports to Excel and PDF from the list, and a per-loan account statement PDF.
02
Loan Statuses & Lifecycle
The states a loan moves through, and what each one actually means.
DRAFT, SUBMITTED and UNDER_REVIEW cover the request before a decision.
APPROVED and DENIED record the decision; PENDING_DISBURSEMENT means approved and awaiting signed documents.
DISBURSED means the money has been released but finance has not yet confirmed it.
ACTIVE is a confirmed loan in repayment; DELAYED is the overdue state.
PAID means fully repaid, CLOSED means completed and closed, CANCELLED means stopped before completion.
DEFAULTED marks a loan classified as non-performing.
A lifecycle stepper on the loan shows where it sits and what comes next.
Delinquency is tracked as a separate dimension, so an ACTIVE loan and its arrears position are never confused.
03
Repayment Schedules
The instalment plan the whole loan is measured against.
Generated automatically at disbursement from the loan’s own configuration.
Each item is typed as principal or interest and carries its own status: pending, partial, paid, overdue or cancelled.
An individual schedule item can be adjusted where circumstances justify it, under permission.
Schedules export to Excel, either for a single loan or across a date range.
The schedule is emailed to the borrower at disbursement where an address is on file.
04
Servicing Actions
The changes a live loan legitimately needs — and how each one is recorded.
Where
Where: Loans → a loan
Access
Access: EDIT_LOAN, REVIEW_LOAN and Managing Director actions
Extension pushes maturity out; the loan records how many times it has been extended and when.
Top-up adds money onto a running loan and tracks the cumulative total.
Restructure reschedules the loan and records the restructure count and date.
Capitalization restructure closes the original loan and opens a new one carrying the capitalized balance, linked back to its predecessor — so a closed loan in a chain is visibly not a loss.
Contract-interest mode is a per-loan toggle: on, the borrower owes the full contract from day one and prepayment never cancels future interest; off, interest accrues as time passes and prepayment reduces it.
Delay interest can be switched on per loan, with a daily accrual job for the loans that opt in.
Processing fee and management fee can be adjusted on the loan under permission.
Loans brought in from a legacy system are marked as migrated, and restructure successors as restructured, so origin is never guessed.
Contract-interest mode materially changes what a borrower owes. Always confirm which mode a loan is in before quoting a settlement figure.
05
Add Existing Loan
Bringing a single backdated loan with history onto the platform.
Access
Access: CREATE_EXISTING_LOAN
Records a loan that was originated elsewhere, with its real disbursement date and repayment history.
The schedule is regenerated from the terms so the loan behaves like any other from that point on.
Marked with a migrated origin so reporting can tell originated from inherited business.
For a whole portfolio rather than one loan, use the Data Importer instead.
Area 05
Payments & Collections
Money coming back in, what it settles, and what happens when it does not arrive. This is where the loan book meets the cash position.
01
Payments
Recording, receipting and correcting every repayment.
Record a repayment against a loan with amount, date, channel and reference.
Channels cover cash, bank, bank transfer, mobile money, cheque, card and other.
Proof of payment can be uploaded and attached to the transaction.
A payment moves through finance confirmation before it counts as received.
Today’s collection summary is available at a glance, and the full ledger exports over any date range.
Every payment keeps a revision history, and a superseded version can be restored.
Payments can be edited or deleted under permission, with critical actions raising a staff alert.
The borrower gets a payment receipt email, and a thank-you when an instalment settles or the loan is paid in full.
02
Payment Allocation
How a payment is split across what the borrower owes.
Allocation order is penalty, then fees, then interest, then principal.
Within that order, the oldest outstanding instalments are settled first.
A loan set to INTEREST_FIRST reverses the penalty/interest precedence for that loan only.
Overpayment beyond current dues is applied to principal as prepayment.
Money beyond the entire outstanding balance is held on the payment as an overpayment credit rather than silently absorbed.
Each allocation is stored line by line, so any payment can be traced to exactly what it settled.
03
Penalties
Charging for late payment, and adjusting the charge where it is justified.
Access
Access: ADJUST_PENALTY for waivers and corrections
Four penalty behaviours: standard, days-percent, compounding and weekly-compound.
Weekly-compound charges at each completed fourteen-day period after grace — partial periods are never charged. Loans originated before that policy keep their original seven-day period for life, so an old and a new loan can legitimately show different penalty curves.
Penalties carry their own status — pending or paid — and are settled ahead of everything else by default.
A Managing Director can adjust or waive a penalty manually, and the action is recorded.
Clearing a penalty, or the borrower paying it off, resets the penalty clock; days past due and re-accrual are measured from that reset plus grace, not from the original due date.
Penalty-applied and penalty-adjusted emails keep the borrower informed when those notifications are enabled.
04
Loan Recovery & Delinquency
Continuous arrears classification against the BNR provisioning ladder, used as a collections worklist.
Where
Where: Operations → Loan Recovery
Access
Access: VIEW_DELINQUENCY, VIEW_LOANS, REVIEW_LOAN or RECORD_REPAYMENT
Six buckets, derived from days past due and mapped to the regulator’s classes and provision rates:
Normal — 0 days in arrears, 0% provision.
Watch — 1 to 89 days, 1% provision.
Substandard — 90 to 179 days, 20% provision.
Doubtful — 180 to 359 days, 50% provision.
Loss — 360 to 719 days, 100% provision.
Write-off — 720 days and beyond, 100% provision.
Each bucket opens as a queue of the loans inside it, so collections work top-down by severity.
A portfolio-at-risk summary sits above the queues, and the same classification feeds the dashboard, the provisions posting and the BNR return.
Classification is recalculated continuously, including immediately after a bulk import, rather than only at month end.
The six platform buckets roll up to the five classes of the BNR workbook — its single Loss class covers both Loss and Write-off here. Since both carry 100%, the provision totals agree either way.
05
Automated Reminders & Greetings
Scheduled borrower and management communication, run on Kigali time.
Where
Where: Settings → Email Notifications controls which of these send
Due-soon reminders to borrowers each morning at 08:00.
Overdue notices each morning at 08:15.
A settlement thank-you sweep at 08:20 as a safety net for instalment-settled emails.
Delay-interest accrual for opted-in loans at 02:15 daily.
Portfolio-at-risk threshold alerts to management on the 1st and 15th at 08:30.
A monthly leadership risk digest on the 1st at 08:45.
Client birthday greetings at 07:30 and public-holiday greetings at 07:45.
Monthly interest accrual posting on the 1st at 02:30.
Any of these can also be triggered manually for testing before being trusted to run unattended.
Area 06
Accounting & Finance
A full double-entry general ledger sitting under the loan book, not beside it. Lending events post themselves, and the statements are produced from the same entries rather than re-keyed.
01
Chart of Accounts
The organization’s own ledger accounts, seeded with a working microfinance chart.
Where
Where: Accounting → Chart of Accounts
Access
Access: VIEW_ACCOUNTING / MANAGE_ACCOUNTING
A default MFI chart is seeded automatically the first time the page is opened, so nobody starts from a blank ledger.
Code ranges by type: assets 1xxx, liabilities 2xxx, equity 3xxx, income 4xxx, expenses 5xxx, with a next-code suggestion inside the right range.
An account’s type locks once it carries journal entries — the ledger will not let history be reinterpreted.
An account with entries or posting-role bindings cannot be deleted; mark it dormant instead.
02
Account Mapping (Posting Roles)
The bridge between business events and the ledger — bound once, then automatic.
Where
Where: Accounting → Account Mapping
Access
Access: MANAGE_ACCOUNTING
Business events never name an account directly. They post through a fixed catalogue of posting roles, and each organization binds every role to one of its own accounts.
Cash roles cover the default disbursement source, a separate binding per payment channel, and any number of extra named bank or mobile-money sources.
Lending roles cover loans receivable, interest receivable, the impairment allowance, provision expense, write-off expense, interest income, fees income, penalty income and bad-debt recovery income.
Balance-sheet and funding roles cover trade payables, borrowings, grant income, share capital, accumulated depreciation and depreciation expense.
Tax roles cover output VAT payable and recoverable input VAT.
Payroll roles cover gross salary expense, net salary payable, PAYE payable and each RSSB liability.
An unbound role is the single most common cause of “my transaction never reached accounting”. Bind the role, then run Controls → Posting Health → Repair to post the entries that were missed.
03
Opening Balances
Bringing legacy books onto the platform so the statements start from the truth.
Where
Where: Accounting → Opening Balances
A wizard captures the as-of date and per-account opening amounts.
Saving posts one balanced, dated opening journal entry; re-saving replaces that snapshot rather than stacking a second one.
Set these before relying on any report — without them the trial balance and balance sheet will not agree with the legacy books.
04
Journal & Manual Entries
Every general-ledger transaction, and the controlled way to correct one.
Where
Where: Accounting → Journal
Lists every entry, each opening to show its debit and credit lines and the event it came from.
Manual journal entries can be posted, but must balance — total debits equal total credits.
Posted entries are immutable. They are never edited or deleted; they are reversed, which posts an equal-and-opposite entry.
Supporting documents can be attached to a journal entry and removed again, giving each posting its voucher.
05
Financial Reports
The statement set, produced from the ledger and date-ranged.
Where
Where: Accounting → Reports, plus dedicated screens
General Ledger — T-accounts per account with opening brought forward, period movements and closing carried forward.
Trial Balance — opening, movement and closing debit and credit per account.
Income Statement — profit or loss for a period, with gross, operating and net margins and the effective tax rate.
Balance Sheet — statement of financial position as at a date, with debt and equity ratios.
Cash Book / Bank Book — receipts, payments and a running balance per cash and bank account.
Day Book — the journal register: every entry in the period with its lines and totals.
Cash Flow Statement — indirect method, split into operating, investing and financing.
Expense Report — expense-account movements grouped by category.
AP Aging — outstanding vendor bills bucketed by age.
VAT Return — output VAT less input VAT, giving net VAT payable.
Depreciation Report — including the quarterly view.
BNR Income Statement and BNR Statement of Financial Position — the same figures rendered in the National Bank of Rwanda microfinance layout.
Every report carries a short basis-of-preparation note explaining how its figures were derived.
If a report looks wrong, check in this order: the date range, then opening balances, then posting-role bindings, then whether Posting Health is reporting unposted events.
06
Provisions, Write-offs & Impairment
Carrying the loan-loss allowance the classification actually requires.
Where
Where: Accounting → Provisions
The summary compares the required allowance by BNR classification against the allowance actually on the books.
Posting the provision books the top-up or release needed to reach the required level — debit provision expense, credit impairment allowance.
Write-off removes an uncollectible loan, using the allowance and expensing any shortfall.
Recovery records money received on a previously written-off loan — debit cash, credit bad-debt recovery income.
The loan’s delinquency status and days past due are what drive the required figure, so collections work and provisioning stay in step.
07
Interest Accrual
Recognising interest earned on loans that have not yet been repaid.
Where
Where: Accounting → Interest Accrual
The summary shows interest earned against interest recognised, and the pending accrual.
Running the accrual recognises interest up to a chosen date — debit interest receivable, credit interest income.
An automatic monthly job runs on the 1st at 02:30, so the position stays current without anyone remembering.
This is what makes the income statement show interest income before cash arrives; low interest income usually means accrual has not been run for the period.
Vendor bills: record a bill (debit expense, credit trade payables), pay it (debit payables, credit cash), or void an unpaid one, which reverses its posting. A paid bill cannot be voided — reverse the payment first.
Fixed assets: register an asset with its cost and optionally post the acquisition at the same time.
Run straight-line depreciation for all active assets up to a chosen date — debit depreciation expense, credit accumulated depreciation — with a quarterly view for reporting.
Disposal removes cost and accumulated depreciation and books the gain or loss.
The register shows cost, accumulated depreciation and net book value.
Funding records capital injections and withdrawals, borrowing drawdowns and repayments, and grants, suggesting the right accounts from the bindings, with paginated history.
09
Tax & Remittances
Statutory liabilities — computing them, and clearing them.
Where
Where: Accounting → Tax / Remittances, and Operations → Taxes
Access
Access: MANAGE_TAX for the loan-tax module
VAT return for a period: output VAT less input VAT gives net VAT payable.
Income tax provision posts debit income tax expense, credit income tax payable.
The Taxes module holds organization-defined taxes — a percentage against a chosen base, or a fixed amount — which are applied to loans.
Each loan can be viewed with and without tax, so the effect on the borrower’s obligation is explicit.
Remittances list every outstanding statutory and payroll liability — PAYE, RSSB pension, RSSB maternity, CBHI, medical and other deductions — with the current balance on each.
Recording a remittance posts debit the liability, credit cash or bank, and appears in the paginated remittance history.
10
Accounting Controls
The integrity layer: catching missed postings and freezing periods that are done.
Where
Where: Accounting → Controls
Financial year configuration sets the period boundaries every report works against.
Posting Health scans for business events — disbursements, repayments, penalties, payroll runs — that have no ledger entry or whose entry is out of sync.
Each issue can be repaired individually, posting or re-posting that entry. Run it after changing bindings, after an import, or whenever a report looks wrong.
Period locks block any further postings dated inside a range, and can be lifted if a period genuinely must reopen.
Period close previews net profit, financial position and posting health before you commit.
Close is a soft close: it validates, snapshots the figures and locks the range. It does not post closing or year-end entries.
11
Reconciliation
Proving that what the system says was collected is what the institution actually holds.
Where
Where: Operations → Reconciliation, and Accounting → Reconciliation
Access
Access: RECONCILIATION / VIEW_RECONCILIATION
Feature
Feature: Reconciliation
Branch reconciliation compares system totals for cash, bank and mobile money against the actual counted totals for a branch over a date range.
The difference is computed and the record carries a status: pending, matched, discrepancy, approved or rejected.
Reconciliations are prepared by one user and approved by another, with both recorded.
Bank reconciliation works at ledger level: pick a cash or bank account, enter the statement date and balance, and clear individual journal lines against the statement until the difference is zero.
Bank reconciliations save as drafts and complete when they balance.
Reconciliation records export for review, and reconciliation alerts notify staff when enabled.
Area 07
Compliance & Regulatory Reporting
The returns Rwandan lenders have to file, generated from live loan data rather than assembled by hand in a spreadsheet the night before.
01
BNR Reporting
Quarterly NDFSP regulatory reporting templates, produced from the loan book.
Where
Where: Operations → BNR Report
Access
Access: VIEW_REPORTS
Choose a cut-off date and the return is built from the portfolio as it stood on that date.
Headline figures: loans on book, outstanding principal, provision required and amounts written off.
Loans are presented by regulatory class — normal, watch, substandard, doubtful, loss — plus restructured and written-off positions.
The organization’s district, sector and BNR institution code print on the template header; missing fields are flagged before export.
Exports as a workbook for the institution’s finance team to review and file.
The accounting module additionally produces the BNR-format income statement and statement of financial position from the same ledger.
Unguka360 generates the workbook. It does not file on the institution’s behalf — the finance team reviews and submits it.
02
CRB Reporting
Borrower credit data prepared for Rwanda’s Credit Reference Bureau.
Where
Where: Operations → CRB Reporting
Access
Access: VIEW_CRB / EXPORT_CRB
Feature
Feature: CRB reporting
A CRB record is opened automatically when a loan is disbursed.
Record status tracks the borrower’s position as active, cleared or delayed.
Records are listed for review before anything leaves the building.
Export produces the submission data set for the bureau.
The CRB report is also available from the central Reports screen for authorised users.
03
BNR Compliance Overview
A read-only supervisory view for a regulator’s agent.
Where
Where: BNR Compliance → Compliance Overview
Access
Access: BNR Agent role only
Read-only view of portfolio health and regulatory compliance metrics.
The agent is invited into a specific organization and can see nothing outside it.
No operational actions are available from this role — it observes, it does not transact.
04
Audit Logs
The immutable record of who did what, when, and what changed.
Where
Where: Management → Audit Logs
Access
Access: VIEW_AUDIT_LOGS; Super Admins see platform-wide activity
Every consequential action is logged — approvals, disbursements, payments, edits, deletions, permission changes and failed imports.
Entries record the actor, the entity type and id, the timestamp, the IP address and the user agent.
Before-and-after detail is kept on changes, so an edit shows the previous and new values rather than just the fact of an edit.
Filter by user, entity type and organization, and sort newest or oldest first.
Audit entries cannot be deleted from the interface.
The log exports to Excel for internal or external audit.
Area 08
People — HR & Payroll
Staff records, time, leave and Rwandan statutory payroll, with every employee also getting a self-service view of their own file.
01
Employee Records
The staff master file and the structure it hangs on.
Employees carry personal details, hire date, department, position, base salary and employment status.
Departments and positions are defined by the organization and maintained from the same screen.
Custom employee fields can be added — text, number, date or yes/no — for whatever the institution tracks that the standard record does not.
Employee documents are uploaded, listed and removed against the individual’s file, held in private storage.
Every platform user is mirrored as an employee, which is what gives everyone a personal HR view.
02
Attendance
Time recorded by the employee, correctable by HR.
Where
Where: HRMS → Attendance; My HR for staff
Access
Access: MANAGE_ATTENDANCE for administration
Staff clock in and clock out from their own My HR screen.
Attendance carries a status and a source, so a self-recorded entry and an HR-entered one are distinguishable.
A daily view shows the whole organization for a given date.
HR can create, amend or delete attendance records where a correction is genuinely needed.
Backfill and history tools exist for periods entered after the fact.
A work schedule defines the organization’s standard working pattern.
03
Leave
Leave types, requests, approvals and balances.
Where
Where: HRMS → Leave; My HR for staff
Access
Access: MANAGE_LEAVES for approval
Leave types are defined by the organization with their own entitlements.
Employees request leave with dates, type and an optional reason, and can cancel a request they have raised.
Requests move through pending, approved and rejected.
Leave balances are computed per employee per type and visible to both HR and the employee.
A leave calendar shows who is away and when, so cover can be planned.
04
Payroll
Rwandan statutory payroll, run, approved, paid and payslipped.
Where
Where: HRMS → Payroll
Access
Access: RUN_PAYROLL
Payroll configuration holds the rates and rules the run is computed against.
A run is created for a period and scope, computing gross, deductions, employer cost and net take-home per employee.
Statutory lines cover PAYE income tax, RSSB pension for both employee and employer, RSSB maternity for both, CBHI community health, and the employer’s occupational-hazard contribution.
Overtime pay is included in the computation.
A run moves through draft, approved and marked-paid, and can be deleted while still unapproved.
Individual payslips are produced per employee and visible to that employee in My HR.
The resulting liabilities appear in Accounting → Remittances, ready to be cleared to the authorities.
05
My HR (Self-service)
Each employee’s own file, without going through HR for routine things.
Where
Where: Overview → My HR
Access
Access: Every user
View your own employee profile — department, position, hire date and contact details.
Clock in and clock out, and see your recent attendance.
Request leave, see your remaining balance by type, and track your requests.
Open and download your own payslips by period.
View the documents held on your file.
Area 09
Intelligence, Reporting & Support
Turning the record into something a manager can act on this morning — plus the channel for getting help without leaving the system.
01
Dashboard
The role-appropriate opening view of the institution’s position.
Where
Where: Overview → Dashboard
Access
Access: Every user, filtered by role and branch
Headline statistics: portfolio outstanding, collections for the period, overdue count and active clients.
Portfolio-at-risk widget grouped by delinquency bucket, using the same colour language as the delinquency and BNR screens.
Disbursement trend across recent months, with the current month distinguished.
Branch comparison for organizations running more than one branch.
Portfolio breakdown views for drilling into composition.
Recent loans and overdue loans as clickable worklists rather than static counts.
Quick actions for the things staff do most: new loan, clients, loan recovery, reports.
Managing Directors see the consolidated position with a branch filter; branch users see their own branch.
02
Reports & Exports
The central export desk — every operational report, in Excel or PDF.
Where
Where: Intelligence → Reports
Access
Access: VIEW_REPORTS or VIEW_EXECUTIVE_REPORTS
Client Loan Status — client, loan and payment status combined for actionable follow-up.
Branch Portfolio Risk — branch-level exposure, collections and risk concentration in one report.
Payments — all payment transactions, honouring the date range applied on the Payments screen.
Reconciliation — branch reconciliation records, where the feature is enabled.
CRB Reporting — the credit reference bureau data set, where the feature is enabled.
Loan Schedules — repayment schedules for a single loan or across a date range.
Portfolio at Risk — the delinquency summary and the queue by bucket.
Audit Logs — the activity trail, for users with audit access.
Clients — the client list with status and KYC position.
Users — organization users, for the Managing Director.
Loan Applications — every application and its status.
Loans — the portfolio list with principal and status.
The Loan Book report is available as its own card, and Accounting keeps its statement set separately.
03
Loan Scoring
A configurable client score to support, not replace, the credit decision.
Where
Where: Intelligence → Loan Scoring
Access
Access: Managing Director, or MANAGE_SCORE_CONFIG
Feature
Feature: Loan scoring
Three weighted factors, configurable by the organization: KYC completion, loan experience and past loan payment behaviour.
Weights are set to total 100 and saved as the active configuration.
Search a client and calculate their score on demand.
The result shows the overall score, a risk level of low, medium or high, and the points contributed by each factor — so the number can be explained to a committee.
Applications carry their own scored state, and score results are retained against the record.
04
AI Assistant
Plain-language questions about the institution’s own portfolio and about how the system works.
Where
Where: Intelligence → Unguka360 AI Assistant
Access
Access: Every user in an organization with the feature enabled
Feature
Feature: AI assistant
Ask about your portfolio in ordinary language and get answers grounded in your organization’s live data.
Answers are scoped to the asking user’s organization, role and branch — the assistant cannot show what the user could not open themselves.
Backed by a curated knowledge base covering BNR licensing, capital adequacy, reporting and provisioning rules, portfolio-at-risk practice, the Rwandan microfinance ecosystem, CRB, loan appraisal, the five Cs of credit, recovery and legal action, risk management, and this platform’s own workflows.
Includes a Kinyarwanda financial glossary for client-facing communication.
Answers operational how-do-I questions with the actual next step, status and permission required.
05
Notifications
In-app alerts for the things that need a person.
Where
Where: Top bar
Access
Access: Every user
In-app notifications with an unread count in the header.
Mark an individual notification read, or clear the whole list at once.
Notifications are delivered in-app and, where the organization has them enabled, by email.
Loan stage changes, applications, KYC decisions, payments awaiting confirmation and reconciliation alerts all raise notifications for the staff concerned.
06
Support Tickets
Getting help without leaving the platform — and without an email thread nobody can find later.
Where
Where: Support → Help & Support
Access
Access: Every organization user; Super Admins answer rather than raise
Raise a ticket with a subject, a message and a priority of low, normal, high or urgent.
Each ticket is a message thread — both sides post onto the same ticket, so context stays together.
Statuses run open, in progress, resolved and closed.
Organization users see their own organization’s tickets; the platform team sees every organization’s.
Platform administrators answer tickets and set status; they do not raise them.
Support in Unguka360 is the in-app ticket system. Include the exact screen, what you expected and what happened — that is what lets a ticket be answered on the first reply.
Area 10
Platform Administration
The operator-side of the product: migrating institutions onto it, keeping it configured, and keeping it running.
01
Data Importer
Bulk-loading an existing portfolio from a legacy system in one controlled pass.
Where
Where: Platform → Data Importer
Access
Access: Super Admin only
Loads clients, loans, payments and payment allocations from a single combined CSV.
Two mandatory steps: a dry run that previews and validates, then a commit. The commit requires the token issued by the dry run, the file must be byte-identical to the previewed one, and the token is single-use and expires after fifteen minutes.
The target organization is chosen in the interface; branch can be set per row, falling back to the chosen branch when left blank.
Maximum upload is 10 MB, and the import runs inside one transaction with a ten-minute budget — roughly 2,000 rows per file.
All-or-nothing: if any row fails, nothing is written, and the failure is recorded in the audit log with its reason.
Only existing-portfolio loan statuses are accepted — disbursed, active, delayed, paid and closed. Pre-disbursement statuses are rejected, because those belong in the normal origination flow.
Every imported loan must carry its interest rate, interest model, repayment model, term value, term unit and repayment frequency; unknown columns are rejected outright.
Balances supplied in the file are recomputed from the generated schedule; where they disagree you get a warning showing both, and the computed value wins.
Payment columns are only read on rows that also carry the loan key, and payment references must be unique per loan. Only confirmed payments are importable.
On re-import, blank optional client columns mean keep the existing value, and a KYC decision already made in the platform is preserved.
After commit, delinquency is recalculated, so overdue imported loans show as delayed immediately instead of sitting as active.
For a single backdated loan on an existing client, use Add Existing Loan instead — the importer is built for portfolios, not for one record.
02
Organization Profile & Branding
The institution’s own identity inside the product and on its documents.
Where
Where: Settings → Organization
Access
Access: UPDATE_ORGANIZATION_PROFILE
Organization name, TIN, registration number, address, email and phone.
District, sector and BNR institution code, which print on the regulatory report headers.
Logo upload plus primary and secondary brand colours.
Default language for the organization, with each user still free to choose their own.
Subscription plan and expiry are held against the organization.
03
Email Notification Settings
Per-organization control over every email the system is capable of sending.
Staff and internal alerts — loan stage alerts, loan application alerts, loan deleted alert, payment awaiting finance confirmation, payment critical actions, reconciliation alerts, KYC submitted, approved, rejected and resubmitted, portfolio-at-risk threshold alert and the monthly risk digest.
Security and account emails — password reset, password changed, staff invite and account enabled or disabled. These are always sent and are shown locked rather than pretending they can be switched off.
Each toggle writes immediately, and the screen shows how many notifications are currently switched off.
04
Holidays
The days the institution recognises — used for greetings and for working-day logic.
Where
Where: Settings → Holidays
Access
Access: Managing Director
Rwandan public holidays are seeded, and the list can be reset back to them at any time.
Add, edit or remove the organization’s own holidays with a name and a date.
Holidays drive the automated public-holiday greeting to clients.
05
Changelog & Platform Updates
Telling every institution what changed, inside the product.
Where
Where: Platform → Changelog
Access
Access: Super Admin publishes; every user sees
Publish release notes and product updates to all organizations.
The current update surfaces to users in-app.
A user can dismiss an update once seen, and the dismissal is remembered per user.
06
System Monitoring
A live operational snapshot of the deployment itself.
Where
Where: Platform → System Monitoring
Access
Access: Super Admin only
Backend health, reported as ok, degraded or error.
Process status for the running application services.
SSL certificate status, including a warning while a certificate is approaching expiry.
Backup freshness, reported as fresh or stale so a silently failed backup is visible.
Auto-refreshes every thirty seconds, with a manual refresh available.
07
Document Storage & Security
How every uploaded file is held and who is allowed to read it.
Every tenant document — KYC packages, loan files, payment proofs, HR records and accounting vouchers — is held in private object storage on an internal network with no public port.
Files are never served by a guessable public URL. Each request is authorised against the organization that owns the object before a single byte is streamed.
Documents are viewable in-app through a viewer, and downloadable by authorised users.
Uploads are constrained by type and size at the point of upload.
The store is created on boot, so a fresh deployment, a restored backup and a rebuilt volume all converge on the same working state.
08
Data Wipe Requests
Clearing an organization’s client and loan data, under dual control.
Where
Where: Platform → Organizations
Access
Access: Super Admin, with a second Super Admin approving
One administrator raises a wipe request against an organization with a reason.
A second administrator must approve it before anything is removed.
The current outstanding request is visible on the organization, so a pending wipe is never a surprise.
The whole exchange is recorded in the audit log.
About this guide
This guide describes the platform as it is built today. Access to any given module depends on the role, the permissions and the branch of the signed-in user, and on the features enabled for that institution — so no single person sees every screen described here.
Unguka360 covers the lending side: the client master, the loan book, the general ledger and the reporting layer above them. It does not provide deposit accounts, teller operations or clearing, and it does not file returns on an institution’s behalf — it produces the BNR workbook and the CRB submission data for the finance team to review and file.
