NirmaanOne Help
ConceptReviewed 2026-09-29

Party ledgers, bill-wise tracking and ageing

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.

Party ledgers, bill-wise tracking and ageing

A party ledger is the account a set of books keeps for one outside party: a buyer, a society member, a channel partner or a vendor. It is bill-wise, which means the ledger does not just hold a balance; it holds a list of bills, each opened by one voucher and settled by later ones, so you can always say which demand a receipt paid and which commission is still owed. Ageing groups the open bills by how far past their due date they are.

How it works in NirmaanOne

How a party ledger comes to exist

Nobody has to create party ledgers in advance. The first posting that involves a party in a set of books creates its ledger there: issuing a demand, recording a receipt or payout, accruing a benefit, approving a commission. You can also create one ahead of time with Party ledger on Ledgers ("Finds the party's ledger in these books or creates it…"). The ledger is named after the party (a member as "<name> (Member <no>)"), is bill-wise, and gets a generated code:

Party Code Group
Person (a buyer, contact) CUST-nnnnn Receivable
Society member (tenant) TEN-nnnnn Compensation
Company (channel partner) CP-nnnnn Payable
Company whose type is Vendor or Contractor VEN-nnnnn Payable

Numbers run from the highest used plus one, per prefix, per set of books. A ledger links to exactly one party and the link cannot be changed later (the Party field's hint: "A party ledger is settled bill by bill and cannot be re-linked later."; trying anyway gives "The party link of a ledger cannot be changed once set."). The same person has a separate ledger in each promoter's books.

Bills and allocations

On a bill-wise ledger every voucher line must be fully allocated; posting refuses otherwise ("Line <n> (<code>) is bill-wise: allocations <x> must equal the line amount <y>"). An allocation is one of four kinds:

  • New Ref opens a bill: number (typed, or the voucher number), the voucher date, a due date, the amount, and the side (Dr when the party owes us, Cr when we owe the party).
  • Against Ref settles an existing bill on the opposite side. It cannot exceed what the bill still has outstanding ("Bill <no> has <x> outstanding, allocation is <y>").
  • Advance: money received or paid before any bill exists.
  • On Account: left unallocated, to be settled against bills later.

A bill's outstanding = its original amount − Against Ref allocations on the settling side from posted vouchers (+ any on the same side, which is how a reversal or a bounce reopens a bill). It is Settled when the outstanding reaches zero and open again if a reversal pushes it back up. Advances and On Account amounts carry no bill, so they sit on the ledger's balance but never appear as bills.

The system postings do all this for you:

  • Demand issue debits the buyer's or member's ledger with a New Ref bill numbered like the demand and due on its due date. Clearing a receipt credits the ledger Against Ref on the bills of the demands it is allocated to; anything left is an Advance.
  • Commission approval credits the partner's ledger with a New Ref bill COMM-<booking no> (with -2, -3 … added for a second or third commission on the same booking). Benefit accrual credits the member's ledger with one New Ref bill per benefit row. Clearing a payout debits the ledger Against Ref on those bills; the rest settles the party's open credit bills (a cancelled booking's credit note) and then goes On Account.
  • Cancellation and bounce reverse or reopen bills the same way.

On a manual voucher you pick the allocations yourself with + New Ref, + Against Ref (choosing from "Open bills of this ledger"), + Advance and + On Account.

Ageing

Outstanding bills lists every open bill with its original, settled and outstanding amounts, its due date and a bucket. The Ageing report adds them up per party ledger, on one side at a time (Receivables, what parties owe us, or Payables, what we owe them), as of a date:

  • days overdue = as-of date − due date, when the bill is outstanding and past due;
  • bucket Not due (not yet past due, or no due date), 1–30 days, 31–60 days, 61–90 days, Over 90 days;
  • one row per party, largest total first, with the count of bills and the oldest due date.

The As of date moves bills between buckets and leaves out bills dated after it, but the outstanding is always today's figure: settlements posted after the as-of date are already counted.

Balance sheet presentation

A buyer's ledger whose overall balance is in credit (money received ahead of billing) is shown on the Balance sheet under 2120 Advances from Customers - Unapplied rather than netted against receivables. The test is the ledger's balance, not its bills: an advance on a ledger that is still in debit overall simply reduces that debit.

Why bill-wise

A developer collects one flat's price in twenty installments over three years and pays a member's transit rent for thirty months. Without bills, a ledger balance of ₹8,28,320 says nothing about which demand is unpaid or how late it is. With bills, the ageing report shows exactly which installments to chase, a bounced cheque reopens exactly the bill it had settled, and the member's ledger reconciles row by row with their offer.

Example

Anil Deshmukh books unit A-1203 on Sai Darshan. He has no ledger in "Shree Siddhi Developers" until demand DM-2026-27-00087 is issued on 28 September 2026: the issue creates CUST-00023 Anil Deshmukh under Receivable, bill-wise, and its Sales voucher debits it ₹18,28,320.00 as New Ref bill DM-2026-27-00087, due 15 October 2026 (Dr side: he owes us).

  • 20 October: receipt RCT-2026-27-00012 of ₹10,00,000.00 is allocated to the demand and cleared. The Receipt voucher credits CUST-00023 ₹10,00,000.00 Against Ref DM-2026-27-00087. Outstanding = 18,28,320 − 10,00,000 = ₹8,28,320.00; the demand is Partially Paid.
  • 15 November: demand DM-2026-27-00102 for ₹9,14,160.00 is issued, due 15 December 2026.
  • 25 November: he pays ₹2,00,000.00 "for the next installment" with no demand named. The receipt's allocations are empty, so the voucher credits CUST-00023 ₹2,00,000.00 as an Advance. It reduces his ledger balance but opens no bill and settles none.

Ageing (Receivables) as of 30 November 2026 shows one row, "Anil Deshmukh · CUST-00023 · oldest due 15 Oct 2026": DM-2026-27-00087 is 46 days overdue → 31–60 days ₹8,28,320.00; DM-2026-27-00102 is not yet due → Not due ₹9,14,160.00; Total ₹17,42,480.00, 2 bills. The ₹2,00,000 advance is not there; the ledger report shows the balance as 17,42,480 − 2,00,000 = ₹15,42,480.00 Dr, and that is the figure his ledger contributes to receivables on the balance sheet. Nothing moves to 2120, because his ledger is still in debit overall; only if his advances exceeded his open bills would the credit balance be shown there.

On 3 December the bank returns the October cheque. Bounce on RCT-2026-27-00012 posts a reversal whose line debits CUST-00023 ₹10,00,000.00 Against Ref on the same bill; being on the bill's own side it adds back, and DM-2026-27-00087 shows ₹18,28,320.00 outstanding again, now 49 days overdue.

On the payable side, Sunita Patil's ledger TEN-00012 Sunita Patil (Member 12) was opened by a payout run's accrual with four Cr bills (RENT/1/…, RENT/2/…, RENT/3/…, SHIFTING/1/…) due in July, August and September, all dated 30 September (the run's as-of date). Ageing (Payables) as of 30 September shows ₹1,51,000.00: the two bills due 1 July (₹42,000 + ₹25,000, 91 days overdue) under Over 90 days ₹67,000.00, the August rent (60 days) under 31–60 days ₹42,000.00 and the September rent (29 days) under 1–30 days ₹42,000.00. The run's payout, once cleared, debits the ledger Against Ref on all four and the row disappears.

Where you see it

Related

  • LedgersScreen

    Every ledger of the chosen set of books, as a grouped tree or a flat list, with the actions to add ledgers and party ledgers, edit or retire them, and open a ledger's report.

  • 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.

  • Ledger reportScreen

    The ledger of one account between two dates: opening balance, every posting with a running balance, and closing balance, 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.

  • New voucherScreen

    Enter a manual voucher (receipt, payment, journal, contra, sales, purchase, credit note or debit note) with its lines and bill allocations, and save it as a draft or post it straight away.

  • DemandScreen

    One demand: the installments it bills, its amounts with GST, the expected TDS and what is payable in money, the receipts and TDS credits against it and how the money is placed on the charges, with the actions to edit, issue, cancel or delete 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.

  • 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.

  • 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.

  • Balance sheetScreen

    Assets against liabilities and equity as of a date, with the year's profit to date carried into equity and a check that the two sides agree.

  • 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.

  • Vouchers, reversals and system vouchersConcept

    A voucher is the only way an amount enters the ledger: a dated header with balanced debit and credit lines, editable as a Draft, numbered and frozen when posted, corrected only by a mirrored reversal; demands, payments, commissions, benefit accruals, cancellations, revenue runs and the year-end close post their own system vouchers the same way.

  • The chart of accounts: templates, books copies, nature and system rowsConcept

    The organization keeps one master chart (group templates, ledger templates and default mappings) and every set of books holds its own copy of it; each group carries a nature (asset, liability, equity, income, expense) and a Direct flag that feeds gross profit, a few system rows are locked, codes are never reused, and the Consolidated report adds the books up by the template each ledger came from.

  • 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.

  • Demands, demand runs and the GST splitConcept

    A demand is the bill raised on a buyer's installments (or a member's offer charges): numbered by financial year, billing the full total with the buyer's expected 194-IA TDS shown apart, posted as a sales voucher with GST split as CGST + SGST or IGST by place of supply; a demand run raises one demand per buyer for everything due by a date.

  • Payout runs: member benefits, commissions and refundsConcept

    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.

  • Manual appropriation of receiptsConcept

    A receipt settles a demand as a whole; which charges the money was for is decided by you, on the demand, in any split up to each line's billed amount and up to what was received, and that split is what marks the payment schedule's rows paid.

  • Contacts, companies and company typesConcept

    A contact is a person; a company is a legal entity with people attached. The company type decides which registrations the form asks for (promoter, channel partner, vendor, contractor), and a channel partner's default commission feeds the commissions on the bookings it brings.