Setting Up Property-Management Accounting

This is the master setup guide for property-management accounting in REDA — the configuration that lets your property records on one side and your books on the other work as one system. When it's done, rent invoices post to the right owner's ledger, management fees bill themselves, owners get paid and get statements, and every figure can be reported by property, building, and portfolio. This page walks the entire setup end to end, in the order you should do it, and explains every item: what it is, why it matters, and what breaks if it's wrong. It's the hub — each phase links to a detailed article — but you can execute the whole thing from here. No prior accounting-integration experience is assumed; every concept is defined as we reach it.

The two-party model you're configuring

Before the steps, hold one picture in mind. Property-management accounting always involves two sets of books:

• The landlord entity — each property owner's own books. Rent a tenant pays is collected into the owner's books; owner payouts come out of them.
• The PM entity — your property-management company's own books. This is where the management fee you earn lands as revenue.

An Entity in REDA Financials is simply a separate set of books — its own ledger, currency and fiscal year. Every landlord you manage typically has one, and your management company has one too. A property ties the two together: it names its Owner Account (→ the landlord entity) and its PM Entity (→ your company's entity). Almost everything in this setup is about giving each entity the banks, products and mappings it needs so money moves correctly between the two.

Throughout this guide we'll use one worked example: Meridian Properties is the management company; Continental Holdings is a landlord who owns two buildings, Meridian Court and Harbour Tower, that Meridian manages on its behalf.

The setup, in order

Here is the whole thing as a checklist — tick each item as you complete it. Every phase has its own detailed section below and, where it's deep, its own article. Do them roughly in this order: later phases depend on earlier ones.

• 1. Turn on the accounting extension. The master switch that connects REDA to accounting. Usually already on — confirm it.
• 2. Activate each entity and configure its banks & products. Turn each landlord and your PM company into a set of books, then give each one its Operations Bank, Settlement Bank, fee products, owner-draw product and administration property.

• 3. Map each charge code to accounting. Tell every charge code its Product, GL Account, Cost Center and Tax Profile.
• 4. Tag the property-management GL accounts. Flag the rent-income, expense, asset and liability accounts so the fee, draw and statement runs know what to count.
• 5. Set the property dimensions. Give each property its Portfolio, Region, Property Type and Parent Property so finance can report by property, building and portfolio.

• 6. Mark payees. Confirm who can be selected when recording a tenant payment (lessees are handled for you).
• 7. Configure NSF fees (optional) — auto-bill a fee when a payment bounces.
• 8. Set up electronic payments (EFT) (optional) — bank originator details and standing instructions for ACH collections and payouts.

• 9. Set the owner-statement send day (optional) — build each portfolio and choose the day of month its statement emails, then schedule the statement job.
• 10. Confirm the billing bridge. Raise a test invoice and confirm it posts to accounting with no error.

Phase 1 — Turn on the accounting extension

The accounting extension is the single master switch that connects REDA to REDA Financials. Every accounting automation — posting invoices, syncing payments, creating entities, running fees, draws and statements — checks this switch first. With it off, the whole integration sits dormant: nothing posts, nothing syncs, no entity is ever created.

You'll find it in the REDA Admin Console (App Launcher → REDA Admin → REDA Admin Console) on the Global App Settings tab, as the accounting extension setting. In most orgs your implementation partner enables it during onboarding, so your job here is usually just to confirm it's on.

Phase 2 — Activate each entity, then configure its banks & products

This is the biggest phase, and the foundation everything else stands on. You'll do it once for your PM company and once for each landlord.

Activating the entity

Turning an account into a set of books is a one-checkbox job. On the account (App Launcher → REDA → Accounts), check Financial Active and save — REDA automatically creates a matching Entity and links it back to the account. But three things must be true before you check the box, or no entity is created:

When you save, the new Entity arrives ready — name, code, region, currency, territory, an accrual accounting basis and an active status are all filled in for you. There's nothing to key in on the Entity to bring it into existence. The full walkthrough (and exactly what the Entity looks like) is in Activating a Client Account as a Financial Entity.

Configuring the entity's banks & products

An activated entity is a set of books, but the property-management runs need to know which banks the money moves through and which products carry the right general-ledger accounts. You set these on the entity record. Not every field applies to every entity — some belong on the PM company, some on the landlord:

Two more entity defaults — set as part of standard accounting onboarding — matter here because the runs rely on them: a Default Bank Account (the rent-escrow account the fee settlement draws from) and a Default Cash Account and Default Ledger (used when you record a tenant payment). Configuring those accounts is covered in the REDA Financials help center.

Phase 3 — Map each charge code to accounting

A charge code is REDA's reusable definition of something you bill — rent, a deposit, a late fee, a move-in fee. When a lease bills one, accounting needs to know how to turn it into a ledger line. You teach it that on the charge code itself: App Launcher → REDA Admin → Charge Codes, then open each one.

Phase 4 — Tag the property-management GL accounts

The fee, draw and statement runs don't read your whole ledger — they only look at the accounts you've told them are property-management money. You do that by flagging each relevant general-ledger account as a Property Management GL Account. This single flag is the master switch for what "counts":

Phase 5 — Set the property dimensions

Property-level accounting is only useful if you can report on it — income by property, by building, by portfolio. REDA makes that possible by carrying five dimensions from each property onto every accounting document it generates. You set them on the property record (App Launcher → REDA → Properties):

You don't need to register these dimensions with accounting — that's already built in and active. Your only job is to make sure each property actually has its Portfolio, Region, Property Type and Parent Property filled in, because a blank dimension shows up as a blank column in the reports. The reporting side is covered in Property Dimensions in Financial Reports.

Phase 6 — Mark payees

When you record a tenant's payment (Phase 10 and the everyday Recording Tenant Payments flow), you pick a payee — the person the payment is attributed to. For standard leases this needs no setup: anyone whose role on the lease is Lessee is automatically eligible and appears in the payee list. You only take action for a non-lessee payer (say a guarantor or a company paying on a tenant's behalf) — in that case an administrator marks that contact role as a payee so it shows up in the dropdown.

Phase 7 — Configure NSF fees (optional)

An NSF fee ("non-sufficient funds") is what you charge when a tenant's payment bounces. REDA can raise it automatically: when a recorded payment is later voided, it creates a fresh fee invoice that flows straight back through the billing bridge. You switch this on per account. On the tenant's (or landlord's) Account, set:

Leave these blank and voiding a payment simply reverses it, with no fee. This phase is optional — set it up only for accounts where you want automatic bounce fees.

Phase 8 — Set up electronic payments, EFT (optional)

If you collect rent or pay owners electronically, REDA can generate the bank file (ACH / NACHA) for you. There are three layers to configure, and each is optional depending on whether you use electronic banking at all:

When you run the processor for a date, REDA gathers the instructions that are due, creates the matching receipts or payments, and produces a bank file you download and upload to your bank. The full walkthrough is in Bank EFT / NACHA Processing.

Phase 9 — Set the owner-statement send day (optional)

REDA can email each owner a branded statement — income, expenses, distributions and balances for their properties — on a schedule. Statements are organized by Portfolio (a grouping of owner accounts and properties). To turn on automatic statements:

Owner draws (paying owners their money) and statements are covered together in Owner Draws & Owner Statements.

Phase 10 — Confirm the billing bridge

The billing bridge is the runtime path that turns a property invoice into a posted invoice in accounting. You don't switch it on per invoice — new standalone invoices arm themselves automatically, and invoice batches are armed when you set them to create the accounting entry. What you do need is for the earlier phases to be complete, because the bridge relies on them:

• The invoice's Default Receivable Account must be set, and that account must be an activated entity (Phase 2).
• The charge code behind each line must be mapped (Phase 3).

To confirm everything is wired up, raise one test invoice on an activated account and check that it produced a posted invoice in accounting with no error. If it did, the bridge is working; if it shows an Accounting Error Message, read the message — it names what's missing — fix it, then clear the message to let the invoice retry. How posted amounts and payments sync back is covered in Payments & Balance Sync-Back, and the whole integration picture is in How REDA Works with REDA Financials.

How it all flows once set up

With the setup complete, here's the sequence that runs on its own — no per-transaction configuration:

Through all of it, the five property dimensions ride every posted document — so finance can report profit and loss by property, building, portfolio, type and region without any extra tagging.

Reference: the setup at a glance

One row per phase — what you set, where, and what breaks if it's wrong:

Reference: entity settings

Reference: what each run produces

Worked example: onboarding Continental Holdings

Meridian Properties takes on a new owner, Continental Holdings, who owns Meridian Court and Harbour Tower. Here's the whole setup applied to them:

An activated PM-company Entity (Meridian Properties). The Management Fee Configuration section shows the Management Fee Revenue Product, Settlement Bank, Operations Bank and Administration Property all filled in — the defaults a management-fee run draws on to bill the fee, book the cost and settle the cash.

Where to go next

1. Activating a Client Account as a Financial Entity — Phase 2 in full, with everything the auto-created Entity contains.
2. Charge Code Accounting Setup — Phase 3 field by field.
3. Management Fee Automation — how the fee run calculates and bills once set up.
4. Owner Draws & Owner Statements — Phase 9, plus paying owners their balances.
5. Bank EFT / NACHA Processing — Phase 8 in detail.
6. Property Dimensions in Financial Reports — Phase 5 and the reports it powers.
7. Recording Tenant Payments — the everyday payment flow this setup enables.
8. How REDA Works with REDA Financials — the whole integration at a glance.

Frequently asked questions