原価管理システムの移行は、旧台帳の合計を新画面へ入力すれば終わりではありません。工事・品目・案件の番号を対応させ、開始残高と明細を二重に計上せず、未完了の発注・請求・支払を引き継げることが必要です。本記事では、移行範囲の決定からデータ整理、試験、切替、旧環境の保管までを実務手順として説明します。
手順はBIZEE編集部による設計例です。個別の会計処理は自社の経理方針と専門家の確認に従ってください。製品の出力・契約情報は2026年8月31日に公式公開情報を確認しました。移行先をまだ決めていない場合は要件整理と選定と5製品比較から始めます。
移行範囲と切替日を、契約終了日より先に決める
最初に、全部の過去明細を移すのか、進行中の案件だけを移すのか、開始残高から始めるのかを決めます。すべてを移せば便利とは限らず、過去のコードや誤入力まで持ち込むと新しい運用の整理が難しくなります。一方、過去データを切り捨てると、問い合わせや比較資料を作れなくなることがあります。照会、集計、継続取引の三つの用途で必要な範囲を分けます。
切替日は、月末だから自動的に最適というわけではありません。会計の締め、工事の請求、棚卸、給与・工数の確定が重なる日は作業が集中します。各部署が照合できる日と、旧環境を使い続けられる期間を確認して決めます。移行の検査が終わる前に旧契約を終了する計画は避け、必要なデータを取得する時間を確保してください。
例えばReforma PSAの公式規約は解約後のデータ利用・閲覧ができなくなる旨を定め、レッツ原価管理Go2クラウドの詳細も更新しない場合の閲覧終了を案内しています。2026年8月31日確認。サービス側の保管があるとしても、自社が自由に取得できる期間と同じとは限りません。
移行計画には、担当者、承認者、作業日、判定資料、失敗時の戻し方を書きます。販売元へデータ変換を依頼する場合でも、変換後の内容を正しいと承認する責任は自社に残ります。「ファイルの取込み成功」を「業務移行完了」と同義にせず、各部署が何を確認すれば合格かを先に決めてください。
データ台帳を作り、残高と明細を区別する
| データ群 | 確認する内容 | 移行時の注意 |
|---|---|---|
| マスター | 工事・案件・品目・取引先・部門・科目 | 旧番号と新番号の対応表を残す |
| 開始残高 | 切替前までの累計売上・原価・在庫など | 明細と重複して集計しない |
| 未完了取引 | 発注残・未請求・未回収・未払 | 残高だけでなく対象取引を追える状態にする |
| 過去明細 | 照会や比較に必要な期間 | 取り込み対象と参照保管を分ける |
| 添付・帳票 | 証憑・出力様式・説明資料 | 専用形式と一般閲覧形式を区別する |
| 権限・履歴 | 担当・承認・変更の情報 | 自動移行できると決めつけない |
この表は移行対象を整理するためのものです。すべての製品がすべての項目を出力・取込みできるという意味ではありません。販売元へはデータの名称だけでなく、サンプルの列、件数、文字コード、日付形式、添付の関係を示し、何をどの形式で移せるか確認します。出力できない情報は、別の保管方法で目的を満たせるかを検討します。
原価の累計残高と個々の伝票を同じ集計へ入れると二重になります。例えば切替前までの累計を開始額として持つなら、移した過去明細は参照だけにするのか、集計へ含めるなら開始額をどう扱うのかを決めます。単に取込画面の指示どおり入力するのではなく、新システムの集計方法を理解してからテストしてください。
データ台帳には、取得元、取得時刻、対象期間、抽出条件、ファイル名、件数、合計、確認者を残します。同じ「最新版」という名前のファイルが複数ある状態を避け、抽出後に旧環境へ追加された伝票は差分として管理します。ファイルの個数だけでは完全性を確かめられないため、どの情報が含まれているかを台帳で説明できるようにします。
マスター整理：同名の統合と別物の区別
取引先の略称や旧社名が複数ある場合、同じ会社だからといってすべてのコードを無条件に統合しません。請求先と支払先、支店、契約主体の違いがあるかを確認します。統合するなら旧コードから新コードへの対応を一意に定め、どの残高が合算されたか説明できるようにしてください。
工事や案件は、親子関係を先に決めます。本工事と追加工事、年間契約と月別作業、一つの顧客の複数プロジェクトをどう扱うかが変わると、前年対比や担当者別の資料も変わります。新しい番号へ置き換えるだけでなく、旧資料を探せる番号や参照情報を残します。途中でルールを変えた場合は変更日と適用範囲を記録します。
製造系では、品目、規格、単位、構成を照合します。箱・個・重量などの単位が混じる場合、単位変換が必要か、固定の係数で扱えるかを確認します。売上原価Proのように製品・半製品・材料を分けて検討する場合は、状態の違う在庫を一つの品目へまとめてよいかも検証します。似た名称の材料を誤って統合しないよう、現場責任者に確認を依頼してください。
部門と原価科目も、使われていないものをすぐ削除するのではなく、過去参照の必要性を見ます。今後の入力候補から外すことと、過去資料から消すことは別です。移行後に古い科目が選べず、新しい伝票の入力が簡潔になる一方、以前の分類をたどれる設計を目指します。
工事・在庫・工数で違う、開始時点の照合
工事型では、切替時点の未成工事を一覧にし、実行予算、累計原価、発注残、未払、追加工事の売上見込みを別々に確認します。発注済みの金額と仕入実績を合算して二重に原価へ含めないことが重要です。請求書がまだ来ていない取引は、何を見込みとして持ち、正式請求到着後にどう置き換えるかを決めます。
在庫型では、帳簿数量と実際の数量、評価の対象と時点を揃えます。移行作業中にも受入や出荷が続くなら、どの時刻で在庫を切り、以後の動きをどちらに入力するかを決めます。材料、半製品、完成品の分類を変える場合、数量だけでなくどの状態へ移したかを記録してください。移行差額の処理を便宜的に調整せず、経理責任者と原因を確認します。
工数型では、案件ごとの累計時間と、売上・外注・経費の対応を照合します。移行と同時に時間単価や工数分類を変えるなら、過去の原価が同じ値にならない可能性があります。比較用の旧条件と運用開始後の新条件を分け、何が変わったか説明できる資料を作ります。Reforma PSAやZACを選ぶ場合にも、案件単位の定義を先に確認してください。
どの型でも、全社合計だけでは不十分です。案件別、取引先別、科目別など、日常の問い合わせで使う単位へ掘り下げて確認します。合計が同じでも別案件に付いていれば、個々の採算や支払に影響します。差額がないかだけでなく、必要な対象へ正しく配分されているかを検査します。
試行移行：小さく通して、差異の理由を記録する
- 凍結前の試行匿名化した代表データで形式と項目対応を確認。
- 全体の試行本番相当の範囲で件数・合計・処理時間を検証。
- 差異の修正コード、日付、税区分、重複、対象外を切り分ける。
- 切替の承認未解決項目と戻し条件を責任者が確認。
- 本番照合最終抽出と追加差分を反映し資料を再確認。
編集部の手順例です。最初の試行では通常の伝票だけでなく、取消、値引き、分割、過去日付、ゼロ金額、名称の長い項目など、自社データにある例外を含めます。特殊なケースを後回しにすると、全件移行した日にエラーが集中します。形式の問題と業務上の意味の違いを分けて、修正方法を決めます。
差異表には、旧値、新値、差額、対象番号、原因、処置、再試験結果を書きます。原因不明の差額を「端数」とまとめないでください。本当に丸め方が違うなら、その単位と条件を説明します。抽出対象の日付が違う、取消伝票が二重に入った、税の扱いが違うなどの原因を順に確認すると、表面上だけ数字を合わせる修正を避けられます。
製品側の仕様により完全一致しない場合は、許容する差異と説明資料を承認してもらいます。許容という言葉で重要な欠落を隠さず、業務に影響しない理由を示します。何を合格としたかを記録しておくと、本稼働後に担当者が変わった際も、既知の違いと新しい不具合を分けられます。
切替当日と、元へ戻す判断
切替直前は、旧環境での入力を止める時刻を決め、停止後に届いた伝票の置き場を用意します。担当者が独自に旧システムへ入力を続けると、最終抽出との差分を取り切れません。緊急の支払や請求が必要な場合の処理を事前に決め、例外を一覧へ記録します。業務を完全停止できない会社ほど、この差分管理が重要です。
- 最終データと追加差分の取得時刻が記録されている。
- 件数・合計・主要案件の照合が完了している。
- 入力者・承認者が自分の権限で業務を通せる。
- 会計等への初回連携と、エラー時の再送手順を確認した。
- 問題発生時に旧運用へ戻る期限と責任者が決まっている。
戻す判断には、重要データの欠落、請求・支払の継続不能、権限の重大な不整合、照合できない差額などを設定します。画面の表示の好みと、業務を止める問題を同じ優先度にしないでください。新環境へ本番入力を始めた後に戻すなら、その入力を旧環境へどう反映するかも必要です。単にバックアップを戻せばよいとは限りません。
特にレッツ原価管理Go2は、公式FAQでオンプレミスとクラウドの同一PC共存不可を案内しています。並行試験や戻し方に端末が関係する例です。どっと原価3でも本体・追加サービス・契約構成を揃えて確認します。クラウドという名称だけで端末準備が不要と判断しないでください。
旧データの保管と、終了手続き
移行後も旧データを保管する場合、一般的な形式で読める帳票と、再取込み用のデータを分けます。PDFは参照しやすい一方で、後から集計し直す用途に向くとは限りません。CSVは再集計に使えても、項目の意味やコード対応がなければ正しく読めません。専用バックアップは、対応ソフトや契約が終了した後に使えるかを確認します。
保管場所は個人PCや個人アカウントだけにせず、会社が管理できる場所を選びます。アクセス権を限定し、担当者が異動・退職しても必要な人が参照できる状態にします。保管期間や削除の方針は自社の法令・契約・社内規程に従い、記事の一般論で一律の年数を決めないでください。必要な資料の範囲を経理・契約担当と確認します。
旧契約の終了は、本体、保守、クラウド基盤、追加サービス、会計連携などを一覧にして行います。サービスの解約申請、利用者の停止、端末アプリの整理、出力ファイルの保管、削除証明の取得が必要かをそれぞれ確認します。解約したつもりでも周辺サービスだけ残ることがないよう、契約台帳と請求を照合します。
本稼働後の確認と、よくある質問
引継ぎ資料には、数字の照合結果だけでなく、日常の検索方法を含めます。例えば過去の工事番号から新しい案件を探す方法、取引先の旧名で検索する方法、取消済みの伝票を参照する方法です。移行担当者だけが対応表の場所を知っている状態では、日々の問い合わせがその人へ集中します。別の担当者が資料を使って回答できるかを試してください。
例外の残り方も管理します。移行日に確定できなかった請求額や、後から届く外注費があるなら、対象番号、暫定値、確定予定日、担当者を一覧へ残します。こうした未確定情報を完成済みデータと混ぜず、翌月の締めで更新したことを確認します。旧環境の誤りを新環境で直した場合も、差額がどの処置で解消したかを記録します。
契約終了の手続きが済んだ後は、不要になった接続権や連携アカウントの扱いを確認します。ログインできる人を残す必要がある場合も、閲覧目的と管理責任者を明確にします。移行そのものが成功していても、旧環境へ誰でもアクセスできる状態を放置しないことが、引継ぎを完結させる最後の工程です。
最初の月次締めでは、旧運用と同じ条件の資料を作り、違いを説明します。旧環境と完全な二重入力を長く続けると負担が増えるため、並行照合の期間と終了条件を決めます。請求、支払、原価、在庫、工数のうち重要な対象を優先し、未処理・訂正を月次運用ガイドの管理へ引き継ぎます。
過去データは全部移すべきですか？
必ずしも全部ではありません。進行中の取引、過去照会、比較分析の目的に分けて必要範囲を決めます。移さない期間も、契約終了後に読む方法が必要なら事前に確保します。移行量を減らすこととデータを失うことを同義にしない設計が重要です。
合計金額が合えば移行成功ですか？
それだけでは不十分です。件数、工事や案件、取引先、科目への対応を確認します。合計が同じでも付け先が違えば採算や支払を誤ります。差異の原因を説明できる記録と、利用者による業務確認を合わせて判断してください。
販売元が移行してくれるなら自社確認は不要ですか？
不要ではありません。販売元は形式変換を支援できても、自社の旧台帳が意味する内容まで自動的に保証できるわけではありません。自社の責任者が開始残高と未完了取引を確認し、必要な業務が再現できることを承認します。
調査・更新履歴：2026年8月31日作成。公式契約・製品説明を基に、編集部が移行台帳、差異表、切替・戻し条件、旧データ保管の手順を整理しました。製品ごとの出力可否や契約終了の条件は、各詳細と正式な契約書面で最終確認してください。
