Field of the Invention

The present invention relates to a system and a method for routing of invoices. Specifically, the present invention relates to a computerized invoice routing system and a computer- implemented method of routing invoices which are generated by invoicing parties for customers.

Background of the Invention

Typically, invoices (i.e. bills) are generated and issued by invoicing parties (i.e. billers) in printed form on paper and sent via postal delivery services to individual customers (i.e. bill recipients). Consequently, a large amount of paper is being used as carrying medium for invoice information and transported physically from the invoicing parties to the customers.

Thus, a considerable volume of CO ₂ emissions is produced by the production and transportation of paper-based invoices. Furthermore, the paper-based invoices are manufactured from cellulose which stems to some large extent from wood, i.e. from trees which are cut for the sole purpose of manufacturing paper for invoices.

Not only are paper-based invoices not environmentally friendly, but paper-based invoices are also inefficient with regards to their handling by senders as well as recipients. Customers receiving paper-based invoices spend time and effort for visiting their physical mail box, extracting any new mail including paper-based invoices, returning to their premises, opening each envelope, and extracting any paper-based invoice from the envelope. Subsequently, the recipients organize and file paper bills, for example by reviewing and sorting paper-based invoices by date and/or invoicing party, hole-punching the invoices, and archiving the invoices in physical file folders. In addition, recipients spend time and effort when searching for a specific invoice. For example, when a recipient needs to locate a paper-based invoice which was sent a year ago, he spends considerable time and effort for searching for the invoice in the physical file folder, particularly when he does not remember the name of the invoicing party or the exact invoice date. Moreover, recipients need to provide physical space in their homes/offices for storing paper-based invoices.

Regardless of whether the paper-based invoices are paid by the recipient via a computer- implemented online banking system or "manually" at a payment teller, e.g. at a post office, a bank or a corresponding service provider, paying paper-based invoices is very time consuming. For example, paying a paper-based invoice through an online-banking system requires an estimated three minutes per invoice for accessing the online banking system (first click), loging into the online banking system (second click), opening a payment option (third click, e.g. for selecting a payment option using a payment slip included with the invoice), entering name, address and banking information of the invoicing party, the invoice amount and an invoice reference number, activating execution of the payment (fourth click), confirming correctness of the entered invoice amount, e.g. by re-entering the invoice amount (fifth click), and submitting the payment (sixth click). Alternatively, for paying paper-based invoices "manually" at a payment teller, considerably more time is spent for the way to and from the location of the teller, waiting in line, handing the invoice to the teller, and paying the invoice by cash or debit card, for example.

Managing paper-based invoices also requires the recipient to remember different payment deadlines for each separate invoice, track which invoices have already been paid and which invoices still need to be paid, and dispose of the envelopes and additional paper received with the invoice. On the other hand, the invoicing parties incur high costs for generating paper-based invoices, including costs for the paper, for the envelopes, and for physical delivery (postage), as well as costs and time associated with manual procedures in preparing, printing and dispatching the invoices. Summary of the Invention

It is an object of this invention to provide an invoice routing system and a method of routing invoices which system and method do not have at least some of the disadvantages of the prior art. In particular, it is an object of the present invention to provide an invoice routing system and a method of routing invoices which system and method make it possible to forward efficiently to customers invoices which are generated by invoicing parties for the customers. In particular, it is another object of the present invention to provide an invoice routing system and a method of routing invoices which system and method make it possible for a customer to manage and pay efficiently and securely invoices received from invoicing parties.

According to the present invention, these objects are achieved particularly through the features of the independent claims. In addition, further advantageous embodiments follow from the dependent claims and the description.

According to the present invention, the above-mentioned objects are particularly achieved in that in a computerized invoice routing system a customer is registered and a system-specific e-mail address is assigned to the customer. An invoice addressed to the customer's system- specific e-mail address is received via a telecommunication network from an invoicing party. For example, the invoice is transmitted and received per e-mail, and the e-mail comprises a non-editable electronic representation of a visualizable (i.e. printable or graphically presentable) invoice, e.g. including a payment slip. For example, the invoice is encrypted and/or electronically signed by the invoicing party. From a plurality of invoices received and addressed to the customer's system-specific e-mail address, the customer selects an invoice via a user interface. The selected invoice is displayed by the user interface together with a graphical element which enables the customer to activate payment of the selected and displayed invoice. For example, the selected invoice is displayed by generating based on the non-editable electronic representation a graphical representation of the invoice and the payment slip, if applicable. Responsive to the customer using the graphical element to activate payment of the selected and displayed invoice, generated is a payment order which includes the selected and displayed invoice and a payment authorization associated with the customer. The payment order is transmitted via the telecommunication network to a financial institution associated with the customer. Transmitting an invoice from the invoicing party to the customer via a telecommunication network makes it possible to transfer invoices electronically without having to use any paper. Displaying the invoice together with a graphical element for activating payment of the displayed invoice makes it possible for the customer to pay a specific invoice efficiently at a single click of the graphical element. Displaying the invoice concurrently with the graphical element establishes a one-to- one relationship between the invoice and the graphical element and, thereby, ensures that a payment order is always and exclusively associated with the invoice that is displayed when the graphical element is activated.

In a preferred embodiment, invoicing parties are registered with the routing system. From the registered invoicing parties, the customer selects invoicing parties via the user interface. The customer's system-specific e-mail address is transmitted to the selected invoicing parties. In a further embodiment, financial institutes are registered with the routing system. From the registered financial institutes, the customer selects financial institutes via the user interface. The customer's system-specific e-mail address is transmitted to the selected financial institutes. The reception of invoices addressed to the customer's system-specific e- mail address is limited exclusively to invoices received from invoicing parties selected by the customer. Limiting the reception of invoices to the customer's selected invoicing parties prevents delivery of unsolicited invoices or other transmissions to the customer's system- specific e-mail address. At the same time, automatic transmission of the customer's system- specific e-mail address to the selected invoicing parties makes is possible for the invoicing parties to set up efficiently (automatically) and promptly customers as communication partners for receiving their invoices though the invoice routing system. In an embodiment, a public encryption key is transmitted to the selected invoicing parties. Subsequently, as an antifraud measure, prior to their transmission, invoices are encrypted by the invoicing parties using the respective customer's public encryption key. The customers decrypt their received invoices using their (secret) private key.

In a further preferred embodiment, the payment order includes an electronic signature which links cryptographically the customer, the displayed invoice and the payment authorization. Thus, the electronic signature not only provides for authenticity of the customer but also ensures integrity of invoice and payment authorization as submitted by the customer. In other words, the electronic signature establishes the authenticity of the link between the invoice, the payment authorization, and the customer, as well as the authenticity of the invoice and the invoicing parties.

In an embodiment, the selected invoice is displayed together with a graphical element which enables the customer to activate rejection of the selected and displayed invoice. Responsive to the customer using the graphical element to activate rejection of the selected and displayed invoice, a payment rejection is generated. The payment rejection includes the selected and displayed invoice and a rejection notification associated with the customer. The payment rejection is transmitted via the telecommunication network to the invoicing party associated with the displayed invoice. Displaying the invoice together with a graphical element for activating rejection of the displayed invoice makes it possible for the customer to reject a specific invoice efficiently at a single click of the graphical element. Displaying the invoice concurrently with the graphical element establishes a one-to-one relationship between the invoice and the graphical element and, thereby, ensures that a payment rejection is always and exclusively associated with the invoice that is displayed when the graphical element is activated. Preferably, in the latter embodiment, the payment rejection includes an electronic signature which links cryptographically the customer, the displayed invoice and the rejection notification. Thus, the electronic signature not only provides for authenticity of the customer but also ensures integrity of invoice and rejection notification as submitted by the customer. In other words, the electronic signature establishes the authenticity of the link between the invoice, the rejection notification, and the customer.

In a further embodiment, a reference is assigned to a registered invoicing party. The reference includes a service code which indicates a service type provided by the registered invoicing party. When an invoice is received, the invoice is filed and/or indexed automatically based on the reference (or at least the service code) associated with the received invoice. In addition, the customer's selection of a selected invoice is based on the index, e.g. the reference or at least the service code, associated with a received invoice. Thus, invoices are filed and/or indexed automatically in accordance with their associated reference (or at least the service code) and can thus be efficiently sorted, selected, and/or displayed. Hence, it is possible for the customers to manage, organize and handle invoices a lot more efficiently and flexibly than paper-based invoices, because there is no need to visit a physical mail box, extract, handle, organize and file physically paper-based invoices, or store and search physical invoices.

In addition to the computerized invoice routing system and the computer-implemented method of routing invoices, the present invention also relates to a computer program product comprising computer program code means for controlling one or more processors of a computer system, preferably a computer program product comprising a computer-readable medium containing the computer program code means therein. Preferably, the computer program code means are configured to control the one or more processors of the computer system such that the computer system registers a customer and assigns a system-specific e- mail address to the customer; receives via a telecommunication network from an invoicing party an invoice addressed to the customer's system-specific e-mail address; receives from the customer via a user interface a selection of a selected invoice from invoices received and addressed to the customer's system-specific e-mail address; displays the selected invoice together with a graphical element which enables the customer to activate payment of the selected and displayed invoice; generates a payment order, responsive to the customer using the graphical element to activate payment of the selected and displayed invoice, the payment order including the selected and displayed invoice and a payment authorization associated with the customer; and transmits the payment order via the telecommunication network to a financial institution.

Brief Description of the Drawings

The present invention will be explained in more detail, by way of example, with reference to the drawings in which:

Figure 1 shows a block diagram illustrating schematically a server and a client computer of an invoice routing system which is interconnected via a telecommunication network with a computer of an invoicing party and a computer of a financial institution.

Figure 2 shows a block diagram illustrating schematically a computerized invoice routing system which is configured to interconnect invoicing parties, customers and financial institutions for the purpose of routing invoices from the invoicing parties to customers and financial institutions.

Figure 3 shows a flow diagram illustrating an exemplary sequence of steps for routing invoices from invoicing parties to customers and financial institutions. Figure 4 shows a diagram illustrating an exemplary user interface for organizing, listing, selecting, displaying, printing, paying and rejecting invoices received by a customer from registered invoicing parties selected by the customer,

Detailed Description of the Preferred Embodiments In Figures 1 and 3, reference numeral 1 refers to a routing system server computer, reference numeral 2 refers to a routing system client computer, reference numeral 3 refers to an invoicing computer, reference numeral 4 refers to a financial institution computer, and, in Figure 1 , reference numeral 5 refers to a telecommunication network. As illustrated in Figure I ₁ the client computer 2 is associated with a customer 20, the invoicing computer 3 is associated with an invoicing party 30, and the financial institution computer 4 is associated with a financial institution 40 such as an (online) bank or a clearing centre. Routing system server computer 1 , routing system client computer 2, invoicing computer 3, and financial institution computer 4 each comprise a communication module enabling data exchange via telecommunication network 5.

For example, client computer 2 is implemented as a fixed or a mobile communication terminal such as a personal computer (PC), a PDA-computer (Personal Digital Assistant) or a mobile radio telephone.

Preferably, telecommunication network 5 includes the Internet accessible to server computer 1 , client computer 2, invoicing computer 3, and financial institution computer 4 through fixed networks and/or wireless networks. For example, the telecommunication network 5 includes a local area network (LAN), Digital Subscriber Lines (DSL), a GSM-network (Global System for Mobile communication), a UMTS-network (Universal Mobile Telephone System) or another mobile radio telephone system, and/or a wireless local area network (WLAN) for accessing the Internet. In Figure 2, reference numeral 10 refers to a computer-implemented invoice routing system comprising various functional modules, including a registration module 1 1 , an invoice receiving module 21 , an invoice management module 22, an invoice payment module 23, an invoice rejection module 24, and an e-mail module 25. As illustrated in Figure 2, invoice routing system 10 further includes a data store 1 10 for storing data related to registered customers 20 and a data store 1 1 1 for storing data related to registered invoicing parties 30. Preferably, the functional modules are implemented as programmed software modules comprising computer program code configured to control one or more processers of the routing system server computer 1 and/or client computer 2 such that the routing system server computer 1 and/or client computer 2 execute functions as described below.

In the following paragraphs, described with reference to Figures 2 and 3 are possible sequences of steps performed by the functional modules for routing and managing invoices issued by a an invoicing party 30 for a customer 20. At first preparatory steps Sl-S6b are described; subsequently, described are steps S7-S18 for routing and managing an invoice 61 issued by invoicing party 30 for customer 20.

In step Sl , an invoicing party 30 is registered with the invoice routing system 10. For example, invoicing party 30 is registered using a conventional web browser running on invoicing computer 3, for example Internet Explorer by Microsoft, Mozilla Firefox by the Mozilla Foundation, or Safari by Apple, for accessing server computer 1 via telecommunication network 5 and transmitting invoicing party registration data to the registration module 1 1. The registration module 1 1 receives and stores the invoicing party's registration data in data store 1 1 1. For example, the registration data associated with an invoicing party includes name, postal address, e-mail address and type of service(s) provided by the invoicing party. Furthermore, the registration module 1 1 generates and stores for the invoicing party a reference which includes an identifier that identifies the invoicing party, and a service code that indicates the specific type of service offered by the invoicing party (in a variant multiple references with different service codes are assigned to an invoicing party providing various types of services). In an embodiment, the reference is transmitted by the registration module 1 1 to invoicing computer 3 where it is stored for future use.

In step S2, a financial institute 40 is registered with the invoice routing system 10. For example, financial institute 40 is registered using a conventional web browser running on financial institution computer 4, for accessing server computer 1 via telecommunication network 5 and transmitting financial institute registration data to the registration module 1 1. The registration module 1 1 receives and stores the financial institute's registration data in data store 1 1 1. For example, the registration data associated with a financial institute includes name, postal address, e-mail address as well as bank identification data such as Bank Identifier Code (BIC). Furthermore, the registration module 1 1 generates and stores for the financial institute a reference which includes an identifier that identifies the financial institute. In an embodiment, the reference is transmitted by the registration module 1 1 to financial institution computer 4 where it is stored for future use.

In step S3, a customer 20 is registered with the invoice routing system 1. For example, customer 20 is registered using a conventional browser running on client computer 2 for accessing server computer 1 via telecommunication network 5 and transmitting customer registration data to the registration module 1 1. The registration module 1 1 receives and stores the customer's registration data in data store 1 10. For example, the registration data associated with a customer includes name and postal address of the customer. Furthermore, the registration module 1 1 generates and stores for the customer a system-specific e-mail address (e.g. αιstomemame@invoicerouting,com). The system-specific e-mail address is transmitted by the registration module 1 1 to customer computer 2 where it is stored for future use. Preferably, a customer specific secret password and additional third level access codes are transmitted to the user via separate channels. In an embodiment, upon registration of the customer, client software for an invoice routing application is transmitted to and installed on client computer 2. The invoice routing client software 200 includes invoice management module 22, invoice payment module 23, and invoice rejection module 24. Depending on the embodiment, the invoice routing client software 200 further includes invoice receiving module 21 and/or e-mail module 25. Using invoice routing client software 200 has the advantage that the exchange of customer- specific and possibly confidential invoice data is limited to a direct data exchange between invoicing party 30 (i.e. invoicing computer 3) and customer 20 (i.e. client computer 2) without involvement of server computer 1.

In an alternative embodiment, invoice receiving module 21 , invoice management module 22, invoice payment module 23, invoice rejection module 24, and/or e-mail module 25 are implemented on server computer 1 and customer 20 uses a conventional browser running on client computer 2 for accessing these functional modules via telecommunication network 5.

In step S4, a registered customer logs into the invoice routing system 10 using his system- specific e-mail address as user name, for example, and entering his password and a third level access code, if applicable. Upon successful login, invoice management module 22 generates user interface 9 which is presented to the customer 20 on client computer 2.

In step S5, customer 20 defines partner invoicing parties 30. For example, user interface 9 displays a list 99 of invoicing parties 30 registered with the invoice routing system 10 (either permanently or in response to an instruction from the customer). From the list 99 of registered invoicing parties 30, the customer selects those from which invoices 61 are to be received via the invoice routing system 10. For example, invoicing parties 30 are selected by setting in the list 99 checkboxes associated with the respective invoicing parties 30. Invoice management module 22 records the selected invoicing parties 30 for the customer 20 in data store 1 10.

Preferably, in step S5a, the invoice receiving module 21 transmits the customer's system- specific e-mail address to the selected invoicing parties 30. Accordingly, in step S5b, the customer's system-specific e-mail address is stored in each case in the invoicing computer 3 of the selected invoicing parties 30. In an embodiment, additionally, the customer's public encryption key is transmitted to the selected invoicing parties 30 and stored in the respective invoicing computer 3 assigned to the customer's system-specific e-mail address.

In step S6, customer 20 defines partner financial institutes 40. For example, list 99 also includes financial institutes 40 registered with the invoice routing system 10. From the list 99 of registered financial institutes 40, the customer selects those to which payment orders are to be sent and from which payment confirmations and monthly balance reports are to be received via the invoice routing system 10. For example, financial institutes 40 are selected by setting in the list 99 checkboxes associated with the respective financial institute 40. In step S6a, upon selection of a financial institute 40, a communication session is established between client computer 2 and the respective financial institute computer 4 and a user interface window prompts the customer to enter his account details for the selected financial institute 40, e.g. an International Bank Account Number (IBAN), a SWIFT code (Society for Worldwide Interbank Financial Telecommunication), account number, clearing number, etc. In an embodiment, the customer is further requested through the user interface window (corresponding to an online banking login) to confirm his identity by entering the bank account specific password and further identification/authentication elements such as a NIP code. Upon successful verification, the user interface window displays to the customer a confirmation from the respective financial institute, confirming that the customer has successfully signed up the financial institute for payment of invoices received via the invoice routing system 10. The selected financial institute(s) 40 and the respective account details are stored for the customer 20 in data store 1 10.

Preferably, in step S6a, the customer's system-specific e-mail address is transmitted to the selected financial institutes 40. Accordingly, in step S6b, the customer's system-specific e- mail address is stored in each case in the financial institution computer 4 of the selected financial institutes 40. In an embodiment, additionally, the customer's public encryption key is transmitted to the selected financial institutes 40 and stored in the respective financial institution computer 4 assigned to the customer's system-specific e-mail address.

In step S7, for customer 20, an invoice 61 is generated at invoicing computer 3. Preferably, invoice 61 is a non-editable electronic representation of a visualizable invoice, i.e. an invoice which is printable (on paper) or graphically presentable (on a display), e.g. an invoice in a Portable Document Format (PDF). Preferably, invoice 61 is generated exclusively and directly in electronic form by invoicing computer 3; alternatively, a non-editable electronic representation could by generated by scanning already existing paper-based invoices. For example, invoice 61 includes a payment slip 61 1. In an embodiment, invoice 61 is provided with an electronic signature 62 based on a private key associated with invoicing party 30. In a further embodiment, invoice 61 is additionally or alternatively encrypted by invoicing computer 3, e.g. by using the customer's public encryption key.

In step S8, invoice 61 is transmitted per invoicing e-mail 6 from invoicing computer 3 via telecommunication network 5 to the customer's system-specific e-mail address, In an embodiment, the invoice 61 or the invoicing e-mail 6 includes the reference and service code associated with invoicing party 30. Preferably, the e-mail's subject indicates the service or product related to the invoice 61. In a further embodiment, the invoice 61 or the invoicing e-mail 6 includes invoice data comprising an invoice amount, an invoice date and an invoice number provided by the invoicing party 30, In step S9, the invoicing e-mail 6 (or at least the invoice 61 included therein) is received by invoice receiving module 21 through e-mail module 25, depending on the embodiment either at server computer 1 or client computer 2. Invoice receiving module 21 checks whether or not the invoicing party 30 who issued and transmitted the invoice 61 is selected by customer 20 as an invoice routing partner. If the invoicing party 30 is not a selected invoice routing partner, the invoice 61 is rejected in step Sl 6. Otherwise, the invoicing e- mail 6 (or at least invoice 61 included therein) is stored in the customer's 20 inbox (either on server computer 1 or on client computer 2). If applicable, invoice 61 is decrypted, e.g. using the customer's private encryption key. In addition, the invoice 61 or invoicing e-mail 6, respectively, is indexed automatically based on the invoicing party's reference, specifically based on the invoicing party's identifier and/or service code included in the reference. Depending on the embodiment, the complete reference or the service code are included in the invoice 61 or invoicing e-mail 6, or the reference or service code, respectively, are determined by invoice receiving module 21 from data store 1 1 1 based on the e-mail sender address associated with the invoicing e-mail 6, i.e. the respective invoicing party 30.

In the following sections, the term "invoice" is used to represent the invoicing e-mail 6 and/or the invoice 61 included therein, unless the term "invoicing e-mail" is used explicitly to represent the e-mail comprising the invoice 61.

In an embodiment, based on its indexing information (e.g. including the invoicing party's identifier and/or the service code included in the reference), an invoice is stored in and/or associated with different folders of the inbox. As shown in Figure 4, depending on service codes associated with the customer's selected invoice routing partners, the customer's inbox 91 may have a variety of service-specific folders (and subfolders) 91 1 , for example phone (mobile, fixed), television, Internet, electricity, insurance (home, health, car), etc., as well as status-dependent folders ("unpaid", "paid", rejected" and optionally "deleted"), or user- defined subject-specific folders ("Home", "Carpenter", "Electrician", "Vacations", etc.). Furthermore, depending on the reference or invoicing party's identity associated with the customer's selected invoice routing partners, the customer's inbox 91 may have a variety of folders (and subfolders) 91 1 specific to different invoicing parties, for example Power Company, Health Ltd., United Bank, etc. In an embodiment, numeric indicators 912, 913 indicate the number of unread or unpaid invoices, respectively, in a specific folder and/or subfolder.

In step Sl O, customer 20 employs user interface 9 to list, sort, select, view and/or delete invoices. As illustrated in Figure 4, user interface 9 is configured to generate and show a list 92 of the invoices included in the inbox or in (customer-) selected folders. In an embodiment, visual indicators 914, 915 indicate unread or unpaid invoices, respectively, in a specific folder and/or subfolder. User interface 9 also includes a data entry field 90 for defining one or more search terms for searching a list of invoices matching and/or including the search term. For each invoice in the list, user interface 9 shows invoice summary data including, for example, the name of the invoicing party 30, the subject of the invoice, the reference and/or invoice number, the date received and/or the invoice amount. By clicking on a list entry 921 , the customer 20 selects the respective invoice. Upon selection, user interface 9 displays the selected invoice. Specifically, user interface 9 shows detailed invoice data 93 for the selected invoice, including invoice data not shown in the list entry 921. Particularly, the user interface 9 shows the non-editable electronic representation of the visualizable invoice 94 including payment slip 95, if applicable. Furthermore, user interface 9 is configured to display together with the selected invoice a first graphical element 96 which enables the customer 20 to activate payment of the selected/displayed invoice 94, and a second graphical element 97 which enables the customer 20 to activate rejection of the selected/displayed invoice 94. For example, the first and second graphical elements 96, 97 are graphical icons, such as function buttons or hypertexts, which when clicked on by a pointing device (e.g. a pointer or cursor 98) activate payment or rejection of the selected/displayed invoice 94, respectively. In an embodiment, graphical elements 96, 97 are positioned dynamically by user interface 9 in an area of the selected/displayed invoice 94 or payment slip 95, respectively, which does not contain any textual or numeric information. In an embodiment, graphical elements 96, 97 are actually included and stored in the electronic representation of the visualizable invoice 61 received by invoice receiving module 21 , before it is presented by user interface 9. Thus, depending on the embodiment, displaying first and second graphical elements 96, 97 together with the selected invoice means not only displaying the invoice and graphical elements 96, 97 concurrently, but displaying (and possibly even storing) the graphical elements 96, 97 as an integral part of the invoice. Upon clicking on the first graphical element 96 ("payment button"), the processing continues in step Sl 1.

In step SI l , the invoice payment module 23 generates a payment order 70 for the selected/displayed invoice 94. As illustrated in Figure 2, the payment order 70 includes the non-editable electronic representation of the visualizable invoice 71 , including payment slip 71 1 , a payment authorization 72, and an electronic signature 73. Preferably, the electronic signature 73 is generated to link cryptographically customer 20, the electronic representation of the visualizable invoice 71 , and payment authorization 72. For example, the electronic signature 73 is generated using a private encryption key associated with the customer 20 to encrypt a defined hash of payment authorization 72 and the electronic representation of the visualizable invoice 71. Thus, using a Public Key Infrastructure (PKI) and the defined hash function, authenticity and integrity of customer 20 and payment order 70 can be verified using the public key associated with the customer 20, For example, the payment authorization 72 includes the invoice amount, the invoice number or reference, information identifying customer 20 and/or banking information such as account information, credit card number and payment method.

In step Sl 2, invoice payment module 23 uses e-mail module 25 to generate payment e-mail 7 including the payment order 70 and transmit the payment e-mail 7 via telecommunication network 5 to financial institution computer 4 associated with a financial institution 40.

In step Sl 3, the financial institution computer 4 receives and stores the payment e-mail 7. Preferably, the financial institution computer 4 uses the public key associated with customer 20 to decrypt the electronic signature 73 and verify identity and authenticity of customer 20. Furthermore, using the defined hash function, the financial institution computer 4 verifies integrity of the link between the electronic representation of the visualizabie invoice 71 and payment authorization 72.

In step SI 4, financial institution 40 executes the payment order by paying the invoice based on the payment authorization data (or rejects the payment, if authentication and/or integrity tests failed).

Although not illustrated in Figure 3, financial institution computer 4 confirms reception and/or execution of the payment order, and in response to the confirmation, invoice management module 22 adjusts the status of the respective invoice from "unpaid" to "paid". In an embodiment, financial institution computer 4 transmits payment reports and/or periodic (monthly) balance reports via telecommunication network 5 to the customer's system-specific e-mail address. The payment reports and/or balance reports are filed automatically in a folder associated with the respective financial institute 40. Thus, the payment reports and/or balance reports can easily be selected by the customer through user interface 9, for review on a display of client computer 2 and/or for creating a printed copy on a printer of client computer 2, e.g. for proof of payment.

In step Sl 5, customer 20 selects another invoice from the list 92. Responsive to the selection of the invoice, user interface 9 displays the selected invoice together, i.e. concurrently, with first and second graphical elements 96, 97. Upon clicking on the second graphical element 97 ("rejection button"), processing continues in step SI 6.

In step Sl 6, the invoice rejection module 24 generates a payment rejection 80 for the selected/displayed invoice 94. As illustrated in Figure 2, the payment rejection 80 includes the non-editable electronic representation of the visualizable invoice 81 , including payment slip 81 1 , a rejection notification 82, and an electronic signature 83. Preferably, the electronic signature 83 is generated to link cryptographically customer 20, the electronic representation of the visualizable invoice 81 , and rejection notification 82. For example, the electronic signature 83 is generated using a private encryption key associated with the customer 20 to encrypt a defined hash of rejection notification 82 and the electronic representation of the visualizable invoice 81. Thus, using a Public Key Infrastructure (PKI) and the defined hash function, authenticity and integrity of customer 20 and payment rejection 80 can be verified using the public key associated with the customer 20. For example, the rejection notification 82 includes the invoice amount, the invoice number or reference and/or information identifying customer 20.

In step SI 7, invoice rejection module 24 uses e-mail module 25 to generate rejection e-mail 8 including the payment rejection 80 and transmit the rejection e-mail 8 via telecommunication network 5 to invoicing computer 3 associated with invoicing party 30.

In step Sl 8, invoicing computer 3 receives and stores rejection e-mail 8. Preferably, invoicing computer 3 uses the public key associated with customer 20 to decrypt the electronic signature 83 and verify identity and authenticity of customer 20. Furthermore, using the defined hash function, invoicing computer 3 verifies integrity of the link between the electronic representation of the visualizable invoice 81 and rejection notification 82. Although not illustrated in Figure 3, invoicing computer 3 confirms reception and/or execution of the payment rejection, and in response to the confirmation, invoice management module 22 adjusts the status of the respective invoice from "unpaid" to "rejected". User interface 9 permits customer 20 to delete invoices having a "paid" or "rejected" status. In an embodiment, in order to adhere to accounting regulations and/or for auditing purposes, a deleted invoice may be assigned a "deleted" status without actually being deleted. Invoices having a "deleted" status will be hidden by user interface 9, unless a specific function is selected to list and/or display "deleted" invoices.

It should be noted that, in the description, the computer program code has been associated with specific functional modules and the sequence of the steps has been presented in a specific order, one skilled in the art will understand, however, that the computer program code may be structured differently and that the order of at least some of the steps could be altered, without deviating from the scope of the invention.