TECHNICAL FIELD

The various aspects relate to processing and updating of invoice information. BACKGROUND

If customers are late with payments, a reminder is sent that may be accompanied with an updated invoice with an increased invoice amount. Despite the reminder and the updated invoice and the increased amount, customers can still use the information of the original invoice and pay the original amount. If customers subsequently pay the original amount, an amount is still outstanding.

SUMMARY

A first aspect provides in an invoice information server, a method of processing invoice information. The method compr ises r eceiving invoice info rmation representing an invoice and g enerating a transaction reference for identifying the invoice information The transaction reference is provided to an invoice generation module . The transaction reference is also sent to a payment handling server with the invoice information . The method further comprises re ceiving updated invoice information representing an updated invoice related to the invoice and g enerating an updated transaction reference for identifying the updated invoice information. T he updated transaction reference and the updated invoice information are sent to the payment support server for replacing the transaction reference and the invoice information.

By providing the updated transaction reference and the updated invoice information to the payment support server, like a payment service provider (PSP), one can ensure that a payment of the invoice through the payment service provider is handled in accordance with up to date information. So in that case, payment serv ice provider is able to ensure that the invoice is paid including the late payment fee in case applicable.

An embodiment of the first aspect comprises starting running of a timer on a timer unit providing an incrementing time value; and wherein receiving updated invoice information comprises generating the updated invoice information if the time value is equal or larger than a pre-determined value.

This embodiment allows for a fully automated dunning procedure, making the method of the first aspect more efficient.

In another embodiment of the first aspect the invoice payment information server comprises an invoice enhancement module for adding information to the invoice, the method further comprising: receiving the invoice; and adding the transaction reference to the invoice.

This embodiment provides invoices that may comprise usual invoice details like goods and/or services purchased, as well as a link to for example the payment service provider. With the transaction reference, the payment service pr ovider can look up the corresponding invoice information received earlier and facilitate the payment of the invoice by the intended payer. In this way, the customer as intended payer only has to fill in bare necessities like a pin code or the like, as othe r details like invoice identifier and amount are already pre-filled in. A second aspect provides in a payment support server, a method of supporting a payment comprising r eceiving invoice information representing an invoice , receiving a transaction refere nce for iden tifying the invoice information, r eceiving updated invoice information and receiving an updated transaction reference for identifying the updated invoice information . The invoice information is replaced with the updated invoice information and the transaction reference is replaced with the updated transaction reference. The method further comprises r eceiving the updated transaction reference from an intended payer of the invoice and e nabling the intended payer of the invoice to select a payment handling service for payment of the invoice in accordance with the updated invoice information. The intended payer is forwarded payer to a payment handling server corresponding to the selected payment handling service; and the updated invoice information is also forwarded to the selected payment handling server.

In this way, the payment support server of a payment service provider arranges that with the intended payer being forwarded to the payment handling server - like an acquirer and/or a card issuer or a bank -, also payment information is provided that applies at the moment the intended payer wants to pay. So if the invoice amount is updated and increased, the updated invoice information with the updated invoice amount is provided by the payment service provider to the bank.

An embodiment of the second aspect further comprises upon receiving the updated transaction reference, saving the transaction reference receiving earlier; after having received the updated transaction reference, receiving the transaction reference from the intended payer ; and providing a message to the intended payer that the updated transaction reference is to be obtained by the intended payer.

If, for whatever reason, the intended payer uses an earlier transaction reference for accessing the payment support server, the payment support server is able to recognise the earlier transaction reference as it is kept. In case an updated transaction reference is available, the payment support server is able to identify that the earlier tra nsaction reference and corresponding earlier invoice information may not apply anymore. So this embodiment allows to recognise that an earlier transaction reference is used by the intended payer, that the corresponding earlier invoice information does not apply anymore and inform the intended payer accordingly.

In another embodiment of the second aspect, the invoice information comprises validity information indicating a validity period of the invoice information, the method further comprising upon r eceiving the transaction reference from the intended payer of the invoice, verifying whether the validity period of the invoice information has not expired; and sending an error message to the intended payer if the validity period of the invoice information has expired.

This embodiment allows a quick and accurate check whether data used by a user is valid or has been updated.

A further embodiment of the second aspect further comprises receiving a message from the payment handling server that an updated amount comprised by the updated invoice information has been paid by the intended payer; and forwarding a message comprising invoice information and information that the updated amount comprised by the updated invoice information has been paid by the intended pay er to an invoice administration server.

With this embodiment, the invoice administration server is informed in time that an invoice has been paid, allowing a dunning process to be stopped.

A third aspect provides an invoice information server comprising a communication unit and a processing unit. The communication unit is arranged to r eceive invoice information representing an invoice; and receive updated invoice information representing an updated invoice related to the invoice. The processing unit arranged to generate a transaction reference for identifying the invoice information; and generate an updated transaction reference for identifying the updated invoice information . T he communication unit is further arranged to: provide the transaction reference to an invoice generation module, s end the transaction reference and the invoice information to a payment handling server; and send the updated transaction reference and the updated invoice information to the payment support server for replacing the transa ction reference and the invoice information.

A fourth aspect provides a payment support server comprising a communication unit, a storage module and a processing unit. The communication unit is arranged to receive invoice information representin g an invoi ce and a transaction reference for identifying the invoice information as well as to receive updated invoice information and an updated transaction reference for identifying the updated invoice information. The storage module arranged to store the invoice information, the transaction reference, the updated invoice information and the updated transaction reference. The processing unit arranged to r eplace the invoice information with the updated invoice information ; and replace the transaction reference with the updated transaction reference. The communication unit is further arranged to r eceive the updated transaction reference from a n intended payer of the invoice and the processing unit is further arranged to enable the intended payer of the invoice to sele ct a payment handling service for payment of the invoice in accordance with the updated invoice information.

Furthermore, the communication unit is arranged to f orward the intended payer to a payment handling server corresponding to the selected payment ha ndling service; and forward the updated invoice information to the selected payment handling server. A fifth aspect provides a computer programme product comprising computer executable instruction to enable a computer to carry out the method according to the first aspect.

5 A sixth aspect provides a programmable computer programmed to carry out the method according to the first aspect.

A seventh aspect provides a computer programme product comprising computer executable instruction to enable a computer to carry out the method according to the l o second aspect.

An eighth aspect provides a programmable computer programmed to carry out the method according to the second aspect.

15 BRIEF DESCRIPTION OF THE DRAWINGS

The various aspects and embodiments thereof will now be discussed in further detail in conjunction with Figures. In the Figures: Figure 1 : shows a network system; and

20

Figure 2: shows a flowchart. DETAILED DESCRIPTION

Figure 1 shows a network system 100 comprising a network infrastructure 102, an order 25 administration server 130, an invoice linking server 1 10, a payment facilitator server 140, a bank server 150 and a customer computer 160. The order administration server 130, the invoice linking server 1 10, the payment facilitator server 140, the bank server 150 and the customer computer 160 are connected to one another via the network infrastructure 102 such that they are able to communicate with one another. The

30 network infrastructure 102 may be wired, wireless, or a combination thereof and a wide area network, a local area network or a combination thereof.

The order administration server 130 comprises a processing unit 132, a harddisk 134 as a storage module, a network communication module 136, an invoice information processing unit 138 and a timer module 139. The invoice linking server 1 10 comprises a processing unit 1 12, a harddisk 1 14 as a storage module, a network communication module 1 16, an invoice information pro cessing unit 1 18 and a timer module 1 19. The payment facilitator server 140 comprises a processing unit 142, a harddisk 144 as a storage module and a network communication module 146. The bank server 150 comprises a processing unit 152, a harddisk 154 as a storage module and a network communication module 156. The customer computer 160 comprises a processing unit 162, a harddisk 164 as a storage module and a network communication module 166. The computers, including the serves may be conventional computers, but also portable devices like mobile telephones, to the extent suitable for the function to perform.

Instead of harddisks, also other means for storage of data may be used, like non volatile solid state memories, optical discs or other. The harddisks ha ve software stored on them that allow the processing units of the computers, including the servers, to be programmed to perform the methods and procedures as disclosed. Alternatively, the computers comprise dedicated hardwired electronics to operate as des cribed below. The processing units are also arranged to control the operation of the computers and to process information sent and received by the communication modules of the computers. The processing units may comprise clock units keeping a value of loca I time zone time value or the value of another time zone.

The communication modules of the computers are arranged for two-way communication with other communication modules of the other computers, either directly or via the network infrastructure 102. The communication modules may comprise multiple units arranged for communication via various protocols, including but not limited to Ethernet, Bluetooth, USB, WiFi or other, for either wired or wireless communication. Optionally, the communication modules may comprise modems like ADSL modems, cable modems or modems for cellular communication of data. The operation of the various servers and computers comprised by the wide area network system 100 will now be discussed in detail in conjunction with a flowchart 200 depicted by Figure 2. The process depicted by the flowchart 200 is carried out by various components of the wide area network system 100. The table below provides a brief overview of various steps of the flowchart 200. These steps will subsequently be discussed in further detail.

Step no. Brief description

202 Start process

204 Receive invoice information

206 Create invoice

208 Receive link

210 Append link to invoice

212 Send invoice

214 Receive invoice

216 Send access request

220 Send link request

222 Receive link request

242 Generated reference

226 Generate link

228 Send link to invoice server

230 Send reference to payment facilitator

232 Send invoice information to payment facilitator

234 Receive reference

236 Receive invoice information

238 Store reference

240 Store invoice information

242 Receive access request

244 Analyse access request

246 Reference still valid?

248 Facilitate payment

250 Receive transaction result

252 Payment successful?

254 Report payment

256 Stop timer

258 End process

260 Issue error message

262 End process 270 Issue error message

272 End process

280 Start timer

282 Run timer

284 Timer equal or larger than pre-determined value?

286 Update invoice information

288 Send updated invoice information

The process starts in a terminator 202 and is followed by the order administration server 130 receiving invoice information in step 204. The invoice information is in this embodiment generated by an order processing system in which an order for goods or services by a customer is process ed. An invoicing address and an order for goods or services are received from the customer. This information may be received from the customer computer 160. Alternatively, this information may be received by telephone or paper and is entered in the order administration server 130 manually.

For the goods or services, a price is calculated by the order processing system. Based on this information, the invoice information is created. Such invoice information comprises preferably an invoice identifier for identifying an invoice for payment for the goods or services ordered, a customer identifier identifying the customer and an invoice amount. The customer identifier may be a string of alphanumerical or numerical characters that uses less storage space than the full customer information including addresses, telephone numbers and the like. The latter information may later be looked up in a database with for example the customer identifier as a look -up key. Also the invoice identifier may be a string of alphanu merical or numerical characters. Optionally, also other or less information may be included in the invoice information.

In step 206, an invoice is created based on the invoice information received. This may be done by the order administration server 130. The invoice may be in text only or in marked up text, for example in portable document format, Open Office format, hypertext mark up language, Word format or another format. The invoice may be specified, specifying each an every good and/or service purchas ed, with price per piece, with the full contact details of the customer. Alternatively, some information is abbreviated. For example the full contact details of the customer may be reduced to a first name, last name and an email address and may be accompanied by the customer identifier.

In step 220, the invoice information is sent to the invoice linking server 1 10. The invoice information is received by the invoice linking server 1 10 in step 222. In step 224, the invoice linking server generates an invoice reference related to the invoice information. The invoice reference may be a string of alphanumerical or numerical characters that uses less storage space than the full invoice information. The invoice reference may the same as or different from the invoice identifier. In step 226, a link is created for later use to access the payment facilitator server 140 for payment of the invoice. The link is preferably a uniform resource locator - URL - referring to a domain name via which the payment facilitator serv er 140 is accessible. The link - and specifically the URL preferably also comprises the invoice reference.

In step 228, the link is sent to the order administration server 130, which receives the link in step 208. Subsequently, the link is appended to t he invoice created in step 206. The link may be appended by adding it as a single string to the invoice. This works particularly well with a text -only invoice. If the invoice has been generated in a mark -up language, further operations may need to be perfo rmed to fit the link and the text thereof properly in the marked up and made up invoice. Alternatively, the invoice is sent to and received by the invoice linking server 110 and the link is appended to the invoice by the invoice linking server 1 10.

With the link appended to the invoice, the invoice in finalised and sent out in step 212. The invoice may be sent out to the customer by means of regular paper mail, electronic mail or another public or proprietary electronic communication protocol.

In step 21 4, the invoice is received by the customer. That may be as an email or a portable document format file received by electronic mail or a proprietary system like an Enterprise Resource Planning ( EPR) system or accounting system for electronic invoicing. Alternatively, the invoice is received in paper form via regular mail. With the invoice sent and received via an electronic communication protocol, the invoice may be received via the customer computer 160. In step 216, the link generated earlier is used by th e customer an entered into the customer computer 160 to access the payment facilitator server 140 via the network communication module 166 of the customer computer 160 and the network communication module 146 of the payment facilitator server 140. Having sent the link to the order administration server 130 in step 228, the invoice linking server 1 10 sends the link to the payment facilitator server 140 in step 230. The invoice linking server 1 10 sends the invoice information to the payment facilitator serve r 140 in step 232. The payment facilitator server 140 receives the link in step 234 and the invoice information in step 236.

The link is stored on the harddisk 144 of the payment facilitator server 140 in step 238 and the invoice information is stored on the harddisk 144 of the payment facilitator server 140 in step 240. The link and the invoice information are stored in a database structure stored on the harddisk 144, allowing the invoice information to be looked up by means of the invoice reference. The record and/or cells comprised therein may be accompanied with a lifetime indicator, indicating until what time and/or date the record and/or individual cells thereof are valid and/or may be accessed. Though sending, receiving and storing the invoice inform ation and the link are depicted as individual steps, both may be sent and received one and the same message in communication between the order administration server 130 and the payment facilitator server 140.

In step 242, the access request issued in step 216 by the customer via the customer computer 160, is received by the payment facilitator server 140. The payment facilitator server 140 receives, with the access request, the link created earlier and with that, the invoice reference created earlier. Afte r having been received, the access request is analysed. In particular, the invoice reference comprised by the link is analysed. The analysis of the invoice reference may comprise checking whether the format is correct, calculation of a checksum and verifying the checksum, looking up invoice information by means of the invoice reference received in step 242 in the database stored on the harddisk 144, checking validity information in the record and verifying it to the actual time recorded in the payment facilitator server 140, other or any combination thereof.

In decision 246 is checked whether the invoice reference received in step 242 exists, is valid or is still valid. If the invoice reference exists and is valid, process continues with 248 by facilitating payment of the invoice amount by the customer or any other entity. The payment facilitator server 140 facilitates the payment by providing the paying entity a choice between payment options, like direct debiting payment via electronic means or payment by means of credit card, a choice of a bank holding an account from which the outstanding invoice amount is to be paid, other options or a combination thereof.

If the invoice reference does not exist or is not valid, the process branches to step 260 in which an error message is issued to the customer computer 160 and the process ends in terminator 262.

Upon receiving option information from the paying entity, the paying entity is, via the customer computer 160, redirected by the payment facilitator server 14 0 forwarded to the bank server 150 for actual instruction of the payment of the outstanding invoice amount. In particular the bank server 150 may be more than one computer, managed by multiple entities like an acquirer and a card issuer. The outcome of the actual instruction may be successful or not, depending on credentials of the paying entity, an amount on the bank account, other, or a combination thereof.

The result of the payment instruction is received back by the payment facilitator server 140 in st ep 250 and in decision 252 is checked whether the payment has been executed successfully or not. If the payment has been executed successfully, the result is communicated to the customer computer 160 in step 254. The positive result is preferably also comm unicated to the order administration server 130 in the same step.

The latter may be provided to mark the applicable invoice as paid, preventing the customer from receiving payment reminders. Subsequently, the process ends in terminator 258. In between, in a step 258, a timer that will be discussed below in further detail is stopped.

If the payment instruction has not been executed successfully, the process branches to step 270 in which an error message is communicated to the customer computer 160. Also an error message may be issued to the order administration server 130.

Subsequently, the process ends in terminator 272. It should be noted that forwarding error messages related to payments to servers or computers other than the customer computer 160 may result in privacy issues. From step 206, the process also branches to step 280, in which a timer is started with the timer module 1 19 of the invoice linking server 1 10. Alternatively or additionally, the timer is started with the timer module 139 of the orde r administration server 130. Preferably, the invoice reference is associated with the timer or the value thereof. The timer is kept running in step 282 and in decision 284 the value of the timer is compared to a pre-determined value. The pre-determined value corresponds to a payment term for the invoice and is stored on the harddisk 134 of the order administration server 130 and/or on the harddisk 1 14 of the invoice linking server 130. This is a relatively long term - at least days or weeks -, so the value of the timer does not have to be checked on a continuous basis. The value of the timer may also be checked once per day, at any interval between continuous or at a longer interval.

If the value of the timer is lower than the pre-determined value, the timer is kept running. The timer may be stopped upon receiving information that the invoice has been paid. If the value of the timer is equal to or higher than the pre -determined value, the process branches to step 286 in which the invoice information is u pdated to provide updated invoice information. The updating of the invoice information is handled either by the invoice information processing unit 1 18 of the invoice linking server 1 10 or by the invoice information processing unit 138 of the order adminis tration server 130. In particular in this embodiment, the invoice information is updated by increasing the amount of the invoice by a late payment fee. This may be a fixed fee, a percentage of the outstanding amount, other, or a combination thereof. The u pdated invoice information is subsequently provided to the order administration server 130 in step 288, upon which it is received by the order administration server 130 in step 204 again. Upon re -execution of the step 204, at least some of the various further steps of the procedure depicted by the flowchart 200 may be executed again. Re-execution of these steps with the updated invoice information having in an embodiment the same invoice identifier as the original invoice information means in an embodiment that in step 238 and step 240 the data of the original invoice information is overwritten by the updated invoice information. This means in practice that earlier dat a for the original invoice information stored in the harddisk 144 is actually overwritten by the updated invoice information , thus rendering the original invoice information inaccessible for the intended payer.

Alternatively, a new record is created by the payment facilitator server 140. In this embodiment, the earlier described validity information is set such that the original invoice information is valid up to the moment that the timer that is run in step 282 and checked in step 284 to the pre -determined value. Records may in such case be complemented with a date and/or time value that is substantially equal to the date of the original invoice, plus the pre -determined value. So the original record is kept and expires at the expiry date of the original invoice. At substantially that moment, possibly little later due to processing and net work traffic delay, an updated record is created based on the updated invoice information.

So in this case, two records with the same invoice identifier may exist, but with different validity data and validity period in particular and with different amoun ts. These records have different identifiers that may be pointed to . The intended payer will receive a reference to the updated invoice information and the original invo ice information will be rendered inaccessible. This may be performed by assigning a pointer already available to the intended payer from a first record comprising the original invoice data to a second record comprising the updated invoice data. This means the intended payer will only be able to pay the invoice by using the updated invoice information , thus by paying the updated amount . With paper invoices, the old invoice would still be available once received by mail by the intended payer, allowing the intended payer to pay the original amount as the information would still be available. By providing data through the system as discussed here, the original invoice information can be made inaccessible and the intended p ayer may always be provided with the updated invoice information once available and valid.

In practice this still means that the original invoice information is replaced by the updated invoice information as the original invoice information expires at about the same moment the updated invoice information becomes active. So replacing does not necessarily mean physical replacement of data or overwriting of data . The validity information may be set by the invoice linking server 1 10, by the order administration server 130, other, or a combination thereof. The validity information may be part of t he invoice information.

With the updated invoice information processed and the access request analysed in particular in step 244, it is checked whether the link data sent with the access request relates to the updated invoice information or the invoice in formation. For the following scenario, the updated invoice information is stored in the payment facilitator server 140 and the original invoice information is not valid anymore - and the access request is made with a link comprising a reference to the original invoice information.

The access request is analysed, the record with the original invoice data is retrieved as that is where the access request refers to and the validity of the original invoice data is checked. As the record with the original invoice data is not valid anymore - because the first payment term has expired and the date and time in the validity data record has passed - the process branches in decision 246 to step 260 in which an error message is issued.

In this scenario, the error messa ge specifically indicates that the link used and the invoice with which the link has been provided have expired and that the updated link with the updated invoice should be used. In this way, a customer is after the expiry of a first payment forced to use the link with the updated invoice , with which the customer is forced to pay the invoice amount incremented earlier in step 286. Alternatively, expiry of invoice information is automatically triggered at the moment updated invoice information is received. T his embodiment requires checking whether newer invoice information and/or a newer transaction reference is available. If so, the earlier data record may be deleted or marked as invalid and/or expired. Alternatively, this is done on the fly when an access request with a transaction reference arrives.

In this way, parts of the process depicted by the flowchart 200 may be repeated several times, until the invoice has been paid, either within the first payment term or even in a third or fourth term.

Expressions such as "comprise", "include", "incorporate", "contain", "is" and "have" are to be construed in a non -exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. In particular various steps of embodiments of the first and second aspects may be performed by either one of the invoice linking system 1 10, the payment facilitator server 140 or the order administrator server 130. The servers by all be fully integrated in one physical device as well as split over multiple physical devices. Reference to the singular is also to be construed in be a reference to the plural and vice versa.

In the description above, it will be understood th at when an element such as layer, region or substrate is referred to as being "on", "onto" or "connected to" another element, the element is either directly on or connected to the other element, or intervening elements may also be present.

Furthermore, the invention may also be embodied with less components than provided in the embodiments described here, wherein one component carries out multiple functions. Just as well may the invention be embodied using more elements than depicted in the Figures , wherei n functions carried out by one component in the embodiment provided are distributed over multiple components. A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodim ents disclosed and/or claimed may be combined without departing from the scope of the invention.

It is stipulated that the reference signs in the claims do not limit the scope of the claims, but are merely inserted to enhance the legibility of the claims.