はじめに

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

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

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

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

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

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

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

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

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

 

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

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

投稿者:systemkanri 投稿日時:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

投稿者:systemkanri 投稿日時:

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

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


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


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

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

 

投稿者:systemkanri 投稿日時:

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

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

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

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

 

案件

見積

受注

納品

売上

請求

入金

消込

クラウド型販売管理

クラウド会計

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

 

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

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

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

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

 

投稿者:systemkanri 投稿日時:

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

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

 

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

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

 

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

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

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

 

締め請求

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

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万円になっておりますので、通常のロジックで請求データを作成すると、二重請求になってしまうのです。
請求書発行をシステム化するのは、かなり難しいことが、ご理解頂けますでしょうか。

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

 

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

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

 

未払いを合算して請求

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

 

投稿者:systemkanri 投稿日時:

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

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

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

 

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

 

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

 

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

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

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

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

投稿者:systemkanri 投稿日時:

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

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

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

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

 

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

 

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

 

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

 

投稿者:systemkanri 投稿日時:

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

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

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


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


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

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

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

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

 

投稿者:systemkanri 投稿日時:

2 クラウド型販売管理(個別受注型)

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

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

 

投稿者:systemkanri 投稿日時:

2-1 受注残とは

受注残とは

2-1

受注残とは

未だ顧客へ納品(あるいは出荷)していない注文のこと

 受注残とは、顧客から注文を受けた商品サービスについて、未だ顧客へ納品(あるいは出荷)していない注文のことを言います。例えば、単価100円のA商品を数量10個で注文を受けたとします。このとき、受注残は、数量10個(1,000円)になります。その後、販売者側の都合により、7個を納品したとします。このときの受注残は、数量3個(300円)になります。そして、受注残の数量3個を納品すれば、受注残は0になり、1つの受注に対して納品を完了したことになります。つまり、受注残は注文主である顧客に対する納品までの進捗状況を管理することができるのです。

なお、納品日と検収日を分けて受注を管理することもあります。納品後に顧客側での検収作業あり、検収基準で売上計上する場合です。この場合、受注残は納品日で消えますが、検収残として管理する必要が出てくるのです。受注残を検収日まで含めるのか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があるのです。
※「検収」という言葉は仕入にも使いますので、受注検収という言葉を使うことをお勧め致します。
クラウド型販売管理の受注残は、顧客単位、受注単位に受注残を一覧で参照したり、受注残のある顧客リストや受注一覧を表示することができます。顧客からの問い合わせ対応に役立つことになります。

「販売9」
freee連携kintoneプラグイン
統合型ワークフロー

投稿者:systemkanri 投稿日時:

2-2 発注残とは

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

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

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

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

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

投稿者:systemkanri 投稿日時:

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

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

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

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

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

 

投稿者:systemkanri 投稿日時:

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

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

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

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

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

 

投稿者:systemkanri 投稿日時:

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

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

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

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

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

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

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

 

投稿者:systemkanri 投稿日時:

2-6 買掛金から振込ファイル(全銀ファイル)を作成

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

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

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

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

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

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

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

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

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

なお、クラウド会計の会計freeeでは、(1)と(2)のどちらでも対応が可能です。

 

投稿者:systemkanri 投稿日時:

【目次】クラウド販売管理とクラウド会計

<目次>

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

 

はじめに

1.クラウド販売管理とクラウド会計

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

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

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

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

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

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

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

 

2.クラウド型販売管理(個別受注型)

2-1 受注残とは

2-2 発注残とは

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

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

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

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

 

3.なぜエクセルを使うのか、なぜエクセルはダメなのか

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

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

 

4.しっかりとした企業は、ワークフロー(申請承認)を導入している。

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

4-2 受注、仕入の承認

4-3 経費の申請(事前)と清算(事後)

 

5.まだ丸投げですか?、記帳は難しくない ~ 今どきのクラウド会計freee

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

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

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

5-4 仕訳もAIで推測

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

 

6.売上、仕入の計上

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

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

 

7.在庫の話し

 

8.IT導入は何から始める?失敗しないシステム導入とは

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

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

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

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

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

 

9.まだまだある、ITで業務効率アップ。

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

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

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

 

10.オールクラウドで作る業務システム

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

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

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

 

投稿者:systemkanri 投稿日時: