You're negotiating with a US vendor for a complex software development.
In response to the unwillingness of the vendor to give strong warranties around functionality, you propose a standard, staged acceptance test. Full acceptance will only occur after detailed tests have been passed. The vendor says "Well, we'd love to offer that, but we can't. The problem is accounting standards. We just could not recognise the revenue."
Have you ever been in that situation or know someone who has? Ever wondered what the vendor is talking about, why it is important and more crucially, should you accept that line?
Accounting - the root of evil?
Love it or hate it, accounting is the language of business. And accounting standards are the spelling and grammar rules that you have to follow.
Under US accounting standards, revenue cannot be recognised until it is certain. For a vendor this means:
- you have done the work asked for;
- you are entitled to be paid; and
- you are in fact likely to get paid.
The problem is in the IT world, sometimes these things are not all present at once.
Take acceptance tests. In IT, it is common that no payment is due until the tests are finally passed. This is despite much of the initial the work being done, and only the rectification still to be performed. In IT terms, as the customer has not received the end deliverables to a satisfactory standard and meeting the specifications, payment is deferred until the faults are rectified by the vendor. Unfortunately, this means under US accounting rules, the vendor cannot account for the revenue until the tests are indeed passed (if at all).
Why is this important?
The fact that a US vendor cannot "recognise revenue" would not cause many customers to lose sleep. But it does have a consequence for the vendor. US vendors typically report quarterly on the number and value of deals signed. The US market then values the worth of the vendor by its pipeline of work. If a deal cannot be recognised until the passing of acceptance tests or completion of some other criteria, then the deal is not valued until that point. The vendor suffers.
But are the vendors right?
US vendors claim that the inability to recognise revenue means that acceptance tests can't be set up in such a way that the customer is not obliged to pay for work that does not pass those tests. Vendors would rather say that the fixes will be done for free later, but the customer's obligation to pay exists now.
In essence, we are only talking about a timing difference - the delay between performing the work and the passing of an applicable acceptance test. If the vendor performs as required, then they will get the revenue - only slightly later.
The second point to note is that by simply restructuring the payments into milestones, the whole issue can be avoided.US accounting for construction contracts have for a long time recognised that a "percentage of completion" method will allow revenue to be recognised depending on how complete a project is.
In the IT world, this has translated into milestone payments. Progressive revenue can be recognised as the milestones are achieved - one being the passing of acceptance tests for a software development, but several may be earlier stages.
Result?
This approach of using milestones will allow progressive revenue recognition - depending on the nature of the milestones themselves.
So, a US vendor can recognise some of the revenue in stages - but importantly for the customer the balance is withheld until the vendor actually achieves the final task. This means the customer is not obliged to pay until they actually receive what they have contracted for.
A well-structured pricing schedule, and honest discussion of where each party is coming form should resolve this "revenue recognition" issue.
And accountants are not even to blame.
Quentin Lowcay
Senior Associate
T +61 2 9296 2080
quentin.lowcay@mallesons.com