海外からの配信に消費税を課税することを検討する模様
今日の日経の1面トップに 海外からの配信に消費税、財務相が検討表明 という記事が。早ければ 2014年4月の消費税増税と同時に実施って、こういうときだけやけに仕事早いなおい。
ちょうどこれに近い内容に関して某記者さんと先日お話をさせていただいたところだったので、自分的には大変タイムリーな話題。楽天あたりが海外の Kobo 社を買収して、海外からコンテンツを配信することで消費税を回避しようとしているようで、そういうことになったらご愁傷さまです。
海外の事業者に一体どうやって納税義務を果たさせるのか非常に興味深いところです。Google Play でEU向けに有料販売するときの VAT の扱いについて にも書きましたが、EU も VAT で同じことをやっていて、EU外からEU域内にデジタルコンテンツを販売するときには課税しているので、やってやれないことはないはずです。すんげえ面倒くさそうですが。
たぶん海外の事業者には、日本に対して消費税納税事業者登録みたいなことをさせて VAT Registration Number ならぬ JCT Registration Number なんかを発行したりして、Invoice にはこの番号書いてねーんみたいなことにして、だけども Google Play が発行する領収書には当然この番号が書いてないから、海外の事業者はせっせと自分で Invoice を発行しなくちゃいけないんだけども、Google Checkout API が提供されてないから自動化できなくてどうすんだよウワァァン、もう消費税なんて徴収しないし納税しないし知らない！なんて事業者がわんさか出てくるのが目に見えるようで、もう今から目頭が熱くなります。わかりにくいネタですいません。
まぁ、VAT の場合も、年間 EUR10,000 くらいの売上なら VAT 免税にしているようなので、小規模な事業者は免税とかにするのではないかと想像しています。何しろ、国内の事業者だって年間売上1,000万までは免税事業者ですし。そもそも、この海外配信に消費税を課税するのは、先の楽天のように海外に事業を移転して消費税を回避しようとしている事業者とか、Amazon みたいなかなり大規模な事業者をターゲットとしていると思われるので、中小事業者は Out of 眼中なのではないかと。だいたい小規模な事業者が EU みたいな VAT 登録なんて面倒くさくてやれんと思います。
海外には普通に考えて法的な強制力が及ばず実効性がどのくらいあるのか疑問なので、いっそ米国の輸出規制法(EAR)みたいに違反者を Denied Person List（禁止顧客リスト)に載せてその事業者と取引した国内事業者に罰則かけるといういわゆる「域外適用」をやってみたらいいんじゃねとふと思いつきました。だけど、あれは米国のように強い立場だからできる話なので、日本だと難しいだろうし、他にもいろいろ面倒だからやっぱ却下。
その一方で、国内の事業者としてはこれは歓迎するでしょうね。今のまま消費税増税になったら、ただでさえ円高で相当なハンデを負っているのにさらに追い打ちをかけることになってしまいますので。
どうでもいいけど、例の記事についてるはてなブックマークとか 2ch の投稿みてると、消費税の仕組みを全然わかってない人が大半で、愕然とします。消費税は事業者じゃなくて消費者が負担するものであるという根本的なところがわかってないとか、そもそも直接税と間接税の違いがわかってないとか。自分達消費者が納税者なんだから、もうちっと消費税のこと勉強しとけよ、と思うんですがね。あといまだに輸出戻し税が云々言う奴はあとで職員室に来なさい。
Anti AntiLVL - AntiLVL への簡単な対抗方法について考えてみる
故あって、Android の LVL を無効化する「AntiLVL」の対抗策を検討していたりします。
LVL (License Verification Library) は Google が提供する Android のライセンス検証用のライブラリで、簡単にいうと Google Play でちゃんと購入されたアプリかどうかをサーバに問い合わせて確認するというライブラリです。AntiLVL は、APK ファイルを書き換えてLVL を無効化してしまうというツールで、Google Play で有料アプリを購入してすぐに APK を取り出して注文キャンセルし LVL を無効化してしまえば不正にアプリを利用できるというわけです。そんなことする不届き者はとっとと氏ねばいいのにと思うわけですが。
AntiLVL での LVL 解除は非常に簡単にできてしまうので開発者としては何らかの対策が必要です。
署名検証すれば良いのでは？
AntiLVL は、APK を分解してデコンパイルし、バイトコードにパッチを当てて再度 APK に戻すことで LVL を解除しています。
APK の内容を改竄するので、当然開発者とは違う証明書で APK に署名することになるわけです。したがって、PackageManager を使って署名を確認し改竄されていないか確認すれば良さそうな気がしますよね。
ところが、AntiLVL は PackageManager を差し替えて署名を偽装するのでこれは容易ではありません。PackageManager を直接使わずリフレクション使えばいいじゃんと思うわけですが、AntiLVL はリフレクションの Method#invoke もフックするためこれもダメです。
JNI で native コードを書くか、jar ファイルをパッケージの中に入れておいて自前でクラスロードすれば回避できると思いますが、かなり面倒です。そこでここでは、署名検証せずに AntiLVL を回避する方法について考えてみます。
AntiLVL はどうやって LVL を解除しているのか
AntiLVL 1.4.0 の場合、LVL に含まれる ServerManagedPolicy と LicenseValidator の２つのクラスにパッチを当てています (これは AntiLVL の jar をバラして得られる XML ファイルにルールが書いてあります)
まず、ServerManagedPolicy の方。こちらは allowAccess() メソッドの返り値を強制的に true に変更します。具体的には、以下のようにしてパッチを行います。
- 以下の条件のいずれかを満たすクラスは、ServerManagedPolicy クラスと判断します (他にもいくつか条件があるが省略)
- "com.android.vending.licensing." という文字列が含まれる
- "ServerManagedPolicy" という文字列が含まれる
- "validityTimestamp" という定数文字列が含まれる
- この中に、以下のメソッドがあれば allowAccess() と判断します
- public なメソッド
- System.currentTimeMillis() を呼んでいる
LicenseValidator のほうは、verify() メソッド内の switch - case 文を書き換え、全部 LICENSED と判定するようにします。具体的には:
対策方法
ここまでわかれば、対策としては比較的簡単です。やり方はいくつかありますが、例えば以下のようにすればよいでしょう。当然 ProGuard の難読化は必要です。
- ServerManagedPolicy クラスは
- 文字列定数の PREFS_FILE, PREF_VALIDITY_TIMESTAMP を違う文字列に変更します (変更しても動作には影響ないはず。詳細はソース参照)
- allowAccess() は System.currentTimeMillis() を直接呼ばず、別のメソッドを経由して呼ぶように変更
- LicenseValidator クラスは
- verify メソッドの switch - case 文を if 文に変更します。
とりあえず、この修正を加えれば AntiLVL は効かなくなります。
また、AntiLVL を罠にかけるために、わざと AntiLVL が書き換えるようなコードを仕込んでおくという手もあります。上記 ServerManagedPolicy そっくりのクラスを作っておき、allowAccess は必ず false を返すようにしておきます。AntiLVL で書き換えた APK では allowAccess の返り値が必ず true になるので、true になっていれば AntiLVL により書き換えられたことが判別できるので、ライセンス違反と判定すればいいでしょう。
いたちごっこなので AntiLVL 側がさらに対策してくる可能性もありますが、そもそもの問題はみなが同じ LVL ライブラリを使っていることが問題なので、みなが少しずつ違う実装にしていれば AntiLVL 側では対処できなくなるはずです。
PS. CashFlow は対策済みです。
Google Play の取引手数料が税込価格の30%にこっそり変わってる件 (修正済)
補足: 本問題は 7/17 に修正されました。詳細は追記参照。
先月 5/23日より、Google Play の価格表示が税込価格に変更になりました。これは前々回のブログに書いたとおりで、ちゃんと総額表示できるようになったので歓迎すべき修正です。
んが、実はそれと同時に30%の取引手数料もこっそり変更されてました。従来は「税抜き価格の」30%だったんですが、これが「税込価格の」30% になっています。つまり、実質取引手数料が 5% 値上げ。Google さん、何も言わずにこんな重要な変更も一緒にやるなんて、冗談きついです。英語のヘルプには今でもしっかり税抜き価格 (Net price) の30%って書いてあるのにー。
Google Checkout の明細の抜粋はこんな感じ。
左が5/22より前、右が5/22以後の明細です。税込価格表示記念（なんの記念だ）で値下げをしたので比較しにくいですが、以前は税抜価格 230円の30% = 69 円が手数料だったのですが、5/22以後は税込価格 210 円の 30% = 63 円が手数料となっております。
で、税込価格から手数料とるんだから、当然手数料には消費税入ってるんだよね、とか思うわけですが、明細にはその消費税額は記載されていません。どっちだよ！！まぁ、記載されていない以上は、税込ではない（つまり以前の記事にも書いたとおり不課税取引）として扱うしかないでしょうね。つまり実質手数料値上げというわけです。
んもう。。。
ちなみに、海外でも問題になっている模様 ⇒ Transaction fees calculated false from today on!!!
'12/6/18 追記 : どうやら Google 側のシステムの問題だった模様。Developer Console に以下の告知がでており、早急に修正して返金するとのことです。
Errors in transaction charges due to VAT-inclusive pricing
We are aware of the reports of errors in transaction charges due to VAT-inclusive pricing and are working to resolve the issue. Once the problem is fixed, the correct amounts will be charged for VAT-inclusive purchases and we will reimburse any developers who have been impacted as soon as possible.
'12/7/31 追記 : 計算方法が無事に元に戻りました。7/17に修正がされたようです。⇒ https://groups.google.com/forum/?hl=ja&fromgroups#!topic/android-sdk-japan/k6DVm0LhmZE
三菱東京UFJが OFX の出力機能を無くした模様
三菱東京UFJ銀行が、Money電子明細(OFX)の出力機能を外した模様。このため、数日前から FeliCa2Moneyの問い合わせが急増中。
主に、CSV の取り込みがうまく行かないとか、摘要の取り込み時に従来の OFX と入力項目が違うとか。そう言われても、自分は三菱東京UFJ使ってない(実は口座は持ってるけど)ので、正直なところ知らんがな、というしかないのだけど。対応して欲しいのなら、せめてどういうフォーマットの CSV が出力されるのか、サンプルくらい送ってきてくれないと何ともならん。
CSV の変換ルールは、今のところ私しか公式に取り込む方法がないのだけど、ふぉーくそのみー的（死語）にユーザがばんばん定義を追加していけるようにしたほうがいいでしょうかね。FeliCa2Money に改造いるけど。あと完全ボランティアだから自分には全然インセンティブはないけど。
それと本当は FeliCa2Money の Android 版作りたいんですよね。Android デバイスをカードにかざしたら OFX がメールで飛んでくる or Dropbox に OFX が入る的な。Android内のFeliCa読めるAPIもあったら速攻作るんだけど。CashFlow への取り込み機能付きで。
あと、OFX は別に Microsoft Money 専用のフォーマットではなく業界標準フォーマットなので、金融機関各位におかれましてはサポートを外さないようお願いしたく。ていうか、OFX出力外した金融機関は全資産引っこ抜いて別の金融機関に移ったろうか、という気持ちなのですが、もう国内の銀行はほぼ OFX 全滅 (というか三菱東京UFJがほぼ最後？)なので、なんともなりませんねぇ。
クレジットカードはまだ OFX 対応しているところがいくつかあるんですけどねー。
Google Play の価格表示が税込価格になりました
本日(2012/5/21)付で、ようやく Google Play の価格表示が税込価格になりました。開発者がきちんと税率設定をしていれば、きちんと税込価格が表示されるようになっています。
開発者は、Developer Console で税抜き価格を設定するようになっています。
上の表示からわかる通り、税抜き価格を指定します。そして、各国毎の価格には下のように税込価格と税率がきちんと表示されます。
これで総額表示義務もきちんと果たせるようになり、一安心ですね。
Google Play でEU向けに有料販売するときの VAT の扱いについて
'14/10/28追記 : 2015/1/1 から、VAT については Google が代行徴収と納付を行ってくれることになったようです。
海外向けに Google Play で販売するときの現地間接税(Sales Tax や VAT など)について少し調べています。今回はEUのVAT(付加価値税）についてメモ。
id:tmurakam:20120321#1332256170 にも書いたとおり、Google は間接税の徴収・当局への納税は一切やってくれないので、販売者側で責任を持ってやる必要があります (Apple は EU については代行してくれています)
消費税や VAT のような間接税は基本的に最終消費者が負担するわけですが、国をまたいだいわゆる「クロスボーダー」取引はこれが課税対象になるのかどうかが問題になります。
大抵の場合物理的なモノ（貨物）の場合は基本的に消費地、つまり買った側の国で課税されます。具体的には税関を通るときに課税するわけです。だからあまり難しく考える必要はありません。
ところがデジタルコンテンツのようないわゆる「クロスボーダー電子商取引」の場合、税関を通らないので判断が難しくなります。参考文献をいろいろ探してみたところ、貿易関係の書物はたくさんあるんですが貨物（物理的なモノ）を扱っているのがほとんど、つまり税関を通すものについての言及ばかりで、デジタルコンテンツについて書かれているものがなかなかありません。そんな中で電子商取引をめぐる課税上の取扱いについては結構しっかり書かれていておすすめ。
日本の消費税の場合は、デジタルコンテンツ販売のような役務提供は役務提供地で判定します。つまり、米国から日本に販売する場合、役務提供地が米国なので日本の消費税は課税対象外です。ところが、EU の場合はそうではなく、消費地課税になります。つまり日本から EU 内の消費者に販売する場合、現地の VAT の課税対象になるということです。これは上記文書の 31 ページ目あたりに書いてあります。また JETROの税制-EU にも以下のように記載されています。
さらに、理事会指令2008/8/ECは、サービスの事業者間取引一般について、従来の供給者所在国での課税から変更し、原則として、サービス受益者の所在地で課税されることとした。BtoCの取引には、従来どおり供給地の税率が課される。ただし、上記の2002/38/ECで導入された電子サービスの消費地課税主義は維持される。
つまり、B2C の電子サービス提供については、消費地課税になる、ということです。
事業者間取引(B2B) の場合は、EU内の輸入者側が最終消費者から徴収・納税するので販売側は相手に任せておけばいいんですが、Google Play のように販売者から消費者への直接販売(B2C)ではそうはいきません。日本国内の販売者（つまり我々）が VAT を徴収し、EU の当局に納税しなければならないのです！
これを行うためには VAT 登録を行う必要があります。ただ、実際には販売額が大きくなければ、VAT は免税になるようですので、個人でそれほど売れていなければさほど心配する必要はありません。EU向けインターネット販売する際のVAT登録によると、EU域内消費者通信販売の特例(DIRECTIVE 2006/112/EC の Section 3(2)(a))というのがあり、販売額が一定額を超えなければ免税です。具体的な金額は、このページの「EU域内消費者通信販売の特例」適用のための上限額一覧」リンク先にあります。国によって違いますが、だいたい年間 10,000ユーロくらい？ちょっと頑張って売れちゃったら割りと超えてしまいそうです (いや、Google Play だとそんなに売れないか、、、)
なお、VAT登録を行う場合は、EU 内の一国に対してのみ VAT 登録を行い、EU内の各国消費者から徴収したVATを VAT登録した国の当局に払う(税率はもちろん国によって違います)、というワンストップショップ制になっており、国ごとに VAT 登録は必要ない模様。それでも、個人レベルでそこまでやれるかというとかなり無理な気がします。
そうそう、あと VAT 登録して販売する場合、VAT Invoice (請求書・領収書ですね)には VAT Registration Number を記載しなければなりません。んが、Google が発行する領収書にはそんなもの書いてくれません。どーするんでしょうね。海外の掲示板で見たところ、VAT Registration Number を記載した VAT Invoice をユーザ毎にメールで出してる、と言っている開発者がいましたが、マジですか、、、自動化しなきゃ無理ポですが、さらに Google Checkout API は US/UK の開発者しか使えないので自動化もほぼ無理という罠仕様。
そんなわけで VAT はかなり面倒な雰囲気が漂うことはわかりました。米国の Sales Tax はこれに比べるとだいぶ楽らしいですが、、、
