Skip to main content
Solutions · Dealer & channel payouts

Every dealer has their own deal. Run all of them as one system.

Two-wheeler, car and used-car lending lives or dies at the dealership counter. PayPrompt runs dealer-level payout structures, dealer-level targets, and pays fast enough that your file is the one they push.

The problem

Faster payout is more business.

A dealer working with four lenders routes the next file to the one that pays correctly and fastest. Four reasons that race is lost in a spreadsheet.

Payout speed is origination

Late or disputed payouts do not read as an ops problem at the counter. They read as a reason to route the next file to whoever pays faster. Lost origination, quietly, file by file, at counters you never see.

Every dealership negotiates its own deal

Per-dealer grids, subvention slabs, festive schemes. The policy fragments down to individual dealerships, and a spreadsheet holds that as forty tabs and one person who understands them.

One file's payout splits many ways

Dealer, sub-dealer, connector and the agents on the file each take a share, by different rules. The splits have to resolve per file, automatically, or the month ends in disputes.

The invoice holds up the money

The calculation finishes and the payment still waits: GST invoices arrive in every format, approvals queue on a desk, reconciliation is a person with two ledgers. The paperwork, not the math, sets your TAT.

Each of these is where dealer payouts stall. Everything below exists to make your payout the fastest and least disputed one on the dealer's desk.

How it works

Dealers and agents, one payout run.

One disbursal file in, every share of its payout computed in the same cycle.

Dealers, sub-dealers and connectors

Channel partners on their own commercial terms

  • Per-dealership grids, slabs and targets
  • GST invoice with TDS, generated or uploaded, auto-reconciled
  • Same-day invoice-to-payment

Agents and DSA teams

The people who move the file

  • Split schemes: one file's payout divided between dealership and agents by rule
  • By role, product and hierarchy
  • Live standing and earnings
One engine. The same outcome for both
Faster payout TATFewer payout queriesTransparency for every payeeAudit-ready records
What the dealer sees

Standing, earnings, and the next slab. At the counter.

  • Real-time standing against target, dealership by dealership
  • Earnings as they accrue, file by file, not a month-end surprise
  • Nudges tied to the payout math, so the message is money, not motivation posters
  • A dealer who can see the payout on the next file pushes your file first

Sample view. The dealer app: live standing, earnings file by file, and the next slab in sight.

What the ops desk gets back

A separate policy per dealership, without the tabs.

  • Every dealership can run its own scheme; the engine treats that as policy, not exceptions
  • A festive scheme ships mid-month; the old scheme stays honored and versioned
  • Retroactive changes recompute in the engine, not in a midnight rerun
  • Every dealer query answers itself from the calculation trail
  • The scheme logic survives a resignation
Rule builder · Dealership scheme
The invoice flow

From calculation to cash, without a paperwork queue.

The payout run ends with money moving, not a folder of PDFs. PayPrompt generates the dealer's GST invoice from a template, or takes the invoice the dealership uploads, and carries it through e-sign, approval and reconciliation in one flow.

End to end, the process runs itself: calculation, invoice, signature, approval, payment.

  • Invoice createdTemplated generation from the calculation, or the dealer's own GST invoice uploaded
  • E-signedBy the dealership, from the phone
  • Approved with OCR checksThe uploaded invoice read and matched against the calculation
  • ReconciledInvoice against calculation against payment, one ledger
What the product head sees

A payout that wins the counter.

T+4
Payout TAT, down from up to T+25 days
Same day
Invoice-to-payment, was 3 to 4 days
Before launch
Every new dealer scheme simulated on real data, so it doesn't blow the budget
What the CFO signs off on

Liability you can accrue. Controls you can show.

Accrual from the engine

Payout liability is a computed number at cycle close, not an estimate trued up on the P&L a quarter later.

One reconciliation, not three

Payout, TDS and GST reconcile inside the invoice flow, off the finance ops close calendar.

Clawbacks that follow the loan

Early default reverses the payout by rule, per the scheme version that paid it, with the trail intact.

Heard before every deployment

Fair objections. Straight answers.

"We run this on Excel with a capable ops team."

The team is capable. The tool is the risk: version chaos, retroactive reruns, logic that lives in one head. And Excel's real costs never hit a P&L line: leakage found late, supervisor hours on disputes, an audit trail that is a person.

"We tried a tool before. It died in UAT."

Tools die in UAT when policy is frozen at implementation and the edge cases get dodged during onboarding. We start with your ugliest scheme, configured by your own ops team in the first week, and the first cycle runs parallel to Excel: every mismatch is either our bug, fixed during the run, or an Excel error, logged.

"Every dealership has its own deal. No tool holds that."

That is the qualifying condition, not the objection. Bring your most negotiated dealership grid and the festive scheme you did not dare ship mid-season. In the demo, we configure the dealer and ship the scheme mid-cycle, and time both.

"Dealers will not use one more portal."

Dealers adopt money. Many never touch an invoice at all: the engine generates it from the calculation and sends it for e-sign on the phone. The ones who upload their own GST invoice get it read by OCR and matched automatically. The portal that pays same day is the one that gets used.

Before any commitment

The simulation: your last quarter, recomputed.

Bring one product line and one quarter of anonymized payout data. We run your schemes through the engine and hand back a discrepancy report: your policies recomputed line by line, the differences against what was actually paid, and your top scheme configured on screen.

If the engine cannot hold your schemes, you find out on your own data, before anyone signs anything. Ask for the simulation in the demo, or go straight to the POC: your policy running in 5 to 10 days.

  • Your schemes, recomputedLine by line, on the quarter you share
  • Discrepancies, listedAgainst what was actually paid
Tata Capital

Tata Capital runs sales and collections payouts on PayPrompt across DSAs, agencies and call centers, on one governed engine. Dealer payouts use the same policy engine, the same invoice flow and the same audit trail.

Read the case study
FAQ

Dealer payout questions, answered.

TAT, subvention, splits, GST invoices and clawbacks, in the vocabulary your channel team already uses.

What is payout TAT and what is normal for dealer payouts in vehicle lending?

Payout TAT is the number of days between cycle close and money landing with the dealer, written as T+n. In vehicle lending it commonly runs T+15 or later, and stretches up to T+25 where dealer invoices reconcile by hand. Payouts on PayPrompt land at T+4.

How are dealer payouts calculated?

Dealer payouts are calculated from disbursal data in your LOS and LMS. Each file is priced on the dealership's own grid by product, scheme and region, splits divide the payout between dealer, sub-dealer, connector and agents, caps and guarantees are enforced, and clawbacks follow the scheme version that paid the file. Every line carries its inputs and policy version.

Can every dealership have its own payout scheme?

Yes. Policy in PayPrompt scopes down to the individual dealership, so a dealer-specific grid or a one-dealer festive push is a scheme version, not a spreadsheet exception. Business teams ship the change in days, and the old scheme stays honored and versioned for the period it ran.

How are GST invoices from dealers handled?

Both directions work. PayPrompt generates a templated GST invoice from the calculation and sends it for e-sign, or the dealership uploads its own invoice and OCR-based checks read and match it against the calculation in approval. Invoice, calculation and payment reconcile in one flow, and invoice-to-payment runs same day.

Are dealer payouts clawed back on early default?

Yes, by rule. If a loan defaults early or cancels, the clawback reverses the payout per the scheme version that paid it, with the calculation trail intact. The reversal shows in the dealer's standing during the cycle, not as a surprise deduction at month-end.

If your dealer policies fill a spreadsheet with 40 tabs, that's a normal Tuesday for this engine.

A working POC on your own dealer structures, subvention slabs and data, typically inside 10 days.