特許 7239669 買掛金を管理するための装置、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-03-06

(45)【発行日】2023-03-14

(54)【発明の名称】買掛金を管理するための装置、方法及びプログラム

(51)【国際特許分類】

   G06Q 40/02 20230101AFI20230307BHJP

【ＦＩ】

G06Q40/02

【請求項の数】 5

(21)【出願番号】P 2021203202

(22)【出願日】2021-12-15

(65)【公開番号】P2022121375

(43)【公開日】2022-08-19

【審査請求日】2022-01-06

(31)【優先権主張番号】P 2020211569

(32)【優先日】2020-12-21

(33)【優先権主張国・地域又は機関】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】519331420

【氏名又は名称】ペイトナー株式会社

(74)【代理人】

【識別番号】110003605

【氏名又は名称】弁理士法人六本木通り特許事務所

(72)【発明者】

【氏名】阪井 優

【審査官】宮久保 博幸

(56)【参考文献】

【文献】米国特許出願公開第２０１４／０２７９４６２（ＵＳ，Ａ１）

【文献】特開２００６－０７２８８４（ＪＰ，Ａ）

【文献】特開２００１－２１６３７１（ＪＰ，Ａ）

【文献】特開２０１８－１５１６９８（ＪＰ，Ａ）

【文献】特開２００２－２８８４４２（ＪＰ，Ａ）

【文献】特表２００８－５１１０８５（ＪＰ，Ａ）

【文献】特開２００２－０４９６６８（ＪＰ，Ａ）

【文献】宇都宮 浩, 外4名，請求書業務のデジタル化で変わる経理部門と新しい働き方，Think! 別冊 No.9 間接費改革から始める 戦略的コストマネジメント，山縣 裕一郎，2017年04月06日，No.9，p.46-49

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ１０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

買掛金を管理するための方法であって、
管理サーバが、買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信するステップと、
前記管理サーバが、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データを生成するステップであって、前記支払データは、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含むステップと、
前記管理サーバが、前記登録者が属するユーザー企業からの振込資金を管理するための銀行サーバから、前記ユーザー企業に関連づけられた仮想口座への入金通知を受信するステップと、
前記管理サーバが、前記入金通知に含まれる仮想口座識別子及び入金額に基づいて、前記仮想口座識別子に関連づけられた前記ユーザー企業の残高を前記入金額に応じて計算するステップと、
前記管理サーバが、前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をするステップと
を含むことを特徴とする。

【請求項2】

請求項１記載の方法であって、
前記生成は、前記請求書データにより表示可能な請求書に含まれる複数の項目を文字認識することにより行われることを特徴とする。

【請求項3】

請求項１又は２に記載の方法であって、
前記管理サーバが、前記支払データの内容に応じて、前記支払のワークフローを判定するステップと、
前記管理サーバが、前記第１のユーザー端末から、前記買掛金の承認申請を受信したことに応じて、前記ワークフローにより定められた承認者が用いる第２のユーザー端末に、前記買掛金の承認依頼を送信するステップと、
前記管理サーバが、前記第２のユーザー端末から、前記承認依頼に対する承認通知を受信するステップと
を含み、
前記支払実行処理の設定は、前記管理サーバが、前記承認通知を受信した後に行うことを特徴とする。

【請求項4】

コンピュータに、買掛金を管理するための方法を実行させるためのプログラムであって
、前記方法は、
管理サーバが、買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信するステップと、
前記管理サーバが、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データを生成するステップであって、前記支払データは、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含むステップと、
前記管理サーバが、前記登録者が属するユーザー企業からの振込資金を管理するための銀行サーバから、前記ユーザー企業に関連づけられた仮想口座への入金通知を受信するステップと、
前記管理サーバが、前記入金通知に含まれる仮想口座識別子及び入金額に基づいて、前記仮想口座識別子に関連づけられた前記ユーザー企業の残高を前記入金額に応じて計算するステップと、
前記管理サーバが、前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をするステップと
を含むことを特徴とする。

【請求項5】

買掛金を管理するための装置であって、
買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信して、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データであって、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含む支払データを生成し、
前記登録者が属するユーザー企業からの振込資金を管理するための銀行サーバから、前記ユーザー企業に関連づけられた仮想口座への入金通知を受信して、前記入金通知に含まれる仮想口座識別子及び入金額に基づいて、前記仮想口座識別子に関連づけられた前記ユーザー企業の残高を前記入金額に応じて計算し、
前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をすることを特徴とする。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、買掛金を管理するための装置、方法及びプログラムに関する。

【背景技術】

【0002】

企業の会計業務において、売掛金管理に並んで買掛金管理が重要な業務としてある。買掛金管理は、受け取った請求書に基づいて買掛金を計上し、それぞれの支払期日までに入金処理を行うことを伴う。請求書の受け取りは月初が多く、買掛金の入金は月末が多い。また、請求書の受け取りは、郵送、メール等方式が複数ある。

【発明の概要】

【発明が解決しようとする課題】

【0003】

こうした一連の業務は、請求書の枚数が数枚であれば大きな負担ではないが、数十枚、数百枚となってきた場合、月末又は月初に経理担当者が数日を費やすことも多い。請求書の受け取りとそれにより生じた買掛金の入金の処理タイミングが分割されているため、ミスが発生しやすい。請求書の受け取り方式が複数あることが買掛金管理の煩雑さを助長している。

【0004】

本発明は、こうした問題点に鑑みてなされたものであり、その目的は、買掛金を管理するための装置、方法及びそのためのプログラムにおいて、処理ミスを増やすことなく、効率性を向上させることにある。

【課題を解決するための手段】

【0005】

このような目的を達成するために、本発明の第１の態様は、買掛金を管理するための方法であって、管理サーバが、買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信するステップと、前記管理サーバが、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データを生成するステップであって、前記支払データは、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含むステップと、前記管理サーバが、前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をするステップとを含むことを特徴とする。

【0006】

また、本発明の第２の態様は、第１の態様の方法であって、前記生成は、前記請求書データにより表示可能な請求書に含まれる複数の項目を文字認識することにより行われることを特徴とする。

【0007】

また、本発明の第３の態様は、第１又は第２の態様の方法であって、前記支払実行処理は、前記支払期日又はその前の所定若しくは指定の期日における、前記支払を実行するための銀行サーバに対する支払実行要求の送信であることを特徴とする。

【0008】

また、本発明の第４の態様は、第１又は第２の態様に記載の方法であって、前記支払実行処理は、前記支払期日又はその前の所定若しくは指定の期日における、前記支払を実行するための銀行サーバによる入金処理であることを特徴とする。

【0009】

また、本発明の第５の態様は、第１から第４のいずれかの態様の方法であって、前記管理サーバが、前記支払データの内容に応じて、前記支払のワークフローを判定するステップと、前記管理サーバが、前記第１のユーザー端末から、前記買掛金の承認申請を受信したことに応じて、前記ワークフローにより定められた承認者が用いる第２のユーザー端末に、前記買掛金の承認依頼を送信するステップと、前記管理サーバが、前記第２のユーザー端末から、前記承認依頼に対する承認通知を受信するステップとを含み、前記支払実行処理の設定は、前記管理サーバが、前記承認通知を受信した後に行うことを特徴とする。

【0010】

また、本発明の第６の態様は、第５の態様の方法であって、前記判定は、前記支払データに含まれる金額が所定の金額以上であるか否か、及び、前記支払データに含まれる取引先が新規であるか否かの少なくとも一方に応じて行うことを特徴とする。

【0011】

また、本発明の第７の態様は、第３の態様の方法であって、前記管理サーバが、前記登録者が属するユーザー企業からの振込資金を管理するための銀行サーバから、前記ユーザー企業に関連づけられた仮想口座への入金通知を受信するステップと、前記入金通知に基づいて、前記ユーザー企業の残高を計算するステップとを含むことを特徴とする。

【0012】

また、本発明の第８の態様は、第７の態様であって、前記管理サーバが、前記支払実行要求の送信前に、前記残高と前記金額を比較して、前記支払実行要求の送信可否を判定するステップをさらに含むことを特徴とする。

【0013】

また、本発明の第９の態様は、コンピュータに、買掛金を管理するための方法を実行させるためのプログラムであって、前記方法は、管理サーバが、買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信するステップと、前記管理サーバが、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データを生成するステップであって、前記支払データは、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含むステップと、前記管理サーバが、前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をするステップとを含むことを特徴とする。

【0014】

また、本発明の第１０の態様は、買掛金を管理するための装置であって、買掛金の登録者が用いる第１のユーザー端末から、前記買掛金を発生させる請求書の請求書データを受信して、前記請求書データに基づいて、前記買掛金の支払の内容を表す支払データであって、金額、請求日、支払期日、取引先名又はその識別子、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号を含む支払データを生成し、前記第１のユーザー端末から、前記支払の予約要求を受信したことに応じて、前記金額の支払実行処理の設定をすることを特徴とする。

【発明の効果】

【0015】

本発明の一態様によれば、管理装置が提供するサービス上で、請求書データに基づく買掛金の登録から支払実行の予約までを実行可能とすることによって、買掛金の管理が大幅に簡略化される。

【図面の簡単な説明】

【0016】

【図1】本発明の一実施形態にかかる管理装置を示す図である。

【図2】本発明の一実施形態にかかる管理方法の流れを示す図である。

【図3】本発明の一実施形態にかかる支払データの表示例を示す図である。

【図4】本発明の一実施形態にかかる支払データが生成された後の請求書一覧画面を示す図である。

【発明を実施するための形態】

【0017】

以下、図面を参照して本発明の実施形態を詳細に説明する。

【0018】

図１に、本発明の一実施形態にかかる管理装置を示す。管理装置１００は、買掛金の登録者が用いる第１のユーザー端末１１１と、買掛金の承認者が用いる第２のユーザー端末１１２と、ユーザー企業からの振込資金を管理するための第１の銀行サーバ１２１と、買掛金の支払を実行するための第２の銀行サーバ１２２とコンピュータ・ネットワークを介して通信可能である。承認のためのフローが有効でない場合には、第２のユーザー端末１１２との通信は不要となる。また、ユーザー企業からの入金を受け取る銀行口座と買掛金の支払元となる銀行口座が同一である場合には、第１の銀行サーバ１２１及び第２の銀行サーバ１２２は同一サーバとなることがある。

【0019】

管理装置１００は、通信インターフェースなどの通信部１０１と、プロセッサ、ＣＰＵ等の処理部１０２と、メモリ、ハードディスク等の記憶装置又は記憶媒体を含む記憶部１０３とを備え、各処理を行うためのプログラムを実行することによって構成することができる。管理装置１００は、１又は複数の装置、コンピュータないしサーバを含むことがある。また、当該プログラムは、１又は複数のプログラムを含むことがあり、また、コンピュータ読み取り可能な記憶媒体に記録して非一過性のプログラムプロダクトとすることができる。当該プログラムは、記憶部１０３又は管理装置１００からアクセス可能な記憶装置又は記憶媒体に記憶しておき、処理部１０２において実行することができる。

【0020】

管理装置１００はまず、買掛金の登録者が用いる第１のユーザー端末１１１から、当該買掛金を発生させる請求書の請求書データを受信する（Ｓ２０１）。請求書データは、ＰＮＧ形式、ＪＰＥＧ形式等の画像形式のデータとすることができる。あるいは、表示される内容に含まれる文字が識別可能なＰＤＦ形式等のファイル形式のデータとしてもよい。

【0021】

管理装置１００は、受信した請求書データに基づいて、当該買掛金の支払の内容を表す支払データを生成する（Ｓ２０２）。支払データは、たとえば、管理装置１００が、受信した請求書データにより表示可能な請求書に含まれる複数の項目を文字認識することによって生成することができる。より具体的には、機械学習により生成された推測モデルを用いた文字認識を行うことが挙げられる。文字認識は、管理装置１００で行うことのほかに、たとえばＡＰＩ連携によって管理装置１００からアクセス可能なサーバに請求書データを送信して行うことが考えられる。

【0022】

図３は、生成された支払データの少なくとも一部を請求書データにより表示される請求書とともに第１のユーザー端末１１１の表示画面に表示した例である。この例では、請求書に含まれる項目として、金額３０１、請求日３０２、支払期限３０３、取引先名３０４、金融機関名３０５、支店名３０６、口座種別３０７及び口座番号３０８が認識されている。加えて、請求書番号、取引先のメールアドレス、口座名義名などが文字認識されることがある。支払データは、記憶部１０３又は管理装置１００からアクセス可能な記憶装置又は記憶媒体に記憶される。支払データは、文字認識を用いて自動的に生成されるものの、オペレーターの目視による確認を加えて行うこともできる。

【0023】

管理装置１００は、支払データの生成が完了した後、すなわちデータ化が完了した後、自動的に、又は第１のユーザー端末１１１からの要求に応じて、請求書一覧画面の表示情報を第１のユーザー端末１１１に送信する（Ｓ２０３）。表示情報は、一例として、ＨＴＭＬ形式のデータとすることができる。

【0024】

図４は、支払データが生成された後の請求書一覧画面の例である。「データ化中」はオペレーターによる目視確認中の状態を意味し、「申請待ち」はワークフローに沿った承認申請が行われていない状態を意味する。

【0025】

管理装置１００が、第１のユーザー端末１１１から、買掛金の承認申請を受信し（Ｓ２０４）、生成された支払データの内容に応じて、買掛金の支払に必要な承認のためのワークフローを判定する（Ｓ２０５）。ここで「ワークフロー」とは、買掛金の登録の後にその支払を承認する必要のある１又は複数の承認者及びその流れを意味する。また、ワークフローの判定は、承認申請の受信後に行うものとして記述したが、支払データが生成された後であれば承認申請の受信前に行ってもよい。

【0026】

一例として、支払データに含まれる金額及び取引先又はその識別子の少なくとも一方に応じて、複数のワークフローのうちのいずれかが適用されるように、ワークフローの判定を行うことが考えられる。金額が１００万円以上か否か、新規の取引先か否かがワークフローの判定基準として挙げられる。個々のワークフローは、ユーザー企業の担当者が管理装置１００が提供するウェブページ上で必要に応じて設定すればよい。

【0027】

次いで、管理装置１００は、ワークフローにより定められた承認者が用いる第２のユーザー端末１１２に、買掛金の承認依頼を送信し（Ｓ２０６）、第２のユーザー端末１１２から、承認依頼に対する承認通知を受信する（Ｓ２０７）。ここでは、承認者が１名のワークフローを示しているが、複数名のワークフローとすることができる。承認依頼の送信は、具体例としては、第２のユーザー端末１１２に対するメールの送信とすることができる。

【0028】

また、管理装置１００は、ユーザー企業からの振込資金を管理するための第１の銀行サーバ１２１から、当該ユーザー企業に関連づけられた仮想口座への入金通知を受信する（Ｓ２０８）。管理装置１００が提供するサービスにユーザー企業がユーザー登録した場合、管理装置１００は、当該ユーザー企業が用いる端末に、当該ユーザー企業に関連づけられた仮想口座の口座番号を通知する。これにより、当該ユーザー企業は、買掛金の支払額に相当する金額の入金を行うことができる。なお、「仮想口座」とは、銀行口座に関連づけて提供される振込専用の口座のことをいい、仮想口座に入金された金額は当該仮想口座が関連づけられた口座に対する入金として処理され、記憶される。仮想口座は、管理装置１００から第１の銀行サーバ１２１に対して仮想口座の生成要求を送信することによって生成でき、生成された仮想口座の口座番号が管理装置１００に通知される。仮想口座は、ユーザー登録の際に都度生成してもよく、又は複数の仮想口座を事前に生成してもよい。

【0029】

入金通知は、仮想口座識別子及び入金額を含む。管理装置１００は、ユーザー企業のユーザー識別子と当該ユーザー企業に関連づけた仮想口座識別子との対応づけを有し、入金通知に含まれる仮想口座識別子に基づいて当該対応づけを参照することによって、入金を行ったユーザー企業を判定し、当該ユーザー企業の残高を計算することができる。残高は、一例として、合計入金額から後述する支払額を引いた額となる。仮想口座識別子は、具体的には仮想口座の口座番号とすることができる。

【0030】

管理装置１００は次いで、買掛金の支払の予約要求を第１のユーザー端末１１１から受信し（Ｓ２０９）、当該予約要求を受信したことに応じて、当該買掛金の支払期日又はその前の所定若しくは指定の期日における第２の銀行サーバ１２２に対する支払実行要求の送信を設定する（Ｓ２１０）。設定された期日になると、管理装置１００は、第２の銀行サーバ１２２に対して、支払実行要求を送信する（Ｓ２１１）。支払が完了した場合、管理装置１００は、第２の銀行サーバ１２２から完了通知を受信し（Ｓ２１２）、支払額を管理装置１００が管理する残額から引く。支払実行要求は、支払額を含み、また、入金先口座を含む。入金先口座は、たとえば、金融機関名又はその識別子、支店名又はその識別子、口座種別及び口座番号により指定することができる。

【0031】

図４において、ワークフローに沿った承認が済むと「支払予約待ち」の状態となり、予約要求が第１のユーザー端末１１１から送信されて管理装置１００における処理が完了すると「支払予約中」の状態になる。

【0032】

予約要求を受信した管理装置１００は、支払実行要求の送信を設定する前に、予約可否の判定を行ってもよい。具体的には、ユーザー企業の残高と、支払データに含まれる金額とを比較し、一例として当該金額が当該残高以下である場合に、予約可と判定することが挙げられる。残高確認は、管理装置１００が支払実行要求を第２の銀行サーバ１２２に送信する時又はその前に当該要求の送信の条件として行ってもよい。また、支払データに含まれる請求書番号が既に生成されている支払データに含まれるものと一致する場合、二重払いのおそれがあることから、予約要求を送信した第１のユーザー端末１１１に対し、二重払いではないかの確認通知を送信することが考えられる。また、請求書データに請求書番号が必ずしも含まれないことから、金額、請求日、支払期日及び取引先又はその識別子が一致する場合に確認通知を送信することも考えられる。こうした確認通知に対して第１のユーザー端末１１１から必要な応答があった後に、管理装置１００は予約可と判定してもよい。

【0033】

また、上述の説明では、管理装置１００は、予約要求を受信したことに応じて、支払実行要求の送信を設定しているが、予約要求を受信したことに応じて、第２の銀行サーバ１２２に支払実行要求を送信し、第２の銀行サーバ１２２において、支払実行処理の設定をすることも考えられる。この場合には、支払実行要求は、支払期日又はその前の所定若しくは指定の期日を含み、当該期日に第２の銀行サーバ１２２は、支払実行処理を実行する。

【0034】

このように、管理装置１００が提供するサービス上で、請求書データに基づく買掛金の登録から支払実行の予約までを実行可能とすることによって、買掛金の管理が大幅に簡略化される。

【0035】

なお、「××のみに基づいて」、「××のみに応じて」、「××のみの場合」というように「のみ」との記載がなければ、本明細書においては、付加的な情報も考慮し得ることが想定されていることに留意されたい。また、一例として、「ａの場合にｂする」という記載は、明示した場合を除き、「ａの場合に常にｂする」こと、「ａの直後にｂする」ことを必ずしも意味しないことに留意されたい。また、「Ａを構成する各ａ」という記載は、必ずしもＡが複数の構成要素によって構成されることを意味するものではなく、構成要素が単数であることを含む。

【0036】

また、念のため、なんらかの方法、プログラム、端末、装置、サーバ又はシステム（以下「方法等」）において、本明細書で記述された動作と異なる動作を行う側面があるとしても、本発明の各態様は、本明細書で記述された動作のいずれかと同一の動作を対象とするものであり、本明細書で記述された動作と異なる動作が存在することは、当該方法等を本発明の各態様の範囲外とするものではないことを付言する。

【0037】

また、図３において示される「開始」及び「終了」は、一例を示すものに過ぎず、本実施形態にかかる方法がＳ３０１によって必ず開始され、Ｓ３０５によって必ず終了することを意味するものではない。

【符号の説明】

【0038】

１００ 管理装置
１０１ 通信部
１０２ 処理部
１０３ 記憶部
１１１ 第１のユーザー端末
１１２ 第２のユーザー端末
１２１ 第１の銀行サーバ
１２２ 第２の銀行サーバ
３０１ 金額
３０１ 請求日
３０３ 支払期限
３０４ 取引先名
３０５ 金融機関名
３０６ 支店名
３０７ 口座種別
３０８ 口座番号

【図1】

【図2】

【図3】

【図4】