通達99号時代のホテルチェーン会計：一つのシステムで複数施設を

第1部：単独ホテルよりチェーン会計が難しい理由

違いは伝票の量ではありません。5施設のチェーンは、単に1ホテルを5倍したものではなく、各施設が固有の業務内容を持ちながら、全体で一つの財務像にまとめ上げなければならない構造です。

複雑さを生む4つの要因

• 売上が複数の場所で、それぞれ異なる形で発生する。都市型施設は主に客室料金とレストラン1店舗ですが、リゾートにはメインレストラン、プールバー、温浴施設、ツアーデスク、宴会サービスがあります。同じチェーンでも売上構成はまったく異なります。
• 科目体系が統一されていない。各施設が慣習に従って独自に科目名を付けるため、連結の段になると合算できません。ある施設の「その他サービス」と別の施設の「その他サービス」が同じ中身ではないからです。
• 施設間の内部取引。物品の移動、人員の共有、ある施設が別の施設に代わって予約を受けるといったものです。これらを識別できなければ、全体像に二重計上されます。
• 2種類のレポートを同時に。経営陣は各部門の業績を評価するために部門別レポートを必要とし、監督官庁や銀行は会計制度に準拠した財務諸表を必要とします。両者は互いの代わりにはならず、どちらかを手作業で作るのは良くない選択です。

チェーン規模のホテル管理システムが運用領域だけで完結できないのはこのためです。フロントと客室管理には強くても会計帳簿への経路を持たないシステムは、その作業量をすべて集計表という形で経理部門に押し付けます。そして集計表は結局、入力し直さなければなりません。

第2部：複数施設を持つ企業にとっての通達99号

通達99/2025/TT-BTCは通達200/2014/TT-BTCに代わる企業会計制度で、2026年1月1日から適用されます。以下の3点はチェーンが準備すべき事項であり、いずれも施設数が増えるほど負担が重くなります。

全施設で同時に行うべき3つの作業

• 勘定科目体系の更新。一部の勘定科目は名称変更、配列の見直し、または反映内容の調整が行われます。例えば勘定112は現在要求払預金という名称です。チェーンではこれを統一して行う必要があり、各施設が独自の解釈で更新すれば次期の連結が破綻します。
• 新勘定科目体系への残高移行。一度きりの作業ですが、会計年度全体に影響します。複数施設では、共通の基準日、相互確認に責任を持つ担当者、そして説明のために保管する移行前後の対照表が必要です。
• ツールの更新が間に合っていることの確認。会計ソフトが期限までに新勘定科目体系に対応していなければ、残る選択肢は複数施設で同時に手作業を行うことです。しかもそれは会計年度の初め、経理部門全体が最も多忙な時期に当たります。

3点目について、当社の現状を明確に述べます。ホテル会計ソフトDiACCは通達99号に基づく勘定科目体系の更新を完了しており、4〜5つ星のホテルおよびチェーンで実際に稼働しています。これは製品の状態についての情報であって、約束ではありません。残高移行と点検は依然として経理部門の専門業務であり、ツールが支援はしても代行するものではありません。

第3部：複数施設で共有する一つの勘定科目体系

チェーン会計の土台は、ポートフォリオ全体で共有する単一の科目体系と、それを施設ごとに分解するための分析軸です。逆のやり方、つまり施設ごとに体系を持ち期末に相互対応づけをするのは、恒久的な手作業を生み出す方法です。

最低限必要な4つの軸

• 施設軸。各ホテル、各リゾートが一つのコードです。レポートを分ける軸であると同時に、連結を行う軸でもあります。
• 部門軸。客室、料飲、ウェルネス、宴会・イベント、管理部門。管理会計レポートと各部門の業績評価のための軸です。
• アウトレット軸。一つの部門の中に複数のアウトレットが存在しえます。メインレストランとビーチレストランはいずれも料飲部門ですが、個別に測定する必要があります。ルームチャージ計上と複数アウトレット管理の記事で詳しく述べたとおりです。
• 売上区分軸。宿泊、料理、酒類、サービス、物販、第三者預り金。税務および請求の要件に対応する軸であり、上記3軸から独立していなければなりません。ビーチレストランで販売した1本のワインは、4つの軸すべてに同時に属します。

科目体系を崩さないための3原則

• 科目体系の管理は一箇所で。施設が申請し、グループ経理が承認してコードを開設します。各施設が自由にコードを開設すれば、2年で同じ内容の別名コードが複数存在する体系になります。
• レポート階層に「その他」科目を作らない。必要なら新しいコードを開設し、仮置きの受け皿に押し込まないことです。「その他」に入った情報は二度と出てきません。
• 使用中のコードの意味は変えない。変更したい場合は新しいコードを開設し、旧コードを閉じます。そうすれば過去データと現在の比較が可能なまま保たれます。

第4部：管理システムから会計帳簿へ流れる売上

ここが核心であり、統合されたプラットフォームとばらばらのツールの集合との本当の違いが現れる箇所です。チェーンでは複数のアウトレットで毎日数千行が発生します。問うべきは「入力できるかどうか」ではなく、「各行がどの経路で会計帳簿に届き、遡って追跡できるかどうか」です。

3段階の連携レベル、実用に足るのは一つだけ

• 低水準——日次の集計表。一日の終わりに運用側が表を1枚出力し、経理が帳簿に入力します。一見すっきりしていますが、遡及追跡の可能性はすべて失われます。差異が出たとき、どの宿泊日やどのサービス伝票までも遡れません。
• 中水準——明細ファイルの定期取込。明細は増えますが、依然として遅延があり、間に人の作業が残ります。つまり誤りと漏れの余地が残ったままです。
• 実用水準——取引単位でデータが直接流れ、遡及参照を持つ。発生した各項目が施設、部門、アウトレット、売上区分、会計日、原始証憑番号を伴います。経理は入力し直しません。経理部門の仕事はデータ入力から点検と分析へ移ります。まさに価値を生む場所です。

実用水準が機能するための条件

• すべてのアウトレットが同一プラットフォーム上にあるか、取引単位でプラットフォームに接続していること。DiHotel Solutionsのエコシステムでは、料飲領域はDiPOSモジュール、温浴施設はDiONSENモジュール、購買と在庫はDiPOモジュールが担当し、いずれも同一の客室フォリオと同一の科目体系を参照します。
• 会計日が統一して定義されていること。時計ではなくナイトオーディットの締め処理を基準とします。この論点は重要度が高く、次の一節すべてを充てています。
• 両端の自動照合の仕組みがあること。運用側の発生総額と帳簿の計上総額が、施設ごとに毎日一致していなければなりません。差異は四半期末ではなく翌朝に表面化する必要があります。

チェーンが独立したホテル会計ソフトを使用しており、それを維持したい場合、契約に盛り込むべき最低条件は、データが遡及参照付きで取引単位ごとに連携されることです。あわせて、両端の数値が食い違った際にどちらが責任を負うかを明記する条項も必要です。日次の合計値だけを同期するのは一見すっきりしていますが、説明を求められたときに必要となるまさにその情報を捨てています。

第5部：帳簿計上時に誤りやすい宿泊業特有の4つの取引

以下の4つは宿泊業に固有の取引です。経理がずさんだから誤るのではありません。発生時点と入金時点が異なるために誤るのであり、その差は施設数に比例して拡大します。

注意深さではなく設計で解決すべき4箇所

• 1. ナイトオーディットと日付の境界。ホテルの営業日は深夜0時ではなくナイトオーディットの締め処理で終わります。0時30分のチェックイン、午前1時のワイン1本の販売——それぞれどの会計日に属するかは締めの基準時刻が決めます。チェーンにおいて、各施設が異なる時刻で締めているのに連結レポートが暦日で合算していれば、ポートフォリオ全体の数値は追跡困難な形でずれます。
• 2. 仲介チャネル、旅行会社との契約、交渉料金。オンラインチャネル経由の販売ではチャネル側が手数料を留保し、旅行会社経由では交渉料金と期末後回収の売掛金が生じます。実際に受け取った金額で売上を計上すれば売上は過少計上となり、販売費が消えてしまいます。同時にチャネル別の効率比較もできなくなります。
• 3. 前受収益。客室予約の手付金、前払パッケージ、サービスバウチャー、宴会の予約金。入金済みでもサービスは未提供です。これは顧客に対する義務であり、まだ経営成績ではありません。季節性が明確なチェーンでは、翌年の年始休暇シーズンに向けて年末に積み上がる前受額は、誤って計上すれば両期の姿を完全に歪めるほど大きくなります。
• 4. ルームチャージ計上と内部勘定。売上はサービス提供日に属し、現金はチェックアウト日に属します。あわせて、どの宿泊客にも属さない項目——取引先の接待、社内での試用、苦情対応の補填——には専用の計上先と承認者が不可欠です。そうでなければ売上に紛れ込み、数値そのものも説明可能性も損なわれます。

第6部：施設別レポートを保ちながら数値を連結する

チェーンには2つの姿が同時に必要であり、その2つは異なる相手のためのものです。重要なのは、両者が同一のデータソースから生成されることであって、2人が2通りのやり方で作った2枚の表ではないことです。

2つのレポート軸、1つのデータソース

• 会計制度に基づく財務諸表。法人単位で、通達99号の勘定科目体系に従って作成し、報告義務および銀行・監査法人・監督官庁との対応に用います。
• 部門別の管理会計レポート。売上と費用を施設別、部門別、アウトレット別に分解し、経営陣が各部門の業績を評価できるようにします。USALI基準のホテルP&Lの記事で詳しく述べた構造です。この2つの基準は矛盾しません。一方は外部への提示方法であり、他方は内部のための視点です。

連結の品質を決める3つの技術的要件

• 内部取引の識別と消去。施設間の物品移動、ある施設が別の施設に提供したサービス——これらは発生した時点で印を付ける必要があり、期末に探し回るものではありません。
• 締め時期の統一。各施設は同じ基準で締めなければなりません。1施設が遅れれば連結レポート全体をやり直すことになります。
• 指標の定義書を1つだけ維持する。純売上に何を含めるか、稼働率からどの客室を除くか、サービス売上に第三者預り金を含めるか。一度決めて文書化し、年度途中で変えないことです。そうしなければ前年同期比の比較はすべて意味を失います。

第7部：統制、証跡、説明可能性

チェーン規模では、帳簿の品質は数字の見栄えではなく、監査法人や銀行、税務当局から問われたときに各行を説明できるかどうかで測られます。以下の4つの仕組みが最低要件です。

最低限必要な4つの仕組み

• すべての修正・取消操作に対する完全な証跡——誰が、いつ、どういう理由で行い、変更前後の値がどうであったか。これは企業と誠実な従業員の双方を守る仕組みです。
• 統制された期間締め。締め後の調整はすべて上書きではなく新たな仕訳とします。期間を再開する権限は特定の一人に置くべきで、利用者の既定権限にしてはいけません。
• 役割別・施設別の権限設定。施設の経理担当者は自施設のデータを、グループ部門はポートフォリオ全体を参照します。個人単位ではなく職位単位で割り当てます。
• 帳簿から原始証憑への遡及経路。帳簿上の売上1行から、客室フォリオ、アウトレットの伝票、取引時刻、入力者まで遡れなければなりません。この経路がなければ、あらゆる苦情も点検も感覚で処理することになります。

これはベンダー選定時の審査項目に加えるべき基準群でもあり、チェーンおよび4〜5つ星ホテルのためのベンダー審査の記事で挙げた項目と同じ位置づけです。チェーンに対応するAIホテル管理ソフトは、以上4つの仕組みを紹介資料の一文ではなく実データ上で実演できなければなりません。

第8部：まとめ表——どの取引が、チェーン規模でどこで誤るか

第9部：チェーンのための移行ロードマップ

以下の順序には意図があります。まず科目体系を整え、次にデータを接続し、残高移行は最後です。逆に進めれば、移行済みの部分をやり直すことになります。

5つのステップ

• ステップ1——共通科目体系の確定。ポートフォリオ全体で、一つの勘定科目体系と、施設・部門・アウトレット・売上区分の一組のコードを定めます。最も時間を要する工程であり、同時に成否を決める工程です。
• ステップ2——会計日と締め手順の標準化。同じナイトオーディットの基準時刻、同じ締めスケジュール、締め後の調整に関する同じ規程を用います。
• ステップ3——取引単位でのデータ接続。管理システムと各アウトレットから会計モジュールへ、遡及参照を伴い、両端の日次照合を備えた形で接続します。
• ステップ4——1期間の並行稼働。旧数値と新数値を照合し、差異を第8部の7分類どおりに分解します。並行稼働の原則と切り戻し方針についてはシステム移行チェックリストの記事で述べています。
• ステップ5——残高移行と新制度による最初の期間の締めを行い、施設ごとに移行前後の対照表を保管します。

この5ステップを終えたとき、チェーンが得るものは基準に適合した帳簿だけではありません。誰も表を突き合わせることなくポートフォリオ全体の月次業績を把握できる状態です。それはまさにオーナー向けレポートアプリが提供する視点でもあります。同じポートフォリオ内の小規模施設はクラウドAIホテル管理ソフトDiCloudを利用しますが、指標の定義は共通のものを使うため、2つの製品層の間で全体像が分断されることはありません。