If you’ve ever sat in a Yardi deployment meeting and heard somebody say “we’ll just pipe Voyager to Power BI,” you already know the next nine months of your life. Voyager is a system of record. It is not a warehouse. There are three — sometimes four — paths from Voyager into a warehouse, each with its own cost, cadence, and failure mode. This guide is the one we wish we’d had when we deployed our first Yardi pipeline.
The three ways Voyager data leaves Yardi
At the risk of irritating our friends at Yardi, the paths from Voyager to your warehouse collapse into three real options plus one fallback.
1. Yardi Data Connect
Data Connect is Yardi’s officially-sanctioned pipe to Microsoft Power BI. It is a Snowflake-backed replica of your Voyager database, refreshed on a cadence Yardi controls (usually daily, occasionally more frequently for enterprise customers). Data Connect is priced per-database and per-user; pricing is not published, but customers we’ve worked with land in the $18–40K/year range depending on database size and user count.
When to use it: You’re already standardized on Power BI, you’re okay with daily refresh, and you want Yardi to own the pipeline so IT doesn’t have to. Data Connect is the least-friction path for a Power BI-first shop.
When to avoid it: You need sub-hourly freshness. You need to join Voyager data with non-Yardi sources (your insurance carrier, your leasing platform, your HR system). You want to run Looker or Tableau natively instead of Power BI. You want sub-second query response on dashboards (Data Connect is not tuned for that).
2. Yardi Replicate (via Qlik)
Replicate is the change-data-capture (CDC) pathway. Through a Qlik-based connector, Replicate streams near-real-time changes from Voyager into your destination of choice: Snowflake, AWS S3/Redshift, Azure Synapse, or Databricks. This is the pathway Yardi markets at operators who want a real warehouse, not a Power BI-only handoff.
Published pricing is scarce, but the operational pattern we see is $25–60K/year for Replicate licensing plus the Qlik infrastructure, plus whatever your destination warehouse costs (usually Snowflake at $500–3,000/month for a 5,000-unit operator).
When to use it: You want sub-hour freshness, you want your own warehouse in your own cloud account, and you want to mix Voyager data with other sources at the warehouse layer rather than in a BI tool. Replicate is the enterprise-grade path.
When to avoid it: You’re at under 1,000 units and the all-in cost of Replicate + Qlik + Snowflake eats half your analytics budget. For those operators, path #3 is usually saner.
3. Scheduled YSR export to cloud storage
The path Yardi does not advertise loudly, but which is perfectly legitimate in the ICN framework: schedule a YSR (Yardi SQL Report) or SSRS package to run nightly, export to CSV or Excel, and drop the file in an SFTP or S3 bucket your warehouse picks up.
This is what a startup Yardi shop with 500–2,000 units can actually afford. It is also what every Yardi consultant we know secretly reaches for when Data Connect is blocked or Replicate is priced outside the budget.
Cost: The YSR licensing is included in your existing Voyager seat. The bucket is $5/month. The loader is a few hundred lines of Python. Call it $200/month all-in plus the warehouse.
When to use it: You’re under 5,000 units, you’re okay with nightly latency, and you want to run in your own cloud account without buying a new Yardi module. This is the path we default to for small and mid-market clients who haven’t yet licensed Data Connect or Replicate.
When to avoid it: Your ops team can’t tolerate nightly lag. You have compliance requirements that demand audited, vendor-sanctioned extraction (common in LIHTC / HUD contexts).
4. The fallback: direct SQL access
Some Yardi deployments — especially legacy on-premise installations and ICN-partner hosted environments — allow direct SQL access to the Voyager database. This is the highest-power path and the one that makes Yardi’s legal team the most uncomfortable.
We mention it for completeness. We do not recommend it as a default — Yardi’s Interface Partner Program exists for a reason, and direct SQL is the fastest way to end up on the wrong side of a TOS conversation during a renewal.
The reference architecture
For a 5,000-unit, multifamily-dominant operator with 3 funds, 2 asset classes, and a quarterly investor reporting rhythm, here is the stack we default to:
Voyager (system of record)
│
├── Data Connect (if licensed) ──┐
├── Replicate → CDC → cloud ─────┤
└── Nightly YSR → S3 / GCS ──────┤
│
▼
┌──────────────────────┐
│ Snowflake / BigQuery │ ← client cloud account
│ (raw / staging) │
└──────────────────────┘
│
▼
┌──────────────────────┐
│ dbt models │
│ (rent_roll, t12, │
│ ar_aging, bva, │
│ leasing, rollups) │
└──────────────────────┘
│
┌───────────┴────────────┐
▼ ▼
Power BI / Looker AI narrative layer
(6 dashboards) (variance, letters,
alerts, Q&A)
Three things matter about this picture:
-
The warehouse lives in your cloud account. Not ours. You own the credentials, you see the bill, you can rotate us out without data migration. This is non-negotiable for any vendor on this picture; if a BI vendor insists on holding your warehouse, ask them to explain why.
-
dbt is the model layer — not Power BI datasets. The instinct on Yardi projects is to push business logic into Power BI. Don’t. Dashboards come and go. SQL lineage in dbt is how you get a warehouse that survives a staff transition.
-
The AI narrative layer is downstream of the warehouse, not parallel to it. Retrieval for the narrative model runs over the same dbt-modeled data your dashboards query. Same numbers on the page, same numbers in the memo. No reconciliation conversations at 11pm before the board call.
The dbt model layer, in detail
The dbt models that justify their existence in almost every Yardi deployment:
Rent roll (rent_roll)
One row per unit per reporting period. Columns: property, unit, bed/bath, sqft, market rent, in-place rent, charge / credit types, occupancy status, lease start, lease end, next renewal date, notice-given flag, concession accrual. The single most-queried model in a Yardi warehouse. Latency-sensitive — your VP of asset management checks this daily.
Operating statement T-12 (t12_operating_statement)
One row per property per GL account per month for the trailing 12 months. Columns: property, gl_account, gl_code, category (income / operating / utilities / R&M / payroll / etc.), amount, prior_year_amount, prior_month_amount. The T-12 is the spine of every variance memo you will ever write. Get this model right and everything downstream gets easier.
AR aging (ar_aging)
One row per tenant per aging bucket (current, 30, 60, 90+). Columns: property, tenant, unit, charge_type, current_balance, 30d, 60d, 90_plus, last_payment_date, days_since_last_payment. AR aging is the single most predictive signal for anomaly detection — almost every operational problem shows up here first.
Budget vs actual at GL level (bva_gl)
One row per property per GL per month. Columns: property, gl_account, gl_code, category, budget, actual, variance, prior_year_actual. This is the source table for the variance commentary. Everything the AI narrative layer has to say about “what drove the month” comes from this model.
Leasing funnel (leasing_funnel)
One row per lead per stage (applied / approved / leased / moved-in / renewed). Columns: property, lead_source, stage, days_in_stage, concession_applied, rent_rate. Most Voyager shops either don’t run this model or build it from RentCafe rather than Voyager — we’ve seen both patterns.
Portfolio rollup (portfolio_rollup)
One row per fund / region / asset class per period. Aggregates everything above. This is the model the investor letter layer queries.
The real-world costs (a 5,000-unit multifamily operator)
| Line | Monthly | Annual | Notes | |---|---|---|---| | Yardi Voyager seat | — | existing | Baseline Voyager licensing | | Data Connect or Replicate | $1,500–5,000 | $18,000–60,000 | Pick one — not both | | Snowflake (dev + prod, idle-aware) | $600–1,500 | $7,200–18,000 | Client-owned account | | dbt Cloud (team plan) | $300 | $3,600 | Optional; dbt Core is free | | Power BI Pro or Looker | $10–30 / user | $120–4,000 | Your call | | Cloud egress + S3 / GCS | $30–120 | $360–1,400 | Minimal if warehouse colocated | | Analyst retainer | $4,000–5,500 | $48,000–66,000 | Memowright fractional analyst | | AI narrative add-on | $1,500 | $18,000 | Variance + letters + alerts + Q&A | | Total all-in (mid-case) | ~$9,000 | ~$108,000 | vs. $260–360K loaded in-house hire |
These numbers are rough ranges and they will change as your portfolio changes. What’s stable is the order-of-magnitude answer: a production-quality Yardi warehouse + dashboards + AI layer runs roughly a third to a quarter of an in-house BI team.
The four failure modes we see every time
After every Yardi pipeline we’ve deployed, the same four things have gone sideways at least once. Plan for them.
1. The “our YSR report already does this” trap
Every Yardi shop has a few YSR reports that have been running forever, produced by someone who left the company in 2019, with SQL nobody’s read since. When you stand up a new warehouse, half of your stakeholder audience will ask why they can’t just keep running those YSR reports. Plan for a phased decommission. Don’t try to turn them all off at once.
2. GL mapping drift between entities
Multi-entity operators almost always have GL mapping drift — fund 1 uses “6210 R&M
turns,” fund 2 uses “6214 R&M turnover,” fund 3 rolls both into
“6200.” Your warehouse needs an explicit normalization layer that unifies
GL codes across entities without hiding the original. The model layer should expose both
gl_account_raw and gl_account_canonical.
3. Concessions accounting
Voyager lets operators book concessions two ways (cash basis at time of move-in, or accrual across the lease term). The method chosen affects variance commentary dramatically — a concession-heavy month looks very different under cash vs. accrual. Document the method explicitly in your model and surface it in the AI narrative layer’s grounding context.
4. AR aging buckets
Yardi’s default AR aging is based on charge date, not lease date, and bucketing conventions differ between the finance team’s view and the operations team’s view. Build both perspectives. Pick the one your CFO actually uses for the investor letters. Surface the other as a toggle.
When you should use Memowright to build this stack — and when you shouldn’t
We (Memowright) exist because deploying this stack is slow, expensive, and full of the failure modes above. Our retainer delivers it in 2–3 weeks for a flat fee and runs the analyst seat afterward.
Don’t hire us if: you already have a senior Yardi data engineer on staff, you’re happy with Power BI only and Data Connect covers it, or you’re under 1,000 units and your close process is already working fine.
Do hire us if: your finance team is in Excel hell because YSR doesn’t export with live-data links, you’re between 2,000 and 20,000 units, and you want the AI narrative layer that doesn’t exist elsewhere on the market today.
Either way — the architecture above is the architecture. Whoever builds it, this is the shape.
Related reading