EU VAT rules 2015: A mess for startups

This post originally appeared under the title “Why the new 2015 EU VAT rules are actively harmful to startups” on March, 24th 2015 as a guest post at tech.eu.

Seven years ago, in February 2008, the Council of the European Union approved Directive 2008/8/EC to little fanfare. Now, seven years later, this directive is back to haunt European startups on a massive scale with its new VAT (Value Added Tax) rules on the place of supply.

The new rules in a nutshell.

With effect from 1 January, 2015 the place of supply for electronic services (also telecommunication services and broadcasting) provided to consumers is deemed to be the location of the consumer.

Previously the place of supply for e.g. a SaaS (Software as a Service) company providing its services to consumers would -in general- have been the location of the company.

The place of supply is important for tax purposes. It decides where the company is liable for VAT.

Under the old rules, it didn’t matter where a customer was located. A company would always have paid the local VAT rate in its own country, because the place of supply was at the location of the company (for example a german SaaS company would have paid 19% VAT on its sales to its local tax office, regardless if the customer is located in Germany, Italy, Austria or elsewhere in the European Union).

Under the new rules however, because the place of supply is deemed to be at the location of the customer, the company has to pay VAT to the foreign tax authorities (for example a German SaaS company selling to a German customer has to pay 19% VAT to its local tax office, but for its sales to Italian customers it has to pay 22% VAT to the Italian tax authorities, for sales to its Austrian customers 20% VAT to the tax authorities in Austria, and so on).

To comply with these new rules, companies either have to register in each country they are selling to and report their sales to this country or register for the MOSS (Mini One Stop Shop) scheme in their own country and file country by country reports there.


What is the idea behind these rules?

These new rules are designed to prevent so called jurisdiction shopping. Under the old rules, multinational corporations (e.g. Apple) were able benefit from lower VAT rates, simply by deciding where they incorporated their European distribution subsidiaries (e.g. iTunes S.à r.l. in Luxemburg). The new rules prevent this jurisdiction shopping -at least for VAT purposes- as companies are always liable for VAT in the country of their customer and with the VAT rate of that country.

These new rules are harmful to startups.

One might think that companies had seven years to prepare for these new rules, but many aren’t even aware due to the extremely poor communication of tax authorities and governments. But even if companies would be largely aware, startups typically neither have the manpower in-house, nor an army of consultants and tax advisors to take care of the extra burden generated by these new rules – unlike multinational corporations, where even the headcount of the in-house tax department typically surpasses the total headcount of an early stage startup.

A startup is a company designed to grow fast. To achieve this growth, they will often sell internationally right from the start and because of this run into the brick wall of international tax compliancy way before they are prepared to deal with this complexity.

The Mini One Stop Shop doesn’t fix the problem.

With the MOSS scheme companies don’t have to report and register in each and every country they are selling to, but they still have to report their per-country sales to the MOSS in their own country. In Germany the competent authority is e.g. the Federal Central Tax Office.

Admittedly, reporting country-by-country sales to the MOSS instead to each and every country is a lot less complex, but companies are still severely affected by these new VAT rules:

  • Requirement to ask customers for more data during checkout, which negatively affects conversions.
  • Additional work to compile country-by-country reports (and often no easy way to automatically gather this data from payment processors).
  • Development time for invoice handling instead of product features.
  • Additional work for tax advisors resulting in higher costs for companies.
  • More admin overhead with separate MOSS filings in additional to normal tax reporting.

Bottom line: startups are currently forced to burn precious time and money that would be way better invested in building a great product and finding the right customers for it.

How to fix VAT for EU startups?

One easy way to fix this would be to exempt companies with sales below a certain threshold from these rules – similar to the exemption for the supply of goods up to the threshold of 100,000 EUR in Article 34 in Directive 2006/112/EC. Up to this threshold companies would pay VAT on their consumer sales in the country they are located.

A threshold would allow startups to focus on building great products and investing their time and energy in their growth, but also effectively prevent big multinationals from jurisdiction shopping and ensure that VAT yields get distributed fairly between countries within the European Union.


Any comments? Ping me on Twitter.

The perfect AWS ELB SSL Configuration

When setting up an Elastic Load Balancers (ELBs) at Amazon Web Services (AWS) with HTTPS listeners, the predefined SSL configuration (currently ELBSecurityPolicy-2015-02) is usually perfectly sufficient.

With this latest policy, outdated and vulnerable protocols such as SSLv2 and SSLv3 are disabled, server order preference is used and outdated vulnerable SSL ciphers such as RC4 are disabled. In tandem with HTTP Strict Transport Security (HSTS), this is a pretty solid setup for your ELB.

But there is a catch.

If you still have users stuck with Windows XP their computer won’t be able to negotiate any cipher it supports with your load balancer, so all of these users are unable to use your service.


The bad option: Use ELBSecurityPolicy-2014-10

Using ELBSecurityPolicy-2014-10 enables the ECDHE-RSA-RC4-SHA and RC4-SHA ciphers, which are supported by Windows XP. Unfortunately RC4 is vulnerable (e.g. Mozilla and Microsoft as well as many others recommend to disable it where possible) and should be avoided at all cost, both to keep users safe as well as to maintain a good rating in your SSL Labs Report.

The good option: Configure your own Security Policy

If you have to support Windows XP clients, you can’t use ELBSecurityPolicy-2015-02 and you don’t want to use ELBSecurityPolicy-2014-10 because it’s weak. Luckily there’s the DES-CBC3-SHA cipher, which is supported by Windows XP and still considered secure.

To use that, you have to create a Security Policy for your load balancer and then activate it for each listener. This can be done with the AWS Command Line tools in two commands.

Update (March, 18th 2015)

The new AWS provided policy ELBSecurityPolicy-2015-02 also solves this issue:

Create a new Security Policy

To create the security policy (you’ll have to repeat this step for each of your load balancers) run the following command. Make sure to set --load-balancer-name, --policy-name and --region correctly.

aws elb create-load-balancer-policy \
--load-balancer-name myloadbalancer \
--policy-name MySecurityPolicy-2015-03 \
--policy-type-name SSLNegotiationPolicyType \
--region eu-central-1 \
--policy-attributes \
AttributeName=Protocol-TLSv1,AttributeValue=true \
AttributeName=Protocol-TLSv1.1,AttributeValue=true \
AttributeName=Protocol-TLSv1.2,AttributeValue=true \
AttributeName=Server-Defined-Cipher-Order,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES128-GCM-SHA256,AttributeValue=true \
AttributeName=ECDHE-RSA-AES128-GCM-SHA256,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES128-SHA256,AttributeValue=true \
AttributeName=ECDHE-RSA-AES128-SHA256,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES128-SHA,AttributeValue=true \
AttributeName=ECDHE-RSA-AES128-SHA,AttributeValue=true \
AttributeName=DHE-RSA-AES128-SHA,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES256-GCM-SHA384,AttributeValue=true \
AttributeName=ECDHE-RSA-AES256-GCM-SHA384,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES256-SHA384,AttributeValue=true \
AttributeName=ECDHE-RSA-AES256-SHA384,AttributeValue=true \
AttributeName=ECDHE-RSA-AES256-SHA,AttributeValue=true \
AttributeName=ECDHE-ECDSA-AES256-SHA,AttributeValue=true \
AttributeName=AES128-GCM-SHA256,AttributeValue=true \
AttributeName=AES128-SHA256,AttributeValue=true \
AttributeName=AES128-SHA,AttributeValue=true \
AttributeName=AES256-GCM-SHA384,AttributeValue=true \
AttributeName=AES256-SHA256,AttributeValue=true \
AttributeName=AES256-SHA,AttributeValue=true \
AttributeName=DHE-DSS-AES128-SHA,AttributeValue=true \
AttributeName=DES-CBC3-SHA,AttributeValue=true

Activate your new Security Policy

Now activate the new policy for all of your HTTPS listeners on your load balancers. Make sure to set --load-balancer-name, --policy-name, --port and --region correctly.

aws elb set-load-balancer-policies-of-listener --load-balancer-name myloadbalancer --load-balancer-port 443 --policy-name MySecurityPolicy-2015-03 --region eu-central-1

That’s it. Now you have a secure SSL configuration for your ELB and still support Windows XP. We use this configuration at fruux (here’s our SSL Labs Report).


Any comments? Ping me on Twitter.

Federated Stellar addresses

A few days ago a nonprofit foundation, partly backed by Stripe, launched a new decentralized payment network (similar to Bitcoin) called Stellar. Unlike with Bitcoins Stellar doesn’t get mined (so maybe the vast amount of computing power of all this mining hardware could get used to sequence DNA or run SETI@home in the future) and Stellar supports transactions in arbitrary currencies via so called gateways. To learn more about Stellar, their launch blog post and Stripe’s blog post is probably a good starting point.

Another interesting feature of Stellar is federation.


What federation is about

Each Stellar user has both a wallet address (similar to Bitcoin) as well as a human readable username for that address (which is quite handy as sending a payment to e.g. watsi is a lot easier than sending one to gN4oHfh4iLRCSsrHVxVHzt6rZXs6EyTCe4). What’s nice about these usernames is that they are actually federated addresses and not just usernames. The username watsi is just the short version of watsi@stellar.org.

Stellars federation protocol makes it possible to set up federated addresses for your domain. That means, that if you control the domain example.org, you could receive payments under e.g. john.doe@example.org. Think about it like some kind of domain name system for wallet addresses. Stripe’s CTO Greg wrote a blog post with some more details about how federation works and also provides a link to his sample federation server there.

How a client figures out the recipients wallet address

Just to give you a rough idea, here’s a quick overview of how a Stellar client figures out the recipients wallet address.

Locate and parse stellar.txt

When you are trying to send Stellar to e.g. john.doe@example.org the client first tries to find a file called stellar.txt for the example.org domain by trying the following URLs in this order:

  • https://stellar.example.org/stellar.txt
  • https://example.org/stellar.txt
  • https://www.example.org/stellar.txt

If the file is found, the client parses it for the URL of the federation server that’s responsible for this domain. For this example the contents of that file might look something like this:

[federation_url]
https://federation-server.example.org

Query federation server

Now the client makes it’s final request and asks the responsible federation server for the wallet address of john.doe@example.org. If everything worked out as expected and the federation server actually knew that user, the client now knows the wallet address for john.doe@example.org and is able to send a payment.

Running your own federation server

To run your own federation server you’ll need a valid SSL certificate for both the server where your stellar.txt file is located as well as for the domain your federation server itself is running on (those two could of course be the same). If you are also curious about Stellar federation you can give my implementation (it’s on GitHub) a try.

Disclaimer

A quick word of warning: I put this together for fun and haven’t spent a lot of time with it, so please use it at your own risk and don’t sue me if you end up sending your life savings to /dev/null. :) The federation protocol itself also still seems to be evolving, so things might break when they change the protocol.

Let me know if you find bugs or have suggestions for improvement.


Any comments? Ping me on Twitter.

PEAR on OS X 10.10 Yosemite

Like previous versions of OS X, 10.10 also ships with PEAR. Installing and activating it is easy. Once that’s done PEAR and PECL work as expected (if you also want to set up and install Apache, PHP and MySQL, check this post.


Installing PEAR

cd /usr/lib/php
sudo php install-pear-nozlib.phar

If that fails

autoconf may be missing. To install it just use Homebrew. Once Homebrew is installed, installing autoconf is as simple as:

brew install autoconf

After autoconf is installed, try running the pear installer above again.

Upgrade PEAR

sudo pear channel-update pear.php.net
sudo pecl channel-update pecl.php.net
sudo pear upgrade-all

Xcode Command Line Developer Tools

You will run into problems installing pecl extensions, if you don’t have the Xcode Command Line Extensions installed, so we’ll also install them.

xcode-select --install

Configuring PHP

Open /etc/php.ini and add .:/usr/lib/php/pear to include_path (if /etc/php.ini does not exist, create it with the following content).

include_path = ".:/usr/lib/php/pear"

Any comments? Ping me on Twitter.

Apache, MySQL & PHP on OS X Yosemite

OS X 10.10 ships with both a recent version of Apache (2.4.x), as well as PHP (5.5.x), so you’ll just have to install MySQL and go through a few steps to get everything up and running.

Apache

First, you have to create a web root in your user account:

mkdir ~/Sites

Then add a configuration for your user:

sudo tee /etc/apache2/users/$USER.conf <<EOF
<Directory "$HOME/Sites/">
Options Indexes MultiViews FollowSymLinks
AllowOverride All
Require all granted
</Directory>
EOF

Now we have to make sure that our user config above actually gets loaded:

sudo tee -a /etc/apache2/other/$USER-settings.conf <<EOF
Include /private/etc/apache2/users/*.conf
EOF

If you want to use vhosts, you’ll also have to make sure that the vhosts config gets loaded:

sudo tee -a /etc/apache2/other/$USER-settings.conf <<EOF
Include /private/etc/apache2/extra/httpd-vhosts.conf
EOF

After that, configure vhosts as necessary in /etc/apache2/extra/httpd-vhosts.conf (don’t forget to remove the examples in there).

It seems that mod_rewrite no longer gets loaded by default, so we’ll also add that to our config:

sudo tee -a /etc/apache2/other/$USER-settings.conf <<EOF
LoadModule rewrite_module libexec/apache2/mod_rewrite.so
EOF

PHP

PHP doesn’t get loaded by default. So we’ll also add it to our config:

sudo tee -a /etc/apache2/other/$USER-settings.conf <<EOF
LoadModule php5_module libexec/apache2/libphp5.so
EOF

You should also configure a few settings in /etc/php.ini:

sudo tee -a /etc/php.ini <<EOF
date.timezone = "`sudo systemsetup -gettimezone | awk '{print $3}'`"
display_errors = on
error_reporting = -1
EOF

To activate these settings you have to restart Apache:

sudo apachectl restart

If you also need PEAR/PECL, follow these instructions.

MySQL

MySQL is not shipped with OS X, so we’ll have to install that manually. Instead of going for an installer package, we’ll use Homebrew. Once Homebrew is installed, installing MySQL is as simple as:

brew install mysql

If you want to start MySQL automatically, the Caveats section from the output of the following command will show you how:

brew info mysql

Any comments? Ping me on Twitter.