Beware trading in foreign parts

Export success for New Zealand software developers often means having to deal with multi-party distribution chains. Being distant from the end-customer, however, carries extra risk.

Export success for New Zealand software developers often means having to deal with multi-party distribution chains. Being distant from the end-customer, however, carries extra risk.

The attraction for the developer, having already sunk the R&D effort into getting the product into use, is to sit back and receive a steady income from an application service provider (ASP) or reseller. But there are two key risks that need to be managed.

First, the jurisdiction risk.

This arises from the mix of different legal requirements of each country reached through an internet-based distribution chain. Having customers scattered throughout the world is a heady achievement. Business is global, but national governments regulate the way business is done within their jurisdiction. There are laws governing the way contracts can be made, rights that are implied in contracts and regulations peculiar to different industries (traditionally highly regulated industries include healthcare, banking and share trading).

In New Zealand, perhaps one of the most often utilised statutory provisions is section 9 of the Fair Trading Act 1986. Section 9 provides that no person shall, in trade, engage in conduct that is misleading or deceptive or is likely to mislead or deceive.

The reason why this section is so often utilised as a cause of action is because section 9 claims do not rely on the existence of a contract. The result is that, even though it has no direct contact with the consumer, the software developer could be liable for any misleading representations.

As many countries have laws that operate in a similar fashion as section 9, a software company should consider seeking legal advice in its target markets. It could then exclude trading in countries where there is a significantly higher risk than the software company is willing to accept.

Simply, the developer that sells internationally has to be able learn the new skill of “localisation”; that is, making its software perform reliably while changing it to handle currencies, languages and compliance requirements.

The second risk that has to be managed is that of the customer relationship.

This arises from the loss of control that is unavoidable if there is an indirect customer relationship.

The lack of control in the customer relationship in an ASP or reseller model means that when things go wrong the developer cannot intervene directly to fix the customer’s problem and in fixing the problem mitigate liability.

The sales process through a distributor is often the key to why things go wrong. The distributor makes promises that the developer would not make to get the sale working on the basis that the developer can then be “blackmailed” into delivering the promise.

It is very difficult to ensure sufficient control is exercised by the distributor to guarantee that conduct of a section 9 type of claim nature does not occur.

One way of ensuring better control is for the developer to be involved in the process of assessing the fit between the computer system and the customer before even contemplating making the sale and to tightly manage the way installation or implementation of its software is scoped and delivered.

It is common practice for software companies to put in place “back-to-back” contracts in response to these sales and implementation risks. Such contracts often give the developer selling overseas a false sense of comfort that they have passed the whole of the risk on to the distributor or the customer. But what may work contractually in New Zealand or comply with New Zealand law may not work in, say, the US.

Developers can actively manage and control their risk rather than rely on passing risk to the distributor, which may not work. Developer risk management strategies include adopting a service control group model or a licensing model for a localised version, which quarantines the localised version from the core code.

A service control group is the services equivalent of a project control group. This model involves participation from each party in the distribution chain and it is charged with the purpose of ensuring that issues with service delivery can be addressed at an early stage and in a binding fashion.

The level of customisation that is required to the software will influence the risk management model adopted. If there is a high level of customisation required, the developer may be best managing its risk by adopting a teaming model as opposed to a reseller model. The teaming model ensures that, as each opportunity is signed on a site-by-site basis, the respective responsibilities of the teaming partners can be tailored according to the specific risk profile of the customer. Developers that concentrate on ways to actively manage their risk from an international perspective will find that this is a rewarding business strategy.

The objectives of reducing the risk of overselling, improving quality control in the distribution chain, taking care to ensure that end-customers are not abandoned because the distributor has earned their cut but has no long-term interest in the site and, finally, being able to demonstrate to insurers that a real and well-thought out risk management programme is part of the distribution model, will ease the problems of going global.

Neale is an associate and Miller a solicitor in Clendon Feeney’s technology law team. This article, together with further background comments and links to other websites, can be downloaded from Questions and comments are welcome to

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Tech Law

Show Comments