DSA and partner payouts: how much do you owe each partner this month?
Trace each DSA payout to its loan, fee basis and rate. Reconcile partner invoices, distinguish approval from payment, and keep borrower charges separate.
Contents 7 sections
For an NBFC finance controller closing a book sourced through DSAs, the partner payout belongs beside the loan that earned it. Each payable should trace to an attributed loan, the fee basis and the rate in force. That is how you answer both month-end questions: how much is owed, and how much has been paid.
A partner total without that trail leaves a reconciliation and audit-evidence gap. Finance can make the sheet add up and still be unable to explain one line without finding the person who assembled it.
Since July, partner payout tracking has drawn a strong response in our lender conversations. The practical interest is straightforward: connect the partner invoice to the book finance already has to explain.
The payable starts with the loan
The useful record has a chain: loan, partner, applicable terms, fee calculation, invoice and payment. Our position is that the loan management system should preserve that connection, even when enterprise finance or a separate payout engine handles part of the process.
The rate alone is insufficient. A percentage needs a base. A fee needs an eligible period and an agreed trigger. A later change to the arrangement needs a clear effective date, so finance can distinguish the terms used for a past calculation from today’s rate card.
Consider an illustrative fee: ₹10 lakh of eligible principal at 1% produces ₹10,000 before tax or adjustments. The arithmetic is simple. The questions worth retaining are which loan supplied the principal, why it qualified, and which agreement made that rate applicable. These figures are a scenario, not a suggested market rate.
This is work for a deterministic core: explicit rules applied to recorded inputs. A reviewer should be able to reproduce the amount. The policy, the permitted exceptions and the decision to approve remain the lender’s.
Excel can work if the evidence survives
Finance already does this in Excel. A controlled sheet can work when its inputs, calculations and approvals are preserved and another person can reproduce the result.
That is the strongest argument for keeping it. A finance team with a stable arrangement and a documented process may gain little from moving the same calculation into another screen. The weakness appears when month-end requires fresh extracts, terms copied from email, and payment status checked somewhere else. Each cycle then rebuilds the evidence as well as the number.
An existing LMS may track the loan correctly while leaving the partner obligation outside its record. Both facts can be true. The relevant check is whether it can explain the fee owed to the partner who introduced that loan.
Our recommendation is to keep the fee trail close to the loan data and let finance own the approval. A separate payout engine can satisfy that principle if the interfaces and control totals reconcile. Software boundaries matter less than a trace that survives them.
The LSP fee is the lender’s obligation
For NBFC digital lending, the RBI’s Credit Facilities Directions, paragraph 10(4), require the NBFC to pay fees, charges and reimbursements owed to the Lending Service Provider (LSP) directly. The LSP must not separately charge or collect them from borrowers. Paragraph 6(7) retains the NBFC’s responsibility for the LSP’s acts and omissions.
The operating implication is to distinguish the partner payable from borrower dues. A fee linked to a loan for calculation and evidence does not become a charge on that borrower’s account.
DSA describes a sourcing role; LSP is a defined digital-lending role. Check the arrangement’s scope rather than applying the digital-lending provision to every relationship by label. The LOS, LMS and LSP guide explains the roles, and our RBI digital-lending article covers the wider requirements.
Approved and paid answer different questions
Lokta’s fictional demo makes the distinction visible. The sourcing-partner invoice register shows the cycle, amount, approval or payment status, and due date. An approved invoice can also carry an overdue marker. Approval has cleared the review; it has not, by itself, established payment.
The draft-invoice view shows the terms version, fee basis, rate and amount, with a drill-down to the loans behind a fee line. The issued invoice groups its statement by fee line. The payment record is a separate part of the invoice detail.
That gives the review a concrete basis: the calculation explains the amount, the approval records the decision, and payment evidence explains what left. The sourcing-partners product page describes the broader partner record.
The partner needs the same explanation
For the LSP raising an invoice, the question runs in the other direction: which work has the lender accepted, what was invoiced, and what remains unpaid? Files submitted, approval rate and first-time-right rate describe the sourcing relationship. They should not be mistaken for the amount earned under its commercial terms.
The useful conversation connects those measures with invoices raised and the agreed basis for the payable. An approval rate is a relationship measure; it does not establish a fee trigger on its own.
Servicing a book for partner lenders brings a wider set of responsibilities. Those sit with the LSP servicing workflow. This article’s narrower question is the evidence behind the partner invoice.
Test one cycle before changing systems
Start with a completed partner cycle. Have someone other than its preparer reproduce one fee from the loan and agreement, reconcile the invoice, and explain its approval and payment position. Include a changed rate or a disputed line if the cycle contains one. Record what needed a manual explanation.
You do not need to replace an LMS to run that check. Keep a controlled spreadsheet if the evidence holds; bring the partner record alongside the loan when repeated reconstruction is the problem; use a separate payout engine when its specialist requirements justify maintaining reconciled interfaces.
Moving the record can make the payable easier to inspect, but loan attribution, dated terms, opening balances and approval responsibilities still need to be agreed. The lender runs the book and owns those decisions.
Talk to us with one partner cycle and its invoice. Start with the line finance has to explain at month-end.
Frequently asked questions
How should an NBFC reconcile DSA and partner payouts?
Start with the loans attributed to the partner and the commercial terms that apply to each fee. Reproduce the calculation from its basis, rate and eligible period, then reconcile the resulting lines to the partner invoice. Track approval and payment separately, retaining evidence for adjustments and exceptions. This is a recommended operating control: a total that agrees with a spreadsheet still needs an explanation at loan level. The lender remains responsible for deciding what is payable.
Can a lender keep managing partner payouts in Excel?
Yes, if the lender can preserve the source loans, applicable terms, calculations, approvals and payment evidence and someone else can reproduce the result. The test is the quality of the record, rather than a particular number of loans or partners. A spreadsheet becomes a weak control when its owner must reconstruct the basis from emails or replace old rates to calculate a new cycle. Test a completed period before deciding to change systems.
Who pays an LSP's fees under RBI's digital lending rules?
For NBFC digital lending, paragraph 10(4) of the RBI's NBFC Credit Facilities Directions requires the NBFC to pay the LSP directly. The LSP must not separately charge or collect those fees, charges or reimbursements from borrowers. Keep the partner payable distinguishable from the borrower's loan dues. This is a rule for the digital-lending relationship; the label DSA alone does not establish that every sourcing arrangement has the same regulatory treatment.
Does an approved partner invoice mean the partner has been paid?
No. Approval records that the invoice has cleared the lender's review; payment needs its own evidence. Keep the approved amount, payment date, payment reference and remaining balance distinguishable. A due date answers another question: whether an unpaid amount is late under the agreed terms. Lokta's fictional demo shows approved and paid invoice statuses, with an overdue marker beside a due date. The sample demonstrates the view, without establishing a customer's payout performance.
Read next:
- Loan accounting entries for lenders: keep the loan event and its accounting treatment traceable.
- RBI digital lending requirements for NBFCs: the wider controls around the lender-LSP relationship.
- Loan reconciliation in an LMS: receipt matching and control totals for the borrower side of the book.
Sources:
- RBI, Non-Banking Financial Companies - Credit Facilities Directions, 2025, updated 15 July 2026: paragraphs 6(7) and 10(4).
- Product evidence: Lokta’s fictional demonstration tenant, inspected 7 October 2026. The figure is a cropped browser capture; it is not customer evidence.
Lokta editorial analysis by Chandramouli, co-founder and CEO.
