How REDA Works with REDA Financials

REDA runs your properties, leases and billing. When you also run the accounting extension — REDA Financials — a second product sits alongside REDA and takes over the money side: tax, receipts, cash application and the general ledger. The two are wired together so tightly that a rent invoice raised in REDA becomes a posted accounting document in REDA Financials on its own, with no export, no overnight sync and no middleware. This article maps that seam: what each product owns, the switch that turns the connection on, and how a single invoice travels from a lease charge to a posted document and back again. It stays at the surface — where REDA hands off — and points you to the REDA Financials help center for what happens once the accounting side takes over.

Two products, one flow of records

Think of a rent invoice as a baton in a relay. REDA runs the first leg: it holds the lease, works out the charges, and raises the invoice the tenant owes. At a clean line — the receivable — it hands the baton to REDA Financials, which runs the second leg: it turns that invoice into a posted accounting document, applies tax, records the receipt when the tenant pays, and files everything in the ledger. REDA's billing engine deliberately stops at that boundary; the accounting extension owns tax, cash application and the general ledger.

The handoff happens the moment the invoice is ready — it is event-driven and lives entirely inside your single workspace. There is no nightly job, no file transfer and no external connection for this seam. That's why an invoice you raise in REDA shows up in accounting within moments, not overnight.

What each product owns

The cleanest way to hold the two products in your head is by the records each one is responsible for. REDA owns everything up to and including the invoice; REDA Financials owns everything the invoice turns into.

You'll notice REDA displays money it doesn't calculate. A REDA invoice shows a Tax Amount, a Received Amount, a Waived Amount and an Adjustment Amount — but REDA never writes those itself. The accounting extension supplies them, and REDA folds them into the invoice's balance and total. So if an invoice shows an amount received that you never keyed in, that's expected: it flowed back from the posted receipt (see How payments come back).

The switch that turns it on

The whole integration hangs on one setting. Your administrator registers exactly one accounting extension for the workspace; on an organization running REDA Financials, that's the REDA Financials extension. Until it's registered, every integration behavior described here stays dormant — invoices are raised in REDA and simply never travel anywhere.

You don't toggle this per invoice or per lease; it's a one-time, workspace-wide registration your administrator makes during setup. When it's on, the connection is live for every eligible invoice from that point forward. When it's off — which is the default for a fresh workspace — REDA runs on its own and none of the accounting records in this article are created.

How an invoice becomes an accounting document

This is the core of the seam, and it's worth walking slowly because it explains almost everything you'll see on a bridged invoice. When REDA raises a single invoice, the following happens on its own:

If any check fails — most often a receivable account that hasn't been activated as an entity — REDA writes the reason onto the invoice's accounting-error field instead of creating the document, and simply doesn't try again until the error is cleared. That's the safety net that stops a broken invoice from bridging over and over.

What carries over to the accounting document

When you open the resulting Sales Invoice and wonder where a value came from, this is the map. Everything on it is copied from the REDA invoice at the moment of the handoff.

How payments come back

The relay runs in both directions. Once the tenant pays and REDA Financials posts the receipt, the money finds its way back onto the REDA invoice. When a Sales Invoice is Posted, its paid, tax and credit amounts are copied back to the REDA invoice's Received, Tax and Waived amounts — which is why those fields fill in without you touching them. If the accounting document is later moved to Draft or voided, the amounts clear again. For a consolidated batch, the received amounts are spread proportionally across the child invoices.

That's the summary; the full round trip — recording a tenant payment, how credits and refunds reflect — lives in Payment & Balance Sync.

Worked example: one month's rent, round trip

Aisha Rahman rents Meridian Court #101 for 1,200.00 a month. Her July rent invoice has a Billing Date of July 1 and is due July 5. Here's the whole trip:

A REDA Opp Invoice (OI-0000000070) that has bridged to Financials. In its REDA Financials block the Sales Invoice field is stamped with the matching Financials record, Create Bill is checked and the Accounting Error Message is blank; the Sales Invoices (1) related list on the right links straight through to the posted Sales Invoice it raised.

The matching Sales Invoice in REDA Financials — the record the REDA Opp Invoice posted through to. Its Status reads Posted (the Invoice Summary panel carries the green POSTED badge), Customer is Aisha Rahman [ Lease ] and the Invoice Balance Due is $350.00. This is the accounting-side twin of the REDA invoice above.

The seam at a glance

The billing bridge is the busiest touchpoint, but it isn't the only one. Each place the two products meet has its own article — start here, then follow the one you need.

Where to go next

1. Charge Code Accounting Setup — the defaults every invoice line depends on; set these first.
2. Activating a Client Account as a Financial Entity — the ledger an invoice posts into.
3. Payment & Balance Sync — how received amounts flow back onto the invoice.
4. Recording Tenant Payments — logging a payment against a lease.
5. From Application to Move-In — when a lease turns billable in the first place.

Frequently asked questions