Rent invoices raised automatically, and never twice for the same month
A nightly run reads every live contract, works out which periods are now due within the next few days, and raises the invoices — one per customer per period per property. You can run a preview first that shows exactly what would be billed, contract by contract, before a single customer sees a number.
A camp with 400 contracts is one button instead of a week of typing. And if the job crashes at 3am and you re-run it, nobody gets billed twice: the run reports how many lines it skipped because they were already there, which is the figure that proves it is safe to press again.
Part months priced four different ways, and the line says which
A resident moving in on the 18th does not owe a full month. The contract chooses how that is priced: by the real days in the real month, by a flat thirty-day month, as a whole period anyway, or free. Periods themselves run either on the calendar (1st to month end) or on the contract’s own anniversary, across seven cycles from daily to annual.
Every disputed invoice in this business is a part month. The line prints “11 of 28 days (2026-02-18 to 2026-02-28)” next to the amount, so the argument ends at the invoice instead of in a meeting.
Tax decided line by line, from a rulebook you edit
One invoice can mix exempt residential rent with standard-rated wifi and an out-of-scope deposit, so tax is resolved per line, against the date of supply, and each line stores the sentence explaining the answer. The rates and rules are editable rows in your own database, not code: a UAE starter set is seeded — deposits out of scope, first supply of new residential zero-rated, serviced accommodation standard, bare land exempt, ordinary residential exempt, services standard — with priorities you can insert between.
A single rate applied to a whole invoice is wrong for at least one line on it, and you only find out at an audit. When a rate moves, somebody edits a row rather than waiting for a release. And when a customer asks why there is 5% on one row and none on the next, the answer is already printed on the document.
A tax invoice a customer can pay from, with a scannable code and a per-person annexe
The printable document carries the full compliant field set — supplier and customer with tax registration numbers, invoice number, issue date, date of supply, per-line quantity, rate, taxable amount, tax rate and tax amount, a tax summary grouped by code, and totals. It renders in English or Arabic, right-to-left, with a real scannable QR drawn into the page. Corporate invoices get an annexe grouping the detail by employee and by bed.
A corporate client with 40 beds does not reconcile a single total — they reconcile employee by employee. The annexe is what gets the invoice approved rather than returned. The QR means a phone reads the reference and amount instead of somebody re-typing it. And exempt and zero-rated stay separate rows in the summary even though both read 0%, because a tax return distinguishes them absolutely.
Once an invoice is issued, nobody can change it — including us
A draft can be edited freely. The moment it is issued, the amounts, the customer, the number and the dates are frozen: the database rejects the change, not just the screen. Voiding is possible while nothing has been paid, needs a written reason, and keeps the invoice number while writing an equal and opposite ledger entry rather than deleting anything.
The customer has a copy. A gap in your invoice numbering is the first thing a tax authority asks about, and an invoice that quietly changed after it was sent is a document nobody can defend. This is what makes the ledger worth keeping.
Credit notes: the only way to correct an issued invoice
Corrections carry a reason code — correction, goodwill, cancellation, write-off or overbilling — and a written reason. The amount is capped at what is left uncredited, the tax inside it follows the invoice’s own proportion unless you state otherwise, and the invoice flips to fully credited when nothing is left. Two notes raised at the same instant cannot jointly exceed the invoice.
You keep an audit trail instead of an eraser. The cap is enforced with a row lock at the database, so a race between two clerks cannot over-credit an invoice — which is the failure that only shows up at year end. Every credit note gets its own number in its own series.
Every figure is a whole fils, and a split never loses one
Money is stored as whole minor units with a currency beside it — never a decimal that drifts. Anything divided (a shared cleaning bill across six rooms, a balance across three instalments) is split so the parts add back to exactly what went in, with the odd fils handed out largest-remainder. Adding dirhams to dollars throws rather than guessing a rate.
A payment plan for AED 10,000 over three months is 3,333.34 + 3,333.33 + 3,333.33 — not three times 3,333.33 with a fils nobody can explain. Rounding errors in money are not small, they are unexplainable, and an invoice line you cannot explain is a dispute.
Money in, spread across invoices the way you choose — with a receipt, and reversible
Record a receipt in cash, bank transfer, cheque, card, online, adjustment or deposit transfer, and say how to apply it: oldest due first, a named invoice, or your own split. Anything left over is held as customer credit against the next invoice rather than forced onto this one, and can be applied later from the row. The receipt prints which invoices it settled, how much went to each, and what each still owes today. A reversal unwinds every allocation, restores each invoice’s balance and status, and keeps the receipt number.
Which invoices a cheque settles decides whose chasing letter goes out on Monday. Over-applying makes an invoice look over-paid and corrupts your whole aging report. “I paid that” is settled by a receipt naming the invoice. And reversing rather than deleting leaves a trail instead of a hole in the receipt series.
Import your bank statement and match it to invoices
Upload the CSV your bank exports. The system reads the header, proposes which column is the date, the credit, the reference; you correct it. It then scores every incoming credit against your open invoices — the reference naming an invoice number is the strongest signal, an exact amount match next, proximity to the due date after that — and shows the top candidates with a reason for each. Nothing is created until you confirm, and rows it could not read come back with their line numbers rather than being skipped.
Different banks write different files: one says Transaction Date, another says Value Date, another splits credit and debit into two columns. Guessing gets it wrong on the second bank. An automatic match that is wrong moves money against the wrong customer and is discovered a month later by the customer you chased for it — so the operator always confirms. Re-importing the same statement does not pay anything twice, because the bank’s own reference is the identity.
A post-dated cheque register, with a calendar and a custody report
A cheque is its own record, not a payment with a date. It moves through received, in hand, deposited, then cleared or bounced — and from bounced to replaced, legal action or recovered; only the legal next moves are ever offered. Clearing an incoming cheque automatically becomes a payment and settles the customer’s invoices. A month calendar shows each day’s cheques due for presentation, inbound against outbound, with the net; a custody view groups every cheque the system believes you physically hold by where it says it is, and names the ones with no recorded location. Handing one to the bank runner is logged as a move of paper, not a change of status.
A year’s rent arriving as twelve pieces of paper is normal here, and knowing which of them clears next week is the cash-flow forecast. Before an audit somebody has to stand in front of the safe and count — the custody report is that list. And the register stops the fraud the separation exists to prevent: banking a cheque and marking it bounced are different permissions, so one person cannot do both.
What happens the moment a cheque bounces
You record why it bounced — insufficient funds, signature mismatch, stopped payment, closed account, or technical. That single answer drives everything: the customer’s risk band worsens (and never improves from a bounce), a bounce-fee invoice is raised and issued, a collection case opens, any payment the cheque had already produced is reversed, and finance, the leasing owner and the property manager are flagged. A technical bounce — a wrong date, a missing endorsement, usually your own error — carries no fee.
Four of those five things get forgotten when a bounce is handled by hand, and the one most often forgotten is reversing the payment, which leaves an invoice showing as paid when the money is not there. Charging a fee for your own clerical mistake is how a small error becomes a lost client.
A deposit ledger that is a liability, can never go negative, and closes at zero
Deposits sit in their own append-only ledger, entirely separate from revenue — held, deducted, refunded, forfeited, transferred in, transferred out, each with a reason. The balance can never fall below what is actually held, and the system tells you how much you may refund rather than just refusing. Carrying a deposit to a renewal contract is two movements netting to nothing, so no cash appears to move. At move-out, enter the rent to the leaving date, utilities, damages and anything else owed: the deposit covers what it can, the remainder is refunded, and the ledger closes at exactly zero — with anything still owed becoming an ordinary debt rather than a negative deposit.
A deposit is the customer’s money, held. It never belongs in a P&L, and a negative balance means the business has spent something it was only holding. Netting a settlement instead of exhausting it leaves a balance floating against a contract that ended, and those become disputes two years later. Taking money in, deducting, refunding and forfeiting are four different acts needing four different authorities.
Arrears aged into buckets, a ladder that fires once, and capped late fees
Open invoices fall into current, 1–30, 31–60, 61–90 and 90+ days, per customer and in total, with the oldest debt in days. The ladder then works: a friendly reminder at day 1, a formal reminder plus late fee at day 5, escalation to the corporate contact and a task for the property manager at day 10, a final notice with a service-restriction warning at day 20, a collection case at day 30. Each rung fires once per invoice however many times the job runs, and only ever moves forward. Late fees can be a fixed amount, a percentage of the overdue balance or an amount per day — each with a grace period and a hard ceiling, and each raised as its own invoice. Waiving one is a credit note with a reason. You can rehearse the whole run before anybody is chased.
An invoice left alone for a month should produce one escalation, not five emails in a minute after a weekend outage — and never a final notice followed by a friendly reminder. A per-day fee on an invoice forgotten for two years is a number nobody collects and any court strikes out, so the cap is what makes it enforceable. The fee on its own document is chaseable and creditable separately, because the overdue invoice itself can no longer be touched.
Collection cases, promises to pay, and plans that stop the chasing
One case per customer, not one per invoice. Record what they promised and by when; when the date passes the system judges it on money actually received since the promise was made, marks it kept, part kept or broken, and escalates the case on a broken one. An overdue balance can be turned into instalments that add back to the balance exactly — and while a plan is live, normal chasing is suspended.
A customer with four overdue invoices has one problem; four cases is four people ringing them. A promise nobody closes is a promise that was broken, so it is settled against the bank rather than against somebody’s memory. And chasing a customer who is keeping to an agreed plan costs more than the invoice.
A customer’s ledger, with a running balance and its own aging
Every invoice, credit note, payment and adjustment for one customer in date order, with the balance after each, plus that customer’s debt split across the aging buckets. The ledger cannot be edited or deleted — a correction is a new entry with the opposite sign — and an entry’s currency must match the document it belongs to.
This is what you send when a corporate client’s finance department queries the account. A ledger that can be edited is not a ledger; the reversing entry is the trail an auditor follows. The customer’s credit limit on that same screen is withheld from anyone without the specific permission to see it.
An accounting journal export that will not download unless it balances
Every invoice, credit note, payment, expense and deposit movement in a period, restated as debits and credits against account codes you control. Eighteen mapping keys — receivables, bank, deposits held, VAT payable, rental income, utility recharges, late fees, head lease rent and so on — each with a default code you change to match your accountant’s chart. The two sums and their difference are shown, and the file is only offered when they agree.
This is the one thing that leaves the product, and it has to import cleanly into whatever ledger you actually keep your books in. An unbalanced batch does not fail on import — it posts to suspense, and somebody finds it at year end.
Approvals on the decisions that give money away
A discount over your threshold, a write-off over your limit, and postponing a cheque all stop and ask somebody, with the context printed for the approver. The write-off threshold is measured against the running total already forgiven on that invoice, not against this note alone. Thresholds are rules you write in plain conditions like “amount_pct > 10”, against a named approving role.
AED 8,000 written off as two 4,000 halves passed both times before this was measured — a threshold you can step around by splitting the paperwork is a rounding instruction, not a control. Correcting a genuine billing error is deliberately not gated: refusing to fix a mistake until a director is free is how a customer gets chased for a charge everybody agrees was wrong.
Who is allowed to do what, split finely enough to matter
Preparing an invoice and issuing it are different permissions. Recording a receipt and deciding which invoices it settles are different. Taking a deposit, deducting from it, refunding it and forfeiting it are four. Banking a cheque, clearing it and marking it bounced are three. Rehearsing the chasing run costs less authority than actually running it. A site supervisor is sent no money figures at all — the server withholds them rather than the screen hiding them.
Separation of duties is the whole of financial control. A screen can hide a field; it cannot un-send it — so the figures a role must not see never leave the server, and the buttons a role cannot use are never offered. And the person deciding an approval must hold the authority, not merely sit at the desk named in the rule.