Almost every Yardi client I work with has the same hidden infrastructure: a folder of Excel workbooks someone built by hand to answer questions Voyager “doesn’t have a report for.” Property managers email PDFs to accounting. Accounting copy-pastes them into a master file. Someone reconciles it on Friday. Then they do it all over again the next month.
Most of those workbooks could be replaced by one custom Yardi report that runs in 90 seconds. The reason they aren’t is that custom reporting in Voyager has a reputation for being complicated, and to be fair, parts of it are. But the path from “I need a report Yardi doesn’t have” to “I have a report Yardi runs for me every Monday morning” is more navigable than most clients realize, once you know what you’re actually dealing with.
This is what’s going on under the hood when you build a custom report in Voyager, and what you can realistically do in-house versus what is going to cost you a weekend with a consultant.
How Yardi’s reporting architecture works
Voyager has two categories of reports you’ll deal with day-to-day.
Standard reports are the canned ones. Rent rolls, income statements, AR aging, owner statements. You can filter them by property, date, and status. You can’t change the columns, you can’t add a calculation, and you can’t bend them to a different audience. They are what they are.
Custom reports in Voyager almost always means YSR, or Yardi Spreadsheet Reporting. Yardi’s own documentation calls it “the most flexible and customizable Voyager reporting technology” they offer, and they’re not exaggerating. YSR connects Voyager data to an Excel or Word template you’ve designed yourself, drops placeholders where the data should go, and renders the report on demand. If you’ve ever opened a Yardi-generated Excel report and wondered why it looks so polished, with pivot tables, color-coded sections, and formulas that tie back to inputs, that’s YSR doing the work.
There are other reporting tools in the Voyager world. SSRS is the older SQL Server Reporting Services framework, still in use at some clients, but Yardi has been pushing migration to YSR for years. Columnar reports and Voyager ad hoc reports cover niche cases. Yardi BI is the separately-licensed enterprise analytics module, which is a different ballpark and a different price tag. For the vast majority of “I need a custom report” requests, YSR is the answer.
Two paths to a custom report
YSR pulls data in one of two ways, and which one you pick determines whether you can build the report yourself or you’re going to need someone who writes SQL.
Path 1: Voyager analytics, no SQL
Voyager ships with dozens of pre-built data sources Yardi calls “analytics”: Financial Analytics, AR Analytics, AP Analytics, Commercial Analytics, and so on. Many of these are exposed to YSR. If one of them returns the data you need, you can build a custom report by mapping that analytic to a template you design in Excel. No SQL involved.
This is the path I push clients toward whenever it works. Two reasons. First, you don’t need a database person; anyone who can edit an Excel template and follow setup instructions can do it. Second, your data ties out perfectly. You’re using the same engine that powers Voyager’s screen-level reports, so your custom report and your standard rent roll will agree on the numbers.
The catch is that you’re limited to what the analytic gives you. You can reformat the output, you can sometimes add a single extra column using custom tokens, and you can wrap the whole thing in a beautiful template. But you can’t fundamentally change what data comes out. If the analytic doesn’t pull lease option dates and you need lease option dates, you’re stuck.
Path 2: Custom SQL scripts, real flexibility
This is where most of the interesting work happens. With a custom SQL script you can pull anything in your Voyager database. Multi-table joins, calculated fields, conditional logic, period-over-period comparisons, multi-entity rollups. There’s no real limit except your SQL ability and your knowledge of how Yardi’s schema is laid out.
The price of that flexibility is technical skill. Yardi’s own training path for YSR report writers includes courses called “Basics of Database Schema & SQL,” “SQL Scripting,” and “SQL Scripting: Advanced Topics.” That should tell you what you’re signing up for. Yardi’s schema has quirks (surrogate keys called hmy on every table, sign conventions on the GL that flip depending on account type, dozens of foreign-key relationships you have to know in your head), and the learning curve is not trivial.
In practice, most useful custom reports end up using both paths. One section of the report pulls from a Voyager analytic; another section runs a custom SQL script for the data the analytic can’t produce. YSR is happy to combine them in a single template.
Before you build anything: define the report
The number one mistake I see, and I’ve seen it at clients who pay for senior people’s time, is jumping into setup before deciding what the report is for. Yardi’s documentation recommends a written mockup before you touch the system. They’re right. A 20-minute design session up front saves a day of rework on the back end.
Four questions worth answering before you log into Voyager:
- Who’s reading this? A report for your accounting team isn’t the same as a report for your property owners, which isn’t the same as a report for your maintenance coordinator. Different audiences need different fields, different formatting, and very different levels of detail. The accounting team wants every line; the owner wants a summary.
- What’s the one question this report answers? The clearest reports answer one question. Which leases expire in the next 90 days. Which properties are over budget on maintenance. Which tenants are 60+ days past due. Reports that try to answer five questions at once produce output nobody reads.
- Snapshot or period? A vacancy report is a snapshot. What’s the state of things right now. A maintenance cost report is a period. What did we spend between A and B. This decides everything about how the SQL is written and how the filters work.
- What format does the audience need? YSR can output to Excel, Word, PDF, or directly to screen. Owners often want a polished PDF packet. Internal teams usually want Excel they can manipulate. Investor distributions might need a Word document with merge fields. Pick once, design around it.
How YSR setup actually works
YSR setup isn’t drag-and-drop. It’s a series of configuration screens in Voyager that you fill out in a specific order. The work happens in two places: inside Voyager (the setup screens) and outside Voyager (the SQL script files and Excel or Word templates that live on the file system). Here’s the shape of the process.
Create the report and define filters
You start on the YSR Report Setup screen at Admin > YSR Correspondence > Setup Report. That’s the actual path; don’t go looking in the regular Reports menu. You give the report a code, a description, and you define the filter fields the user will see at run time. Property pickers, date ranges, status filters. These are what make the report reusable.
Point the report at a data source
You add one or more report sections. Each section is mapped to either a Voyager analytic (selected from a dropdown) or a custom SQL script (you point Voyager at a text file containing the SQL). You then map your filter fields to the data source so the user’s filter choices actually filter the data.
Top-level select and key column
If the report should iterate (generate one PDF per property, say, or one workbook per tenant), you write a top-level select statement that returns the list of things to iterate over, and you specify the key column that drives the iteration. This sounds abstract until you’ve done it once, after which it’s obvious.
Design the template
The template is an Excel or Word file you create separately and store in Voyager’s reports path. You drop smart markers into cells where the data should go: &=SectionCode.ColumnAlias style. Excel templates can use the full Excel toolbox. Formulas, conditional formatting, pivot tables, charts, multiple worksheets, freeze panes. Yardi ships an Excel Add-In that helps with template design, including a tool that lists the available field names for each analytic.
Test on real data
Run the report. Most reports break the first time, and the breakage is almost always one of three things: a filter mapping is off, a smart marker is referencing a column the SQL doesn’t actually return, or the SQL itself has a join error. None of these are hard to fix; they’re just hard to find if you don’t know where to look.
Set up delivery
Save the report, configure who can run it through Voyager’s security roles, and decide how it should be delivered. Voyager has two scheduling mechanisms: Task Runner for batch jobs and Report Scheduler for scheduled email delivery. YSR can also attach the report to Voyager objects (properties, tenants, vendors) or push it to SharePoint or Investor Portal.
Reports worth building
These are the custom reports that come up over and over at property management clients, grouped by how much technical work they take.
Reports you can probably build in-house
- Lease expiration pipeline. Every active lease sorted by expiration, with property, unit, tenant, current rent. If your module has a corresponding Voyager analytic, no SQL needed.
- Vacant unit summary. Current vacancies, sorted by days vacant, with the last lease end date and the list price. Useful weekly during lease-up.
- Delinquency by aging bucket. Outstanding balances grouped by 30/60/90+ days past due, with last payment date. AR Analytics has most of this; the work is in formatting.
Reports where you’ll likely want help
- Maintenance cost by property per quarter. Work order spend grouped by property and service category, with quarter-over-quarter comparison. Needs joins across work orders, GL transactions, and properties.
- Owner net disbursement preview. What each owner is going to receive on the next disbursement run, by property, before you actually run the disbursement. Needs careful work against GL balances and owner setup.
- Security deposit ledger. Every active security deposit by property, with tenant, amount, date received, holding account. Has to tie back to the trust account balance and the GL, which is fiddly.
The pattern: anything structurally close to a standard analytic is doable in-house. Anything that requires reconciling across modules (work orders to GL, deposits to trust accounts, AR to bank statements) is where the technical complexity jumps.
When to bring in a consultant
Honest answer: it depends entirely on whether you have someone in-house who can write SQL against the Yardi schema.
If you do, and that person is also comfortable with Excel template design, you can absolutely run custom reporting in-house. Yardi’s eLearning and YASC training cover the fundamentals. Two of my clients have built impressive YSR libraries this way over a couple of years.
If you don’t have that person, custom SQL reports are where consultant time pays for itself. Not because the work is mysterious, but because the cost of someone learning Yardi’s schema on the clock (including all the surprises like sign conventions on the GL, the way property lists actually work in security, the quirks of how gltotal joins back to budgets) adds up fast.
There are also a few report categories where I’d recommend bringing in help regardless of in-house skill:
- Reports that have to tie exactly to your audited financials. The schema lets you get a number that’s close to the right number in a dozen ways. Getting the right number, the one that matches what your auditors will see, requires knowing which way to do it.
- Reports that pull across multiple Voyager modules. Cross-module joins have edge cases that aren’t documented anywhere.
- Reports feeding external systems: investor portals, BI dashboards, board packets. The data contract has to be airtight.
- Reports where you’re already getting wrong numbers and can’t figure out why. That’s almost always a schema issue, and schema issues are time-expensive to debug from scratch.
The clearest signal: if you’re spending more time fighting Voyager than getting answers out of it, the math has tilted.
Custom Yardi reporting support
If you’ve got reports your team has been Excel-handling because Voyager “doesn’t have one,” or if you’re not sure your existing custom reports are giving you the right numbers, that’s the work I do. Custom YSR build, audits of existing reports, and training your team to maintain the library themselves are all part of how I help Yardi clients after go-live.
