Home / Blogs

5 Common Misconceptions New Registries Have About Domain Revenue

It is wonderful to see the floodgates open and see so many new gTLDs launch—417 delegated as of October 4th. As registry senior management’s focus switches to operational matters post launch, it is now time to consider how the new registries will deal with revenue recognition and its impact on financial reporting. This is primarily the CFO’s responsibility, but senior management must be mindful that improper domain revenue accounting will lead to corporate reputational damage. In 2004 I faced this challenge as CFO of dotMobi, and I was then a new entrant to the industry. Since then, my experience as a finance executive within the domain industry has led to the realisation that there is widespread uncertainty on how to handle the accounting of domain revenue once you launch. CFOs and founders whose companies are entering the domain registry marketplace need to make sure they understand the complicated rules of revenue recognition from the start—or risk having to restate their financial statements in the future, under the critical gaze of investors, lenders or regulators.

Here are some misconceptions that exist, especially among new entrants.

* * *

Misconception #1 – “Isn’t Invoiced Sales the same as accounting revenue? I’ll just use the reports my back-end provider gives me for my accounting sales.”

Most Registry Service Providers’ (RSP) contracts with new gTLDs provide for the provision of billing, invoicing and statement generation. However, your invoiced sales for the month are not your accounting revenues.

Across all industries revenue recognition has been one of the most controversial topics in accounting for business activity and there are many accounting standards, bulletins and directives to follow. Domain revenue falls under the services category so we must look more to general revenue recognition guidelines (and less to software revenue recognition rules). The key principle is that domain income is earned (and revenue recognised) ratably and equally over the term that the service is delivered. See my CircleID blog from 29th June 2011 for graphic illustration of how invoiced sales & accounting revenue can differ. In a recent position paper, using sample data, I estimated that if a registry recorded invoiced sales as their accounting revenue in their books, they could overstate revenue in year 1 by up to 380%. This error has already happened at existing registries on more than one occasion, and led to entire reinstatement of financial results for those concerned.

Misconception #2 – “I am filing my tax returns on a modified cash basis, therefore I don’t need to consider deferred revenue”

I hear this statement frequently, especially from US based registries. Even if a registry has filed for such an option, why would you decide to declare your cash invoiced sales as your accounting revenue when you can follow best accounting practices to defer the revenue over the lives of the domains? In the sample data I used in my position paper, Year 1 cash sales of $9.8m would correspond to $2m accounting revenue when you defer revenue per the accounting rules. Depending on OPEX, this could result in posting lower profits in the early years and also legitimately deferring the payment of taxes.

Misconception #3 – ” I am the sole owner of the privately held registry so this is not a priority for me”

Accounting best practice is to recognise domain revenue ratably and equally over the life of the domain. Many of the leading incumbent registries have been adopting this policy for the past 10 years or more—with most recognising domain revenue by day and rolling it up to a monthly posting to their general ledger. If a new registry chooses to diverge from this best practice by making manual estimates, they run the risk of their financial results being questioned by their own investors or outside parties. This will become particularly relevant if the registry aspires to raise new funding for expansion, or sees the possibility of selling the business in the medium to long term.

Misconception #4 – “I know all about deferred revenue, but I don’t need to worry because my back-end provider is giving me all the reports I need. No action required”

There is a large expectation gap between what new gTLD applicants believe they are receiving under the terms of their RSP contracts, and what they are contractually entitled to. RSPs do provide a suite of services, but these are not all encompassing—some new gTLD applicants are not even receiving registrar billing as part of the backend contract. With regards to revenue, RSPs will typically provide gTLDs with an invoicing service but will not perform the necessary deferred revenue calculations. In that scenario, the registry (contract holder) becomes responsible for performing these calculations once the invoicing is delivered. Note: some RSPs will offer a deferred revenue calculation tool as an optional paid extra so be sure to explore all of your options.

Misconception #5 – “Ok, so my RSP isn’t giving me deferred revenue calcs. So what? All I need to do is download billing transactions data into a spreadsheet and calculate it myself”

I hear this very often when talking to CFOs of registries with the perception that domain revenue recognition is similar to revenue recognition of other subscription services. It’s not, and I caution against trying to build a solution in a spreadsheet. The reason is that domains have a myriad of life states with many permutations (multi-year, early renewals, auto-renews, transfers, deletes, restores etc.) and many grace periods (“cool-off periods”). These create a plethora of unique rules in recognising revenue, and require unique calculations. Dealing with these exceptions in a spreadsheet environment will be problematic and error prone—especially when domains under management reach a critical mass. Revenue recognition for the registry is the most complicated area of keeping proper books and records, and I believe it requires specialist tools in order to do it correctly.

* * *

I urge all new entrants (and veterans) to the industry to give due consideration to how you wish to approach the treatment of revenue in your books. There are real reputational risks to misstating your revenue figures, and there are real life examples to learn from in the industry. This is a complicated area and worth avoiding the easy path of short-cutting especially if you have outside investors, hope to bring in new funding, or intend to exit at any stage.

By Norbert Grey

Mr. Grey has served in senior financial roles in both the domain name system (DNS) industry and in the technology and mobile telecommunications industries. Architelos, Inc. provides SaaS-based TLD managed services solutions, and strategic consulting for clients in the domain name (DNS) industry.

Visit Page

Filed Under


Based on International Accounting Standards (IAS)? Alex Tajirian  –  Oct 8, 2014 10:11 PM

Based on International Accounting Standards (IAS)?

Accounting Standards Norbert Grey  –  Oct 9, 2014 1:35 PM

Alex, both US GAAP & IAS - domain revenue falls under the "services" category of revenue recognition so it is based on guiding principles and not definitive rules. Both IAS & US have broadly similar principles - domain income is earned over the term that the service is delivered. The principle is straight forward but its application in the domain world is complicated by ICANN rules on domain life cycle like grace periods, deletes, autorenew etc.

I wonder if some registries will fail Phil Buckingham  –  Oct 9, 2014 3:25 AM

Great article, Norbert,
I go even further and wonder if some registries will fail here.
As a fellow DNS CFO I cannot overemphasise the importance of 1000 odd new registries (with the vast majority having no experience of launching, structuring and operating a TLD)understanding this key financial/ accounting issue.
Registries relying on their backend guys doing it the old way,do so at their peril . They run the backend not the front end.
Registries will fail because they mismanage, miscalculate their cashflow forecasts/deferred revenues from analysis of their critical zone file registration data /stats.
They should get an experienced DNS CFO on board before launch.Happy to explain more next week in LA.

reply Norbert Grey  –  Oct 9, 2014 1:49 PM

Thanks Phil, Yes the old adage “if you fail to plan then you plan to fail” runs true here. We’ve been supporting a number of new gTLDs with consulting and deferred revenue tools - freeing them up to focus more on business performance measurement and less on number crunching. See you in LA.

The good and bad of a 10 year registration Jothan Frakes  –  Oct 9, 2014 10:18 PM

Norbert you really nailed it on this.  There is always a tendency to dismiss the accounting aspect of the registry operations and that can be a crucial oversight.

Like so many aspects of our industry for newcomers, things that seem simple at first blush are actually very complicated.

A simple, plain English way to highlight the difference between sales and revenue is evidenced in the following scenario.

Most of the current stats services that are monitoring the zone files are presenting the zone file sizes as registrations.

In that context, a single year registration increases the “TLD count” by one unit.  So does a five or ten year registration.

The registry then reviews the cash or top line from the sales report and makes astronaut level interpretations of the two figures.

Let’s set aside the various complexities of marketing costs, basic cogs such as rsp/DNS provider and ICANN fees, staff and other OPEX, and focus on basic math and logic flaws.

Calling the zone “TLD count” Z, the wholesale price of the domain W, the actual quantity of registrations R, and sales S,  here are some of the most common mistakes which I have witnessed new TLDs make:

(S/W = Registration count) instead of R or
(S/Z = Revenue per unit, then multiplying R by that number )
This breaks more and more with multi year registrations.  The false number from S/W looks awesome (larger than R) in year 1, and then year 2 plummets to less then R in subsequent years (unless you’re really getting increasing registration volume).  Also, if you pay out per unit fees on S/W you will over pay y1 and under pay y2.  If you spend on marketing and staffing budget on this number you may end up with budgetary crunch in y2.


There are some simple equations that can get someone to the numbers they are looking for, but it is very easy to unknowingly pick the wrong ones too.

The importance of getting it right and having experienced help with the financial aspect of registry accounting cannot be more heavily stressed.

Reply Norbert Grey  –  Oct 10, 2014 3:49 PM


thanks for the reply. That is invaluable advice from an industry veteran like yourself. For new entrants, accurate domain revenue recognition falls under the “what you don’t realise you don’t know” category. Building proper financial systems now & tweaking them to ensure they produce financial reports fit for purpose (forecasting, operational performance measurement & stat compliance) is time well spent and worth co-opting in help if necessary.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix