Purchase management system and method

Abstract

To provide a purchase management system and method for allowing a different organization to easily add information on purchase.SOLUTION: In a purchase management system 100, a central database arrangement 110 has central processing means 115, adds a selected purchase group 300 as metadata associated with a first transaction ID, and forwards the metadata to a bank specific database module 130. The bank specific database module has bank processing means 135, judges a purchase approval request, responds to a transaction authentication module 520 by approval or rejection, adds transaction information as the metadata associated with the first transaction ID in the bank specific database module, and forwards it to the central database arrangement. The central processing means 115 also forwards the transaction information to a purchasing institution 200, and purchase information is entered into a management system of the purchasing institution 200.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure generally relates to a purchase management system and method.

Background Art

[0002] In the dynamic payment card management system described in U.S. Patent No. 7,319,986, card control settings can be dynamically modified, and approval parameters can be dynamically managed through the application of configurable corporate purchase policies and rules.

[0003] The system described in U.S. Patent No. 7,319,986 is based on the use of purchase requests. No purchase is made without a specific purchase request. However, the purchase request may also be synthesized in the system. By using the purchase request, the approval process within the enterprise is simplified.

[0004] In the system described in U.S. Patent No. 7,319,986, the client can be notified that a transaction has occurred, but since the system is based on the use of purchase requests, the details of the purchase cannot be transferred to the enterprise's accounting system at the time of purchase. Therefore, the enterprise does not receive the details of the purchase until it receives an invoice from the supplier.

[0005] Furthermore, the system described in U.S. Patent No. 7,319,986 is an integrated card processing system intended to replace the existing payment infrastructure. Therefore, an improved purchase management system is desired.

Summary of the Invention

[0006] A purchase management system based on the use of purchase requests simplifies the approval process within an enterprise. However, since purchase requests are internally managed within the enterprise, external parties cannot add information to them, such as details about completed purchases.

[0007] According to the present invention, instead, a database accessible to any organization for the system is used to store information regarding purchases. The database configuration preferably has a function of "migrating" the data formats used by different organizations for the system into a single data format. This makes it easier for different organizations to add information regarding purchases.

[0008] The present disclosure relates to a purchase management system and a purchase management method in which a purchasing organization can purchase goods and services from suppliers / franchise stores. Conventional systems do not enable automatic input of transaction information from such purchases into the accounting system and other management systems of the purchasing organization. The present invention achieves this by collecting information from various organizations for the system in a way that was not possible with conventional systems.

[0009] The claimed purchase management system may comprise a central database configuration, a client interface to the central database configuration, and a bank-specific database module configured to communicate with a transaction authentication module within the bank. The central database configuration may be configured to receive, through the client interface, purchase rules applied to a purchase group by a purchasing institution. The central database configuration may have central processing means, which adds a selected purchase group as metadata associated with a first transaction ID in the central database configuration, adds the purchase rules applied to the purchase group as metadata associated with the first transaction ID in the central database configuration, and is configured to transfer the metadata associated with the first transaction ID to the bank-specific database module. The bank-specific database module may be configured to receive a purchase approval request from the transaction authentication module, the purchase approval request including transaction information at least including a purchase amount associated with the first transaction ID. The bank-specific database module may have bank processing means, which determines the purchase approval request by approving or rejecting, based on whether the requested purchase meets, the purchase rules associated with the first transaction ID in the bank-specific database module, responds to the transaction authentication module by approving or rejecting the purchase approval request, adds the transaction information received from the transaction authentication module as metadata associated with the first transaction ID in the bank-specific database module, and is configured to transfer the transaction information associated with the first transaction ID to the central database configuration. The central processing means of the central database configuration may further be configured to transfer the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase may be automatically entered into at least one management system of the purchasing institution.This enables easy collection of transaction information from the purchase and conversion of this transaction information into a data format used by the purchasing institution, whereby the transaction information can be automatically input into the accounting system and other management systems of the purchasing institution.

[0010] The claimed purchase management method may include: entering, through a client interface, purchase rules applicable to a purchase group into a central database configuration; adding, as metadata associated with a first transaction ID in the central database configuration, a selected purchase group; adding, as metadata associated with the first transaction ID in the central database configuration, the purchase rules applicable to the purchase group; transferring the metadata associated with the first transaction ID from the central database configuration to a bank-specific database module; receiving, in a transaction authentication module disposed within the bank, a first transaction authentication request associated with the first transaction ID and including transaction authentication information; communicating, from the transaction authentication module to the bank-specific database module, a purchase approval request including transaction information including at least a purchase amount; determining the purchase approval request by approving or rejecting based on whether the requested purchase satisfies the purchase rules associated with the first transaction ID in the bank-specific database module; responding to the approval or rejection of the purchase approval request to the transaction authentication module; responding to the first transaction authentication request associated with the first transaction ID from the transaction authentication module; adding the transaction information received from the transaction authentication module as metadata associated with the first transaction ID in the bank-specific database module; transferring the transaction information associated with the first transaction ID to the central database configuration; and transferring the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase can be automatically entered into at least one management system of the purchasing institution.This enables the easy collection of transaction information from the purchase and the conversion of this transaction information into a data format used by the purchasing institution, whereby the transaction information can be automatically input into the accounting system and other management systems of the purchasing institution.

[0011] In an embodiment, the bank-specific database module is disposed within the bank. The definition of "within the bank" means that the module within the bank exists behind the bank's firewall within the bank's system. Thereby, the information transferred between modules is never transmitted outside the bank's firewall. This enables a short response time to purchase approval requests. Further, it is possible to add transaction information of a type that is not permitted to be transmitted outside the bank's firewall for regulatory reasons as metadata associated with the first transaction ID in the bank-specific database module. There are strict regulatory requirements regarding transaction information that can be received from outside the bank and / or transmitted to the outside. However, by disposing the bank-specific database module within the bank, transaction information that is not permitted to be received from outside the bank and / or transmitted to the outside can also be input into the bank-specific database module.

[0012] In an embodiment, the above purchase group includes at least one purchasing individual. Thereby, purchase rules can be defined and applied to one or more specific purchasing individuals, or a subsection of a purchasing institution that includes one or more purchasing individuals.

[0013] In an embodiment, the purchase group includes the entire above purchasing institution. Thereby, the purchasing institution can define general purchase rules for the entire institution.

[0014] In an embodiment, the above purchase rule is a general purchase rule for a subsection of the above purchasing institution, and the step of adding the purchase rule applied to the above purchase group as metadata associated with the above first transaction ID in the above central database configuration includes the step of determining to which subsection the above purchase group belongs.

[0015] In an embodiment, the above transaction information includes, for example, the name of the franchise store or franchise store information in the form of a code for identifying the franchise store. The step of determining the above purchase approval request by approval or rejection is further based on the above franchise store information. Thereby, the purchasing institution can block purchases from the selected supplier / franchise store and / or enable only purchases from the selected supplier / franchise store.

[0016] In an embodiment, the above purchase rule specifies that before the purchase is executed, predetermined metadata needs to be added to and associated with the above transaction ID in the above central database configuration. The step of determining the above purchase approval request includes the step of rejecting the above purchase approval request if the metadata does not exist and is not associated with the above transaction ID in the above bank-specific database module.

[0017] In an embodiment, information is transferred from the above central database configuration to the payment card issuing institution directly or via the payment card management module within the above bank, whereby the above payment card issuing institution can issue a payment card to the above purchasing institution.

[0018] In an embodiment, the above central database configuration and the above bank-specific database module are synchronized so as to be in a form reflecting each other. However, the reflection does not necessarily include all the information in the database, and some metadata fields can be excluded from the reflection.

[0019] In an embodiment, the central database configuration is configured to communicate with a number of different organizations and includes an adapter that converts the data formats used by each of these different organizations into a single data format, preferably the data format defined by the purchasing institution.

[0020] The present invention is not limited to the use of payment cards and encompasses transactions using other means. Such means are smartphones or other devices such as QR, EAN, or PIN codes.

[0021] The term "bank" in this application refers to any payment service or financial institution that has the authority to approve and execute payment card payments or similar types of transactions. Therefore, it is not limited to officially defined and certified payment services or financial institutions. In some regions, payment services or financial institutions may need to meet certain regulatory requirements in order to be covered by, for example, a deposit insurance system. In such regions, the term "bank" may be used for payment services or financial institutions that meet such regulatory requirements. The term "bank" in this application is not limited to this and encompasses any payment service or financial institution that has the authority to approve and execute payment card payments or similar types of transactions. Therefore, the term "bank" in this application may also encompass credit card networks such as MasterCard or Visa that approve and execute transactions. The term "bank" in this application also encompasses the cooperation between credit card networks such as MasterCard or Visa and payment services or financial institutions that have the authority to approve and execute payment card payments or similar types of transactions.

[0022] The central processing means of the central database configuration can be a single central processing configuration or a plurality of central processing configurations that transmit signals to each other. Some processes can be implemented, for example, in one central processing configuration, and then the signal can be transmitted to one or more other central processing configurations for further processing.

[0023] The bank processing means of the bank-specific database module can be any one or more processing configurations within the bank system. Therefore, it is not necessarily the processing means dedicated to the bank-specific database module.

[0024] The modules within the bank can be physically separate modules that transmit information to each other, but can also be virtual modules implemented on the same server, or simply software modules.

[0025] The scope of the present invention is defined by the claims incorporated herein by reference. Those skilled in the art will, by considering the following detailed description of one or more embodiments, understand the present invention more fully and recognize its additional advantages. Please refer to the pages of the accompanying drawings briefly described first.

Brief Description of the Drawings

[0026]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

[0027] The embodiments of the present disclosure and their advantages are best understood by referring to the following detailed description. It should be understood that reference numbers are used to identify similar elements shown in one or more figures.

Mode for Carrying Out the Invention

[0028] There are a number of different types of payment card processing models. The simplest model in which the franchise issues the payment card and is directly related to the cardholder can be defined as a two-corner model. In the two-corner model, the cardholder can use the payment card only at the franchise that issued it.

[0029] If the franchise does not want to issue and process the payment card, a three-corner model can be used. This is a model in which a third party functions as an intermediary between the cardholder and the franchise. Also in the three-corner model, the cardholder can use the payment card only at a specified franchise.

[0030] To provide flexibility to the cardholder, a four-corner model is usually used for payment cards. In such a model, the cardholder can use the payment card for payments at any franchise that accepts the card. The transaction is processed between the franchise bank and the cardholder bank via a payment card network such as MasterCard or Visa, for example.

[0031] When a payment card is used for payment, the merchant bank sends a transaction authentication request to the cardholder's bank via the payment card network, thereby realizing transaction authentication. Such a transaction authentication request may include transaction authentication information, for example, as shown in FIG. 6. Next, the cardholder's bank performs a plurality of checks on, for example, card data, account balance, limits, and behavior, and approves or rejects the transaction.

[0032] According to the present invention, in addition to general transaction authentication, a purchase approval request is further added to the transaction authentication process. The purchase approval is carried out at the cardholder's bank simultaneously with the execution of general transaction authentication. The merchant bank does not need to be involved in, nor be informed of, the fact that a purchase approval is carried out in addition to general transaction authentication. If the purchase is not approved, the merchant bank receives information that the transaction has not been authenticated. However, it is not necessarily known whether this is due to, for example, checks on card data, account balance, limits, and behavior, or because the requested purchase does not meet the purchase rules.

[0033] Therefore, according to the present invention, it is not necessary to set the supplier / merchant in the purchase management system before a purchase is made, and furthermore, the supplier / merchant does not need to be associated with any purchase management system at all. The present invention enables the transfer of information about a purchase to the purchasing institution even if the supplier / merchant is not associated with any purchase management system at all. This cannot be achieved by any prior art system.

[0034] The present disclosure relates to a purchase management system and a purchase management method. A plurality of embodiments of the disclosed solution are presented in more detail in relation to the figures.

[0035] FIG. 1 schematically shows a purchase management system 100 according to one or more embodiments described herein. The purchase management system 100 may include a central database configuration 110, a client interface 120 to the central database configuration 110, and a bank-specific database module 130 configured to communicate with a transaction authentication module 520 within a cardholder bank 500. The central database configuration 110 may be, for example, a cloud service. The bank-specific database module 130 is disposed within the cardholder bank 500 and may enable a short-time response to a purchase approval request. Further, it is possible to add, as metadata associated with a first transaction ID in the bank-specific database module 130, transaction information of a type that is not permitted to be transmitted outside the bank's firewall for regulatory reasons. There are strict regulatory requirements regarding transaction information that can be received from outside the bank and / or transmitted to the outside. However, by disposing the bank-specific database 130 module within the bank, transaction information that is not permitted to be received from outside the bank and / or transmitted to the outside can also be input into the bank-specific database module 130.

[0036] The central database configuration 110 may be configured to receive purchase rules from a purchasing institution 200 through the client interface 120. The purchase rules may be general purchase rules for the entire purchasing institution 200, but may also be purchase rules specific to a given subsection of the purchasing institution 200 or even specific to an individual purchaser. The client interface 120 may be, for example, a web interface or a mobile application.

[0037] The central processing means 115 of the central database configuration 110 can generate transaction IDs used for transactions. These transaction IDs may be generated one by one, or may be generated collectively, and further may be generated based on predefined rules or in response to a request from the purchasing institution 200. The transaction IDs may be generated even before any purchase rules are defined. The transaction IDs may require activation before use.

[0038] For each transaction ID, information regarding the corresponding purchasing institution may be added as metadata. The corresponding purchasing institution may be defined, for example, as any individual purchaser within the purchasing group 300. The defined purchasing group 300 may include one or more specific individual purchasers, but may also be defined, for example, as a subsection of the purchasing institution 200, or as the entire purchasing institution 200. It is not necessary for all individual purchasers within the purchasing group 300 to be employees of the purchasing institution 200. That is, the purchasing group 300 may include, for example, consultants or subcontractors for the purchasing institution 200.

[0039] Based on the metadata regarding the purchasing group 300, the central processing means 115 of the central database configuration 110 can identify which purchase rules apply to this specific transaction ID and can add these purchase rules as metadata associated with the transaction ID. The purchase rules are always the same for all individual purchasers within the purchasing group 300. However, the purchasing group 300 can be dynamically modified if the need arises for different purchase rules for different individual purchasers within the purchasing group. In such a case, a new purchasing group 300 is simply formed for the individual purchasers who require different purchase rules.

[0040] Other types of information related to the transaction can also be added as metadata associated with the transaction ID in the central database configuration 110. An institution different from the purchasing institution 200 may also be able to access the central database configuration 110 and may be able to add metadata associated with the transaction ID. Preferably, adding metadata to the central database configuration 110 is shown in FIG. 2 by a third-party institution 150 using a specific third-party interface 160. The third-party interface 160 can be, for example, a web interface or a mobile application.

[0041] Such a third-party institution 150 can be, for example, a client of the purchasing institution 200. The purchasing institution 200 makes a purchase and issues a further invoice on behalf of its client. In such a case, the metadata can be, for example, an approval for paying the purchase cost. Then, it is advantageous to add all the information necessary to invoice the client as metadata associated with the transaction ID. This can simplify or even automate the invoicing to the client.

[0042] Another example of such a third-party institution 150 can be an organization that provides information about suppliers registered on a blacklist or suppliers that do not meet certain regulatory requirements. When such an organization adds this information as metadata to all transaction IDs, the purchase rules can be defined such that purchases from the suppliers / dealers defined by this metadata are not possible.

[0043] A further example of such a third - party institution 150 is the franchisee / supplier 400. If the franchisee / supplier 400 is able to access the central database configuration 110 and add metadata associated with the transaction ID, the franchisee / supplier 400 can add, for example, an electronic receipt as metadata associated with the transaction ID. The franchisee / supplier 400 can use the third - party interface 160 or a specific interface for the franchisee / supplier 400. Such an interface can be, for example, a web interface or a mobile application. However, if the franchisee / supplier 400 is unable to access the central database configuration 110, the electronic receipt may be added by another entity, such as a purchasing individual within the purchasing group 300.

[0044] Purchasing individuals within the purchasing group 300 may be communicable with the central database configuration 110 to obtain information and / or add metadata. For example, if the purchasing institution 200 wishes to make a corporate payment card available for personal purchases, the purchasing individual may tag the purchase as personal and may have the option, for example, to have the cost automatically deducted from the next salary. Purchasing individuals within the purchasing group 300 can use the third - party interface 160 or a specific interface for the purchasing group 300. Such an interface can be, for example, a web interface or a mobile application.

[0045] For example, to simplify the management within the purchasing institution 200, the purchase rules may require the purchasing individual to add predetermined metadata to the transaction ID before or after the purchase. The purchasing individual may be required to add, for example, an account, a cost center, a project, or a purpose as metadata associated with the transaction ID. Subsequently, based on the metadata added by the purchasing individual, additional requirements may be added to specific types of purchases. For example, if the purchase is related to an explanation such as a dinner with a client, the purchasing individual may be required to add the names of the participants as metadata associated with the transaction ID. If the purchase is related to a business trip, the purchasing individual may be required to specify the destination and / or its purpose. This enables automatic accounting processing of invoices within the purchasing institution 200. The purchase rules may require that this metadata be added to the approved purchase. If the purchase rules require that this metadata be added, even before the purchasing individual attempts to make a purchase, the purchasing individual may be warned that the purchase will be rejected if this metadata is not added. In such a case, such a warning is preferably communicated to the purchasing individual via, for example, SMS, email, or a mobile application.

[0046] However, certain predetermined items of information cannot be added before purchase approval. For example, the purchasing individual may be required to add a receipt as metadata associated with the transaction ID. This may be done, for example, by taking a photo of the receipt using a mobile application. In such a situation, the purchase has already been made and cannot be rejected. However, future purchases by this purchasing individual may be blocked until the required metadata has been added to all previous transactions. This block may be performed manually by the purchasing institution 200. Alternatively, the purchase rules may specify that, for example, after a predetermined time, or after a predetermined number of purchases where this has not been done, all further purchases are automatically blocked.

[0047] Purchase rules can also specify how purchases can be made for a given supplier / franchisee. For example, for cost reasons, they can specify that only web purchases are possible from a given supplier. In this case, an attempt to purchase in a physical store will be rejected. In this case, information about the reason for the rejection is preferably communicated to the individual purchaser via, for example, SMS, e-mail, or a mobile application.

[0048] The metadata associated with the transaction ID can be transferred to the bank-specific database module 130. If the purchase rules and all the metadata applied to them are transferred, it is not necessarily required to transfer all the metadata to the bank-specific database module 130. However, in one embodiment, all the information within the central database configuration 110 is reflected in the bank-specific database module 130.

[0049] When the bank proprietary database module 130 receives metadata associated with a transaction ID, a purchase approval request can be sent from the transaction authentication module 520 within the cardholder bank 500. The purchase approval request includes transaction information. This can be the same as the transaction authentication information that is sent from the merchant bank to the cardholder bank 500 via the payment card network and received by the transaction authentication module 520 when the payment card is used for payment. An example of such transaction authentication information is shown in FIG. 6. The transaction information within the purchase approval request need not necessarily have all of the transaction authentication information, as long as it includes the amount and sufficient information to associate it with the desired transaction ID. If the purchase approval request does not include a transaction ID, it is necessary to include some other item of transaction information that enables the bank proprietary database module 130 to associate the purchase with a transaction ID. Such an item can be, for example, transaction information that identifies the purchase group 300. If the purchase group 300 is assigned to one or more specific payment cards, this transaction information can be, for example, the payment card number or a token of the payment card number. Thereafter, the bank processing means 135 of the bank proprietary database module 130 can simply assign the purchase to the next available transaction ID for this purchase group 300.

[0050] After that, the bank processing means 135 of the bank-specific database module 130 checks whether the requested purchase meets the purchase rules associated with the transaction ID, i.e., the purchase rules applicable to the purchase group 300. In addition to the above example, the purchase rules can relate, for example, to the maximum amount per purchase, the maximum total amount, whether it is within the budget, or restrictions on where and when a purchase can be made (e.g., purchases from overseas or on weekends can be blocked). If the purchase approval request includes merchant information such as the name of the merchant or a code identifying the merchant, the purchase rules can also relate to specific merchants that are permitted or blocked for the purchase group 300. This enables the purchasing institution 200 to block purchases from selected suppliers / merchants and / or to allow only purchases from selected suppliers / merchants. For example, the purchasing institution 200 can use this function to block purchases from liquor stores such as Systembolaget or to allow purchases only from specific food chains such as ICA and / or Coop or specific types of merchants such as grocery stores.

[0051] Accordingly, the bank processing means 135 of the bank-specific database module 130 approves or rejects the purchase approval request based on whether the requested purchase meets the purchase rules associated with the transaction ID in the bank-specific database module 130. The bank processing means 135 of the bank-specific database module 130 also adds the transaction information received from the transaction authentication module 520 as metadata associated with the transaction ID in the bank-specific database module 130 and transfers this transaction information to the central database configuration 110 so that it is further added as metadata associated with the transaction ID. This can be done either before or after the approval / rejection is sent to the transaction authentication module 520.

[0052] Transaction information is preferably "migrated" or converted into another data format, preferably a data format defined by the purchasing institution 200, by a function in the central database configuration 110. This is further described with reference to FIG. 5.

[0053] Based on the approval / rejection received along with the general transaction authentication performed by checking, for example, card data, account balance, limits, and behavior, from the bank processing means 135 of the bank-specific database module 130, the transaction authentication module 520 approves or rejects the transaction. When the bank processing means 135 of the bank-specific database module 130 rejects the transaction, the transaction authentication module 520 rejects the transaction even if it is shown to be acceptable by the general transaction authentication check. Similarly, if the general transaction authentication check shows that the transaction is not acceptable, the transaction authentication module 520 rejects the transaction even if the bank processing means 135 of the bank-specific database module 130 has approved the purchase. In such a situation, since the transaction is rejected anyway, the transaction authentication module 520 may not need to send a purchase approval request to the bank-specific database module 130.

[0054] Before the purchase approval request is sent to the bank-specific database module 130, when general transaction authentication is performed in the transaction authentication module 520, if the bank processing means 135 of the bank-specific database module 130 determines whether to approve or reject the purchase approval request, the bank processing means 135 of the bank-specific database module 130 can determine whether the transaction authentication module 520 approves or rejects the transaction. Alternatively, the transaction authentication module 520 can transfer this information to the bank-specific database module 130. Information regarding whether the transaction has been approved or rejected by the transaction authentication module 520 can be added as metadata associated with the transaction ID in the bank-specific database module 130.

[0055] Other types of information can also be added as metadata associated with the transaction ID in the bank-specific database module 130. The bank 500 can provide, for example, information regarding suspicion of fraud, transaction status, or other similar types of information to the bank-specific database module 130. Thereby, this information can be transferred to the central database configuration 110.

[0056] When the central database configuration 110 receives the transaction information as metadata associated with the transaction ID, the central processing means 115 of the central database configuration 110 can transfer the transaction information to the purchasing institution 200, preferably in the data format defined by the purchasing institution 200. Thereby, the transaction information can be automatically inputtable into the accounting system and / or other management systems of the purchasing institution 200. In this way, the purchasing institution can grasp all transactions well before receiving any invoices from the supplier / franchise. Thereby, the purchasing institution 200 can always check its budget and adapt the purchase rules accordingly.

[0057] Purchase rules can be applied for various reasons. While a given subsection of the purchasing institution 200 is considered as one purchasing group 300, for example, in order to impose additional restrictions (or block all purchases) on a given individual purchaser, it may be desirable to apply the purchase rules to a given individual purchaser within this subsection. For this individual purchaser, a new purchasing group 300 can be generated with more restricted purchase rules than the others in the subsection. Thus, both the purchasing group 300 and the purchase rules can be dynamically updated by the purchasing institution 200.

[0058] The purchasing institution 200 does not necessarily define the actual purchasing groups within the system. Rather, the purchasing institution 200 can define purchase rules, for example, for multiple hierarchies. Some of the rules can be general for the entire organization, and other rules can be specific to some individuals or groups of individuals. In the context of this application, the purchasing group 300 is one or more groups of individual purchasers to which the same purchase rules apply.

[0059] In the central database configuration 110, a field that enables metadata to be associated with a transaction ID can also be dynamically set by the purchasing institution 200. Thereby, the purchasing institution 200 can define the desired metadata and the data format for this metadata. Thereby, for example, it becomes possible to associate metadata regarding a cost center, an account, and other billing information with the transaction ID in the central database configuration 110. Thereby, the purchasing institution 200 can define the metadata it wishes to receive and the format desirable for its reception within the electronic invoice. Therefore, this metadata can be obtained from the central database configuration 110 and added to the electronic invoice. Such an electronic invoice can be sent from the bank 500, from the central database configuration 110, or from a third party. If the invoice for the transaction conducted using the system 100 is an electronic invoice containing the metadata specified by the purchasing institution 200, it becomes possible to automate the processing of the invoice by the purchasing institution 200, and the workload associated with management can be significantly reduced.

[0060] The present invention can use a payment card for executing a payment, for example. In this case, information about the purchasing individual can be transferred from the central database configuration 110 to the payment card issuing institution 600 as shown in FIG. 3. This transfer can be carried out directly between the central database configuration 110 and the payment card issuing institution 600, or can be executed via the payment card management module 510 within the bank 500. The payment card issuing institution 600 can be associated with the bank 500, but can also be a separate payment card issuing institution 600.

[0061] To associate payments made with a payment card with the individual purchaser making the purchase, information about the payment card is preferably transferred from the payment card issuer 600 directly or via the payment card management module 510 within the bank 500 to the central database configuration 110. Preferably, this information is not the actual credit card number. This is because there may be restrictions on whether it is permitted to store this as metadata associated with a transaction ID in the central database configuration 110. Instead, the information can be, for example, a token of the credit card number.

[0062] Figure 4 is an exemplary flowchart of a purchase management method according to one or more embodiments described herein. The flow is as follows.

[0063] Step 410: The purchasing institution 200 sets its purchase rules in the central database configuration 110 (this can be performed at any point before step 460, and metadata can be added by the purchasing institution 200 at any point in the flow).

[0064] Step 415: The central database configuration 110 orders a card account for the purchasing institution 200 from the cardholder bank 500. Step 420: The cardholder bank 500 orders a payment card from the payment card issuer 600.

[0065] Step 425: Additional information such as card customization or a logo can be provided from the central database configuration 110 to the payment card issuer 600. The payment card may be ordered directly from the central database configuration 110 by the payment card issuer 600.

[0066] Step 430: The payment card is sent from the payment card issuer 600 to the individual purchaser 300 (the purchasing institution 200 may be involved in the distribution).

[0067] Step 435 (optional): The purchasing individual 300 adds metadata related to the purchase to the central database configuration 110 via the user interface (this can be done at any point in the flow).

[0068] Step 440: The transaction ID and the metadata associated with them, such as purchase rules, are transferred from the central database configuration 110 to the bank-specific database module 130. Step 445: The purchasing individual makes a purchase from the franchisee / supplier 400.

[0069] Step 450: The franchisee bank 550 receives information about the purchase from the franchisee / supplier 400.

[0070] Step 455: The franchisee bank 550 requests the cardholder bank 500 to authenticate the transaction via a payment card network such as Visa or MasterCard.

[0071] Step 460: The cardholder bank 500 requests a purchase approval from the bank-specific database module 130.

[0072] Step 465: The bank-specific database module 130 sends a purchase approval to the cardholder bank 500. Step 470: The cardholder bank 500 sends the transaction authentication to the franchisee bank 550. Step 475: The franchisee bank 550 sends the transaction permission to the franchisee / supplier 400.

[0073] Step 480: The bank-specific database module 130 transfers the transaction information related to the approved purchase to the central database configuration 110 (this can be done at any point after step 460).

[0074] Step 485: The central database configuration 110 transfers the transaction information to the purchasing institution 200.

[0075] Step 490 (optional): A third party adds metadata to the transaction (this can be done at any point in the flow).

[0076] FIG. 5 schematically shows a part of the purchase management system 100 according to one or more embodiments described herein. The central database configuration 110 preferably uses a dynamic setting of a “metadata carrier” that enables the association of metadata with a transaction ID. Thereby, the purchasing institution 200 can define the desired metadata and the format for this metadata. As described above with respect to FIGS. 1 to 3, the central database configuration 110 can interact and communicate with a number of different parties such as, for example, the purchasing institution 200, the purchasing individual, or the purchasing group 300, the franchisee / supplier 400, the cardholder bank 500, the payment card issuer 600, and other various third-party institutions 150. The central database configuration 110 needs to have a function, for example in the form of an “adapter”, that “transfers” or converts the data formats used by each of these different parties into a single data format, preferably the data format defined by the purchasing institution 200. The central database configuration 110 needs to have specific adapters 205, 305, 405, 505, 605, 155 for each of the parties 200, 300, 400, 500, 600, 150 respectively. This is because different parties generally use different data formats (if there are several different third parties 150, generally several different adapters 155 are required). Thereby, the purchasing institution 200 can define the metadata it wishes to receive from different parties and the data format of this metadata. Use case

[0077] To further illustrate the present invention, the following use cases are provided. Company A, which is a purchasing organization, has sub - sections such as a service department, a development department, a sales department, and a management department. Company A defines its purchasing policies and rules in the central database configuration 110 through the client interface 120 and orders payment cards from its bank, Cardbank, for all its individual purchasers. Some individual purchasers have personal payment cards, while others have shared payment cards.

[0078] Company A defines its service department, which is one of its sub - sections, as a purchasing group called "service", and the same purchasing rules apply to all staff in this group. The staff in the service department must be able to travel long distances and suddenly for business trips in order to provide prompt service for the malfunctioning equipment. Therefore, all individual purchasers within the purchasing group called "service" have personal payment cards, and there are very few restrictions on the purchasing rules for the purchasing group called "service". On the other hand, Company A always needs to check all purchases against the budget of the service department and can adapt the purchasing rules over time due to budgetary restrictions.

[0079] Company A defines its development department, which is one of its sub - sections, as a purchasing group called "development" with considerably more additional restrictions. The staff in the development department includes both Company A's employees and consultants. The staff in the development department is not allowed to make any purchases without prior approval by the person in charge of the development department. Some of the staff in the development department have personal payment cards, but a large number of shared payment cards are also used within the purchasing group called "development".

[0080] Company A defines its sales department, a sub-section thereof, as two purchasing groups: domestic sales and overseas sales. Since the domestic sales purchasing group usually does not travel overseas for business trips, the purchasing rules can be limited to domestic purchases. On the other hand, since the overseas sales purchasing group travels long distances for business trips, the restrictions in the purchasing rules can be considerably reduced. However, the purchasing rules can be defined such that prior approval is required, for example, when a hotel not on the list of hotels and hotel chains where Company A can receive discounts is selected. All staff in the sales department have personal payment cards.

[0081] Company A defines its management department, a sub-section thereof, as a purchasing group called management. The staff in the management department need to be able to make small purchases such as office supplies and lunches. Therefore, the purchasing rules can be limited, for example, by amount and supplier. The management purchasing group has a shared payment card.

[0082] When an employee in the service department attempts to make a purchase using a payment card, the affiliated bank sends a transaction authentication request to Cardbank via the payment card network, including, for example, the transaction authentication information shown in Figure 6. The transaction authentication module 520 of Cardbank receives the transaction authentication request and performs multiple checks, for example, regarding card data, account balance, limits, and behavior. If the transaction authentication module 520 of Cardbank determines to approve the transaction based on these checks, it sends a purchase approval request to the bank-specific database 130 within Cardbank. There, the transaction ID is stored together with the metadata associated with it.

[0083] Since the same purchase rules apply to all employees in the service department, the bank's proprietary database 130 can assign the purchase to the next available transaction ID in the database tagged with the purchase group of "service". In this case, whether the purchase relates to the purchase group of "service" can be determined, for example, by using the payment card number. However, on the one hand, there is a possibility that a specific transaction ID has already been selected by an employee in the service department who has been able to add the metadata associated with this transaction ID. Since the purchase rules for the service department staff are stored as metadata associated with the transaction ID, the bank's proprietary database 130 determines the purchase approval request by approving or rejecting it based on whether the requested purchase meets the purchase rules of the service department.

[0084] For the purchase rules of the service department, there are very few restrictions, so in many cases, the purchase is permitted. The bank's proprietary database 130 stores the transaction information as metadata associated with the transaction ID and transfers this metadata to the central database configuration 110. Next, the central database configuration 110 transfers the transaction information to Company A. As a result, the information about the purchase can be automatically input into the accounting and other management systems at Company A.

[0085] When the staff in the development department makes a purchase, a similar process is followed. However, since the staff in the development department is not allowed to make any purchases that have not been pre-approved by the person in charge of the development department, prior approval is required for purchases. The staff in the development department who wishes to make a purchase uses the interface (e.g., a web interface or a mobile application) designated for the purchasing group 300 to obtain a transaction ID and enters the necessary metadata related to this purchase into the central database configuration 110 through the interface. Next, an operation for the person in charge of the development department to pre-approve this purchase is set up. This could simply be an operation defined in the system, but a reminder could also be automatically sent to the person in charge via, for example, SMS or email. When the person in charge of the development department approves the purchase, it becomes possible according to the purchase rules.

[0086] When the staff in the sales department makes a purchase, a similar process is followed. Regarding the staff in the service department, there are very few restrictions imposed on the purchasing group of overseas sales. However, if it is found, for example, that the expenses are slightly overspent, it may be desirable to change the purchase rules for an individual or a group of individuals within overseas sales. Next, for example, a new purchasing group with additional restrictions on expenses can be defined. As a result, what was originally the purchasing group of overseas sales becomes, for example, two groups: overseas sales standard and overseas sales restricted.

[0087] When staff in the management department make a purchase, a similar process is followed. However, stricter purchase rules are imposed on the staff in the management department. For example, restrictions regarding approved suppliers / franchisees are imposed. The transaction information sent from the Cardbank's transaction authentication module 520 also includes franchisee information such as, for example, the name of the franchisee or a code for identifying the franchisee. Therefore, the bank-specific database 130 can compare the franchisee information with the approved franchisees according to the purchase rules. The staff in the management department can be restricted to certain suppliers / franchisees such as, for example, ICA and / or Coop, or certain types of franchisees such as, for example, grocery stores. The VISA franchisee category classification uses, for example, the MCC code 5499 for "Food and Groceries, Convenience Stores, Specialty Stores". This code is included in the franchisee identification code in the transaction authentication information. When staff in the management department purchase food at a grocery store, different VAT levels can be applied to different types of items. The different VAT levels for different items in the purchase can then be automatically stored as metadata associated with the transaction ID. This simplifies the management within the purchasing institution 200. Method embodiments

[0088] Figure 7 schematically shows a purchase management method 700 according to one or more embodiments described herein. The method 700 can comprise the following.

[0089] Step 710: Enter the purchase rules applicable to the purchase group 300 into the central database configuration 110 through the client interface 120.

[0090] Step 720: Add the selected purchase group 300 as metadata associated with the first transaction ID in the central database configuration 110.

[0091] Step 725: Add the purchase rules applicable to the purchase group 300 as metadata associated with the first transaction ID in the central database configuration 110.

[0092] Step 730: Transfer the metadata associated with the first transaction ID from the central database configuration 110 to the bank-specific database module 130.

[0093] Step 740: In the transaction authentication module 520 located within the bank 500, receive a first transaction authentication request associated with the first transaction ID and including transaction authentication information.

[0094] Step 750: Communicate a purchase approval request including transaction information including at least the purchase amount from the transaction authentication module 520 to the bank-specific database module 130.

[0095] Step 760: Determine the purchase approval request by approving or rejecting it based on whether the requested purchase meets the purchase rules associated with the first transaction ID in the bank-specific database module 130.

[0096] Step 765: Respond to the transaction authentication module 520 with the approval or rejection of the purchase approval request.

[0097] Step 770: Respond to the first transaction authentication request associated with the first transaction ID from the transaction authentication module 520.

[0098] Step 780: Add the transaction information received from the transaction authentication module 520 as metadata associated with the first transaction ID in the bank-specific database module 130.

[0099] Step 785: Transfer the transaction information associated with the first transaction ID to the central database configuration 110.

[0100] Step 790: Transfer the transaction information associated with the first transaction ID to the purchasing institution 200. Thereby, information about the purchase can be automatically entered into at least one of the management systems of the purchasing institution 200.

[0101] In an embodiment, the bank-specific database module 130 is arranged within the bank 500. Thereby, it becomes possible to respond to a purchase approval request in a short time. Furthermore, it is possible to add, as metadata associated with the first transaction ID in the bank-specific database module 130, transaction information of a type that is not permitted to be transmitted outside the bank's firewall for regulatory reasons. There are strict regulatory requirements regarding transaction information that can be received from outside the bank and / or transmitted to the outside. However, by arranging the bank-specific database 130 module within the bank, transaction information that is not permitted to be received from outside the bank and / or transmitted to the outside can also be input into the bank-specific database module 130.

[0102] In an embodiment, the purchasing group 300 includes at least one purchasing individual. Thereby, purchase rules can be defined and applied to one or more specific purchasing individuals, or a subsection of a purchasing institution that includes one or more purchasing individuals.

[0103] In an embodiment, the purchasing group 300 includes the entire purchasing institution 200. Thereby, the purchasing institution can define general purchase rules for the entire institution.

[0104] In an embodiment, the purchase rule is a general purchase rule for a subsection of the purchasing institution 200, and step 725 of adding the purchase rule applied to the purchasing group 300 as metadata associated with the first transaction ID in the central database configuration 110 includes a step of determining to which subsection the purchasing group 300 belongs.

[0105] In an embodiment, the transaction information includes store information such as, for example, the name of the store or a code for identifying the store. The step 760 of determining the purchase approval request by approval or rejection is further based on the store information.

[0106] In an embodiment, the purchase rule specifies that, before the purchase is executed, predetermined metadata needs to be added to and associated with the transaction ID in the central database configuration 110. The step 760 of determining the purchase approval request includes the step of rejecting the purchase approval request if the metadata does not exist and is not associated with the transaction ID in the bank-specific database module 130.

[0107] In an embodiment, the step 730 of transferring the metadata associated with the first transaction ID from the central database configuration 110 to the bank-specific database module 130 and the step 785 of transferring the transaction information associated with the first transaction ID to the central database configuration 110 include the step of synchronizing the central database configuration 110 and the bank-specific database module 130 so as to be in a mutually reflected form.

[0108] In an embodiment, the central database configuration 110 is configured to communicate with a number of different organizations 200, 300, 400, 500, 600, 150, and includes adapters 205, 305, 405, 505, 605, 155 that convert the data formats used by each of these different organizations into a single data format, which is preferably the data format defined by the purchasing institution 200. The method 700 may further include the following.

[0109] Step 705: Transfer information from the central database configuration 110 to the payment card issuing institution 600 directly or via the payment card management module 510 within the bank 500. Thereby, the payment card issuing institution 600 may issue a payment card to the purchasing institution 200.

[0110] The above disclosure is not intended to limit the invention to the precise forms disclosed or to a particular field of use.

[0111] It is contemplated that various alternative embodiments and / or modifications to the invention are possible in light of the present disclosure, whether explicitly described or suggested herein.

[0112] In this disclosure, embodiments of the invention using a payment card have been described. However, the invention is not limited to embodiments using a payment card and encompasses other payment methods such as payments using, for example, a smartphone or other devices such as QR, EAN, PIN codes, etc. Thus, the scope of the invention is defined only by the claims.

[0113] Furthermore, all steps in the claims need not be performed in the order described. For example, the purchase rules need not be entered into the central database configuration 110 before the transaction ID is generated. Further, when the purchasing institution 200 changes the purchase rules and enters new purchase rules into the central database configuration 110, the metadata regarding the purchase rules associated with the transaction ID in the central database configuration 110 is updated and can be transferred to the bank-specific database module 130 until the purchase approval request for the transaction ID is approved or rejected. In another example, transaction information can be added as metadata associated with the transaction ID before or after the approval / rejection of the purchase approval request. The order of all technically meaningful steps is covered by the claims. [Item 1] Comprising a central database configuration, a client interface to the central database configuration, and a bank-specific database module configured to communicate with a transaction authentication module within the bank. The central database configuration is configured to receive, through the client interface, purchase rules applied to a purchase group from a purchasing institution, and has central processing means, and the central processing means: adds the selected purchase group as metadata associated with a first transaction ID in the central database configuration, adds the purchase rules applied to the purchase group as metadata associated with the first transaction ID in the central database configuration, is configured to transfer the metadata associated with the first transaction ID to the bank-specific database module, The bank-specific database module is configured to receive a purchase approval request from the transaction authentication module, the purchase approval request includes transaction information including at least a purchase amount associated with the first transaction ID, and the bank-specific database module has bank processing means, and the bank processing means: determines the purchase approval request by approving or rejecting, based on whether the requested purchase meets, the purchase rules associated with the first transaction ID in the bank-specific database module, responds to the transaction authentication module according to the approval or rejection of the purchase approval request, adds the transaction information received from the transaction authentication module as metadata associated with the first transaction ID in the bank-specific database module, is configured to transfer the transaction information associated with the first transaction ID to the central database configuration, The central processing means of the central database configuration is further configured to transfer the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase can be automatically input into at least one management system of the purchasing institution. A purchase management system. [Item 2] The bank-specific database module is the purchase management system described in Item 1, which is arranged within the bank. [Item 3] The purchase rule is the purchase rule applied to a purchase group including at least one individual purchaser, which is the purchase management system described in Item 1 or 2. [Item 4] The purchase rule is the purchase rule applied to a purchase group including the entire purchasing institution, which is the purchase management system described in any one of Items 1 to 3. [Item 5] The purchase rule is a general purchase rule for a sub-section of the purchasing institution. The central processing means of the central database configuration is configured to add, as metadata associated with the first transaction ID in the central database configuration, the purchase rule applied to the purchase group based on a determination of which sub-section the purchase group belongs to. This is the purchase management system described in any one of Items 1 to 4. [Item 6] The transaction information includes franchise information. The bank processing means of the bank-specific database module is further configured to determine the purchase approval request by approving or rejecting it based on the franchise information. This is the purchase management system described in any one of Items 1 to 5. [Item 7] The purchase rule specifies that, before purchase execution, predetermined metadata needs to be added to and associated with the transaction ID in the central database configuration. The bank processing means of the bank-specific database module is configured to reject the purchase approval request if the metadata does not exist and is not associated with the transaction ID in the bank-specific database module. This is the purchase management system described in any one of Items 1 to 6. [Item 8] The central processing means of the central database configuration is further configured to transfer information to a payment card issuing institution that issues a payment card to the purchasing institution, either directly or via a payment card management module within the bank, for the purchase management system according to any one of items 1 to 7. [Item 9] The purchase management system is configured to be synchronized such that the central database configuration and the bank-specific database module are in a form that reflects each other, for the purchase management system according to any one of items 1 to 8. [Item 10] The central database configuration is configured to communicate with a number of different organizations, and includes an adapter that converts the data formats used by each of these different organizations into a single data format, which is preferably the data format defined by the purchasing institution, for the purchase management system according to any one of items 1 to 9. [Item 11] Inputting the purchase rules applicable to the purchase group into the central database configuration through the client interface; Adding the selected purchase group as metadata associated with the first transaction ID in the central database configuration; Adding the purchase rules applicable to the purchase group as metadata associated with the first transaction ID in the central database configuration; Transferring the metadata associated with the first transaction ID from the central database configuration to the bank-specific database module; Receiving, in a transaction authentication module arranged within the bank, a first transaction authentication request associated with the first transaction ID and including transaction authentication information; Communicating a purchase approval request including transaction information including at least the purchase amount from the transaction authentication module to the bank-specific database module; Determining the purchase approval request by approving or rejecting it based on whether the required purchase meets the purchase rules associated with the first transaction ID in the bank-specific database module; Responding to the approval or rejection of the purchase approval request to the transaction authentication module; Responding to the first transaction authentication request associated with the first transaction ID from the transaction authentication module; Adding the transaction information received from the transaction authentication module as metadata associated with the first transaction ID in the bank-specific database module; Transferring the transaction information associated with the first transaction ID to the central database configuration; Transferring the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase can be automatically input into at least one management system of the purchasing institution. A purchase management method comprising the steps of. [Item 12] The bank-specific database module is arranged within the bank. The purchase management method according to item 11. [Item 13] The purchase group includes at least one purchasing individual. The purchase management method according to item 11 or 12. [Item 14] The purchase group includes the entire purchasing institution. The purchase management method according to any one of items 11 to 13. [Item 15] The purchase rule is a general purchase rule for a subsection of the purchasing institution. The step of adding the purchase rule applied to the purchase group as metadata associated with the first transaction ID in the central database configuration includes the step of determining to which subsection the purchase group belongs. The purchase management method according to any one of items 11 to 14. [Item 16] The transaction information includes store information, and the stage of determining the purchase approval request by approval or rejection is a purchase management method according to any one of Items 11 to 15 based on the store information. [Item 17] The purchase rule specifies that before purchase execution, predetermined metadata needs to be added to and associated with the transaction ID in the central database configuration. The stage of determining the purchase approval request includes the stage of rejecting the purchase approval request if the metadata does not exist and is not associated with the transaction ID in the bank-specific database module. The purchase management method according to any one of Items 11 to 16. [Item 18] The method further includes a stage of transferring information from the central database configuration to the payment card issuing institution directly or via the payment card management module within the bank, whereby the payment card issuing institution can issue a payment card to the purchasing institution. The purchase management method according to any one of Items 11 to 17. [Item 19] The stage of transferring the metadata associated with the first transaction ID from the central database configuration to the bank-specific database module and the stage of transferring the transaction information associated with the first transaction ID to the central database configuration include a stage of synchronizing the central database configuration and the bank-specific database module so as to be in a mutually reflected form. The purchase management method according to any one of Items 11 to 18. [Item 20] The central database configuration is configured to communicate with a number of different groups and includes an adapter for converting the data formats used by each of these different groups into a single data format, preferably the data format defined by the purchasing institution. The purchase management method according to any one of Items 11 to 19.

Claims

1. A purchase management system comprising a central database configuration configured to communicate with a transaction authentication module within a bank, and a client interface to the central database configuration, wherein the central database configuration is configured to receive, via the client interface, from a purchasing institution, a purchase rule applied to a purchase group and a data format defined by the purchasing institution, fields in the central database configuration enable metadata to be associated with a plurality of transaction IDs, and fields in the central database configuration are dynamically set by the purchasing institution to define the metadata desired by the purchasing institution and the data format for the metadata, and has central processing means, the central processing means adds a selected purchase group as the metadata of the data format defined by the purchasing institution associated with a first transaction ID of the plurality of transaction IDs in the central database configuration, is configured to add the purchase rule applied to the purchase group as the metadata associated with the first transaction ID in the central database configuration, the transaction authentication module is configured to communicate a purchase approval request, the purchase approval request includes transaction information, the purchase approval request is generated by the transaction authentication module based on the transaction information received from the transaction authentication module via a payment card network, the transaction information includes at least a purchase amount associated with the first transaction ID, and the purchase management system has bank processing means, the bank processing means determines the purchase approval request by approving or rejecting the purchase approval request based on whether a requested purchase meets the purchase rule associated with the first transaction ID in the central database configuration, responds to the transaction authentication module by approving or rejecting the purchase approval request, configured to add the transaction information received from the transaction authentication module as the metadata associated with the first transaction ID the central processing means of the central database configuration is further configured to transfer the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase is automatically input into at least one management system of the purchasing institution the central database configuration is configured to communicate with a plurality of different organizations, includes a plurality of adapters, each adapter corresponds to one of the plurality of different organizations, and the plurality of adapters convert the data format used by the corresponding different organizations of the plurality of different organizations into the data format defined by the purchasing institution, a purchase management system

2. The purchase management system according to claim 1, wherein the purchase rule is a purchase rule applied to a purchase group including at least one purchasing individual

3. The purchase management system according to claim 1 or 2, wherein the purchase rule is a purchase rule applied to a purchase group including the entire purchasing institution

4. The purchase rule is a general purchase rule for a subsection of the purchasing institution, and the central processing means of the central database configuration is configured to add the purchase rule applied to the purchase group as the metadata associated with the first transaction ID in the central database configuration based on a determination of which subsection the purchase group belongs to. The purchase management system according to any one of claims 1 to 3

5. The transaction information includes franchise information, and the bank processing means is further configured to determine the purchase approval request by approving or rejecting the purchase approval request based on the franchise information. The purchase management system according to any one of claims 1 to 4

6. The purchase rule specifies that, before purchase execution, predetermined metadata needs to be added to and associated with the first transaction ID in the central database configuration, and the bank processing means is configured to reject the purchase approval request if the metadata does not exist and is not associated with the first transaction ID. The purchase management system according to any one of claims 1 to 5.

7. The central processing means of the central database configuration is further configured to transfer information to a payment card issuing institution that issues a payment card to the purchasing institution, either directly or via a payment card management module within the bank. The purchase management system according to any one of claims 1 to 6.

8. A step of inputting a purchase rule applied to a purchase group and a data format defined by a purchasing institution into a central database configuration through a client interface, wherein fields in the central database configuration enable metadata to be associated with a plurality of transaction IDs, and the fields in the central database configuration are dynamically set by the purchasing institution to define the metadata desired by the purchasing institution and the data format for the metadata. The inputting step; A step of adding a selected purchase group as the metadata of the data format defined by the purchasing institution, which is associated with the first transaction ID among the plurality of transaction IDs in the central database configuration; A step of adding the purchase rule applied to the purchase group as the metadata associated with the first transaction ID in the central database configuration; A step of receiving, in a transaction authentication module disposed within the bank, a first transaction authentication request associated with the first transaction ID and including transaction authentication information; Communicating a purchase approval request from the transaction authentication module, wherein the purchase approval request includes transaction information, the purchase approval request is generated by the transaction authentication module based on the transaction information received from the transaction authentication module via a payment card network, and the transaction information includes at least the purchase amount; Determining the purchase approval request by approving or rejecting the purchase approval request based on whether the requested purchase meets the purchase rules associated with the first transaction ID in the central database configuration; Responding to the transaction authentication module with the approval or rejection of the purchase approval request; Responding to the first transaction authentication request associated with the first transaction ID from the transaction authentication module; Adding the transaction information received from the transaction authentication module as the metadata associated with the first transaction ID; Transferring the transaction information associated with the first transaction ID to the purchasing institution, whereby information about the purchase can be automatically entered into at least one management system of the purchasing institution; and The central database configuration is configured to communicate with a plurality of different organizations and includes a plurality of adapters, each adapter corresponding to one of the plurality of different organizations, and the plurality of adapters convert the data format used by the corresponding different organizations of the plurality of different organizations into the data format defined by the purchasing institution. A purchase management method.

9. The purchase management method according to claim 8, wherein the purchase group includes at least one purchasing individual.

10. The purchase management method according to claim 8 or 9, wherein the purchase group includes the entire purchasing institution.

11. The purchase rule is a general purchase rule for a subsection of the purchasing institution, and the step of adding the purchase rule applied to the purchase group as the metadata associated with the first transaction ID in the central database configuration includes the step of determining to which subsection the purchase group belongs. The purchase management method according to any one of claims 8 to 10.

12. The transaction information includes franchise store information, and the step of determining the purchase approval request by approving or rejecting the purchase approval request further includes the step based on the franchise store information. The purchase management method according to any one of claims 8 to 11.

13. The purchase rule specifies that before the purchase is executed, predetermined metadata needs to be added to and associated with the first transaction ID in the central database configuration. The step of determining the purchase approval request includes the step of rejecting the purchase approval request if the metadata does not exist and is not associated with the first transaction ID. The purchase management method according to any one of claims 8 to 12.

14. The method further comprises the step of transferring information from the central database configuration to the payment card issuing institution directly or via a payment card management module within the bank, whereby the payment card issuing institution may issue a payment card to the purchasing institution. The purchase management method according to any one of claims 8 to 13.

Images