システム開発費の仕訳｜着手金からソフトウェア仮勘定の振替まで実務例

システム開発会社から着手金の請求書が届き、支払いも済ませた。あとは会計ソフトに入力するだけ——のはずが、いざ伝票を切ろうとすると手が止まってしまう。「この支払いは何勘定の借方に立てればいいのか」「完成して検収が終わったら、どう振り替えるのか」。資産計上する方針までは社内で固まっているのに、肝心の借方・貸方が決まらない、という経験はないでしょうか。

システム開発費の仕訳がやっかいなのは、一度の支払いで完結しないからです。着手金 → 中間金 → 検収後の残金 → 完成後の保守費、と支払いが時系列で発生し、その都度立てる勘定科目が変わります。さらに完成前は「ソフトウェア仮勘定」で集計し、完成したら「ソフトウェア」へ振り替えるという、ふだんあまり使わない処理が挟まります。記帳スキルはあっても、システム開発の分割支払いにこれを当てはめた経験がないと、どこから手をつけていいか分からなくなります。

この記事では、システム開発を発注した発注者（経理担当者）が、伝票を切る順番に沿って迷わず仕訳を切れるように、各支払い場面の借方・貸方を金額入りの具体例で示していきます。着手金・中間金の処理、完成時のソフトウェアへの振替、保守費の費用仕訳、減価償却、そしてよくある誤りの修正仕訳まで、自社の取引に当てはめながら確認できる構成にしました。

会計ソフトに入力する前の「叩き台づくり」に、そして顧問税理士へ確認する前の下準備に、そのまま使える内容を目指します。なお、本記事は会計・税務の一般的な仕訳の考え方を整理した解説です。実際の会計処理は契約内容や自社の会計方針によって変わるため、最終的な判断は顧問税理士・公認会計士に確認してください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

システム開発費の仕訳は「支払いのタイミング」で変わる

最初に、システム開発費の仕訳の全体像を押さえておきましょう。ここが頭に入っていれば、個別の仕訳例も「いま自分はどの場面にいるのか」を見失わずに読み進められます。

支払いイベントの流れと、仕訳が変わる理由

システム開発を外部に発注すると、多くの場合、料金は次のような順番で分割して支払います。

着手金 → 中間金 → 検収・残金 → （完成後）保守費

そして、仕訳はこの支払いイベントごとに変わります。理由はシンプルで、支払った時点の「会計上の意味」がそれぞれ違うからです。

• 着手金・中間金: まだシステムは完成していません。お金は払ったけれど、資産として使える「もの」はまだ手元にない段階です。
• 検収・残金: システムが完成し、検収（納品物が要件どおりか確認すること）が終わって、いよいよ自社で使える資産になる段階です。
• 保守費: 完成後、システムを正常に使い続けるための費用です。資産そのものを作る支出ではありません。

同じ「システム開発会社への支払い」でも、完成前か・完成時か・完成後かで、立てる勘定科目がまるごと変わります。だからこそ、伝票を切る前に「いまはどの段階の支払いか」を確認することが、ミスを防ぐ第一歩になります。

完成前はソフトウェア仮勘定、完成後はソフトウェアへ振替

資産計上する方針が固まっている場合、開発途中の支払いをいったん集める「箱」が必要になります。それがソフトウェア仮勘定です。

建物を建てるときに、完成までの支払いをいったん「建設仮勘定」に集めて、完成したら「建物」に振り替えるのと同じ考え方です。ソフトウェアの場合は、完成までの開発費をソフトウェア仮勘定にためていき、完成・検収のタイミングで無形固定資産の「ソフトウェア」へ振り替えます。

【完成前】着手金・中間金・残金 → ソフトウェア仮勘定 に集計
                                      ↓ 完成・検収
【完成後】ソフトウェア仮勘定 → ソフトウェア（無形固定資産）へ振替
                                      ↓
         以降、毎期 減価償却

【保守・運用】 → 保守費・修繕費などで費用処理（資産とは別建て）

この記事は、この流れに沿って各場面の仕訳を順番に見ていきます。

なお、ここまでは「資産計上する」という前提で話を進めてきました。そもそも自社のこの開発が費用計上なのか資産計上なのか、その判断自体がまだ固まっていない場合は、先に判断軸を整理しておくほうが安全です。費用か資産かをどう切り分けるかは、システム開発費用の勘定科目｜費用計上か資産計上かを判断する3分岐で詳しく解説していますので、方針が未確定の方はそちらを先にご覧ください。本記事は、方針が「資産計上」で固まった読者が、実際の仕訳を切るための実務編という位置づけです。

システム開発費の仕訳で使う主な勘定科目

具体的な仕訳例に入る前に、この記事で登場する勘定科目を、仕訳を切る目線で整理しておきます。それぞれ「どの支払い場面で、借方か貸方のどちらに立つか」をイメージしておくと、後の仕訳例がスムーズに頭に入ります。

ソフトウェア仮勘定とソフトウェア（資産側の2科目）

• ソフトウェア仮勘定: 完成前の開発費を集計しておくための資産科目です。着手金・中間金・残金などを支払うたびに、この科目の借方に積み上げていきます。完成までの「仮置き場」と考えるとわかりやすいです。
• ソフトウェア: 完成・検収後の無形固定資産です。完成したタイミングで、ソフトウェア仮勘定にたまった金額をこの科目へ振り替えます。以降、この金額を耐用年数にわたって減価償却していきます。

前払金・研究開発費（着手段階・不確実段階で使う科目）

• 前払金（前渡金）: まだ役務の提供を受けていない段階で先に支払ったお金を、いったん管理しておく資産科目です。着手金を「最初からソフトウェア仮勘定で受けるべきか、前払金で受けるべきか」は実務でよく迷う論点で、のちほど詳しく触れます。
• 研究開発費: 新しい技術の研究や、将来の収益獲得が確実とはいえない段階の開発にかかる費用です。発生時に費用処理するのが原則で、ソフトウェア仮勘定には乗せません。自社利用システムの通常の発注では使う場面は限られますが、新規性の高い開発が混じる場合に区別が必要になります。

保守費・支払手数料・外注費・仮払消費税等（費用側・消費税の科目）

• 保守費・修繕費: 完成後のシステムを正常に使い続けるための費用です。月額保守料や軽微な不具合修正などがここに入ります。
• 支払手数料・外注費: 少額の作業委託や、資産に含めない性質の作業料を費用処理する際に使います。勘定科目名は自社の会計方針に合わせます。
• 仮払消費税等: 支払った消費税を記録する科目です。税抜経理を採用している場合、各支払いの消費税部分をこの科目で受けます。

これらの科目を頭に置いて、いよいよ支払いの順番に沿った具体的な仕訳例を見ていきましょう。

着手金・中間金を支払ったときの仕訳例

ここからが実務の本題です。まずは、検索者が最初に手を止める「着手金・中間金を払った時点で、何勘定の借方に立てるのか」に正面から答えます。以下では、システム開発を税抜 5,000,000 円（消費税 10% の 500,000 円）で発注し、着手金として 30%（税抜 1,500,000 円＋消費税 150,000 円）を支払ったケースを例にします。税抜経理を前提とします。

ソフトウェア仮勘定で集計する仕訳例

資産計上する方針が固まっていて、契約上も「この開発は完成後に自社の資産になる」ことがはっきりしている場合、着手金の支払い時点からソフトウェア仮勘定に集計していくのがシンプルです。

着手金 1,500,000 円（税抜）＋仮払消費税 150,000 円を支払ったときの仕訳は次のとおりです。

続いて中間金として 30%（税抜 1,500,000 円＋消費税 150,000 円）を支払ったときも、同じ要領でソフトウェア仮勘定に積み増します。

この時点で、ソフトウェア仮勘定の残高は 3,000,000 円（着手金 1,500,000 円＋中間金 1,500,000 円）に積み上がっています。完成時に、ここへ残金を加えた金額をソフトウェアへ振り替えることになります。

前払金で受けてから振り替える仕訳例と、どちらを選ぶか

一方で、着手金を「前払金」でいったん受けてから、後でソフトウェア仮勘定に振り替えるという考え方もあります。

これは「着手金の段階では、まだ役務の提供（開発作業）を受けておらず、純粋な前払いに過ぎない」という見方に基づきます。前払金で受ける場合、着手金 1,500,000 円（税抜）を支払ったときの仕訳は次のようになります。

その後、実際に開発作業が進み、開発費としての性質が固まった段階で、前払金をソフトウェア仮勘定へ振り替えます。

どちらを選ぶかは、契約内容と自社の会計方針によります。判断の目安は次のとおりです。

• 完成後に自社の資産になることが契約上はっきりしていて、開発が着実に進む見込み: 着手金の時点からソフトウェア仮勘定で集計するほうが、振替の手間が減りシンプルです。
• 着手金が純粋な前払いの性格が強い、開発の成否がまだ不確実、検収まで資産性を判断したい: いったん前払金で受け、開発が進んでから振り替えるほうが慎重で説明もしやすくなります。

迷ったときは、後者（前払金で受ける）のほうが保守的で、税務上も説明しやすい場面が多くなります。自社の会計方針として「着手金はどちらで処理するか」をあらかじめ顧問税理士と決めておくと、毎回迷わずに済みます。

着手金・中間金にかかる消費税（仮払消費税等）の処理

仕訳を切るうえで避けて通れないのが消費税です。ここは認識のタイミングを誤りやすいので、考え方を押さえておきましょう。

消費税の仕入税額控除は、原則として「課税仕入れを行った日」、つまり役務の提供を受けた日の属する課税期間で行います（国税庁 No.6483 建設仮勘定の仕入税額控除の時期の考え方が参考になります）。

ここで注意したいのが、着手金を「前払金」で受けた場合です。前払金は、まだ役務の提供を受けていない段階の支払いなので、その時点では原則として仕入税額控除の対象になりません。前払金を支払った時点では消費税を計上せず、実際に役務の提供を受けた（開発が行われた）タイミングで仕入税額控除を行う、という整理になります。

一方、着手金の時点で開発作業が始まっており、その分の役務提供を受けていると見られる場合は、その支払いに対応する消費税を仕入税額控除の対象にできます。上の「ソフトウェア仮勘定で集計する仕訳例」で仮払消費税を同時に計上しているのは、この考え方によるものです。

消費税の認識タイミングは、契約形態や役務提供の実態によって判断が分かれるデリケートな論点です。とくに前払金で受ける場合の控除時期は、自己判断せず顧問税理士に確認することをおすすめします。

完成・検収時にソフトウェアへ振り替える仕訳例

多くの読者が最も迷うのが、この「完成・検収時の振替」です。ここを乗り越えれば、システム開発費の仕訳の山場は越えたといえます。引き続き、税抜 5,000,000 円の開発で、着手金・中間金として合計 3,000,000 円をソフトウェア仮勘定に集計済み、というケースで見ていきます。

検収後の残金支払いの仕訳例

システムが完成し、検収が完了して、残金 40%（税抜 2,000,000 円＋消費税 200,000 円）を支払ったとします。この残金も、それまでと同じくソフトウェア仮勘定に積み上げます。

この仕訳を切った時点で、ソフトウェア仮勘定の残高は、着手金 1,500,000 円＋中間金 1,500,000 円＋残金 2,000,000 円＝ 5,000,000 円 になっています。これが、これから「ソフトウェア」へ振り替える元の金額です。

ソフトウェア仮勘定からソフトウェアへの振替仕訳例

完成・検収が終わり、システムを事業で使い始められる状態になったら、ソフトウェア仮勘定にたまった金額を無形固定資産の「ソフトウェア」へ振り替えます。これが、この記事の核となる振替仕訳です。

振替前: ソフトウェア仮勘定の残高 5,000,000 円

振替仕訳:

この振替を切ると、ソフトウェア仮勘定の残高は 0 円になり、代わりにソフトウェア（無形固定資産）に 5,000,000 円が計上されます。以降は、このソフトウェア 5,000,000 円を耐用年数にわたって減価償却していくことになります。

ここで大切なのは、「完成したのにソフトウェア仮勘定のまま放置しない」ことです。仮勘定のままだと減価償却が始まらず、決算で資産区分を誤ることになります。検収・事業供用のタイミングで必ず振替仕訳を切る、と覚えておきましょう。

取得価額に含める費用・含めない費用と、事業供用日・償却開始の関係

ソフトウェアへ振り替える金額（取得価額）に、どこまでの費用を含めるかは迷いやすいポイントです。国税庁の解説によれば、自社で利用するソフトウェアの取得価額には「製作に要した原材料費・労務費・経費の額」に加えて「事業の用に供するために直接要した費用の額」が含まれ、導入時の設定作業や自社仕様への修正費用も取得価額に含まれるとされています（国税庁 No.5461 ソフトウエアの取得価額と耐用年数）。

実務的な目安は次のとおりです。

• 取得価額に含める（資産＝ソフトウェア仮勘定で集計する）: 要件定義、設計、開発（プログラミング）、テスト、導入時の設定や自社仕様への修正など、システムを使えるようにするために直接かかった費用。
• 取得価額に含めない（費用処理する）: 製作のために要した間接費のうち、製作原価のおおむね 3% 以内の少額なもの、研究開発費に該当するもの、製作の仕損じによる費用などは取得価額に算入しないことができるとされています。また、一般的に資産性が乏しいと判断される操作研修費や、運用が始まってからのデータ保守などは費用処理することが多くなります。

含める・含めないの線引きは、請求書の内訳と実態に照らして判断する必要があり、迷う場合は顧問税理士に内訳を見てもらうのが確実です。

なお、減価償却を始めるのは「事業の用に供した日（事業供用日）」からです。検収が終わっても実際に使い始めていなければ償却は始まりません。逆に、使い始めたのに振替を忘れていると償却の開始が遅れます。振替＝事業供用のタイミングとして処理するのが、漏れを防ぐコツです。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

保守費・少額の支払いを費用で仕訳する例

開発（資産）と混同しやすいのが、保守・運用・少額の支払いです。「保守の請求は資産と混ぜていいのか」という迷いに、ここで答えます。結論からいえば、保守費は原則として資産とは別建てで費用処理します。

月額保守料・軽微な改修の費用仕訳例

システムが完成した後の月額保守料は、資産ではなく費用です。月額保守料 50,000 円（税抜）＋消費税 5,000 円を支払ったときの仕訳は次のとおりです。

ここで気をつけたいのが、改修の扱いです。

• 軽微な不具合修正・現状維持のための改修: 費用処理します（保守費・修繕費など）。
• 新しい機能の追加など、システムの価値を高める改修: 資産になり得ます。新機能を作る支出は、最初の開発と同じくソフトウェア仮勘定で集計し、完成後にソフトウェアへ振り替える対象になります。

「保守」という名目でも、中身が機能追加であれば資産処理が必要になる場合があります。請求書の作業内容まで見て判断することが大切です。

少額（一括償却・少額減価償却資産の特例）の費用仕訳例

ソフトウェアでも、取得価額が一定金額未満であれば、資産計上せずに費用処理できる制度があります。

• 取得価額 10 万円未満: 全額をその年度の費用に計上できます。
• 取得価額 10 万円以上 20 万円未満: 一括償却資産として、3 年間で均等に償却する方法を選べます。
• 取得価額 10 万円以上で、中小企業者等の少額減価償却資産の特例を使う場合: 取得価額を全額その年度の費用にできます。なお、この特例の対象となる取得価額の上限は、令和8年（2026年）4月1日以後に取得する資産について 40 万円未満 に拡大されました（それ以前に取得した資産は 30 万円未満）。年間の合計額には上限（300 万円）があります（国税庁 No.5408 中小企業者等の少額減価償却資産の取得価額の損金算入の特例、中小企業庁 少額減価償却資産の特例）。

たとえば、中小企業者等が取得価額 250,000 円（税抜）のソフトウェアを 2026 年 4 月以降に取得し、少額減価償却資産の特例で全額費用処理する場合の仕訳は次のとおりです。

なお、この特例を使うには青色申告法人であることなどの要件があり、適用には所定の明細書の添付が必要です。適用できるかどうかは要件を確認のうえ、顧問税理士に相談してください。

開発費と保守費が混在する請求書の振り分け仕訳例

実務でやっかいなのが、1 枚の請求書に開発（資産）と保守（費用）が混ざっているケースです。この場合、請求書の行項目ごとに、資産と費用へ振り分けて仕訳します。

たとえば、請求書に「機能追加開発 800,000 円（税抜）」と「月額保守料 50,000 円（税抜）」が並んでいて、合計 850,000 円＋消費税 85,000 円を支払ったとします。このときは次のように振り分けます。

混在請求を「全額まとめてソフトウェア仮勘定」にしたり、逆に「全額まとめて保守費」にしたりするのは、よくある誤りです。発注の段階で、システム開発会社に「開発分と保守分を分けて請求してほしい」と依頼しておくと、こうした振り分けの手間が大きく減ります。

減価償却の仕訳｜耐用年数と毎期の償却仕訳

ソフトウェアへ振り替えたら、そこで終わりではありません。資産計上したソフトウェアは、毎期、減価償却していきます。「決算をやり直したくない」という不安に応えるためにも、期をまたいだ処理まで見通しておきましょう。

耐用年数（自社利用5年）と定額法・初年度の月割償却仕訳例

ソフトウェアの耐用年数は、用途によって次のように定められています（国税庁 No.5461 ソフトウエアの取得価額と耐用年数）。

• 自社利用など（その他のもの）: 5 年
• 複写して販売するための原本・研究開発用: 3 年

自社の業務システムは、多くの場合「自社利用」に該当し、耐用年数 5 年・定額法で償却します。先ほどの例（取得価額 5,000,000 円）を、期首に事業供用したとして 1 年分まるごと償却する場合、年間の償却額は 5,000,000 円 ÷ 5 年 ＝ 1,000,000 円です。

無形固定資産であるソフトウェアの償却は、貸方を直接「ソフトウェア」とする直接法が一般的です（有形固定資産のように「減価償却累計額」を使う間接法を採用する場合もあります）。

初年度は、事業供用日から決算日までの月数で月割計算するのが原則です。たとえば、決算が 3 月の会社で、10 月から事業供用を開始した場合、初年度は 6 か月分（10 月〜翌 3 月）だけ償却します。

初年度の償却額 ＝ 1,000,000 円 × 6 か月 ÷ 12 か月 ＝ 500,000 円

償却開始のタイミング（事業供用日）と会計上の耐用年数短縮

償却を始めるのは、検収日ではなく事業の用に供した日（事業供用日）です。検収が終わっても、テスト運用のまま本稼働していない段階では、まだ事業供用していないと判断されることがあります。いつから本格的に使い始めたかを記録しておくと、償却開始時期の説明がしやすくなります。

また、税務上の耐用年数は上記のとおりですが、会計上は、システムの陳腐化が早いと見込まれる場合に、より短い耐用年数で償却する企業もあります。会計上の耐用年数を税務と変える場合は、税務申告で調整が必要になるため、自己判断せず顧問税理士に相談してください。

使われなくなったシステムの除却仕訳例

システムを廃止して使わなくなった場合は、帳簿に残っている未償却の金額（帳簿価額）を除却損として処理します。たとえば、帳簿価額 1,500,000 円のソフトウェアを除却する場合の仕訳は次のとおりです。

新しいシステムに切り替えるときに、古いシステムの除却を忘れていると、使っていない資産が帳簿に残り続けてしまいます。リプレースの際は、旧システムの除却処理も忘れずに行いましょう。

よくある仕訳の誤りと修正仕訳

最後に、システム開発費の仕訳で起こりやすい誤りと、その修正仕訳を見ておきます。「仕訳を間違えて決算をやり直したくない」という不安に対しては、先に典型的な誤りの型を知っておくのが一番の対策になります。

資産にすべき開発費を一括費用化した誤りと修正仕訳

最も多いのが、資産計上すべき開発費を、支払い時に全額「外注費」や「支払手数料」として一括で費用にしてしまう誤りです。

たとえば、本来ソフトウェア仮勘定に集計すべき開発費 1,500,000 円（税抜）を、誤って次のように費用処理してしまったとします。

誤った仕訳:

同じ会計期間内に誤りに気づいた場合は、費用を取り消して資産へ振り替える修正仕訳を切ります。

修正仕訳:

この修正で、誤って計上した外注費が打ち消され、本来あるべきソフトウェア仮勘定に振り替わります。

完成済みなのに仮勘定のまま／保守名目の機能追加を費用化した誤りと修正仕訳

次に多いのが、次の2つです。

①完成・事業供用済みなのに、ソフトウェア仮勘定のまま放置している

完成して使い始めているのに振替を忘れていると、減価償却が始まらず、資産区分も誤ったままになります。気づいた時点で振替仕訳を切ります（残高 5,000,000 円の例）。

加えて、本来償却を始めているべき期間があれば、その分の減価償却費も併せて計上する必要があります（さかのぼる範囲の処理は、決算をまたぐかどうかで対応が変わるため、税理士に確認してください）。

②機能追加を伴う改修を、保守費（費用）で処理してしまった

「保守」名目でも中身が新機能の追加であれば、資産になり得ます。誤って保守費で処理した場合の修正仕訳は次のとおりです（機能追加分 800,000 円の例）。

決算をまたいで誤りに気づいた場合は、自社だけで修正仕訳を切るのではなく、修正申告や更正の請求が必要になることがあります。過年度の処理に関わる修正は影響が大きいため、必ず顧問税理士・公認会計士に相談したうえで対応してください。

まとめ｜支払いタイミング別の仕訳早見表と、税理士確認の前にやること

ここまで見てきた仕訳を、支払いのタイミング別に一覧でまとめます。自社の取引を当てはめて、伝票を切る際の早見表として使ってください。

仕訳の叩き台ができたら、それで完成とせず、顧問税理士・公認会計士に確認してもらうことをおすすめします。本記事で示したのは一般的な考え方であり、実際の処理は契約内容・会計方針・最新の税制によって変わるためです。とくに消費税の認識タイミング、取得価額の線引き、過年度の修正は判断が分かれやすい論点です。

最後に、これから発注する場合の実務的なヒントを1つ。仕訳がスムーズになるかどうかは、実は発注の段階でほぼ決まります。システム開発会社に、次の2点を依頼しておくと、その後の経理処理が格段に楽になります。

• 着手金・中間金・残金の内訳を、契約書・請求書で明確にしてもらう: どの支払いがどのフェーズに対応するかが見えると、仕訳のタイミングを迷わずに済みます。
• 開発分と保守分を、請求書で分けて記載してもらう: 資産と費用の振り分けが、請求書を見るだけでできるようになります。

発注の交渉時に内訳と請求の出し方まで相談しておくこと——それが、後々の決算やり直しを防ぐ、いちばん確実な備えになります。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。