こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

8月15日、東京・有明アリーナ。バスケットボール男子日本代表は韓国を88対68で圧勝した。パリ五輪以来2年ぶりの代表復帰となった河村勇輝が12得点6アシスト—八村塁のスリーポイントをアシストするNBAコンビのプレーは会場を沸かせた。

試合後、河村は最終クォーターのミスをこう振り返った。「タイミングや状況判断のミス」と。

ERP の月次締めも、まったく同じ言葉で語れる。「在庫締めのタイミングが遅れた」「補助元帳の照合完了前に期間をロックした」「外貨再評価の順序を間違えた」—締め処理の失敗のほとんどは、技術の問題ではなく、タイミングと状況判断の問題だ。

「月末になると経理から電話が来る」

プロジェクト現場で一番よく聞く話かもしれません。「締めが終わらない」「試算表が合わない」「なぜかマイナスの在庫がある」—月次締めは、ERPが正しく設計されていたかどうかの採点表です。

月次締めを一度でも一緒に乗り越えたクライアントとは、不思議な絆ができます。夜中の2時に仕訳帳の差額を追いかけながら、「なぜこの科目が合わないんだ」と頭を抱えた経験が、システム導入を本当の意味で理解させてくれる瞬間でした。

締め処理は、ERPの「心拍数」です。毎月・毎年、必ず処理が必要で、設計ミスがあれば誤差が積み上がっていきます。Dynamics 365では、Business Central（BC）とFinance & Operations（FO）でその仕組みが大きく異なります。どちらを選んでいても、締め処理の設計を間違えると「数字が合わない」という苦しい月末を繰り返すことになります。

今回は、BCとFO、そしてCRM・Project Operationsが絡む環境での月次・年度締め処理を、実務の視点で整理します。

締め処理とは何か

「締め処理」とは、ある期間の財務数値を確定するための一連の業務プロセスの総称です。会計的には「ある期間の取引記録を確定し、以後の遡及修正を統制する」処理ですが、重要なのは——システムが物理的にすべての修正を禁止するわけではない、という点です。

実際には、BC で Fiscal Year を Close した後も設定が許す限り GL エントリを転記できますし、FO でも On Hold の期間は管理者が再オープンして修正できます。したがって「締め = ロック」という理解よりも、「締め = 内部統制の設計と運用によって財務数値を確定するプロセス」と捉える方が正確です。

目的は二つあります。一つは正確な財務数値の確定。月次の損益・貸借対照表・在庫評価を確定し、次の意思決定に使える数字を作ることです。もう一つは内部統制。転記日管理・アクセス制御・照合プロセスを組み合わせることで、過去期間への無制限な遡及修正を防ぎ、数字の信頼性を保ちます。これを実現する手段の一つが、Period Control（転記日管理）です。

BCとFOでは、この統制モデルの粒度が根本的に異なります。BCは中堅企業向けに実用性と柔軟性のバランスを取った設計、FOはグローバル企業の内部統制要件に応えるための多段階・精密な設計です。

Business Central の締め処理

BCの月次締めで特にポイントとなるのが、在庫原価の確定と転記日管理の設計です。どちらも「設定を確認する」ことが先決で、環境によって必要な手順が変わります。

ステップ 1：在庫原価の確定（Cost Adjustment）

BCでは在庫の原価調整を担う仕組みとして、Automatic Cost Adjustment の設定が重要です。デフォルトは Always であり、この場合は入出庫の転記時に原価調整が自動実行されます。設定が Off または Scheduled（Job Queue 経由）の場合は、月次締め前に Adjust Cost – Item Entries バッチを手動実行する必要があります。

どちらの設定であっても、締め前に未調整の原価が残っていないことを確認してください。原価調整の仕組みは総平均法（Average Cost）に限らず、FIFO や標準原価など他のコスト方法にも適用されます。

もう一点、Expected Cost Posting（期待原価転記）の設定も確認が必要です。この設定が有効な環境では、仕入未請求の入庫時に暫定的な仮原価が GL へ転記されます。請求書到着後に実際の原価と差額調整が発生するため、月次締め時に「仮原価として計上されている残高がないか」を確認し、未解消の Expected Cost Entry が残っている場合は内容を把握しておく必要があります。

ステップ 2：在庫原価の GL 反映（Post Inventory Cost to G/L）

在庫原価を GL へ反映する方法は、Automatic Cost Posting の設定によって異なります。この設定が有効な環境では、在庫原価は入出庫の転記時に自動的に GL へ記録されるため、手動での Post Inventory Cost to G/L バッチは不要です。Automatic Cost Posting を使用していない環境では、Adjust Cost の後にこのバッチを実行して在庫と財務を同期させます。

月次締め前に「在庫補助台帳（Item Ledger Entries / Value Entries）と GL 在庫勘定の残高が一致しているか」を確認することが本質です。設定に応じた方法で確認してください。

ステップ 3：外貨再評価（Adjust Exchange Rates）

外貨建て取引がある環境では、月末時点のレートで売掛金・買掛金・外貨銀行口座・外貨建て GL 勘定の残高を再評価し、未実現為替差損益を計上します。BCでは Adjust Exchange Rates バッチを実行します。再評価対象は Customer（売掛）、Vendor（買掛）、Bank Account、GL 勘定の4種類をそれぞれ選択できます。実行前に月末の為替レートがシステムに登録されていることを確認してください。

ステップ 4：消費税（VAT）照合

BC では、すべての課税取引が転記時に VAT Entry として記録されます。月次締めでは VAT Statement を実行して課税期間の消費税申告額を試算し、VAT Entry および関連する G/L Entry と整合していることを確認します。

申告タイミングは国・地域によって異なります。月次申告が必要な環境では毎月末に VAT Settlement（VAT 申告の確定処理）まで実施しますが、四半期・年次申告が中心の環境では月次は試算・確認のみで、申告期に本申告を行うパターンが多いです。

国別のローカライズ対応も重要です。英国の Making Tax Digital（MTD） では VAT 申告を HMRC に電子送信する仕組みが BC に組み込まれています。EU 各国・日本・アジア各国向けのローカライズ機能（Microsoft 提供またはパートナー提供）も用意されており、多国展開の環境では法人ごとに VAT 設定・申告フォーマット・税率体系が異なることを前提に設計しておく必要があります。日本法人が含まれる場合は、適格請求書保存方式（インボイス制度）への対応も設計段階で確認してください。

ステップ 5：銀行照合（Bank Reconciliation）

BC の銀行照合は Bank Account Reconciliation 画面で実施します。銀行明細（Bank Statement）を CSV・銀行連携サービス・OFX 等でインポートし、BC 側の Bank Ledger Entries と突き合わせます。

BC には自動照合候補機能が搭載されており、金額・日付・取引先の類似度をもとに自動的に照合候補を提案します。大量取引がある環境では照合作業を大幅に効率化できます。照合できなかった差異（Difference）は、転記済みの仕訳との不一致・タイミング差・未記帳取引のいずれかを原因として特定し、必要に応じて仕訳を追加します。

月末の銀行照合では、以下の点に注意が必要です。

• カットオフ管理：銀行の月末残高確認日と BC 側の転記日が一致しているか。月末日付の取引が翌月に入金されるケースは未収として管理します。
• 未照合残（Outstanding Items）：期末に残った未照合の入出金は理由を説明できる状態にしておく必要があります。翌月への繰越が続く項目は内容を確認してください。
• Payment Reconciliation Journal との使い分け：BC には売掛・買掛の入出金照合に特化した Payment Reconciliation Journal もあります。銀行照合（Bank Account Reconciliation）はあくまで帳簿残高と銀行残高の突き合わせが目的であり、顧客・仕入先への消込は別プロセスです。

ステップ 6：転記可能期間の制御

ここは BCの実務上、非常によく誤解される点です。

BCでは Accounting Period の「Closed」フラグが転記を禁止するわけではありません。Microsoft のドキュメントには「Accounting periods don’t control posting dates.」と明記されており、Fiscal Year を Close した後も、後述の設定が許す限り GL エントリをその年度へ転記できます。Accounting Period は主に、年度・会計期間の構造管理および Close Income Statement 等の期末処理完了管理に使用するものです。

BCで転記可能日を実際に制御するのは以下の2か所です。

月次締め中の設計例：General Ledger Setup で一般ユーザーは翌月のみ転記可能に設定し、User Setup で経理管理者だけが前月への修正転記を許可する——という多段階の統制が可能です。

なお、2026 Wave 1 より、General Ledger Setup・User Setup・General Journal Template で Allow Posting From/To Date Formula を使用できます。日付式は Today（本日日付）を基準に評価されます。

年度締め：Close Income Statement

年度末には損益勘定振替（Close Income Statement）を実行します。P&L 科目残高を指定した貸借対照表勘定（通常は繰越利益剰余金に相当する勘定）へ振り替えます。振替先の勘定は実行時に指定するため、企業の勘定科目設計によって異なります。

重要なのは、Fiscal Year を Close した後も、General Ledger Setup / User Setup の Allow Posting From / To が許す限り、Closed な年度への GL エントリ転記は引き続き可能な点です。翌年度の通常業務を続けながら前年度の決算調整を行えるのが BCの設計の特徴です。

Finance & Operations の締め処理

FO の締め処理は、BC より多段階・精密です。在庫原価、補助元帳、外貨再評価、期間ステータス、モジュール別アクセス制御、仕訳帳単位の統制—これらをセットで設計しないと、月次締めのたびに差額と戦うことになります。

Financial Period Close Workspace（期間締めワークスペース）

FO には「Financial Period Close Workspace」という専用の作業管理画面があります。締め処理に必要なタスクを一覧化し、担当者・ステータス・依存関係を管理します。大企業向けに設計された機能で、締め処理をプロジェクト管理のように運用できます。特に重要なのはタスク間の依存関係管理と並列処理管理で、「在庫締め完了後に補助元帳照合を開始する」「複数法人の照合を並列実行する」といった複雑な締め工程を構造化して管理できます。

ステップ 1：在庫原価の処理（Inventory Recalculation / Inventory Close）

FO では Inventory Recalculation と Inventory Close は目的が異なります。

Inventory Close または Recalculation を実行するまでは、出庫取引は暫定的な実行時原価（Periodic Costing モデルにおける Running Average）で転記されます。ここでいう “Running Average” は公式の在庫評価モデル（Moving Average）とは別の概念であり、期末 Close によって確定される前の暫定値と理解してください。Inventory Recalculation は Inventory Close の前提条件ではありません。月次の Inventory Close で入出庫の settlement と在庫期間クローズを行い、Recalculation は期中の原価調整として必要に応じて実行します。

Moving Average の場合は Inventory Close の対象外です。ただし、Moving Average であっても在庫評価額と GL 在庫勘定の整合性確認は月次締めで必要です。Inventory Close が不要なことと、照合が不要なことは別です。在庫評価モデルごとの締め手順は事前に設計しておく必要があります。また、Inventory Close 後は設定した在庫締め日以前の期間への在庫に影響するトランザクションが制限され、取消する場合は最後に閉じた在庫期間から順番に戻す必要があります。

ステップ 2：補助元帳の照合（Subledger Reconciliation）

FO の特徴は、多くの業務トランザクションが AP・AR・Inventory・Project・Fixed Assets などの補助元帳を経由し、最終的に GL へ転記される点です。一方、General Journal のように補助元帳を経由せず直接 GL へ転記される処理も存在します。この「補助元帳経由」と「GL 直接転記」の2つのルートが混在することを理解した上で補助元帳照合を設計する必要があります。

月次締め前に、補助元帳残高と GL 残高が一致していることを確認します。未転記の仕訳（Unposted Journals）や承認待ちのトランザクションが残っていると、補助元帳と GL に差額が生まれます。確認には、Account Reconciliation workspace（AP / AR / Tax / Bank と GL の照合を自動化・継続的に実施できる現行機能）または従来の Subledger to General Ledger Reconciliation レポートを使用します。

なお、差額がある場合にシステムが自動的に期間 Close を拒否するわけではありません。内部統制上、締め前に差額を解消または例外として承認・記録することが重要です。

ステップ 3：未転記仕訳・未処理トランザクションの確認

FO では仕訳の確定前に未転記の状態（Unposted Journals / Pending Transactions）が存在します。期間締め前にこれらをすべて確認し、承認・転記または削除します。未処理のトランザクションが残っている場合、Account Reconciliation workspace 等での照合で例外として検出される可能性があります。

ステップ 4：外貨再評価（Foreign Currency Revaluation）

外貨建て残高があり、未実現為替差損益を認識する会計方針の環境では、FO の月次締めで外貨再評価を実施します。FO では AR・AP・Bank・General Ledger のそれぞれに外貨再評価の機能があり、未決済の外貨建て残高を月末レートで再評価して未実現為替差損益を計上します。

ここで重要な設計上の注意点があります。AR・AP・Bank 側で外貨再評価を実行する主勘定（売掛金・買掛金・銀行）を、GL 側の外貨再評価対象にも含めてしまうと、為替差損益が二重に計上される可能性があります。どのモジュールで、どの主勘定を、どの Exchange Rate Type で再評価するかを月次締め手順に明記しておく必要があります。

また、FO では Accounting Currency（会計通貨）と Reporting Currency（報告通貨）の両方を管理できます。親会社へのレポートが外貨建てになる場合、報告通貨の再評価設計も月次締め設計に含める必要があります。

ステップ 5：期間ステータスの変更

FO の会計期間には実質的に 3 つのステータスがあります。

月次締めでは On Hold を基本とします。Microsoft の 2026 年ガイダンスでは、すべての調整・確認が完全に完了するまで Permanently Closed を設定しないことを推奨しており、多くの場合は On Hold のまま運用するのが現実的です。

ステップ 6：モジュール別・ユーザーグループ別アクセス制御

FO では Ledger Calendar で期間ステータスを管理するだけでは不十分です。Update Module Access 機能により、選択した Application Module の投稿アクセスを All・None・特定 User Group のいずれかで設定できます。

たとえば月次締め中は、General Ledger は経理締め担当 User Group のみ前月転記可能、AP は請求書処理チームのみ、Sales / Purchase は前月転記不可（None）——という粒度での制御が可能です。この設計を行わないと、経理が照合を終えた後に別部門が前月日付で追加転記し、補助元帳と GL の照合結果が変わってしまいます。

ステップ 7：仕訳帳単位の統制（Journal Control / Posting Restrictions）

さらに厳密な統制が必要な場合は、Journal Name ごとに Journal Control と Posting Restrictions を設計します。Journal Control では転記可能な勘定タイプや財務分析コードの範囲を制限でき、Posting Restrictions では特定の User Group のみがその仕訳帳を投稿できるように制御できます。月次修正仕訳・為替再評価・監査調整の仕訳帳を分離し、用途別に投稿可能な User Group を割り当てることで締め処理中の誤転記を減らせます。

年度締め：Year-end Close

FO の年度締めは「Year-end Close」ワークスペースで実施します。Year-end Close では主に2種類の処理が生成されます。Opening transaction は Balance Sheet 残高を翌年度の期首残高として引き継ぎます。Closing transaction（オプション）は当年度の P/L 残高をゼロにするための処理です。

重要なのは、Year-end Close は再実行できる点です。期末調整仕訳を追加した後に再実行することで、翌年度の Opening Balances を更新できます。複数法人がある場合は法人ごとに実行し、連結（Consolidation）を行っている場合は法人間消去・連結処理を経てから連結財務諸表を作成します。

BC vs FO 締め処理 比較

CRM・Project Operations が関係する締め処理

Sales・Customer Service・Field Service および Project Operations は、会計的な締め処理を行いません。ただし、これらが ERP（BC / FO）の請求・在庫・プロジェクト原価・収益認識と連携している場合、月次締めのタイミングで確認が必要なポイントがあります。連携方式（Dual-write・Dataverse integration・カスタム等）によって確認内容は変わります。

Sales：未連携の受注・請求

Sales と ERP が連携している構成では、当月の売上・請求対象データが ERP 側へ正常に連携済みかを確認します。未連携の受注が残っていると、当月の売上が翌月にずれ込みます。連携方式によって確認手順は異なります。

Project Operations（Integrated with ERP 構成）のタイムシート

Project Operations は Dataverse Core と Integrated with ERP（Finance との統合）の複数の構成があります。Integrated with ERP 構成では、PO 側でタイムシートが承認されると FO のプロジェクト元帳に転記される仕組みです。月末にタイムシートが未承認のまま残ると、当月のプロジェクト原価が確定しません。例えば月次締めの3営業日前を社内のタイムシート提出期限とする——といった運用ルールをプロジェクトマネージャーと事前に合意しておくことが現実的な対策です（これは組織内のベストプラクティスであり、Microsoft の標準仕様ではありません）。

固定価格プロジェクトの月次原価管理（WIP / EAC）

Project Operations + FO 連携で本当にリスクになるのは、タイムシート承認だけではなくプロジェクト損益の把握です。固定価格プロジェクトでは、月次締めのたびに以下の4つを確認する必要があります。

タイムシート承認だけではプロジェクト損益は見えません。EAC が契約金額を超過しているにもかかわらず WIP だけが膨らんでいる状態で月次締めを進めると、プロジェクト別の損益が翌月以降に一気に悪化するリスクがあります。月次締め時には PM と経理が EAC・WIP・請求残高を照合するプロセスを設計段階で組み込んでおく必要があります。

収益認識のタイミング

固定価格プロジェクトやマイルストーン請求では、売上計上のタイミングを明確に設計する必要があります。Project Operations と FO を連携している場合、契約・マイルストーン・タイムシート・費用・請求・プロジェクト会計のどこを売上認識の基準にするかは、業務要件・契約モデル・構成によって異なります。事前に明確な設計がないと、月次締め時にプロジェクト別の売上・原価・WIP が不整合になります。

繰延収益・収益認識の設計

SaaS・サブスクリプション型ビジネスでは、受注金額をそのまま当月の売上に計上するのではなく、契約期間にわたって配分します。Finance の旧 Revenue Recognition 機能は 2024 年 1 月に非推奨化されており、現在は Subscription Billing・Project Operations 固有の収益認識設定・Deferred Revenue のいずれかへの移行が推奨されています。移行先は SaaS・プロジェクト型・製造業など業務モデルによって異なるため、一律に「Subscription Billing へ移行」とはなりません。どのモジュール・構成で繰延収益・収益認識を管理するかを導入初期に定義しておく必要があります。設計を後回しにすると、月次ごとに手動修正が必要になります。

Field Service の請求連動—BC と FO で連携パスが異なる

Field Service の月次確認内容は、バックエンドの ERP によって連携パスが異なります。

BC 環境では、Field Service と BC が直接連携します。Work Order がクローズされると BC 側で請求書が生成され、売上・原価が BC の GL へ計上されます。月次締め前に「クローズ済み Work Order のうち未請求のものがないか」を確認します。

FO 環境では、Field Service は Project Operations を経由して Finance（FO）へ連携します。Field Service の作業実績が Project Operations のプロジェクト原価・WIP として集約され、そこから Finance へ転記される構造です。このため、FO 環境での Field Service 月次確認は、前述の Project Operations（WIP / EAC / タイムシート）の確認と一体で設計する必要があります。Field Service 側で Work Order をクローズしても、PO 側の承認・転記が完了していなければ Finance には反映されません。

Customer Service（Case）そのものは会計転記の主体ではありませんが、有償サポート契約・保証対応に連動する請求がある場合は当月計上対象として確認します。

マルチシステム環境での締め Runbook（一例）

BC + FO + Sales + Project Operations が混在する環境での締め処理の順序を以下に示します。これはあくまで一例であり、企業の環境・モジュール・統制設計によって最適な順序は変わります。特に外貨再評価と照合の順序、法人間処理のタイミングは、設計段階で確認してください。

落とし穴

月次締め完了確認とレポート出力

期間をロックすることは締め処理の「ゴール」ではありません。数値を確定した後、以下のレポート出力と照合を行うことで初めて月次締めが完了します。これらは BC・FO 共通の確認フェーズです。

先日付小切手・手形など期日付き支払手段の注意点

小切手（Check）・約束手形・為替手形など期日付きの支払手段を使用している場合、共通する会計上の課題は手段を授受した日と実際の資金移動日（決済日）がずれることで、月次締めの銀行残高認識にタイミング差異が生じます。

BC・FO ともにこれらの期日付き支払手段の管理機能を持っており、期日管理・GL 計上のタイミングを制御できます。グローバル案件では「銀行残高照合」だけでなく、期日付き支払手段の一覧・期日・計上タイミングの設計を月次締め手順に含めておく必要があります。銀行の実残高と ERP の帳簿残高に差異がある場合、その内訳として未決済の手形・小切手残高を説明できる状態にしておくことが重要です。

AI時代の締め処理—Copilot と Agent の現在地

2026年の今、月次締め処理は「人が手順書を見ながら実行する」段階から「AI Agent が一部を自律実行する」段階に移行しつつあります。Microsoft は Dynamics 365 Finance・Business Central の両方で Copilot 機能と Agent 機能を順次展開しており、締め処理の一部はすでに自動化・アシスト化が始まっています。

ただし、現時点では「Agent が締め処理を完全に自律実行する」段階ではありません。Agent は差異検出・アラート・提案を行い、最終判断と承認は人が行うという「Human-in-the-Loop」設計が基本です。締め処理の設計品質—特に補助元帳照合・期間ステータス管理・モジュールアクセス設計—が整っていない環境では、AI が正しいデータを参照できず、提案精度が下がります。Agent を活かすためにも、本稿で説明した基本設計が前提となります。

まとめ

昨夜の試合に戻ろう。河村勇輝と富樫勇樹のダブルガードは、役割を固定しない。一人がゲームをコントロールし、もう一人がスペースを突く。状況に応じて役割を入れ替えながら、相手を崩していく。BC の GL Setup（全体制御）と User Setup（個別例外）はこの構造に近い。FO の Ledger Calendar と Module Access も同じだ—一方が期間全体を管理し、もう一方がモジュールごとの粒度で締めを制御する。どちらも、一人でやろうとすると穴が生まれる。

そして河村は言った。「タイミングや状況判断のミス」と。締め処理の失敗も、まったく同じ構造だ。

月次・年度締め処理は、ERP の心拍数です。設計が正しければ毎月滑らかに動き、設計ミスがあれば毎月同じ痛みを繰り返します。

BC と FO の本質的な違いは「シンプル vs 複雑」ではなく、統制モデルの粒度と対象業務規模の差です。BC は中堅企業向けに転記日管理・在庫原価設定・外貨再評価・複数法人対応（Consolidation を含む）を実用的な粒度で提供します。FO はグローバル企業の内部統制要件に応えるため、補助元帳・期間ステータス・Module Access・Journal Control・連結まで、より精密な設計が求められます。

さらに踏み込むと、BC と FO の締め思想は根本が異なります。BC は「締めても翌日の業務を止めない」ことを優先する設計—General Ledger Setup / User Setup の柔軟な転記日管理、Closed 年度への追記転記が引き続き可能な構造がその表れです。FO は「締めるために統制する」ことを優先する設計——Ledger Calendar の Period Status、Module Access、Journal Control を組み合わせた多段階の制御がその表れです。どちらが優れているかではなく、企業規模・ガバナンス要件・グローバル展開の有無によって、必要な統制レベルが異なります。この思想の差を理解した上で設計すること—それが、どちらの製品でも月末を穏やかに迎えるための出発点です。

もう一つ重要なのは、「締め処理 = 期間をロックすること」という理解の罠です。BC でも FO でも、適切な設定変更や管理者操作があれば締め後の修正は可能です。締め処理の本質は、転記日管理・アクセス制御・照合プロセスを組み合わせた内部統制の設計と運用にあります。

外貨再評価は、BC・FO 問わず、外貨建て残高があり未実現為替差損益を認識する会計方針の環境では月次締めの重要な処理です。FO では特に、AR / AP / Bank / GL それぞれの再評価対象勘定を整理し、同一主勘定の二重計上が起きない設計を確認してください。

Project Operations・Sales などとの連携がある環境では、ERP の締め処理は ERP 単体では完結しません。連携構成ごとに「どのシステムの、どのデータが、いつ ERP に反映されるか」を明確にしておくことが、月次締めの品質を左右します。

八村塁が戻ってチームが完成したように、設計に欠けているピースを一つひとつ埋めることが、月末のスコアボードに正しい得点を刻む唯一の方法です。

皆さんの環境では、月次締めのどこがボトルネックになっていますか？BC・FO の違いで困ったこと、補助元帳照合で手こずった経験、ぜひコメントや SNS で教えてください。

それでは今日はこのくらいで。Let’s Enjoy our DX365Life!