JP2004310729A - 貿易取引の決済支援装置及びプログラム - Google Patents

Abstract

【課題】 貿易取引の決済に係る業務を省力化する。
【解決手段】 輸出企業側で作成されたインボイスデータがウェブサーバにアップロードされると、同一ドラフト番号が付与された複数のインボイスデータを単一の請求書データへ統合して記憶する(72)。輸出企業の管理者によって内容が承認された請求書データを輸入企業の閲覧に供し、輸入企業の購買部担当者によって内容が確認され、輸入企業の購買部管理者によって承認された後に、輸入企業の経理部担当者からの指示によって送金依頼書データを生成し(84)、輸入企業の経理部管理者による承認後に、送金依頼書データを出力する(92)。出力した送金依頼書データは金融機関への送金依頼(94)に使用される。
【選択図】 図２

Description

本発明は貿易取引の決済支援装置及びプログラムに係り、特に、貿易取引に係る決済を支援するための貿易取引の決済支援装置、及び、コンピュータを貿易取引の決済支援装置として機能させるためのプログラムに関する。

貿易取引の分野でも、貿易取引の迅速化・貿易取引業務の効率化を目的として、インターネット等のコンピュータ・ネットワーク上で売買契約を締結したり、受発注を行う事が行われるようになってきており、更に、貿易ＥＤＩ、例えば公知のボレロ(Bolero International Limited)等を利用して、貿易取引の関係者間の貿易書類の授受をコンピュータ・ネットワークを介して行うことも検討されている。しかしながら、貿易取引に関わる請求や回収業務（即ち決済業務）、及びそれら管理業務については旧来の手法で行われているのが実情であり、貿易取引の迅速化、業務の効率化の障害となっている。

このため、本願出願人は、輸出者及び輸入者のリスクを軽減し、貿易取引の決済を迅速かつ効率的に行うために、輸出者の電子貿易書類データを記憶手段に記憶させ、該電子貿易書類の更新及び記憶手段からの取り出しを禁止すると共に輸入者の閲覧に供し、代金の決済完了後に電子貿易書類の取り出し禁止を解除し、電子貿易書類を記憶手段から取り出して輸入者へ送信する技術を既に提案している（特許文献１参照）。
特開２００２−６３５３３号公報

ところで、貿易取引における請求書は、輸出者によって作成されて輸入者へ送付する商業送り状（インボイスともいう）で代用するのが慣例であり、代金の決済やその管理も通常、個々の商業送り状を単位として行われる。しかしながら、商業送り状は積荷の品名・数量・単価・金額等が記載された書類であり、出荷案内書・積荷の物品明細書としての役目も有しており、輸出者と輸入者との間の受発注の都度発行されるため、特に、例えば同一の企業グループの本社と海外支社等のように、同一の輸出者・輸入者の間で頻繁に貿易取引が行われている等の場合、輸出者から輸入者へ送付される商業送り状の数自体が膨大なものとなり、決済やその管理が非常に煩雑なものとなっていた。

本発明は上記事実を考慮して成されたもので、貿易取引の決済に係る業務を省力化できる貿易取引の決済支援装置及びプログラムを得ることが目的である。

上記目的を達成するために請求項１記載の発明に係る貿易取引の決済支援装置は、輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続された貿易取引の決済支援装置であって、情報を記憶するための記憶手段と、輸出者側で作成されて輸出者のクライアント・コンピュータからデータとして受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを前記記憶手段に記憶させる請求書データ生成手段と、前記記憶手段に記憶されている請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる表示制御手段と、輸入者のクライアント・コンピュータの表示装置に前記請求書が表示されている状態で、輸入者によって特定の請求書が選択されて決済が指示されると、選択された特定の請求書についての決済のための処理を行う決済処理手段と、を含んで構成されている。

請求項１記載の発明に係る貿易取引の決済支援装置は、輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続され、情報を記憶するための記憶手段を備えており、例えば輸出者及び輸入者のクライアント・コンピュータとインターネット等のコンピュータ・ネットワークを介して接続され、ハードディスクドライブ（ＨＤＤ）等の記憶装置を備えたサーバ・コンピュータで実現できる。

請求項１記載の発明では、輸出者側で作成された複数の商業送り状を輸出者のクライアント・コンピュータからデータとして受信し、請求書データ生成手段は、受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを記憶手段に記憶させる。なお、上記の所定の条件（単一の請求書へ統合する商業送り状の条件）としては、例えば請求項２に記載したように、輸出者によって個々の商業送り状データに予め付与された識別情報が同一である、又は、期日、輸入者及び取引通貨が同一である等の条件を適用することができる。

また、請求項１記載の発明では、記憶手段に記憶されている請求書データが表す請求書を、表示制御手段によってクライアント・コンピュータの表示装置に表示され、輸入者のクライアント・コンピュータの表示装置に請求書が表示されている状態で、輸入者によって特定の請求書が選択されて決済が指示されると、決済処理手段により、選択された特定の請求書についての決済のための処理が行われる。

このように、請求項１記載の発明によれば、同一の輸出者・輸入者の間で頻繁に貿易取引が行われることで、輸出者から輸入者へ多数の商業送り状が送付される等の場合にも、複数の商業送り状が単一の請求書に統合されることで、貿易取引の決済及びその管理を個々の請求書を単位として行うことができ、貿易取引の決済及びその管理の対象数が大幅に減少される。従って、請求項１記載の発明によれば、貿易取引の決済に係る業務を省力化することができる。

ところで、請求元の企業による請求書（或いはそれに類する書類）の送付は、一旦作成された請求書の内容が役職者等によって確認されて承認された後に為されることが一般的である。上記を考慮すると、請求項１記載の発明において、例えば請求項３に記載したように、請求書データ生成手段によって生成された請求書データに状態情報を付加すると共に、個々の請求書データに付加した状態情報の内容を、少なくとも、対応する請求書データが表す請求書が輸出者側で承認されているか否かに応じて相違させる第１の請求書データ管理手段を更に備え、表示制御手段は、請求書データに付加されている状態情報に基づき、輸出者側で承認されている状態の請求書のみを輸入者のクライアント・コンピュータの表示装置に表示させることが好ましい。

請求項３記載の発明では、請求書データ生成手段によって生成された特定の請求書データが表す特定の請求書に対し、輸出者側の役職者等が内容を確認して承認すると、前記特定の請求書データに付加された状態情報の内容が変更され、輸入者のクライアント・コンピュータの表示装置には、輸出者側で承認された請求書（変更後の内容に相当する状態情報が付加されている請求書データが表す請求書）のみが表示されるので、輸入者側で、決済対象の請求書を誤りなく認識することができる。

また、請求項１記載の発明において、例えば請求項４に記載したように、請求書データ生成手段によって生成された請求書データに状態情報を付加すると共に、個々の請求書データに付加した状態情報の内容を、対応する請求書データが表す請求書の状態の変化に応じて変化させる第２の請求書データ管理手段を更に備え、表示制御手段は、請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる際に、状態情報の内容も表示させることが好ましい。これにより、クライアント・コンピュータの表示装置に表示された請求書を参照する参照者に、表示された個々の請求書の状態を容易に認識させることができる。

例えば、対応する請求書の決済が指示された状態か否かに応じて状態情報の内容を変化させるように第２の請求書データ管理手段を構成した場合には、輸出者側の参照者に、決済が指示された状態か否かを個々の請求書毎に認識させることができるので、輸出者側に入金予定を把握させることも可能となる。

また、請求項１記載の発明において、決済処理手段は、選択された特定の請求書についての決済のための処理として、例えば請求項５に記載したように、選択された特定の請求書のデータに基づき、輸入者が輸出者への送金を金融機関に依頼するための送金依頼書データを生成・出力する処理を行うことができる。これにより、輸入者側は所望の請求書を選択した後に、自動的に生成・出力された送金依頼書データを金融機関へ送信する、という簡単な作業を行うのみで、所望の請求書についての決済を行うことができる。従って、貿易取引の決済に係る業務を更に省力化することができる。

また、請求項１記載の発明において、例えば請求項６に記載したように、輸入者側からの指示に応じて、所定の条件に合致する複数の請求書データを単一の支払いデータに統合する請求書データ統合手段を更に設けることが好ましい。これにより、輸入者による貿易取引の決済に際し、複数の請求書データを単一の支払いデータに統合させることで、決済の対象数を減少させることが可能となるので、貿易取引の決済に関わる輸入者側の業務や送金に伴う銀行手数料を更に省力化、削減することができる。

請求項７記載の発明に係るプログラムは、輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続され、情報を記憶するための記憶手段を備えたコンピュータを、輸出者側で作成されて輸出者のクライアント・コンピュータからデータとして受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを前記記憶手段に記憶させる請求書データ生成手段、前記記憶手段に記憶されている請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる表示制御手段、及び、輸入者のクライアント・コンピュータの表示装置に前記請求書が表示されている状態で、輸入者によって特定の請求書が選択されて決済が指示されると、選択された特定の請求書についての決済のための処理を行う決済処理手段として機能させる。

請求項７記載の発明に係るプログラムは、輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続され、情報を記憶するための記憶手段を備えたコンピュータを、上記の請求書データ生成手段、表示制御手段及び決済処理手段として機能させるためのプログラムであるので、コンピュータが請求項７記載の発明に係るプログラムを実行することにより、コンピュータが請求項１に記載の貿易取引の決済支援装置として機能することになり、請求項１記載の発明と同様に、貿易取引の決済に係る業務を省力化できる。

以上説明したように本発明は、輸出者側で作成されてデータとして受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを記憶させると共に、記憶させた請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させ、表示装置に表示されている特定の請求書が輸入者によって選択されて決済が指示されると、選択された特定の請求書についての決済のための処理を行うので、貿易取引の決済に係る業務を省力化できる、という優れた効果を有する。

以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るコンピュータ・システム１０が示されている。コンピュータ・システム１０は、貿易取引（輸出入）を行う輸出企業１２及び輸入企業１４が各々所持している多数台のクライアントＰＣ１６を含んで構成されている。

個々のクライアントＰＣ１６は略同一の構成であるので、輸出企業が所持しているクライアントＰＣ１６を例にその構成を説明すると、クライアントＰＣ１６はパーソナル・コンピュータ（ＰＣ）から成り、ＣＰＵ１６Ａ、ＲＯＭ１６Ｂ、ＲＡＭ１６Ｃ及び入出力ポート１６Ｄが、データバス、制御バス、アドレスバス等から成るバス１６Ｅを介して互いに接続されて構成されている。また入出力ポート１６Ｅには、各種の入出力機器として、通信制御装置１８、ＣＲＴ又はＬＣＤから成るディスプレイ２０、キーボード２２、マウス２４、ハードディスクドライブ（ＨＤＤ）２６、ＣＤ−ＲＯＭ２８からの情報の読み出しを行うＣＤ−ＲＯＭドライブ３０が各々接続されている。

また、個々のクライアントＰＣ１６の通信制御装置１８は、多数台のウェブサーバが通信回線を介して相互に接続されて成るコンピュータ・ネットワーク３２（以下、単にネットワーク３２と称する）３２に各々接続されている。ネットワーク３２には、電子インボイス・サービス（詳細は後述）を提供するウェブサイト（電子インボイス・サイト）を運営しているウェブサーバ（本発明に係る貿易取引の決済支援装置として機能するウェブサーバ）３４が接続されている。

なお、輸出企業１２と輸入企業１４がグループ企業（例えば本社と海外現地法人）である場合、ネットワーク３２として社内イントラネットを利用することができ、ウェブサーバ３４は例えば本社に設置することができる。また、ネットワーク３２はインターネットであってもよい。この場合、クライアントＰＣ１６のなりすましは、ＳＳＬ(Secure Sockets Layer)を利用したクライアント認証（認証局で認証）及びワンタイムパスワード認証によって防止し、ウェブサーバ３４のなりすましは、ＳＳＬを利用したサーバ認証により防止すると共に、情報の漏洩を防止するためにクライアントＰＣ１６とウェブサーバ３４の間で送受される情報をＳＳＬ128bitで暗号化し、情報の改ざんを防止するために電子署名を利用することが好ましい。

ウェブサーバ３４はワークステーションから成り、ＣＰＵ３４Ａ、ＲＯＭ３４Ｂ、ＲＡＭ３４Ｃ及び入出力ポート３４Ｄを備え、これらは互いにデータバス、制御バス、アドレスバス等から成るバス３４Ｅを介して互いに接続されている。また入出力ポート３４Ｄには、各種の入出力機器として、通信回線を介してネットワーク３２に接続された通信制御装置３６、ＣＲＴ又はＬＣＤから成るディスプレイ３８、キーボード４０、マウス４２及びＨＤＤ４４が各々接続されている。ＨＤＤ４４には、認証情報データベース（ＤＢ）及び請求書ＤＢ（何れも後述）を記憶するための記憶領域が設けられており、本発明に係る記憶手段に対応している。

また、ウェブサーバ３４には、後述する電子インボイス処理を行うための電子インボイス・プログラムがＨＤＤ４４に各々インストールされている。電子インボイス・プログラムをウェブサーバ３４にインストール（移入）するには幾つかの方法があるが、例えば電子インボイス・プログラムをセットアッププログラムと共にＣＤ−ＲＯＭに記録しておき、該ＣＤ−ＲＯＭを図示しないＣＤ−ＲＯＭドライブにセットし、ＣＰＵ３４Ａに対して前記セットアッププログラムの実行を指示すれば、ＣＤ−ＲＯＭから電子インボイス・プログラムが順に読み出され、読み出された電子インボイス・プログラムがＨＤＤ４４に順に書き込まれることで、電子インボイス・プログラムのインストールが行われる。上記の電子インボイス・プログラムは請求項７に記載のプログラムに対応している。

また、輸出企業１２が所持している複数台のクライアントＰＣ１６のうちの特定のクライアントＰＣ１６は、輸出企業１２の所在地（輸出地）の金融機関（輸出地金融機関）４６内に設置されたホスト・コンピュータ４８と通信回線（例えば公衆電話回線）を介して接続可能とされ、前記特定のクライアントＰＣ１６のＨＤＤ２６には、輸出地金融機関４６に対し、所望の金融取引の実行をホスト・コンピュータ４８を介してオンラインで指示するための金融取引支援プログラムがインストールされている。輸出企業１２は、前記特定のクライアントＰＣ１６上で金融取引支援プログラムを実行することで、所望の金融取引の実行を輸出地金融機関４６にオンラインで指示可能とされている。

また、輸入企業１４が所持している複数台のクライアントＰＣ１６のうちの特定のクライアントＰＣ１６も、輸入企業１４の所在地（輸入地）の金融機関（輸入地金融機関）５２内に設置されたホスト・コンピュータ５４と通信回線（例えば公衆電話回線）を介して接続可能とされ、前記特定のクライアントＰＣ１６のＨＤＤ２６には、輸入地金融機関５２に対し、所望の金融取引の実行をホスト・コンピュータ５４を介してオンラインで指示するための金融取引支援プログラムがインストールされている。輸入企業１４も、前記特定のクライアントＰＣ１６上で金融取引支援プログラムを実行することで、所望の金融取引の実行を輸入地金融機関５２にオンラインで指示可能とされている。

また、輸出地金融機関４６のホスト・コンピュータ４８は輸出地金融機関４６内に設置されたネットワーク５０と通信回線を介して接続されており、輸入地金融機関５２のホスト・コンピュータ５４は輸入地金融機関５２内に設置されたネットワーク５６と通信回線を介して接続されている。そして、輸出地金融機関４６のネットワーク５０と輸入地金融機関５２のネットワーク５６は、Ｓ.Ｗ.Ｉ.Ｆ.Ｔ５８（銀行間のメッセージ交換のための国際間ネットワーク）を介して相互に接続されている。

以下、本実施形態の作用を説明する。本実施形態に係るウェブサーバ３４によって運営される電子インボイス・サイトは、ウェブサーバ３４のＣＰＵ３４Ａが電子インボイス・プログラムを実行する（ウェブサーバ３４によって電子インボイス処理が行われる）ことで実現される。電子インボイス・サイトによって提供される電子インボイス・サービスは、貿易取引（輸出入）の請求〜回収、決済に関わる業務の省力化を実現するサービスであり、輸出企業１２及び輸入企業１４が合意の上、サイトの運営者（例えばグループ企業間で利用の場合は本社）に利用申込書を事前に提出することで、前記サービスを利用することが可能となる。

本実施形態では、利用申込書を提出した企業に対して企業単位でＩＤ（会社ＩＤ）及びパスワード（会社パスワード）が付与され、この会社ＩＤ及び会社パスワードが認証情報ＤＢに予め登録されている。また、個々の企業が提出する利用申込書には、個々の企業において本サイトへのアクセス権限を付与した職員の氏名や所属部署（輸出企業１２であれば販売部、輸入企業１４であれば購買部、経理部等）が記載されており、利用申込書に記載された個々の職員に対してもＩＤ（ユーザＩＤ）及びパスワード（ユーザパスワード）が付与され、このユーザＩＤ及びユーザパスワードも認証情報ＤＢに予め登録されている。

利用者による電子インボイス・サービスの利用は、クライアントＰＣ１６を操作してブラウザ（閲覧ソフト）を起動し、電子インボイス・サイトのＵＲＬ(Uniform Resource Locator)を入力して電子インボイス・サイトにアクセスすることによって為される。電子インボイス・サイトにアクセスすると、ウェブサーバ３４のＣＰＵ３４Ａによって電子インボイス・プログラムが実行されることで、図３に示す電子インボイス処理が行われる。

この電子インボイス処理では、まずステップ１００において、例として図７に示すようなログイン画面のデータをＨＤＤ４４から読み出し、読み出したデータをアクセス元のクライアントＰＣ１６へ送信することで、アクセス元のクライアントＰＣ１６のディスプレイ２０にログイン画面を表示させる。なお、画面及び出力帳票上の言語表記は、事前にユーザ毎に登録した言語表記（例えば日本語、英語、中国語等）で表示することも可能とされている（図８は日本語で表示された状態が示されている）。次のステップ１０２では、アクセス元のクライアントＰＣ１６から認証情報を受信したか否か判定し、判定が肯定される迄ステップ１０２を繰り返す。

図７に示すように、ログイン画面には、会社ＩＤ、会社パスワード、ユーザＩＤ及びユーザパスワードを入力するための入力欄が各々設けられており、利用者はキーボード２２等を操作し各入力欄に該当する情報を各々入力する。利用者によって入力された情報は認証情報としてウェブサーバ３４へ送信される。ウェブサーバ３４では、クライアントＰＣ１６から認証情報を受信するとステップ１０２の判定が肯定されてステップ１０４へ移行し、受信した認証情報が認証情報ＤＢに登録されているか否かを判定することで、クライアントＰＣ１６を介して電子インボイス・サービスを利用しようとしている利用者が、電子インボイス・サービスの正規の利用者か否かを判断する認証処理を行う。

利用者が正規の利用者であることを確認すると、ステップ１０６では、クライアントＰＣ１６から認証情報として受信した会社ＩＤ及びユーザＩＤに基づいて利用者の所属（会社及び所属部署）を判断し、次のステップ１０８において、ステップ１０６における判断結果に応じて処理を分岐する。すなわち、利用者が輸出企業１２の販売部に所属している場合は、ステップ１０８からステップ１１０へ移行して請求側処理を行う。また、利用者が輸入企業１４の購買部に所属している場合は、ステップ１０８からステップ１１２へ移行して購買側処理を行う。また、利用者が輸入企業１４の経理部に所属している場合には、ステップ１０８からステップ１１４へ移行して支払側処理を行う。このように、本実施形態に係る電子インボイス処理では利用者の所属に応じて異なる処理が行われ、異なるサービスが提供される（同一部署に複数部署の処理権限を付与することで、同一人が複数部署の処理を行えることは勿論である）。

以下、ウェブサーバ３４によって実現される電子インボイス処理の詳細について、輸出入の決済の流れに沿って説明する。貿易取引は、輸出企業１２からの物品の売込活動、又は輸入企業１４から輸出企業１２への引合いによって両者の交渉が開始され、品質・数量・価格・納期等の諸条件について両者が合意し受発注が成される（売買契約が締結される）ことによって開始される。

また、輸出企業１２の販売部の担当者又はその受託者は、輸入企業１４との間で受発注が成立する毎にクライアントＰＣ１６のキーボード２２等を操作し、品名・数量・単価・通貨・金額・支払期日・取引先名・取引先部課名等のデータを入力することで商業送り状（インボイス）を作成する（図２のステップ７０も参照）。作成された商業送り状は、輸出企業１２から輸入企業１４に直接、又は銀行経由で提出されると共に、通関の際にも提出される。なお、入力されたインボイスデータはクライアントＰＣ１６のＨＤＤ２６に記憶される。

また、輸出企業１２の販売部の担当者は、輸出する商品の代金を輸入企業に請求するための請求書を作成するために、前述のようにして電子インボイス・サイトにアクセスする。この場合、クライアントＰＣ１６を介して電子インボイス・サービスを利用しようとしている利用者は輸出企業１２の販売部に所属しているので、ウェブサーバ３４では請求側処理が行われる。以下、この請求側処理について図４を参照して説明する。

ステップ１２０では、例として図８に示すような請求側のメニュー画面のデータをＨＤＤ４４から読み出し、読み出したデータをアクセス元のクライアントＰＣ１６へ送信することで、クライアントＰＣ１６のディスプレイ２０に請求側メニュー画面を表示させる。図８に示すように、請求側メニュー画面には、実行可能な処理の選択肢として「請求書作成」「請求書閲覧」「請求書印刷」「異議申し立て」及び「Logout(ログアウト)」が各々表示されている。

次のステップ１２２では、請求側メニュー画面内の複数の選択肢の何れかが選択されることで、選択肢に対応する処理の実行が指示されたか否か判定する。判定が否定された場合には、判定が肯定される迄ステップ１２２を繰り返す。請求書を作成する場合、輸出企業１２の販売部の担当者はマウス２４等を操作して画面内の「請求書作成」を選択する。これにより、ステップ１２２の判定が肯定されてステップ１２４へ移行し、実行が指示された処理が「請求書作成」か否か判定する。この場合は判定が肯定され、ウェブサーバ３４は、例として図９に示すように「請求書作成」に対応する複数の副選択肢（「アップロード」「個別入力」「登録」及び「承認」）をディスプレイ２０に表示させる。

本実施形態では、複数のインボイスを単一の請求書として統合することで請求書を作成するが、統合対象のインボイスのデータの入力方法としては、クライアントＰＣ１６上で既に作成したインボイスのデータをウェブサーバ３４へアップロードする方法（副選択肢「アップロード」に相当）と、個々のインボイスを単位として所定の入力画面内にインボイスのデータを入力する方法（副選択肢「個別入力」に相当）が用意されている。

インボイスデータをアップロードする場合、輸出企業１２の販売部の担当者はマウス２４等を操作して副選択肢「アップロード」を選択する。請求側処理では、画面内に複数表示されている副選択肢のうちの何れかが選択されるとステップ１２６へ移行し、選択された副選択肢が「アップロード」か否か判定するが、この場合はステップ１２６の判定が肯定されてステップ１２８へ移行し、例として図９に示すように、アップロード対象のファイル（インボイスのデータ）を選択するための選択画面をディスプレイ２０に表示させる。また、次のステップ１３０では、アップロード対象のファイルが選択されたか否か判定し、判定が肯定される迄ステップ１３０を繰り返す。

図９に示す選択画面には、アップロード対象のファイルのディレクトリを指定するための指定欄３００と、アップロードの実行を指示するためのボックス３０２が設けられており、輸出企業１２の販売部の担当者は、マウス２４等を操作してアップロード対象のファイルのディレクトリを指定した後にボックス３０２をクリックする。これにより、担当者によって指定されたディレクトリに存在するアップロード対象のファイル（インボイスデータ）がＨＤＤ２６から順次読み出されてウェブサーバ３４へ送信される（図２の「アップロード」も参照）。なお、クライアントＰＣ１６からウェブサーバ３４へのインボイスデータの送信（アップロード）は、図９の選択画面のデータに埋め込まれたスクリプト（Java(R)Script等のスクリプト言語で記述されたスクリプト（プログラム))によって実現されるが、これに代えてファイル転送（ＦＴＰ(File Transfer Protocol)による転送）によってウェブサーバ３４へインボイスデータを送信するようにしてもよい。また、請求側処理ではステップ１３０の判定が肯定されてステップ１３２へ移行し、クライアントＰＣ１６から送信されたインボイスデータを受信し、ＨＤＤ４４に記憶させた後にステップ１４２へ移行する。

なお、本実施形態において、複数のインボイスを単一の請求書として統合するにあたっては、個々のインボイスのデータに付加されているドラフト番号に基づき、同一のドラフト番号が付加されてる複数のインボイスが、単一の請求書として統合すべきインボイスであると判断される。このため、インボイスの作成時には、入金管理等の都合上、単一の請求書に統合して輸入企業１４へ纏めて請求することが適当なインボイス（例えば取引先・通貨・支払期日が互いに同一のインボイス）に対して同一のドラフト番号が付加されるように、個々のインボイスデータにドラフト番号が付加される。そして、上記のアップロードにおいても、ドラフト番号が付加された状態のインボイスデータがクライアントＰＣ１６のＨＤＤ２６から読み出され、ウェブサーバ３４のＨＤＤ４４に記憶される。

一方、「個別入力」によってインボイスデータを入力する場合、輸出企業１２の販売部の担当者はマウス２４等を操作して副選択肢「個別入力」を選択する。請求側処理では、ステップ１２６の判定が否定されるとステップ１３４へ移行し、選択された副選択肢が「個別入力」か否か判定するが、この場合はステップ１３４の判定が肯定されてステップ１３６へ移行し、例として図１０に示すように、インボイスのデータを入力するための入力画面をディスプレイ２０に表示させる。次のステップ１３８ではインボイスのデータの入力が完了したか否か判定し、判定が肯定される迄ステップ１３８を繰り返す。

インボイスデータの入力画面には、インボイスを構成する各情報を入力するための入力欄が設けられており、インボイスデータの入力画面がディスプレイ２０に表示されると、輸出企業１２の販売部の担当者は、各入力欄に対応する情報を入力する。また、図１０に示すように、インボイスデータの入力画面にはドラフト番号を入力するための入力欄（「Draft No」と表記された入力欄）３０４も設けられており、「個別入力」によって請求書を作成する場合も前述と同様、単一の請求書に統合して輸入企業１４へ纏めて請求することが適当なインボイスに対して同一のドラフト番号が付加される。

データ入力が完了し、入力画面内の「登録」と表記されたボックス３０６がクリックされると、入力されたインボイスデータがクライアントＰＣ１６から送信され、このインボイスデータがウェブサーバ３４で受信されることで、ステップ１３８の判定が肯定されてステップ１４０へ移行し、インボイスデータの入力画面を介して入力されたインボイスデータ（クライアントＰＣ１６から受信したインボイスデータ）をＨＤＤ４４に記憶させた後にステップ１４２へ移行する。

次のステップ１４２ではインボイスデータの入力が完了したか否か判定する。輸出企業１２の販売部の担当者が新たなインボイスデータを入力するための操作を行うと、ステップ１４２の判定が否定されてステップ１２６に戻り、ステップ１２６以降の処理が繰り返される。これにより、新たなインボイスデータが「アップロード」又は「個別入力」で入力され、ＨＤＤ４４には複数のインボイスデータが記憶されることになる。

また、担当者がインボイスデータの入力完了を意味する操作を行うと、ステップ１４２の判定が肯定されてステップ１４４へ移行し、ＨＤＤ４４に記憶した複数のインボイスデータに各々付加されているドラフト番号を参照し、同一のドラフト番号が付加されている複数のインボイスデータ同士を統合した請求書データを生成する（図２のステップ７２も参照）。また、ステップ１４６では、ステップ１４４で生成された個々の請求書データに初期値（＝１）を設定した状態情報を各々付加し（図２のステップ７４も参照）、ＨＤＤ４４に記憶させた後にステップ１２２へ戻る。なお、状態情報＝１は対応する請求書データが「アップロード済み」の状態であることを意味している。

上記のように、複数のインボイスデータを単一の請求書データとして統合することで、以降で説明するように、輸出企業１２及び輸入企業１４における輸出入の決済に係る業務（請求書の内容確認・承認・決済等）を請求書データ単位で行うことができ、輸出入の決済に係る業務における対象数が大幅に減少される。従って、輸出企業１２及び輸入企業１４における輸出入の決済に係る業務を省力化することができる。なお、上記のステップ１４４，１４６は本発明に係る請求書データ生成手段（詳しくは請求項２に記載の請求書データ生成手段）に対応しており、ステップ１４６は請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段にも対応している。

上記のようにして請求書データの生成が完了すると、輸出企業１２の販売部の担当者は、生成された請求書データの内容を閲覧・確認して請求書ＤＢに登録する操作を行う。すなわち、輸出企業１２の販売部の担当者は、まず「請求書作成」に対応する複数の副選択肢がディスプレイ２０に表示されている状態で、マウス２４等を操作して副選択肢「登録」を選択する。

請求側処理では、ステップ１３４の判定が否定されるとステップ１４８へ移行し、選択された副選択肢が「登録」か否か判定するが、この場合はステップ１４８の判定が肯定されてステップ１５０へ移行し、ＨＤＤ４４に記憶されている状態情報＝１が付加された全ての請求書データを検索し、検索によって抽出された請求書データを、例として図１１に示すようにディスプレイ２０に一覧表示させる。なお図１１は、ウェブサーバ３４に入力された多数のインボイスデータが、取引先及び支払期日が同一で、ドラフト番号（DRAFT No）が互いに異なり、通貨が一部異なる６個の請求書データに統合された状態が示されている。また、図１１では、個々の請求書データに付加されている状態情報の内容（＝１）が表示されており、更に、状態情報が各値のときの状態が凡例として表示されているので、個々の請求書データの状態を参照者に容易に認識させることができる。上記のステップ１５０は本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

請求書データが一覧表示されると、輸出企業１２の販売部の担当者は、個々の請求書データが表す請求書の内容を閲覧・確認するために、特定の請求書データを選択して内容を表示させる操作（例えば特定の請求書データのドラフト番号の表示を選択する操作）を行う。次のステップ１５２では、請求書データの内容表示が指示されたか否か判定しており、上記の操作が行われると、ステップ１５２の判定が肯定されてステップ１５４へ移行し、例として図１２に示すように、選択された特定の請求書データが表す請求書の内容をディスプレイ２０に表示させる。なお図１２は、図１１に一覧表示されている６個の請求書データのうち、ドラフト番号「i2002010」の請求書データの内容が表示された状態（請求書データを構成するインボイスデータが一覧表示された状態）を示しており、この表示を参照することで、ドラフト番号「i2002010」の請求書データがインボイス番号(INVOICE No)「i2002010-1」〜「i2002010-6」の６個のインボイスデータを統合したデータである等を理解することができる。

また、インボイスデータが一覧表示された状態で特定のインボイスデータが表すインボイスの内容を閲覧・確認したい場合、輸出企業１２の販売部の担当者は、特定のインボイスデータを選択して内容を表示させる操作（例えば特定のインボイスデータのインボイス番号の表示を選択する操作）を行う。この操作が行われると例として図１３に示すように、選択された特定のインボイスデータが表すインボイスの内容がディスプレイ２０に表示される。なお図１３は、図１２に一覧表示されている６個のインボイスデータのうち、インボイス番号「i2002010-1」のインボイスデータの内容が表示された状態（該インボイスデータに付加されている５品目の品物の明細が一覧表示された状態）を示しており、この表示を参照することで、インボイス番号「i2002010-1」のインボイスデータの内容の詳細を理解することができる。

請求書データの内容閲覧・確認が完了すると、輸出企業１２の販売部の担当者は、該請求書データが表す請求書を、輸入企業１４への代金の請求に用いるために請求書ＤＢへ登録させる操作を行う（図２の「閲覧・登録指示」も参照）。この操作は、状態情報＝１の請求書データが一覧表示されている状態（図１１）で画面上の「一括登録」と表記されたボックス３０８を選択するか（この場合、一覧表示されている全ての請求書データが請求書ＤＢに登録される）、特定の請求書データを構成するインボイスデータが一覧表示されている状態（図１２）で画面上の「登録」と表記されたボックス３１０を選択するか、特定のインボイスデータの内容が表示されている状態（図１３）で画面上の「登録」と表記されたボックス３１２を選択することによって為される。

次のステップ１５６では請求書データの登録が指示されたか否かを判定しており、例えば図１１に示す画面上の「戻る」と表記されたボックス３１４が選択された等の場合には判定が否定され、何ら処理を行うことなくステップ１２２に戻るが、前述の「一括登録」又は「登録」のボックスを選択する操作が行われた場合には、ステップ１５６の判定が肯定されてステップ１５８へ移行し、請求書ＤＢへの登録が指示された請求書データを請求書ＤＢに登録すると共に、請求書ＤＢに登録した請求書データに付加されている状態情報を１から２へ変更（図２のステップ７６も参照）した後にステップ１２２に戻る。なお、状態情報＝２は対応する請求書データが「請求内容登録済み」の状態であることを意味している。上記のステップ１５８も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

請求書ＤＢに新たな請求書データが登録されると、輸出企業１２の販売部の管理者（取引先へ送付する請求書の適否を最終的に判断する権限を有している役職者）に対し、新たな請求書データが登録されたことが電子メールによって通知される。該電子メールによって請求書ＤＢに新たな請求書データが登録されたことを認識した輸出企業１２の販売部の管理者は、請求書ＤＢに新たに登録された請求書データの内容を閲覧・確認して承認（適否を最終判断）する操作を行う。すなわち、輸出企業１２の販売部の管理者は、まず「請求書作成」に対応する複数の副選択肢がディスプレイ２０に表示されている状態で、マウス２４等を操作して副選択肢「承認」を選択する。

請求側処理では、副選択肢「承認」が選択された場合には、ステップ１４８の判定が否定されてステップ１６０へ移行し、まず請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させ、輸出企業１２の販売部の管理者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている請求書データのうち、状態情報＝２が付加されており、かつ設定された検索条件に合致する請求書データを検索し、検索によって抽出された請求書データと、抽出された個々の請求書データに付加されている状態情報の内容（＝２）を、例として図１４に示すようにディスプレイ２０に一覧表示させる。上記のステップ１６０も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

なお、副選択肢として「承認」が選択された場合にも、前述の「登録」が選択された場合と同様、一覧表示された請求書データの内容を表示することも可能とされており、次のステップ１６２では、特定の請求書データの内容表示が指示されたか否か判定しており、輸出企業１２の販売部の管理者により、前述のように特定の請求書データの内容表示のための操作が行われると、ステップ１６２の判定が肯定されてステップ１６４へ移行し、選択された請求書データの内容の表示（請求書データを構成するインボイスデータの一覧表示：図１２参照）や、選択されたインボイスデータの内容表示（図１３参照）が行われる。

請求書データの内容閲覧・確認が完了すると、輸出企業１２の販売部の管理者は、該請求書データが表す請求書を承認する操作を行う（図２の「閲覧・請求承認（管理者）」も参照）。この操作は、例えば状態情報＝２の請求書データが一覧表示されている状態（図１４）で画面上の「承認」と表記されたボックス３１６を選択することによって為される。

次のステップ１６６では請求書データの承認が指示されたか否認が指示されたかを判定しており、否認操作が行われた場合には判定が否定され、担当者に請求書データが差し戻されてステップ１４８に戻るが（この場合、請求書データが差し戻された旨を通知する電子メールが担当者へ送信される）、前述の「承認」のボックスを選択する操作が行われた場合には、ステップ１６６の判定が肯定されてステップ１６８へ移行し、承認操作が行われた請求書データに付加されている状態情報を２から３へ変更（図２のステップ７８も参照）した後にステップ１２２に戻る。状態情報＝３は対応する請求書データが「請求内容承認済み」の状態であることを意味している。上記のステップ１６８も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

なお、請求側処理において、「請求書作成」以外の選択肢が選択された場合には、ステップ１２４の判定が否定されてステップ１７０へ移行し、選択肢「ログアウト」が選択されたか否かが判定される。「請求書閲覧」「請求書印刷」及び「異議申し立て」の何れかが選択された場合は判定が否定されてステップ１７２へ移行し、選択された選択肢に対応する処理が行われる。例えば「請求書閲覧」が選択され、請求書データの検索条件として「状態情報＝３」が設定された場合には、例として図１５に示すように、輸出企業１２の販売部の管理者による承認に伴い状態情報が３へ変更された請求書データのみが一覧表示される。また「Logout(ログアウト)」が選択された場合はステップ１７０の判定が肯定され、請求側処理を終了する。

ところで、請求書ＤＢに登録されている請求書データが輸出企業１２の販売部の管理者によって承認されると、輸入企業１４の購買部の担当者に対し、輸出企業１２の販売部の管理者によって承認された請求書データが新たに生じた（本実施形態において、これは輸出企業１２から輸入企業１４へ新たな請求書が送付されたことを意味する）ことが電子メールによって通知される。

該電子メールによって輸出企業１２から新たな請求書が送付されたことを認識した輸入企業１４の購買部の担当者は、新たに送付された請求書（請求書データ）の内容を閲覧・確認するために、電子インボイス・サイトにアクセスする。この場合、クライアントＰＣ１６を介して電子インボイス・サービスを利用しようとしている利用者は輸入企業１４の購買部に所属しているので、ウェブサーバ３４では購買側処理が行われる。以下、この購買側処理について図５を参照して説明する。

なお、購買側処理及び後述する支払側処理は、利用者が輸入企業１４に所属している場合に実行される処理であり、状態情報の内容が「１」及び「２」の請求書データはクライアントＰＣ１６のディスプレイ２０に表示されないが、利用者が輸入企業１４に所属している場合に表示対象の請求書データを上記のように制限することは、請求項３記載の表示制御手段に対応している。

ステップ１８０では、例として図１６に示すような購買側のメニュー画面をクライアントＰＣ１６のディスプレイ２０に表示させる。図１６に示すように、購買側メニュー画面には、実行可能な処理の選択肢として「請求書確認」「請求書閲覧」「異議申し立て」及び「Logout(ログアウト)」が各々表示されている。次のステップ１８２では、購買側メニュー画面内の何れかの選択肢に対応する処理の実行が指示されたか否か判定する。判定が否定された場合には、判定が肯定される迄ステップ１８２を繰り返す。

輸出企業１２から送付された請求書データを確認する場合、輸入企業１４の購買部の担当者はマウス２４等を操作して「請求書確認」を選択する。これにより、ステップ１８２の判定が肯定されてステップ１８４へ移行し、実行が指示された処理が「請求書確認」か否か判定する。この場合は判定が肯定され、ウェブサーバ３４は、例として図１７に示すように「請求書確認」に対応する副選択肢（「確認」及び「承認」）をディスプレイ２０に表示させる。そして、輸入企業１４の購買部の担当者はマウス２４等を操作して副選択肢「確認」を選択する。

購買側処理では、画面内に表示されている何れかの副選択肢が選択されるとステップ１８６へ移行し、選択された副選択肢が「確認」か否か判定するが、この場合はステップ１８６の判定が肯定されてステップ１８８へ移行し、まず表示対象の請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させた後に、輸入企業１４の購買部の担当者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている請求書データのうち、状態情報＝３が付加されており、かつ設定された検索条件に合致する請求書データを検索し、検索によって抽出された請求書データと、抽出された個々の請求書データに付加されている状態情報の内容（＝３）を、例として図１７に示すようにディスプレイ２０に一覧表示させる。上記のステップ１８８も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

請求書データが一覧表示されると、輸入企業１４の購買部の担当者は、個々の請求書データが表す請求書の内容を閲覧・確認するために、特定の請求書データを選択して内容を表示させる操作（例えば特定の請求書データのドラフト番号の表示を選択する操作）を行う。次のステップ１９０では、請求書データの内容表示が指示されたか否か判定しており、上記の操作が行われると、ステップ１９０の判定が肯定されてステップ１９２へ移行し、例として図１８に示すように、選択された特定の請求書データが表す請求書の内容をディスプレイ２０に表示させる。

なお、図１８は、図１７に一覧表示されている６個の請求書データのうち、ドラフト番号「i2002010」の請求書データの内容が表示された状態（請求書データを構成するインボイスデータが一覧表示された状態）を示している。また、個々のインボイスデータには、請求を承認するか否認するかを選択するための選択欄３１８、請求に対する異議申し立ての内容を設定するための設定欄３２０及び異議申し立てに関するコメントを記入するための記入欄３２２が設けられており、輸出企業１２から受領した商品に瑕疵が無いかどうかを検査した結果、受領した商品に数量不足やその他の瑕疵があった場合には、請求を否認したり請求に関して輸出企業１２へ異議を申し立てることを、個々のインボイスを単位として行うことも可能とされている。

また、インボイスデータが一覧表示された状態で特定のインボイスデータが表すインボイスの内容を閲覧・確認したい場合、輸入企業１４の購買部の担当者は、特定のインボイスデータを選択して内容を表示させる操作（例えば特定のインボイスデータのインボイス番号の表示を選択する操作）を行う。この操作が行われると、選択された特定のインボイスデータが表すインボイスの内容がディスプレイ２０に表示される（図１９参照）。

なお、図１９は、図１８に一覧表示されている６個の請求書データのうち、インボイス番号「i2002010-1」のインボイスデータの内容が表示された状態（当該インボイスデータを構成する明細が一覧表示された状態）を示している。個々の明細には、請求を承認するか否認するかを選択するための選択欄３１８、請求に対する異議申し立ての内容を設定するための設定欄３２０及び異議申し立てに関するコメントを記入するための記入欄３２２が設けられており、輸出企業１２から受領した商品に数量不足やその他の瑕疵があった場合に、請求を否認したり請求に関して輸出企業１２へ異議を申し立てることを、個々の明細を単位として行うことも可能とされている。なお、特定の明細、或いは特定のインボイスについて異議申し立てが行われた場合、対応する請求書データに付加されている状態情報は８へ変更される。状態情報＝８は対応する請求書データが「異議申し立て中」の状態であることを意味している。

請求書データの内容閲覧・確認が完了すると、輸入企業１４の購買部の担当者は、該請求書データが表す請求書を確認したことを意味する操作を行う（図２の「閲覧・確認」も参照）。この操作は、状態情報＝３の請求書データが一覧表示されている状態（図１７）で画面上の「一括確認」と表記されたボックス３２４を選択するか（この場合、一覧表示されている全ての請求書データに対して一括して確認処理が行われる）、特定の請求書データを構成するインボイスデータが一覧表示されており（図１９）、各インボイスデータについて選択欄３１８の「承認」が選択されている状態で画面上の「実行」と表記されたボックス３２６を選択することによって為される。

次のステップ１９４では請求書データの確認が指示されたか否かを判定しており、上記の操作が行われなかった場合は判定が否定され、何ら処理を行うことなくステップ１８２に戻るが、前述の「一括確認」又は「実行」のボックスを選択する操作が行われた場合には、ステップ１９４の判定が肯定されてステップ１９６へ移行し、確認対象の請求書データに付加されている状態情報を３から４へ変更（図２のステップ８０も参照）した後にステップ１８２に戻る。なお、状態情報＝４は対応する請求書データが「購買担当者請求内容確認済み」の状態であることを意味している。上記のステップ１９６も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

上記の処理が行われることで、図１７と同一の検索条件での検索によって抽出された請求書データを一覧表示した場合、例として図２０に示すように、確認対象の請求書データについてのみ、状態情報の内容が「４」と表示されることになる（図２０は、図１７に一覧表示されている請求書データのうち、ドラフト番号「i2002010」の請求書データについてのみ確認が行われた場合を例として示している）。

輸入企業１４の購買部の担当者によって請求書データの確認が行われると、輸入企業１４の購買部の管理者（輸入企業１４の購買部内で請求書の適否を最終的に判断する権限を有している役職者）に対し、確認・承認対象の新たな請求書データが生じたことが電子メールによって通知される。該電子メールによって確認・承認対象の新たな請求書データが生じたことを認識した輸入企業１４の購買部の管理者は、確認・承認対象の新たな請求書データの内容を閲覧・確認して承認（適否を最終判断）する操作を行う。すなわち、輸入企業１４の購買部の管理者は、まず「請求書確認」に対応する副選択肢がディスプレイ２０に表示されている状態で、マウス２４等を操作して副選択肢「承認」を選択する。

購買側処理では、副選択肢「承認」が選択された場合には、ステップ１８６の判定が否定されてステップ１９８へ移行し、まず請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させ、輸入企業１４の購買部の管理者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている請求書データのうち、状態情報＝４が付加されており、かつ設定された検索条件に合致する請求書データを検索し、検索によって抽出された請求書データと、抽出された個々の請求書データに付加されている状態情報の内容（＝４）を、例として図２１に示すようにディスプレイ２０に一覧表示させる。上記のステップ１９８も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

なお、副選択肢として「承認」が選択された場合にも、前述の「確認」が選択された場合と同様、一覧表示された請求書データの内容を表示することも可能とされている。すなわち、次のステップ２００では、特定の請求書データの内容表示が指示されたか否か判定しており、輸入企業１４の購買部の管理者により、前述のように特定の請求書データの内容表示のための操作が行われると、ステップ２００の判定が肯定されてステップ２０２へ移行し、選択された請求書データの内容の表示（請求書データを構成するインボイスデータの一覧表示：図１９も参照）や、選択されたインボイスデータの内容表示（図示省略）が行われる。

請求書データの内容閲覧・確認が完了すると、輸入企業１４の購買部の管理者は、該請求書データが表す請求書を承認する操作を行う（図２の「閲覧・承認（管理者）」も参照）。この操作は、例えば状態情報＝４の請求書データが一覧表示されている状態（図２１）で画面上の「一括承認」と表記されたボックス３２８を選択する等によって為される。

次のステップ２０４では請求書データの承認が指示されたか否認が指示されたかを判定しており、否認操作が行われた場合には判定が否定され、請求書データが購買部の担当者に差し戻されてステップ１８６に戻るが（この場合、請求書データが差し戻された旨を通知する電子メールが購買部の担当者へ送信される）、前述の「一括承認」のボックス３２８を選択する操作等が行われた場合には、ステップ２０４の判定が肯定されてステップ２０６へ移行し、承認操作が行われた請求書データに付加されている状態情報を４から５へ変更（図２のステップ８２も参照）した後にステップ１８２に戻る。状態情報＝５は対応する請求書データが「購買管理者請求内容承認済み」の状態であることを意味している。上記のステップ２０６も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

上記の処理が行われることで、図２１と同一の検索条件での検索によって抽出された請求書データを一覧表示した場合、例として図２２に示すように、承認対象の請求書データについてのみ、状態情報の内容が「５」と表示されることになる（図２２は、図２１に一覧表示されている請求書データのうち、ドラフト番号「i2002010」の請求書データについてのみ承認が行われた場合を例として示している）。

なお、購買側処理において、「請求書作成」以外の選択肢が選択された場合には、ステップ１８４の判定が否定されてステップ２０８へ移行し、選択肢「ログアウト」が選択されたか否かが判定される。「請求書閲覧」又は「異議申し立て」が選択された場合は判定が否定されてステップ２１０へ移行し、選択された選択肢に対応する処理が行われる。また「Logout(ログアウト)」が選択された場合はステップ２０８の判定が肯定され、購買側処理を終了する。

ところで、請求書ＤＢに登録されている請求書データが輸入企業１４の購買部の管理者によって承認されると、輸入企業１４の経理部の担当者に対し、輸出企業１２に対して支払いを行うべき請求書データが新たに生じたことが電子メールによって通知される。該電子メールによって支払いを行うべき請求書データが新たに生じたことを認識した輸入企業１４の経理部の担当者は、支払いを行うべき請求書データの内容を閲覧・確認して支払内容を登録するために、電子インボイス・サイトにアクセスする。この場合、クライアントＰＣ１６を介して電子インボイス・サービスを利用しようとしている利用者は輸入企業１４の経理部に所属しているので、ウェブサーバ３４では支払側処理が行われる。以下、この支払側処理について図６を参照して説明する。

ステップ２３０では、例として図２３に示すような支払側のメニュー画面をクライアントＰＣ１６のディスプレイ２０に表示させる。図２３に示すように、支払側メニュー画面には、実行可能な処理の選択肢として「支払内容確認」「請求書閲覧」「支払内容閲覧」及び「Logout(ログアウト)」が各々表示されている。次のステップ２３２では、支払側メニュー画面内の何れかの選択肢に対応する処理の実行が指示されたか否か判定する。判定が否定された場合には、判定が肯定される迄ステップ２３２を繰り返す。

支払いを行うべき請求書データの内容を閲覧・確認して支払内容を登録する場合、輸入企業１４の経理部の担当者はマウス２４等を操作して「支払内容確認」を選択する。これにより、ステップ２３２の判定が肯定されてステップ２３６へ移行し、実行が指示された処理が「支払内容確認」か否か判定する。この場合は判定が肯定され、ウェブサーバ３４は、例として図２４に示すように「支払内容確認」に対応する副選択肢（「確認」「承認」及び「依頼書出力」）をディスプレイ２０に表示させる。そして、輸入企業１４の経理部の担当者はマウス２４等を操作して副選択肢「確認」を選択する。

支払側処理では、画面内に表示されている何れかの副選択肢が選択されるとステップ２３６へ移行し、選択された副選択肢が「確認」か否か判定するが、この場合はステップ２３６の判定が肯定されてステップ２３７へ移行し、ネッティング有りか否か判定する。詳細は後述するが、本実施形態に係る電子インボイス・サービスでは、債権と債務の相殺を可能とするネッティング・サービスも提供している。ネッティング・サービスを利用する企業は、電子インボイス・サービスの利用を申し込む際にネッティング・サービスの利用も申請する。ネッティング・サービスの利用を申請した企業は、電子インボイス・サービスを利用する各企業に関する情報を登録するための企業マスタにネッティング対象企業として登録される。ステップ２３７では、輸入企業１４が企業マスタにネッティング対象企業として登録されているか否かを判断することで、ネッティング有りか否かを判定している。

上記ステップ２３７の判定が否定された場合にはステップ２３８へ移行し、まず表示対象の請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させた後に、輸入企業１４の経理部の担当者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている請求書データのうち、状態情報＝５が付加されており、かつ設定された検索条件に合致する請求書データを検索し、検索によって抽出された請求書データと、抽出された個々の請求書データに付加されている状態情報の内容（＝５）を、例として図２４に示すようにディスプレイ２０に一覧表示させる。上記のステップ２３８も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

次のステップ２４０では取りまとめの実行が指示されたか否か判定し、判定が肯定される迄ステップ２４０を繰り返す。図２４に示すように請求書データが一覧表示されると、輸入企業１４の経理部の担当者は、支払対象の数を減少させるために、画面内の「取りまとめ実行」と表記されているボックス３３０をクリックすることで、請求書データの取りまとめの実行を指示する操作を行う（図２の「閲覧・取りまとめ指示」も参照）。これにより、ステップ２４０の判定が肯定されてステップ２４２へ移行し、一覧表示している請求書データのうち、取引先・通貨が互いに同一の複数の請求書データを単一の支払いデータへ取りまとめる（取りまとめ後の請求書を統合請求書と称する）ことで、該統合請求書を表す統合請求書データを生成すると共に、個々の統合請求書に識別番号（REF No）を各々付与する（図２のステップ８４も参照）。なお、ステップ２４２は請求項６に記載の請求書データ統合手段に対応している。

そして、次のステップ２４４では例として図２５に示すように、統合請求書を識別番号と共にディスプレイ２０に一覧表示させる。なお図２５は、図２４に一覧表示されている請求書データのうち、ドラフト番号「i2002010」「i2002011」「i2002012」の３個の請求書データが識別番号「00001」の統合請求書に取りまとめられ、ドラフト番号「i2002013」「i2002014」の２個の請求書データが識別番号「00002」の統合請求書に取りまとめられ、ドラフト番号「i2002015」の請求書データが識別番号「00003」の統合請求書として表示されている状態が示されている。

統合請求書が一覧表示されると、輸入企業１４の経理部の担当者は、個々の統合請求書の内容を閲覧・確認するために、特定の統合請求書を選択して内容を表示させる操作（例えば特定の統合請求書の識別番号の表示を選択する操作）を行う。次のステップ２４６では、特定の統合請求書の内容表示が指示されたか否か判定しており、上記の操作が行われると、ステップ２４６の判定が肯定されてステップ２４８へ移行し、例として図２６に示すように、選択された特定の統合請求書の内容をディスプレイ２０に表示させる。

なお、図２６は、図２５に一覧表示されている３個の統合請求書のうち、識別番号「00001」の統合請求書の内容が表示された状態（統合請求書として取りまとめられた３個の請求書データが一覧表示された状態）を示している。また、単一の統合請求書として取りまとめられた請求書データが一覧表示された状態で特定の請求書データの内容を閲覧・確認したい場合、輸入企業１４の経理部の担当者は、特定の請求書データを選択して内容を表示させる操作（例えば特定の請求書データのドラフト番号の表示を選択する操作）を行う。この操作が行われると、選択された特定の請求書データの内容がディスプレイ２０に表示される（図示省略）。

特定の統合請求書の内容閲覧・確認が完了すると、輸入企業１４の経理部の担当者は、特定の統合請求書について支払方法の登録を行うことを意味する操作を行う。特定の統合請求書として取りまとめられた請求書データが一覧表示されている状態（図２６）で、画面上の「支払方法登録」と表記されたボックス３３２を選択することによって為される。次のステップ２５０では支払方法の登録が指示されたか否かを判定しており、上記の操作が行われなかった場合は判定が否定され、何ら処理を行うことなくステップ２３２に戻るが、「支払方法登録」のボックス３３２を選択する操作が行われた場合には、ステップ２５０の判定が肯定されてステップ２５２へ移行し、例として図２７に示すように、特定の統合請求書についての支払方法を登録するための画面をディスプレイ２０に表示させる。

この支払方法登録画面は、輸入地金融機関５２に仕向送金を依頼する際に作成すべき送金依頼書のレイアウトとされており、「送金種類」「支払銀行手数料負担区分」「受取人銀行名」「受取人支店名」「口座番号」「送金依頼銀行・支店」「引落口座番号」「対価区分」「送金目的」等の情報を設定するための設定欄が各々設けられている。支払方法登録画面がディスプレイ２０に表示されると、輸入企業１４の経理部の担当者は各設定欄に対応する情報を各々設定する。そして、支払方法の設定が完了すると、設定した情報の登録を指示する操作（支払方法登録画面上の「登録」と表記されたボックス３３４を選択する操作）を行う（図２の「閲覧・支払方法登録」も参照）。

次のステップ２５４では、支払方法登録画面上で設定された情報の登録が指示されたか否か判定しており、上記の操作が行われるとステップ２５４の判定が肯定されてステップ２５６へ移行し、設定された情報を特定の統合請求書のデータに送金依頼書データとして付加する（図２のステップ８６も参照）と共に、特定の統合請求書のデータに付加されている状態情報を５から６へ変更（図２のステップ８８も参照）した後にステップ１８２に戻る。なお、状態情報＝６は対応する請求書データが「支払内容登録済み」の状態であることを意味している。上記のステップ２５６も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

上記の処理が行われることで、統合請求書を一覧表示した場合、例として図２８に示すように、支払方法が設定されて送金依頼書データが付加された統合請求書についてのみ、状態情報の内容が「６」と表示されることになる（図２８は、図２５に一覧表示されている統合請求書のうち、識別番号「00001」の統合請求書についてのみ支払方法の設定・送金依頼書データの付加が行われた場合を例として示している）。

一方、先のステップ２３７でネッティング有りと判定された場合はステップ２８６へ移行する。ネッティングには、通貨が同一の債権・債務についてのみネッティングを行う「シングルカレンシー」と、債権・債務を事前に取り決めた換算レートで特定の基軸通貨に換算することで通貨が異なる債権・債務に対してもネッティングを行う「マルチカレンシー」がある。本実施形態に係るネッティング・サービスはネッティング対象をシングルカレンシーとすることもマルチカレンシーとすることも可能であり、ネッティング対象をシングルカレンシーとするかマルチカレンシーとするかは、ネッティング・サービスの利用申請時に企業によって指定される。なお、ネッティング対象としてマルチカレンシーが指定された場合には、基軸通貨及び換算レートの取り決めも同時に行われる。

またネッティングには、決済形態として、二者間で債権・債務のネッティングを行う「バイラテラル・ネッティング」と、三者以上の間で債権・債務のネッティングを行う「マルチラテラル・ネッティング」があり、本実施形態に係るネッティングサービスは決済形態をバイラテラル・ネッティングとすることもマルチラテラル・ネッティングとすることも可能とされている。なお、バイラテラル・ネッティングでは二者のうち債務額が多い方によってネッティング尻の決済（支払：本システムでは後述する送金依頼書の作成）が行われる。また、マルチラテラル・ネッティングではネッティングセンター（例えば企業グループであれば通常は親企業）を介してネッティング尻の決済が行われ、例えばネッティングを行った結果、Ｂ社の債務額が債権額を越えていた場合、本システムではＢ社によってネッティングセンター（例えば親企業）宛の送金を依頼する送金依頼書が作成される。決済形態をバイラテラル・ネッティングとするかマルチラテラル・ネッティングとするかについても、ネッティング・サービスの利用申請時に企業によって指定される。

ステップ２８６では、まず表示対象（ネッティング対象）の請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させた後に、輸入企業１４の経理部の担当者によって検索条件（例えば支払期日等の条件）が設定されると、事前に設定されたネッティングの条件（ネッティング対象がシングルカレンシーかマルチカレンシーか）に基づき、請求書ＤＢに記憶されている請求書データのうち、状態情報＝５が付加されており、かつ設定された検索条件に合致するネッティング対象の請求書データ（マルチカレンシーであれば支払期日が同一の請求書データ、シングルカレンシーであれば支払期日が同一かつ通貨が同一の請求書データ）を、請求分及び被請求分について各々検索する。次に、検索によって抽出された請求書データに対し、事前に設定されたネッティングの条件（ネッティング対象／決済形態）に基づいてネッティングを行った場合の結果（支払／受取の種別や支払又は受取金額）を演算し（ネッティング対象がマルチカレンシーの場合は、必要に応じて基軸通貨への換算が行われた後にネッティングの演算が行われる）、演算結果に対して識別番号（REF No）を付与する。そして、例として図３３に示すように、検索によって抽出されたネッティング対象の請求書データと、抽出された個々の請求書データに付加されている状態情報の内容（＝５）を、請求分と被請求分とに分けてディスプレイ２０に一覧表示させると共に、ネッティングの演算結果を「ネッティング後支払い・受取金額」として識別番号（REF No）と共にディスプレイ２０に表示させる。なお、図３３は決済形態がマルチラテラル・ネッティングの場合を例として示している。

次のステップ２８８では、ネッティングの演算結果に基づき、支払金額が受取金額よりも大きいか否か、すなわち支払／受取の種別が「支払」か否か判定する。判定が否定された場合は、ディスプレイ２０に一覧表示された請求書データに関しては、輸入企業１４が支払（送金依頼書の作成）を行う必要はないので、輸入企業１４の経理部の担当者が表示内容を確認したことを意味する操作を行ったことをトリガとして、ステップ２９０で一覧表示している請求書データに付加されている状態情報を５から５０へ変更した後にステップ２８０へ移行する。なお、状態情報＝５０は対応する請求書データが「ネッティングにより支払不要」の状態であることを意味している。

また、支払金額が受取金額よりも大きい場合、ディスプレイ２０に一覧表示された請求書データに関して、輸入企業１４が支払（送金依頼書の作成）を行う必要がある。このため、ステップ２８８の判定が肯定された場合はステップ２４６へ移行する。前述のステップ２８６では、ネッティング演算の結果、支払／受取の種別が「支払」であった場合、ネッティングの演算結果を表すデータ（ネッティングデータ）に、ネッティングの条件（決済形態）に応じて支払先（請求元）を表す情報が自動的に設定される（決済形態がバイラテラル・ネッティングの場合はネッティング対象の請求書データにおける支払先がそのまま支払先として設定され、決済形態がマルチラテラル・ネッティングの場合はネッティングセンターとして事前に登録された企業が支払先として設定される）。そして、ステップ２４６以降では、支払先を表す情報が付加されたネッティングデータが、複数の請求書データを取りまとめた統合請求書として扱われ、先にも説明したように、必要に応じて統合請求書（ネッティングデータ）の内容が閲覧・確認された後に、支払方法が登録されることで送金依頼書データが付加され、状態情報が５から６０へ変更されることになる。なお、状態情報＝６０は対応する請求書データが「ネッティング後に支払内容を登録した」状態であることを意味している。また、後述するように、この請求書データが輸入企業１４の経理部の管理者により承認されると、状態情報は６０から７０へ変更されることになる。

輸入企業１４の経理部の担当者によって統合請求書への支払方法の設定・送金依頼書データの付加が行われると、輸入企業１４の経理部の管理者（輸入企業１４の経理部内で輸出企業１２への支払いの適否を最終的に判断する権限を有している役職者）に対し、確認・承認対象の新たな統合請求書が生じたことが電子メールによって通知される。該電子メールによって確認・承認対象の新たな統合請求書が生じたことを認識した輸入企業１４の経理部の管理者は、確認・承認対象の新たな統合請求書の内容を閲覧・確認して承認（適否を最終判断）する操作を行う。すなわち、輸入企業１４の経理部の管理者は、まず「支払内容確認」に対応する副選択肢がディスプレイ２０に表示されている状態で、マウス２４等を操作して副選択肢「承認」を選択する。

支払側処理では、ステップ２３６の判定が否定された場合にはステップ２５８へ移行し、選択された副選択肢が「登録」か否か判定するが、この場合はステップ２５８の判定が肯定されてステップ２６０へ移行し、まず統合請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させ、輸入企業１４の経理部の管理者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている統合請求書データのうち、状態情報＝６が付加されており、かつ設定された検索条件に合致する統合請求書データを検索し、検索によって抽出された統合請求書データと、抽出された個々の統合請求書データに付加されている状態情報の内容（＝６）を、例として図２９に示すようにディスプレイ２０に一覧表示させる。上記のステップ２６０も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

なお、副選択肢として「承認」が選択された場合にも、前述の「確認」が選択された場合と同様、一覧表示された統合請求書データの内容を表示することも可能とされている。すなわち、次のステップ２６２では、特定の統合請求書データの内容表示が指示されたか否か判定しており、輸入企業１４の経理部の管理者により、前述のように特定の統合請求書データの内容表示のための操作が行われると、ステップ２６２の判定が肯定されてステップ２６４へ移行し、選択された特定の統合請求書データの内容の表示（統合請求書として取りまとめられた請求書データの一覧表示：図２６も参照）や、選択された請求書データの内容表示（図示省略）が行われる。

統合請求書データの内容閲覧・確認が完了すると、輸入企業１４の経理部の管理者は、該統合請求書についての支払いを承認する操作を行う（図２の「閲覧・支払承認（管理者）」も参照）。この操作は、例えば統合請求書データが一覧表示されている状態（図２９）で画面上の「一括承認」と表記されたボックス３３６を選択する等によって為される。

次のステップ２６６では統合請求書についての支払いが承認されたか否かを判定しており、否認操作が行われた場合には判定が否定され、統合請求書のデータは経理部の担当者に差し戻されてステップ２３２に戻るが、前述の「一括承認」のボックス３３６を選択する操作等が行われた場合には、ステップ２６６の判定が肯定されてステップ２６８へ移行し、承認操作が行われた統合請求書データに付加されている状態情報を６から７へ変更（図２のステップ９０も参照）した後にステップ２３２に戻る。なお、状態情報＝７は対応する請求書データが「支払管理者の承認済み」の状態であることを意味している。上記のステップ２６８も請求項３に記載の第１の請求書データ管理手段及び請求項４に記載の第２の請求書データ管理手段に対応している。

上記の処理が行われることで、輸出企業１２側で請求書データを閲覧した場合（図２の「閲覧（入金予定確認）」も参照）に、例として図３２に示すように、輸入企業１４の経理部の管理者によって支払いが承認された請求書データについてのみ、状態情報の内容が「７」と表示されることになる（図３２は、図２５に一覧表示されている統合請求書のうち、識別番号「00001」の統合請求書についてのみ支払いが承認された場合を例として示している）。状態情報の内容が「７」とされている請求書データは、輸入企業１４の経理部の管理者によって支払いが承認されているので、支払期日迄には支払いが行われると判断することができ、輸出企業１２側で入金予定を把握することができる。

輸入企業１４の経理部の管理者によって統合請求書についての支払いが承認されると、輸入企業１４の経理部の担当者に対し、支払いを行うべき統合請求書が生じたことが電子メールによって通知される。該電子メールによって支払いを行うべき統合請求書が生じたことを認識した輸入企業１４の経理部の担当者は、支払い対象の統合請求書の送金依頼書をデータとして出力させる操作を行う。すなわち、輸入企業１４の経理部の担当者は、まず「支払内容確認」に対応する副選択肢がディスプレイ２０に表示されている状態で、マウス２４等を操作して副選択肢「依頼書出力」を選択する。

支払側処理では、選択された副選択肢が「依頼書出力」であれば、ステップ２５８の判定が否定されてステップ２７０へ移行し、まず統合請求書データの検索条件を設定するための設定画面をディスプレイ２０に表示させ、輸入企業１４の経理部の担当者によって検索条件（例えば支払期日等の条件）が設定されると、請求書ＤＢに記憶されている統合請求書データのうち、状態情報＝７が付加されており、かつ設定された検索条件に合致する統合請求書データを検索し、検索によって抽出された統合請求書データと、抽出された個々の統合請求書データに付加されている状態情報の内容（＝７）を、例として図３０に示すようにディスプレイ２０に一覧表示させる。上記のステップ２７０も本発明に係る表示制御手段（詳しくは請求項４に記載の表示制御手段）に対応している。

支払対象の統合請求書データが一覧表示されると、輸入企業１４の経理部の担当者は、処理対象の特定の統合請求書の選択する操作を行う。この操作は、例えば統合請求書データが一覧表示されている状態（図３０）で、特定の統合請求書の識別番号の表示を選択する等によって為される。次のステップ２７２では特定の統合請求書が選択されたか否かを判定し、判定が肯定される迄ステップ２７２を繰り返しており、特定の統合請求書が選択されるとステップ２７２の判定が肯定されてステップ２７４へ移行し、選択された特定の統合請求書データに付加されている送金依頼書データをＨＤＤ４４から読み出し、読み出した送金依頼書データを、例として図３１に示すように、輸入地金融機関５２に仕向送金を依頼することで特定の統合請求書についての支払いを行うための送金依頼書としてディスプレイ２０に表示させる。

特定の統合請求書についての送金依頼書がディスプレイ２０に表示されると、輸入企業１４の経理部の担当者は、表示された送金依頼書をデータとして出力させる操作を行う（図２の「データ出力指示」も参照）。この操作は、例えば送金依頼書が表示されている状態（図３１）で、画面上の「依頼書データ出力」と表記されたボックス３３８を選択する等によって為される。なお、画面上の「依頼書印刷」と表記されたボックス３４０を選択することで、ディスプレイ２０に表示されている送金依頼書を印刷出力させることも可能とされている。

次のステップ２７６では送金依頼書のデータ出力が指示されたか否かを判定しており、データ出力が指示されなかった場合には判定が否定され、何ら処理を行うことなくステップ２３２に戻るが、送金依頼書をデータとして出力させることを指示する操作が行われた場合には、ステップ２７６の判定が肯定されてステップ２７８へ移行し、ディスプレイ２０に送金依頼書として表示させている送金依頼書データを、特定のデータ形式（例えばＣＳＶ(Comma Separated Value)形式等）のデータとしてクライアントＰＣ１６へ送信する。上記のステップ２７８は、先に説明したステップ２５６と共に本発明に係る決済処理手段（詳しくは請求項５に記載の決済処理手段）に対応している。

なお、支払側処理において、「支払内容確認」以外の選択肢が選択された場合には、ステップ２３４の判定が否定されてステップ２８０へ移行し、選択肢「ログアウト」が選択されたか否かが判定される。「請求書閲覧」又は「支払内容閲覧」が選択された場合は判定が否定されてステップ２８２へ移行し、選択された選択肢に対応する処理が行われる。また「Logout(ログアウト)」が選択された場合はステップ２８２の判定が肯定され、支払側処理を終了する。

ウェブサーバ３４から送信された送金依頼書データがクライアントＰＣ１６で受信されると、輸入企業１４の経理部の担当者は、特定のクライアントＰＣ１６（金融取引支援プログラムがインストールされているクライアントＰＣ１６）上で金融取引支援プログラムを実行し、受信した送金依頼書データを金融取引支援プログラムによって公衆電話回線経由で輸入地金融機関５２のホスト・コンピュータ５４へ送信することで、輸入地金融機関５２に仕向送金を依頼する（図２のステップ９４も参照）。輸入地金融機関５２ではＳ.Ｗ.Ｉ.Ｆ.Ｔ５８のネットワーク等を介して、輸入企業１４から依頼された仕向送金を輸出地金融機関４６宛に行う。輸出地金融機関４６は、輸出企業１２の口座に送金代金を入金することで、ウェブサーバ３４から輸入企業１４のクライアントＰＣ１６へ送信された送金依頼書データに対応する特定の統合請求書についての決済（統合請求書として統合された複数の請求書についての決済）が完了する。

輸出地金融機関４６は、輸出企業１２の口座への入金を行うと、入金処理の内容を輸出企業１２へ通知するための入金明細情報を生成する。この入金明細情報は、輸出企業１２の特定のクライアントＰＣ１６（金融取引支援プログラムがインストールされているクライアントＰＣ１６）上で金融取引支援プログラムを実行し、受信処理を行うことで輸出企業１２の特定のクライアントＰＣ１６で受信されるが、この入金明細情報を電子インボイス・サービスに取り込んで輸出企業１２が利用することも可能とされている。

なお、本実施形態に係る電子インボイス・サービスは、親会社が、同一の企業グループに属する子会社を閲覧対象として予め登録しておくことにより、子会社間の請求のやり取りを親会社がディスプレイ上で閲覧したり、ウェブサーバ３４からデータとしてダウンロードすることも可能とするサービスも提供している。現在、企業グループの親会社は、四半期、半期、年度毎に連結決算対象の企業（同一の企業グループに属する子会社等）の財務諸表を手作業で作成しているが、この財務諸表の作成にあたっては、全社の債権・債務を一定の時点で確定することが困難であるという問題がある。これに対し、上記のサービスを利用することにより、或る状態以前の債権・債務（例えば状態情報＝６迄の請求書データ）を全て表示又はダウンロードすることができるので、同一の企業グループに属する全社について、同一条件の下で売掛債権、買掛債務の残高を把握することが可能となり、連結決算のための財務諸表の作成を容易に行うことができる。

また、上記では同一のドラフト番号が付加されてる複数のインボイスを単一の請求書として統合する例を説明したが、本実施形態に係る電子インボイス・サービスは、予め設定することでインボイス＝請求書として扱うことも可能とされている。

また、上記では説明を省略したが、本実施形態に係る電子インボイス・サービスには、経費を請求したり、一度支払った破損商品の返金を請求する機能（デビットノート機能）や、経費や破損商品の返金等を能動的に支払うための機能（クレジットノート機能）も付加されており、輸出及び輸入を各々行っている企業については、請求と、購買／支払いの双方の業務を行うことも可能とされている。

なお、上記では同一のドラフト番号が付加されてる複数のインボイスを単一の請求書として統合する例を説明したが、これに限定されるものではなく、例えば個々のインボイスの支払期日、輸入者（取引先）及び取引通貨を比較し、支払期日、輸入者及び取引通貨が全て同一のインボイスを単一の請求書として統合するようにしてもよい。

また、上記では送金依頼書のデータ出力が指示されると、ウェブサーバ３４が送金依頼書データを輸入企業１４のクライアントＰＣ１６へ送信し、輸入企業１４が輸入地金融機関５２へ送金依頼書データを送信することで仕向送金が依頼される例を説明したが、これに限定されるものではなく、例えば送金依頼が指示されるとウェブサーバ３４から輸入地金融機関５２のホスト・コンピュータ５４へ送金依頼書データを直接送信するようにしてもよい。

本実施形態に係るコンピュータ・システムの概略構成を示すブロック図である。 インボイスデータの作成から統合請求書を単位とする支払いに至るシーケンス図である。 ウェブサーバで実行される電子インボイス処理の内容を示すフローチャートである。 請求側処理の内容を示すフローチャートである。 購買側処理の内容を示すフローチャートである。 支払側処理の内容を示すフローチャートである。 ログイン画面の一例を示すイメージ図である。 請求側のメニュー画面の一例を示すイメージ図である。 インボイスデータのアップロード画面の一例を示すイメージ図である。 インボイスデータ作成画面の一例を示すイメージ図である。 請求書データ登録時の画面の一例を示すイメージ図である。 単一の請求書に対応する複数のインボイスの一覧表示画面の一例を示すイメージ図である。 単一のインボイスの明細表示画面の一例を示すイメージ図である。 請求側における承認対象の請求書一覧表示画面の一例を示すイメージ図である。 請求側における承認後の請求書一覧表示画面の一例を示すイメージ図である。 購買側のメニュー画面の一例を示すイメージ図である。 購買側における確認対象の請求書一覧表示画面の一例を示すイメージ図である。 購買側における確認対象の単一の請求書に対応する複数のインボイスの一覧表示画面の一例を示すイメージ図である。 購買側における確認対象の単一のインボイスに対応する複数の明細の一覧表示画面の一例を示すイメージ図である。 購買側における確認後の請求書一覧表示画面の一例を示すイメージ図である。 購買側における承認対象の請求書一覧表示画面の一例を示すイメージ図である。 購買側における承認後の請求書一覧表示画面の一例を示すイメージ図である。 支払側のメニュー画面の一例を示すイメージ図である。 支払側における確認対象の請求書一覧表示画面の一例を示すイメージ図である。 支払側における取りまとめ後の統合請求書一覧表示画面の一例を示すイメージ図である。 支払側における処理対象の単一の統合請求書に対応する複数の請求書の一覧表示画面の一例を示すイメージ図である。 支払方法登録画面の一例を示すイメージ図である。 支払方法登録後の統合請求書一覧表示画面の一例を示すイメージ図である。 支払側における承認対象の統合請求書一覧表示画面の一例を示すイメージ図である。 支払側における承認後の統合請求書一覧表示画面の一例を示すイメージ図である。 支払側における支払方法確認画面の一例を示すイメージ図である。 請求側における、入金予定の請求書を含む請求書一覧表示画面の一例を示すイメージ図である。 支払側におけるネッティング対象の請求書一覧表示画面の一例を示すイメージ図である。

符号の説明

１０ コンピュータ・システム
１６ クライアントＰＣ
２０ ディスプレイ
２２ キーボード
２４ マウス
３２ インターネット
３４ ウェブサーバ
４８ ホスト・コンピュータ

Claims (7)

1. 輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続された貿易取引の決済支援装置であって、
   情報を記憶するための記憶手段と、
   輸出者側で作成されて輸出者のクライアント・コンピュータからデータとして受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを前記記憶手段に記憶させる請求書データ生成手段と、
   前記記憶手段に記憶されている請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる表示制御手段と、
   輸入者のクライアント・コンピュータの表示装置に前記請求書が表示されている状態で、輸入者によって特定の請求書が選択されて決済が指示されると、選択された特定の請求書についての決済のための処理を行う決済処理手段と、
   を含む貿易取引の決済支援装置。
2. 前記請求書データ生成手段は、前記所定の条件として、輸出者によって個々の商業送り状データに予め付与された識別情報が同一、又は、期日、輸入者及び取引通貨が同一の複数の商業送り状を単一の請求書に統合することを特徴とする請求項１記載の貿易取引の決済支援装置。
3. 前記請求書データ生成手段によって生成された請求書データに状態情報を付加すると共に、個々の請求書データに付加した状態情報の内容を、少なくとも、対応する請求書データが表す請求書が輸出者側で承認されているか否かに応じて相違させる第１の請求書データ管理手段を更に備え、
   前記表示制御手段は、前記請求書データに付加されている状態情報に基づき、輸出者側で承認されている状態の請求書のみを輸入者のクライアント・コンピュータの表示装置に表示させることを特徴とする請求項１記載の貿易取引の決済支援装置。
4. 前記請求書データ生成手段によって生成された請求書データに状態情報を付加すると共に、個々の請求書データに付加した状態情報の内容を、対応する請求書データが表す請求書の状態の変化に応じて変化させる第２の請求書データ管理手段を更に備え、
   前記表示制御手段は、請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる際に、前記状態情報の内容も表示させることを特徴とする請求項１記載の貿易取引の決済支援装置。
5. 前記決済処理手段は、前記決済のための処理として、前記特定の請求書のデータに基づき、輸入者が輸出者への送金を金融機関に依頼するための送金依頼書データを生成・出力する処理を行うことを特徴する請求項１記載の貿易取引の決済支援装置。
6. 輸入者側からの指示に応じて、所定の条件に合致する複数の請求書データを単一の支払データに統合する請求書データ統合手段を更に備えたことを特徴とする請求項１記載の貿易取引の決済支援装置。
7. 輸出者及び輸入者が各々所持しているクライアント・コンピュータと通信回線を介して接続され、情報を記憶するための記憶手段を備えたコンピュータを、
   輸出者側で作成されて輸出者のクライアント・コンピュータからデータとして受信した複数の商業送り状のうち、所定の条件に合致する複数の商業送り状を単一の請求書に統合し、統合した請求書を表す請求書データを前記記憶手段に記憶させる請求書データ生成手段、
   前記記憶手段に記憶されている請求書データが表す請求書をクライアント・コンピュータの表示装置に表示させる表示制御手段、
   及び、輸入者のクライアント・コンピュータの表示装置に前記請求書が表示されている状態で、輸入者によって特定の請求書が選択されて決済が指示されると、選択された特定の請求書についての決済のための処理を行う決済処理手段
   として機能させるためのプログラム。

Images