Freelancing from Germany in the US

This post is for anyone who plans to work for a US company as a freelancer, living in Germany. It assumes that you’re already registered as a freelancer in Germany. As you should be used to, a blog post is no replacement for proper legal advice.

The good news: You don’t need any permits to freelance from Germany for US companies. That doesn’t apply anymore when you travel to the US, see below for some details.

To start with: What about taxes?

Taxes

In short: You only pay income tax in Germany. You don’t add VAT (Umsatzsteuer/USt), like you would for german clients, and you don’t pay any taxes in the US.

The legal base for that is an agreement between Germany and the US from 1989 that intends to avoid double taxing. The german law that puts the agreement into practice is called “Abkommen vom 29. August 1989 zwischen der Bundesrepublik Deutschland und den Vereinigten Staaten von Amerika zur Vermeidung der Doppelbesteuerung und zur Verhinderung der Steuerverkürzung auf dem Gebiet der Steuern vom Einkommen und vom Vermögen und einiger anderer Steuern”. I’ve looked up the page that has the full text of the agreement, the law text and a few change document (patches!) for you. The relevant article of the agreement itself is article 7, “Business Profits”.

As for why you don’t have to charge and pay Umsatzsteuer for US clients: I can’t tell you where exactly that’s regulated. Though there’s a multi-language phone support service, established by a cooperation between  Germany, Netherlands and Belgium. You can find the free local phone number for each country on their page here. I called there back in 2010 when I was starting my freelance career and called there again today to check if the service is still up and running. You’re likely to talk to someone from the Netherlands first (they speak german, too), but you can leave a number for a german colleague to call you back. I got the information about the Doppelbesteuerungsabkommen (DBA) from there, while my german tax consultant had no clue.

How to get paid

Before you start your first project with a client from the US, you need to agree on how to get paid. There are a two important descisions: What currency are you getting paid in? How will you get your money?

For the currency you can agree on a hourly rate (or whatever you do) in USD. In this case, whenever the exchange rate between USD and EUR changes, you end up with more or less money then you originally planned with. This can be both good and bad. You risk getting paid less, with the chance of getting paid more. The alternative is to get paid in EUR. That moves the exchange rate gamble to your client, since there’s no way to completely avoid it. On newer projects I recently tend to ask to get paid in EUR, so far no client had a problem with that.

Either way, next up is figuring out how to actually get your money. While PayPal works for small amounts, their percentage-based fee gets really expensive when invoicing a full month of work. At a rate of 50€ per hour you’d invoice 8000€ for a full month of work, which means several hundred Euros in PayPal fees. In that case, wire transfers through old school banks are a lot cheaper. They will also charge you, usually on both ends, but at least in my experience so far, they only charge a fixed price based on fixed thresholds. For example, anything below 5000€ would cost you 20€, anything below 20.000€ would costs you 50€. The actual numbers depend on the bank. In practice, there’s still a lot of variations: On one project, I invoiced in USD and eventually an amount in EUR landed on my business bank account. Inbetween, both banks charged fees and converted from USD to EUR. On another project, I invoiced in EUR and got exactly the amount I invoiced. I’m not sure how exactly that worked and how much my client ended up paying on top, or if they just used a less greedy bank, but it worked pretty well for me. In general, ask your client to spend some time researching options, both to speed up the transfer and to reduce costs for you and them.

So much for the money aspects. Another interesting one:

Timezones

Timezones are annoying. Timezone math is annoying, calendars are annoying, but there’s no way around them. And the idea to adopt UTC time everywhere isn’t very likely to go anywhere, considering that we can’t even drop daylight saving time (DST). Speaking of which, twice per year there’s this fun period between a few days and a few weeks where Germany is still on DST, while the US isn’t anymore. Or the other way round. In practice, the time difference between you and your client shifts an hour, for a while. So every single meeting is at a different time.

For that and for keeping your sanity in general, use a calendar application that allows you to specify the timezone of a meeting. Google Calendar does that, it even allows you to display your calendar with multiple timezones at once. In my case that meant setting all the timezones of meetings related to the jQuery project to east coast time (ET). That way, the meeting time would adjust on my calendar for those periods of the year.

Different timezones also mean different work hours. Unless you’re already sleeping during the day and working at night, you should find clients that are on the east coast and get up pretty early. If you get up late, your work hours might still not fully overlap, but at least you share several hours during each day and you can still have some non-work activities in your evenings. Working with people on the west coast and their nine hour time difference is really exhausting, since your day is done by the time they get up.

Traveling to the US

Above I layed out that you can work for a US company from Germany and the tax situation is pretty okay. The picture looks quite different if you consider traveling to the US or even staying there to work on site. From that moment on, the US have a huge interest in your activity. I’ve only ever visited the US to meet friends and attend conferences. If you plan to do that, you’re fine, at least with a german citizenship, since you get a three month VISA automatically. You just need to apply for ETSA (all online, requires a credit card to pay the $15 fee). If you plan to actually work in the US, you have to ask someone else, though this Engineer’s Guide to US Visas is a good starting point. You certainly shouldn’t fly to the US with the intention to work there without knowing anything about this.

Closing Notes

There’s probably a lot more I could write about this topic. If there’s something you’d like to know about, tell me! Send an email or ask me on Twitter. If you have corrections or suggestions to anything, please also let me know and I’ll update the post accordingly.

When new is worse: MacBook Air 2012 screens

This is another guest post by my friend Tobi. —Jörn

It has been a few weeks since I bought a brand new Apple MacBook Air Mid 2012. As far as I tested it is a very solid piece of hardware. Nevertheless, there is one annoying point I want to show up within this post.

All began when I noticed a gray gradient starting in the lower region of the display close to where it ends. This gradient is well visible if the display is dimmed to around 4 points in the brightness settings and if you are looking at a white area in fullscreen mode. It is around 3-4mm thick. After I compared it with the MacBook Air 2010 of Jörn we found out that it only affects the MacBook Air 2012. So I called Apple Care and they told me that it shouldn’t be like this but to be sure I should go to an Apple Store.

So I went to the closest Apple Store and explained my concern. After the sales guy agreed, we compared it with the other MacBook Air 2012 in the store and found out that each of them has this issue. So I did some research investigation and as far as I cantell based on my personal experience and from what I found on the web, the quality of the panels in the MacBook Air of the current 2012 generation decreased compared to the MacBook Airs built in 2010.

There are three manufacturers supplying panels for the MacBook Air 2012. Here is a short break down of the facts:

Samsung: Best white and black levels, best contrast, best color gamut
LG: Best color accuracy but the colors appears to be washed out. This can be handled by the color settings
AUO: Used in the 11″ MacBook Air, but I couldn’t find any information about this panel.

To find out which panel you have type this into the terminal

ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | strings -6

The first to letters are relevant:

LP = LG
LT = Samsung
B = AUO

Unfortunately, all of those panels have the issue I described above – some more and some less visible (even the replacements). If you can’t life with it, don’t buy a MacBook Air 2012.

Some references:

Release: Validation Plugin 1.11.0

A new version of the jQuery Validation Plugin is available. Once again this release brings more stability (bug fixes!), better localization (new: Malay) and improved html5 compability (min/max attributes on type=”date” now work with the min/max methods). More details on the code and feature changes in the changelog below.

Backwards compatibility is still going strong: The plugin should work with anything from jQuery 1.4.x to 1.9.x.

This is the first release to make it to the new jQuery Plugins site.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation!

Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com !

The full changelog:

  • Remove clearing as numbers of `min`, `max` and `range` rules. Fixes #455. Closes gh-528.
  • Update pre-existing labels – fixes #430 closes gh-436
  • Fix $.validator.format to avoid group interpolation, where at least IE8/9 replaces -bash with the match. Fixes #614
  • Fix mimetype regex
  • Add plugin manifest and update headers to just MIT license, drop unnecessary dual-licensing (like jQuery).
  • Hebrew messages: Removed dots at end of sentences – Fixes gh-568
  • French translation for require_from_group validation. Fixes gh-573.
  • Allow groups to be an array or a string – Fixes #479
  • Removed spaces with multiple MIME types
  • Fix some date validations, JS syntax errors.
  • Remove support for metadata plugin, replace with data-rule- and data-msg- (added in 907467e8) properties.
  • Added sftp as a valid url-pattern
  • Add Malay (my) localization
  • Update localization/messages_hu.js
  • Remove focusin/focusout polyfill. Fixes #542 – Inclusion of jquery.validate interfers with focusin and focusout events in IE9
  • Localization: Fixed typo in finnish translation
  • Fix RTM demo to show invalid icon when going from valid back to invalid
  • Fixed premature return in remote function which prevented ajax call from being made in case an input was entered too quickly. Ensures remote validation always validates the newest value.
  • Undo fix for #244. Fixes #521 – E-mail validation fires immediately when text is in the field.
As usual:
  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, eg. new validation methods) to the GitHub issue tracker

Enjoy!

Cologne.js 2012

Cologne.js is this little user group that a few people founded in June 2010. Michael Bumann, offered to host the event at Cowoco, and has been regularly around since then. After half a year, we crowd-funded a projector and donated it to Cowoco, which meant that everything we needed was right on site. For quite some time, Matthias Luebken ran most of the time, recruiting speakers and advertising the events through Twitter and the mailing list. Its probably been a year now since Frederic Hemberger and myself took fully over. It has been challenging and frustrating at times, but especially our latest meetup in December was a very special success, and I wanted to write some more about that.

For the second time this year, we arranged a sponsored speaker to come to our event and speak there, with a local company paying the travel expenses (big thanks to Railslove and Denkwerk). We had Felix Geisendörfer come from Berlin to talk about NodeCopter. He told us how the idea came together, how it went from a singular event to a whole series with more planned for the summer next year. He live demoed his nodejs based library to program the drone, then went on to even write a custom firmware to execute directly on the drone itself. It was a lot of fun, mixed with learning about binary encodings to write a drone firmware.

As a kind of warm-up, Sebastian Golasch, by now a regular at our event, talked about what he dubbed Dirty Little Helper. Walking us through various hardware-browser setups, including his MakeyMakey based Simon-Says clone, he eventually presented his custom home automation setup. Remotely turn off lights and use your laptop camera to check on things, all DIY-style with cheap and simple components. I’m ordering a MakeyMakey!

The third talk, with which the evening started, was by Jan-Christoph Borchardt talking about Unhosted and Remote Storage. His colleague and founder of Unhosted told me about the ideas behind Unhosted last year at a beer.js event in Berlin, so it was quite interesting to me how far they came along. The remoteStorage specification, along with a reference implementation, can be used today to build applications where you control where your data is stored, instead of having to buy-in to editors attached to storage like Google Docs forces you to. Its unclear how much mainstream traction this will be able to achieve, but its an important idea worth spreading.

Those were the three talks that we advertised with. We ended up with a record number of visitors of 50! A lot of people also followed our beer.js invitation and stayed around after the talks, forcing Bumi to refill the beer fridge, since also a record number of drinks were consumed. Thanks to 5apps for sponsoring that.

I’m excited about next year. We’ve got one talk lined up for January already, but are, as usual, looking for more. If you want to present something, let us know (Twitter, email).