Caps, splits and shortfalls: multi-payer billing done properly

In subsidised residential portfolios, the question "who pays the rent?" rarely has one answer. A student's bed might be funded by NSFAS up to a capped amount, with the balance billed to a bursary or a parent. A senior living unit might split across the resident, their family and a subsidy programme. Corporate housing splits between employer and employee. The lease is single; the money is plural.

Generic invoicing systems assume one debtor per invoice. Operators bend them with manual credit notes, duplicate "shadow" accounts and side spreadsheets - and every month, reconciliation eats days and still leaks. The leak is not small: mis-billed funder claims go unpaid, shortfalls surface months late, and arrears reports chase the wrong people for the wrong amounts.

A real multi-payer engine treats the payer mix as data on the lease: each payer with a share, a priority, and - for subsidised funders - a cap and a cap basis. The billing run then does the arithmetic every period, without a human in the loop.

Make it concrete. A bed rents for R5,400 a month. NSFAS funds the student up to a monthly accommodation cap of, say, R4,800. A bursary agreement covers half of anything the funder does not. The parent, who signed surety, carries the rest. A correct billing run produces three artefacts from one charge: a funder line of R4,800 against the NSFAS account, a bursary invoice of R300, and a parent invoice of R300 - each labelled, each on the right account, each traceable back to the same underlying charge.

Priorities matter as much as shares. The capped funder bills first; the cascade covers the remainder in a defined order. When the inputs change - the cap moves, the bursary lapses, the funding confirmation arrives late - the engine must re-derive the split for affected periods and issue the delta as a correcting document, not force a manual rebill that breaks the audit trail.

Shortfall handling is the part that separates toy implementations from real ones. Funding in this sector is confirmed late and revised often. Registrations lapse mid-term; caps change between academic years; a funder decision arrives in May covering February. An engine that can only bill forward from today is useless here. It has to recompute the past honestly - original document, adjustment, net position - so that every account tells the true story at any point in time.

Billing correctly is half the job. Funders pay in bulk: one remittance covering thousands of beds, rarely matching expectations line for line. Somewhere in that payment, three students' funding was reduced, five were not on the schedule at all, and two were paid at last year's cap. The month is only closed when that file is imported, matched against expected billing per bed, and every difference is an explicit record with an owner.

That means three first-class outcomes per line: matched, short, or over. Shortfalls flow into the cascade - billed on to the next payer or flagged for dispute with the funder. Overpayments sit visibly on account rather than vanishing into suspense. Disputes carry their history, because the query you raise with a funder in August will be answered with reference to how February was billed.

Do this with highlighted cells in a workbook and the numbers are stale before the meeting ends. Do it in the ledger, and funder ageing becomes a report you can trust - and the collections conversation with the funder becomes specific: these beds, these periods, this difference.

Splits only matter if collections respect them. Each payer pays on their own rails: a funder by bulk EFT against a remittance schedule, a parent by debit order or instant EFT, a bursary by monthly transfer with its own reference format. The engine has to issue payer-specific references, match inbound receipts to the right payer account automatically, and hold the exceptions - not the whole bank statement - for a human.

Unallocated receipts are the tell. In a portfolio doing this properly, the unallocated balance at month-end is a short list with names on it. In a portfolio doing it in spreadsheets, it is a number nobody can explain, quietly absorbing both real arrears and real payments. If you want a one-line health check of any operator's billing setup, ask for their unallocated receipts figure and watch how long the answer takes.

A few less obvious requirements separate systems that survive contact with a real portfolio from those that do not. Proration: mid-month move-ins and cancellations must split correctly across every payer, not just the primary. Deposits: in a multi-payer world the deposit is often paid by a different party than the rent, and the refund at lease-end must find its way back to whoever actually paid it. Statements: each payer sees their own account - a parent should never see the funder's side, a funder never the parent's - yet the operator sees the consolidated truth.

And credit control has to be payer-aware. Chasing a student for a funder's shortfall poisons the relationship and collects nothing. Dunning journeys should route by payer type: a courteous reminder to a parent, a reconciliation query to a funder, an internal flag when the mix itself looks wrong.

This is why we say Atrium is "built to pay the rent". Multi-payer billing is not a feature bolted onto an invoicing module; it is the shape of the ledger itself - shares, priorities, caps, cascades, corrections and reconciliation as first-class citizens. Collections is not a line on the pricing page. It is the loop the whole data model is designed around.