An Evaluation On How To Post A Payment In Yardi Breeze for An Amount Different Than the Invoice

For abbreviated instructions on Correcting Entries in Yardi Breeze, see this article How To Enter A Correcting Journal Entry In Yardi Breeze

Background

While recording automatic payments for commercial property utility expenses (electricity, water & sewer, etc.) in Yardi Breeze where the invoices were recorded as adjustments, I ran into a problem where the payment drafted from a property's checking account was different than what appeared on the invoice. Leaving what caused the discrepancy aside, this left me uncertain as to how I should proceed with recording the Payment in Yardi Breeze.

I know what I'd like to do as an accountant. Ideally, I would record the payment as a compound adjusting journal entry ("J/E" henceforth) driving the difference between payment and accrual through the expense account the utility charge was originally booked against. Assuming an accrual of $1,000 and a payment of $900, this would look like:

However, after reviewing what tools I had available with Yardi Breeze, it wasn't clear that I had the ability to record the discrepancy how I'd like to. When you record a payment as an adjustment, you're provided the following dialogue box:

The only items within my control are the "Check Date" which should line up with what appears on the checking account statement, and the "Check Post Month" which controls the period in which the transaction is reflected in financial reports. By selecting "OK," I'll have a J/E composed of a debit to "Accounts Payable" for the accrued amount (using my example above, this would be $1,000) and a balancing credit to "Cash," together closing the payable. Nothing from this dialogue box gets me to where I need to be.

From here, I suspect that my options are, (1) delete the transaction, and (2) reverse the entry and restart the workflow.

The Options

I have concerns with both deleting the transaction and reversing using the built-in "Reverse" option. 

First, deleting the transaction isn't good practice because it softens controls over the accounting process. I'm sure that there's still "audit trail" and that the database transaction is only soft-deleted whereby the actual object/record simply has a field marked deleted, etc., thus removing it from queries. I don't think the story is disappearing for good. But the story isn't being told well because the transaction is removed from the reporting flow.

The second option is the reverse the inaccurate entry and start over. However, I have concerns with this approach also. Technically speaking, it's more valid than the first approach since all activity is preserved above board and you have the option to notate what occurred for the benefit of future users. But I don't like the workflow available to accomplish this. Here's the dialogue box to reverse a payable:

This seems harmless enough. The "Invoice Date" and "Post Month" are set to the current date (I started composing this article 6/13/2024), which is generally what we want. The reversal along with the restated accrual should occur as of the discovery date rather than the original accrual date which is likely the date shown on the invoice.

Why do we want to use the current date over the original date? Because with our books we're trying to capture the best representation of the truth at a given point in time. When the invoice was first accrued, the amount reflected on the invoice was our best guess at truth. Going back and making a change effective to the original date doesn't make sense because the adjusted amount didn't reflect things as we understood them to be at that point in time, the invoice did.

With that out of the way, here's where my concern comes in. When you select "Reverse," use the current dates as I previously recommended, select "Restart Invoice Workflow" (because presumably you still need enter the invoice for the correct amount), and select "OK," you're actually brought to the reversed payable's page and not the restarted invoice view. When you navigate to Accounting > Payables > Invoices, you'll see the restarted invoice ready for you to continue with processing. When you open the invoice you'll notice that the fields are pre-filled with the earlier incorrect information. This is not what we want.

Some information is desirable, sure. Having vendor information pre-filled will save us some time. However, the dates and amounts are wrong. The dates will be for the original accrual date. Instead this must be changed to the reversal date. I'll illustrate why with journal entries. I'll use the amounts used in the running example. Assume the original accrual date was 5/1/2024 and the payment date as well as the reversal date was 6/13/2024 (I'm assuming we caught the discrepancy immediately which would be the case if we reconcile daily as some do). Here's what the journal entries would look like:

Original Accrual: 5/1/2024

Reversal: 6/13/2024

Restated Accrual: 5/1/2024

Payment: 6/13/2024

The problem here deals with timing. Because the restatement workflow pre-fills the invoice date along with all the other original information, there's a risk of allocating amounts to the wrong periods if the transactions span multiple periods like the above example does. With this example, we're going to have a "Utilities Expense" of $1,900 and ($1,000) in May and June respectively as a result of these entries.

We'll still end the year where we need to be so long as the dates don't span years. But just the same, this will cause your Income Statement to look a bit odd when displayed on a monthly basis and the reporting quality will be diminished.

Now if you follow up the pre-filled data and enter the correct amounts and dates, then good on you. You're still able to achieve a good outcome. In my experience, however, if you have pre-filled data that is inconsistent or inaccurate, the errors will occur with absolute certainty.

What Did Customer Support Recommend?

Given my concern, I reached out to Yardi's customer support department to see how they would approach this situation. After all, they built the system.

Recommendation #1

The first approach they recommended for correcting a payment different than the accrual is to simply delete and start over. I was surprised by this because of my previous concerns with accounting controls. But let's assume that the Yardi Breeze product is primarily consumed by smaller shops where few or one person(s) are responsible for the entirety of the accounting process. In this case, controls are less of a concern because you really can't control for yourself if it's just you to begin with. If you're a one-person shop, then by all means, delete and move on with your life.

Recommendation #2

The second approach they recommended was to enter a second payable for the difference. If you need to reduce the accrual amount, then enter the payable amount as a negative number. I was surprised by this recommendation. Not that it isn't technically correct from an accounting perspective, because it would be if properly notated and connections were established between entries. This approach would be completely valid and would be considered your typical adjusting entry. 

Instead what surprised me about this approach is that it's outside the system. By that I mean that it's not one of the visible workflows the system makes available through the user interface. From a software perspective, it's sort of a workaround.

Furthermore, you're going to run into problems downstream when using this approach. When you use the Yardi reconciliation workflow, the system will attempt to match transactions to your checking account transactions by dollar amount. While the net of your two payable accruals (the original and the adjusting) will balance your checkbook, they'll still be discrete transactions so you'll need to reconcile manually adding a step.To do so, navigate to Accounting > Banking > Checkbook Maintenance, query the appropriate transactions, mark reconciled with the "Rec?" checkbox and supply the appropriate "Reconciled Date."

Again, completely valid. But in going this route, you're adding steps and when you add steps you introduce the possibility of data entry errors. Because of this, I prefer the reversal approach. That way, your reconciliations will still function normally and you won't need to manually reconcile.

What To Do?

The first and easiest approach if you're working by yourself is to just start over. You should delete the transaction and start fresh. If the transaction is material or there's something of special concern that I really, really want to preserve, then I'll either reverse or take Yardi's second recommendation. But I expect those situations will be unlikely.

If you're working in a team, then I highly recommend you choose an approach that retains the audit trail such as the reversal or the adjustment. My personal preference is to use the "Reversal" approach. But instead of selecting "Restart Invoice Workflow," leave this checkbox blank and restart the workflow from scratch.

There isn't really a benefit to the "Restart Invoice Workflow" option because there isn't a connection from the new workflow to the old workflow. You wish there would be. It would be great to see the reversed transaction attached directly to the new payable, but that's not the case. So instead of risking a mistake, just start over.

Before you do start over, write down a few notes to make sure you don't enter the wrong data.

First, record the date of the reversal. You need to use this date for the new invoice accrual otherwise you could run into the earlier mentioned issue where you have a double count in the earlier period and a negative amount in the later period.

Next, write down the amount that you need to accrue. If you attach the invoice to the payable, you'll have incorrect information right in front of you and it will be too easy to grab the wrong data when moving quickly. Write the updated dates and amounts somewhere visible so this risk is minimized.

Personally, I follow this workflow: I first download the invoice image from the reversed payable, I open the invoice with a .pdf editor and add the notes directly to the invoice document in bright colors, then start the restated payable workflow with the notated invoice. That way, my notes are right in front of me and difficult to ignore.

Finally, add notes connecting this transaction back to the reversed transaction and explain clearly what occurred. As previously mentioned, the system doesn't do this automatically so it's up to you.

Final Thoughts

When you have a payment for an amount different than the accrued payable, you're going to need to take additional steps to accommodate for the discrepancy. If you're a one-person team, it might just be easier to delete and start over, especially if the transaction isn't material. If controls are of concern or information preservation is vitally important, you can either use Yardi's recommendation of an adjusting entry followed by manual reconciliation or use my approach over reversal and restatement. Which route you choose will depend on your specific circumstances and constraint. Whichever you decide, notate your actions generously.