Running Frappe Lending loan management on ERPNext
Frappe Lending is a Frappe app that runs on ERPNext and covers the loan lifecycle, from application and disbursement through repayment, within the same database, permissions and ledgers that your finance team already uses. Lenders usually consider it when they want loan products, repayment schedules and accounting entries in one ERP instead of a separate loan system with a nightly reconciliation job. This page covers the decisions that shape that design: how loan products and applications are modeled, how collateral is tracked, how disbursement and repayment entries reach ERPNext accounting, how co-lending and loan transfers are handled, and the point at which a dedicated core banking platform is the better fit. Before scoping anything, confirm the app's current feature set and its compatibility with the ERPNext major version you run, because the app's documentation, not this page, is the authority on what it does today.
The first technical step is an inventory of what the app must do in your lending operation, compared against what its documentation describes. Ask for the loan product types you intend to offer, the repayment methods, interest and penalty rules, and the collateral types you hold. Then confirm, with the app's documentation and a working test site, which of these it covers out of the box and which need custom DocTypes or server scripts. Server Scripts are disabled by default from version 15 and must be enabled with server_script_enabled, and Frappe Cloud public shared benches do not allow them, so hosting choice affects how much logic you can place in configuration. Also decide who approves applications and disbursements, and map those steps to ERPNext roles and workflow states before go-live.
The accounting design deserves the most review time. Each disbursement, interest accrual, repayment and write-off should post to a ledger account you have chosen and tested, with cost centers or dimensions that match your reporting. Run a month-end cycle on a copy of production data and reconcile the loan book against the general ledger before any real customer is onboarded. Plan for the recurring cost as well as the one-time build: upgrades of ERPNext and the lending app must be tested against your product rules, and the supported-version policy requires a listed version and a matching support plan for warranty coverage. Ask any implementation partner to quote the scope in writing, including data migration, testing and the upgrade path.
What Frappe Lending covers from application to repayment
Frappe Lending runs the loan lifecycle inside ERPNext, so each stage (origination, money movement, servicing, security and transfers) writes to the same accounting and customer records. The cards below mark what the lender configures at each stage and what the work produces. Confirm exact document types and settings in the app documentation before scoping.
Loan application and approval
The lender defines loan products, eligibility inputs and the approval steps a file passes through before any money moves. Configuration covers which applicant data is captured, who can approve at each limit, and what is recorded when an application is declined. The output is a documented approval path that credit, risk and operations agree on before go-live. Check whether your approval rules need to live in the app or in an external decision step, and confirm how the app records the decision reason for audit.
Disbursement workflow
Disbursement converts an approved loan into a payment and a receivable. The lender decides how funds leave (bank transfer, payment gateway or internal account), which conditions must be met first, and who authorizes release. The work produces a tested disbursement path with dual control where your policy requires it. Confirm which bank and payment integrations are supported out of the box and which need custom development, since payout errors are costly to unwind.
Repayment schedules and collections
Repayment schedules set installment amounts, due dates, interest accrual and how partial or early payments are applied. The lender configures the schedule rules per product, grace periods, and the order in which payments clear interest, fees and principal. The output is a schedule that matches the signed loan terms, checked on sample loans across each product. Confirm how late payments, penalties and restructuring are represented, because these cases usually need product-specific rules.
Collateral tracking
Where a loan is secured, the lender records each collateral item, its valuation, and the link to the loan it supports. Configuration covers the collateral types offered, how valuations are updated, and what happens when coverage falls below a set level. The work produces a register that risk teams can review without a separate spreadsheet. Confirm whether the app tracks release and revaluation events, and where documents such as titles or valuation reports are attached.
Automated accounting entries in ERPNext
Each loan event, such as disbursement, interest accrual, repayment and write-off, should post to the ERPNext general ledger through accounts the lender maps in advance. The lender designs the chart of accounts for loan receivables, interest income and provisions, and sets the posting rules. The output is a reconciled ledger that finance can close each period. Test posting for every event type and confirm the reversal behavior for corrections before any live loans are booked.
Co-lending and loan transfers
Co-lending splits a loan between partner lenders, and transfers move an existing loan to another lender or portfolio. The lender must define each party's share, how interest and repayments are divided, and which records prove the transfer. The work produces split rules and a transfer procedure that finance and legal can audit. Confirm which co-lending and transfer features the current app version supports, and whether partner reporting needs custom reports or exports.
Which loan model and configuration fits your book
This table compares the main configuration decisions for loan products on Frappe Lending inside ERPNext, with the options, the situations each suits and what to settle with finance and risk first. Read each row as a decision to make before any loan product is built, because most of them are costly to change once live loans exist.
| Decision | Options and when each fits | What to confirm with finance and risk first |
|---|---|---|
| Loan product structure | Single-tranche term loans for simple books. Revolving or line-based products where borrowers draw and repay repeatedly. Products with grace periods or moratoriums for projects that pay back late. | Which product types you will offer at launch, the maximum tenor and limit per product, and whether any product needs a separate approval path. |
| Interest and repayment schedule rules | Fixed or floating rate schedules with equal installments, equal principal or custom schedules. Daily accrual against a rate master for variable pricing. Penalty interest rules for late payment. | Day-count basis, rounding and final-installment treatment, how penalties are calculated and capped, and who signs off the rate table changes. |
| Collateral handling | No collateral for unsecured products. Pledged assets recorded against the loan for secured products, with valuation and haircut rules applied at approval. Multiple collateral items per loan where one asset does not cover the limit. | Which collateral types are accepted, valuation source and update frequency, haircut policy, and the legal documentation needed before a pledge is recorded. |
| Disbursement and repayment postings to ERPNext accounts | Map each product to a receivable, interest income, fee income and disbursement account. Post disbursements as payments from the funding bank account. Post repayments by principal, interest and penalty components to separate income lines. | Chart of accounts design, cost center and accounting dimensions, which accounts auditors will sample, and the close calendar the postings must align with. |
| Co-lending funding and income split | Single-lender books need no split. Co-lending where partners fund a fixed share of each loan requires a split of disbursements, repayments and interest. Partners with different cut-off or settlement dates need a settlement schedule outside the loan record. | Partner agreements that define the funding ratio, income share, fee allocation, default responsibility and settlement frequency, plus who reconciles partner statements. |
| Loan transfers and ownership records | Keep the loan with its original lender for life. Transfer whole loans with an outstanding balance to a new owner, which changes who holds the receivable from the transfer date. Partial transfers of participations need a record of each share. | Transfer eligibility rules, the effective date and accounting cut-off, how the receivable moves in the ledger, and how borrowers and regulators are notified of a change in owner. |
| Dedicated core banking platform | Stay on ERPNext with Frappe Lending when products are standard, volumes are moderate and lending is one line of business. Consider a dedicated core banking platform when you need deposits, multi-product ledgers at high volume or tenancy-level separation. | Expected product count and transaction volume, deposit and savings needs, regulatory reporting scope, and whether the ledger must be separate from the general ledger of other businesses. |
When a dedicated core banking platform is the better fit
Choose a dedicated core banking platform when the lender's activity goes beyond lending on ERPNext. The usual trigger is deposit-taking: once you hold customer savings or current accounts, the regulator's expectations for ledgers, customer records and reporting are set by your licence, not by the loan workflow. Other triggers are a large book spread across many loan and savings products, several legal entities or tenants sharing one system, or transaction volumes that make a single ERPNext bench a capacity question. Frappe Lending on ERPNext suits lenders whose products, accounting entries and collateral records fit one company's books. It is not designed to act as a multi-tenant banking ledger.
Apache Fineract is the open-source alternative most teams evaluate. It is licensed under the Apache License 2.0 (SPDX: Apache-2.0), manages client records, loan and savings portfolios and real-time accounting, and is built as a headless application: it exposes REST APIs and provides no user interface of its own, so you would need to build or select a front end. It recommends PostgreSQL and treats MariaDB and MySQL as deprecated. Tenants are separated by the Fineract-Platform-TenantId header, and the documentation describes read, write and batch instance roles, with Liquibase migrations running only on write instances. The project's README warns that production deployment can be complex, costly and time-consuming and does not provide a comprehensive production deployment guide. Ask any vendor you engage to scope that work explicitly, and budget for the front end, the integrations back to ERPNext and the operations team it needs.
Before you compare platforms, confirm the licence and product scope with your regulator and counsel. Whether you may take deposits, how you must segregate customer funds, which reporting and capital rules apply and whether a co-lending or loan transfer structure changes your obligations are legal questions that no software choice answers. Once those answers are written down, map each required product and control to the platform that will hold it. A practical rule is to keep Frappe Lending where ERPNext already runs your books and the lending scope is bounded, and to evaluate Fineract only when the licence and product list clearly require a core banking ledger.
How a Frappe Lending rollout runs from product design to go-live
This sequence moves a lender from confirmed versions and hosting to a live loan book, with each step closing on a written record the lender can review and sign off.
Confirm versions, hosting and app compatibility
DeployOpen and the lender's team confirm the ERPNext and Frappe Lending versions the lender will run, check that the versions are listed as supported on Frappe's supported versions page, and choose the hosting model: Frappe Cloud, Docker Compose or a bench install in infrastructure the lender controls. Confirm which Frappe Cloud support plan, if any, matches the chosen version, since Frappe's policy ties warranty coverage to a listed version and a matching plan. The output is a version and hosting decision record with the sizing and backup assumptions written beside it.
Design loan products and the chart of accounts map
Product owners, finance and risk define each loan product: eligibility, interest method, repayment schedule, fees, penalties and collateral requirements. Finance then maps every income, receivable, provision and fee type to a specific ERPNext account, including the cost centers and dimensions that month-end reporting needs. The output is a signed product catalogue and a posting map that lists each lending event and the debit and credit accounts it creates. Nothing moves to configuration until finance has reviewed the map line by line.
Configure the lifecycle and approval workflow
The team builds loan products, applicant and loan application records, and the approval steps that a loan must pass before sanction and disbursement, using the roles and permissions the lender defined earlier. It also sets up repayment schedules, penalty rules and write-off handling in the test environment. The output is a configuration record exported for version control, plus a walkthrough log showing one loan from application through approval and disbursement in the test site. Changes outside the export are not accepted into the baseline.
Build and test accounting entries against a reconciled sample
DeployOpen loads a sample book of loans that finance has already reconciled by hand, covering disbursements, scheduled repayments, late fees, prepayments and write-offs. The team runs each lifecycle event and compares the generated journal entries and ledger balances with the expected results, investigating every difference before continuing. The output is a test log with each scenario, its expected and actual postings, and the sign-off from the finance owner. Scenarios that fail are fixed and retested, not explained away.
Migrate open loans with a reconciled opening position
For loans already on the books, the team maps each open loan's principal, accrued interest, schedule, collateral and borrower data into Frappe Lending records, then reconciles the opening balances against the legacy ledger at a cutoff date. Migration runs in rehearsal cycles on copies of production data until the totals match. The output is a migration reconciliation report that shows loan counts, outstanding principal and interest by product, and the list of records left out with the reason for each.
Run parallel repayment and month-end checks
For a defined period, the lender runs repayments and at least one month-end close in parallel, with the old system or manual process still active, and compares collections, interest accruals, provisions and ledger balances between the two. Finance and operations review every break, and the migration is corrected where the cause is in the data. The output is a parallel-run report with each break, its cause and its resolution, plus a month-end close checklist that finance has run once in the new system.
Cut over to production and hand over operations
The team freezes changes, runs the final data load and reconciliation at the cutoff date, switches disbursement and repayment to the production site, and confirms backups, monitoring and access reviews are working before the first live business day. The lender's operations owner receives runbooks for the scheduler, backups and common repayment exceptions. The output is a signed cutover checklist, the production configuration baseline, and a post-go-live review date agreed in writing.
What drives Frappe Lending implementation effort and cost
This table lists the factors that most change the work on a Frappe Lending build, what makes each one heavier, what keeps it lighter, and what to request in a written quote. Cost is set by the written scope, so use the rows to check whether a proposal covers each driver explicitly. The main takeaway is that loan data quality and accounting entry mapping usually decide schedule risk more than the number of screens.
| Driver | What increases effort | What reduces effort | What to ask for in a quote |
|---|---|---|---|
| Loan products and interest rules | Many products with distinct repayment schedules, penalty rules, moratoriums or rate resets that need custom logic | A short list of products with standard interest and repayment patterns defined before build starts | A product-by-product configuration list with interest, penalty and schedule rules, and which items are excluded |
| Collateral types | Several collateral classes with different valuation, haircut, release and revaluation rules | One or two collateral types with fixed valuation logic and clear release conditions | Confirmation of which collateral types are configured, how valuations are recorded, and whether any type needs custom code |
| Co-lending partners | Multiple lenders sharing one loan, each with its own share, fee split and reporting feed | A single lender model, or partner shares that follow one agreed template | A description of share calculation, settlement between partners, and how partner reports are produced |
| Legacy loan data volume and quality | Large histories, open loans with partial schedules, inconsistent customer records or missing collateral details | Clean extracts, a documented field mapping, and a limited set of open loans to migrate | Data profiling findings, the migration approach for open versus closed loans, reconciliation steps, and who cleans the source data |
| Accounting entry mapping | Many event types (disbursement, interest accrual, penalties, write-offs) each needing a different ledger treatment | A signed-off chart of accounts and a short table of event-to-account rules | A mapping table covering each loan event, the ERPNext accounts and cost centers used, and the accounting owner who approves it |
| Custom approvals or scripts | Credit approval chains with conditions, custom scoring inputs or server scripts that must run on document events | Standard approval workflows used as delivered, with custom logic kept to a small number of documented rules | A list of each approval step and script, the role that owns it, and the testing and review steps before enabling it |
| Bank and KYC integrations | Live connections to core banks, payment rails, credit bureaus or identity verification providers with their own certification and error handling | Batch file exchange or a single integration point with agreed formats | The named external systems, interface method, data fields, error handling and who holds the vendor relationship and credentials |
| Testing depth | Full regression across products, repayment cycles, month-end close and reconciliation with partner feeds | Scenario-based testing focused on the agreed products and the accounting events that reach the ledger | The test scenarios, the test data used, who signs off each stage, and the evidence produced for finance and audit reviewers |
Which compliance obligations shape the lending build
Several obligations decide how a lending build is designed, and which ones apply depends on your licence, listing and footprint. If you are a non-bank lender under FTC jurisdiction, the FTC Safeguards Rule (16 CFR 314.4(c)(5)) requires multi-factor authentication for any individual who accesses an information system, unless your Qualified Individual approves an equivalent control in writing. That reaches ERPNext desk users, underwriting and collections screens, and administrator accounts, so decide early which sign-in paths carry the second factor. If your lender reports under US securities law, SEC Release 33-8810 names program development, program changes, computer operations and access to programs and data as IT general control areas for SOX Section 404 assessments. Disbursement and repayment entries that post to the general ledger fall inside that scope, so change control over the lending app and its accounting mappings must be designed before go-live.
For EU financial entities, DORA has applied since 17 January 2025. Article 28(3) requires a register of information covering every contractual arrangement for ICT services, including hosting providers, implementation partners and any Frappe Cloud support plan. Article 28(8) requires documented and tested exit strategies for ICT services that support critical or important functions, and a live loan book usually qualifies. Article 30(2) requires each contract to state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Confirm these terms with your hosting and support providers before you pick an infrastructure model. Borrower identity, income and collateral records also fall under Regulation (EU) 2016/679 (GDPR), so retention periods, access logs and deletion procedures need a named owner.
PCI DSS applies only if the lending system stores, processes or transmits cardholder data, or could affect the security of systems that do. If borrowers repay by card, identify which component touches card data and whether a hosted payment page keeps the ERPNext and Frappe Lending servers out of scope. Ask your assessor to confirm that boundary in writing. Server Scripts also shape the design: from version 15, they are disabled by default and need the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Custom loan logic that depends on them needs an approved enablement path in your change process. DeployOpen can prepare the access controls, change records, backup evidence and data maps these obligations ask for. It does not issue audit reports, attestations or certifications. Auditors, assessors and certification bodies issue those opinions, so agree the evidence they need before the build starts.
How Frappe Lending connects to ERPNext, identity and payment rails
Frappe Lending is not a standalone system. It posts into ERPNext accounting, takes its access rules from ERPNext roles, and depends on the staff identity, data import and bank feed paths around it. Each integration point below is a decision to make before configuration starts, not a step to finish later.
ERPNext accounting and the general ledger
Loan disbursements, interest accruals and repayments generate accounting entries that land in the ERPNext general ledger, so the loan product setup determines how receivables, interest income and provisions are mapped to accounts. Decide early which accounts each loan product uses, how company and cost center dimensions are applied, and who reviews posted entries at period close. Confirm the exact entry types and posting behavior for your Frappe Lending version with the Frappe documentation and a test company before go-live.
ERPNext roles and permissions
Loan officers, credit committees, collections staff and finance users should see different loan records and fields. ERPNext role permissions, user permissions and field-level restrictions decide who can create applications, approve limits, change repayment schedules or view customer personal data. Map each loan lifecycle step to a role before building workflows, and test the boundary with a user who holds only one of those roles. See the access control guidance for how to layer these controls.
Staff identity through LDAP or Social Login Key
Staff sign-in to ERPNext can run through LDAP against Active Directory or OpenLDAP, or through Social Login Key with OAuth or OpenID Connect providers. LDAP also maps directory groups to ERPNext roles at each login, which makes group design a credit-control matter, not only an IT one. Decide who owns the group-to-role mapping, how leavers lose access, and whether borrowers are ever given logins at all, since borrower portals are a separate design question.
Legacy loan file and data import
Most lenders start with loan books in spreadsheets, a previous core system or scanned files. The ERPNext Data Import tool loads records from CSV or Excel using templates and supports child table rows, but the documentation advises importing only a few thousand records at a time. Plan the import in batches with reconciliation totals for outstanding principal and interest, and agree which historical entries are re-posted to the ledger and which are carried as opening balances.
Bank statement and payment feeds
Disbursement payouts and borrower repayments reach the ledger through bank transactions, so the feed setup determines how quickly payments are matched to repayment schedules. The ERPNext integrations group documents which bank feeds and payment gateways sync and what each one brings across. Confirm with the bank or gateway whether settlement files carry loan references, how partial and late payments are reported, and who clears unmatched items each day.
Reporting through Frappe Insights
Portfolio aging, delinquency, provisioning and disbursement volumes are usually answered with custom reports or BI tools. Frappe Insights queries ERPNext data without SQL and can build dashboards for credit and finance teams. Decide which reports must reconcile to the general ledger, define the outstanding balance logic once, and check that Insights users inherit the same permissions as the underlying ERPNext records.
What buyers ask before hiring help with Frappe Lending
What does a Frappe Lending implementation cost and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of loan products and their repayment rules, how many legacy loan files must be migrated and how clean they are, how many integrations are needed (bank feeds, payment collection, credit bureaus, document storage), the number of ERPNext companies and accounts that post entries, and how many approval and reporting flows must be built. Ask for a quote that splits one-time work (configuration, migration, testing, training, go-live) from recurring work (support, upgrades, monitoring). Confirm whether the quote covers testing with your own finance and risk staff and whether it includes any custom app code.
How long does a Frappe Lending project take to go live?
Duration depends on the number of products, the migration scope, the integrations and how quickly your credit, finance and risk teams can sign off decisions. A project with a single simple product and clean data differs greatly from one with several products, co-lending terms and years of legacy files. Ask for a timeline in the written scope with named milestones: product design sign-off, chart of accounts mapping, migration rehearsals, user acceptance testing and go-live. Your own approval cycles often set the critical path, so confirm them before the schedule is agreed.
What must the lender provide before implementation starts?
The lender needs to supply decisions and data that no implementer can invent. The core inputs are:
- A written loan product policy covering eligibility, interest and fee rules, repayment schedules, penalties, restructuring and write-off rules.
- A chart of accounts and the accounting policy for interest income, provisions and fee recognition, so automated entries post correctly in ERPNext.
- Legacy loan files, with balances, schedules, collateral records and customer identifiers, in a format that can be checked.
- Named risk and compliance sign-off for the product rules and the controls around them.
Confirm these owners and deadlines at the start, because delays in any of them move the whole plan.
Can our in-house team implement Frappe Lending without a partner?
Yes, if you have people who know ERPNext, the Frappe Framework and lending operations well enough to design products and test them. Most teams need skills in Python for server scripts and custom apps, ERPNext accounting, data migration and release management. The harder part is usually the lending design itself, which requires credit, finance and risk judgment. Assess your team against that list, then decide which parts to keep in-house and which to scope to a partner. A fixed-scope engagement can cover only the pieces you choose, such as migration or integrations.
Do ERPNext upgrades affect the Frappe Lending app?
They can. Frappe Lending runs on ERPNext and the Frappe Framework, so a platform upgrade may change APIs, document structures or accounting behavior that your custom scripts depend on. Check the supported versions page before planning any upgrade, because ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, while version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029. Test every upgrade in a staging copy with real loan scenarios, and confirm with the vendor which Frappe Lending release matches your ERPNext version before you start.
Does Frappe Lending replace a core banking platform?
Not for every lender. Frappe Lending covers loan origination, disbursement, repayment, collateral and accounting inside the ERPNext ecosystem, which suits many non-bank lenders and some lending teams inside larger organizations. A lender that needs deposits, savings, a full general ledger for a regulated bank, or high-volume real-time transaction processing may need a dedicated core banking platform. Apache Fineract is one open-source option built for that role, licensed under Apache-2.0. Compare the required functions and volumes against both options before choosing, and confirm the regulator's expectations for your license type.
What support is available after go-live?
Support after go-live can be run as a retainer or handled by your own team, and both need a clear written scope. Typical recurring work includes monitoring scheduled jobs such as interest accrual and repayment reminders, applying ERPNext and app upgrades, fixing defects, handling new product changes, reviewing accounting entries at period close and keeping backups tested. Ask what response channels and working hours are covered, how changes are approved, and who holds the source code and credentials. DeployOpen runs ongoing support, upgrades and continuous testing as retainers, so confirm the exact service levels in the agreement rather than assuming them.
How should we check our loan data before migration?
Start by agreeing what a correct migrated loan looks like: outstanding principal, accrued interest, next due date, schedule type, collateral link and the matching ledger balance. Then reconcile a sample of legacy loans by hand, load them into a test site, and compare balances line by line. Expect to repeat this several times before go-live. Keep the reconciliation report as evidence for your finance and audit teams, and confirm with the implementer how rejected records are logged and fixed. Large files should be loaded in batches, since the ERPNext Data Import documentation advises importing only a few thousand records at a time.
How DeployOpen scopes and delivers a Frappe Lending implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Frappe Lending on ERPNext, we start from your loan products, accounting rules and lending compliance obligations, then deliver the configuration, scripts and tested integrations in writing before go-live.
How we scope
- We agree a written scope covering your loan products, approval rules, disbursement and repayment flows, and collateral tracking needs.
- We map each loan event to the ERPNext journal entries, accounts and cost centers your finance team must review.
- We confirm which Frappe Lending features your version supports and list anything that needs custom work or confirmation.
How we build
- We configure loan products and repayment schedules in a non-production environment on the ERPNext version you have chosen.
- We build custom apps, scripts or integrations only where the standard app does not cover a documented requirement, and keep them upgradable.
- We test accounting postings, co-lending splits and loan transfers against agreed test cases before anything reaches production.
How we hand over
- We document configured products, accounting mappings, roles, permissions and every custom component so your team can maintain them.
- We run hands-on training for loan operations and finance staff on the workflows they will use after go-live.
- We deliver runbooks for deployment, backups and rollback so your team can operate the system without us on day one.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the implementation.
- We plan ERPNext and Frappe Lending upgrades against the supported versions list and test each step before applying it.
- We confirm with your compliance and audit teams which controls and evidence we can prepare, while independent auditors give the assurance.
