WO2016204666A1

WO2016204666A1 - Method and system for facilitating exchange of invoice related information

Info

Publication number: WO2016204666A1
Application number: PCT/SE2016/000035
Authority: WO
Inventors: Olof Andersson
Original assignee: SCHÜTT, Peder
Priority date: 2015-06-16
Filing date: 2016-06-14
Publication date: 2016-12-22

Abstract

The present disclosure relates to a method performed by an electronic invoice adapting system (11) for facilitating exchange of invoice related information between an electronic invoice issuer (1) and an electronic invoice receiver (2). The electronic invoice adapting system derives (1101), from a non-human data source (4) comprising information related to an electronic invoice (5), at least a first piece of content (51) characterizing the electronic invoice. The electronic invoice adapting system further generates (1103) an electronic file name (6) comprising at least a first field (61), which at least first field comprises the at least first content. Moreover, the electronic invoice adapting system associates (1104) the electronic invoice with the electronic file name.

Description

METHOD AND SYSTEM FOR FACILITATING EXCHANGE OF INVOICE RELATED INFORMATION

TECHNICAL FIELD

The present disclosure relates to an electronic invoice adapting system and a corresponding electronic invoice interpreting system, and methods performed therein, for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. BACKGROUND

There are many ways in which different entities choose to communicate, in order to send and receive invoices - as well as pay, execute and announce payments. Solutions span from complete manual routines to complex electronic flows. In many countries and/or areas, it is still common to issue manual checks for payment purposes, whereas in Scandinavia, for instance, it is common to utilize a relatively high degree of automated electronic flow.

An electronic flow in the technical field in question, may relate to electronic invoicing. Commonly, integrations between an invoice issuer, a bank and an invoice receiver have an Electronic Data Interchange (EDI) format. However, due to the EDI format being rather complex, relatively few issuers choose to connect their business software to the banks' e- invoicing systems. The complexity, in part, has to do with the fact that an invoice receiver needs to interpret the graphical content of the electronic document. This brings about several disadvantages - for instance that the graphical interpretation needed in the present EDI solutions is an indirect route that not only makes the information exchange more complex than it needs to be. It also affects the quality of the received information negatively. Further disadvantages relate to the graphical content - i.e. the layout - being restricted to what is actually possible for the software to interpret. Furthermore, interpretation errors may occur. In these cases, the interpreted document does not fully match the original, and as a consequence the interpreted document is not fully usable in the hands of the receiver. Yet another is that if the invoice receiver requires an original, or if the invoice issuer wants to provide an original as a service, the invoice issuer may need to send the original as a separate file. This procedure will naturally be more costly for both the invoice issuer and the bank; additionally, it will be more complicated to handle for the invoice receiver. Still another disadvantage relates to that, due to the need to interpret the graphical content of the electronic document, there are a lot of different standard formats - both on a national and an international level. This may be one of the reasons why banks commonly use third party vendors, who may handle some of the different complexities, like providing invoice convertors. Since the graphical content needs to be interpreted and since the interpretation requirements escalate over time, yet another disadvantage relates to that the interpretation software and file standards need to be updated to match the new requirements. Accordingly, all parties need to adapt to the ever new standard revisions, which may be both unorderly and costly. Consequently, the disadvantages described above may be a major hindrance for improved efficiency, since they inhibit a lot of parties in their efforts to join electronic invoicing systems.

Yet another electronic flow in the technical field in question, may relate to automated invoice reception. Automated invoice reception is commonly handled by loading the of the received electronic file, e.g. into a business software, which may imply the complexity described above. Alternatively automated invoice reception may be handled by scanning and interpreting of a printed paper invoice, in which case an even greater interpretation problem occurs as, compared to the interpretation of the electronic file described above. That is, a commercial invoice receiver may need to invest in third party software - used for scanning, interpreting and archiving the printed invoice - which may need to be integrated with the business software. Not uncommonly, partial interpretation errors occur - upon which a manual check and a manual interpretation need to be performed. Such a check is commonly not performed by the same person who attests the invoice - who is likely to have a good idea of what questionable parts of the invoice mean - but rather by the person who scans the invoice - who may not have any information at all about what the questionable parts mean. The result may be a clear efficiency loss, as the invoice may need to be passed back and forth for information confirmation. Furthermore, a large portion of printed invoices is commonly not possible to scan and/or interpret at all, which may be the case concerning e.g. invoices received via fax. Consequently, several methods are commonly required to get invoices registered and archived, which increase the workload and makes financial routines less organized.

Still another electronic flow in the technical field in question, may relate to automated payments. That is, in scenarios where the invoice issuer and the invoice recipient have different banks, there needs to be an agreement in place - between at least two parties - regarding how the information transfer should be performed. Presently, there is no uniform world standard in place to determine how invoice payments should be automatically performed. Solutions implemented up to date are often peer to peer agreements between banks. In some countries there are nationwide standards, in which case the payments commonly are executed via a separate "Clearing house". One example of such a clearing house is "Bankgirocentralen" ("BG"), situated in Sweden. However, the solutions differ from country to country and as discussed above, in most countries there is not even a nationwide standard implemented. Moreover, there are also differences between national payments and international payments. International payments are generally slower, more expensive for the user, and many times partially characterized by manual work effort. Even though semi global initiatives have been presented, these appear to be restricted merely to automated payments rather than being aimed at handling the entire electronic flow. Typically, common solutions and initiatives have a high level of complexity and a need for expensive third party solutions, which altogether is a hindrance for many entities' route towards standardization and automation.

Yet another electronic flow in the technical field in question, may relate to consumers' e- invoice payment. The complex EDI format mentioned above also affects consumer's wanting to pay via internet, as the current e-invoice layout formats and are limited to what the interpretation software may interpret, and as interpretation errors may occur. As a result the invoices become harder to read. Furthermore the complexity of the solutions offered has the consequence that relatively few invoice issuers choose to send their invoices electronically. Thus, consumers commonly put more time and energy into administrating their payments than they would need to - had the banks had a more flexible solution in place.

Consequently, as may be derived from the discussions above, there is a lack of global standard(s) in the mentioned technical fields. As discussed above, the solutions in place are generally complex - and subsequently expensive - and the lack of standard(s) opens up for a broad diversity of solutions, which may be confusing for different entities when it comes to deciding which solution to choose. Moreover, there appears to be no known single solution in place that covers the entire flow electronically. Consequently, at least partly due to the difficulties mentioned in the foregoing, it appears that relatively few entities invest in an electronic invoicing and payment flow - which is a hindrance in worldwide progress towards higher financial efficiency. SUMMARY OF THE INVENTION

It is therefore an object of embodiments herein to provide a technical approach for facilitating electronic exchange of information related to an electronic invoice.

According to a first aspect of embodiments herein, the object is achieved by a method performed by an electronic invoice adapting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. The electronic invoice adapting system derives, from a non-human data source comprising information related to an electronic invoice, at least a first piece of content characterizing the electronic invoice. The electronic invoice adapting system moreover generates an electronic file name comprising at least a first field, which at least first field comprises the at least first content. Furthermore, the electronic invoice adapting system associates the electronic invoice with the electronic file name. The deriving, generating and associating steps are not carried out by humans but by non-human entities, such as computers or machines.

The word "associates" is intended to mean that electronic invoice is re-named using the electronic file name comprising the at least first content and the electronic invoice may then be used, i.e. sent, forwarded, stored etc. together with the electronic file name comprising the at least first content. Alternatively, once an electronic file name comprising the at least first content has been generated, this electronic file name is linked with the electronic invoice, for example by providing a database that stores the electronic invoice or information concerning the electronic invoice together with the electronic file name comprising the at least first content, whereby the electronic invoice can be accessed on request, but whereby only the electronic file name is used in subsequent correspondence, i.e. the entire electronic file name is not sent, forwarded, stored etc. together with the electronic invoice that it concerns. A party receiving the electronic file name comprising the at least first content may be provided with information on how a copy of the electronic invoice that it concerns may be obtained, if said party wants to receive the electronic invoice itself.

Thereby, the file name may be utilized so that necessary payment information - e.g. all information that is necessary for the electric invoice to be automatically identified, registered, logically stored and duly paid - is comprised in the file name itself. Subsequently, there is no need to interpret the graphical part of the document, i.e. the printout. As a result, there is no discrepancy between the invoice issuer's, bank's and/or invoice receiver's data.

An advantage of embodiments according to the inventive concept is thus that the graphical part of the file may be utilized only for the purpose of visual presentation, documentation and archiving, in the hands of both issuer and receiver. Since the content further does not need to be interpreted, the issuer may choose freely how to construct the layout. This also means that the issuer can enclose commercial messages, insurance letters and/or other information in the same document/file. This, of course, has the potential of both increasing income and lowering costs.

Furthermore, embodiments of the inventive concept may support the entire invoice and payment flow - from electronic invoice printing, via bank reception, via end receiver reception, archiving of the electronic invoice at the hand of the end receiver, and invoice payment. That is - full automation may be achieved, using one standardized system. Thus vendors, customers and/or banks may exchange invoice related information electronically in an efficient, uniform and organized manner.

Yet another advantage is, as indicated above, that the commercial receiver does not need to interpret the content of the document. Instead, all information needed to register the invoice may be presented in the file name. Via the file name, the file - with its graphical content - can also be linked to the registered/posted invoice. As a consequence, there is no need to invest in separate third party softwares to scan, interpret and/or to archive the original document.

Still another advantage is that a technical approach is provided which permits a uniform integration and a uniform operation mode for all parties, using electronic invoicing and automated reception - without the need for expensive and complicated third party solutions. Another advantage is that embodiments of the inventive concept provide a high security level, in that for banks, the documents do not need to be opened - they only need to be identified via the electronic file name. Correspondingly, a high security level is provided for the commercial receiver, as he or she may need to register the vendor in his or her business software - thereby approving the vendor for payment - and can send the payment directly via his or her internet bank; no third parties or third party software involved. The security issues may thereby be limited to the banks payment site.

Yet another advantage is that all parties involved may save money via lower transaction costs, lower development costs, a uniform standard and/or a larger volume - as more issuers and receivers can afford to use electronic invoicing. In addition, cost savings may be achieved in that less manual work may be required as compared to commonly known automated systems. Still another advantage is that the file format may further be totally open, and not dependent on a specific platform, e.g. operating system.

Another advantage with embodiments of the inventive concept is that, since the invoice document/file is an original, it may meet legal standards.

Yet another advantage is that embodiments of the inventive concept may set a standard, even a world standard, which all business software vendors and/or banks - with a small effort and a low cost - can adopt. The potential standard(s) may be uniform for all parties - as the same principal may be used regardless of whether the information exchange is performed between issuer and bank, directly between issuer and end receiver, and/or between bank and end receiver. Moreover, the potential standard(s) may work throughout the whole world, as preferably all necessary information needed for payment is presented in the file name. Furthermore, the potential standard(s) makes it possible for a commercial receiver to, at a certain point in time, only accept electronic invoices in accordance with such a new standard. The receiver may accordingly need to approve the invoice issuer in order for the invoice to get registered and paid. The result is that the risk of paying swindlers may be eliminated and/or reduced, as swindlers commonly tend to send fraudulent invoices in paper format only. For that reason, a technical approach is provided for facilitating electronic exchange of information related to an electronic invoice.

Expressions utilized throughout the disclosure may be defined as follows: "Invoice issuer", sometimes also abbreviated "issuer": any type of entity who may issue an invoice, e.g. a vendor.

"Invoice receiver", sometimes also abbreviated "receiver": any type of entity who have been addressed to receive an invoice, e.g. a bank or a customer.

"Customer", sometimes also expressed as "end receiver": for instance a commercial human or non-human customer or a consumer. "Commercial customer": a commercial human or non-human invoice receiver.

"Consumer": a non-commercial_human or non-human invoice receiver.

"End receiver": A commercial customer or a consumer.

"Third party": someone/something, e.g. a human or non-human entity, that provides technical products or services that accommodates for instance communication needs, electronic file interpretation needs and/or format conversion needs - during information exchange between the main parties, e.g. issuers, banks and/or end receivers.

"Clearing house": a third human or non-human party that regulates payments between issuer and end receiver.

"Invoice": an arbitrary electronic document - or paper document. The term "invoice" also comprises - but is not limited to - a tab, a debt instrument, a bill of debt, ticket, receipt, etc.

"Invoice converter": a service that converts an invoice from the issuer's format to the format used by the receiver. This service is often provided by a non-human third party.

The terms above may be used alternatively throughout the disclosure. The terms are then to be regarded as interchangeable, meaning that for instance "vendor" may have the same broad meaning as an "invoice issuer".

The technical features and corresponding advantages of the above mentioned method will be discussed in further detail in the following. By introducing a method performed by an electronic invoice adapting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver, an approach is provided which enables e.g. vendors to provide invoice related information to e.g. customers and/or banks electronically in an efficient, uniform and organized manner. "System" may throughout this disclosure refer to one or more "units", whereas "electronic invoice" throughout this disclosure may be abbreviated "e-invoice".

Since the electronic invoice adapting system derives, from a non-human data source comprising information related to an electronic invoice, at least a first piece of content characterizing the electronic invoice, data associated with the electronic invoice is fetched from a data storage. "Deriving" may for instance refer to "retrieving", "reading", "fetching", "receiving" and/or "determining", whereas "content characterizing the electronic invoice" throughout this disclosure may refer to "payment information characterizing the electronic invoice", "data indicative of the electronic invoice" and/or "payment data indicative of the electronic invoice". Moreover, the "non-human data source" - which for instance may be comprised in a commonly known business software or business software system - may refer to "data storage" and/or "one or more memory units". Since the electronic invoice adapting system moreover generates an electronic file name comprising at least a first field, which at least first field comprises the at least first content, a file name may be created comprising necessary payment information - e.g. all necessary payment information. "Generating" may refer to "creating" and/or "determining", whereas "field" throughout this disclosure may refer to "part" and/or "section".

Since the electronic invoice adapting system further associates the electronic invoice with the electronic file name, payment information characteristic for the electronic invoice may be comprised in the file name itself, such that there is no need for a subsequent invoice receiver to interpret the graphical part of the document, i.e. the printout, only the file name. "Associating" may in this context refer to "associating electronically" and/or "associating digitally".

According to an embodiment, the at least first piece of content may comprise one or more of an invoice receiver ID, a payment method, a payment receiver ID, a BIC code, a document type, a payment ID, a document date, a due date, a currency and/or an amount. Thereby, one or more commonly utilized pieces of necessary payment information may be comprised in the file name itself, rather than and/or in addition to being comprised in the graphical part of the electronic invoice. According to another embodiment, the electronic invoice adapting system may further derive, from the data source, at least a second piece of content characterizing the electronic invoice. The electronic invoice adapting system then generates an electronic file name comprising at least a first field and at least a second field separated by one or more delimiters, which at least first field comprises the at least first content and which at least second field comprises the at least second content. Thereby, at least two, or preferably more, pieces of content indicative of necessary payment information may be derived and subsequently comprised in the generated electronic file name. "Delimiters" - which for instance may refer to "separators" - are provided in order to enable separating the first field from the second field, the second field from a potential third field, etc.

According to yet another embodiment, the electronic invoice adapting system associating the electronic invoice with the electronic file name, may comprise naming, re-naming and/or saving the electronic invoice using the electronic file name. In this context, "naming" may refer to "naming electronically" and/or "naming digitally", "re-naming" may refer to "re- naming electronically" and/or "re-naming digitally", whereas "saving" may refer to "saving electronically" and/or "saving digitally".

According to still another embodiment, the electronic invoice adapting system may further send - directly or indirectly to the electronic invoice receiver and/or an electronic invoice interpreting system associated with the electronic invoice receiver - the electronic file name and/or the electronic invoice with the electronic file name. "Sending" may in this context refer to "submitting", "providing" and/or "communicating".

According to a second aspect of embodiments herein, the object is achieved by a method performed by an electronic invoice interpreting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. The electronic invoice interpreting system interprets at least a first field of an electronic file name associated with an electronic invoice, wherein the at least first field comprises at least a first piece of content characterizing the electronic invoice. Similar advantages as those mentioned in the foregoing in relation to the first aspect correspondingly apply, which is why these advantages are not further discussed.

By introducing a method performed by an electronic invoice interpreting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver, an approach is provided which enables e.g. customers and/or banks to interpret invoice related information received electronically from e.g. a vendor in an efficient, uniform and organized manner. Moreover, since the electronic invoice interpreting system interprets at least a first field of an electronic file name associated with an electronic invoice, which at least first field comprises at least a first piece of content characterizing the electronic invoice, a file name comprising necessary payment information - e.g. all necessary payment information - may be interpreted. "Interpreting" may for instance refer to "reading" and/or "construing".

According to an embodiment, the at least first piece of content may comprise one or more of an invoice receiver ID, a payment method, a payment receiver ID, a BIC code, a document type, a payment ID, a document date, a due date, a currency and/or an amount. According to another embodiment, the electronic invoice interpreting system may interpret at least a second field of the electronic file name, wherein the at least second field comprises at least a second piece of content characterizing the electronic invoice. The at least first field and the at least second field are then separated by one or more delimiters. According to yet another embodiment, the electronic invoice interpreting system may receive - directly or indirectly from the electronic invoice issuer and/or from the electronic invoice adapting system discussed above associated with the electronic invoice issuer - the electronic file name, and/or the electronic invoice with the electronic file name. "Receiving" may for instance refer to "obtaining" and/or "acquiring".

Similar advantages as those mentioned in the foregoing in relation to the first aspect correspondingly apply to the second aspect, which is why these advantages are not further discussed. According to a third aspect of embodiments herein, the object is achieved by an electronic invoice adapting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. The electronic invoice adapting system comprises a content deriving unit adapted for deriving - from a non-human data source comprising information related to an electronic invoice - at least a first piece of content characterizing the electronic invoice. The electronic invoice adapting system moreover comprises a file name generating unit adapted for generating an electronic file name comprising at least a first field, which at least first field comprises the at least first content. Furthermore, the invoice adapting system comprises an associating unit adapted for associating the electronic invoice with the electronic file name.

According to an embodiment, the at least first piece of content may comprise one or more of an invoice receiver ID, a payment method, a payment receiver ID, a BIC code, a document type, a payment ID, a document date, a due date, a currency and/or an amount.

According to another embodiment, the content deriving unit may further be adapted for deriving, from the data source, at least a second piece of content characterizing the electronic invoice. The file name generating unit is then adapted for generating an electronic file name comprising at least a first field and at least a second field separated by one or more delimiters, which at least first field comprises the at least first content and which at least second field comprises the at least second content.

According to yet another embodiment, the electronic invoice adapting system may further comprise a sending unit adapted for sending - directly or indirectly to the electronic invoice receiver and/or the electronic invoice interpreting system discussed above associated with the electronic invoice receiver - the electronic file name, and/or the electronic invoice with the electronic file name.

According to still another embodiment, the associating unit may be adapted for naming, renaming and/or saving the electronic invoice using the electronic file name.

Similar advantages as those mentioned in the foregoing in relation to the first aspect correspondingly apply to the third aspect, which is why these advantages are not further discussed. According to a fourth aspect of embodiments herein, the object is achieved by an electronic invoice interpreting system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. The electronic invoice interpreting system comprises a file name interpreting unit adapted for interpreting at least a first field of an electronic file name associated with an electronic invoice, wherein the at least first field comprises at least a first piece of content characterizing the electronic invoice.

According to another embodiment, the file name interpreting unit may further be adapted for interpreting at least a second field of the electronic file name, wherein the at least second field comprises at least a second piece of content characterizing the electronic invoice. The at least first field and the at least second field are then separated by one or more delimiters.

According to yet another embodiment, the electronic invoice interpreting system may further comprise a receiving unit adapted for receiving - directly or indirectly from the electronic invoice issuer and/or from the electronic invoice adapting system discussed above associated with the electronic invoice issuer - the electronic file name, and/or the electronic invoice with the electronic file name.

Similar advantages as those mentioned in the foregoing in relation to the second aspect correspondingly apply to the fourth aspect, which is why these advantages are not further discussed.

According to a fifth aspect of embodiments herein, the object is achieved by a computer program product comprising a computer program containing computer program code means arranged to cause a computer or a processor to execute the steps of the electronic invoice adapting system discussed above, stored on a computer-readable medium or a carrier wave. Yet again, similar advantages as those mentioned in the foregoing in relation to the first aspect correspondingly apply to the fifth aspect, which is why these advantages are not further discussed. According to a sixth aspect of embodiments herein, the object is achieved by a computer program product comprising a computer program containing computer program code means arranged to cause a computer or a processor to execute the steps of the electronic invoice interpreting system discussed above, stored on a computer-readable medium or a carrier wave. Yet again, similar advantages as those mentioned in the foregoing in relation to the second aspect correspondingly apply to the sixth aspect, which is why these advantages are not further discussed.

According to a seventh aspect of embodiments herein, the object is achieved by a method performed by an electronic invoice enhancement system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver. The electronic invoice enhancement system derives, by means of the electronic invoice adapting system discussed above, from a non-human data source comprising information related to an electronic invoice, at least a first piece of content characterizing the electronic invoice. The electronic invoice enhancement system further generates, by means of said electronic invoice adapting system, an electronic file name comprising at least a first field, which at least first field comprises the at least first content. Moreover, the electronic invoice enhancement system associates, by means of the electronic invoice adapting system discussed above, the electronic invoice with the electronic file name. Furthermore, the electronic invoice enhancement system interprets, by means of the electronic invoice interpreting system discussed above, the at least first field of the electronic file name associated with the electronic invoice.

By introducing a method performed by an electronic invoice enhancement system for facilitating exchange of invoice related information between an electronic invoice issuer and an electronic invoice receiver, an approach is provided which enables e.g. vendors, customers and/or banks to exchange invoice related information electronically in an efficient, uniform and organized manner. Similar advantages as those mentioned in the foregoing in relation to the first and second aspects correspondingly apply to the seventh aspect, which is why these advantages are not further discussed.

BRIEF DESCRIPTION OF THE DRAWINGS

The various aspects of the non-limiting embodiments of the invention, including particular features and advantages, will be readily understood from the following detailed description and the accompanying drawings, in which: Figure 1 is a schematic block diagram illustrating an exemplifying electronic invoice adapting system and an exemplifying electronic invoice interpreting system according to embodiments of the disclosure;

Figure 2 illustrates an exemplifying electronic file name associated with an electronic invoice generated according to embodiments of the disclosure;

Figure 3 is a flowchart depicting an exemplifying method performed by an electronic invoice adapting system according to embodiments of the disclosure;

Figure 4 is a flowchart depicting an exemplifying method performed by an electronic invoice interpreting system according to embodiments of the disclosure; Figure 5 is a flowchart depicting an exemplifying method performed by an electronic invoice enhancement system according to embodiments of the disclosure; and

Figures 6a-d relate to exemplifying electronic flows involving embodiments of the disclosure.

DETAILED DESCRIPTION

The non-limiting embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which currently preferred embodiments of the disclosure are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Like reference characters refer to like elements throughout. Dashed lines of some boxes in the figures indicate that these units or actions are optional and not mandatory. In the following, according to embodiments herein which relate to facilitating exchange of invoice related information between an electronic invoice issuer 1 and an electronic invoice receiver 2, there will be disclosed an approach for e.g. vendors, customers and/or banks to exchange invoice related information electronically in an efficient, uniform and organized manner. Referring now to the figures and Figure 1 in particular, there is depicted a schematic block diagram illustrating on the left hand side an exemplifying electronic invoice adapting system 11 and on the right hand side an exemplifying electronic invoice interpreting system 21 according to embodiments of the disclosure. Together, the electronic invoice adapting system 11 and the electronic invoice interpreting system 21 constitute an electronic invoice enhancement system 12.

The electronic invoice adapting system 11 - which for instance may be associated with and/or situated at the electronic invoice issuer 1 and/or comprised in or associated with a commonly known invoice/business software system of the electronic invoice issuer 1 - is configured for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2. The electronic invoice issuer 1 may be represented by any arbitrary entity that may issue an invoice, for instance a vendor, whereas the electronic invoice receiver 2 may be represented by any arbitrary entity that may be addressed to receive an invoice, for instance a bank or a customer.

As further shown on the left hand side in Figure 1 , the electronic invoice adapting system 1 - which may be realized purely by software, or by software in combination with hardware - comprises a content deriving unit 111 , a file name generating unit 112, and an associating unit 113, all of which will be further described in conjunction with Figures 3 and 4. Moreover, the electronic invoice adapting system 11 may comprise an optional sending unit 114, which correspondingly will be further described in conjunction with Figure 3 and 4. Furthermore, the embodiments herein for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2, may be implemented through one or more processors, such as a processor 115, here denoted CPU, together with computer program code for performing the functions and actions of the embodiments herein. Said program code may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the electronic invoice adapting system 11 and/or into e.g. an invoice/business software system in which said electronic invoice adapting system 11 may be comprised or be associated with. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the electronic invoice adapting system 11 and/or to said optional invoice/business software system.

The electronic invoice adapting system 11 may further comprise, and/or utilize, a memory 5 116 comprising one or more memory units. The memory 116 may be arranged to be used to store e.g. information, and further to store data, configurations, schedulings, and applications, to perform the methods herein when being executed in the electronic invoice adapting system 11 or in said optional invoice/business software system. Furthermore, the content deriving unit 111 , the file name generating unit 112, the associating unit 113, the0 optional sending unit 114, the optional processor 115, and/or the optional memory 116 may for instance be implemented in one or several arbitrary electronic devices, such as computers and/or servers. Those skilled in the art will also appreciate that the content deriving unit 111 , the file name generating unit 112, the associating unit 113, and/or the optional sending unit 114 described above, and which will be described in more detail later5 on in this description, may refer to software; additionally or alternatively to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory such as the memory 116, that when executed by the one or more processors such as the processor 15 perform as will be described in more detail later on. One or more of these processors, as well as the other digital hardware, may be0 included in a single ASIC (Application-Specific Integrated Circuitry), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a SoC (System-on-a-Chip).

Further shown in Figure 1 is a non-human data source 4, which may be associated with5 the electronic invoice adapting system 11 , the electronic invoice issuer 1 and/or the optional business software system of the electronic invoice issuer 1. The data source 4, which for instance may be represented by one or more data bases and/or which according to some embodiments may comprise - or be comprised in - the memory 116 discussed above, comprises information related to an electronic invoice 5. The electronic invoice 5 is0 characterized by at least a first piece of content 51 and an optional at least second piece of content 52, which will be further described in conjunction with Figure 2. Associated with the electronic invoice 5 is moreover an electronic file name 6, which correspondingly will be further described in conjunction with Figure 2. The electronic invoice interpreting system 21 on the other hand - which for instance may be associated with and/or situated at the electronic invoice receiver 2 and/or be comprised in or associated with a commonly known invoice/business software system of the electronic invoice receiver 2 - is configured for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2.

As further shown on the right hand side in Figure 1 , the electronic invoice interpreting system 21 - which may be realized purely by software, or by software in combination with hardware - comprises an associating unit 211, which will be further described in conjunction with Figures 3 and 5. Moreover, the electronic invoice interpreting system 21 may comprise an optional receiving unit 212, which correspondingly will be further described in conjunction with Figures 3 and 5.

Furthermore, the embodiments herein for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2, may be implemented through one or more processors, such as a processor 215, here denoted CPU, together with computer program code for performing the functions and actions of the embodiments herein. Said program code may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the electronic invoice interpreting system 21 and/or into e.g. the invoice/business software system in which said electronic invoice interpreting system 21 is comprised or associated with. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the electronic invoice interpreting system 21 and/or to said optional invoice/business software system.

The electronic invoice interpreting system 21 may further comprise, and/or utilize, a memory 216 comprising one or more memory units. The memory 216 may be arranged to be used to store e.g. information, and further to store data, configurations, schedulings, and applications, to perform the methods herein when being executed in the electronic invoice interpreting system 21 and/or in said optional invoice/business software system. Furthermore, the associating unit 211 , the optional receiving unit 212, the optional processor 215, and/or the optional memory 216 may for instance be implemented in one or several arbitrary electronic devices, such as computers and/or servers. Those skilled in the art will also appreciate that the associating unit 211 and/or the optional receiving unit 212 described above, and which will be described in more detail later on in this description, may refer to software; alternatively to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory such as the memory 216, that when executed by the one or more processors such as the processor 2 5 perform as will be described in more detail later on. One or more of these processors, as well as the other digital hardware, may be included in a single ASIC (Application-Specific Integrated Circuitry), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a SoC (System-on-a-Chip).

Turning now to Figure 2, there is illustrated an exemplifying electronic file name 6 associated with an electronic invoice 5, generated according to embodiments of the disclosure. The shown electronic file name 6 here comprises a plurality of fields each comprising content characterizing the electronic invoice 5.

The electronic file name 6 comprises at least a first field 61, which at least first field 61 comprises the at least first content 51 characterizing the electronic invoice 5; here an "Invoice Receiver ID" of the exemplifying number "1234567". The word "field" may for instance refer to section, part and/or portion.

Moreover, optionally, the electronic file name may comprise at least a second field 62, which second field 62 comprises the at least second content 52 characterizing the electronic invoice 5; here a "Payment method" indicated by the exemplifying number "0", e.g. representing "Bankgiro" ("BG"). The at least first field 61 and the at least second field 62 may then be separated by one or more delimiters 63. The one or more delimiters 63 - which may refer to one or more separating characters - may be represented by and/or comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs; here a delimiter 63 is represented by an exemplifying underscore, i.e. The one or more delimiters 63 may need to be distinguishable, such that they may be interpreted as delimiters 63 and not content 51 , 52 of the fields 61 , 62.

The one or more pieces of content 51 may, for instance, comprise one or more of an invoice receiver ID, a payment method, a payment receiver ID, a BIC code, a document type, a payment ID, a document date, a due date, a currency, and/or an amount. The invoice receiver ID - which may refer to an ID of the invoice receiver, e.g. a receiver ID at the end receiver's bank - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, such as exemplifying "01234567".

The payment method - which may refer to type of payment, e.g. national payment or international payment - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, e.g. exemplifying "BG=0". The payment receiver ID - which may refer to an ID of the payment receiver, e.g. an ID of exemplifying "BG" - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, e.g. exemplifying "5510-8500".

The BIC code - or an equivalent or successor thereof - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, e.g. exemplifying "0".

The document type - which may refer to invoice or credit memo - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, e.g. exemplifying "0".

The payment ID - which may refer to the ID of the payment - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs, e.g. exemplifying "1721020090239". The document date - which may refer to the issuance date of the invoice - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs - e.g. exemplifying "20150430".

The due date - which may refer to the payment due date of the invoice - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs - e.g. exemplifying "20150528".

The currency - which may refer to a currency in which the invoice is to be paid - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs - e.g. exemplifying "SEK". The amount - which may refer to the amount to be paid - may comprise any arbitrary number of, and combination of, digits, letters, characters and/or signs - e.g. exemplifying "2500,5".

Figure 3 is a flowchart depicting an exemplifying method performed by an electronic invoice adapting system 11 according to embodiments of the disclosure. The exemplifying method, which may be continuously repeated, comprises the following actions discussed with support from Figures 1 and 2. The actions may be taken in any suitable order, and even be performed simultaneously where applicable. It should for instance be noted that the optional Action 1102 alternatively may be performed prior to, or simultaneously with, Action 1101. The exemplifying method is for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2; correspondingly - as previously discussed - the electronic invoice adapting system 11 is configured for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2.

Action_1101

In Action 1101 , the electronic invoice adapting system 11 derives, from the non-human data source 4 comprising information related to the electronic invoice 5, the at least first piece of content 51 characterizing the electronic invoice 5. Correspondingly, the content deriving unit 111 is adapted for deriving - from the non-human data source 4 comprising information related to the electronic invoice 5 - the at least first piece of content 51 characterizing the electronic invoice 5.

Optionally, as discussed above in conjunction with Figure 2, the one or more pieces of content 51 may comprise one or more of an invoice receiver ID, a payment method, a payment receiver ID, a BIC code, a document type, a payment ID, a document date, a due date, a currency, and/or an amount.

Action_1102

In optional Action 1102, the electronic invoice adapting system 11 may derive - from the data source 4 - the at least second piece of content 52 characterizing the electronic invoice 5. Correspondingly, the content deriving unit 111 may further be adapted for deriving from the data source 4, the at least second piece of content 52 characterizing the electronic invoice 5.

Action_1103

5 In Action 1103, the electronic invoice adapting system 11 generates the electronic file name 6 comprising the at least first field 61. Correspondingly, the file name generating unit 112 is adapted for generating the electronic file name 6 comprising the at least first field 61. The at least first field 61 comprises the at least first content 51 , as shown in Figure 2.

10 Optionally, should Action 1103 of generating the electronic file name 6 follow upon optional Action 1102 of deriving the at least second piece of content 52 characterizing the electronic invoice 5, then Action 1 03 may comprise generating the electronic file name 6 comprising the at least first field 61 and the at least second field 62 separated by the one or more delimiters 63. Correspondingly, should the content deriving unit 111 be adapted for deriving

15 - from the data source 4 - the at least second piece of content 52 characterizing the electronic invoice 5, then the file name generating unit 112 may be adapted for generating the electronic file name 6 comprising the at least first field 61 and the at least second field 62 separated by the one or more delimiters 63. The at least first field 61 comprises the at least first content 51 and the at least second field 62 comprises the at least second content

20 52, as shown in Figure 2.

Action_1104

In Action 1104, the electronic invoice adapting system 11 associates the electronic invoice 5 with the electronic file name 6. Correspondingly, the associating unit 113 is adapted for associating the electronic invoice 5 with the electronic file name 6.

25

Optionally, Action 1104 of associating the electronic invoice 5 with the electronic file name 6, may comprise naming, re-naming and/or saving the electronic invoice 5 using the electronic file name 6. Correspondingly, the associating unit 113 may be adapted for naming, re-naming and/or saving the electronic invoice 5 using the electronic file name 6.

30

Action_1105

In optional Action 1105, the electronic invoice adapting system 11 may send - directly or indirectly to the electronic invoice receiver 2 and/or to the electronic invoice interpreting system 21 - the electronic file name 6 and/or the electronic invoice 5 with the electronic file 35 name 6. Correspondingly, the electronic invoice adapting system 11 may further comprise a sending unit 114 adapted for sending - directly or indirectly to the electronic invoice receiver 2 and/or to the electronic invoice interpreting system 21 - the electronic file name 6 and/or the electronic invoice 5 with the electronic file name 6. Figure 4 is a flowchart depicting an exemplifying method performed by an electronic invoice interpreting system 21 according to embodiments of the disclosure. The exemplifying method, which may be continuously repeated, comprises the following actions discussed with support from Figures 1 and 2. The actions may be taken in any suitable order, and even be performed simultaneously where applicable. It should for instance be noted that the optional Action 2103 alternatively may be performed prior to, or simultaneously with, Action 2102. The exemplifying method is for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2; correspondingly - as previously discussed - the electronic invoice interpreting system 21 is configured for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2.

Action_2101

In optional Action 2101 , the electronic invoice interpreting system 21 may receive - directly or indirectly from the electronic invoice issuer 1 and/or the electronic invoice adapting system 11 - the electronic file name 6 and/or the electronic invoice 5 with the electronic file name 6. Correspondingly, the receiving unit 212 may be adapted for receiving - directly or indirectly from the electronic invoice issuer 1 and/or the electronic invoice adapting system 11 - the electronic file name 6 and/or the electronic invoice 5 with the electronic file name 6.

Action_2102

In Action 2102, the electronic invoice interpreting system 21 interprets the at least first field of the electronic file name 6 associated with the electronic invoice 5. Correspondingly, the file name interpreting unit 211 is adapted for interpreting the at least first field of the electronic file name 6 associated with the electronic invoice 5. The at least first field 61 comprises the at least first piece of content 51 characterizing the electronic invoice 5.

Action_2103

In optional Action 2103, the electronic invoice interpreting system 21 may interpret the at least second field 62 of the electronic file name 6. Correspondingly, the file name interpreting unit 211 may further be adapted for interpreting the at least second field 62 of the electronic file name 6. The at least second field 62 comprises the at least second piece of content 52 characterizing the electronic invoice 5. Moreover, the at least first field 61 and the at least second field 62 are separated by the one or more delimiters 63, as shown in Figure 2.

Figure 5 is a flowchart depicting an exemplifying method performed by the electronic invoice enhancement system 12 according to embodiments of the disclosure. The electronic invoice enhancement system 12 comprises the electronic invoice adapting system 11 and the electronic invoice interpreting system 21 discussed above, and is accordingly for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2; correspondingly the electronic invoice enhancement system 12 is configured for facilitating exchange of invoice related information between the electronic invoice issuer 1 and the electronic invoice receiver 2. The exemplifying method, which may be continuously repeated, comprises on the left hand side the actions of the electronic invoice adapting system 11 discussed above in conjunction with Figure 3, and on the right hand side the actions of the electronic invoice interpreting system 21 discussed above in conjunction with Figure 4. It may be noted that Action 2 01 and/or Action 2102 may follow upon Action 1104 and/or Action 1105.

Figures 6a-d relates to exemplifying electronic flows involving embodiments of the disclosure and are provided for visualization of how the inventive concept may be implemented. It should be noted that a variety of flows are conceivable, and that the electronic flows discussed in the following should be considered exemplifying.

The table below presents exemplifying different parts of a file name of an electronic invoice according to embodiments of the disclosure. Column three shows an example of field contents for a national payment - which corresponds with the exemplifying electronic file name shown in Figure 2 - and column four shows an example of field contents for an international payment.

The different fields of the electronic file name may be separated with a respective separating character, i.e. a delimiter, as also shown in Figure 2. In order to distinguish the separating character used as a delimiter from the content of the fields, the separating character is here reserved to be utilized solely as a delimiter; thus restricted from being comprised in the content of the fields characterizing the electronic invoice. The delimiter may need to occur as many times as there are parts - i.e. fields - in the file name, in order to ascertain that all fields are attended to. In the shown examples, the character underscore, has been chosen as a delimiter; however, as previously indicated, any suitable character(s) can be used. The file name may have an extension at the end, indicating the file format of the electronic invoice. The file format may be arbitrary, i.e. may be completely open. In the example below, the electronic invoice is a file of commonly known PDF format, showing that the file both has a file name and a graphical content. Accordingly, the file name may for instance - for a national payment - and as also shown in Figure 2, be represented by:

Ί 234567890_0_5510-500_0_0_1721020090239.20150430_20150528_SEK_2500, 50_.PDF"

Similarly, the file name may for instance - for an international payment - be represented by:

"234567890_2_FI62500000045466455_FINBABIC_0_90239_20150430_20150528_EUR_800,29_.PDF" In the shown examples, in order to avoid potential integration problems concerning different date formats, the exemplifying date format "YYYYMMDD" is implemented for the document date as well as for the due date. Thereby, there is suggested a solely numerical date format, e.g. without dashes or forward slashes, thus enabling for the format to be numerically sorted. This would not necessarily have been the case, should e.g. slashes or dashes have been included in the date format, and/or should DD have been put in front of MM.

Similarly, in the shown examples, in order to avoid potential integration problems concerning different decimal formats, the exemplifying comma character, i.e. is implemented for the amount. Thereby, the risk of mixing up the decimal character with the "thousand delimiter" may be eliminated.

The file transfer - e.g. from invoice issuer to invoice receiver - may be performed in any arbitrary manner known in the art. In the shown examples, exemplifying e-mail is utilized as file carrier. Thereby, the electronic invoice is sent in a convenient manner and by means of a standardized technique, with built-in check functions that all relevant parties may already have access to.

In the following, there will be described exemplifying business scenarios, i.e. electronic flows, in which the inventive concept may be utilized. Figure 6a illustrates an overview of potential parties involved, i.e. a vendor, a customer, the customer's bank and the vendor's bank. A flow from the vendor to the customer or the customer's bank is denoted A, a flow from the customer's bank to the customer denoted B, a flow from the customer to the customer's bank denoted C, and a flow from the customer's bank to the vendor's bank denoted D. Figure 6b illustrates symbol explanations of symbols utilized to visualize the exemplifying scenarios to follow. Firstly, an exemplifying establishment of an electronic business relationship will be described. Provided that the end receiver accepts automated handling of electronic invoicing, the flow may be started with the establishment of an electronic business relation. In the scenario of the end receiver being represented by a commercial receiver, the commercial receiver may send the following information - e.g. via email - to the new vendor:

- The name of the receiver's bank

- The receiver's customer ID at the bank, i.e. previously discussed "Invoice receiver ID" - The e-mail address, or addresses, to where the electronic invoices shall be sent

The vendor may then register the commercial customer in his or her business software, using all, or part, of the information above. Moreover, the commercial receiver may register the vendor to accept the vendor to be paid electronically:

- In his or her business software, e.g. using previously discussed "Payment Receiver ID"

- At his or her bank Correspondingly, in the scenario of the end receiver being represented by a consumer, there may be at least two alternative approaches for a business relationship to be established between an invoice issuer and a consumer. According to the first approach, when the customer receives the first invoice - which may have been sent directly from the invoice issuer - the consumer may upload the invoice directly to the bank, e.g. while being logged into the internet bank. The bank may be able to identify and establish the invoice as an electronic invoice and handle it accordingly. According to the second approach, which is a commonly known process, the bank is notified by the invoice issuer that the electronic invoices are available and that the consumer can choose to accept electronic invoicing from his/her internet bank. The electronic invoice may then be sent from the invoice issuer to the bank.

Secondly, an exemplifying fully integrated business to business (B2B) electronic flow will be described with reference to Figure 6c. The exemplifying flow comprises Actions 1- 15 discussed with support from Figures 6a and 6b. The actions may be taken in any suitable order, and even be performed simultaneously where applicable. It should be noted that boxes indicated by bold edges and bold text may be intended to refer to functionality related to embodiments of the inventive concept. Moreover, boxes indicated by bold edges but without text being bold, may be intended to refer to functionality which may go beyond this disclosure, for which adaptations are presumed in order to support embodiments of the inventive concept.

Action 1 :

The invoice issuer may register an invoice.

Action 2:

The invoice issuer may post and/or print the invoice. The business software may print the invoice in e.g. a PDF format , whereupon the business software may use the electronic invoice adapting system to name the file, as discussed in conjunction with Figures 1-4.

Action 3:

When the invoice is posted and/or printed, an e-mail - with the pdf-file attached - may automatically be created.

Action 4:

The e-mail may automatically be sent to either the customer's bank (5a-5c) or directly to the customer (5A-5B). The customer may also have requested that the issuer send an invoice to the bank with a copy directly to the customer. The copy is useful in such a way that the end user more quickly can start up an attest flow. Action 5:

The customer's bank may receive the invoice:

a) The file name may be interpreted and checked, with the aid of the electronic invoice interpreting system. If an error is found, the mail may be returned automatically. The system may also check, again with the aid of the electronic invoice interpreting system, if the end receiver has registered his vendor in his internet bank. If this has not been done, then the e-mail may be returned automatically.

b) The transaction may then be registered - with the aid of the electronic invoice interpreting system - in the bank's e-invoice system, where e.g. the first six fields may make for the primary key in one transaction. If a transaction with the same primary key already exists, then the e-mail may be automatically returned. c) The customer may download new invoices from the bank. Action 6:

The customer may upload the file into his or her business software:

The file may have been sent via the customer's bank (5a-5c) or directly from the invoice issuer (5A-5B).

a) The file name may be interpreted and checked, with the aid of the electronic invoice interpreting system. If an error is found, the mail may be returned automatically. The system may also check, with the aid of the electronic invoice interpreting system, if the end receiver has registered his vendor in his internet bank. If this has not been done, then the e-mail may be returned automatically. b) The file may be uploaded into the business software automatically, via the interpreted file name, and a link to the document - for visual reading and/or for printing - may be stored.

Action 7:

The invoice may be posted and a link to the invoice file may be created. At the same time, a vendor ledger entry may be created.

Action 8:

At a certain time, the end receiver may choose to pay a certain batch of invoices. The receiver may therefore create a text file containing which invoices to be paid, and to what extent.

Action 9:

The customer may log on to the internet bank and upload the file containing the invoices to be paid, whereupon the internet bank may match the invoices to the ones already registered - and mark the invoices to be paid.

Action 10:

After a final check, the customer may then confirm the payment, whereupon the customer's internet bank may execute the payment.

Action 1 1 :

The vendor's bank may receive and store the payment file, which may have been sent by the end receiver's bank.

Action 12:

The vendor's bank may register the received payments on the vendor's account. Action 13:

The vendor may regularly log onto his or her internet bank and download registered payments. Action 14:

The vendor may upload the payment file into his/her Cash receipt journal.

Action 15:

The vendor may post the uploaded payment.

In the scenario of a semi integrated B2B electronic flow - which may apply when the receiver prefers to upload the invoice according to Action 6 above but prefers to pay manually or in accordance with other automated payment systems - then Actions 8-9 or 8- 10 may be ignored.

Furthermore, in the scenario of a B2B flow with bank integration only - which may apply when the commercial receiver does not have the functionality to upload the electronic invoice - then the flow, at the customer's end, may end when the customer, e.g. the end receiver, has received the e-mailed invoice. Actions 6, 6-7, 8-9 and/or 6-10 may in this scenario accordingly be ignored, and the commercial receiver instead handle the invoice as commonly known in the art.

In the scenario of a B2B flow with no integration - which may apply should e.g. neither the bank nor the end customer prefer any integration at all - then the invoice issuer may still use the same routine, that is:

- Print and send the invoice via e.g. PDF directly to the end receiver, utilizing embodiments of the inventive concept, or

- Print and post the invoice as a paper invoice. Thirdly, an exemplifying business to consumer (B2C) electronic flow will be described with reference to Figure 6d. The difference between the scenarios of Figures 6c and 6d mainly relate to the end customer in the latter case being represented by a consumer rather than a commercial customer. Accordingly, the actions of Figure 6d correspond to the actions of Figure 6c, to great extent.

Action 1 :

The invoice issuer may register an invoice.

Action 2:

The invoice issuer may post and/or print the invoice. The business software may then print the invoice in a PDF format , whereupon the business software may use the electronic invoice adapting system to name the file, as discussed in conjunction with Figures 1-4.

Action 3:

Action 4:

The e-mail may then automatically be sent to either the customer's bank (5a-5c) or directly to the customer (5A-5C), depending on whether the customer has chosen to accept e-invoices or not.

If the consumer has accepted e-invoices from the invoice issuer, the flow continues with:

Action 5:

The invoice may be sent to the internet bank and the handling of the invoice may also be almost the same as today. The important simplification lies, as earlier mentioned, in the fact that the bank does not need to interpret the graphical part and that the layout is identical with the original, sent by the issuer. For example:

a) The file name is interpreted and checked, with the aid of the electronic invoice interpreting system as discussed in conjunction with Figures 1-4. If an error is found, the mail may be returned automatically. The system may also check, again with the aid of said electronic invoice interpreting system, if the end receiver has registered his vendor in his internet bank. If this has not been done, then the e-mail may be returned automatically.

b) The transaction may then be registered, with the aid of the electronic invoice interpreting system, in the bank's e-invoice system, basically in the same way as today, where e.g. the first six fields may make for the primary key in one transaction. If a transaction with the same primary key already exists, then the e-mail may be automatically returned.

The pdf-file may automatically be loaded into the customers table of "Invoices to be paid". The invoice may now be visible on the customer's Internet bank. c) After logging into his or her internet bank, the customer can choose to print the invoice and/or to download the invoice. Actions 6-8 of Figure 6c are not applicable for a consumer, and are accordingly ignored for the scenario illustrated in Figure 6d. Actions 9-15, on the other hand, are identical to Actions 9-15 of Figure 6c. If the consumer has not accepted e-invoices from the invoice issuer, the flow after Action 4 continues with:

Action 5:

If the customer has chosen not to accept e-invoices, then the invoice may have been sent directly from the issuer to the consumer, and the flow will be the same as today, the only difference being the name of the file. For example:

A. The pdf-file is received by the customer.

B. The customer may choose to store the file on his or her computer.

C. The customer may choose to print the invoice.

D. The customer may manually pay the invoice on the internet or via other means.

As indicated above, Actions 6-9 of Figure 6c are not applicable for a consumer, and are accordingly ignored for the scenario illustrated in Figure 6d. Action 10:

The consumer may manually register and pay the invoice.

Actions 11-15 are identical to Actions 9-15 of Figure 6c.

Consequently, regardless of whether it may be a B2B or a B2C scenario and regardless of the integration level above, the invoice issuer will be able to use the same business process, the only difference beeing where to send the invoice and whether it may be an e-invoice or a paper version - which for instance may be handled via two simple setup fields on the customer card in the business software.

Moreover, the file names in today's operating systems can be 260 characters long, including the file path. This allows for a solid amount of information comprised within the file name. The electronic file name according to embodiments of the inventive concept may need e.g. between 60 and 160 of these 260 characters. Thus, there may be at least 100 characters left to address the file path, which may be more than enough.

Furthermore, the proposed inventive concept is well prepared for the future - not the least when it comes to the file format, as only the file name is interpreted, not its content. Thus, a vendor may send the file in for instance XPS format, without any adaptation. The only thing that may be required is that the end receiver can read (not interpret) the graphical format. Therefore, it may be recommended that the issuer use a world standard, which currently is PDF.

Moreover, embodiments of the inventive concept may as previously indicated allow for e- mail - or an equivalent or successor thereof - to be used as information carrier. This gives the parties involved several benefits, in that e-mail is a carrier that almost all parties already have access to. E-mail is thus a world standard that is likely to not invoke an extra cost for the relevant parties. Moreover, e-mail has built-in functions to approve or dismiss a certain message, which enables for the mail being returned should an error occur. The dismiss function may additionally be used for other purposes; for instance, the invoice receiver may want the invoice returned at a later stage, with a message explaining why the invoice has not been approved. In the following, a scenario is described where this functionality may be of use:

a. The end receiver has a paper subscription.

b. The paper vendor sends e-invoices to the end receiver, via the bank, according to embodiments of this disclosure.

c. The end receiver has decided to terminate the subscription.

d. When the end receiver sees the next e-invoice at his or her internet bank, he or she can mark the transaction, and via a simple function provided by the bank, write a few sentences and then dismiss the invoice.

e. As a result, a return mail is sent from the bank to the invoice issuer, who in an efficient way gets information about why the invoice has not been approved.

This routine may save time for both the issuer and for the end receiver.

The person skilled in the art realizes that the present disclosure by no means is limited to the preferred embodiments described above. On the contrary, many modifications and variations are possible within the scope of the appended claims. It should furthermore be noted that the drawings not necessarily are to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein. Additionally, in the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or ' does not exclude a plurality.

Claims

1. A method performed by an electronic invoice adapting system (1 1) for facilitating exchange of invoice related information between an electronic invoice issuer (1) and an electronic invoice receiver (2), said method comprising:

deriving (1 101) from a non-human data source (4) comprising information related to an electronic invoice (5), at least a first piece of content (51) characterizing the electronic invoice (5);

generating (1 103) an electronic file name (6) comprising at least a first field (61), said at least first field (61 ) comprising said at least first content (51); and associating (1 104) said electronic invoice (5) with said electronic file name

(6)·

The method according to claim 1 , wherein said at least first piece of content (51 ) comprises one or more of:

an invoice receiver ID;

a payment method;

a payment receiver ID;

a BIC code;

a document type;

a payment ID;

a document date;

a due date;

a currency; and/or

an amount.

The method according to claim 1 or 2, further comprising:

deriving (1102) from said data source (4), at least a second piece of content (52) characterizing the electronic invoice (5);

wherein said generating (1 103) an electronic file name (6) comprises: generating (1 103) an electronic file name (6) comprising at least a first field

(61 ) and at least a second field (62) separated by one or more delimiters (63), said at least first field (61) comprising said at least first content (51 ) and said at least second field (62) comprising said at least second content (52).

4. The method according to any one of claims 1-3, wherein said associating (1 104) comprises naming, re-naming and/or saving said electronic invoice (5) using said electronic file name (6).

The method according to any one of claims 1-4, further comprising:

sending ( 105), directly or indirectly to said electronic invoice receiver (2) and/or an electronic invoice interpreting system (21 ) associated with said electronic invoice receiver (2), said electronic file name (6) and/or said electronic invoice (5) with said electronic file name (6).

A method performed by an electronic invoice interpreting system (21) for facilitating exchange of invoice related information between an electronic invoice issuer (1) and an electronic invoice receiver (2), said method comprising:

interpreting (2102) at least a first field (61) of an electronic file name (6) associated with an electronic invoice (5), wherein said at least first field (61 ) comprises at least a first piece of content (51) characterizing the electronic invoice (5).

The method according to claim 6, wherein said at least first piece of content (51 ) comprises one or more of:

an invoice receiver ID;

a payment method;

a payment receiver ID;

a BIC code;

a document type;

a payment ID;

a document date;

a due date;

a currency; and/or

an amount.

8. The method according to claim 6 or 7, further comprising:

interpreting (2103) at least a second field (62) of said electronic file name (6), wherein said at least second field (62) comprises at least a second piece of content (52) characterizing the electronic invoice (5), said at least first field (61) and said at least second field (62) being separated by one or more delimiters (63).

9. The method according to any one of claims 6-8, further comprising:

receiving (2101), directly or indirectly from said electronic invoice issuer (1) and/or an electronic invoice adapting system (11) associated with said electronic invoice issuer (1), said electronic file name (6) and/or said electronic invoice (5) with said electronic file name (6).

10. An electronic invoice adapting system (1 1) configured for facilitating exchange of invoice related information between an electronic invoice issuer (1 ) and an electronic invoice receiver (2), said electronic invoice adapting system (11) comprising:

a content deriving unit (11 1) adapted for deriving (1 101 ) from a non- human data source (4) comprising information related to an electronic invoice (5), at least a first piece of content (51) characterizing the electronic invoice (5);

a file name generating unit (112) adapted for generating (1103) an electronic file name (6) comprising at least a first field (61), said at least first field (61 ) comprising said at least first content (51); and

an associating unit (1 13) adapted for associating (1104) said electronic invoice (5) with said electronic file name (6).

1 1. The electronic invoice adapting system (1 1 ) according to claim 10, wherein said at least first piece of content (51) comprises one or more of.

an invoice receiver ID;

a payment method;

a payment receiver ID;

a BIC code;

a document type;

a payment ID;

a document date;

a due date;

a currency; and/or

an amount.

12. The electronic invoice adapting system (1 1) according to claim 10 or 11 , wherein said content deriving unit (11 1) further is adapted for:

deriving (1 102) from said data source (4), at least a second piece of content (52) characterizing the electronic invoice (5); and

wherein said file name generating unit (1 12) is adapted for:

generating ( 103) an electronic file name (6) comprising at least a first field (61 ) and at least a second field (62) separated by one or more delimiters (63), said at least first field (61 ) comprising said at least first content (51) and said at least second field (62) comprising said at least second content (52).

13. The electronic invoice adapting system (11) according to any one of claims 10-12, further comprising:

a sending unit (1 14) adapted for sending (1 105), directly or indirectly to said electronic invoice receiver (2) and/or an electronic invoice interpreting system (21 ) associated with said electronic invoice receiver (2), said electronic file name

(6) and/or said electronic invoice (5) with said electronic file name (6).

14. The electronic invoice adapting system (11) according to any one of claims 10-13, wherein said associating unit (113) is adapted for naming, re-naming and/or saving said electronic invoice (5) using said electronic file name (6).

15. An electronic invoice interpreting system (21 ) for facilitating exchange of invoice related information between an electronic invoice issuer (1 ) and an electronic invoice receiver (2), said electronic invoice interpreting system (21) comprising:

a file name interpreting unit (211) adapted for interpreting (2102) at least a first field (61 ) of an electronic file name (6) associated with an electronic invoice (5), wherein said at least first field (61) comprises at least a first piece of content (51 ) characterizing the electronic invoice (5).

16. The electronic invoice interpreting system (21) according to claim 15, wherein said at least first piece of content (51 ) comprises one or more of:

an invoice receiver ID;

a payment method;

a payment receiver ID; a BIC code;

a document type;

a payment ID;

a document date;

a due date;

a currency; and/or

an amount.

7. The electronic invoice interpreting system (21) according to claim 15 or 16, wherein said file name interpreting unit (211 ) further is adapted for:

8. The electronic invoice interpreting system (21 ) according to any one of claims 15- 17, further comprising:

a receiving unit (212) adapted for receiving (2101), directly or indirectly from said electronic invoice issuer (1 ) and/or an electronic invoice adapting system (1 1 ) associated with said electronic invoice issuer (1 ), said electronic file name (6) and/or said electronic invoice (5) with said electronic file name (6).

9. Computer program product comprising a computer program containing computer program code means arranged to cause a computer or a processor to execute the steps of a method according to any of claims 1-5, stored on a computer-readable medium or a carrier wave.

20. Computer program product comprising a computer program containing computer program code means arranged to cause a computer or a processor to execute the steps of a method according to any of claims 6-9, stored on a computer-readable medium or a carrier wave

21. A method performed by an electronic invoice enhancement system (12) for facilitating exchange of invoice related information between an electronic invoice issuer (1) and an electronic invoice receiver (2), said method comprising: deriving (1101), by means of an electronic invoice adapting system (11), from a non-human data source (4) comprising information related to an electronic invoice (5), at least a first piece of content (51) characterizing the electronic invoice (5);

generating (1103), by means of said electronic invoice adapting system (11), an electronic file name (6) comprising at least a first field (61), said at least first field (61) comprising said at least first content (51);

associating (1104), by means of said electronic invoice adapting system (11), said electronic invoice (5) with said electronic file name (6); and

interpreting (2102), by means of an electronic invoice interpreting system (21), said at least first field (61) of the electronic file name (6) associated with the electronic invoice (5).