工事台帳システムとクラウド会計freeeへの二重入力

工事台帳は工事請負事業者にとって欠かすことのできない管理簿になります。工事現場で管理している実行予算書（工事台帳）への入力と、経理が入力しているクラウド会計freeeへの入力を行うのです。どうして工事台帳とクラウド会計freeeのどちらも同じような内容なのに何度も入力しないといけないのか？こんなことを思われた方は多くいらっしゃるのではないでしょうか。また工事台帳システムとクラウド会計freeeの互いのシステムが連動していないために、数字が合わない場合は互いのシステムの内容をチェックしなければならず多くのチェック作業が発生してしまいます。工事台帳システムとクラウド会計freee互いのシステムが連動していれば楽になるのに、と思いながらもどうしたらシステムが連動するのか、解決の糸口が見つけられず、長い間頭を悩ませられている問題です。

なぜ二重入力が起きてしまうのでしょうか。

問題が起きる原因を探るには、実行予算に関する業務の流れを確認する必要があります。

＜実行予算の流れ＞

①実行予算を組む
②発注をする
③発注した工事に対して査定をする
④支払をする

※見積書作成のため受注前に実行予算を組むケースも多いと思いますが、今回は受注したあと、着工前に実行予算を組む想定で話を進めます。

おおまかな流れとしては上記の流れで行われているのではないでしょうか。③の査定をしていない会社ですと、請求書が来た内容を工事担当者に確認してOKであれば、④の支払業務を行うといった簡便的なやり方を行っているケースもあると思います。実務であれば簡便的なやり方の方が多いのが実情でしょうか。

この流れを見ただけでも多くの人やシステムが介在することになります。ここでわかり訳すするために各業務に対して誰がどのシステムを入力しているかという観点から記述していきます。（一般的な場合のみです）まず①の実行予算を組むですが、工事担当者が原価管理システムに入力します。次に②の発注をするですが、発注内容を工事担当者が原価管理システムに入力します。発注書が発行できるものが多いですが、そうでない場合は別のシステムで発行しなければなりません。③発注した工事に対して査定をするですが、2つの業務が存在します。工事担当者が原価管理システムに実績を入力する業務、経理がクラウド会計freeeに費用を入力する業務です。④支払いをするですが、経理が査定を行った内容と請求書等を突合してクラウド会計freeeで支払業務を行います。ただし支払業務が複雑な場合はクラウド会計freeeとは別のシステムで管理して支払業務を行っている場合もあると思います。

このように大まかな流れを見ただけでも、業務の流れが複雑で、手間の掛かる事であることが分かりましたでしょうか。こういった業務を一つ一つ整理しなくては業務効率の糸口を見つけることはできません。まずはここが「はじめの一歩」となります。この業務の整理ができた後の、次の一歩については次節以降を読み進めていただければと思います。

実行予算を組んだ段階での予算の原価は管理しているけど、工事が終わったあとの実績の原価が管理できていない。こういった状況になってしまっていないでしょうか？もしくは、工事毎に都度都度の実績管理ができていないので、決算を締めてみないと実績の粗利が分からないといった状況になってしまっていないでしょうか。こういった問題を抱えたまま業務を進めてしまうと、原価管理という面で大きなリスクを伴うことになります。リスクとしては大きく点あります。一つ目は予算と実績の比較ができないために工事が終わったあと検証ができないという点、二つ目は工事の途中で予算と実績に大きな乖離があった場合、そのシグナルが工事途中段階で見える化されないという点です。とくに後者については会社の業績に大きく影響しますので、この問題は是が非でも解決しておきたいものです。

なぜ予算は管理できているのに、実績が管理できなくなるのか。

これは実績を入力するタイミングが大きく影響しています。先ほどの実行予算の大まかな業務の流れをご覧ください。

＜実行予算の流れ＞

①実行予算を組む
②発注をする
③発注した工事に対して査定をする
④支払をする

本来であればこちらの流れで業務の流れが行われていると思います。この時に③発注した工事に対して査定をするという業務ですが、この時に発注に対しての査定が行われますので、多くの場合このタイミングで債務が確定します。要は実績が決定するわけです。この時必要な業務は工事担当者が原価管理システムに実績を入力する、経理担当者がクラウド会計freeeに費用を入力するといった2つの業務が必要になります。この2つの業務というのがミソで、会計業務は必須ですから必ず行われると思いますが、同じような業務を原価管理システムでも行わなければならないため、この時にやらなくなってしまうといったケースが多くあります。
また③の査定をしていない会社ですと、請求書が来た内容を工事担当者に確認してOKであれば、④の支払業務を行うといった簡便的なやり方を行っているため、なおさら工事担当者がその実績を原価管理システムに書き写すという業務が行われなくなってしまうというケースが多いようです。

こういったメカニズムで、「予算」の管理はできるのに「実績」の管理ができなくなってしまう、といった問題が生じているのです。

クラウド工事台帳とクラウド会計freeeのすすめ

上記の問題を解決する方法として、アイティーフィットではクラウド工事台帳とクラウド会計freeeによって、原価管理システムと会計システムの連携をご提案させて頂いております。システム連携により、クラウド工事台帳に実績を入力することによって、会計の仕訳が生成され、そのデータがクラウド会計freeeに連携されますので、重複する業務を減らすことが可能です。また実績管理が容易になりますので、工事途中であっても予算と実績の比較が容易にでき、また工事完成後の検証も行うことが出来ます。

発注管理で気を付けるべきこと

次に注意をしなくてはならない点が発注管理です。発注を行う場合、工事担当者もしくは購買を一元管理している場合は購買担当者となると思います。多くの場合は工事担当者でしょうか。発注を管理するうえで気を付けないといけないことは、発注残の管理です。実行予算に対して、これからまだ発注しなければならないのが発注残です。この発注残を管理しておかないと、予算に対して費用が超過しているのか否かを工事の途中段階の発注段階で把握することが出来なくなってしまいます。つまりは発注管理が出来なくなってしまうのです。工事担当者が現在発注しているものは予算から超過しているのか、いないのかが、発注段階で見える化されていなければ経営判断の指標としては不十分です。

発注管理を怠るとこんなケースが・・・

発注管理が行われていない場合にはこんなケースも考えられます。
決算月に案件をすべて締めて、利益が確定したかたと思った後に、業者から請求書がきて予想した利益を下回ってしまった。こういった経験はありませんでしょうか。

発注管理はクラウド工事台帳で解決！

こういった問題を解決するために、クラウド工事台帳では、予算の入力、発注の入力、発注書の発行などを一元管理しており、発注残の情報が見える化されています。また査定の情報や請求書の情報なども入れられますので、まだ査定が終わっていない発注や請求書が来ていない発注などを見ることも可能です。

会社の利益管理に関わる問題は経営判断に大きな影響を与える問題となりえます。発注管理を行い正しい経営判断に活かせるよう整備することが望まれます。

振替作業に関する問題

次にご紹介するのが振替作業に関する問題です。こちらについては、建設業の経理実務を行った方が経験することが多い問題です。

まずは費用の面からみていきましょう。通常まだ工事が完成していない状態で発生する費用に計上に関しては、2つのパターンで未成工事支出金の計上と振替を行っていると思います。

パターン①

一つ目のパターンは、①未完成時の費用を費用科目で計上し、期末段階でまだ未完成の場合は、その工事に関わる費用を未成工事支出金に振り返えます。その後完成した場合はその未成工事支出金の金額を完成工事原価に振り返るパターンです。

パターン②

二つ目のケースは、②未完成時の費用を未成工事支出金で一旦すべて計上して、完成した場合に、未成工事支出金を各費用科目に振替処理をするパターンです。

おそらく実務上では前者のパターン①を取られている場合が多いと思います。なぜなら、後者のパターン②に比べて非常に簡便であるからです。

パターン②のメリットとデメリット

パターン②の場合一旦未成工事支出金で計上しますので、わざわざ完成したときに費用科目別に振替処理を行わなければなりません。未成工事支出金の相手勘定科目をすべて振り返って振替伝票を作成する必要があるのです。これは大きな手間となります。しかしながら、②についてはメリットも存在します。それは月次試算表の損益が比較的正確に把握できます。なぜなら①の場合未完成時にも費用として計上されてしまいますので期中で大赤字となってしまうことが多いと思いますが、②の場合は未成工事支出金として資産計上されているため、費用計上されません。よって期中の試算表が比較的正確に把握できます。さらに、完成工事原価の詳細がきちんと費用科目ごとに把握できますので、原価管理をより詳細に記載できます。

パターン②のデメリットをクラウド工事管理とクラウド会計freeeで解決！

パターン②のケースを採用して人の手で行おうとすると、とても大変な作業となりますが、クラウド工事台帳とクラウド会計freeeによって、一発解決することが可能です。通常実行予算書には、費用の詳細が記載されています。その費用ごとに会計の費用科目を紐づけさせておくことで、完成時に振替伝票を自動で作成することが可能です。またその自動で作成された振替伝票をクラウド会計freeeに連携すれば一発で未成工事支出金の振替を行うことができます。

こういったクラウド連携の恩恵を利用することで高度な会計処理を行うことが可能となります。

クラウド工事台帳とクラウド会計freeeの可能性

ここまで様々な問題に対してクラウドの有効性を述べてきましたが、もっと広がるクラウド工事台帳とクラウド会計freeeの可能性について触れたいと思います。
クラウド会計freeeは、銀行口座明細をAPI経由で自動取込して、さらに、AIを使って消込のマッチングまで行ってくれます。
こういった機能を利用してクラウド工事台帳と連携することによって、実際に入出金があったかどうかの情報を持たせることが可能です。
つまり実行予算書の収益に対しての実際の入金状況や、費用に対しての実際の出金状況などを把握することが可能です。
これにより、経理に確認するまでもなく、工事担当者は入出金の状況をクラウド工事台帳で確認することが可能となります。

こういった機能をもつシステムを構築するためには、今まで多くのIT投資が必要でした。しかしながら現在は、多くのクラウドサービス台頭により、クラウド機能の恩恵を大いに活用することが可能です。賢くクラウドサービスを活用し、より高収益体質の企業を目指しましょう。

「在庫管理は、倉庫責任者に任せているから、システム化は必要ないかな？」

表面上は上記の通り、現場に任せれば何とかなるように思われがちですが、適正な在庫管理をしないことによるデメリットがあります。

• 倉庫責任者に聞かないと在庫が分からない。
• 第三者による判断がない。
• 突発的な欠品により、商品が用意できない。
• 過剰在庫によりスペースが確保できていない。
• 管理工数が削減できない。
• 正しい売上原価が計算できない為、利益が分からない。
• トラブル対応時に、商品のトレースができない。
• 会計システムへの適切な登録ができていない。
• 在庫管理システムはあるが、クラウド型ではないから外出先で見れない。

上記の中でも、適正な在庫管理を行わないことによって発生することが多い過少在庫、過剰在庫のデメリットは以下です。

■過少在庫によるデメリット

1. 販売機会の損失
2. 欠品によるクレーム

■過剰在庫によるデメリット

1. 在庫を維持する為の費用増（倉庫代、光熱費、人件費）
2. 商品の陳腐化（賞味期限、消費期限）による商品価値の低下
3. 資金繰りの悪化（回収までの期間増）によるキャッシュフローの減少

欠品による機会損失を防止する為には、現場以外の部門でもリアルタイムで在庫数を把握できる仕組みと、適正な発注をする必要があります。

前述の通り、クラウド在庫管理を導入せず、倉庫責任者に一存してしまうと、営業が確度の高い商談をしている時でも、都度倉庫責任者への問い合わせが必要となります。最悪の場合、連絡がつかず、在庫が把握できなかったが為に、商談が破綻してしまう可能性もあります。

クラウド在庫管理の導入による可視化が必要

改善するには、現場の人に一存せず、クラウド在庫管理の導入による数値化、可視化が必要となります。

また、肌感覚や勘、ノウハウに頼って発注を行うと、営業側の受注見込みとの差による販売機会の損失や、発注漏れにより過少在庫になってしまいます。

調達期間（リードタイム）や発注量、発注点、また営業側の受注状況等をクラウド販売管理やクラウド在庫管理で数値化して、管理を行う必要性があります。

尚、基本的な発注として、以下の2方式が挙げられます。

・定期発注
　発注時期に在庫数を把握し、必要数量を定期的に発注する。

・定量発注
　ある一定数量を下回ると発注する。

欠品を防止するため、（安全な）在庫数を把握し、発注を行うことが肝要となります。

一方で、過剰在庫とならないために、「3 適正在庫による在庫圧縮／保管費の削減」の観点が必要となります。

在庫圧縮並びに保管費の削減をする為には、倉庫内の整理、責任者の明確化と合わせて、商品の受注状況の把握（売れる商品と売れない商品の把握を含む。）や適正な理論在庫、実在庫の把握が必要となります。

「1 経験と勘による在庫管理」でも申し上げた通り、過剰在庫による影響は各種保管費が増えるだけでなく、商品の品質低下により適正価格で販売する事ができなくなり、商品入荷時の支払いから販売して入金されるまでの期間経過によるキャッシュフローの悪化まで起きてしまいます。

上記を改善するには、物理的な対策、体制・運用での把握と合わせて、クラウド在庫管理による在庫回転率の計算やクラウド販売管理との連携などを実装する方法があります。

尚、在庫の量を判断する指標として、在庫回転率が挙げられます。

在庫回転率（回） = 出庫金額（年間の売り上げ） ÷ 在庫金額（棚卸資産）＊１

＊１：（期首在庫＋期末在庫）/2

在庫回転率が低いものは現金化するまでに時間が掛かっているものと判断できる為、在庫回転率が低い商品の在庫数量を削減することにより、在庫圧縮／保管費の削減を実現することができます。

トレーサビリティとは

トレーサビリティとは、特定のロットの商品が、いつどこでどのようにしたのかを入荷、製造から納品、廃棄まで追跡できる仕組みを指します。

トレーサビリティの管理ができていないと、リコールなど万が一の事態が発生した際に、どのお客様に影響があるのか、原因はどこにあるのかといったことが迅速に対応できなくなってしまいます。
場合によっては、影響範囲が分からず、全ての商品を回収する必要があります。

トレーサビリティの実装

リスク回避と共に顧客満足度を向上する意味でも、クラウド在庫管理によるトレーサビリティの実装は必然と考えます。

トレーサビリティを実現する為には、以下2点による双方向からトレースする機能を備えたクラウド在庫管理の導入が必要となります。


・トレースフォワード
　製品自体に問題が発生した際、どこで問題が発生をしていたのか、原因はどこにあるのかといったものを特定する為に、製造段階まで遡ること。


・トレースバック
　製品の出荷後、製造物の元となるもの(パーツや原材料など)に問題がある事が分かった際、その元となるものが使われた製品を特定、回収すること。

また、ロット番号による記録、管理をしておく事により、上記トレーサビリティが円滑になり、また賞味期限の管理や先入れ先出しを行っている場合に、出荷先の特定が詳細かつ迅速に可能となります。

尚、適正なトレーサビリティを実現する大前提として、正確な検品作業が必須です。

クラウド販売管理と連動した上で、受注伝票から出荷指図書を生成し、出荷指図書に基づき、ピッキング(出荷処理)を行います。
また、発注伝票から入荷指図書を生成し、入荷指図書に基づき、ピッキング(入荷処理)を行います。

また、検品を行う際にはバーコードリーダーの導入、スキャン項目の精査、作業区分や動線の見直しなどを行う事により、作業効率化並びにミスの防止を行えます。

クラウド在庫管理で管理する在庫データは、クラウド販売管理との連動だけでなく、クラウド会計freeeとも関わります。
在庫の会計処理は思っている以上に複雑なので、定義や各種数値の集計・評価方法などを理解した上で、適正なクラウド在庫管理を導入しましょう。

会計上の在庫とは

会計上の在庫とは、主に以下の3つを指します。

1. 製品または商品
2. 仕掛品
3. 原材料

会計上の処理を行うには、前提条件として、これらの定義を理解した上で、各種マスタや在庫ステータスの管理をクラウド在庫管理で行う必要があります。

売上原価の原則的な算出方法

売上原価の原則的な算出方法は、以下の通りです。

売上原価 ＝ 期首商品棚卸高 ＋ 当期商品仕入高 － 期末商品棚卸高

期首並びに期末に棚卸結果を会計へ報告をするのが一般的ですが、プロジェクト単位での売上原価を正確に算出するには、入荷並びに出荷のタイミングで、プロジェクトと紐づけたデータを、クラウド在庫管理とクラウド会計freeeで連動する必要があります。

但し、上記運用を行うには、出荷をする度に仕分け処理を行う必要がある為、当機能を備えたクラウド在庫管理と、クラウド会計freeeへの連携を意識したシステム構築が必須となります。

顧客管理、名刺データ化、案件や引き合い管理、受注や売上や請求などの販売管理、財務会計、そして、勤怠や給与計算など、業務に役に立つクラウドサービスが続々と登場してきました。今までは、自社でデータベースサーバなどのハードウェアを設置したり、パッケージソフトをインストールしていましたが、その構築作業は不要となり、利用料を支払えばすぐにインターネット上で利用することができるようになります。
また、これらの業務系クラウドサービスは、他のクラウドサービスと連携できる機能も有しており、中にはプログラミング不要で、データ連携できるクラウドサービスもあります。

IT技術者の確保が難しい企業にとっては、こうしたクラウドサービスの利用は大きなメリットがあると言えます。

しかしながら、自社の業務をクラウドサービスで実現させるためには、複数の業務系クラウドサービスを利用することになります。顧客データや案件データ、売上データ、請求データ、入金データ、会計データをどのように、結び付けて業務系クラウドサービスを連携させれば良いのか、これが難しいのです。

例えば、クラウド型販売管理サービスに売上データを登録したとします。同時に会計クラウドに売掛の仕訳レコードが登録されます。売上に対して請求書を発行し、指定銀行口座に入金があったとします。営業マンは、入金あったことをいつも利用しているクラウド型販売管理で通知を受けたいと考えるし、経理部はクラウド会計でネットバンキングによる入金データを取得するでしょう。クラウド会計からクラウド型販売管理へ入金情報を連携すれば実現はできますが、入金が前月の未払い分と合算されていたら、どうでしょうか。売掛残高をクラウド型販売管理とクラウド会計の両方で管理することになり、データと機能が重複することなります。さらに、両クラウドでの残高突合も必要になり、業務も複雑になります。

クラウド型販売管理とクラウド会計の間での機能のすみわけ、そして、アナログで残る業務、これらをうまく設計する必要があるのです。

弊社のクラウド導入経験をもとに、クラウド型販売管理とクラウド会計を中心した、業務系クラウドサービス導入の勘所をまとめました。

業務系クラウドサービスをご検討中の企業様の一助になれば幸いです。
（随時、更新しております。）

※一般的な会計システムをこのWebサイトでは「クラウド会計」と記載しております。読み替えて、お読み頂いても結構です。

株式会社アイティーフィット　小沢広文

販売・請求管理kintoneアプリ「販売９」とfreee連携kintoneプラグイン

kintone販売・請求管理アプリ「販売９」アプリは、無料でお使い頂けます。
会計freeeへの連携も「freee連携kintone」プラグインを導入することで可能になります。

クラウド販売管理

クラウド会計連携

1-1 見積から入金の流れ

顧客登録→案件→見積→受注→納品→請求→入金→売掛消込

ごくごく、一般的な掛売の流れになります。
一直線に業務が進んでいく流れになりますので、簡単なように感じます。

しかし、実際には、営業部、業務部、経理部など、複数の部署や担当者がこの一連の流れに関わることになります。見積と受注は営業部、納品は業務部、請求と入金と売掛消込は経理部といったケースが多いかと思います。
例えば、経理部では、納品が完了した受注がどれで、どの受注を請求して良いのか、を正確に把握する必要があるのです。案件から見積、受注、納品、請求、入金、売掛消込のそれぞれの業務において、状況を共有することが必要になるのです。

ところで、それぞれの業務において重要なデータ項目となるのは、金額と数量と日付です。
特に日付については、受注日、発送日、納品日、検収日、請求日、支払期日、入金日など様々な日付があります。これらの日付の意味を先ほどの部署間もしくは会社全体で認識を一致させることが重要です。

日付の「意味」というのは、例えば、クラウド会計に登録する際の「売上計上日」はいつでしょうか？ということです。あなたの会社は、発送日ですか？納品日ですか？それとも検収日でしょうか。

物販の場合には、売上計上日は、出荷基準、引渡基準、検収基準などがあります。

この「売上計上日」について正確にお答え頂かないと、販売管理システムを構築することができないのです。請求のタイミングにも関係します。もちろん、仕訳データそして決算にも影響します。

これと反対に、仕入については下記の通りです。

仕入先登録→発注→入荷→検収→請求（される）→支払

こちらも、仕入計上のタイミングは、入荷基準、検収基準などがあります。

クラウド型販売管理とクラウド会計では、それぞれの日付の意味が重要になります。

日付以外にも、受注残や発注残の考え方も重要です。これらについては、後の章で取り上げます。

その場で販売（サービス提供）することで、売上が確定するケースです。店頭販売がこのケースですが、やや複雑なケースもあるのです。例えば出張修理サービスでは、修理作業費や提供部品を販売した場合で、後日、請求書発行にて請求を行う場合もあります。
この場合、見積や受注がその場で行われて、作業完了をもって売上が確定するのです。

売上 → 請求 → 入金 → 売掛消込

顧客マスタへの登録は行わず、1売上を1請求する流れになります。
前章のような一般的なクラウド型販売管理では、顧客マスタへの登録が必須になります。また、クラウド会計は、売掛を管理するために取引先として顧客マスタへの登録が必要になります。
しかし、いきなり売上する場合には、顧客登録の作業が業務負荷になったりするのです。
この場合、会計では取引先を売上に紐づけずに仕訳を行うなどの対応が必要になります。顧客情報はクラウド型販売管理側で保持することになります。なお、クラウド会計側では、仕訳データの摘要に顧客名や受注番号を付記することが多いようです。

このようにクラウド型販売管理とクラウド会計の導入においては、見積からスタートするケースか、売上からスタートするケースか、大きな違いがあるのです。

会計データ（仕訳）は、事後の世界。販売管理データは、現在過去未来。なのです。

例えば、クラウド会計への売上（収益）データの登録は、売上が確定した後になります。未来の日付で売上を登録するこはありません。なぜかというと、日本の会計基準では、収益（売上）は「実現主義」で認識するのが原則となっているからです。
受注した商品を出荷したことで会計の売上になります。「出荷した」は過去ですので、本日含めて過去日なのです。売上の確定をもって、クラウド会計に売上データを仕訳として登録することができるのです。（もちろん、クラウド会計でデータ入力制限が無い場合には、未来日で売上をデータ登録はできますが・・・）

クラウド型販売管理とクラウド会計の範囲は次のようになります。

〇：機能をサポート、およびデータ保持
△：最近のクラウド会計ではサポートしている場合が多い。

特に、受注の欄に注目して頂きたいのですが、受注が確定するとクラウド型販売管理では受注データを登録しますが、クラウド会計には何もデータを登録することはできません。
受注したけど、まだ、売り上がっていないためです。

「今月の売上はいくらになる？」の答えは、クラウド会計には無いのです。
経営者は今月売り上がる予定の受注金額を含めた売上額として認識したいのですが、
そのデータは、クラウド型販売管理にしか存在しないのです。しかも、すでに売上がった金額と今月末までの出荷予定（売上予定日）の受注金額を合計する必要があるのです。

売上の予実管理もクラウド会計では難しいのです。
月別の売上目標を設定したとします。これが予算になります。
予実管理の実績は、売り上がった金額になるのですが、先ほどのように、受注が確定して出荷日（売上予定日）が決まった金額も実績として集計される必要があります。これ以外にも、年間契約によって毎月売り上がる保守サービスなどを実績として積んでおきたいのです。

こうして見ると、クラウド会計は事後の世界であり、クラウド型販売管理は現在過去未来である言えます。

売り上がった金額を請求する。いたってシンプルな考え方なのですが、これが意外と難しいのです。

顧客マスタとして一元管理しない場合

顧客を一元管理しない場合には、顧客マスタを持たずに、請求先の住所や氏名は請求書データに保持します。この場合は、同じ人が複数回取引（売上）を行った場合には、同じ住所・氏名の請求書データが保存されていることになります。売上高は管理できますが、顧客分析ができなくなります。

顧客マスタで一元管理する場合

初回の取引で、新規に顧客マスタに登録します。相手が企業であれば与信を行うなど、顧客マスタの登録にはいくつかのステップが存在します。相手が個人であると、同姓同名の場合もあるので、識別できる情報を付加して顧客マスタに登録することになります。
顧客マスタに登録した後に、売上データを登録し、その後、請求書データを作成する流れになります。この場合には、売上データをシステムに登録する前に、顧客マスタに登録する必要がありますので、業務の流れに縛りが発生し、煩雑にもなります。よって、いきなり売上のケースでは、顧客マスタの設置は難しいのです。

以下は、顧客マスタで一元管理する場合になります。

締め請求

「月末締めで、翌月月初に請求書を発行し、月末に入金」といったケースです。

7月10日に売上が10万円、7月20日に売上が20万円発生したとします。7月の売上合計が30万円ですので、翌月の8月に30万円の請求書を発行し、8月末までに入金して頂くといった流れになります。
ここまでは単純なのですが、取引先毎に締め日が異なったらどうでしょうか。A社は月末締めで、B社は20日締め、といったことがあるのです。しかも、入金して頂く支払期日も、A社は締め日の翌月末、B社は締め日の翌々月末となると、会社ごとに、締め日と支払期日が異なるのです。極端なことを言うと、毎日どこかの取引先が締め日で処理をすることになります。しかし、通常は「ごとうび」（五十日）が基本で、毎月の5日、10日、15日、20日、25日を締め日としています。なお、30日を締め日とする指定はなく、「月末」として扱う場合が多いです。
支払期日も「当月」「翌月末」「翌々月末」など指定することになります。これを支払サイトを呼んでます。
クラウド型販売管理では、取引先マスタに設定された締め日や支払サイトを判定しながら、締め請求の処理を行うことになります。

前払いの請求書

手付金などがこれで、100万円の商品を販売する前に、手付金として20万円を請求する場合です。まだ商品を出荷していないので、20万円の売上が立っていない状態で請求するのです。単純に20万円の請求書を印刷すれば良い？と考えますが、売上情報をもとに請求書を作成するロジックになっているクラウド型販売管理やクラウド会計ではこれができないのです。特に最近はクラウド会計で請求書を発行できるようになっておりますが、前払いについては、仮の売上データを登録するなどの工夫が必要になるのです。
さらに、商品を出荷し売上が確定し、その後、請求書を発行する際には注意が必要です。というのは、すでに、20万円を頂いてますから80万円の請求になります。ところが、クラウド型販売管理のデータや会計上は、出荷日での売上が100万円になっておりますので、通常のロジックで請求データを作成すると、二重請求になってしまうのです。
請求書発行をシステム化するのは、かなり難しいことが、ご理解頂けますでしょうか。

そして、さらに難しさの話は続きます。

支社からの受注を本社に請求

全国に支社が存在する取引先企業の場合、支社から受注し、支社に出荷納品するケースがあります。取引先企業のご希望に応じて、支社への請求を本社にまとめて請求して欲しいというご要望を頂くこともあります。この場合、取引先マスタに親子関係を持たせる必要があります。本社を親、支社を子にして、子の売上を親に請求するという機能です。
売上をそのまま取引先に請求するのではなく、請求先が別途指定できるということです。

未払いを合算して請求

前回まで請求した金額で、未払いがある場合に、未払い金額を今回の請求に合算するケースです。これは、前回の請求タイミングから今回の請求タイミングの間に、支払（決済）が必ず存在する場合です。分かり易いのがクレジットカードや口座振替です。前回の請求金額が未払いになったことが確実に把握できることが前提になるのです。ですので、振込みでは合算請求は難しいものになります。取引先の担当者と事前に連絡して合意している場合は、合算請求できますが、運用が手間になりますし、混乱のもとになります。
未払いを合算するのは、かなり難しい業務になりますので、月毎に請求して、請求書の単位に未払いの対応（入金フォローなど）を行うのが良いでしょう。

聞きなれない言葉かと思います。分かり易いように、私たちが定義した言葉ですので、ご安心ください。でも、この２つをきちんと識別することが重要なのです。

単月売上は、今までお話ししましたように、商品の出荷日で売上を計上する場合です。これに対して、1年間の役務（サービス）を提供する場合は、提供期間中の各月で売上を計上する必要があります。これを私たちは期間売上と呼んでいます。例えば、年間12万円のクラウド利用サービスを提供するとします。期間中は、毎月1万円を売上計上する必要があるのです。クラウド型販売管理は、単月売上か期間売上かを識別する必要があるのです。

さらに、クラウド会計に毎月の売上を計上する必要があります。1年間の契約を受注した時点で、12ヶ月先までの各月の売上が見込まれるのですが、クラウド会計は「事後の世界」ですから、未来の売上を受注のタイミングで計上することは、お勧めしません。
この場合は、クラウド型販売管理で、毎月の締めの時点で、売上データをクラウド会計に登録するという流れになります。

特にIT企業さんは、システム初期開発は単月売上ですし、導入後のシステム保守は期間売上になりますので、受注件数が多いアプリ開発業者さんは、それなりに複雑な請求業務を行うことになります。（弊社もそうなんです。）

さらにさらに、請求のタイミングいつでしょうか？。

• (A)年払いの前払い
• (B)月単位の前払い
• (C)月単位の後払い

の3つのケースがあります。（年払いの後払いは考えられません。）

さらにさらにさらに、先ほどの締め日請求や本社へのまとめ請求などが絡んできますので、本当に請求って悩ましいのです。
 

入金消込は、経理部門の仕事であると考えている人も多いと思います。銀行口座の情報を参照できるのは、経理部門に限定されていたりするので、そう考えても無理はないでしょう。

しかし、入金があったことを営業担当も知りたいのです。お得意様に直接お会いする機会が多いのは営業マンです。お会いしたときには、「ご入金ありがとうございます。」の一言は早めにお伝えしたいでしょう。入金消込は、クラウド会計で行われるのが通例です。最近のクラウド会計（freeeさんやMFさんなど）は、銀行口座明細をAPI経由で自動取込して、さらに、AIを使って消込のマッチングまで行ってくれます。
しかし、営業マンはクラウド会計を利用する権限が無かったりしますので、入金情報を知ることができません。多くの営業マンは、経理部門に都度問合せをするなど行っているようです。

これを解決するためには、クラウド会計側で入金消込を行った情報をクラウド型販売管理側に戻せば良いのです。システム間の連携になるので難しい部分もありますが、クラウド型販売管理の売上データに該当する入金情報をクラウド会計側からクラウド型販売管理側に反映または、クラウド型販売管理側から取得すれば良いのです。

ただし、業務上の観点からして難しい点もあります。それは、取引先から振り込まれた金額が、複数の請求の合算であったり、または、振込手数料が差引かれている場合です。売上金額と入金金額が完全一致しないのです。その場合は、クラウド会計側で、入金金額を複数の売上に割り振ったり、振込み手数料を「支払手数料」として計上するなど、一つ一つの売上データを消し込む作業が必要になります。
これが、かなり面倒なのですが、最近のクラウド会計（特にfreee）では、AIを駆使して自動マッチングを行ってくれます。これは、ほんとうに嬉しい機能です。（弊社でも利用しております。）
クラウド会計側で、個々の売上データに対する消込を行うことにより、クラウド型販売管理側で保持している売上データに消込情報を反映できるようになるのです。

このように、クラウド型販売管理とクラウド会計がクラウド間で連携することで、営業マンは「ご入金ありがとうございます。」を言えるようになり、顧客満足度の向上につながるのです。

会計freeeからkintone販売管理への入金消込機能はこちらをご覧ください。

取引先の情報が最初に登録するのはクラウド型販売管理であり、その後、クラウド会計に登録する流れになることは、一般的に想像がつくことかと思います。クラウド型販売管理では案件登録する前に、取引先（顧客）のマスタ登録を行います。与信などを行って、社内承認を得るなどのワークフローが存在する場合もあります。その後、受注し売上が確定したタイミングでクラウド会計に売上データを登録する場合、クラウド会計側で事前に取引先を登録しておく必要あります。売上データ、つまり仕訳データに取引先コードを指定する必要があります。クラウド型販売管理側から売上データをクラウド会計に連携する場合には、クラウド会計で管理されている取引先コードを指定してあげる必要があります。

ところが、取引先の登録タイミングはクラウド型販売管理が先ですから、クラウド会計で取引先を登録し、かつ取引先コードが付与され、これをクラウド型販売管理側のマスタに反映させる必要があります。

クラウド型販売管理 → (1)処理 → クラウド会計 → (2)処理 → クラウド型販売管理

の連携になります。(1)はクラウド会計への新規登録で、付与された取引先コードを(2)の処理でクラウド型販売管理の取引先マスタを更新する必要があります。システム的なことを言うと、クラウド型販売管理の取引先マスタの更新キーが必要になるのです。（処理が煩雑になるのです。）

そなると、クラウド型販売管理側で取引先を登録するのと同時に、クラウド会計側でも取引先を登録してしまえば良いのでは？と考えるかもしれません。しかし、クラウド会計は「事後の世界」ですから、受注しなかった取引先をクラウド会計にマスタ登録をしたくないのです。せめて、受注が確定した段階で、クラウド会計に取引先を登録するという考えになるのです。

クラウド会計（freee）では、取引先登録のAPIが提供されていますので、クラウド型販売管理側の自由なタイミングでAPI経由で取引先を登録することができます。もちろん1回のAPI処理で、取引先コード(ID)も取得できますので、その後の売上データ登録で利用することができます。

取引先マスタの連携も、実は奥が深いのです。

クラウド型販売管理のうち個別受注型に関して記載しております。例えば、IT企業のアプリ開発会社であれば、顧客のご要望に応じてアプリの仕様がことなりますので、見積してから受注し、受注後も開発プロジェクトがスタートし、開発を行ったアプリを納品して、顧客にて検収して頂くことになります。見積、受注、納品、検収、売上の流れになります。また、納品までには外注会社からのデザイン画像を受け入れる場合もあります。よって、受注残や発注残をきちんと管理する必要があるのです。

一方で一般消費者を対象に商品を販売するECサイト（ストアサイトやショッピングサイトとも呼ばれてます）は、ほぼシステムで自動処理されるのが通常です。クラウド型販売管理としてはECサイトで購入決定の受注から始まることになります。そして、商品を発送することで売上が立ちます。もちろん、商品の在庫がある前提で受注しますので、受注に対する発注残という考え方はないのです。（仕入に対する発注残の管理はあります。）

発注残とは、自社の商品サービス等の仕入先への発注について、未だ自社に納品されていない発注のことを言います。例えば、仕入単価70円のA商品を数量10個で発注したとします。このとき、発注残は、数量10個（700円）になります。その後、仕入先の都合により、7個が分納されたとします。このときの発注残は、数量3個（210円）になります。そして、発注残の数量3個が納品されれば、発注残は0になり、１つの発注に対して仕入が完了したことになります。
つまり、発注残は、仕入先からの納品の進捗状況を管理することができるのです。

なお、納品日と検収日を分けて発注を管理することもあります。納品後に自社での検収作業があり、検収基準で仕入計上する場合です。この場合、発注残は納品日で消えますが、検収残として管理する必要が出てくるのです。発注残を検収日まで含めるか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があります。

※「検収」という言葉は受注にも使いますので、仕入検収おちう言葉を使うことをお勧め致します。

なお、クラウド型販売管理としては、仕入先を社内部門として位置付けることにより内作の管理に利用することもあります。

クラウド型販売管理の発注残は、仕入先単位、発注単位に発注残を一覧で参照したり、発注残のある仕入先リストや発注一覧を表示することができます。仕入先からの問い合わせ対応に役立つことになります。

個別受注型では、基本的に在庫をもたず、1つの受注について都度仕入を行ったり、内作により商品サービスを提供するケースです。複数の仕入先が関係する場合もあり、1つの受注についてリードタイムが異なる発注をそれぞれの仕入先に行うことになり、業務管理が煩雑になります。

1つの受注について、この受注から発生する複数の発注を関連付けて管理できることがクラウド型販売管理に求められます。
例えば、受注一覧において受注残が見れることは当然ですが、同時に発注残もこの受注一覧に表示されるというものです。もちろん、１つの受注の参照画面でも、発注残を確認できるということです。

これにより、発注残が0になった受注は、仕入が完了しているので顧客への納品が可能であることが分かります。仕入担当と営業担当が分かれている企業の場合には、このような受注残と発注残の一元管理がとても重要な役割になります。

個別受注型では、受注残と発注残を一元管理できることが求められるのです。

請求することは、企業にとってはとても慎重になる業務です。二重請求はもっての外であり、請求漏れも企業の信頼を損ないます。皆さまの会社では、どのようなルールで請求業務を行っておりますか？

個別受注型では、納品あるいは受注検収がされたものを請求するというのが基本ルールになります。
クラウド型販売管理では、受注残が0になったタイミングで請求が可能になるというロジックになります。請求可能になった状態から実際に請求書を発行した際には、その受注について請求済みにする必要があります。そうすることで、二重請求を防ぐことができます。

聞きなれない言葉かもしれませんが、請求残という考え方があります。
10個の受注を受けて、その後に納品まで行ったとします。受注残は0になりますが、同時に請求残を10個とするのです。そして、請求書を発行した際には、請求残を0にするという考え方です。受注残、発注残と同様にクラウド型販売管理では、請求残のロジックを実装することができるのです。受注一覧画面では、受注残、発注残と請求残を同時に参照することができますので、受注から請求完了までを一つの画面で確認することが可能となります。

請求残の考え方を業務に組み込むことで、請求漏れや二重請求を防ぐことができるのです。
自社の請求関連業務を今一度見直ししてみてはいかがでしょうか。

請求書を発行したあとは、入金を待つことになります。
売掛つまり売掛金とは、「信用取引にて商品サービスを提供した代金を受け取る権利（およびその金額）」を言います。
クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを提供した」は、納品あるいは受注検収がされた日に、販売代金を売掛金にプラスします。
「受け取り権利」が消滅するのは、支払があった日、銀行口座に入金があった日に、入金額を売掛金からマイナスします。

こうしてみると簡単なロジックなのですが、実際にはもう少し複雑なのです。
売掛金は、取引先毎に管理するのが基本です。クラウド会計などの売掛金リストは、取引先単位でかつ月別の集計表で表示されるのが一般的です。さらに、商品サービスを提供した単位（これを取引と言います）、請求書を発行した単位に、入金を管理できることが求められます。これを入金消込と呼んでます。

請求書は、複数の取引を請求明細としてまとめて1つの請求書として発行することがあります。取引は日付が異なる場合があります。例えば、前月1日から末日までの取引をまとめて1つの請求書として発行するケースです。
前月10日に1万円、前月20日に2万円の取引があったとすると、請求書の請求額は3万円になります。その後、3万円の入金があったとすると、前月10日と20日の取引にこの3万円を割り当てて消し込みを行うと同時に、発行した請求書についても消し込むことになります。そして、売掛金をマイナスします。

売掛金の消し込みは、システム観点からしても意外と複雑なロジックになりますが、顧客や取引先との信頼関係に直結することですので、とても慎重に行う必要があります。

今どきのクラウド会計では、AIを駆使して入金消込を自動で行ってくれる会計システムもあります。お勧めなのが、会計freeeです。会計とう領域であるものの販売管理に近い「取引」という考え方を取り入れ、かつ、請求書を作成かつ郵送してくれます。銀行口座ともネット接続し、AIを駆使して入金消込も自動で行ってくれるのです。会計freeeは一度、お試しする価値はあります。

弊社では、kintoneと会計freeeを連携させるプラグインをご提供しております。業務効率化のお役に立てれば何よりです。

買掛は、売掛と同様に考えれば良いのですが、大きな違いとしては、支払を行い買掛金を消し込むことです。一般的に支払は、実際の振込日の数日前に行います。買掛金の消し込みは、実際に支払った日に消滅します。つまり、支払操作を行った日と買掛金が消滅する日にタイムラグがあり、支払操作を行ったことを記録しておき、二重振込等の間違いを起こさないようにシステムでロジックを組む必要があるのです。

そもそも、買掛金とは、「掛け取引によって、商品サービスを購入した代金を支払う義務（およびその金額）」を言います。

クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを購入」は、仕入の商品サービスが納品された、または検収した日に、仕入金額を買掛金にプラスします。
「代金を支払う義務」が消滅するのは、支払った日に、仕入金額を買掛金からマイナスします。

単純なロジックではありますが、この買掛金のプラスとマイナスの間には、請求書を受け取る、請求金額を確認する、支払操作をするという業務があります。これらの業務が煩雑な作業になっているのです。

まず、請求書を受け取り、請求金を確認するという業務では、仕入をした代金をいつ支払うのか？が問題になります。例えば、仕入を行った月の翌々月末払いのケースです。この場合は、今月末日に支払うのは、前々月の仕入金額の合計になります。この金額には、前月の仕入は含みません。でも、買掛金としての今現在の残高は前月分も含まれますので、注意が必要です。
これを管理するために、支払期日が必要になるのです。商品サービスを仕入れ、または検収した日を基準に、翌々月末など仕入先毎に異なる支払サイトに従って、支払期日を算出するのです。こうしておくことで、今月に支払いするべき金額を支払期日をもとに合計することができるのです。
仕入先から受領した請求書が、クラウド型販売管理やクラウド会計で計算した支払するべき金額と一致することで、請求書の確認できるようになるのです。

そして、次は支払です。クラウド会計を利用すると、支払期日で合計した金額をもとに、銀行振込ファイル（総合振込ファイル）を作成してくれます。これをオンラインバンキングで振込ファイルをアップロードすることで支払操作が完了します。しかし、注意が必要です。
オンラインバンキングで振込ファイルをアップロードした後、実際に振込みされるのは、数日後です。では、買掛金はいつ消し込むべきでしょうか？という疑問がでてきます。

• （１）クラウド会計で振込ファイルを出力したタイミング
• （２）実際に振込が完了した後の銀行明細をクラウド会計に取込んだタイミング

（１）では、未来の振込予定日に支払したことにして、買掛金を消し込むことになります。もし、振込が失敗したらどうなるのか？と懸念されます。（実際は手補正になります。）
（２）は、振込した事実に基づき買掛金を消し込みますので、振込み失敗の場合も対応が可能なのですが、（２）のタイミングまで買掛金が残っているので、振込ファイルを誤って二重作成してしまうことが懸念されます。この場合は、特に承認申請フローなどの業務ルールをきちんと作成しておく必要があります。

（１）と（２）は、利便性や業務フローの構築など、一長一短があります。どちらのケースでシステム化を行うかは、自社の業務レベルに合わせて検討されることをお勧め致します。

なお、クラウド会計の会計freeeでは、（１）と（２）のどちらでも対応が可能です。

＜目次＞

※今後掲載予定の章を含めて目次としております。リンクがある章が公開中になります。

はじめに

１．クラウド販売管理とクラウド会計

1-1 見積から入金の流れ

1-2 もう一つの流れ「いきなり売上」

1-3 クラウド会計の範囲と限界

1-4 簡単なようで難しい「請求」業務

1-5 単月売上と期間売上

1-6 入金消込と営業担当

1-7 クラウド販売管理とクラウド会計間での取引先マスタ連携

２．クラウド型販売管理（個別受注型）

2-1 受注残とは

2-2 発注残とは

2-3 受注残と発注残の関係

2-4 何を根拠に、請求している？

2-5 売掛を管理できている？

2-6 買掛金から振込みファイル（全銀ファイル）を作成

３．なぜエクセルを使うのか、なぜエクセルはダメなのか

3-1 なぜ、エクセルを使うのか

3-2 なぜ、エクセルはダメなのか

４．しっかりとした企業は、ワークフロー（申請承認）を導入している。

4-1 まずは、取引先の与信

4-2 受注、仕入の承認

4-3 経費の申請（事前）と清算（事後）

５．まだ丸投げですか？、記帳は難しくない　～　今どきのクラウド会計freee

5-1 単式ライクな取引入力、自動仕分け

5-2 請求書も作れる、郵送までしてくれる

5-3 銀行口座と連携できる

5-4 仕訳もAIで推測

5-5 クラウドだから、税理士さんと共有できる

６．売上、仕入の計上

6-1 1年間の保守サービス料を開始前に請求している

6-2 建設業は必須の「未成工事支出金」

７．在庫の話し

８．IT導入は何から始める？失敗しないシステム導入とは

8-1 だれでも言う「使ってみないと、わからない。」＆「自社に合ったシステムが欲しい。」これって、矛盾してない？

8-2 出来合いのアプリをまずは、無料で使ってみる

8-3 サイボウズ　kintoneは何が良いのか

8-4 無料で使える「販売９」

8-5 例えば、こんなのはカスタマイズになる

９．まだまだある、ITで業務効率アップ。

9-1 勤怠管理とプロジェクト原価

9-2 契約締結もクラウドで出来る。しかも、印紙不要！

9-3 みんなEDIでらくらく（中小企業共通EDI、全銀EDI【ZEDI】）

１０．オールクラウドで作る業務システム

10-1 いろんなクラウドサービスのご紹介

10-2 どうやってつなげる？APIがあるさ！

10-3 自社の業務データを整理して、クラウドを当てはめてみる。