Money: payments, receivables, expenses, deposits

The four money modules, the upcoming-payments view, and the expense category list.

Watch how it works

On this page

Four modules track every dirham that moves through your portfolio. Each is a separate ledger, and they connect at well-defined points. Here's the model.

The four modules

ModuleWhat it representsCreated by
ReceivablesRent owed to you (not yet collected)Auto-generated from contract schedules
PaymentsRent collected (or to be collected)You record, system verifies
ExpensesMoney you've spent on the propertyYou record, system verifies
DepositsSecurity deposits held + refundedAuto from contract, refunded manually

Receivables

When a contract is created, the system generates one receivable per scheduled rent installment. The Receivables page (/app/receivables) is your home for collections work: what's owed, by whom, when, and what's overdue. Monthly contracts → 12 receivables for a one-year term; quarterly → 4 receivables; etc.

Each receivable has a due date, an amount, and a status (Upcoming, Due, Overdue, Paid). The dashboard surfaces overdue and due-this-week receivables so your collection team knows where to focus.

The Overdue tab's Since Last Payment column tells you how many days it's been since the tenant last paid anything on that receivable, a quick read on collection momentum. If the tenant has never paid on it, the count runs from the due date instead; a receivable that isn't due yet shows a dash.

You can split a receivable (partial payment), defer it (with reason), or write it off (with reason). Each action is logged for the audit trail.

Written-off receivables stay trackable and reversible. Pick Written off in the status filter to see them; the receivable's detail page shows who wrote it off, when, the amount, and the reason. An admin or accountant can Restore a write-off (from the row's actions menu or the detail page), which returns the amount to outstanding (it reappears in collections, dashboards, and payment allocation). Restoring works even if the contract has since been terminated: the amount simply becomes collectable debt again. The write-off history is never deleted. A restore records who reversed it and when.

Upcoming payments

The Receivables page has an Upcoming tab next to Overdue and Paid. By default it shows the next 90 days of scheduled rent installments, the standard rolling window for forecasting near-term cash.

Need a different horizon? Use the date-range filter at the top of the table. Common patterns:

  • "What's due next week": set the date range to the next 7 days.
  • "What's expected this quarter": leave the default 90-day window.
  • "All of next year's contracts": set the date range to next January through December.

Each row shows: payment number on the contract, due date, tenant, property/unit, and amount. Click any row to jump to the contract for context.

Two contrasts to remember:

  • The Overdue tab is everything past its due date. It's danger-styled: that's the collection team's daily work list.
  • The Upcoming tab is purely informational planning. Items move from Upcoming → due-this-week → Overdue → Paid automatically as time passes and payments arrive.

Discounted payments

An admin can grant a negotiated discount on a contract's scheduled payments (see Leases and contracts). Wherever that installment appears (the Receivables list, the Upcoming tab, the record-payment form), you'll see the reduced amount with a Discounted tag, and the CSV export carries a discount column. Rent reminders chase the reduced amount too, and a fully discounted installment drops out of collections entirely. On the dashboard, a "Discounts given" figure appears (when there is one) and opens a per-contract breakdown.

A discount is not a write-off: a write-off abandons collection of an amount already owed, while a discount is a reduction you agreed with the tenant on a scheduled payment. Each keeps its own audit trail, and removing a discount makes the original amount owed again.

Payments

A payment is money you've received from a tenant. Open Payments → Record payment to record one:

  • Pick the tenant (Contact).
  • Pick which receivable(s) it applies to. The system pre-fills the amount from the matching receivable.
  • Record method (cash, bank transfer, cheque), reference number, date.
  • Attach proof (transfer receipt, photo of cheque).

Payments enter the payment verification workflow: the recorder submits it, a verifier reviews, and once approved it's posted. Verified payments mark their linked receivables as Paid.

Which installment a payment is applied to

A payment is applied to the installment you picked when recording it. If you open the July row and record a payment there, it settles July, even if an earlier installment is still unpaid.

Two things follow from that:

  • Paying out of order leaves the earlier installment open. If January is still overdue and you record a payment against March, March is settled and January stays overdue, so January keeps its reminders and can still escalate. That's intended: January genuinely hasn't been paid. To settle January, record the payment from the January row.
  • Paying ahead stays ahead. A payment recorded against a future installment is held against that installment. It won't be pulled forward onto an earlier one, and it won't show up as an overdue amount being paid off.

If a payment isn't tied to an installment at all (for example, an advance recorded from the Payments page with no due date selected), it's applied to the oldest amount owed first, then forward.

On a multi-unit contract, "Record contract payment" splits one payment across the contract's units. Each unit is credited exactly the amount shown in the split table, including any amount you override by hand.

The installment picker shows the installment's full amount, with the remaining balance in brackets when part of it has already been paid, e.g. "Jan 1, 2026: SAR 26,250.00 (SAR 5,000.00 owed)".

Expenses

An expense is money you've spent on a property: repair invoices, cleaning, utilities, taxes. Open Expenses → Record expense and record:

  • Property + unit (or property-wide).
  • Vendor (Contact).
  • Amount + date + category.
  • Attach the invoice, and any other documents or fields your workflow asks for.

The document slot(s) and input fields in the Record-expense form are driven by your expense verification workflow: a workspace admin configures them under Settings → Configuration → Workflows (add a second attachment slot, mark the invoice required, add an input field like a reference number, …) and the form updates to match: no fixed single-file picker. What you upload/enter is captured onto the workflow and shown on the expense's documents.

Expenses go through the expense verification workflow: submitter, then verifier, then posted. Verified expenses appear on the property's P&L and the dashboard.

Lifetime caps on the Free plan: 100 expense entries over the workspace's lifetime. Paid plans are unlimited.

Expense categories

Categories drive expense reporting and the property P&L roll-up. Your workspace ships with nine built-in categories seeded on creation:

  • Ejar platform fee
  • Government fee
  • Maintenance
  • Utilities
  • Salaries
  • Insurance
  • Marketing
  • Professional services
  • Other

These eight (plus Other) cover most operating-cost lines a Saudi portfolio sees. Manage the list at Settings → Configuration → Expense categories: open the page, add as many custom categories as you need ("Pool maintenance," "Generator fuel," whatever fits how your bookkeeper reports).

Payment methods

The payment method picker you see when recording a payment or marking an expense paid (Cash, Bank transfer, Cheque, Mada, Ejar platform, Other) is now yours to customize. Manage the list at Settings → Configuration → Payment methods: add one row per real account you collect into or pay from ("Al Rajhi (main)", "STC Pay", "Riyad Bank (deposits)"), so every recorded payment is tagged to the right account for your books.

The same delete-and-restore rule as categories applies. Each method has one Delete action: deleting a built-in default, or any method already used on a payment or expense, hides it (gone from every record-payment picker but kept on your history, and restorable from Show deleted → Restore, or Restore defaults); an unused custom method you added is removed for good. Methods you add appear everywhere a payment is recorded across web and mobile. Deleting a method never touches Odoo: its journal mapping is kept, so a restored method works immediately.

Deposits

When a contract is created, the system records the security deposit the tenant paid (you enter the amount during contract creation). It's held in the contract record: neither receivable nor expense, just held.

When the contract ends, open the contract and pick Refund deposit. You'll record how much to return (the original, minus any deductions for damages), what was deducted and why, and attach proof. The deposit-refund workflow verifies and posts the refund.

Recording a deposit payment and a deposit refund both show the document slots + input fields configured on their respective workflows (Settings → Configuration → Workflows → Deposit payment / Deposit refund), the same way expenses do, so the receipt/refund-proof you upload and any fields you fill are captured onto the workflow and verified through it.

Deposits also support charges during the tenancy: if a tenant damages something mid-term and you deduct from the deposit, the deduction is logged.

Where each piece shows up

  • Dashboard: this month's expected revenue (sum of receivables due), this month's collected (sum of verified payments), this month's expenses (sum of verified expenses).
  • Property page: per-property P&L roll-up.
  • Contracts page: per-contract receivable / payment timeline.
  • Reports: full financial reports across the date range and filters you pick.

Free-plan lifetime caps

ResourceFreePaid plans
Payment records100 lifetimeUnlimited
Expense records100 lifetimeUnlimited
Maintenance requests10 lifetimeUnlimited
PDF extracts10 lifetimeUnlimited

Lifetime means the running total since the workspace was created, not "100 per month." Hit the cap on Free, and you'll be prompted to upgrade. See Plans and billing.

For a deeper look at how Aqarflow handles real-estate accounting end-to-end (from P&L roll-up to the Saudi-specific expense categories to Odoo export), see Real estate accounting software.

Paying once for a multi-unit contract

When a tenant leases several units under one contract and pays a single amount for an installment, you don't have to record a payment for each unit separately. Use Record contract payment (on the contract page, from a Receivables row, or from any Record-payment button on a multi-unit contract, on web and mobile): pick the installment, enter the total, and the amount is split across the units by what each still owes. The split table is editable: adjust any unit's share as long as the per-unit amounts add up to the total. Each unit keeps its own payment history, and the whole set is verified together in one approval (one notification), and you can approve or return the whole group at once (web and mobile).

Because one recorded payment becomes several per-unit rows behind the scenes, both money lists group by default so you see the payment you actually made, not the split. The Payments ledger shows one row per contract payment (expand it for the per-unit breakdown); Receivables shows one row per installment with the units folded underneath. On web you can search the Payments ledger by the total you recorded to find it again. To move a grouped payment to a different installment, delete it and re-record: a single unit of a group can't be re-pointed on its own.

Each unit also shows its own Rent status (Current / Partial / Overdue) based on that unit's share of the schedule, so within one multi-unit contract, a cheaper unit that's fully covered can read Current while a pricier one still owing reads Partial.

On the offer and contract pages, each unit's listed value is tax-inclusive: it's that unit's share of rent, services, and VAT, so the unit values add up to the contract's total. Whether you price by total-split-by-area or enter a rent per unit, the split works the same way.

Dashboard performance view

The dashboard shows how your properties performed over a time frame you pick: a preset (This month, This quarter, This year, Last year, Last 12 months) or a custom from/to range. Picking a full year keeps the classic yearly view; any other window switches to a "range" view where the money cards read "in period", the chart granularity adapts (daily, monthly, or yearly bars), and three extra cards appear:

  • Leasing activity: new leases vs renewals (a renewal is not a new contract) vs churn, and net leasing.
  • Net operating income: collected minus operating expenses for the period.
  • Average occupancy: the true occupancy across the whole period, not just today, read two ways: by units and by value.

Opportunity cost estimates the rent you lost to empty units during the period, using only your own numbers: each vacant unit is priced at the full rent it last actually earned, including service fees and VAT, or, if it was never rented, at the Expected annual rent you set on the unit (Properties → unit → Edit; enter that figure inclusive of services and VAT). Units with neither are flagged so you know to fill that field in. Vacancy before today is shown as "rent lost"; if your range runs into the future, the remaining empty days show as "rent at risk". The 3-Month Action Plan and "expiring in 30/60/90 days" always look ahead from today, whatever range you selected.

If you're entering old contracts for units you owned before adding them here, the dashboard automatically dates each unit back to its earliest contract, so historical periods are correct. For a unit that was empty for years with no contract on record, set its optional In service since date (Properties → unit → Edit). It's used only to show that older vacancy in the dashboard.

If you use Sales, an empty unit that is for sale is not counted as vacant. From the day you list it (or a buyer's quotation is accepted) until it is sold or withdrawn, its empty days are left out of opportunity cost and out of both occupancy rates, and the dashboard shows it on its own Held for sale line. A unit you sell with its tenant still in it is unaffected, because it is still earning rent.

Occupancy by units vs by value

The dashboard shows occupancy twice, and the two numbers will usually differ.

By units counts doors: the share of your unit-days that were rented. By value counts money: the share of your rent that you actually earned, with each unit weighted by what it is worth.

The gap between them is the useful part, and neither one is more correct than the other. A building with four small units let and one large one empty is 80% full by units, but if the empty unit is half the rent, it is closer to 50% by value. When by value sits well below by units, your empty units are the expensive ones, which is a very different problem from having a lot of small vacancies.

The industry calls these two figures physical and economic occupancy.

How an empty unit is priced. By whatever it last actually earned, and if it has never been rented, by the Expected annual rent you set on the unit (Properties → unit → Edit; enter it inclusive of services and VAT). A unit with neither is left out of the calculation entirely rather than counted as worthless, and the card tells you how many units that applies to. Fill those in and the figure gets sharper.

The figure is what your contracts say you earned, not what was collected. Whether the money arrived is the separate collection rate.

Choosing what you see. If two percentages is more than you want, an admin can switch the dashboard to one or the other under Settings → Configuration → Dashboard → Occupancy display. It only changes what is drawn, never any figure.

The Properties list shows the same pair as a snapshot of today rather than an average over a period, so the two pages can show different numbers on the same day. Both are right; they are answering different questions.

Overdue grace on the dashboard

The dashboard treats rent as overdue only once it's both past its due date and past a grace period, a short cushion before a late payment is counted against you. A payment that lands within the grace window still counts as on-time on the dashboard.

  • An admin sets a workspace default grace under Settings → Configuration → Dashboard (30 days out of the box).
  • An admin can override the grace on a single contract from the contract page. Leave it blank and that contract just uses the workspace default.
  • An overdue placement option (also under Settings → Configuration → Dashboard) chooses whether the performance chart marks overdue in the month the rent was due, or the month it became overdue (after the grace runs out). It only moves where the marker sits: the overdue total is the same.
  • You can also hide the overdue markers entirely (Settings → Configuration → Dashboard → Overdue markers) if your team doesn't want them on the chart, a display choice that doesn't change any figure.
  • Changing any of these, or a contract's grace, updates the dashboard right away (no hard refresh needed).

The chart's bars are also clickable: click a month (or day/year) to see exactly the scheduled, collected, and overdue behind it.

Receipt vouchers

A receipt voucher is a numbered paper you hand whoever paid, as proof that you received the money. It is issued from a payment already recorded in the system, so it never carries an amount your books did not see and never disagrees with your records.

Receipt vouchers are marked Beta: they are new and still being refined. They work, but if something does not behave as you expect, tell us.

Turning them on. A workspace admin turns receipt vouchers on and off on the web, under Settings → Configuration → Modules. They start on in new workspaces and off in workspaces created before they were released. If you cannot find the "Issue receipt voucher" button on a payment, or a "Receipt vouchers" page in the sidebar, ask your workspace admin to turn them on. Turning them off deletes nothing: vouchers already issued are kept, and come back as they were when the module is turned on again.

Issuing one.

  1. Open the Payments page, then open the payment.
  2. In the "Receipt voucher" section, press "Issue receipt voucher".
  3. Check what will be printed. The amount and the payment method come from the payment and cannot be changed here. "Received from" and "Being" are proposed from the contract, and you can change both. If the payment was a cheque, type its number in "Cash / Cheque no." and the bank in "Bank", because a payment does not store those two fields.
  4. Press "Issue". What you confirm here is what prints on the voucher and stays on it.

Only for approved payments. A voucher can be issued once the payment is approved, and for a payment covering more than one unit once it is approved for all its units; until then the payment page says so where the button would be.

What prints. The voucher is half an A4 sheet, landscape. Every label is in Arabic and English, the date is given in Hijri and Gregorian, and there are two signature lines at the bottom, for the receiver and the accountant. The payment method prints under its Arabic name, unless it is a method you added with an English name only, which prints as named. The workspace name is not printed: it is an internal label for you and means nothing to the person who paid.

The logo. The voucher prints the workspace logo uploaded under Settings → Configuration → Branding. There is no separate upload for vouchers. If no logo has been uploaded, the voucher prints with a clean header.

Numbering. It starts at 0001 in each workspace, goes up by one with every voucher, and no number is ever used twice. A cancelled voucher keeps its number, so if a number seems to be missing from the list it is most likely a cancelled voucher, which appears when you tick "Show cancelled vouchers".

The Receipt vouchers page. It appears in the sidebar for anyone who can record payments and lists the vouchers issued, newest first. Search by voucher number or tenant name, and use each voucher's menu to view, download or cancel it. Cancelled vouchers stay hidden until you tick "Show cancelled vouchers".

Viewing and downloading. "View voucher" opens it on screen exactly as it prints, without saving a file, and "Download voucher" saves it straight away; the preview has its own download button too. Both are on the payment page and in each voucher's menu on the Receipt vouchers page.

A payment covering more than one unit. The tenant handed you one amount, so they get one voucher for the total, and the units are listed on the "Being" line. The same voucher shows on the payment page of each of those units.

Cancelling. A voucher is never edited and never deleted. If one is wrong, press "Cancel voucher" on the payment page or on the Receipt vouchers page, add a reason if you like, then issue a new one. The cancelled voucher stays on record with its number, and CANCELLED prints across it if you open or print it.

Who can. Issuing and cancelling a voucher is for anyone who can record payments on the payment's property. Anyone whose role hides payment amounts on a property cannot open or download its vouchers, and they are left out of the list.

On the phone. Receipt vouchers reach the app from version 1.0.4, as a "Receipt voucher" card on the payment screen. Pressing "Issue receipt voucher" opens a confirmation showing the payer, the amount and the "Being" line as they will print, and the voucher is issued only when you confirm. Those lines cannot be changed on the phone and the cheque and bank lines are left empty, so if you need to change any of them, issue the voucher from the web. "Download voucher" opens it inside the app. Cancelling, and the Receipt vouchers page, are on the web.

When an amount shows as dots

If a figure reads •••• instead of a number, your role does not include permission to see that kind of amount. Hover it and the tooltip names the exact box your workspace admin would need to tick.

Amounts are grouped into six kinds, and each is granted separately, so it is normal to see some figures and not others: what a lease is worth, what a tenant owes, what was paid, what was spent, deposits, and the value agreed on a service agreement. A Property Manager, for example, usually sees what a tenant still owes but not what the lease is worth.

The value on a service agreement (an insurance, cleaning or owner agreement kept as a recurring template) is its own kind, and it follows the permission to manage recurring tasks rather than the one for expenses. It is a figure somebody agreed to pay, not an expense that was recorded, so the people who administer these agreements see it and an accountant who never touches one does not.

Where a decision is waiting on you, the figures you need to make it are shown even if your role would normally hide them, and a note on the page says so. They go back to hidden once you have acted.