ホテルソフトウェアの切り替え：経理責任者のための期首残高の確定

第1部：ホテルソフトウェアの切り替え——期首残高は経理責任者の机に載る

「旧帳簿を締め、新帳簿を開く」という原則を簡単に振り返ります。取引先の過去の売掛金・買掛金は締め日時点の残高として、取引先ごとに1行で、明細表と署名済みの記録を添えて移します。滞在中のゲストのフォリオ（客室の請求書）と将来の予約のデポジットは、必ず各予約に正しくひも付けて移します。旧システムで架空の客室に計上していたデポジットは、架空の客室を作り直すのではなく、会計モジュールの期首残高に入れます。

原則が正しくても、実行がまずければ失敗します。リスクは締めの夜の前後数時間に集中するため、初週から役割を割り当ててください。総支配人は締め日と差異の許容基準を承認し、経理責任者は残高の一覧を確定して確認待ち項目について判断し、フロントと出納担当は明細表を印刷して釣銭を数え、ベンダーは試験移行を実行して照合表を用意します。

第2部：締め日を選び、締めの時刻を取り決める

• 旧システムのナイトオーディット直後に締める。 この時点で当日の売上は締まり、最終夜の室料はフォリオに計上され、残高は静止したスナップショットになります。
• 旧システムを凍結する。 締めの時刻以降、予約、営業、レストランのPOSを含むすべてのアカウントから書き込み権限を外します。旧システムは閲覧専用になります。
• 締めのルールを文書にする。 締め前に証憑のある取引は旧帳簿、締め後の取引は新帳簿に属します。締め前に受け取ったものの、まだ予約と突き合わせられないお金は確認待ちのグループに入れます。
• 可能なら月次決算に近い日を選ぶ。 そうすれば、新システムの期首残高が、経理がすでに締めた期末の数字と一致しやすくなります。月末が繁忙期にあたるなら、閑散期を優先します。
• 大型団体の到着や出発がある夜は避ける。 また、締めの時刻を全部門に周知し、誰も旧システムで新たなデポジットを受け付けないようにします。

第3部：確定すべき期首残高の一覧

この表は、ホテル運営から生じる残高だけを対象にしています。預金、在庫、固定資産、税金、資本などの会計帳簿上のその他の残高は、会社の通常の期末決算の手続きで経理が移します。ギフト券や架空の客室のデポジットは、ルームマップに表示されないため忘れられがちです。顧客が支払ったもののまだ使っていない金額をすべて、フロントと営業チームに直接確認してください。

第4部：残高グループごとの3つの情報源での照合

新システムと旧システムを比べることで証明できるのは、移行が正しくコピーしたことであって、旧システムの数字が正しいことではありません。各グループには、2つのソフトウェアから独立した第3の情報源が必要です。

最初の2つの情報源は、データ移行ツールが照合表として出力します。第3の情報源は会計の専門的な作業なので、早めに始めてください。プロジェクトの2週目から、取引先に残高確認書を送ります。

第5部：差異の処理——基準は差異を目にしてからではなく、事前に決める

ホテルは、一致しない行を目にしてからではなく、最初の試験運用の前に、自ら基準を書面で定めるべきです。お金のグループについては、原則として、どれほど小さくても説明のつかない差異は認めません。顧客プロフィールのような件数ベースのグループについては、理由があれば差異は許容されます。たとえば、重複していたプロフィールを統合した場合です。

• タイミングによる差異：締め後に受け取ったお金、または旧システムには計上済みだが銀行への入金がまだのお金。締めのルールに従って処理します。
• 旧データに由来する差異：長年積み重なった誤り。締め前に修正するか、確認待ちのグループに入れるかを経理責任者が判断します。
• 説明のつかない差異：新システムには計上しません。「確認待ち項目」のグループに、項目ごとに理由を付けて1行ずつ入れ、計上する前にホテルが書面で判断します。

第6部：残高確定記録——内容、明細表、署名者

• 締めの日付と時刻、および旧システムが閲覧専用になった時刻。
• 総括表：売掛金、買掛金、滞在中のゲストのフォリオ、将来の予約のデポジット、架空の客室から移したデポジット、確認待ち項目。各行に旧システムの残高、新システムの残高、差異を示します。
• 添付する2つの明細表：取引先別の残高、移行したデポジットと確認待ち項目。明細表の合計は記録と一致させ、全ページに略式署名をします。
• 締め日以降の処理：旧債権の入金は期首残高を減らします。後から見つかった差異は補足記録で対応します。

署名者は、締めの夜の後、新システムでの最初のシフトが始まる前に、ホテルの代表者、経理責任者、ソフトウェアベンダーの代表者です。釣銭は別の現金実査記録で、前払いバウチャーとギフト券は券番号別の明細表で確定し、同じ書類一式に保管します。

第7部：期首残高をDiACCに入力する

DiHotelでは、会計モジュールDiACCが通達99/2025/TT-BTCに基づいて稼働し、ホテル管理側から自動で仕訳します。フロント、レストラン、各種サービスの売上がそのまま帳簿に流れ込みます。帳簿を開くときは、フォリオとデポジットはホテル管理システム内で各予約にひも付けて置きます。取引先の売掛金・買掛金は期首残高としてDiACCに入れ、取引先一覧は過去の債権債務を含めずに別途移します。架空の客室のデポジットは、DiACCの貸方に独立した取引先で入れます。旧システムに会計モジュールがなかった場合は、ホテルの経理担当者が署名済みの記録に従って残高を入力します。

入力後は、開始日時点の売掛金台帳と試算表を印刷し、取引先の売掛金・買掛金の行と移行したデポジットを署名済みの記録と照合します。予約にひも付いたフォリオとデポジットについては、ホテル管理システムを締め時に印刷した明細表と照合します。本稿では項目を運営上の名称で記述しています。経理責任者は、正しい勘定科目を選ぶために、自社が適用している会計制度を確認してください。チェーンの勘定科目体系の組み立て方は通達99号に対応したホテルチェーンの会計の記事で、モジュールの紹介はホテル会計ソフトウェアDiACCのページで扱っています。

第8部：多施設チェーン——施設ごとに確定し、それから統合する

各施設に、それぞれの締め日、照合表、署名済みの記録があります。データが整っている施設から始めて、1施設ずつ切り替えます。チェーン全体に送客する旅行会社のような共通の取引先については、施設ごとに残高を確定します。施設間の取引がある場合は、統合時に二重計上されないよう、双方の記録に注記します。

試算表などの会計報告書の統合は、施設が1つのDiACCを共有し、各施設を下位単位として設定し、印刷時に複数の単位または「すべて」を選べば、現在DiACCで行えます。各施設がそれぞれ別のDiACCを使う場合は自動統合されないため、最初の施設の締め日より前に下位単位の構成を決めておく必要があります。オーナー側では、DiOwnerが、運営システムと一致する数字で、ポートフォリオ全体を1つの閲覧専用のマルチプロパティ ホテル管理ソフトウェアに表示します。

第9部：監査人と検査のための書類保管

監査人や検査チームから、なぜ期首残高がその数字なのかを問われることがあります。答えは1つの書類一式にあります。文書化した締めのルール、略式署名付きの明細表を添えた署名済みの記録、各回の照合表、締め日時点の残高確認書、現金実査記録、銀行取引明細、各確認待ち項目についての判断、そして締めの時刻に旧システムから印刷した報告書です。

旧システムは3〜6か月間閲覧専用で残します。停止する前に、最終バックアップを旧サーバーとは別の場所に保存し、書類一式を会計書類の法定保存期間にわたって保管します。旧サーバーのサポート終了が近いなら、停止日はサーバーのサポート終了の記事のスケジュールと並べて設定してください。

第10部：データ移行ツールと「0円乗り換え」パッケージ

旧世代のオンプレミス型システムからDiHotelへのホテルソフトウェアのデータ移行ツールは、すでに実運用されています。データベースのコピーを読み込み、稼働中のシステムに書き込まずに試験運用し、グループごと（売掛金・買掛金の残高、滞在中のゲストのフォリオ、将来の予約のデポジット、顧客プロフィール、マスターデータ）に照合し、書き込み前に自動でバックアップを取り、ロールバックの地点を持ち、重複させずに再実行でき、残高確定記録のひな形も付いています。ある施設での1回の実行では、6万件を超える顧客プロフィールと5,000件を超える予約を、15分未満のマシン稼働時間で処理し、100%一致、ロールバックも可能でした。これは1回の実行結果であり約束ではありません。プロジェクト全体では規模に応じて通常2〜3週間かかります。オンプレミスとクラウドのどちらで運用すべきかは、オフラインかクラウドか：ホテル管理ソフトウェアの記事をご覧ください。

客室数50室以上のホテル、または2施設以上のチェーンで、旧世代のオンプレミス型システムを使っており、2027年6月30日までに契約を締結する場合は、「0円乗り換え」パッケージの対象となります。経理責任者にとって、5つのお約束は次の意味を持ちます。データ移行は無料で、事前に読める照合表付き。旧システムは3〜6か月間閲覧専用で開いたまま。旧契約の残存期間（最大6か月）はDiHotelの期間に上乗せされ、2社に同時に料金を払うことはありません。本稼働日の前に双方が署名する残高確定記録。各部門へのトレーニング（資料と録画付き）。利用料は旧システムの保守料を上回りません。DiHotelは値引きはしませんが、その分を移行リスクの解消に充てます。

ホテルがソフトウェアを切り替えるとき、期首残高にはどの項目が含まれますか？

ホテル運営から生じる残高には、通常、企業・旅行会社・オンライン販売チャネルに対する売掛金、仕入先に対する買掛金、将来の予約のデポジット、滞在中のゲストのフォリオ（客室の請求書）、フロントの釣銭、前払いバウチャーと未使用のギフト券、そして旧システムで架空の客室に計上していたデポジットが含まれます。預金、在庫、固定資産、税金、資本などのその他の残高は、会社の通常の期末決算の手続きで移します。

何年分もの売掛金の明細を新しいソフトウェアに移す必要がありますか？

いいえ。取引先ごとに締め日時点の1行の残高として移し、明細表と双方署名の記録を添えます。過去の年の明細は、閲覧専用モードの旧システムで照会します。

どの程度の差異なら許容されますか？

ホテルが最初の試験運用の前に、自ら基準を書面で定めます。お金のグループについては、原則として説明のつかない差異は認めません。不明確な項目は確認待ちのグループに入れ、経理責任者が書面で判断します。

残高確定記録には誰が、いつ署名しますか？

ホテルの代表者、経理責任者、ソフトウェアベンダーの代表者が署名し、添付の明細表の全ページに略式署名をします。記録は、締めの夜の後、新システムでの最初のシフトが始まる前に署名します。

多施設チェーンでは、切り替え後に統合された会計報告書が得られますか？

はい。施設が1つのDiACCを共有し、各施設を下位単位として設定していれば、DiACCは試算表などの会計報告書を統合します。各施設がそれぞれ別のDiACCを使う場合は、自動統合されません。

切り替え後、旧システムはどのくらい残しておくべきですか？

照会用に、旧システムを3〜6か月間閲覧専用モードで残します。停止する前に、最終バックアップ、締め日時点の報告書、残高確定の書類一式を、会計書類の法定保存期間にわたって保管します。