Condominium ERP & owners-association management

Most condominium software bills your units. This one runs your community.

Condominium management software for the whole operation - the property register, owners and tenants, access control, utility metering, service charges, monthly invoicing, arrears and disputes - with full accounting built in. One system, one set of numbers, one supplier.

Register, billing and accountsOwners, tenants and accessBuilt on Odoo

Overview

One system for the property, the people, the billing and the books.

BH Condominium

BH Condominium is a condominium ERP: it manages every apartment across your buildings - who owns it, who occupies it, and what each of them owes.

Every month it turns meter readings into charges, applies your service charge rules, issues one consolidated invoice per payer, records settlement, tracks arrears and posts the whole run to the accounts.

The register, the billing and the ledger are one database. Nothing is exported, re-keyed or reconciled between systems - because it is built on Odoo rather than bolted beside it.

What it replaces
Separate spreadsheets for units and meter readings, a standalone billing tool, a payments tracker, and an accounting package that receives all of it by re-entry.
Who it's for
Property management companies, owners' associations and developer-operators - from a single tower to a multi-community portfolio.
What it delivers
A complete monthly cycle: readings validated, charges calculated, invoices issued, receipts recorded, arrears reported, ledger posted.

Scope

Everything BH Condominium manages.

Four areas, one database. Each is opened up in detail further down this page.

Property

Every block, floor and apartment as its own record, with common areas, parking and unit categories.
Blocks Floors Apartments Common areas Parking Unit categories Net & gross area Lifecycle status

Owners and occupants

Ownership shares, tenancy periods and the access credentials issued against each, including the units that change hands mid-month.
Owners Ownership shares Tenants Lease periods Move-in & move-out Access cards Keys & biometrics Handovers

Billing and collection

Meter readings through to service charges, one consolidated invoice per payer, receipts, arrears and challenged charges.
Meter readings Water Electricity Tariffs Service charges Common-area allocation Consolidated invoices Part-month splits Receipts Arrears Disputes

Accounting and reporting

Full double-entry accounting on Odoo, and five dashboards over the same month.
Chart of accounts Journals Bank & reconciliation Receivables Occupancy Consumption Property ledger Financial statements
OverviewCommand centre
Condominium command centre overview dashboard, filtered by community, year and month, showing total invoiced and outstanding balance tiles, an apartment status distribution chart across draft, active and under maintenance, a units-per-community chart, and a community summary row with 14 total units, 12 active and 85.7 percent occupancy.
Every unit across every community, its state and its occupancy, filtered to the month you are looking at. Four more dashboards sit behind this one - financial, utilities, occupancy and a per-unit ledger.

How it works

How a month runs.

01
Set up the register
Buildings, apartments, owners and tenants are loaded once. Every charge and every access card is issued against that record.
02
Capture the readings
The month's meter readings are imported and validated. Readings that fall outside the unit's own history are flagged before anything is charged.
03
Issue the invoices
Service charges and consumption combine into one invoice per payer, routed to the owner or the tenant according to the lease.
04
Collect and report
Receipts are recorded against the invoice, arrears surface on a worklist, and the whole run posts to the accounts.
3 tiersblock, floor and unit, each a real record with its own lifecycle, ownership history and meters - not columns in a shared workbook
5 levelsof payer resolution, so each charge reaches the right owner or tenant without anyone deciding it by hand
3 testsrun on every meter reading - peer comparison, distribution fence and the unit's own history - before a single charge is raised
5 viewson the same month, one of which is the arrears worklist nobody has to build in a spreadsheet

What it covers, in detail

One system for the whole community, not one clever feature.

A condominium is a register, a set of leases, a security estate, a billing operation and a set of books - and most teams run those five things in four different places. Here they are one Odoo database. Everything below is implemented and running today.

Property register
Block, floor and unit as real records, with common areas, unit categories, net and gross area, and a lifecycle from draft through active, under maintenance and archived.
Ownership
Any number of owners per unit with individual percentages and dates - joint ownership, investor syndicates and mid-year transfers, with the active total held at or under 100%.
Tenancy
Every lease kept with its move-in and move-out dates, not a single current-tenant field. That history is what makes retrospective billing and dispute investigation possible at all.
Access credentials
Key cards, physical keys, biometrics and temporary passes - issued to a named holder, with expiry, status, a reissue action, and a lifecycle that ends when the lease does.
Service charges
A priority-ordered rules engine - fixed or per square metre, targeted by unit category, block or floor, with effective dates and a manual override where a unit genuinely needs one.
Utility sub-metering
Meter registry, bulk reading import, three statistical anomaly tests, date-effective tariffs and common-area allocation. The deepest part of the product, for the communities that need it.
Invoicing
Consolidated Odoo customer invoices per payer per unit, debit notes, and a five-level chain that always resolves the right owner or tenant without anyone deciding it by hand.
Disputes
A challenged charge is logged against the exact line it disputes, numbered, threaded, and worked through to a recorded resolution with an agreed amount and the person who signed it off.
Dashboards
Five analytical views - overview, financial, utilities, occupancy and a per-unit property ledger - each filtered by community, year and month, each drilling through to the record behind it.

The monthly cycle, in detail

Nine stages, one system, no spreadsheet in the middle.

Most mid-sized property management companies run this cycle on a shared workbook and an email chain. Here it is a workflow with states, validation and an audit trail - the same nine stages every month, in the same place.

01
Define
Model the property - block, floor and apartment, plus common areas, unit categories and every meter.
02
Occupy
Ownership with percentages, date-bounded tenancies, and the access credentials each holder has been issued.
03
Meter
Import the month's readings from Excel, validate them line by line, and score the outliers automatically.
04
Rate
Apply date-effective tariffs per block, each one approved before it can be used.
05
Charge
Turn readings into charge lines, allocate the common-area meters by entitlement and area, and run the service charge rules.
06
Bill
Generate one consolidated invoice per payer per unit - owner, tenant, or both, resolved automatically.
07
Settle the exceptions
Debit notes, and a pro-rata engine for the units that changed hands halfway through the month.
08
Settle disputes
A challenged charge is logged against the line it disputes, numbered, threaded, and worked through to a recorded resolution.
09
Analyse
Five dashboards - overview, financial, utilities, occupancy and a per-unit property ledger that doubles as the arrears list.

Property, ownership and access

The register underneath everything else, kept properly.

Every charge, every dispute and every dashboard figure rests on the record of who lives where and who owns what. Block, floor and unit are modelled as real records with their own history - not columns in a list someone maintains by hand.

Block, floor, unit
Unit codes unique per community, net and gross area, category, and a lifecycle from draft through active, under maintenance, inactive and archived.
Ownership that is actually shared
Any number of owners per unit with individual percentages and dates. Joint ownership, investor syndicates and mid-year transfers, with the active total held at or under 100%.
Tenancy history, not a current tenant field
Every lease is kept with its move-in and move-out dates. That history is exactly what makes retrospective pro-rata billing and dispute investigation possible at all.
Credentials with a lifecycle
Key cards, physical keys, biometrics and temporary passes - issued to a named holder, with expiry, status and a reissue action that closes the old card and notes why.
Cards die with the lease
The move-out billing run lists every active credential held by a departing tenant and deactivates the ticked ones as the invoice is generated. The common security gap, closed by the workflow rather than by memory.
Everything is on the record
Units, credentials, tariffs and disputes are all message-threaded with tracked fields, so who changed what, and when, is never a question of asking around.
Apartment B102Property structure
Apartment B102 in Block B, Floor 1, category 2 Bedrooms, net area 92 and gross area 102 square metres, in the Active state. The Residents tab lists owner Carlos Silva at 100 percent from May 2020 and tenant Hiruni De Silva from March 2023 marked currently active, with billing responsibility Tenant Only. A warning button shows one faulty meter.
One unit: its owner and their percentage, the tenant currently in place, the tabs for access control, billing configuration and meters - and a warning at the top that one of its meters is faulty, which is what stops that meter being billed.

Utilities

Where your communities are sub-metered

A wrong reading costs you twice: once in money, once in trust.

Not every community recharges utilities by meter. In the ones that do, it is most of the invoice and almost all of the arguments - and it is the part every other platform treats as a line item.

So the readings are validated before they are ever priced. Upload the month's spreadsheet and each row is matched to a meter, checked against the previous reading, and marked ok, warning or error. A batch with a single error cannot be validated, and a meter that is faulty or disconnected cannot be charged at all.

Excel import or prefilled rows
Six-state batch workflow
Re-validate after corrections
Reading batch - February, Block AUtilities
Reading batch URB/2026/0002 for Block A, February, with its reading lines: apartment, meter, reading date, last and current readings, usage, an ok or warning status badge, an anomaly star, a score, and the message "Abnormally high usage (388.00). Previous: 205.00. Please verify."
One block's readings, each row matched to its meter and badged ok or warning. The flagged row is well above its previous period, so it is scored and explained in a sentence - before any of it becomes money.
Three independent tests
A peer comparison against the rest of the block, a distribution-free fence for when consumption is heavily skewed, and the unit's own history - the vacated flat still drawing water, the new appliance nobody mentioned.
A score, not a shrug
Every flagged row carries a 0-100 score and a sentence in plain language - “usage is 4.2x last period - spike” - so a reviewer triages 500 rows in the right order instead of reading all of them.
Meters have a life
Active, temporarily disabled, disconnected or faulty, each with dates and notes. Only an active meter can be billed, and the import blocks the rest rather than quietly charging them.
Trend, not just total
Each line stores the previous usage, the percentage change and the direction of travel, with per-unit consumption history a click away.
Reading batchesThe period at a glance
List of utility reading batches showing reference, block, utility type, period from and to, month, year, rate per unit, state, and columns for total rows, errors, warnings and anomalies.
Every batch carries its own row, error, warning and anomaly counts, and its state - and it cannot become charges while an error is outstanding.

“Why am I paying for the gym meter?” deserves a real answer.

Shared consumption is where goodwill goes to die. The pool pump, the lift lobby, the gym - metered together, split by whoever is doing the spreadsheet that month, and impossible to explain when a resident asks. Here the split is a rule, applied the same way every period, traceable back to the meter.

The spreadsheet method6 steps · 3 places it breaks
Amenity meter read
Split evenly across every unit
Units with no access still charged
Rounded to two decimals
Total no longer matches the meter
Explained on the phone, unit by unit
With BH Condominium4 steps · reconciles to the cent
Amenity meter read
Only entitled unit types included
Shared out by each unit's net area
Last unit absorbs the remainder - total matches exactly
The charge line names the common area it came from, so the answer is on the invoice.
  • Entitlement lives on the unit category, so a studio without gym access is never charged for the gym meter
  • Tariffs are held per utility per block, with as many date-effective steps as the supplier gives you, each approved before it can be used
  • Rates carry four decimal places, because two decimals quietly round real money away across a thousand units
Electricity [Block A]Approved
Approved utility rate record for Electricity, Block A, showing a current rate of 58.0000 and a rate history tab with two date-effective lines: 58.0000 from March 1 and 55.0000 from January 1.
One tariff per utility per block, approved before use. A mid-period supplier increase is two rate lines, and every batch picks up whichever rate was in force on its own dates.

Billing and invoicing

In unit 4B the tenant pays electricity and the owner pays the service charge.

Every community has units like that, and every billing run gets them wrong at least once. So the payer is not a note in someone's head - it is a resolution chain that runs on every single charge and always ends in an answer.

01
This unit, this charge, this utility
The most specific rule wins: in 4B the tenant pays electricity but the owner pays water.
02
This unit, this charge type
In 4B the tenant pays all utilities.
03
The community default
Here, tenants pay utilities and owners pay service charges.
04
The unit's own setting
Owner only, tenant only, or mixed - set on the apartment itself.
05
The fallback
The unit's billing partner, or the primary owner. A payer is always found.
Service charges by rule
A priority-ordered rule set - fixed or per square metre, targeted by unit category, block or floor, with effective-from and effective-to dates. Rules are evaluated in order and the first match wins, so a specific rule cleanly shadows a general one.
Overrides, on the record
A unit that genuinely needs a different number is set to manual override and bypasses the rules engine entirely - and the resulting line is flagged as manual, so it is visible rather than mysterious.
One invoice per payer
Charges are grouped by the payer the chain resolved, so a split unit correctly produces two documents instead of one document and an argument.
A re-run cannot double-bill
Only charges not yet on an invoice are collected, and each one is stamped with the invoice line it produced. Run it twice by accident and nothing happens twice.
Your call on missing tenants
Where a charge should bill a tenant and the unit is empty, the run either stops and tells you, or falls back to the owner - configured before you press go.
Scope it how you work
The whole community, one block, or a hand-picked list of units. By billing month or by date range. Utilities and service charges included or excluded independently.
Debit notes
Same scope, period and payer logic, printed on their own template showing the block, the unit and the period, and kept distinct from invoices in the ledger.
Disputes, worked to a resolution
A challenged charge becomes a numbered, message-threaded record attached to the exact line it disputes, moving draft to under review to resolved or rejected - with the resolution text, the agreed amount, the date and the person who signed it off all kept.
Traceable both ways
From an invoice line back to the charge, the reading and the meter that produced it - which is what turns a dispute into a two-minute conversation.
Customer invoiceGenerated from the charges
Posted customer invoice INV/2026/00010 with charge lines for tennis court, gym and swimming pool totalling 11,000.00, and the standard Odoo Send, Print, Pay, Preview and Credit Note buttons.
What the run produces is an ordinary Odoo customer invoice - Send, Print, Pay, Credit Note, all standard - with the condominium charges as its lines and every one of them traceable back to the charge that raised it.

The hard case

A tenant left on the 14th. Who pays for the electricity?

Every property manager knows this one. The lease ended mid-period, the meter was read at month-end, and now three people have three different opinions about the split - none of which the outgoing tenant accepts, because none of them is based on anything they can see.

The billing run breaks the period into occupancy sub-periods by walking the actual tenancy records: owner before, tenant during, owner after. Then it does the thing that settles the argument. If a real move-out reading exists for that meter, the outgoing tenant is billed on actual consumption, not on a share of days. The rest is spread across the remaining occupants, and the final split absorbs the rounding so the parts add back to the metered total.

Every invoice line says which method it used. There is nothing left to argue about, because the arithmetic is printed on the document.

Utility Charges - 4B (01/09/2026 to 14/09/2026, 14/30 days, move-out reading)

An invoice line that explains itself. Where no move-out reading exists, the line says “estimated” instead - and says so on the resident's copy, not just in your database.

Owner and tenant splits generated from real lease dates
Actual reading preferred over day-count, every time
Departing tenant's access cards deactivated in the same step
Mid-Month Pro-Rata BillingStep 1 - scope
Mid-month pro-rata billing dialog: billing scope and company, billing period from and to, journal, post-invoices-immediately, and checkboxes to include utility and service charges, with an explanation of how the period is split by tenant move-in and move-out dates.
Scope, period and journal. The run splits each unit's period by the real move-in and move-out dates, and nothing is created until you have looked at the splits.
Apartment overviewStep 2 - before anything is created
Mid-month preview for unit A101: a warning that the tenant lease ends this billing period, owner Nuwan Perera, and two tenant splits - Dilshan Gunasekara for 12 of 31 days at 38.7 percent and Malithi Peris for 19 of 31 days at 61.3 percent - each showing service charges and electricity for the full period and for the split, both marked estimated, with invoice totals of 7,861.94 and 12,448.06.
One unit with a lease ending mid-period. Both splits here are day-prorated and labelled estimated, with the arithmetic shown. Where a real move-out reading exists, that split is billed on the actual reading instead and says so.

Dashboards

Five views of the same month, and one of them is the arrears list.

Every dashboard filters by community, year and month, and every table drills through to the record behind it. No exports, and nobody rebuilding the same figures in a spreadsheet at the end of each month.

Overview
Total, active, vacant and under-maintenance units, occupancy rate, total invoiced and outstanding, with a per-community breakdown.
Financial
Invoiced, collected and outstanding for the period, split between utility and service charge revenue.
Utilities
Consumption and value by utility, a six-period trend per utility, and the top ten consumers with a click through to the unit.
Occupancy
Owner-occupied against tenanted, the unit mix by category, and the fill rate of every unit type across the portfolio.
Property ledger
Invoiced, paid, outstanding and collection rate per unit, sorted by what is owed. The arrears worklist, without anyone building it.
OverviewCommand centre
Condominium command centre overview dashboard, filtered by community, year and month, showing total invoiced and outstanding balance tiles, an apartment status distribution chart across draft, active and under maintenance, a units-per-community chart, and a community summary row with 14 total units, 12 active and 85.7 percent occupancy.
The month in one screen: unit states, units per community, and an occupancy figure nobody had to calculate.
OccupancyOwner against tenant
Occupancy dashboard showing six owner-occupied units, six tenanted units and five unit categories, a tenanted versus owner-occupied donut, a units-by-category chart, an occupancy breakdown by community, and a table of occupancy by unit category with fill rates from 75 to 100 percent.
Who is actually in the building - owner-occupied against tenanted, by unit type, with the fill rate of each category.
Property ledgerApartment-wise
Property ledger dashboard listing every apartment with its community, block and floor, owners, tenant, state, and its invoiced, collected, outstanding and collection-rate figures, above tiles for total apartments, invoiced, collected, outstanding and collection rate.
Every unit with its owners, its tenant and its financial position on one line, sorted by what is outstanding - and a click on any row opens the unit itself.

The foundation

We did not write an accounting system. We billed into one.

Standalone condominium platforms have to build ledgers, tax engines and payment reconciliation from scratch, and then certify them market by market. BH Condominium doesn't, because its invoices are ordinary Odoo customer invoices with four condominium fields added - the unit, the billing month, the billing year, and whether the document is a debit note.

Everything Odoo Accounting already does therefore comes with it, on day one, with no integration in the middle: payment registration, reconciliation, partial payments, credit notes, tax, multi-currency, aged partner balances and the e-invoicing localisations of the country you operate in.

Each community is its own Odoo company, so its chart of accounts, journals, sequences and financial statements are separate by construction - which is what association law generally requires anyway - and Odoo's own multi-company rules keep one community's data out of another's.

A full property operation on top of a real ledger, at open-source cost.
Comes with the platform
Odoo 19

Not connected to accounting - running on it. Everything below is part of the same database as your units, leases and meters.

Payments & reconciliation

Registered against the invoice, matched to the bank, partial payments included.

Tax & localisation

VAT or GST and the e-invoicing rules of your jurisdiction, maintained by Odoo.

Aged receivables

Live, per community, without anyone rebuilding it in a spreadsheet.

Credit notes & follow-up

Standard documents and standard chasing, on the same ledger as everything else.

Four internal roles

Property admin, utility officer, accountant and manager, each implying the one below.

One database, separate books

Each community is its own company, with its own accounts, journals and statements.

Before the detail

Where we lead, where we match, and where we're going next

Every vendor has all three. Most only show you the first.

Where we lead
Utilities and turnover as a business process
  • Sub-meter registry with a real lifecycle and a billability gate
  • Bulk reading import with a two-phase validation pipeline
  • Three independent statistical anomaly tests, with scores and reasons
  • Common-area allocation by entitlement and area, reconciled to the cent
  • Mid-month turnover billing on actual move-out readings
  • Access credentials tied to the lease and closed by the move-out run itself
Where we match
What every serious platform does
  • Block, floor and unit structure with unit lifecycle states
  • Multi-owner percentage ownership and full tenancy history
  • A service charge rules engine with category, block and floor targeting
  • Consolidated invoicing with owner and tenant payer routing
  • Charge disputes raised and resolved on the record
  • Five analytical dashboards, and accounting and receivables through Odoo at lower cost
What our future looks like
Payments, operations and mobile
  • Online resident payments and auto-pay
  • Late fees, dunning ladder and account statements
  • Maintenance requests and work orders with photos
  • Amenity booking on the common areas already modelled
  • Budget and reserve fund accounting for regulated markets
  • A resident app, and a meter-reading app for your officers

The pattern is deliberate and worth saying plainly: this product is deep where the money is, and young where the engagement features are. If your decision rests on resident self-service today, read the next two sections before you go any further.

The comparison

How we compare, including where we don't

We reviewed the condominium and community-association software market in September 2026, capability by capability. Here is the result, with the rows we lose left in.

Capability comparison - BH Condominium against three leading community-association platforms
CapabilityBH Condominium BuildiumCondo ControlAppFolio
Multi-owner percentage ownership YesPartialYesYes
Access credential management YesNot offeredYesNot offered
Charge dispute workflow NativeVia helpdeskVia requestsVia helpdesk
Accounting, receivables and tax Same databaseBuilt inIntegrationBuilt in
Sub-meter registry with status lifecycle Built inLimitedNot offeredLimited
Bulk meter reading import with validation Excel, two-phaseNot offeredNot offeredNot offered
Statistical anomaly detection on consumption Three methodsNot offeredNot offeredNot offered
Date-effective tariffs per block With approvalNot offeredNot offeredPartial
Common-area consumption allocation By entitlement & areaFlat allocationNot offeredFlat allocation
Mid-month pro-rata turnover billing On actual readingsManualNot offeredPartial
Online resident payments PlannedYesYesYes
Late fees and automated dunning PlannedYesPartialYes
Maintenance requests and work orders PlannedYesYesYes
Amenity booking PlannedYesCategory leaderPartial
Budget and reserve fund accounting PlannedYesIntegrationYes
Native resident mobile app PlannedYesCategory leaderYes

Competitor capabilities per our September 2026 review of Buildium, AppFolio, Condo Control, TOPS [ONE], Yardi Voyager, MRI and the Odoo real-estate app ecosystem (vendor documentation, Software Advice, Capterra, G2 and published comparison guides). “Integration” means delivered through a separate connected product. Vendors change. Verify directly before you decide.

Straight answer · what we don't do yet

Six things we can't do, and one reason we're telling you

A resident cannot pay you inside this system today, and there is no app. If that is what decides this purchase, the established platforms are ahead of us right now. We would rather you heard it from us on this page than found it out in month three.

  • Planned

    Online paymentsInvoices are issued and reconciled in Odoo, but residents pay by bank transfer today - there is no card or direct debit in the product.

  • Planned

    Late fees and dunningArrears are visible on the property ledger. Chasing them is still a person's job.

  • Planned

    Maintenance and work ordersNo resident request flow with photos, routing and status yet.

  • Planned

    Amenity bookingCommon areas are modelled and their entitlements are known. Booking them is not built.

  • Planned

    Budget and reserve fundsOperating and reserve fund separation is required by law in several markets. It is not here yet, and we will say so before we quote you in one of them.

  • Planned

    Resident self-serviceNo app, no push notification, and no online resident self-service we are willing to put in front of you yet - nor an offline meter-reading app for your officers.

Those six are the roadmap, roughly in that order - payments and collections first, then operations, then mobile. No dates promised on a marketing page. Ask us for the current plan and we'll show you the whole document, including the parts that are not flattering.

Everything else on this page is implemented and running. If a vendor's comparison table has no losing rows, ask them why.

Anything we haven't answered? Call +94 76 664 6664 and ask us directly.

Before you ask

The questions we get every time

Who is this actually for?

Property management companies and developer-operators running roughly 200 to 5,000 units across multiple towers or communities. The product covers the whole monthly cycle - the property register, ownership and tenancy, access credentials, service charges, invoicing, disputes and the dashboards - so it stands up whether or not your communities are individually sub-metered. Where they are, the utility side goes considerably deeper than the mainstream platforms, and that is usually what decides it.

What if our communities aren't sub-metered?

Then you use the rest of it, and it is worth saying so in the first meeting so we scope accordingly. The property register, multi-owner and tenancy records, access credentials, the service charge rules engine, consolidated invoicing with owner and tenant payer routing, disputes and the five dashboards all work with no meters in the picture - service charges run off fixed or per-square-metre rules rather than consumption. What you would be leaving unused is the metering depth, which is a large part of what makes us the cheaper answer for a sub-metered portfolio. If nothing you manage is metered and nothing will be, we will tell you plainly whether we are the right fit.

How is a mid-month move-out actually billed?

The billing period is split into occupancy sub-periods from the real lease dates - owner before, tenant during, owner after. For each utility, if a genuine move-out meter reading exists for that unit inside the period, the departing tenant is billed on that actual consumption and the line says so. The rest is spread across the other occupants by days, marked estimated, with the last split absorbing the rounding so the parts add back exactly to the metered total. Every split is shown to you, editable, before a single invoice is created. And the departing tenant's access cards are deactivated in the same step.

Can residents pay online?

Not yet. Invoices are issued and reconciled in Odoo, but payment happens by bank transfer today. Online payment and auto-pay are the first items on our roadmap, and Odoo's payment providers make it far more of a configuration and interface exercise than a rebuild. We are not promising you a date on a web page - ask us where it stands the week you're evaluating.

How are service charges calculated?

Off a priority-ordered rule set rather than a formula buried in code. Each rule is either a fixed amount per unit or an amount per square metre of net area, and can be targeted at a unit category, a block, a floor, or any combination - leave a targeting field empty and it matches everything. Rules carry optional effective-from and effective-to dates, they are evaluated in sequence, and the first match wins, so a specific rule cleanly shadows a general one. Where a single unit genuinely needs a different number, you set it to manual override and the resulting line is flagged as manual so nobody has to wonder later.

What happens when the utility supplier changes the tariff mid-period?

You add a rate line with the date it takes effect, and it gets approved by whoever is allowed to approve it. Rates are held per utility per block and carry four decimal places, because two decimals round real money away when you multiply by a thousand units. Nothing needs to be rebuilt, and the change carries its own discussion and audit history on the record.

Why build this on Odoo instead of as its own product?

Because the accounting is the hard part, and it already exists. Invoices here are ordinary Odoo customer invoices with four condominium fields on them, so payment registration, reconciliation, partial payments, credit notes, tax, multi-currency, aged receivables and local e-invoicing all work on day one. A standalone platform has to build and certify that itself, in every market it enters, and charge you for it.

Can we run several communities from one system?

Yes. Each community is its own company inside Odoo, so it gets its own chart of accounts, journals, sequences and financial statements - which is what association law generally expects - and one community's data is kept out of another's by Odoo's own multi-company rules. The trade-off is honest: per-community reporting is excellent by construction, and consolidated cross-community reporting is something we build for you rather than something that comes free.

Is there an app?

No - and no resident self-service we would show you yet either. There is no installable app, no push notification and no offline meter-reading app for your utility officers. Two thirds of condominium owners say they would rather deal with their building through an app, so we are not going to pretend this is a small thing. It is on the roadmap, and it is the honest answer to the question most competitors would answer with a screenshot.

Do we own our data?

Yes. The database is yours and you can export it in full at any time. You are not locked into us as a supplier in order to keep operating, and that is a deliberate choice on our part. It is worth asking every vendor on your shortlist the same question, and noticing which ones need a moment before answering.

How long does implementation take?

It depends on how many communities and units you're bringing, how clean the property and meter registers are, and whether you're migrating billing history. Setting up the register and, where they exist, the meters and tariffs is usually the long pole - the rest is configuration. We scope it properly before quoting rather than giving you a number we would have to walk back later. Ask for the timeline in writing, from us and from everyone else you're talking to.

Bring us last month's billing run.

The spreadsheet, the arrears nobody had time to chase, the disputes it caused, and the one move-out nobody could agree on. We'll show you what the same month looks like in the system.

Usually a reply within one business day

Company

Beaver Hub (Pvt) Ltd

Address

Ethul Kotte, Sri Lanka

Phone+94 76 664 6664
Email[email protected]