NetSuite vs. Yardi


Readers in the Real Estate and Property Management fields might find this article useful in assessing which cloud-based solution would be optimal.

Yardi is a provider of cloud-based ERP and accounting software specific to the Real Estate sector. Oracle’s NetSuite is a leading ERP software provider, with modules and add-ons (“Bundles”) that are geared for various industries – but does not yet have a specific module for Real Estate enterprises. I had the opportunity to spend about a year learning the Yardi “Voyager” software and found it interesting to note the differences and similarities between it and NetSuite. Each has its strong and weak points which highlight different approaches to solving common business problems. I’ll focus on a few here, to illustrate.

General Ledger.

Like many traditional accounting systems, Yardi requires a separate “posting” function to cause transactions to impact the general ledger. In NetSuite, transactions are designed to directly impact the general ledger, unless an approvals process is activated. This distinction is significant, and might reflect a different view on the relationship between Operations and Finance. NetSuite’s approach requires cohesiveness between finance and other departments. The teams entering transactions often develop sensitivity to how the ledger is impacted, and the finance team needs to develop awareness as to the functions of the operations department, since operational tasks will directly touch the ledger. Yardi’s approach seems to assume less interaction between finance and operations, and might reflect a more common company culture in Real Estate, as the operations people are often in an on-site office at each property, whereas the finance team typically is centralized in an off-site location.

Basic Structure – Entities/Subsidiaries.

Yardi’s basic table structure represents the industry they serve. Typically, Yardi’s customers are large management companies or groups of real estate investors that own multiple properties, with each property or each group of properties legally “owned” by its own entity. Often, the properties that are tracked in one system have no legal relationship with one another, rather they share common individual investors or managers. Yardi thus allows for unlimited number of entities, allows unrelated properties, yet also holds the concept of an “owner” or “investor” with the percentage contributed. The number of entities within a single Yardi instance can vary frequently as properties are bought and sold, and Yardi easily handles this.

In contrast, NetSuite has a limit to the number of Subsidiaries (125), and there must be a parent-child link between the ultimate “parent” company and all of the various child companies. It takes a few days to add licensing for extra subsidiaries, and the general orientation reflects industries where the number of entities inside a consolidated entity change infrequently and there typically is significant lead time before a new subsidiary becomes part of a parent entity structure.


Yardi’s reporting engine is usually one of its best selling points over other real estate management tools. There are a variety of out-of-the-box reports and these can be configured or customized with moderate effort. Sql experts can create custom layouts and bring together virtually any data in the system using traditional joins. Users without programming background will find it hard to customize reports, though. Additionally, the standard dashboards are quite rigid and don’t allow for much customization.

NetSuite offers 3 different reporting tools (reports, searches, and analytics) and arguably the most powerful of the three – “saved searches” – is far superior to Yardi’s reporting capacity, in my opinion. Even users with little or no sql background can customize reports with relative ease. Likewise, dashboards can be easily customized to create beautiful, clear outputs that make sense for each role.

Data Layers.

Out-of-the box, Yardi Voyager contains records for Properties, Buildings, Units, Tenants, and Roommates, aside from the standard Vendor, Customer, and Employee records. The Commercial module contains additional layers representing Leases, Floors, and Square footage. These special records provide powerful reporting tools and transactional automation relevant to each part. Yardi also contains special records such as a “legal card” to track legal actions relevant to tenant relations, and integrated tables for Rent Control rules in jurisdictions where this is applicable. Its commercial module has powerful capacity to calculate CAM reimbursements, and its “Affordable” module has the capacity to track compliance with complex government regulations for affordable housing concerns. Conversely, NetSuite does not (yet) have a module which contains any these pieces (see next section, though).


Overall, although Yardi does contain the ability to create “packages” to automate certain functions or to drive reporting, it does not have the same open platform that would allow significant changes to transaction forms, to create new record types, or to create completely new user forms.

Here is where NetSuite is strongest. Aside from the native, point-and-click ability to change forms, add fields, and add new record types, it is highly extendable with scripting.

To illustrate, if we wanted to make NetSuite better suited for Real Estate, we could create custom segments to represent geographic regions, and custom records to represent Properties, Buildings, and Floors. We perhaps would use Statistical accounts to track Units, and custom transaction types for Rent transactions and CAM reimbursements. This of course would require scripting to maintain the relationships and interaction between these parts, but in theory, I believe it could be done. The bigger challenge would be creating the records and integrations needed for the compliance rules, but this too would not be insurmountable.

User Interface.

I personally prefer NetSuite’s user experience, as it is more modern looking and intuitive. Yardi’s seems a bit more dated, with smaller fonts, with more rigid form navigation. Additionally, many of the Yardi tools take multiple steps to navigate through and set up, and it often is hard to determine where to go for what task, whereas in NetSuite, generally the design is efficient.


NetSuite is constantly expanding the list of the business Verticals that they serve. I would venture to say that it won’t be long before a real estate module emerges. In the meantime, all things equal, a real estate company having upwards of 4000 units should consider Yardi due to the advanced features that are very industry-specific. Smaller concerns might consider using a separate Rent Management software such as RentManager and integrate with NetSuite to gain the more robust reporting tools, rather than invest in Yardi. Large conglomerates having significant real estate holdings aside from other business activities like retail or manufacturing might consider using Yardi for their real estate segments and NetSuite for their other operations, and it would be interesting to create an integration between these two softwares. We at Prolecto Resources, Inc. are NetSuite Integrators, which means we have developed creative ways to bring data from different sources together, and this type of project would be an exciting challenge for us.

If you’ve had experience in either using NetSuite to manage real estate, or in integrating Yardi with NetSuite, I would be very curious to learn. Likewise, if you need help understanding how NetSuite can be customized for Real Estate, we’d be happy to hear from you!

Understand NetSuite’s Currency Translation Approach


Currency Translation vs. Currency Valuation.
Problem: Foreign Subsidiary balances were valued using different methods than NetSuite.
Solution Part 1: Manually fix the rates in the consolidated translation rate tables.
Solution Part 2: Use reversing entries in next period at same rates (does not work if you need monthly balances), import balances at new rates, rather than delta amounts.
Alternate Solution: Use entries to an “adjustment only book” to account for differences.


See related post NetSuite Currency Translation II for a flexible approach to adjust consolidated currency amounts and base currency amounts.


Consolidated (multi-subsidiary) reporting can be confusing, especially when it comes to currency translation. NetSuite has the capacity to perform currency translation work automatically, but it takes some effort to understand the method it uses and how to properly set it up.

This article will discuss migrating historical foreign subsidiary balances to NetSuite. Often, foreign subsidiary balances had previously been translated using a different method than what NetSuite uses. Therefore, the consolidated reports generated from NetSuite would not naturally yield the same results as reported in their prior system. But first, let’s understand NetSuite’s general approach to multi-currency.


It’s important to distinguish between currency conversion, currency revaluation, and currency translation.

  1. Currency “conversion” occurs when a transaction is entered in a different currency than the Subsidiary’s base currency. NetSuite will convert the amount into the base currency at the rate contained in the Exchange Rate field. The default exchange rates are driven by tables that hold daily exchange rates, and these tables can be set manually or updated automatically. Importantly, the rates on individual transactions can be changed manually without impacting the underlying tables.

  2. Currency “revaluation” refers to revising the base currency impact of an existing foreign currency transaction. This is done in two ways:
    • When a foreign currency A/R or A/P invoice/bill is paid at a different rate than the original transaction. This results in a “Realized Gain or Loss”.
    • At month end, when the current rate has changed, such that the true base currency value of the open A/R or A/P balance is different than it was when it first was created. This results in an “Unrealized Gain or Loss”.
  3. Currency “translation refers to the way that foreign subsidiary account balances are reported on a parent entity’s financial statement. In contrast with the first 2 concepts, this is not transactional. As its name suggests, it simply translates the foreign subsidiary account balances when viewed in the parent entity’s currency. The tables in NetSuite that contain the translation rates are not the same ones used in conversion. This is explained more fully below.

Currency Translation.

NetSuite provides tables that contain the translation rates for each accounting period. This is not a daily rate, rather these are rates for each period. Typically, Assets, Liabilities, Income, Expenses and Equity are translated differently. NetSuite provides 3 different “rate types”, and there is a field on the “Account” record where a rate “type” is selected.

The 3 rate types are:

Current: This is a spot rate as of the last day of the reporting period. This type is usually used for Assets and Liability accounts.

Average: This is a weighted average rate for the period reported. The “weights” are all transactions hitting GL accounts which use the same “rate type”. This type is usually used with Income and Expense accounts.

Historical: This is the actual rates of all transactions having this rate type. (Essentially this is the same method as the “Average” type, as it is the equivalent of a weighted average rate based on transaction amounts.) This type usually is used for Equity accounts.

Currency Exchange Rate Tables.

There are two sets of exchange rates stored in NetSuite. One set is used for both foreign currency conversion and revaluation (see the definition of these terms above).

Currency Exchange Rate Tables

The second set of exchange rates are used for translation. These rates cannot be set on a transaction basis, and they are rates for each accounting period, not daily. They can be set manually, but the rate that is set will apply to all accounts that use the same “rate type”.

Consolidated Exchange Rate Tables

Delta amounts vs. Balances.

When NetSuite revalues accounts that are set to a “rate type” of “current”, such as most balance sheet accounts, it revalues the entire balance of each account as of the report date, based on the current (“spot”) rate on the report date. When NetSuite revalues accounts set to a rate type of “average” or “historical” (such as P&L accounts or equity accounts), it revalues only the delta amounts for each accounting period.

Currency Translation Sample.

TypeDateRateRinggit AmountUSD Amount


Calculated Weighted Avg:

Jan = (.24184 * 100K + .24307 * 100K) / 200K = .242455

Feb = (.24468 * 200K + .2457 * 100K) / 300K = .24502

In the above example, if the company was running a consolidated Income Statement for February 2019, NetSuite would not translate the entire 500K balance in the revenue account. Rather, the Jan amount (200K) would still be translated at the Jan weighted average, and the Feb amount (300K) would be translated at the Feb weighted average rate.

Loading Historical Data.

This presents a challenge when loading historical trial balances which were produced before adopting NetSuite. A company’s practice may have been to translate the YTD balance each month at a non-weighted average for the YTD (i.e. the total of all daily rates ÷ number of days YTD). Thus, even if we manually set the Jan and Feb translation rates in NetSuite, there is no way to consistently yield the result desired, since NetSuite will only look to translate the Feb amounts in Feb, not the Jan amount, and the YTD non-weighted average will not necessarily equal the combined manually-entered Jan and Feb rates when each month is translated separately.

It would be nice if we could simply assign a translation rate on specific transactions, the same way that this can be done for the currency exchange rates when entering a foreign currency transaction. If we could, we would simply import each month’s balance, reverse in the following month (at the same rate), and import the following month’s transaction at a different rate to match what had previously been reported. However, as mentioned, NetSuite’s foreign currency translation is not a true transaction, rather it is a function of reporting – and therefore we cannot assign a different translation rate for different transactions.

Solution 1.

There is a relatively easy solution to the problem, if a company only needs to produce quarterly or annual reports for the historical (pre-NetSuite) activity:

  1. Manually set the rates on the last periods in the quarters or years that need to be reported on.
  2. Then set the rates to be the same for the first period subsequent to each quarter or year.
  3. Enter each quarter’s or year’s balances and set the Journal Entry reversal dates to occur in the following period.
  4. When entering the subsequent quarter’s or year’s balance, be sure to load the entire cumulative balance, rather than just the delta amounts.

Solution 2.

If a company needs to produce monthly reports on historical balances prior to NetSuite, the above solution will not work, as each period will need its own correct currency translation rate. Instead, the problem can be solved either using an Adjustment-only book, or entries to an Elimination Subsidiary.

  1. Calculate the differences between what NetSuite shows as the USD-Translated account balances each month, and what had previously been reported.
  2. Book JE’s either to the Adjustment Book or Elimination Subsidiary with these amounts. The offsetting debit or credit should be booked to the Cumulative Translation Adjustment account (although the account balance normally does not contain transactions, it is possible to post Journals to this account if desired).

Either way, the process is somewhat manual. Companies that are adopting NetSuite OneWorld might need to consider changing how they account for translations so that they can get the full value out of NetSuite capacities.

Master your consolidated reporting.

NetSuite has powerful tools to aid with consolidation, but it can take some time to understand the approach and assess how best to configure it to suit your business needs. If you’d like to learn more about NetSuite’s foreign currency tools and capacities, we’d be happy to talk to you.

Meir’s NetSuite Advice Blog

“I’m not gonna fight this thing.”

— Larry Ellison – NetSuite co-founder referring to Cloud Computing, Sept 2008


Welcome to my NetSuite advice blog, glad to have you here. If you’re here, chances are you are looking for help using NetSuite. If your experience is like mine, you might feel that your company is underutilizing NetSuite’s capabilities, or you are confused about some feature, or you have already determined that NetSuite’s native ability doesn’t quite achieve a particular need and therefore are looking to go beyond the standard functions with some customization. The purpose of this blog is to bring “order to the chaos”, and to help the NetSuite user community in the following three ways:

  1. We’ll explain NetSuite’s features and “best practices”, in ways perhaps not adequately described in SuiteSolutions or NetSuite help articles.
  2. We’ll describe how scripting and custom solutions can overcome limitations in the standard NetSuite offering.
  3. We’ll compare different approaches to solving business challenges and give some context so that users can make better decisions about how they use NetSuite.

A Suggestion.

NetSuite is an extremely powerful tool, yet because it is designed to be useable by anyone with basic computer skills, it is built with assumptions and parameters that do not fit every company or use case. Nevertheless, it is highly extendable with scripting and custom work. Sometimes the trick to getting the most out of it is to strike the right balance between modifying company practices to fit NetSuite’s intended model, vs. modifying (customizing) NetSuite to fit existing company practices. There are no hard and fast rules about this, as it depends on many factors such as company size, budget, user skills, and requirements, however, my personal approach can best be summarized by the quote from Larry Ellison at the top of this article. “Don’t fight the thing”. Larry was referring to cloud computing generally, but I think the same can be said about decision making about customizing. Here are some basic questions company decision makers might ask themselves when evaluating whether to customize:

  • Does NetSuite have an out-of-the-box solution for what we are seeking to do? Precisely which parts fall short of our needs?
  • What is the underlying reason for the practices we have? Are they required to serve a business need? To satisfy regulatory requirements? Because “that’s how we always did it”? What would happen if we changed?
  • Are we trying to go against the grain of core NetSuite functionality?

Asking these questions often can help companies better refine their true objectives and allows for deliberate and mindful decisions. It often pays to invest in time getting to the bottom of these types of questions before launching NetSuite development projects. An hour’s worth of planning can save many more hours of “fine-tuning” after a project is already underway.

About Me.

My name is Meir Bulman, I am a CPA with some 10+ years’ experience as a NetSuite Administrator and Controller, and a Yardi implementor. (Yardi is a cloud-based ERP software geared for the Real Estate sector.) In January 2018 I decided to focus on NetSuite and to put my knowledge and real-world experience to help others deepen their understanding of NetSuite and extend the ways in which they use it. I’ve joined an extremely talented team of 20+ consultants at Prolecto Resources, Inc. led by its founder, Marty Zigman. Our clients are diverse in their industries, corporate culture, and geography; but are similar in their understanding that NetSuite can dramatically enhance their accounting and operations efficiency.

We at Prolecto are here to help you. I hope you will find these articles useful, and will be happy to hear from you if you’d like to explore ways in which we may be of service to you.