Excelの1900/2/29問題は仕様です!?

f:id:boost-up:20171215204329j:plain

今日は何となく1900/2/29問題のことを思い出しましたので、事象と背景について書いてみたいと思います。

1900/2/29問題ってそもそも何?

おそらく、普段Excelを仕事に活用されている方でも、1900/2/29問題を知っている人の方が少ないと思いますが、この問題は実際には存在しない1900/2/29という日付をExcelが有効な日付と認識している現象です。

言葉で説明するよりも実例を見て頂いた方が分かりやすいと思いますので、下のキャプチャをご覧ください。

f:id:boost-up:20171215194119p:plain

A列とB列には同じ年月日を入力しており、書式設定をA列は「日付」、B列は「標準」にしています。 Excelの日付は1900/1/1を1日目としてカウントしていきますので、3行目の1900/1/1が1となります。

2行目の1899/12/31は有効な日付と認識されず、文字として認識されています(左寄せになっていることがお判りでしょうか?)。 そして、5行目の1900/2/28は1900/1/1から数えて59日目ということになります。

ここまでは普通の話なのですが、問題は6行目にある1900/2/29です。

理屈は一旦横において、実際には1900/2/29という日は存在しません(でした)ので、本来は1900/3/1が60日目にならないと不味いのですが、1900/2/29が60日目となったことにより、1900/3/1以降が1日ずつズレてしまっている事象、これがExcelの1900/2/29問題です。

うるう年の計算方法

うるう年には2/29が存在しますが、多くの方は4年に1回開催される夏季オリンピックの年がうるう年だと記憶していると思います。 実生活において問題ないので私もその一人です。

ただし、実際には上記の理解には2つの例外があります。

1つ目は、西暦を100で割って割り切れる年にはうるう年は存在しないというルールです。 このルールによって、1900年には2/29が存在しないことになるのです。

ちょっと待って、前回の西暦2000年にはうるう年があったよ!?って方、とても鋭いです。

これが2つ目の例外で、西暦を400で割って割り切れる年にはうるう年が存在するという、今この世に生きている我々はこの先誰も経験することのできない超例外ルールが適用されたのが、前回の西暦2000年だったのです。

1900/2/29問題はバグではないのか?

話を元に戻しますが、この問題のことをExcelのバグだと言う方がいるのですが、Microsoftはこれを「仕様」と明言しています。

例えば、Microsoftの公式サポートサイトでは次のような記述を見つけることができます。

Excel では、日付/時刻を内部でシリアル値として処理しています。Excel は他の表計算ソフトで使用される日付システムとの互換性を保つため、1900 年を閏年と解釈し、1900/2/29 が存在するように設計されています。Excel が外部データの取り込みを行う際には、1900/2/29 までのシリアル値が Excel の内部処理により自動的に修正されます。

https://support.microsoft.com/ja-jp/help/967188

ここでいう「他の表計算ソフト」というのは、Microsoft Excel以前に表計算ソフトの分野のデファクトスタンダードの地位にあった「Lotus 1-2-3」のことを指すと言われています。

Lotus 1-2-3のことはもう気にしなくていいんじゃないの?

Windows 95が発売され、一般家庭にパソコンが普及した頃は、Lotus 1-2-3がプリインストールされているパソコンが多かった記憶がありますが、2017年の現在において、少なくとも私の周りにおいてLotus 1-2-3を使っている人は、噂含めて皆無です。 そもそものロータス社自身もIBMに買収されてしまい、ブランドも再編されてしまいました。

Microsoftが未だにLotus 1-2-3自体を意識しているとは考えにくいですが、Lotus 1-2-3と互換性があることを前提に作られた当時のExcel資産は、まだ現役だったりすることもあるのかも知れません。

そういった、これまで生き残ってきたレガシーExcelともなると、もはや中身を理解してお守りをできる人がいないことが多く、解読できないことが更に寿命を延ばす理由になっていたりします。

私見ですが、MicrosoftはLotus 1-2-3との互換性ではなく、旧バージョンのExcelとの互換性を維持することを意識して、この仕様を残しているのだと思います。

結局1900/2/29が存在すると何が困るの?

「仮に1900/2/29が存在したところで、今更困ることはないだろう」 そんな声が聞こえてくるのはごもっともですが、実は私が1900/2/29問題を認知したのは、その「困ったこと」が起きたことがきっかけでした。

そのとき問題が起きていなければ、私も1900/2/29問題なんてものに関心を示すこともなかったと思います。

ExcelとVBA(いわゆるマクロ)で扱いが違う!!

下の画面キャプチャを見てください。先ほどのExcelの日付と同じ日付をメッセージボックスに表示するサンプルです。 (VBAは”#”で囲むと日付形式であることを意味します。)

f:id:boost-up:20171215202739p:plain

赤字になっている箇所がVBAの構文エラーです。 Excelでは有効である1900/2/29がエラーになっているのがお判りでしょうか。 もう一つ、Excelで無効である1899/12/31が有効な日付と解釈されていることもお気付きでしょうか。

この挙動のせいで、VBAで組んだプログラムが予期せぬ動作をしたのです。

Microsoft様、VBAはMicrosoft社謹製のプログラム言語であり、Lotus 1-2-3とは無関係のはずですが、これも「仕様」でしょうか?

おまけ

Excelのオプションを見ると、ブックの計算を「1904年から計算する」というオプションがあります。 f:id:boost-up:20171215203633p:plain

これにチェックを付すと、1900/1/1が1ではなく、1904/1/1が1となるのですが、 不用意にチェックしてしまうと、Excelに入力した日付形式のセルが軒並み4年程ズレるという多大なる影響が生じます。

今のところ、このオプションが必要になるシーンが想像できませんが、 どなたかご存知でしたら教えてくださいませ。

はてなブログを始めてちょうど1ヶ月目のアクセス数を公表します

f:id:boost-up:20171214202431j:plain

今日で、はてなブログを始めてからちょうど1ヶ月になりました。

世の中には始めて1ヶ月で数万PVという方もいるようですが、現実はそんなに甘くないことを実感しています。

幸い私は、プロブロガーの皆さんのようにブログを中心に食べていこうと思ってはいませんし、扱っている話題が万人ウケするものでもなければ商売っ気を出しにくい内容であることを十分自覚していますので今のところはネガティブな感情は全くありません。

むしろ、力を込めた26の記事を投稿することができ、1か月継続できたことに対する満足感と今後への期待感の方が高まっています。 boost-upの記事は話題性のあるものではないので、書いた記事は比較的長期に渡り価値のあるものだと信じています。

今後アクセスが増えてきたとしても、世の物品・サービス紹介サイトのような収益率は見込めないとは思いますが、活動を継続していくためにも、一刻も早く、はてなブログProのコストをペイ出来るようにはなりたいですね。

どれくらいのアクセスがあったか?

この記事を書くにあたり、いくつかの同種の記事を拝見しましたが、どうやらboost-upは群を抜いて少ないようです(笑)

では、発表します! f:id:boost-up:20171216170121p:plain 1ヵ月で40ユーザ、378PVという驚愕の数字を叩き出してしまいました。 しかもこのアクセスの中には私自身がページを確認するためにアクセスした分が含まれますので、実際のアクセスはもっと少ないはずです。

それでもここ数日、ようやくサーチエンジン経由の流入がコンスタントに発生し始めたので、今後の大きな飛躍を期待したいと思います。

この1か月で最もアクセスのあった記事はこちらです。 blog.boost-up.net blog.boost-up.net 同じ15PV(少なっ!!)で同率首位でしたが、『監査法人の「業務及び財産の状況に関する説明書類」とその「公衆縦覧」について』の方が10日程後に投稿した記事ですので、事実上の一位は前者ですね。

石の上にも3年と言いますが、次は3ヶ月目の状況をご報告したいと思います。

同じような状況で挫けそうになっている方、諦めずに継続しましょう!!

RailsアプリをLet's Encryptで常時SSL化する方法

f:id:boost-up:20171214003033j:plain

常時SSLはもはや現代の常識!?

今を遡ること3年前、2014年のことになりますが、GoogleがSSL化されたサイトをサーチエンジンがポジティブに評価することを発表して以来、新しくWebサービスを作る場合にはSSL化することが必須タスクの一つになってきました。

私が運営するWebサービスでは、今年2017年に立ち上げたSCDB JAPANはサービス開始当時から常時SSL化の対応を行っていますが、2014年から運営している上場企業サーチ.comはユーザが情報を登録する機能を実装していないこともあり、これまでSSL対応が出来ていませんでした。

Let's Encryptの登場

従来、WebサイトのSSL化を実現するためには、認証局に対してお金を払ってサーバ証明書を発行してもらう必要がありました。 このコストは最も安いものでも年間数千円必要であり、個人が格安のレンタルサーバで運営しているような小規模なWebサイトでは無視できないケースもあったのではないかと思います。 また、証明書の発行を申請するためには、サーバにOSログインして証明書署名要求(CSR( Certificate Signing Request ))を作成する必要があり、若干のハードルがありますので、対応できずにいたWebサイト運営者もいたのではないかと思います。

そんな中、2016年に登場したLet's Encryptは通信の暗号化に特化した無料のSSL証明書発行サービスです。

ドメインを認証するDV認証にしか対応しておらず、発行される証明書の有効期限が3ヶ月と短く定期的に更新手続きが必要にはなるものの、サーバのルート権限を持っている管理者であれば簡単な操作で署名済みの秘密鍵(KEY)と公開鍵(CRT)を入手することができます。

今回、上場企業サーチ.comに導入しましたので、以下ではその手順を紹介します。 OSはCentOS7.3になります。

Let's Encryptのインストール

1.epelリポジトリを有効にしてcertbotをインストールします。

sudo yum install epel-release
sudo yum install certbot

2.certbotのコマンドを実行してサーバ証明書を作成する

path-to-rootにはRailsアプリのルートディレクトリを指定します。

certbot certonly --webroot -w path-to-root -d xn--vckya7nx51ik9ay55a3l3a.com

私は上記のコマンドを実行したところ、次のエラーが発生しました。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. xn--vckya7nx51ik9ay55a3l3a.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ [210.140.40.129]: 404

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: xn--vckya7nx51ik9ay55a3l3a.com
   Type:   unauthorized
   Detail: Invalid response from
   http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ
   [210.140.40.129]: 404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

エラーメッセージを見る限り、サーバ直下に作成される.well-knownディレクトリにインターネットからアクセスしようとして404エラーが出たことが問題のようです。 Let's EncryptはSSL化しようとしているサーバに作ったファイルに外部からアクセスできることをもって、実在性の確認を行っているようです。

3..well-knownへのアクセスを許可する

上場企業サーチ.comはRailsで構築しており、publicフォルダ内に置いた静的ファイル以外はunicornに渡す設定にしているのですが、 .well-knownはpublic外にあり、当然ながらルーティングも設定されていないため、設定上正しい動きとして404になります。

今回、WebサーバにはH2Oを使っていますので、h2o.confに下記の末尾2行を追加してサービスを再起動します。

  "xn--vckya7nx51ik9ay55a3l3a.com:80":
    listen:
      port: 80
      host: 0.0.0.0
    paths:
      "/.well-known":
        file.dir: path-to-root/.well-known/

4.改めて、certbotのコマンドを実行してサーバ証明書を作成する

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/privkey.pem
   Your cert will expire on 2018-03-12. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

今度は上手くいきました。 fullchain.pemが公開鍵、privkey.pemが秘密鍵になりますので、適切な場所に保管します。

5.h2o.confにSSL接続の設定を追加する

  "xn--vckya7nx51ik9ay55a3l3a.com:443":
    listen:
      port: 443
      host: 0.0.0.0
      ssl:
        certificate-file: "path-to-fullchain.pem"
        key-file: "path-to-privkey.pem"
        cipher-suite: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        cipher-preference: server

ポート443の設定を追加します。 certificate-filekey-fileには先ほど作成した公開鍵と秘密鍵のパスを指定します。 cipher-suitecipher-preferenceはなくても動きますが、脆弱な暗号方式を使わないようにするための設定です。

設定後、h2oサービスを再起動するとSSL通信が可能となります。

6.その他

今回は詳しくは触れませんが、上記まででSSL接続ができないときは、ファイヤーウォールでインバウンド443が空いているかを確認してください。 それから、80ポート(HTTP)へのアクセスを443ポートにリダイレクトしておいた方が良いと思いますので、適宜この設定も追加してください。

7.おまけ

昔から慣れているので今でもSSLと言ってしまいますが、暗号化方式としてSSLは既に時代遅れと言われており、世の中的にはTLS通信に移行が進んでいます。

上で書いた5.のcipher-suiteのところで、頭に"!"が付いているのはそのアルゴリズムを「許可しない」ことを意味するのですが、今回の設定ではSSLを軒並み拒否しています。

冒頭で「常時SSLは世の中の常識!?」とまで書きましたが、正しくは「常時TLSは世の中の常識!?」ですね。

bootstrapを使ったモバイル画面で幅が100%にならずに「ぐらぐら」する件

bootstrapを使ってコーディングしたページをモバイルで表示したとき、横幅がきっかり100%にならずに「ぐらぐら」する場合があります。

↓ちょっとわかりにくいですが、こういうやつです。

f:id:boost-up:20171212220135p:plainf:id:boost-up:20171212220121j:plain
スワイプするとぐらぐるするWebページのスクリーンショット

SCDB JAPANでも以前から発生していることを認識はしていながら、これまで放置しておりましたが、 ようやく対応が完了しましたので対応方法を共有します。

ぐらぐらの原因は何だったのか?

グリッドシステムのrowにはマイナスのmargin(ネガティブマージン)が設定されており、これが要素を左右に引っ張っているために親要素を突き破っていたことが原因でした。

修正前の状況

横幅320pxの画面で表示した場合の状況なのですが、親要素が307.2pxなのに対して、子要素で左右-15ずつのmarginが取られたことによりコンテンツが307.2px+15px+15px=337.2pxとなり、画面サイズの320pxをオーバーしてしまっています。

【親要素】 f:id:boost-up:20171212221929p:plain

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222200p:plain

修正内容

親要素のpaddingに左右それぞれ+15pxを取り、子要素のネガティブマージンと相殺しました。

.parent-element{
  padding-left: 15px;
  padding-right: 15px;
}

【親要素】 f:id:boost-up:20171212222806p:plain 左右にpaddingを取ったため、コンテンツの幅が同じだけ狭くなりました。

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222830p:plain ネガティブマージン自体はそのままですが、親要素が狭くなったことで子要素も同じだけ狭くなっており、320px以内に収まるようになりました。

<経過観察中>RapidSSLで認証したSSLサーバ証明書を使っているサーバにChromeでアクセスすると警告がでる件

f:id:boost-up:20171211234910j:plain

既に数か月前から騒がれている話ですが、GoogleがSymantec系のサーバ証明書に対する信頼を落としており、Thawte、VeriSign、Equifax、GeoTrust、RapidSSLといったSymantec系のサーバ証明書を使っているサーバは証明書の再発行、再署名といった対応が求められる可能性が高い状況です。 forest.watch.impress.co.jp

SCDB JAPANはRapidSSLを使っており、今日現在ChromeでアクセスするとConsoleに以下のような警告が表示される状況です。 (この情報は、モダンブラウザを数クリックすれば誰でも確認できるので隠す程のことではありません。)

f:id:boost-up:20171211230802p:plain

RapidSSLのWebサイトの情報

www.rapid-ssl.jp

RapidSSLのサイトによるとサーバ証明書の「発行日」と「有効期限」の組み合わせによって、必要な対応が変わってくるそうです。

対象・対応と日程:

1.2016年6月1日より前に発行された証明書(Google Chrome66よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年3月14日以前:対応不要
② 有効期限が2018年3月15日以降:2018年1月~3月までに再発行

2.2016年6月1日より後且つ2017年12月より前に発行された証明書(Google Chrome70よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年9月12日以前:対応不要
② 有効期限が2018年9月13日以降:2018年1月~9月までに再発行

scdb.jpのサーバ証明書は次の通り、発行日が2017/2/25、有効期限が2020/2/26ですので、上記の2-②のパターンに該当します。

f:id:boost-up:20171211232305p:plain

来年まで悠長なことを言わずに今すぐ再発行できないのかと考え、契約したRapidSSLの販売代理店に問い合わせたところ「来年2月頃に再発行をご案内します」との回答。

仕方がないのでとりあえず忘れないようにここに備忘を残し、時が来るのを待つことにしたいと思います。

余談

SSL化の目的は主に、通信経路を暗号化することと、運営者に対する第三者証明の2つがあります(それ以外にも、SEOの観点でも加点要素と言われています)。 後者については、ドメイン認証、企業認証、EV認証という三段階の認証基準があり、どれを採用するかでコストも認証の難易度もかなり変わってくるのですが、実は暗号化レベルは基本的に一緒です。

私は今のところはドメイン認証ができれば十分なので、コスト的に最もお手軽なRapidSSLを使っているのですが、それでもこれまでは少なからず対価を支払う必要がありました。

ところが最近は、3ヵ月毎の更新が必要ではあるものの、Let's Encryptという無料サービスが普及してきています。 私が管理する別のサーバでも使っていますが、インターネット側のサーバもイントラネット内のサーバも問題もなく動作しています。

通信経路の暗号化を目的にドメイン認証が出来れば良いというのであれば、Let's Encryptでも十分なのかも知れません。

14%の上場企業が連結納税制度を採用していた件

f:id:boost-up:20171211234614j:plain

連結納税制度とは

連結納税は「法人税」を対象とした税制で、2以上の法人を1つの法人とみなして課税所得を計算する仕組みで、日本では平成14年4月から施行されています。

この連結納税は親会社の黒字と子会社の赤字を通算することにより、法人全体の法人税負担を軽くできるなど、基本的には法人税額を減らすための仕組みなのですが、以前は連結納税制度を採用する時点で連結子法人が持っていた繰越欠損金が切り捨てられるルールだったことから、繰越欠損金を抱える子会社を有する親会社にとっては採用に踏み切りづらい側面もありました。

その後、平成22年の税制改正により、みなし連結欠損金の範囲が拡大されたことなどをきっかけに、次第に連結納税制度を採用する企業が増える傾向にあったと思います。

ただ、これまでは漠然と「あ、この会社も連結納税始めたんだ」くらいの感覚的なものでしかなかったので、今回改めて、上場企業の中で連結納税制度を採用している会社がどれくらいあるのかを調べてみました。

2017年12月時点で上場企業約3,700社中、約520社が連結納税制度を採用(一部直近まで採用していた企業を含む)

以前、消費税の税込処理を行っている上場企業を調べたときと同じ方法で、上場企業サーチのデータベースから、2017年12月11日時点で各社が開示している最新の有価証券報告書の情報を使い、連結納税制度を採用している会社数を調べました。

以下は、「重要な会計方針」に「連結納税」という単語を含む数を上場市場と業種でクロス集計したものです。

f:id:boost-up:20171211223554p:plain

単純合計では523社ありますが、個別に調べたところ、極少数ですが「今期から連結納税制度の適用を取りやめた」会社も含まれていました。

例えば、名証二部の1件というのは「ニッコー株式会社」なのですが、この会社は今期途中に吸収合併を行った結果、連結完全支配関係を有する国内連結子会社が存在しなくなったという理由で連結納税の適用を取りやめています。

今回は1件単位で正確な数字を拾うことが目的ではありませんので、約520社ということで整理させて頂きますのでご了承ください。

日本には約3,700社の上場企業がありますので、約520社というのは約14%となります。

この数字を多いと思うか、少ないと思うかは人それぞれだと思いますが、私としては「かなり増えた」という印象を受けました。

また、パッと目につくところでは5大商社はいずれも連結納税制度を採用していますし、トヨタ、本田、日産、マツダ、スズキなどの自動車大手、パナソニック、シャープ、富士通、三菱電機、日本電気、東芝などの電機大手なども名を連ねています。

感覚的となりますが、多数の連結子会社を抱える商社、製造業に連結納税が浸透しているということは、かなりの数の会社が連結子法人として連結納税制度に参加していると言えると思います。

また、興味が向いたときにもう少し分析してみたいとは思いますが、個人的には欲求が満たされたのでこのくらいにしておきたいと思います。

2017年12月時点で連結納税制度を採用している(いた)上場企業の一覧

今回の集計で作った一覧を下のリンクからダウンロードすることができますので、興味がある方はご利用ください。

ただし、正確性など品質は一切保証できませんので自己責任の下で利用いただくようお願いします。

https://blog-contents.ds.jp-east.idcfcloud.com/2017年12月時点で連結納税制度を採用している(いた)上場企業の一覧.xlsx

上場企業で消費税を税込経理している会社が3社存在した件

f:id:boost-up:20171208202121j:plain

税込経理と税抜経理

企業会計では消費税の会計処理として税込処理と税抜処理の2つの方法が認められています。

税込経理とは取引の本体価格と消費税を一体として処理する方法であり、 税抜経理とは取引の本体価格と消費税を区別して処理する方法です。

例えば、本体価格1万円の商品を販売した場合、税率を現在の8%とすると、それぞれの方式における仕訳は次のようになります。

  • 税込経理の場合
売掛金 10,800 / 売上 10,800
  • 税抜経理の場合
売掛金 10,800 / 売上 10,000
        / 仮受消費税 800

仕訳だけを見れば、税込経理の方が単純で楽そうですが、 税務上、会計上様々な理由から、特に規模の大きい企業では税抜経理が常識と言われています。

その理由は今回の本旨ではありませんのでまたの機会にするとして、 ふと、「常識」が正しいのかどうか気になりましたので調べてみることにしました。

データソースは上場企業サーチ.comで集めている上場企業各社の有価証券報告書になります。

対象とした有価証券報告書

本日2017年12月8日現在、上場企業各社がEdinetを通じて開示している最新の「有価証券報告書」を対象にしました。 対象の各有価証券報告書において、個別財務諸表の注記事項として記載されている「消費税等の会計処理」を全件調査しました。

開示されるのは上場企業本体の消費税処理方式ですので、 グループ会社などの消費税処理方式は親会社と異なる可能性もあります。

上場企業で税込経理を採用しているのはわずか3社!!!

もしかしたら1社も該当がないのではないかとの不安と期待を旨に結果を取り出してみたところ、 たった3社だけ、税込経理を採用している上場企業がありました。

眼科薬の開発を行う創薬会社の持株会社

家賃保証業務を行っている会社

不動産担保ローン業務を行っている会社

上場企業で税込経理を採用する会社があったことは正直意外でしたが、 よくよく見てみると、窪田製薬ホールディングスは上場会社単体では売上高がゼロという極めて珍しい状況ですし、 あんしん保証とアサックスの2社もそれぞれ家賃保証、不動産担保ローンを業としており、非課税取引が本業の会社ということで、 やはりそれぞれ一定の事情はあるようです。 (後の2社については、非課税取引が本業の会社で税抜経理を採用している会社も多数ありますので、単に業種だけの問題だけの問題ではないとは思います。)

ということで、上場企業は税抜処理という「常識」は一応確信に変わりました。