Rent becomes an invoice raised on a date against a named arrangement, so the recurring charge stops being the exception that gets handled by hand every month.
Property Management
Property managers and letting agents who collect rent on a fixed date, raise a chargeable repair against the same tenancy that already has a lease on it, and who are used to a tenant, a property, and a landlord being three things that the system insists are one.
The problem
Rent behaves nothing like the rest of this site's trades. Nothing has to happen for an invoice to be correct: the date arrives, the rent is due, and the work being billed is the absence of a problem for a month. Billing software is built around work delivered, so the recurring charge is either handled as an exception every month or quietly skipped in the months when nobody had a reason to think about it, and the collection rate becomes a mystery that gets explained away. The second problem is object confusion, and it is older and worse than the billing one. A property is not a tenant. A tenancy is neither of them, it is the relationship between one and the other, and it has a start, a term, a deposit, a notice period, and an exit — none of which belong to either side. So the same address appears as a customer several times, the same person appears against several addresses, and a duplicate created in a hurry at a move-in becomes a rent reminder sent to the wrong person and a repair billed to the wrong tenancy. Most software solves this by merging automatically, which converts a data problem into a tenancy dispute. The third thing is repairs, which are not one problem but three: the work itself, whether the cost lands on the landlord or the tenant, and whether the tenant will pay a bill for something that happened to them rather than for something they asked for. Only the second and third are commercial records, and only the third is quotable.
A working day
The day starts with the date, not with a request. Rent is due and an invoice goes out whether the property had a peaceful month or not, and the interesting case is the month it did not, because that is when the collection call happens and the conversation is about something that already happened and cannot be un-incurred. Then somebody reports a leak and the job splits in two immediately: the work, and the argument about who pays for it. A repair already invoiced and found to be faulty is a credit note against a record. The same repair before anything is invoiced is a new quote on the same tenancy, priced on the spot by a person standing in a kitchen. Neither is a change request, because there is no change-request record in this product and there is no tenancy record either — the tenancy is a project with the parties named on it, and it is the arrangement, not a stored legal object with rent running through it. Somewhere two records for the same address are about to be created a third time, because that is what happens at every move-in, and nothing in the platform will merge them for the manager: detection flags the candidates and a person decides. At the end of the month the arrears list is either a queue with a written rule behind it or a list someone sorted by shouting.
How NoxOrigin fits this business
Every business runs the same sequence, from first contact to money in. NoxOrigin keeps each step tied to the last: Customer → Opportunity → Quote → Project → Work → Invoice → Payment.
The steps are the same. What changes is the words you use for them, the pressure at each one, and who is responsible for it. This is how it reads for property management.
The property, the person, and the arrangement
Customer → Opportunity
Three objects where most systems hold one. A prospective tenant or an incoming owner is a customer with an owner and a next action; a vacant property is a project waiting for an occupancy decision; and the arrangement between them is carried as the project itself, because there is no tenancy record in NoxOrigin and no rent ledger running through one. Holding the parties as customers and naming the property on the record keeps the confusion visible instead of resolving it silently, which is the honest alternative to a system that guesses which of the two a row refers to.
Deposit, terms, and move-in
Quote
The commercial terms of an occupancy as a priced proposal: the rent, the deposit, the notice period, what the rent covers and what it does not, and what a key handover triggers. It is a quote, so there is no contract editor and no e-signature, and the lease and the deposit receipt remain the manager's own documents. A change of rent, a change of terms, or a mid-term variation is a new quote on the same arrangement with its own price, which is what keeps a rent revision from appearing as a number that changed with no reason attached to it.
The occupancy as the live record
Project
From move-in to exit, the record carries who is there, what was agreed, what has been raised, and what is outstanding. It is not a tenancy system: there is no tenancy record, no rent ledger, and no due-date scheduler, so the date on which rent is expected is a date a person holds and raises an invoice against. It also has no maintenance scheduling, so nothing here books a contractor or sequences a repair — the diary that does that is the manager's other problem, and the record that a chargeable repair was needed is what belongs here.
Repairs and maintenance
Work
The work record is the job: what was found, what was done, and what it came to, attached to the occupancy, so a year of maintenance on one property reads as a list with values rather than as a drawer of invoices. There is no timesheet record and no payroll, so labour time is not captured and the figure on the record is the figure somebody agreed. When the cost is the tenant's to bear rather than the landlord's, that is not a note on the work — it is a second quote on the same occupancy, priced and accepted, which is the distinction that keeps a repair from turning into a disputed line item at the end of the month.
Rent invoices and the deposit
Invoice
Raised on the date, whether or not anything happened, which is the opposite of every other trade here: there is no work behind the invoice, and that is the point. Rent due, a deposit held, a repair chargeable to the tenant, a credit for something that was billed in error — all of them raised against the same occupancy with their own lines. Invoice and payment are two different records, and the manager who is owed money is looking at the difference between them, not at a tenant flagged as paid.
Payment, arrears, and the notice conversation
Payment
Rent arrives late, in parts, or as a promise with a date on it, and the deposit sits against the last month rather than in the account. A payment promise is a dated commitment recorded as its own thing, not a paid flag closed early. This is not a recovery engine: it is a prioritised list of what is outstanding with a rule the manager set behind the order, and the escalation from a reminder to a notice to losing the occupancy stays a human decision with legal weight attached, which is not something software should be doing quietly on a schedule.
The portfolio, and what was never charged
Reports
Rent due against rent collected by property and by month, so a collection problem shows up as a pattern by month rather than as a feeling at the end of a quarter, and a property that is always late is visible next to one that is always on time. The other half is the repairs that were chargeable and were never quoted, which is money the manager gave away by not pricing it at the time — and the honest limitation is that expenses are not tracked in the platform, since expenses are a Nox-Billings capability and purchasing sits in Commerce, so the manager's cost side is assembled from elsewhere.
What changes
What is different by next week.
A repair that is the tenant's cost becomes a second quote on the same occupancy, priced before the work is invoiced, instead of a line on the next bill that nobody agreed to.
Arrears become a prioritised outstanding list with a promised date on each item, so the queue is decided by a written rule rather than by who spoke to the tenant last.
A duplicate address or a duplicate person is flagged as a candidate for a person to review, with the dangerous pairs held as exceptions, because nothing in the platform merges a record on its own.
A rent revision or a mid-term variation becomes a new quote on the same occupancy, so a changed number always has a stated reason attached to it.
Who does what
Different people need different parts of the same information.
Everyone is looking at the same information. What changes is which part of it they are responsible for.
- Property managerHolds the occupancy, decides what a repair costs and who bears it, and works the arrears queue, which is the job that quietly decides whether the month ends well.
- Leasing and move-inTurns an enquiry into an occupancy, sets the terms and the deposit, and is the person who creates records at speed when there is a key to hand over.
- AccountsRaises the rent invoices on the date, records what came in including part payments and promises, and raises the credit note when a charge was wrong.
- Owner or principalSees the portfolio as due against collected, decides on the legal escalation when a tenant stops paying, and owns the repairs that were absorbed.
What software should not decide
NoxOrigin keeps the facts. You still make the decisions.
Keeping the facts in one place ends the argument about what happened. It does not make the decisions that were always yours to make.
- Whether to chase a tenant for the full rent on day one, or wait. Chasing early is defensible and turns a late payer into a hostile one for eleven months; waiting is comfortable and converts one late payment into a habit, which is how a property ends up in the notice process for something that started small.
- Whether a repair is the tenant's cost, the landlord's, or shared. Writing it off is the fastest route to an easy month and teaches everyone involved that repairs are free, and raising it as a second quote on the same occupancy costs an argument at the worst possible moment — which is still cheaper than arguing about an unexplained line on an invoice at month end.
- Whether to raise a rent revision on an existing occupancy, which may push a good tenant out, or leave it and absorb the gap until they move. Raising it is honest and risks the record; absorbing it quietly subsidises every month until the next vacancy, and the next vacancy may be years away.
- Whether to merge two records that are obviously the same person. Merging is tidier and destroys evidence, because a disputed rent reminder sent to the wrong record is exactly the situation where somebody will need to show that two records existed separately.
- Whether a deposit is returned in full, offset against damage, or argued about item by item. The deposit is the manager's only leverage and spending it on a small deduction early is a small sum that costs the whole relationship, and often the whole portfolio with it.
Free tools
What this trade tends to ask, answered with a calculator.
Lead response cost calculator for real estate agents
What a slow reply may be costing on incoming enquiries, built from the two assumptions a letting team actually owns: how fast a prospect goes cold, and what a signed occupancy is worth to the portfolio.
Receivables aging calculator
Outstanding rent and chargeable repairs bucketed by how old they are, so an arrears position is a queue with a written rule behind it rather than a list somebody sorted from memory. A calculation to work from, not a ledger.
Where to look next
The product areas this depends on.
Quotes, Billing & Finance
Rent raised on the date whether or not anything happened, repair charges raised as their own priced event, deposits, credit notes, and GST treatment — with no work required behind the recurring invoice.
Debt collection and recovery
Not a recovery engine: a prioritised outstanding list with a recorded promise and date on each item, ordered by a rule the manager set, with escalation left to a person.
Customer complaint and warranty
A repair already invoiced and found faulty is a credit note; the same repair before it is invoiced is a new quote on the same occupancy — the split that keeps a repair from becoming a disputed line.
Customer data cleanup
Duplicate addresses and duplicate people flagged as candidates with the dangerous pairs held as exceptions. Detection proposes, a person reviews, and nothing merges automatically.
Before you look at pricing.
Is this a tenancy management system?
No, and it is worth being precise about the gap. NoxOrigin holds no tenancy record, no rent ledger, and no maintenance scheduling: it will not tell you who is contractually occupying a property, it does not run a ledger that rent flows through, and it does not book contractors or sequence repairs. What it holds is the commercial side of the arrangement — the parties as customer records, the terms as a quote, the occupancy as the project, the repair as work, and the rent and repair charges as invoices with payments recorded against them.
Does it chase rent, send reminders, and handle escalation?
It is not a recovery engine. What exists is a prioritised list of what is outstanding with recorded payment promises and dates, ordered by a rule the manager sets rather than by whoever is loudest. Nothing here sends notices or starts a legal process on a schedule: escalation from a reminder to a notice to losing an occupancy is a human decision with legal weight attached, and software that does it automatically is a liability rather than a feature.
How is a repair the tenant has to pay for handled?
As a second quote on the same occupancy. The work is a work record, and when the cost is the tenant's to bear rather than the landlord's, that is a quote raised against the same arrangement with its own price, then an invoice, then a payment against it. There is no change-request record in this product, and a fault on work already invoiced is a credit note rather than an edit, so the repair stays visible as its own priced event instead of disappearing into the next month's rent.
The tenant and the property get confused constantly — can it sort that out?
Partly, and it will not pretend to do it for you. Duplicate detection flags candidate records for a person to review and holds the dangerous pairs as exceptions; nothing merges automatically, and the merge policy is a setup decision rather than a default. The deeper point is that the arrangement itself is a separate thing from both sides, and NoxOrigin does not model a tenancy as a legal object with rent running through it — it carries the parties as customers and names the property on the record, so a wrong merge is a decision somebody can still be asked to justify.
Does it track maintenance costs, vendor bills, or the manager's expenses?
Not in the platform. There is no expense tracking here — expenses are a Nox-Billings capability, and purchasing sits in Commerce, so materials, contractor payments, and the manager's own costs are assembled elsewhere. What NoxOrigin holds is the repair as work, and the charge raised to the tenant as a quote, an invoice, and a payment, which is the part that belongs to the occupancy rather than to the manager's books.