NirmaanOne Help
ConceptReviewed 2026-09-29

Payout runs: member benefits, commissions and refunds

A payout run pays everything due from one set of books in one batch: the transit rent, corpus and shifting rows of live member offers (accrued first, one payout per member), approved channel-partner commissions (one per partner) or the refunds of cancelled bookings; it is drafted, approved, exported as a bank file and cleared with the bank's UTRs.

Payout runs: member benefits, commissions and refunds

A payout run is one batch of money going out of one set of books. Instead of recording a payout to each society member or channel partner by hand, you tell the app "pay everything of this kind that is due on or before this date", and it drafts one pending payout per payee, waits for a Finance Lead to approve the batch, gives you a bank file to upload to net banking, and then posts every payout to the ledger once you type in the bank's UTRs.

How it works in NirmaanOne

The three kinds

Every run has one Kind, chosen in the New payout run dialog on Payout runs:

Kind Who is paid What for
Member Benefits Society members (tenants) with a live offer The benefit rows of their offers (transit rent, corpus, shifting and any other benefit we pay) that are still open and fall due on or before the run's Pay everything due on or before date. One payout per member, one allocation per row.
Commissions Channel partners (companies, or people) Commissions in the books that are Approved or Partially Paid and still have something outstanding. One payout per partner, one allocation per commission.
Refunds Buyers of cancelled bookings The pending payouts with the purpose "Refund" that the Cancel booking wizard created and no run has picked up yet. The run adopts them as they are.

A live member offer means one whose status is Issued, Accepted or Signed. Only rows with an amount above zero, a due date, and status Pending or Partially Paid are due; the run pays the row's unpaid remainder. Money already earmarked by another Pending payout is left out, so two runs cannot pay the same row twice.

A run belongs to one set of books and, optionally, one project of that books' promoter. The payee's bank account is their primary active account, or any active account when none is marked primary.

Drafting

Draft <n> payouts creates the run as Draft with a number PR-<financial year>-<serial> (one series per organization, the financial year taken from the Payment date). For each payee:

  • If the run's Mode is anything other than Cash or Cheque and the payee has no active bank account on file, the payee is skipped with "The payee has no active bank account on file" and listed under Skipped payees. The dialog warns you beforehand, for example "2 payees have no active bank account on file and will be skipped for a NEFT run."
  • Otherwise the payout is drafted. Each payee is handled on its own, so one failure (for example a benefit component with no ledger mapping) skips that payee with the error's text and the rest of the run still drafts.

For Member Benefits the draft does one more thing: it accrues the due rows first. Until a run is drafted nothing about a benefit is in the ledger. For each member and offer, the run posts one Journal dated the run's as-of date:

  • Debit the expense ledger the benefit component is mapped to (5100 Displacement Rent Expense for transit rent, 5110 Corpus Expense, 5120 Transport Compensation - Tenants in the seeded chart), tagged with the mapping's cost centre or else the project's cost centre;
  • Credit the member's party ledger, opening one bill per row, numbered <component code>/<row number>/<offer> and due on the row's own due date.

A row is accrued only once. A row that was partly paid by hand accrues its unpaid remainder. If a later run's payout bounces or is cancelled, the bill stays open and the next run pays it again without a second accrual. The run then drafts one Pending payout per member with the purpose "Member benefits", the narration "Benefits due as of <date> (<run no>)", and one allocation per row.

Commissions runs draft one Pending payout per partner (purpose "Commission") and need no accrual, because approving a commission already posted its Journal and opened the partner's bill. Refunds runs simply attach the pending refund payouts to the run; they keep the mode, paying account and date the cancellation wizard gave them.

Approve, bank file, clear

  1. Approve needs the Approve permission on Payments (the Administrator and Finance Lead roles by default) and at least one Pending payout. The run becomes Approved. The Accountant role can draft and clear runs but not approve them; the run page tells such a user that a Finance Lead approves the run before the bank file is exported.
  2. Bank file (CSV) downloads a file named after the run number with one row per payout that is not cancelled: payment number, payee (the account holder's name when a bank account is on file), bank, account number, IFSC, the net amount, mode, narration (cut to 100 characters), UTR and status. Upload it to net banking outside the app.
  3. Clear <n> payouts (the Edit permission on Payments) takes a Cleared on date and an optional UTR per payout (stored in upper case). Each payout posts its Payment voucher: debit the member's or partner's ledger, settling the bills the allocations name, and credit the bank ledger of the paying account (or 1000 Cash in Hand when the run pays from cash). Each payout posts on its own; one that fails is reported under "<n> payouts failed on the last attempt" with its message, and the others still clear. The run turns Cleared once no Pending payout is left. Fix the cause (a missing bank ledger, a locked period, inactive books) and clear again; payouts already posted are not touched.

Cancel run works on a Draft or Approved run with no cleared payout. A Member Benefits or Commissions run cancels its pending payouts; a Refunds run only detaches the refunds, which stay pending for a later run. A run with any cleared payout cannot be cancelled ("Some payouts of this run are already cleared; bounce them individually instead."): open that payout and Bounce it.

Why it is built this way

  • Accrual before payment makes member benefits behave like any other payable: the expense is recognised when the run recognises the row as due, the member's ledger shows a bill per installment, and the Ageing and Outstanding bills reports age what you owe each member exactly as they age what buyers owe you.
  • One payout per payee matches how the bank transfer is made and how the UTR comes back.
  • Approval in the middle separates the person who prepares the batch from the person who releases the money.
  • Payees without a bank account are skipped rather than failing the run, so a NEFT run for eighty members is not held up by the two whose accounts are missing.

Automatic runs

Rules with a schedule can draft runs on a cadence; the Automatic payout runs card on the runs page lists them, and Schedule automatic payout runs opens the rule builder with the payout-run preset. The seeded rule "Daily payout runs (system)" ships switched off; it drafts benefits, commissions and refunds at 09:00 and leaves approval to a person unless the rule's approve option is on and its owner holds the Approve permission.

Example

Shree Siddhi Developers keeps the books "Shree Siddhi Developers" and is redeveloping Shree Ganesh CHS as the project Sai Darshan. Two members have live offers:

  • Sunita Patil (Member 12): transit rent ₹42,000 a month from 1 July 2026 (rows due 1 July, 1 August, 1 September, …), shifting charges ₹25,000 due 1 July 2026, corpus ₹3,00,000 due 1 October 2026. Her primary bank account is on file.
  • Ramesh Jadhav (Member 7): the same benefits. He has no bank account recorded.

On 30 September 2026 the accountant opens Payout runs, presses New payout run, keeps the kind Member Benefits, picks the books, sets Pay everything due on or before and Payment date to 30 September 2026, mode NEFT, and From our account HDFC Bank ····0217. The preview shows 2 payees and a total of ₹3,02,000, with the warning "1 payee has no active bank account on file and will be skipped for a NEFT run." The corpus rows are not listed: they fall due after the as-of date.

Draft 2 payouts creates run PR-2026-27-00004:

  1. For Sunita Patil the run posts the accrual Journal JV-0088 dated 30 September 2026:

    • Dr 5100 Displacement Rent Expense ₹42,000.00 (cost centre P001, Sai Darshan), narration "Transit Rent installment 1"; the same for installments 2 and 3;
    • Dr 5120 Transport Compensation - Tenants ₹25,000.00, "Shifting Charges installment 1";
    • Cr TEN-00012 Sunita Patil (Member 12) ₹1,51,000.00 (Rent 3 × 42,000 + shifting 25,000), opening four bills on her ledger: RENT/1/3f9a12c4 due 1 July, RENT/2/3f9a12c4 due 1 August, RENT/3/3f9a12c4 due 1 September and SHIFTING/1/3f9a12c4 due 1 July (RENT and SHIFTING are the seeded codes of the Transit Rent and Shifting Charges components; the last part of each bill number identifies her offer).

    Then it drafts payout PMT-2026-27-00031 for ₹1,51,000.00, Pending, with four allocations of ₹42,000.00, ₹42,000.00, ₹42,000.00 and ₹25,000.00.

  2. Ramesh Jadhav is skipped: "The payee has no active bank account on file." Nothing is accrued for him.

The run shows 1 payout, ₹1,51,000.00 net, 1 skipped payee, and the toast reads "Run PR-2026-27-00004 drafted with 1 payout." The Finance Lead presses Approve, the accountant downloads Bank file (CSV) (one row: PMT-2026-27-00031, Sunita Patil, HDFC Bank, her account number and IFSC, 151000.00, NEFT, "Benefits due as of 2026-09-30 (PR-2026-27-00004)"), uploads it, and after the transfer presses Clear 1 payout with the UTR the bank returned. Payment voucher PAY-0042 posts:

  • Dr TEN-00012 Sunita Patil (Member 12) ₹1,51,000.00, settling the four bills;
  • Cr the bank ledger of HDFC Bank ····0217 ₹1,51,000.00.

The four schedule rows on her offer turn Paid and the run is Cleared. The rehab officer records Ramesh Jadhav's bank account, and the next run (say as of 31 October) pays him his four open rows plus the October rent, and pays Sunita Patil her corpus of ₹3,00,000 and October rent of ₹42,000 in one payout of ₹3,42,000.00.

A Commissions run works the same way without the accrual. Prime Realty holds two approved commissions: 2% on a ₹1,20,00,000 booking (gross ₹2,40,000.00, GST 18% ₹43,200.00, TDS 194H 2% ₹4,800.00, net ₹2,78,400.00) and 2% on a ₹60,00,000 booking (net ₹1,39,200.00). One payout of ₹4,17,600.00 is drafted with two allocations; clearing it debits CP-00003 Prime Realty against both commission bills and credits the bank.

Where you see it

Related

  • Payout runsScreen

    Every payout run of the chosen books, the dialog that drafts a new run of member benefits, commissions or refunds, and the scheduled rules that draft runs automatically.

  • Payout runScreen

    One payout run: its payouts, skipped payees and failures, and the steps to approve it, export the bank file, clear it with the bank's UTRs or cancel it.

  • PaymentScreen

    One receipt or payout: its details, amounts and allocations, and the actions to clear it, bounce it, cancel it, edit it or delete it.

  • PaymentsScreen

    Every receipt and payout of the chosen books, with filters and search, and the buttons to record a receipt, record a payout or open the payout runs, the RERA sweeps, the TDS credits and the escrow withdrawals.

  • Record receipt / Record payoutScreen

    Record money received from a buyer or society member, or paid to a channel partner or society member: who, how and how much. A receipt settles the payer's open demands by itself, oldest due first; a payout is allocated to commissions or benefit rows by hand. A buyer's consideration and GST are two separate receipts; the TDS they deducted is a TDS credit.

  • CommissionScreen

    One channel-partner commission: the partner, the brokerage with GST and TDS, the payouts against it, and the actions to edit, approve, cancel or delete it.

  • CommissionsScreen

    Every channel-partner commission accrued on bookings, with filters for status, payable state, project and books, and a shortcut to open each one.

  • Component mappingsScreen

    Which ledger each charge component posts to in the chosen set of books (a main ledger, an optional second tax ledger, an optional cost centre and, for sale and tenant charges, the revenue treatment and contract liability ledger), and the action to copy template additions into the books.

  • Outstanding billsScreen

    The bills on bill-wise ledgers of the chosen books: what each bill was for, how much has been settled, what is still outstanding and how overdue it is.

  • AgeingScreen

    What each party owes you (receivables) or you owe each party (payables), split by how overdue the open bills are, with CSV export.

  • VoucherScreen

    One voucher with its lines and bill allocations, its reversal links, its history, and the actions to post, reverse, cancel or delete it.

  • Tenant BenefitsScreen

    Keep ready-made benefit plans (corpus, transit rent, shifting…) that a rehab officer applies to an allottee's offer in one go.

  • AllotteeScreen

    One society member, landowner or PAP tenant on a page: who they are, what they hold today, their co-owners, their offers on each project, the letters and files filed for them, their bank accounts and parking.

  • Cancel bookingScreen

    The four-step wizard that cancels a booking: it shows the demands and receipts that will be reversed, suggests the forfeiture and charges from the rule in force, sets the refund and posts everything in one go, releasing the unit and parking and marking the opportunity lost.

  • RulesScreen

    Every automation rule in your organization, system and custom, with filters, the switch that turns each rule on or off, and shortcuts to edit, test, clone, see the run history of or delete a rule.

  • Bank accountsScreen

    One register of every bank account you pay from or into: the promoter's collection, RERA separate, operative, GST and operating accounts, and the payout accounts of channel partners, vendors, buyers and society members, with joint holders and verification.

  • Benefit plans and benefit accrualConcept

    A benefit plan is a project's ready-made list of what the developer pays an allottee (corpus, transit rent, shifting), applied to a draft offer in one go; benefit accrual is how a Member Benefits payout run books each due installment as an expense and a bill on the member's ledger before paying it.

  • Channel partner commissionsConcept

    Brokerage owed to the channel partner who sourced a booking: accrued from the booking with a basis percent or a gross amount, GST and TDS under 194H, approved to post the accrual journal, and paid out singly or through a Commissions payout run.

  • Receipts and payouts: allocation, clearing and the UTRConcept

    A receipt is recorded as Pending and settles the payer's open demands by itself, oldest due first; a payout is allocated to commissions or member rows by hand. Both post their voucher only when cleared and can be bounced afterwards; the UTR is the bank's transfer reference, typed on NEFT-style payments and per payout when a payout run is cleared.

  • Component mappings: which ledgers a charge posts toConcept

    A component mapping tells one set of books where a charge component posts: a main ledger, an optional second tax ledger, an optional cost centre and, for sale and tenant charges, the revenue treatment; demands, commissions, benefit accruals, payouts and cancellations all read it, and an unmapped component stops the posting.

  • Party ledgers, bill-wise tracking and ageingConcept

    A party ledger is the bill-wise ledger a set of books keeps for one buyer, society member, channel partner or vendor, created on first use with a generated code; every posting on it is allocated as New Ref (opens a bill), Against Ref (settles one), Advance or On Account, so the books know what each bill still owes and how overdue it is.

  • Bank accounts, purposes and bank ledgersConcept

    One register of every bank account you pay from or into: who owns an account, what its purpose tag means, why the collection, RERA separate, operative and GST purposes belong to the promoter, what the primary account and the IFSC are for, and how a bank ledger is created in the books.

  • Booking cancellation, forfeiture and refundConcept

    Cancelling a booking reverses its demands with credit notes, posts the forfeiture and any charges against the buyer's ledger by the rule in force, creates the refund as a pending payout for the credit that is left, and frees the unit and parking; with nothing billed or received it only frees them.

  • Books, the active books switcher and cost centresConcept

    A set of books is the ledger of one promoter company: every posting for a project lands in its promoter's books, every accounting screen works on the one set chosen in the Books switcher, and cost centres inside the books (usually one per project with a child per tower) let the ledger and reports be cut by project.