Most microfinance institutions end up running the loan book twice: once in a spreadsheet that holds the real schedules, arrears buckets and provisioning, and once in Odoo, where somebody re-keys the disbursement as a vendor payment and the repayment as a customer receipt. Odoo core has no concept of a loan. account.move models an invoice, not an amortising principal balance; there is no field that knows what portion of a repayment is principal versus interest versus a late fee, no object that ages an instalment into a 30/60/90 bucket, and no report that will tell a board or a regulator what PAR 30 looks like this morning. The Enterprise accounting apps do not close that gap either — deferred revenue and asset models solve a different problem. The moment you need a rescheduled loan, a partial write-off, or a portfolio-at-risk figure that ties back to the general ledger, the spreadsheet becomes the source of truth and Odoo becomes a filing cabinet.

We build a proper lending domain inside your database. The core is a loan.product model carrying the terms your institution actually sells — flat or declining-balance interest, tenor, repayment frequency, grace period, processing and insurance fees, penalty rate and the accounting configuration (receivable, interest income, fee income, penalty and provision accounts). A loan.contract record inherits mail.thread and mail.activity.mixin so every approval, restructure and field-officer note is threaded on the chatter, and moves through a real state machine — draft → submitted → approved → disbursed → closed, with rejected, restructured and written_off branches. Generating the schedule writes loan.schedule.line records with principal, interest, fee and balance columns; the outstanding balance, days past due and bucket are compute fields with explicit @api.depends, and the aggregate ones are store=True so they can be grouped, filtered and pivoted rather than recalculated per row in a list view.

Money movement is posted, not described. Disbursement generates the account.move entries against the configured journal and can be routed to the payment provider or bank file you already use; repayment allocation applies your waterfall — penalty, then fees, then interest, then principal, or whatever your policy says — and each allocation is written to the schedule lines so a partial payment leaves an auditable trail rather than a lump credit. Collections get their own workspace: overdue contracts land in aged buckets (current, 1–30, 31–60, 61–90, 90+) with kanban and list views for field officers, follow-up activities raised by ir.cron and base.automation rules, and a loan.collection.action log of every promise-to-pay and site visit. Provisioning runs off a configurable matrix — a percentage per bucket per product — producing a monthly provision journal entry and a provisioning view that reconciles to the GL. Portfolio reporting ships as QWeb PDF statements and repayment schedules for the customer, plus stored read-group models behind pivot and graph views for PAR 30/60/90, collection efficiency, disbursement volume by branch and officer, and ageing by product. Access is governed by ir.model.access.csv groups (Loan Officer, Branch Manager, Credit Committee, Portfolio Accountant) with ir.rule record rules scoping officers to their own portfolio and branches to their own book, so a multi-branch MFI can share one database safely. Everything is reachable over XML-RPC and JSON-RPC, so a mobile collections app, a USSD gateway or a credit bureau feed can read and write contracts without a bespoke integration layer.

This is a build-to-order product, not a download. After a short scoping call we agree your interest method, repayment waterfall, bucket definitions, provisioning matrix, approval hierarchy and chart-of-accounts mapping, then write the module against your exact Odoo version — 17.0, 18.0 or 19.0, Community or Enterprise — with the __manifest__.py depends list limited to what your database actually has. Typical delivery is 2 to 4 weeks from confirmed scope. You get the installable source, a staging deployment for UAT with a documented rollback, a training session for the loan and finance teams, and a post-go-live support window. The git repository is handed over at the end, so the code is yours and no future change is gated behind us.