How To Handle Rent Paid In Arrears Using Yardi Breeze

Background

Most commercial leases have rent paid in advance, usually on the first of the month. The engineers behind our favorite property management software seem to have figured this out and it's generally an easy task to input a simple rent schedule with rent paid on a forward basis. Less common, however, are those leases where rent is paid in arrears.

Many of us haven't yet encountered a lease structure with rent paid in arrears and may never. I don't see these leases often and they're almost always associated with the Federal Government or its agencies.

For those of us who have tenants that pay in this manner, depending on the system a little finesse may be needed to make sure the systems we use accurately reflect the contracts being paid on. Yardi Breeze is one such system.

This article will explore two methods I derived for handling leases with rent paid in arrears: one that's simple and easy to implement and another that's more comprehensive.

Set Up

For purposes of this demonstration, we'll use a hypothetical three-year deal. Our rent schedule will begin with $1,000.00 and escalate 5% annually thereafter. On the lease agreement, this will likely look something like:

To input this rent schedule in Yardi Breeze assuming rent is paid on a forward basis, first navigate to the tenant in question and select Scheduled Charges from the sidebar. Then select the appropriate Charge Code for the type of rent being applied. We're using a charge code 'Commercial Rent' for this office tenant. Next we'll enter the From and To date ranges for this rent schedule which in this case are congruent with the calendar year. Then we'll select 'Flat Amount' for Amount Type and 'Monthly' for Amount Period. Finally, we enter the monthly rental amount for the respective date range in Amount. Altogether, this should appear as follows:

Last, select save to commit our rent schedule to the database and we're all set. The rent schedule will now be available for monthly postings.

Again, this is for rent paid on a forward basis. The schedule above will assume that rent is due at the beginning of the period and payable on or before the beginning of the period.

The Simple Solution

The easies way to correct for rent payable in arrears is to shift everything down a month assuming language like:

Tenant agrees to pay to Landlord ( ... ) the monthly and annual sums ( ... ) payable in arrears on the first (1^st) day of each calendar month ...

Here we have rent still payable on the first, just looking backwards. Beginning your rent schedule a month later, ending a month later, and entering all rent steps in between a month later will result in effectively billing in arrears.

In addition to those adjustments, you'll need to first adjust your tenant information to push out lease expiration a month to accommodate the extended schedule otherwise Yardi will reject your scheduled rent with an end date beyond lease expiry. Also, let's add a note to explain what we're doing so that those accessing this information later don't interpret the lease end date as an error and revert.

Now for the rent schedule. As mentioned before, we simple adjust all dates to occur a month later. I'm also going to add a placeholder at the beginning of the schedule to indicate why the paid rent portion of the schedule isn't beginning at commencement in a lease not depicting abatement.

With those changes, the system will now synthetically treat rent as if payable in arrears. Primarily, this means late fees won't be applied incorrectly from believing charges are due earlier than contracted.

Hazards To The Simple Solution

Ideally, we would have a system that gracefully handles everything thrown at it. But that's not the reality of enterprise software. Not every circumstance can be engineered for and we'll have to construct workarounds. But with any workaround, you may create further issues by solving one and introduce unanticipated problems.

First and foremost, my greatest concern when entering data inconsistent with what it relates to in the physical world (e.g. rent schedule on the lease form) is that another party down the line isn't going to understand the original objective correctly and revert our data entry thinking a mistake was made. We review our data on a routine basis, at least annually. I worry that another party will see the rent schedule during such a review, notice superficially that the dates in the system don't aline with the lease, and change back the system information to match the lease. There are times when I struggle to interpret what my own intentions were for actions taken in the past after enough time has gone by. Because of this, document and notate heavily the situation at every available opportunity.  

Language for arrears is often a bit buried. From my experience, it's generally not acknowledged where the rent schedule exists (often the first article), but instead exists where the more verbose definition of rent occurs. It would be quite easy to miss this key piece of information at a later date, especially for a party not well aquatinted with the lease's nuance, such as an admin covering many properties.

Next, there's an issue with the conveyance of information to the tenant. Although your tenant paying in arrears will likely understand that their rent payment isn't due until the conclusion of the period, they'll likely still expect the invoice received in advance to be for the current period rather than the backward looking period. You now have a problem with invoices not communicating effectively what period they belong to and the opportunity for confusion exists. Your invoice will be labeled for period t because your system still thinks you're paying forward when in reality the invoice is for t-1. Essentially, the informative value of your invoices declines.

In general, I'm not too worried about this because in those circumstances where you have leases with rent negotiated to be payable in arrears you're going to have sophisticated tenants. For example, the Federal Government as mentioned earlier. Or, at the very least, you're going to have corporate tenants with either internal or external lease administrators. In either case, they're probably not relying on your invoices anyways and instead tracking their rent payable on their own side.

The Comprehensive Solution

Now having explored a relatively simple way to get up and running quickly with rent payable in arrears, how can we improve this process including the informative value of the rent schedule and invoices generated? First I want to revert back to the first way in which the rent schedule was entered, i.e. the schedule entered on a normal forward basis. That looks like:

This is a better starting point because what's represented here tracks the physical rent schedule present in the lease. Consistency between these two resources improves informative value and decreases the risk that someone in the future misinterprets your intentions and makes undesired adjustments. From this starting point I'll add charges to push out the schedule by a month. These adjusting charges will occur in the first and last period rent is charged and at every rental increase. Formulaically, we can represent the adjustment factor as the preceding period's basic rental less the current period's basic rental.

In the first period (January 2024), we have $0 - $1,000 = ($1,000), for the first rental increase (January 2025) we have $1,000.00 - $1,050.00 = ($50.00), and in the final period (January 2027) we have $1,102.50 - $0 = $1,102.50.

It may be easier to start with a simple spreadsheet organizing your charges before data entry:

With our charges mapped out, we're ready to enter these charges into Yardi. Note, we still want our lease expiration to remain a month longer than the lease's scheduled expiration to accommodate the final adjustment. Fortunately with the exception, Yardi will complain about the conflict with the rent schedule if someone tries to return the lease expiration back inline with the lease document. Hopefully upon inspecting the rent schedule they'll encounter our descriptive notes and understand the objective.

Those charges once entered in Yardi will now look like:

With this schedule, we have adjustments that effectively push out the rent schedule by a month. In the first period, we have an adjustment that will fully offset scheduled rent so that nothing is due. For the periods with a rental increase, we have an adjustment equal to the difference between rent levels effectively delaying the increase by a month. And in the final period, really one month after the conclusion of the lease, we add a payment equivalent to the previous rent schedule.

In this format, we've preserved the original rent schedule so the physical system and the lease match. Then we apply adjustments to shift the schedule and add appropriate notes to communicate our intentions to other users of the system. Last, the recipients of invoices will more clearly see what period rent belongs to and what's being done to accommodate the nuance of their agreement.

It takes a little more effort to get there, but this way you have more informative system entry. The tradeoff here is complexity which increases the risk of error, especially in data entry.

Final Thoughts

In a perfect world, we have systems that anticipate and accommodate all situations we may encounter. In practice not all use cases are covered, system can be rigid, and we need to find ways to achieve a desired result despite system limitations. Here we look at two approaches. The first favors simplicity over informative value whereas the second favors informative value at the expense of simplicity. Which direction you choose will depend on your own unique constraints.