Microfinance institutions and small lenders almost always end up running the loan book somewhere other than the ERP. Business Central handles the general ledger, the bank accounts, the payment journals and the statutory reporting well — but it has no concept of a loan product, an amortisation schedule, a disbursement tranche, a PAR-30 bucket or a provisioning stage. Teams bridge the gap with spreadsheets: one workbook for schedules, another for arrears ageing, a third for the provision matrix that finance types into a manual journal at month end. The result is a loan portfolio the CFO cannot reconcile to the trial balance without a two-day exercise, and a collections team working from a file that was correct yesterday morning.

Business Central's native building blocks run out of road quickly here. Customer ledger entries and a Payment Terms code can express "due in 30 days" but not a 24-instalment declining-balance schedule with a grace period, a processing fee capitalised at disbursement and a penalty rate that starts on day 8 of delinquency. Dimensions can tag a branch or a loan officer but cannot carry the state machine a loan moves through — applied, approved, disbursed, current, in arrears, restructured, written off. And nothing in the standard product produces the reports a lender actually lives on: portfolio at risk by ageing band, disbursement and collection volumes by product and branch, expected credit loss staging.

What we build is a per-tenant AL extension (or an AppSource-shaped app where you prefer that packaging) that adds the lending domain to Business Central as first-class data rather than as a bolted-on interface. New tables carry Loan Product, Loan, Loan Schedule Line, Loan Transaction and Collection Entry; table and page extensions add borrower attributes and a Loans FactBox to the Customer card so a loan officer never leaves the record they are already on. Schedule generation, interest accrual, penalty calculation and provisioning live in codeunits, not in page code, so the same logic serves the UI, the job queue and the API. Posting is done through Business Central's own general journal posting routines with configurable posting groups per loan product, which is what makes the portfolio reconcile to the GL by construction instead of by reconciliation. Event subscribers hook the standard payment application and customer posting events, so a cash receipt applied against a borrower is allocated across penalty, interest and principal in your defined waterfall.

Operationally it runs on the platform's own plumbing. Nightly accrual, ageing reclassification and provisioning runs are Job Queue Entries with their own error handling and retry, so nothing depends on someone remembering to open a page. API pages exposed over REST API v2.0 / OData v4 let a mobile field-collection app, a payment-gateway callback or a credit bureau integration read and write loans without screen scraping — and the same endpoints feed Dataverse and the Power Platform if you want Power BI portfolio dashboards or a Power App for field officers. Dedicated permission sets separate the loan officer who originates from the credit committee that approves and the finance user who posts, and every state transition is written to an audit trail. The extension targets current Business Central release waves and works on both SaaS online and on-premises deployments.

Delivery is build-to-order. Nothing here is a download you buy today and install this afternoon: we start with a scoping call, confirm your loan products, interest methods, penalty and waterfall rules, ageing bands and provisioning matrix in a written scope, then build against your Business Central version. Typical delivery is one working week from confirmed scope, depending on how many products and integrations are in play. You get the compiled app plus the AL source, deployment into a sandbox for UAT before anything touches production, a documented and rehearsed rollback, and a git repository handover so the code is yours to maintain or extend with any AL developer.