JP4926404B2 - 電子請求書の提示および支払いに対する方法およびソフトウェアアプリケーション - Google Patents

Description

発明の背景
発明の技術分野
本発明の技術分野は、電子データ処理の分野である。より詳細には本発明は、自動的な請求システムのための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。さらに詳細には、遠隔からの確認および支払いのためにカスタマへ送付される電子的な明細請求書の処理、生成および提示のための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。

関連分野の説明
ここで使用されているような用語「提示（presentment）」は、通常はコマーシャルペーパーに関連する特別な定義を含んでいないことを理解されたい。すなわち、名宛人に対する譲渡可能な文書に基づく提示という定義を含んでいないことを理解されたい。むしろこの用語は、電子的手段を介して情報を提供すること、とりわけ、少なくとも同一のカスタマ請求データを含む「明細請求書」を提供することを指している。これは、典型的には紙の明細請求書に記載されているカスタマ請求データである。電子的な提示は有利には、インターネットウェブサイトまたはイントラネットウェブサイトを使用することによって行うか、またはｅメールまたはＳＭＳを使用することによって行うことができ、例えば１つまたは複数の人に対してアクセス可能にすることによって行うことができるが、それに限定される訳ではない。電子的提示はさらに、コンピュータ読み出し可能な記憶媒体を、例えば標準的な郵便を介して送付することによって行うこともできる。このコンピュータ読み出し可能な記憶媒体は、ディスク、ＺＩＰディスク、光磁気ディスク、ＣＤ‐ＲＯＭ、ＣＤＲＷ‐ＲＯＭ、ＤＶＤ‐ＲＯＭ等である。

エンタープライズリソースプランニングソフトウェア（ＥＲＰ enterprise resource planning software）の環境における電子請求書提示支払い（ＥＢＰＰ electronic bill presentment and payment）のための方法およびシステムが、従来技術から公知である。ＵＳ６０４４３６２において、自動的な電子的明細請求書生成および支払いのためのシステムが開示されている。このシステムによって遠隔のカスタマが、明細請求書の請求者からの自動請求を確認することができる。このシステムは明細請求書提示電子装置を有しており、この明細請求書提示電子装置には制御システムおよび第１の電子通信装置が設けられている。このシステムは、カスタマインタフェースを備えている少なくとも１つの遠隔認証端末も有しており、この端末には第２の電子通信装置が設けられており、この第２の電子通信装置は、操作により第１の電子通信装置と通信するように適合化されている。明細請求書提示電子装置の制御システムは、自動請求に対してあらかじめ認証されたカスタマ明細請求書について、第１の電子通信装置へ請求データを供給するように適合化されている。これは第２の電子通信装置へ伝送するためである。遠隔認証端末のカスタマインタフェースは、請求データをカスタマに提示し、請求データに関連する応答をカスタマから受信するように適合化されている。この応答は、自動請求のための請求データの承諾か、または自動請求を変更するための請求データの変更のいずれかを示す。承諾は、カスタマからの能動的な応答か、または受動的な応答とすることができる。受動的な応答は例えば、事前設定された限度までの自動的な承諾である。

ＵＳ５４６５２０６には、事前設定された規則にしたがって動作する請求書支払いシステムが開示されており、この請求書支払いシステムでは、関与するカスタマにより、関与する請求者に請求額が支払われる。関与するカスタマは関与する請求者から、金額および一意の請求者識別番号を示す請求書（紙／郵便の請求書、ｅメール通知の請求書、自動的借入のための暗黙的な請求書）を受け取る。送金額を認証するためには、カスタマは銀行（関与する銀行）へ請求書支払いオーダを送信する。この請求書支払いオーダは、支払い日、支払い額、請求者に伴うこのカスタマの口座番号、資金源および請求者の請求者識別番号を直接示しており、またはこれらのデータ要素を含む静的データへの参照によって示している。銀行Ｃは支払いメッセージを支払いネットワークへ送信し、請求者参照番号を割り当てるこの支払いネットワークは、支払いメッセージを請求者の銀行へ転送する。清算に対してカスタマの銀行はカスタマの口座に借方記入し、支払いネットワークと共に正味持ち高（net position）に対して支払い義務を負う。また請求者の銀行は正味持ち高を支払いネットワークから受信し、請求者の銀行口座に貸方記入する。保証された支払いネットワークのケースでは、カスタマの銀行が、取消不可（non-reversible）な支払いメッセージを送信することに同意した場合、資金不足の場合にこのカスタマの銀行が損失のリスクを負うことを同意しないかぎり、資金が十分になるまでこのカスタマの銀行はトランザクションを送信しない。請求者の銀行は、支払いメッセージの受信に応じて資金を請求者に解放し、請求者Ｂが指示した形態でＡ／Ｒデータを請求者へ供給する。この形態は、請求者に対して例外項目として処理する必要がない形態である。トランザクションが支払いネットワークのあらかじめ定めた規則に準じて取消可能なトランザクションでない場合、請求者の銀行はこの支払いネットワークによる支払いが保証される。特別な実施形態では、カスタマは請求額支払いオーダを手動で、すなわちＡＴＭにおいて紙で、またはＰＣで、または電話機のプッシュボタンを介して行う。

別のシステムが、ウェブサイトwww://ofx.netから公知である。オープンフィナンシャルエクスチェンジ（ｏｆｘ Open Financial Exchange）は、金融上のデータおよび命令をカスタマと金融機関との間で交換するための、広い支持基盤を有するフレームワークである。これによって金融機関は媒介者を必要とせずに、カスタマと直接接続することができる。オープンフィナンシャルエクスチェンジは、誰もが具現化できるオープンな仕様である。すなわち、すべての金融機関、トランザクションプロセッサ、ソフトウェア開発者または他のパーティが実現できるオープンな仕様である。ここでは、データフォーマット（ＸＭＬ等）、接続（ＴＣＰ／ＩＰおよびＨＴＴＰ）およびセキュリティ（例えばＳＳＬ）の、広く受け入れられているオープンな標準が使用される。オープンフィナンシャルエクスチェンジは、各金融サービスかつ共通フレームワークおよびインフラストラクチャによって使用される要求メッセージおよび応答メッセージを定義することにより、これらのメッセージの通信を支援する。請求者およびカスタマのデータは、同一のシステムにて保持される。

しかしながら請求者とカスタマとの間で直接的なコンタクトを使用するシステムは、異なる請求者の請求書を１カスタマに提示するというビジネスシナリオを技術的に具現化するのが困難であるという欠点を有する。さらに、このようなシステムを請求者およびカスタマのＩＴ（情報技術）システムに統合および維持するのは、とりわけ大きな請求書量を処理しなければならない場合に困難である。

したがって上記の問題の少なくとも一部を、より効率的に解決するための方法および／またはソフトウェアアプリケーションおよび／またはデータ処理システムが必要である。とりわけ、請求書処理をより効率的にするためのメカニズムを有するソフトウェアアプリケーションを提供することが望ましい。

発明の要約
本発明によれば、カスタマに対する請求書を電子的な処理するコンピュータシステムが提供される。ここでこのコンピュータシステムは、第１処理モジュールと、第２処理モジュールとを有しており、上記の第１処理モジュールは、
− 請求者によって入力されたデータを受信する手段と、
− この受信データを記憶する請求者マスタデータ記憶手段と、
− この請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段とを有しており、
上記の第２処理モジュールは、
− カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
− ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
− 上記の第１処理モジュールによって作成された複数の請求書をカスタマ毎にまとめて上記のビジネスオブジェクトデータベースに記憶するコンソリデーション手段とを有しており、上記のカスタママスタデータには請求書フォーマットが含まれており、
上記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
上記の１つまたは複数の第１処理モジュールと第２処理モジュールとがこのデータ交換手段を介して接続されており、ここで
ａ） 第１処理モジュールは、請求者によって入力された請求情報を受信し、
ｂ） 第１処理モジュールは、上記の請求情報および上記の請求者マスタデータ記憶手段に記憶されている情報を使用して請求書を作成し、
ｃ） 第１処理モジュールは、第２処理モジュールから上記のカスタママスタデータを受信し、上記の請求書を、上記のカスタママスタデータにより特定される請求書フォーマットの請求書に変換し、
ｄ） 第１処理モジュールは、変換した請求書を第２処理モジュールに送信し、
ｅ） 第２処理モジュールは、この第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて上記のビジネスオブジェクトデータベースに記憶することを特徴とする。

本発明はさらにコンピュータプログラムと、コンピュータ読み出し可能な媒体とを対象としている。これらはそれぞれ本発明の方法にしたがい、また本発明の実施形態において、請求書を処理するためのプログラムコードまたは命令を有する。

第１処理モジュールおよび第２処理モジュールはコンピュータプログラムとして、異なるハードウェアシステム（コンピュータまたはコンピュータシステム）にインストールすることができ、相互に別個にまた独立して動作させることができる。これらの異なるシステムは、相互に通信できるようにネットワークの形態で接続することができる。

本発明の付加的な目的および利点は詳細な説明に部分的に記載されているか、または本発明の実施によって習得することができる。本発明の目的および利点は、とりわけ従属請求項に記載された個々の要素および組み合わせによって実現および達成される。本発明の実施形態は、詳細な説明の部分および従属請求項において開示されている。

以下の全般的な説明および以下の詳細な説明は、双方とも単なる挙例および詳解のために記載されたものであり、請求項に記載されているように、本発明を限定するものではない。

図面の簡単な説明
本明細書に組み込まれており本明細書の一部を構成する添付図面によって、本発明の実施形態を図解し、詳細な説明とともに本発明の基本思想を詳述する。図面において、
図１は、１コンピュータシステム内での本発明の方法の実施を概略的に示すブロック図であり、
図２は、本発明の方法の例示的なブロック図であり、
図３は、本発明の電子的な請求書提示および支払いシステムの例示的な概略説明図であり、
図４は、第１および第２処理モジュールの相互接続を示す例示的なブロック図であり、
図５は、本発明の請求プロセスの例示的なフローチャートであり、
図６は、本発明の請求書提示プロセスの例示的なフローチャートであり、
図７は、本発明の電子請求プロセスに対してカスタマを登録するためのプロセスの例示的なフローチャートであり、
図８は、請求者によるカスタマの登録をアクティベートするプロセスの例示的なフローチャートであり、
図９は、カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするテーブルの例示的なブロック図であり、
図１０は、本発明の電子請求書提示および支払いシステムにｅバンキングが組み込まれた例示的なブロック図であり、
図１１は、カスタマによる請求書の確認を開始および実行するプロセスの例示的なフローチャートであり、
図１２は、図１１に示したフローチャートの続きを示しており、
図１３は、請求者またはカスタマのデータに対するアーカイブプロセスの例示的なブロック図である。

詳細な説明
コンピュータとプログラムとは密接に関連している。以下で使用されているように、「コンピュータは〜を行う」および「プログラムは特定の動作を行うまたは実行する」等のフレーズは、プログラムによって制御されるコンピュータによる動作を表現するための便宜上の短縮表現であるか、またはコンピュータシステムが特定の動作を実行できるようにプログラムまたはプログラムモジュールが設計されていることを表現するための便宜上の短縮表現である。

本発明の構想においてこれらの用語は、特に断らない限り、データ処理の分野のコンテクストにおいて通常の意味を有するものとする。コンピュータシステムは、ＰＣまたはラップトップ等の独立したコンピュータであるか、または社内のネットワーク等のネットワークとして接続された一連のコンピュータであるか、またはインターネットを介して接続された一連のコンピュータとすることが可能である。

要約の部分に記載された本発明の方法の第１実施形態は、第２処理モジュールにより、変換された請求書を第３処理モジュールに対してアクセスできるようにするステップを有することを特徴とする。

本発明の方法の第２実施形態は、上記の方法がさらに上記の変換された請求書をカスタマがアクセスできるようにするステップを有することを特徴とする。

第３実施形態は、上記の変換された請求書をカスタマに対して提示または送付することを含んでいる。

第４実施形態は、請求書を第１処理モジュールによってディジタル署名することを含んでいる。

第５実施形態は、カスタマのアクセスのために、変換された請求書に、この変換された請求書の記憶位置またはこの請求書の詳細の記憶位置へのリンクを設けることを特徴とする。

第６実施形態は、請求書または変換された請求書を、プリントサービスへ送信することを特徴とする。

本発明の第７実施形態では、第１および／または第２処理モジュールを用いて請求書および／または変換された請求書を暗号化することが含まれている。

第８実施形態は、第１および／または第２処理モジュールを用いて請求書および／または変換された請求書をアーカイブすることを含んでいる。

別の実施形態は、カスタマの請求書についての概略を提示する手段を提供する第３処理モジュールを特徴とする。有利にはこの第３処理モジュールにより、請求書を検証するための手段が提供される。本発明による方法の別の実施形態では、この第３処理モジュールにより、作業フロー支援または請求書異議申し立てのための手段が提供される。

別の実施形態の特徴は、第２処理モジュールにより、各国固有の請求書の提示および／または支払いのための手段が提供されることである。別の実施形態の特徴は、第２処理モジュールにより、１つまたは複数の別の第２処理モジュールとデータを交換するための手段が提供されることである。別の実施形態の特徴は、第２処理モジュールがカスタマから支払いオーダを受け取ることである。別の実施形態は、第２処理モジュールにより、支払いオーダまたは変換された支払いオーダが支払いサービス提供者に転送されることを特徴とする。

本発明による方法の別の実施形態の特徴は、請求情報が、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、支払い情報、ＶＡＴ情報と、購入オーダに関連する項目化された請求ポジション、および／または会計情報を有することである。別の実施形態では請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのためのオプションおよび／またはプリントサービスのためのオプションおよび／または通知のためのオプションに関する情報を有する。別の実施形態ではカスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのためのオプションに関する情報および／または通知のためのオプションに関する情報を含んでいる。

別の実施形態は、第２処理モジュールが、１つまたは複数の別の第１処理モジュールとデータを交換するための手段を有することを特徴とする。別の実施形態の特徴は、第２処理モジュールが、１つまたは複数の別の第３処理モジュールとデータを交換する手段を有することである。

別の実施形態では第２処理モジュールまたは第１処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングする手段を有する。

別の実施形態は、請求者によって使用されるフォーマットがカスタマのマスタデータで指定されたフォーマットでない場合、中間フォーマットを使用することなく、請求者によって使用されるフォーマットから、カスタマのマスタデータで指定されたフォーマットに請求書を直接変換することを含んでいる。

別の実施形態では、第１処理モジュールによって請求者から請求情報を受け取る。ここでこの第１処理モジュールは、請求者のマスタデータにアクセスすることができる。

別の実施形態では、請求情報および請求者のマスタデータを使用し、上記の第１処理モジュールによって請求書を作成する。

別の実施形態では、上記の第１処理モジュールにより、変換された請求書を第２処理モジュールに転送する。

別の実施形態では、本発明の方法、コンピュータシステムおよびコンピュータ読み出し可能媒体は、エンタープライズリソースプランニングソフトウェアに使用される。

第３処理モジュールをコンピュータプログラムとして、第１処理モジュールおよび第２処理モジュールと同一のハードウェアシステムにインストールするか、または異なるハードウェアシステムにインストールして、他の２つのモジュールとは別個に独立して実行することができる。第３処理モジュールを第２処理モジュールの一部とすることもできる（第２処理モジュールに組み込むことができる）。

コンピュータプログラムを実行するのに適したプロセッサには例えば、汎用マイクロプロセッサおよび専用プロセッサの両方と、任意の種類のディジタルコンピュータの１つまたは複数のプロセッサとがある。一般的には、プロセッサは命令およびデータを読み出し専用メモリまたはランダムアクセスメモリから受け取るか、または双方から受け取る。コンピュータの重要な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１つまたは複数の記憶装置である。一般的にはコンピュータは、データを記憶するための１つまたは複数の大容量記憶装置（記憶手段）も有しているか、またはこの大容量記憶装置からデータを受け取るかまたはこれにデータを転送するかまたは双方を行うためにこの大容量記憶装置と動作上有効に結合されている。上記の大容量記憶装置は例えば、磁気ディスク、光磁気ディスク、または光学ディスクである。コンピュータプログラム命令およびデータを具現化するのに適した情報担体には、すべての形式の不揮発性メモリが含まれている。ここに含まれるのは例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリデバイスなどの半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスク等の磁気ディスク、光磁気ディスク、ＣＤ‐ＲＯＭディスクおよびＤＶＤ‐ＲＯＭディスクである。プロセッサおよびメモリは、ＡＳＩＣ（特定用途集積回路）によって補足されるか、またはＡＳＩＣに包括することができる。

ユーザとの対話を可能にするため、情報をユーザに表示するＣＲＴ（陰極線管）モニタまたはＬＣＤ（液晶ディスプレイ）モニタ等の表示装置と、ユーザがコンピュータに入力を行うことができるキーボードおよびマウスまたはトラックボール等のポインティング装置を備えたコンピュータ上に本発明を実現することができる。別の種類の装置を使用して、ユーザとの対話を可能にすることもできる。例えば、ユーザに供給されるフィードバックは、視覚的なフィードバックまたは聴覚的なフィードバックまたは触覚的なフィードバック等のどの形式の感覚的なフィードバックでもよい。さらにユーザからの入力を、どの形式で受け取ってもよい。この形式には、音響入力、音声入力または触覚入力が含まれる。

データ処理プロセスに基づいて本発明を説明することにより、本発明の基本思想を詳述する。これらデータ処理プロセスの実施例は添付の図面に示されている。ここで触れる実施例は、本発明を説明しようとするものであり、本発明をどのような意味でも制限しようとするものでない。

以下、第１処理モジュールをＢＳＰ（"biller service provider" 請求書サービス提供者）と、第２処理モジュールをコンソリデータ（"consolidator" 整理統合ユニット）と、また第３処理モジュールをカスタマーサービス提供者ＣＳＰ（"customer service provider"）と称する。ＣＳＰがコンソリデータに統合される場合、得られる組合せを「統合化されたＣＳＰ」（ｉＣＳＰ）と称する。

図１は、本発明の１実施形態の実施例を示している。ここでは本発明の方法を実施するプログラムモジュールを有するコンピュータシステムが示されている。図１にはＣＰＵ１０５を有するコンピュータ１０３と、ＣＰＵ１０５によって処理されるソフトウェアアプリケーションが記憶されている作業記憶装置１１２（メモリ）とからなるコンピュータシステム１０１が示されている。このソフトウェアアプリケーションには、本発明の方法にしたがい、第１、第２および第３処理モジュールをそれぞれ実行するプログラムモジュール１０６，１０９，１１０が含まれている。さらにコンピュータシステム１０１は、例えばプログラムモジュールをスタートさせるためおよび／またはデータ入力のためにユーザとの対話するための入力手段１１７、出力手段１１２、ならびにデータを送受信するためのネットワーク接続部１１４を含む一般的な入／出力手段１０４を有している。ここでこのデータは、例えば、請求情報、請求書、支払いオーダ、カスタマおよび請求者のマスタデータなどである。複数のコンピュータシステム１０１を、ネットワーク１１３の形態でネットワーク接続部１１４を介して接続することができる。このような場合、各モジュール１０６，１０９，１１０は、別個および互いに無関係に各コンピュータ１１３において実装および実行することができる。この場合、ネットワークコンピュータ１１３は、さらなる記憶場所としての使用を含めて、さらなる入／出力手段として使用することができる。コンピュータシステム１０３はさらに、カスタマのマスタデータが記憶されている第１記憶手段１０７と、請求者のマスタデータが記憶されている第２記憶手段１０８とを含む。本発明の方法によれば、第１処理モジュール１１０（ＢＳＰ）は、記憶手段１０８に記憶されている請求者のマスタデータにアクセスでき、また第２処理モジュール１０６（コンソリデータ）は、記憶手段１０７に記憶されているカスタマのマスタデータにアクセスできる。請求者１１１およびカスタマ１１５は、入／出力手段１０４を介してコンピュータシステム１０３に常時接続されているか、またはオンデマンドベースで接続される。支払いサービス１１６に対して別のコネクションを確立することができる。請求者１１１およびカスタマ１１５と、付随するプログラムモジュール１１０，１０９との対話は、それぞれ破線の矢印で示されている。ＢＳＰおよびコンソリデータと、記憶手段１０８，１０７とのそれぞれの関係も同様である。

図２はいくつかのプログラムモジュール、すなわち、ＢＳＰ２０１ａ，２０１ｂ，コンソリデータ２０２ａ，２０２ｂ，２０２ｃ、およびＣＳＰ２０３のネットワークコネクションの例を示しており、ここでこれらのモジュールはそれぞれ別個のコンピュータシステム２０４ａ，ｂ，２０５ａ，ｂ，ｃおよび２０８にインストールされている。それぞれのコンピュータシステムは、アプリケーションの状況の要求に依存して同じでも、互いに異なっていてもよい。コンピュータシステムは、世界中の別個の国々に設置することができる。一つまたはそれ以上の請求者は、ウェブブラウザ２０７ａ，ｂを使用し、コンピュータシステム２０６ａ，ｂを介してこのネットワークにアクセスすることができる。これらのコンピュータシステム２０６ａ，ｂは、各ＢＳＰ２０４ａ，ｂに接続可能である。カスタマは、ウェブブラウザ２１１を有するコンピュータシステム２１０を介してこのネットワークにアクセスすることができる。請求書に付随する支払いを実行するために、ｅバンキングアプリケーションを有する支払いサービス提供者のコンピュータシステム２０９は、１つまたは複数のコンソリデータシステム２０５ａ，ｂ，ｃに接続可能である。

請求者マスタデータと、カスタママスタデータとを分ける本発明のコンセプトにしたがい、ＢＳＰを必要なだけ１コンソリデータに接続することができる。これによって、不必要なデータの移動が回避される。それは、請求書を処理するモジュールにカスタママスタデータを移動またはコピーする必要がないからである。これは従来技術の方法によれば必要である。このコンセプトによれば、例えば、１ヶ月当たりに数百万を上回る請求書量を１コンソリデータに接続されているいくつかのＢＳＰで処理することができる。カスタママスタデータを更新しなければならない場合、本発明のシステムではこれは極めて簡単である。それは、コンソリデータのデータベースだけを変更すればよいからである。このような更新によってＢＳＰデータベースが影響を受けることはない。さらなる効果は、マスタデータに対するメンテナンスコストが低減されることである。

図３には、請求者とＢＳＰとの間、ＢＳＰとコンソリデータとの間、コンソリデータとＣＳＰとの間、およびＣＳＰとカスタマ（支払い者）との間でデータ交換をするためのフォーマットおよびインタフェースの例の概要が示されている。請求者側は、３つケースに分かれている。すなわち、ＳＡＰ ＥＲＰシステム（ＳＡＰ ＡＧ，D-69190 Walldorf, Germany）を使用する大規模の請求者と、ＳＡＰ ＥＲＰシステムでないシステムを使用する大規模の請求者と、小規模の請求者とに分かれている。ここで「大規模」および「小規模」とは、それぞれの会社または人の取引高のことであり、説明のためだけの任意の尺度である。カスタマ側にも同じことが相応に当てはまる。この例においてＣＳＰは、大規模支払い者に対してはｉＣＳＰとしてコンソリデータに組み込まれており、また小規模支払い者に対しては、択一的な２つの実装、すなわちＳＡＰポータルＣＳＰおよびオンラインバンキングＣＳＰを有する別個のプログラムモジュールである。この例においてＢＳＰは、請求情報に対して４つのフォーマットをサポートしている。すなわちＩＤＯＣ，FLATFILEおよびEDIFACTフォーマットおよびあらかじめ定義可能なＢＳＰであり、請求者およびＢＳＰのシステムをそれぞれのソフトウェアのインストール中にこれらに適合化しなければならない。請求者側のシステムは、ＨＴＭＬ，HTTPS，XML-IDOC（ＳＳＬ），ＦＬＡＴ（ＳＳＬ），ＥＤＩ（ＳＳＬ）に基づいてＢＳＰと通信することができる。ＢＳＰおよびコンソリデータ、またコンソリデータおよびＣＳＰも、ＸＭＬを介して通信することができる。ＣＳＰおよび／またはｉＣＳＰは、ＨＴＭＬ（HTTPS），XML-IDOC（ＳＳＬ），ＥＤＩ（ＳＳＬ）およびＸＭＬに基づいてカスタマのシステムと通信することができる。

図４は、ＢＳＰおよび／またはＣＳＰおよび／またはｉＣＳＰが有し得るインタフェース（ＩＦ）の例を示している。すなわち請求者またはカスタマＥＤＩ／ファイルＩＦ，ウェブＧＵＩ（graphical user interface），ＢＣＸ，フラットファイル（Flat File）変換，プリントＩＦ，アーカイブＩＦ，請求エンジンとのコネクションに対するコストイベントＩＦ，支払いサービス（金融機関）とのコネクションに対するＩＦ，またはインターネットサービスプロバイダ（ＩＳＰ）とのコネクションに対するＣＣＸ ＩＦが示されている。これらの請求者は、その請求書サマリのリストを見るため、請求者は、ＢＳＰに接続することができ、またカスタマは好みに応じて直接的にまたは金融機関またはＩＳＰへのコネクションを介して間接的にＣＳＰ／ｉＣＳＰに接続することができる。項目化された請求書および登録に対して、カスタマはＢＳＰに接続することができる。ＢＳＰは、請求者に関連するすべてのデータをパートナデータベースに記憶する。請求者のマスタデータは、アドレス、識別キー、権限付与、請求者統合化レベル（インタフェース能力および実装された処理）、ロゴ、請求書におけるロゴの位置、個人別の販売促進に対する宣伝フォーム、クレジットに対するフォーマット、ディジタル署名などを含む。請求情報、生成および／または変換された請求書、ウェブ提示に対する請求書の詳細は、ＢＳＰにより、ビジネスオブジェクトデータベースに記憶することができる。この意味でのビジネスオブジェクトは、特定の請求書に対する発生原因としてのビジネストランザクションに属するデータ全体のことである。典型的な請求情報は、品物、品物のタイプ、番号、ポジション、ＩＤ、品物の説明、価格、税情報、住所（例えば配送用）、参照（詳細に対するＵＲＬ）、日付（例えば、請求日付）などである。コンソリデータ／ｉＣＳＰは、カスタマおよび金融機関に付随するすべてのデータをパートナデータベースに記憶する。すなわち、カスタマのアドレス、カスタマの組織内およびカスタマと請求者との間の通信用のアドレス、請求書を提示すべきフォーマット、ステータス情報または異議申し立てまたは調査管理を供給するためのアドレス、識別キー、権限付与、ディジタル署名などを含むカスタマのマスタデータを記憶する。カスタマに提示すべき請求書サマリまたは整理統合または総計された請求書は、コンソリデータ／ｉＣＳＰにより、コンソリデータのビジネスオブジェクトデータベースに記憶される。このようにして、請求書量を処理するために必要な数のＢＳＰを１コンソリデータ／ｉＣＳＰに接続することができる。

プログラムモジュール１０６，１０９，１１０が図１のＣＰＵ１０５によって処理されて本発明の方法が実施される場合、以下に説明するステップが上記のようにコンピュータシステム１０１またはネットワークのシステムによって実行される。

図５は、本発明の方法の例示的な実施の流れ図を示している。このタイプの流れ図の時間軸は上から下に続いている。請求者は（そのＥＲＰコンピュータシステムによって）、この請求者がＢＳＰ登録時に合意したフォーマットで請求情報をＢＳＰに送信する。ＢＳＰは、この請求情報および請求者マスタデータに基づいて請求書を作成し、ステータス「新しい」をこのオブジェクトに割り当てる。つぎにこのＢＳＰは、カスタマについての情報の要求（CustomerInfoRequest）をコンソリデータ／ｉＣＳに送信する。コンソリデータ／ｉＣＳＰはこの要求に応答して、問い合わされたカスタマに対するカスタママスタデータベースから、利用可能なデータをこのＢＳＰに返す（CustomerInfoResponse）。上で示した情報に加えて、上記の応答は、カスタマが、ウェブ表示に対する請求データを要求したか（疎な整理統合化、「疎である」のは主要な情報だけがカスタマに提示されるからである）、またはＥＲＰシステムにおける処理を要求したか（密な整理統合化、「密である」のはこの請求書が、請求書の詳細を含めてカスタマに電子的に送信されるからである）、または適用可能な税または別の法的な規定にしたがってディジタル署名フォーマットで行うか、または表示する請求書を暗号化するか否かについての情報を含むことができる。さらに付加的に上記の応答は、各ＥＲＰシステムにおける各ＩＤに関する、請求者とカスタマとの関係についての情報（ＢＣＲ biller to customer relation）を含むことができる。さらに付加的に上記の応答は、項目化された請求書にアクセスするためまたは暗号化（ディジタルＩＤのリスト、識別名（distinguished name）、証明シリアル番号など、Ｘ．５０９証明書を参照する）に対する認証情報を含むことができる。つぎにＢＳＰは、CustomerInfoResponse（カスタマ情報応答）で受信したフォーマットに請求書を変換する。

データは、ソースフォーマットからターゲットフォーマットにできるだけ直接的に、ソースのできる限り近くで変換すべきであり、また可能であれば、変換は回避すべきである。それはデータ損失のリスクを孕んでいるからである。ターゲットフォーマットを内部で形成できない場合には、ＢＳＰは外部の変換サービスを使用することができる。理由は、ＢＳＰにおいて請求書を直接的にカスタマのフォーマットに変換することにより、ＶＡＴ控除に対する政府の規定に適合する請求書をディジタル署名することができるからである。カスタマは直接、処理して、明細請求書をアーカイブすることができ、これによって簡単な統合化プロセスが得られる。アプリケーションコンテンツは比較的簡単に保存することができる。サポートされるフォーマットの総数を少なくする（標準化）ことによって変換作業およびコストが低減される。ＰＳＰ（payment format 支払いフォーマット）固有の適合化は、コンソリデータ／ｉＣＳＰにおいて処理することができる。

従来技術によるＥＢＰＰシステムのコンテキストでは変換は、中間（社内"in-house"）フォーマットを使用することによって間接的に行われ、ソースデータはまずこの社内フォーマットに変換され、つぎにターゲットフォーマットに変換される。この技術の利点は、変換の回数が、フォーマットの数（ｎ）に対して、直接変換の場合のｎ(ｎ−１)と比較して線形（２ｎ）になることである。しかしながら中間フォーマットというものがＢＳＰの提示時における変換にも使用できる事実とは関係なく、カスタマフォーマットへの変換は提示プロセスにおいてできる限り早く行うべきである。ＢＳＰにおいてエンドユーザフォーマットに明細請求書を変換することの利点は、ＢＳＰにおいてこの請求書に署名できることである。請求者は、その請求書作成プロセスをＢＳＰに外注するため、ＢＳＰに署名を委任することが可能である。コンソリデータにおいてＰＳＰフォーマットを請求者およびカスタマフォーマットに変換することの利点は、コンソリデータだけがＰＳＰ（例えば国）固有拡張を含むことである。ＢＳＰおよびＣＳＰはＰＳＰフォーマットには無関係のままである。

ＢＳＰはこれが第３者のハードウェアシステムに実装されている場合、法的には請求者の外注パートナとして扱うことができる。同じことがＣＳＰおよびコンソリデータ／ｉＣＳＰにも相応に適用される。この点においてＢＳＰは、電子的な請求書を、またオプションとしては紙の請求書を請求者に代わって作成するのである。法人としての請求者は、ＢＳＰを経営する法人に請求書にディジタル署名する権利を委任するのである。ＢＳＰは、カスタマによって承諾され、可読であり、処理可能であり、またＶＡＴ控除に対して有効なフォーマットで、ディジタル署名された明細請求書メッセージを作成しなければならない。これは上述の変換プロセスを使用することによって達成される。カスタマは、上記の委任をオンラインでチェックすることができる。請求者のリスト（電子請求書に対するカスタマ登録を参照されたい）は、ＢＳＰにありかつ請求者によってディジタル署名された委任文書へのハイパーリンクを含んでいる。

多くの欧州の国々では、最近まで、購入した品物に対するＶＡＴ（Value Added Tax）の償還に対して、明確に規定された最小セットの情報を有する紙の明細請求書を管轄官庁に提示しなければならなかった。また明細請求の文書は、請求者が印刷しなければならなかった。電子的に転送され、カスタマによって印刷された請求書は認められなかったのである。欧州連合および他の国々（例えばスイス）では新たな法律および規則により、請求者によってディジタル署名された請求書であれば、電子的に転送された請求書に基づくＶＡＴ控除が認められる。署名に使用される証明および手続きは規制されている。

要求されるフォーマットを生成するためにＢＳＰは、外部の変換サービス、例えばウェブサービスにアクセスすることができる。考えられ得るカスタマのアクセスに対する請求書の提示には準備がなされる。選別：カスタマと電子的に連絡を取れない場合、例えばCustomerInfoResponse（カスタマ情報応答）が「不明」を返す場合、ＢＳＰは紙の請求書を生成し、および／または請求者に相応に通知することができる。

請求情報に含まれている明細請求書送付日付に達した後、ＢＳＰは、変換した請求書をコンソリデータ／ｉＣＳＰに送付する（InvoiceDeliveryRequest 明細請求書送付要求）。付加的にＢＳＰは、コンソリデータ／ｉＣＳＰに、請求者の統合化状況についての情報を提示する（BillerPreference 請求者好み設定）。これらの情報は、コンソリデータ／ｉＣＳＰが、受信した変換済み請求書を操作するのに有益である。これらの操作は、利用可能なクレジットの通知またはクレジット通知フォーマット、請求者に対する最終的なビジネストランザクション状態（例えば、送付した請求書または支払った請求書など）、サポートされている処理（例えば、異議申し立て、送金通知拒絶など）の要求である。コンソリデータ／ｉＣＳＰは、変換した請求書が、カスタマによるアクセスに対して利用可能であることを、ＢＳＰへのｏｋ応答によって確認する（InvoiceDeliveryResponse 明細請求書送付応答）。ＢＳＰは、請求書のステータスを「送付済み」に設定し、コンソリデータ／ｉＣＳＰは、受信した変換済み請求書のステータスを「オープン」に設定する。

つぎの処理ステップは、カスタマがウェブカスタマであるか、またはＥＲＰカスタマであるかに依存し、または支払いの好みが、特定のカスタマに対して適用可能であるか否かに依存し、または請求者およびカスタマの支払いサービス提供者（ＰＳＰ）の接続状況に依存する。いくつかのオプションを挙げると、バンキングポータルを使用したウェブ提示および支払い（ＣＣＸ ＩＦ）、ＩＳＰ（例えばyahoo）およびＰＳＰを使用したウェブ提示および支払い、支払いチャンネル（payment channel）を使用したＥＲＰ接続および支払い、ＳＡＰ ＥＢＰＰシステムを使用したＥＲＰ接続および支払いがある。カスタマは、変換された自分の請求書をコンソリデータ／ｉＣＳＰから受け取るか、またはウェブポータルを介して、コンソリデータおよび／またはｉＣＳＰデータベースにある、変換された請求書にアクセスする（請求書送付）。オプションのステップを、明細請求書検査、資料管理とのクロスチェック、支払い処理に対する作業フローに基づいて行うことができる。つぎに（オプションでディジタル署名された）支払いオーダがコンソリデータ／ｉＣＳＰに送信される。つぎにコンソリデータ／ｉＣＳＰは、支払いオーダによって構成される支払いスケジュール情報をＢＳＰに伝える（SetEBPPStatusRequest）。つぎにＢＳＰは、（オプションではスケジュールされた）支払いを請求者に通知する。直ちにまたは要求された支払い日付に、コンソリデータ／ｉＣＳＰは、ＰＳＰによって要求されたフォーマットで支払いオーダを生成し、この支払いオーダをＰＳＰに送信する。この支払いオーダは、暗号化法で認証される。ＰＳＰは支払いを処理する。要求があれば、これには銀行間支払い処理が使用される。カスタマのＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、口座引き落とし通知（debit advice）をカスタマに送信させる。コンソリデータ／ｉＣＳＰは、カスタマが要求したフォーマットで口座引き落とし通知を生成し、メッセージをカスタマに送信させる（口座引き落とし通知）。変換された請求書のコンソリデータ／ｉＣＳＰにおけるステータスは、「支払い済」に設定される。請求者のＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、この請求者にクレジット通知を送信させる。コンソリデータ／ｉＣＳＰは、請求者によって要求されたフォーマットでクレジット通知を生成して、ステータス変更要求と一緒にそのメッセージをＢＳＰに送信する（SetEBPPStatusRequest）。ＢＳＰは、このクレジット通知メッセージを請求者に送信して、請求書のステータスを「支払い済」に変更する。

図６には請求書提示プロセスの例示的なフローチャートが示されている。すなわち、
カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。ｉＣＳＰ／コンソリデータのマスタデータへのウェブアクセスに対してＤＮ（distinguished name 識別名）を許可しなければならない。このユーザはつぎにクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、カスタマの整理統合された請求書のリストを直接選択することができる（GetListOfBills）。ここでこのユーザはこのカスタマに対してログインしている。このリストの請求書毎に通例、以下のデータを提示することができる。すなわち、明細請求書参照、請求者名、請求者銀行預金口座、支払期日、通貨による金額、ビジネストランザクション（請求書）状態（オープン、（または催促）、満期、予定、支払済み、別額による支払い）、請求書に対する付加的な情報用のハイパーリンク（ルーペシンボルまたは下線付きの明細請求書参照）を提示することができる。カスタマは、ハイパーリンクを選択して、請求書に対する付加的な情報を得ることができる。この（ＳＳＬ）ハイパーリンクは、請求者の情報ページをポイントしており、これは、通常、ＢＳＰがホストをしている（択一的な例としてはこのページは請求者のウェブサーバに存在することも可能である）。ＢＳＰは、トークン（請求書の詳細が準備される時点で生成され、請求書サマリの一部として渡される）に基づいてカスタマを認証する。このトークンは、ハイパーリンクと一緒にＢＳＰに戻される。カスタマが強力な認証を要求する場合、認証がCustomerInfoReference（カスタマ情報参照。前の図を参照されたい）で指定した証明書のうちの１つと一致する場合にだけ請求書が提示される。ＢＳＰは、多くのＨＴＭＬテンプレートを保持しており、参照されたビジネストランザクション（請求書）に基づいて適切なテンプレートを選択する。このテンプレートは、書き込むべきビジネストランザクションデータを参照することができる（例えば、個人別の広告に有効である）。カスタマアドレスに基づき、また請求者との合意により、ローカルに第３者の広告を付加することができる。生成したＨＴＭＬページは、項目化された請求書へのハイパーリンクを含む。カスタマは、この項目化された請求書へのハイパーリンクを選択して、（認証の後）ＰＤＦフォーマットで請求書を受信する。

図７には、電子請求書に対するカスタマの登録プロセスの例示的なフローチャートが示されている。すなわち、
カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。ｉＣＳＰ／コンソリデータのマスタデータへのウェブアクセスに対してＤＮ（distinguished name 識別名）を許可しなければならない。ユーザはつぎにクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、請求者のリストを直接、選択することができる。コンソリデータは、電子的な請求者への情報を含む（通常は管理保持された）ＨＴＭＬテンプレートを保有している。このリストには、ロゴおよびＢＳＰからの請求者データを書き込むことができ、ここでこれはハイパーリンクを使用して得られる（択一的にはこのデータをコンソリデータにおいてローカルに保持することも可能である）。また提示されたリストは、各請求者におけるカスタマ登録ステータス（イナアクティブ、アクティブ、登録要求、登録拒絶）も含んでいる。この登録ステータスは、コンソリデータのＢＣＲ（Biller Customer Relation 請求者カスタマ関係）テーブルに記憶される。カスタマは、請求者を選択する。登録フォームに対するＵＲＬは、ＢＳＰ（または請求者のウェブサーバ）をポイントする。ＢＳＰは、カスタマＰＩＤ（Partner Identification Number パートナ識別番号）をこのＵＲＬから受信する。またこのカスタマを認証できないため、ＢＳＰは、コンソリデータから受信したＰＩＤに一致するカスタママスタデータを受け取る。請求者固有のＨＴＭＬテンプレートに基づいて登録フォームが提示され、これはカスタマのマスタデータ（編集不可）と、少なくとも登録または登録を取り消すためのボタンを含む。付加的に請求者は、ＢＣＮ（Biller's Customer Number請求者のカスタマ番号または債務者番号）を要求することができる。カスタマがこの請求書をＥＲＰシステムで処理する場合、この登録フォームは、ＣＢＮ（Customer's Biller Number カスタマの請求者番号 ＝ 債権者番号）を記入するために１フィールド分拡張される。カスタマは、この登録フォームを記入し終えて、これをＢＳＰに返送する。ＢＳＰは、コンソリデータにおいて「登録要求（registration＿requested）」のステータスを有するＢＣＲエントリを作成する。ＢＳＰは、新たな登録について請求者に（例えばＥメールで）通知することできる（オプション）。

図８は、カスタマ登録における請求者の動作の例示的なフローチャートを示している。すなわち、
請求者または（請求者の）ユーザは、ＢＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。ＢＳＰのマスタデータへのウェブアクセスに対してＤＮ（distinguished name 識別名）を許可しなければならない。ユーザはつぎにクライアント（請求者）を選択するか、またはこのユーザがクライアントを有しない場合、フィルタリング検索条件（例えば、すべてのregistration＿requested 登録要求）を直接定めて、カスタマのリストにアクセスすることができる。ＢＳＰは、この要求をコンソリデータ／ｉＣＳＰに送信して、コンソリデータ／ｉＣＳＰの応答を処理し、請求者にカスタマのリストを提示する。請求者は、提供された登録情報を詳細に調べて（ＢＣＮおよびカスタマ名における不整合は回避すべきである）、登録データが正しい場合にはＢＣＲステータスを「アクティブ」にする。ＢＳＰは、SetBCRState（ＢＣＲステート設定）要求を使用して、コンソリデータ／ｉＣＳＰにＢＣＲ状態を設定する。ＢＣＲテーブルに適切な状態を設定した後、コンソリデータ／ｉＣＳＰは、（例えばＥメールによって）カスタマに通知することができる。

図９には請求者カスタマ関係テーブルのコンセプトが示されている。すなわち、
請求者カスタマ関係コンセプトは、請求者またはカスタマＥＳＰシステムの統合化を最適にサポートするために設計されている。

ＢＣＮ（Billers Customer Number 請求者カスタマ番号）：ＢＣＮまたは債務者番号は、コンソリデータ／ｉＣＳＰシステムに記憶することができる。これによって請求者は、ＢＳＰに送信される請求データに存在するカスタマ識別子を使用することができる。コストのかかるマッピングを回避することができる。カスタマ登録プロセスにおいて取得される情報に基づいて、コンソリデータ／ｉＣＳＰは、ＢＣＮを一意的なカスタマ識別子（例えば、ＣＰＩＤ，Customer Partner Identification カスタマのパートナ識別子）にマッピングすることができる。

ＣＢＮ（Customers Biller Number カスタマの請求者番号）：カスタマＥＲＰシステムにおいて請求者を識別するために使用される貸方番号も、カスタマ登録プロセス中にコンソリデータ／ｉＣＳＰに記憶される。これによってＢＳＰは、ＢＳＰにおける変換中にＢＰＩＤ（Biller Partner Identification 請求者のパートナ識別子）を、カスタマＥＲＰシステムに既知である請求者ＩＤに直接マッピングすることができる。したがってカスタマは、面倒でコストのかかるＩＤのマッピングを実装する必要はないのである。

図１０にはＣＣＸ ＩＦを使用したｅバンキング統合化が示されている。ＣＣＸ（Consolidator CSP Exchange コンソリデータＣＳＰ交換）インタフェースを使用すれば、ｅバンキングソリューションにより、請求書提示を統合化することができる。カスタマは、複数のＣＳＰ（マルチバンキング）を使用することができる。すなわち、ＣＳＰは、提示のためにコンソリデータ／ｉＣＳＰにおける請求書の現在のリストを取り出すことができるのである。請求書はＣＳＰによって単純にルーティングされるのではない。これにより、カスタマはユニークな機能を得て、相異なる複数のＣＳＰ（例えば銀行）からの自分の請求書を見て、支払うのである。

図１１および１２には、請求書を確認するための作業フローの例示的なフローチャートが示されている。すなわち、
ここではディスパッチャと称することにするカスタマの１従業員は、コンソリデータ／ｉＣＳＰにログインして請求書のリストを選択する（ウェブ請求書提示を参照されたい）。確認作業フローの準備がまだ整っていない請求書に対して、ディスパッチャは、SetUpReviewWorkflow（確認作業フローのセットアップ）を選択することができる。フォームが提示されると、ディスパッチャは、確認者のリストを決めることができる。これは確認者のＥメールアドレス（またエイリアス）を入力することによって行われる。ディスパッチャは、またテキスト（質問、請求書項目の割り当てその他）を入力することもできる。これと並行してディスパッチャは、項目化された請求書を提示させることができる（ウェブ請求書提示を参照されたい）。ディスパッチャは、このフォームをコンソリデータ／ｉＣＳＰに返送する（PostReviewForm）。ｉＣＳＰ／コンソリデータは、Ｅメールを確認者に送信する（可能であれば、暗号化またはプライベート（社内）ネットワークを使用する）。このＥメールは作業項目、確認請求書および（カスタマイズ可能な）短い説明へのハイパーリンク（ＵＲＬ）を含むことができる。オプションでは、このＥメールは認証トークンを含むことが可能である。ビジネストランザクションのステータスは、「請求書確認」に変更される。このＥメールの受信者は、このＥメールにリストアップされていたｉＣＳＰ／コンソリデータのＵＲＬに接続する。ｉＣＳＰは有利にはＳＳＬクライアント認証を使用し、受信した証明書と、マスタデータ内の認可された証明書とを比較するか、またはＵＲＬのトークンに基づいてユーザを許可するか、ユーザｉｄ／パスワードメカニズムに基づいてユーザ認証する（認証／許可方式はシステムにおいてカスタマイズ可能である）。ｉＣＳＰ／コンソリデータは、これまで付加したすべてのデータと一緒に現在の確認フォームを返送する。この確認フォームも付加的な請求情報へのハイパーリンクを含むことができる（ウェブ請求書提示を参照されたい）。ユーザは、請求書の内容についてコメントおよび会計情報を付加することができる（例えば、ポジション３は受信していない、ポジション１および４はｏｋ、内部明細番号XYZに変更その他）。記入済みのフォームはｉＣＳＰ／コンソリデータに返送される（PostReviewForm）。別の確認者は、自分の作業フローの項目を同様に処理することができる。ディスパッチャまたは権限を有する別の任意のユーザは、任意の時点に請求書のリストを介して確認フォームにアクセスすることができる。すべての確認者が確認フォームを送り、ビジネストランザクションの状態が期限日に依存して「オープン」または「期限日」に設定されると、システムはあらかじめ定めたアドレスにメッセージを送信する。確認者は、別の請求書または請求書のリストにアクセスする必要はない。認証／許可だけをｉＣＳＰ／コンソリデータに記憶するだけでよい（例えば、ディジタルｉｄを有する確認者に対し、そのＤＮだけを請求書確認に対する権限と結び付けて記憶するだけでよい）。

図１３には例示的なアーカイブ作成プロシージャが説明されている。アーカイブ作成は、適用可能な規則（ＶＡＴ）の要求を満たさなければならない。請求者は、ＢＳＰとのすべてのビジネストランザクション（請求書）を含むＣＤまたはＤＶＤ ＲＯＭまたは別のリードオンリー装置の形態でアーカイブを受け取る。カスタマも請求者と同じ形態で、ｉＣＳＰ／コンソリデータとのすべてのビジネストランザクションを含むアーカイブを受け取ることができる。 ＰＳＰおよびサポート組織もそれ自体のデータを含むアーカイブを受け取ることができる。アーカイブは以下を含むことができる。

ＢＳＰまたはｉＣＳＰ／コンソリデータによってそれぞれディジタル署名されたインデックス。ここでこのインデックスはアーカイブのすべてのビジネストランザクションの請求書サマリを含む。このインデックスにはディジタル署名することができ、これによってビジネストランザクション（提示された請求書）毎にアーカイブコンテンツの証明ができるようにする（ビジネストランザクションは除去できない）。またアーカイブはつぎを含むことができる。すなわち、
オリジナルメッセージへのハイパーリンク、すべてのビジネストランザクションイベントの履歴および請求書サマリを含むビジネストランザクションリポート、
交換されたすべてのメッセージ、例えば、構造化されたメッセージ（ＸＭＬ ＩＤＯＣまたはEDIFACTなど）としてのディジタル署名された明細請求書、同様にディジタル署名されたＰＤＦファイルとしての明細請求書など、
オプションでは暗号化メカニズムが適用されて、アーカイブの任意の内容変更が回避される。このアーカイブは、請求者またはカスタマの要求にしたがって定期的に作成することができる。アーカイブは、請求者またはカスタマに送付することができる。受け取り側は、受け取ったアーカイブが読み取れることを確認することができ、これは「アーカイブ受け入れ」メッセージを送信することによって、またはこの受け入れを対話的に確認することによって行われる。 所要の受入メッセージをすべて受信した後、また設定可能な就業日数（通例９０日）の後、ビジネストランザクションは、ＢＳＰおよびｉＣＳＰ／コンソリデータからそれぞれ除去することできる。

上に示した本発明の方法およびシステムにより、ＥＢＰＰシステムにおけるつぎのような要求が解決される。すなわち、請求者ＩＴシステムとカスタマＩＴシステムとを簡単に統合化すること、１カスタマに対する別個の請求者の請求書を整理統合すること、支払いに対して複数の金融機関を許容すること、請求書の詳細のプライバシーおよびアクセスセキュリティ、政府のＶＡＴ規定の遵守、請求書量についての高いスケーラビリティ、クロスボーダーのＥＢＰＰを許容すること、および請求書確認作業フローなどの要求が解決される。

ここに示した実施例および本明細書の考察から当業者には本発明の変更および適合化が明らかであろう。本発明の実施について上で述べたことは、例証および説明を目的として示しただけである。これは網羅的ではなく、また開示した内容と正確に同じ形態に本発明を制限するものではない。上で教示した内容を考え合わせれば変更および変形が可能であり、また本発明の実施例から変更および変形を得ることもできる。例えば、上で説明した実現はソフトウェアを含むが、本発明に見合ったシステムおよび方法をハードウェアおよびソフトウェアの組合せとして、またはハードウェア単独で実現することができる。さらに、メモリへの記憶に対して本発明の種々の様相を説明したが、当業者には、これらの様相は、別のタイプのコンピュータ読み出し可能な媒体、例えばハードディスク、フロッピィディスク、またはＣＤ−ＲＯＭ等の２次記憶装置、インターネットまたは別の伝搬媒体、またはＲＡＭまたはＲＯＭの別の形態にも記憶することができることがわかるであろう。明細書および実施例は例示だけのものとみなされること意図しており、本発明の真の範囲および精髄は添付の特許請求の範囲に示されている。

言葉による説明およびフローチャートに基づくコンピュータプログラムは、経験を積んだ開発者の技量の範囲内にあるものである。当業者に公知の任意のテクニックを駆使して種々のプログラムまたはプログラムモジュールを作成することができ、または既存のソフトウェアと結びつけて設計することができる。例えば、プログラムまたはプログラムモジュールは、Ｊａｖａ(Ｒ)，Ｃ＋＋，ＨＴＭＬ，ＸＭＬまたはＪａｖａアプレットが組み込まれたＨＴＭＬで、またはこれらを用いて設計することができ、またはＳＡＰ Ｒ／３またはＡＢＡＰで設計することできる。１つまたは複数のこのようなモジュールを既存のＥメールまたはブラウザソフトウェアに組み込むことができる。

コンピュータシステム内での本発明の方法の実施を概略的に示すブロック図である。 本発明の方法の例示的なブロック図である。 本発明の電子的な請求書提示支払いシステムの例示的な概観説明図である。 第１および第２処理モジュールの相互接続を示す例示的なブロック図である。 本発明の請求プロセスの例示的なフローチャートである。 本発明の請求書提示プロセスの例示的なフローチャートである。 本発明の電子的請求システムに対してカスタマを登録するためのプロセスの例示的なフローチャートである。 請求者によるカスタマの登録をアクティベートするプロセスの例示的なフローチャートである。 カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするテーブルの例示的なブロック図である。 本発明の電子的な請求書提示支払いシステムにｅバンキングが組み込まれた例示的なブロック図である。 カスタマによる請求書の確認を開始および実行するプロセスの例示的なすフローチャートである。 図１１に示したフローチャートの続きである。 請求者またはカスタマのデータに対するアーカイブプロセスの例示的なブロック図である。

Claims (33)

1. カスタマに対する請求書を電子的に処理するコンピュータシステムにおいて、
   該コンピュータシステムは、第１処理モジュール（ＢＳＰ）と、第２処理モジュール（コンソリデータ）とを有しており、
   前記の第１処理モジュール（ＢＳＰ）は、
   − 請求者によって入力されたデータを受信する手段と、
   − 当該の受信データを記憶する請求者マスタデータ記憶手段と、
   − 当該の請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段とを有しており、
   前記の第２処理モジュール（コンソリデータ）は、
   − カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
   − ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
   − 前記の第１処理モジュールによって作成された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータベースに記憶するコンソリデーション手段とを有しており、前記のカスタママスタデータには請求書フォーマットが含まれており、
   前記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
   前記の１つまたは複数の第１処理モジュールと第２処理モジュールとが当該のデータ交換手段を介して接続されており、ここで
   ａ） 第１処理モジュールは、請求者によって入力された請求情報を受信し、
   ｂ） 第１処理モジュールは、前記の請求情報および前記の請求者マスタデータ記憶手段に記憶されている情報を使用して請求書を作成し、
   ｃ） 第１処理モジュールは、第２処理モジュールから前記のカスタママスタデータを受信し、前記の請求書を、前記のカスタママスタデータにより特定される請求書フォーマットの請求書に変換し、
   ｄ） 第１処理モジュールは、変換した請求書を第２処理モジュールに送信し、
   ｅ） 第２処理モジュールは、当該の第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータベースに記憶することを特徴とする、
   カスタマに対する請求書を電子的に処理するコンピュータシステム。
2. さらに前記の第２処理モジュール（コンソリデータ）に接続された第３処理モジュール（ＣＳＰ）を有しており、
   該第３処理モジュールは、
   − カスタマによって入力されるデータを受信する手段と、
   − 当該のカスタマに請求書を提示する出力手段とを有しており、
   ここで前記の第２処理モジュールは、前記のまとめた請求書を第３処理モジュールがアクセスできるようにする、
   請求項１に記載のコンピュータシステム。
3. さらに前記のまとめた請求書をカスタマがアクセスできるようにした、
   請求項１または２に記載のコンピュータシステム。
4. さらに前記のまとめた請求書をカスタマに提示または配送する、
   請求項１から３までのいずれか１項に記載のコンピュータシステム。
5. さらに前記の第１処理モジュールによって請求書にデジタル署名する、
   請求項１から４までのいずれか１項に記載のコンピュータシステム。
6. さらにカスタマがアクセスできるようにするため、前記の請求書の詳細の記憶位置へのリンクが前記のまとめた請求書に設けられている、
   請求項１から５までのいずれか１項に記載のコンピュータシステム。
7. さらに前記の作成した請求書が第１処理モジュールによって暗号化され、および／または前記のまとめた請求書が第２処理モジュールによって暗号化される、
   請求項１から６までのいずれか１項に記載のコンピュータシステム。
8. 前記の作成した請求書が第１処理モジュールによってアーカイブされ、および／または前記のまとめた請求書が第２処理モジュールによってアーカイブされる、
   請求項１から７までのいずれか１項に記載のコンピュータシステム。
9. さらに前記の第２処理モジュールには、１つまたは複数の別の第２処理モジュールとデータを交換する手段が設けられている、
   請求項１から８までのいずれか１項に記載のコンピュータシステム。
10. さらに前記の第２処理モジュールにより、支払いオーダをカスタマから受信する、
    請求項１から９までのいずれか１項記載のコンピュータシステム。
11. さらに前記の第２処理モジュールにより、支払いオーダまたはまとめられた支払いオーダが支払いサービス提供者に転送される、
    請求項１から１０までのいずれか１項に記載のコンピュータシステム。
12. さらに前記の請求情報には、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または会計情報が含まれる、
    請求項１から１１までのいずれか１項に記載のコンピュータシステム。
13. さらに前記の請求者マスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１から１２までのいずれか１項に記載のコンピュータシステム。
14. さらに前記のカスタママスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１から１３までのいずれか１項に記載のコンピュータシステム。
15. さらに前記の第２処理モジュールは、１つまたは複数の別の第３処理モジュールとデータを交換するための手段を有する、
    請求項１から１４までのいずれか１項に記載のコンピュータシステム。
16. エンタープライズリソースプランニングソフトウェアに使用される、
    請求項１から１５までのいずれか１項記載のコンピュータシステム。
17. カスタマに対する請求書を電子的に処理するシステムとしてコンピュータを機能させるプログラムにおいて、
    該プログラムは、請求書を作成する第１処理モジュール（ＢＳＰ）および請求書をまとめる第２処理モジュール（コンソリデータ）として前記コンピュータを機能させ、
    前記の第１処理モジュール（ＢＳＰ）は、
    − 請求者によって入力されたデータを受信する手段と、
    − 当該の受信データを記憶する請求者マスタデータ記憶手段と、
    − 当該の請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段とを有しており、
    前記の第２処理モジュール（コンソリデータ）は、
    − カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
    − ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
    − 前記の第１処理モジュールによって作成された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータベースに記憶するコンソリデーション手段とを有しており、前記のカスタママスタデータには請求書フォーマットが含まれており、
    前記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
    前記の１つまたは複数の第１処理モジュールと第２処理モジュールとが当該のデータ交換手段を介して接続されており、ここで
    前記のプログラムは、前記の第１処理モジュールに
    ａ） 請求者によって入力された請求情報を受信するステップと、
    ｂ） 前記の請求情報および前記の請求者マスタデータ記憶手段に記憶されている情報を使用して請求書を作成するステップと、
    ｃ） 第２処理モジュールから前記のカスタママスタデータを受信し、前記の請求書を、前記のカスタママスタデータにより特定される請求書フォーマットの請求書に変換するステップと、
    ｄ） 変換した請求書を第２処理モジュールに送信するステップを実行させ、
    さらに前記のプログラムは、第２処理モジュールに
    ｅ） 当該第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータベースに記憶するステップ
    を実行させることを特徴とする、
    カスタマに対する請求書を電子的に処理するシステムとしてコンピュータを機能させるプログラム。
18. 前記のコンピュータシステムはさらに、第２処理モジュール（コンソリデータ）に接続された第３処理モジュール（ＣＳＰ）を有しており、
    該第３処理モジュールは、
    − カスタマによって入力されるデータを受信する手段と、
    − 当該のカスタマに請求書を提示する出力手段とを有しており、
    前記のプログラムは、前記のまとめた請求書を第３処理モジュールがアクセスできるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１７に記載のプログラム。
19. さらに前記のまとめた請求書をカスタマがアクセスできるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１７または１８に記載のプログラム。
20. さらに前記のまとめた請求書をカスタマに提示または配送できるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１７から１９までのいずれか１項に記載のプログラム。
21. さらに請求書にデジタル署名するステップを前記の第１処理モジュールに実行させる、
    請求項１７から２０までのいずれか１項に記載のプログラム。
22. さらにカスタマがアクセスできるようにするため、前記の請求書の詳細の記憶位置へのリンクを前記のまとめた請求書に設けるステップを第２処理モジュールに実行させる、
    請求項１７から２１までのいずれか１項に記載のプログラム。
23. 前記の作成した請求書を第１処理モジュールによって暗号化し、および／または前記のまとめた請求書を第２処理モジュールによって暗号化するステップを前記の第１処理モジュールまたは第２処理モジュールに実行させる、
    請求項１７から２２までのいずれか１項に記載のプログラム。
24. 前記の作成した請求書を第１処理モジュールによってアーカイブし、および／または前記のまとめた請求書を第２処理モジュールによってアーカイブするステップを前記の第１処理モジュールまたは第２処理モジュールに実行させる、
    請求項１７から２３までのいずれか１項に記載のプログラム。
25. さらに１つまたは複数の別の第２処理モジュールとデータを交換するステップを前記の第２処理モジュールに実行させる、
    請求項１７から２４までのいずれか１項に記載のプログラム。
26. さらに支払いオーダをカスタマから受信するステップを前記の第２処理モジュールに実行させる、
    請求項１７から２５までのいずれか１項記載のプログラム。
27. さらに支払いオーダまたはまとめられた支払いオーダを支払いサービス提供者に転送させるステップを前記の第２処理モジュールに実行させる、
    請求項１７から２６までのいずれか１項に記載のプログラム。
28. さらに前記の請求情報には、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または会計情報が含まれる、
    請求項１７から２７までのいずれか１項に記載のプログラム。
29. さらに前記の請求者マスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１７から２８までのいずれか１項に記載のプログラム。
30. さらに前記のカスタママスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１７から２９までのいずれか１項に記載のプログラム。
31. さらに１つまたは複数の別の第３処理モジュールとデータを交換するためのステップを前記の第２処理モジュールに実行させる、
    請求項１７から３０までのいずれか１項に記載のプログラム。
32. エンタープライズリソースプランニングソフトウェアに使用される、
    請求項１７から３１までのいずれか１項記載のプログラム。
33. 請求項１７から３２までのいずれか１項に記載のプログラムを記憶するコンピュータ読み出し可能媒体。

Images