Purchasing management system and method

Abstract

The purchasing management system 100 comprises a central database configuration 110 and a purchasing authorization database module 130, the purchasing authorization database module 130 being operated by a payment provider 400 that operates a payment card network and is therefore configured to communicate with a transaction authorization module 405 located within the payment card network. The central database configuration 110 receives purchasing rules from the purchasing entity 200 that apply to purchasing groups 250; adds the selected purchasing group 250 as metadata linked to a first transaction ID; adds purchasing rules that apply to the purchasing group 250; and transfers the metadata to the purchasing authorization database module 130. The purchasing authorization database module 130 receives purchasing approval requests from the transaction authorization module 405; makes decisions regarding the purchasing approval requests based on whether the requested purchases meet the purchasing rules; responds to the transaction authorization module 405 with approval or rejection of the purchasing approval requests; and transfers the transaction information to the central database configuration 110. The central database configuration 110 transfers the transaction information to the purchasing entity 200, thereby enabling the purchasing information to be automatically imported into the purchasing entity 200's management system. Figure 1

Description

Technical Field

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

Background Art

[0002] US7319986 describes a dynamic payment card management system that can dynamically modify card control configuration items, thereby dynamically managing approval parameters through the application of configurable corporate procurement policies and rules.

[0003] The system described in US7319986 is developed centered on the use of procurement requests. Procurement cannot be performed without a specific procurement request, but the procurement request may be synthesized by the system in some situations. The use of procurement requests simplifies the approval process within the company. [Problems in Conventional Art]

[0004] In the system described in US7319986, a customer may be notified that a transaction has occurred, but since the system is developed centered on the use of procurement requests, there is no method for transferring procurement details to the corporate financial system at the time of procurement. Therefore, the company does not receive the procurement details until it receives an invoice from the supplier.

[0005] Furthermore, the system described in US7319986 is an overall card processing system intended to replace existing payment infrastructure.

[0006] Accordingly, there is a need for an improved procurement management system.

Summary of the Invention

[0007] A purchasing management system that revolves around the use of purchase requests simplifies the internal approval process, but because purchase requests are managed internally within the company, external parties cannot add information to them, such as details about completed purchases.

[0008] According to the present invention, instead of storing purchasing information, a database accessible by any party to the system is used. The database configuration preferably includes functionality to "translate" data formats used by different parties to the system into a single data format, which makes it easier for different parties to add purchasing information.

[0009] This disclosure relates to a purchasing management system and a purchasing management method that enable a purchasing entity to purchase goods and services from suppliers / merchants. Prior art systems do not allow transaction information from such purchases to be automatically incorporated into the purchasing entity's economic system and other management systems. The present invention achieves this by collecting information from various parties to the system in a manner that prior art systems cannot.

[0010] The billed purchasing management system comprises a central database configuration, a customer interface to the central database configuration including data fields for linking metadata to transaction IDs, and a purchasing authorization database module operated by a payment provider operating a payment card network and configured to communicate with a transaction authorization module located within the payment card network. The central database configuration is preferably configured to receive purchasing rules applied to purchasing groups from purchasing entities through the customer interface. The central database configuration preferably comprises a central processing means configured to add selected purchasing groups as metadata linked to a first transaction ID in one or more first data fields within the central database configuration; add purchasing rules applied to the purchasing groups as metadata linked to the first transaction ID in one or more second data fields within the central database configuration; and transfer the metadata linked to the first transaction ID from the data fields to the purchasing authorization database module. The purchase authorization database module may be configured to receive purchase authorization requests from the transaction authorization module, which are generated in the transaction authorization module based on information received via the payment card network and include transaction information, including at least the purchase amount, linked to a first transaction ID.The purchase authorization database module preferably includes authorization processing means configured to: determine a purchase authorization request by approving or rejecting the purchase authorization request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the purchase authorization database module; respond to the transaction authorization module by approving or rejecting the purchase authorization request; add the transaction information received from the transaction authorization module as metadata linked to the first transaction ID in the purchase authorization database module; and transfer the transaction information linked to the first transaction ID to a central database configuration. The central processing means of the central database configuration may further be configured to transfer the transaction information linked to the first transaction ID to the purchasing entity, thereby enabling the purchase information to be automatically incorporated into at least one management system of the purchasing entity. This enables simplified collection of transaction information from purchases and conversion of this transaction information into a data format used by the purchasing entity, thereby enabling the transaction information to be automatically incorporated into the purchasing entity's economic system and other management systems.

[0011] The billed purchasing management system may alternatively include a central database configuration configured to communicate with a transaction authorization module, which is operated by a payment provider operating a payment card network and is therefore located within the payment card network, and a customer interface to the central database configuration which includes data fields for linking metadata to transaction IDs. The central database configuration preferably includes a central processing means configured to receive from a purchasing entity through the customer interface purchasing rules to apply to purchasing groups; add selected purchasing groups as metadata linked to a first transaction ID in one or more first data fields in the central database configuration; add purchasing rules to said purchasing groups as metadata linked to the first transaction ID in one or more second data fields in the central database configuration; and receive purchase authorization requests from the transaction authorization module, which are generated in the transaction authorization module based on information received via the payment card network and include transaction information, including at least the purchase amount, linked to the first transaction ID. The central database configuration preferably includes authorization processing means configured to: determine a purchase approval request by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the central database configuration; respond to the transaction authorization module by approving or rejecting the purchase approval request; and add the transaction information received from the transaction authorization module as metadata linked to the first transaction ID in the central database configuration. The central processing means of the central database configuration may further be configured to transfer the transaction information linked to the first transaction ID to the purchasing entity, thereby enabling the purchase information to be automatically incorporated into at least one management system of the purchasing entity.This enables simplified collection of transaction information from purchases and conversion of this transaction information into a data format used by the purchasing entity, thereby allowing the transaction information to be automatically incorporated into the purchasing entity's economic system and other management systems without the need for a separate purchase authorization database module.

[0012] The billed purchasing management method includes the steps of: entering purchasing rules to be applied to purchasing groups through a customer interface to a central database configuration that includes data fields for linking metadata to transaction IDs; adding selected purchasing groups as metadata linked to a first transaction ID in one or more first data fields in the central database configuration; adding purchasing rules to said purchasing groups as metadata linked to the first transaction ID in one or more second data fields in the central database configuration; transferring the metadata linked to the first transaction ID from the data fields in the central database configuration to the purchasing authorization database module; and receiving a first transaction authorization request linked to the first transaction ID in a transaction authorization module operated by a payment provider operating a payment card network, and therefore located within the payment card network, where the first transaction authorization request includes transaction authorization information; Steps include: transmitting a purchase authorization request from the transaction authorization module to the purchase authorization database module, wherein the purchase authorization request is generated in the transaction authorization module based on information received via the payment card network and includes transaction information, at least the purchase amount; determining whether to approve or reject the purchase authorization request in the purchase authorization database module based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID; responding to the transaction authorization module by approving or rejecting the purchase authorization request; responding to the first transaction authorization request linked to the first transaction ID from the transaction authorization module; adding the transaction information received from the transaction authorization module as metadata linked to the first transaction ID in the purchase authorization database module; and transferring the transaction information linked to the first transaction ID to the central database configuration.The process also includes a step of transferring transaction information linked to a first transaction ID to the purchasing entity, thereby enabling the information regarding the purchase to be automatically incorporated into at least one of the purchasing entity's management systems. This allows for the simplified collection of transaction information from the purchase and its conversion into a data format used by the purchasing entity, thereby enabling the transaction information to be automatically incorporated into the purchasing entity's economic system and other management systems.

[0013] The requested purchasing management method is, alternatively, a customer interface to a central database configuration that includes data fields for linking metadata to transaction IDs, which involves the steps of: entering purchasing rules to be applied to purchasing groups; adding selected purchasing groups as metadata linked to a first transaction ID in one or more first data fields in the central database configuration; adding purchasing rules to said purchasing groups as metadata linked to the first transaction ID in one or more second data fields in the central database configuration; receiving a first transaction authorization request linked to a first transaction ID in a transaction authorization module operated by a payment provider operating a payment card network and therefore located within the payment card network, the first transaction authorization request including transaction authorization information; and transmitting the purchase authorization request from the transaction authorization module to the central database configuration. The transaction includes the following steps: generating transaction information in the transaction authorization module based on information received via the payment card network, and including at least the purchase amount; determining the purchase authorization request by approving or rejecting the purchase authorization request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the central database configuration; responding to the transaction authorization module by approving or rejecting the purchase authorization request; responding to the first transaction authorization request linked to the first transaction ID from the transaction authorization module; adding the transaction information received from the transaction authorization module as metadata linked to the first transaction ID in the central database configuration; and transferring the transaction information linked to the first transaction ID to the purchasing entity, thereby enabling the purchase information to be automatically incorporated into at least one of the purchasing entity's management systems.This enables simplified collection of transaction information from purchases and conversion of this transaction information into a data format used by the purchasing entity, thereby allowing the transaction information to be automatically incorporated into the purchasing entity's economic system and other management systems without the need for a separate purchase authorization database module.

[0014] According to the present invention, the payment card number identifies the payment service provider and also identifies to the payment card network and / or payment service provider that the payment card is part of a purchasing management system. Therefore, the payment card number automatically triggers the generation of a purchase authorization request, which enables direct "hard blocking" of purchases at the time of purchase, based on purchasing rules defined by the purchasing entity.

[0015] In the embodiment, the purchase authorization database module is operated by the same entity as the central database configuration, and in the embodiment, it may even be part of the central database configuration so that a separate purchase authorization database module is not required.

[0016] In this embodiment, the purchase authorization database module is operated by a bank or other type of payment service provider (e.g., Apple®, Google®, Klarna®, PayPal®, Amazon®, or Alibaba®) or a transaction provider (e.g., FIS Global® or Nexi®).

[0017] The transaction authorization module is preferably operated by a payment provider operating a payment card network (e.g., MasterCard®, VISA®, or American Express®, etc.) and is therefore located within the payment card network. Because the payment provider operates the payment card network, the payment provider has access to all transaction information transmitted within the payment card network. When the transaction authorization module is operated by a payment provider operating a payment card network, checks typically performed by the payment provider (e.g., those relating to card data, limits, and behavior) can be performed within the transaction authorization module without even contacting the cardholder's bank (i.e., the bank holding the account).

[0018] In some embodiments, the purchase authorization module is also operated by the payment provider, possibly together with the provider of the central database configuration. However, the purchase authorization module may alternatively be operated by a third party and communicate directly with the transaction authorization module within the payment card network. In either case, purchase authorization based on purchase rules can be performed between the transaction authorization module and the purchase authorization module without even contacting the cardholder bank, if desired. In this case, the cardholder bank is not contacted until all checks except a final check of the account balance have been performed. However, it is also possible for the cardholder bank to perform a check of the account balance before the purchase authorization module performs purchase authorization based on purchase rules.

[0019] In this embodiment, data fields in the central database configuration are configurable, and the central database configuration is configured to receive from the purchasing entity a configuration of the data format of metadata for each data field defined for the purchasing group.

[0020] In this embodiment, the purchasing group includes at least one purchasing individual. This allows purchasing rules to be defined for and applied to one or more specific purchasing individuals, or to be defined for a subsection of a purchasing entity that includes one or more purchasing individuals.

[0021] In this embodiment, the purchasing group includes all purchasing entities. This allows a purchasing entity to define general purchasing rules for all entities.

[0022] In this embodiment, the purchasing rules are general purchasing rules for a subsection of a purchasing entity, and adding the purchasing rules applicable to a purchasing group as metadata linked to the first transaction ID in the central database configuration involves determining which subsection the purchasing group belongs to.

[0023] In the embodiment, transaction information includes merchant information, such as the merchant's name or merchant category and / or a code to identify the merchant, and decisions regarding a purchase authorization request, by approving or rejecting the purchase authorization request, are further based on the merchant information. This allows the purchasing entity to block purchases from selected suppliers / merchants and / or merchant categories, and / or to allow purchases only from selected suppliers / merchants and / or merchant categories. The purchasing entity can also block purchases in a certain city, region, country, currency or similar, and / or to allow purchases only in a certain city, region, country, currency or similar.

[0024] In an embodiment, a large-scale supplier / merchant that supplies a plurality of different product categories uploads the product numbers of those products to a central database arrangement, and a purchasing entity indicates which products are permitted to be purchased by a purchasing group. At the time of purchase, the supplier / merchant communicates directly with the central database arrangement and / or the purchase authorization database module to check whether the purchase of the currently targeted product is permitted in accordance with the purchase rules of the purchasing group. This check is performed in addition to the purchase approval request, and enables the purchase rules to also include rules regarding which product categories are permitted to be purchased.

[0025] In an embodiment, the purchase rules specify that certain metadata must be added linked to a transaction ID in the central database arrangement before a purchase is made, and determining on the purchase approval request includes rejecting the purchase approval request if this metadata does not exist linked to the transaction ID in the purchase authorization database module.

[0026] In an embodiment, information is transferred from the central database arrangement to the payment card issuing entity directly or via a payment card management module within the cardholder's bank, whereby the payment card issuing entity can issue a payment card to the purchasing entity.

[0027] In an embodiment, the central database arrangement and the purchase authorization database module are synchronized to be mirror versions of each other. However, mirroring does not necessarily include all information in the database, and some metadata fields may be excluded from mirroring.

[0028] In an embodiment, the purchase authorization database module is operated by the same entity as the central database arrangement, and in an embodiment, may even be part of the central database arrangement such that a separate purchase authorization database module is not required.

[0029] In the embodiment, the central database arrangement is configured to communicate with a plurality of different parties, and includes an adapter that converts the data format used by each of these different parties into a single data format, preferably a data format defined by the purchasing entity.

[0030] The term "payment card" in the present application encompasses all payment means used for payment via a payment card network such as, for example, MasterCard, VISA or American Express. This also includes cases where physical payment cards, electronic payment cards, virtual payment cards, smartphones or other devices are used for payment services such as Apple Pay, Google Pay, Samsung Pay, and includes the use of, for example, QR, EAN or PIN codes.

[0031] In this application, the term “bank” refers to any payment service provider or financial institution authorized to approve and execute payment card payments or similar types of transactions, and therefore does not refer only to payment service providers or financial institutions formally defined and licensed as banks. In some jurisdictions, payment service providers or financial institutions must meet certain regulatory requirements, for example, to be covered by deposit insurance schemes, and in those jurisdictions, the term “bank” may be reserved for payment service providers or financial institutions that meet such regulatory requirements. In this application, the term “bank” is not so limited and encompasses any payment service provider or financial institution authorized to approve and execute payment card payments or similar types of transactions. Therefore, in this application, the term “bank” may also encompass payment networks such as MasterCard, VISA, or American Express that approve and execute transactions. In this application, the term “bank” also encompasses cooperation between payment networks such as MasterCard, VISA, or American Express and payment service providers or financial institutions authorized to approve and execute payment card payments or similar types of transactions.

[0032] In this application, the term "cardholder bank" refers to the "bank" that holds the account used for the transaction.

[0033] The central processing means of a central database configuration may be a single central processing configuration, or it may be multiple central processing configurations between which signals are transmitted. Some processing may be performed, for example, in one central processing configuration, and then the signals may be transmitted to one or more other central processing configurations for further processing.

[0034] The authorization processing means of the purchase authorization database module can be any processing configuration within the system, and therefore is not necessarily specific to the purchase authorization database module.

[0035] Modules can be physically separate modules from which information is transmitted, but they can also be virtual modules implemented on the same server, or simply software modules.

[0036] The scope of the present invention is defined by the claims incorporated into this section by reference. A more complete understanding of embodiments of the present invention and recognition of their additional advantages will be given to those skilled in the art by considering the following detailed descriptions of one or more embodiments. The accompanying sheet of drawings, which is briefly described first, will be referenced. [Brief explanation of the drawing]

[0037] [Figure 1] A schematic diagram of a purchasing management system according to the embodiments described herein is shown. [Figure 2] A schematic diagram of a purchasing management system according to the embodiments described herein is shown. [Figure 3] A schematic diagram of a purchasing management system according to the embodiments described herein is shown.

[0038] [Figure 4] This is an illustrative flowchart of a purchasing management method according to the embodiments described herein.

[0039] [Figure 5] A schematic diagram shows a portion of a purchasing management system according to one or more embodiments described herein.

[0040] [Figure 6] This is an example of transaction authorization information.

[0041] [Figure 7] A schematic representation of a purchasing management method according to the embodiments described herein is shown.

[0042] Embodiments of this disclosure and their advantages will be best understood by referring to the detailed description below. It should be understood that similar reference numerals are used to identify similar elements shown in one or more figures. [Modes for carrying out the invention]

[0043] There are several different types of payment card processing models. The simplest model, in which the merchant issues the payment card and has a direct relationship with the cardholder, can be defined as the two-corner model. In the two-corner model, the cardholder can only use the payment card at the issuing merchant.

[0044] If a merchant does not wish to issue and handle payment cards, a three-corner model can be used in which a third party acts as an intermediary between the cardholder and the merchant. In the three-corner model, the cardholder can still use the payment card only at designated merchants.

[0045] To provide cardholders with greater flexibility, payment cards typically use a four-corner model instead. In such a model, a cardholder can use the payment card to make payments at any merchant that accepts cards, and the transaction is handled between the merchant bank and the cardholder bank via a payment card network such as MasterCard, Visa, or American Express. The payment card has a payment card number, which (in the case of a physical payment card) is typically hardwired into the chip and / or magnetic stripe of the payment card.

[0046] In this application, the term "payment card" encompasses all payment methods used for settlements via payment card networks such as MasterCard, VISA, or American Express. This includes physical payment cards, electronic payment cards, virtual payment cards, smartphones, or other devices used with payment services such as Apple Pay, Google Pay, and Samsung Pay, and includes the use of QR codes, EAN codes, or PIN codes.

[0047] When a payment card is used for payment, transaction authorization is achieved by the merchant bank sending a transaction authorization request to the cardholder bank via the payment card network. Such a transaction authorization request may include transaction authorization information, for example, as shown in Figure 6. The cardholder bank then typically performs several checks, such as card data, account balance, limits, and behavior, to approve or reject the transaction.

[0048] According to the present invention, in addition to general transaction authorization, purchase authorization requests are added to the transaction authorization process. Purchase authorization is performed simultaneously with general transaction authorization. Merchant banks do not need to be involved in, or even informed of, the fact that purchase authorization is performed in addition to general transaction authorization. If a purchase is not authorized, merchant banks receive information that the transaction was not authorized, but they do not necessarily receive information as to whether this is due to checks on, for example, card data, account balance, limits and behavior, or because the requested purchase does not meet the purchase rules.

[0049] Therefore, according to the present invention, suppliers / merchants do not need to be configured in a purchasing management system before a purchase is made, and suppliers / merchants do not need to be linked to any purchasing management system in any way. The present invention makes it possible for information about a purchase to be transferred to the purchasing entity even if the supplier / merchant is not linked to a purchasing management system in any way, and this is not possible by any prior art system.

[0050] This enables simplified collection of transaction information from purchases and conversion of this transaction information into a data format used by the purchasing entity, thereby allowing the transaction information to be automatically incorporated into the purchasing entity's economic system and other management systems. The payment card number (in the case of a physical payment card, typically hardwired on the chip and / or magnetic stripe on the payment card) identifies the payment service provider and also identifies the payment card network and / or payment service provider that the payment card is part of a purchasing management system. Thus, it is the payment card number that automatically triggers the generation of a purchase authorization request, which enables direct "hard blocking" of purchases at the time of purchase, based on purchasing rules defined by the purchasing entity.

[0051] This disclosure relates to a purchasing management system and a purchasing management method. Embodiments of the disclosed solutions are presented in more detail with reference to the drawings.

[0052] Figures 1-3 schematically show different embodiments of the purchasing management system 100.

[0053] The purchasing management system 100 schematically shown in Figure 1 includes a central database configuration 110 (which may be, for example, a cloud service), a customer interface 120 to the central database configuration 110, and a purchasing authorization database module 130 configured to communicate with a transaction authorization module 405 located within the payment card network, which is operated by a payment provider 400 that operates a payment card network such as MasterCard, VISA, or American Express. Since the payment provider 400 operates the payment card network, the payment provider 400 has access to all transaction information transmitted within the payment card network. If the transaction authorization module 405 is operated by the payment provider 400 that operates the payment card network, checks typically performed by the payment provider 400 (e.g., those relating to card data, limits, and behavior) may be performed in the transaction authorization module 405 without even contacting the cardholder bank 500 (i.e., the bank where the account is held).

[0054] In the embodiment of the purchasing management system 100 schematically shown in Figure 1, the purchasing authorization module 130 is also operated by the payment provider 400, and possibly together with the provider of the central database configuration 110. However, the purchasing authorization module 130 may be operated by a third party and may communicate directly with the transaction authorization module 405 in the payment card network. In either case, purchasing authorization based on purchasing rules may be performed between the transaction authorization module 405 and the purchasing authorization module 130 without even contacting the cardholder bank 500, if desired. In this case, the cardholder bank 500 is not contacted until all checks except a final check of the account balance have been performed. However, it is also possible for the cardholder bank 500 to perform a check of the account balance before the purchasing authorization module 130 performs purchasing authorization based on purchasing rules.

[0055] In an embodiment, the purchase authorization database module 130 may therefore be operated by the same entity as the central database configuration 110, and in an embodiment, it may even be part of the central database configuration 110, so that a separate purchase authorization database module 130 is not required.

[0056] In this embodiment, the purchase authorization database module 130 may be operated by a bank or other type of payment service provider (e.g., Apple, Google, Klarna, PayPal, Amazon, or Alibaba) or a transaction provider (e.g., FIS Global or Nexi).

[0057] The central database configuration 110 preferably includes data fields that enable metadata to be linked to transaction IDs. These data fields may be configurable and dynamic, and the central database configuration 110 may be configured to receive configurations from the purchasing entity 200 regarding the data format of metadata for each data field defined for the purchasing group 250.

[0058] The central database configuration 110 may be configured to receive purchasing rules from purchasing entities 200 through the customer interface 120. These purchasing rules may be general purchasing rules for the purchasing entity 200 as a whole, but they may also be purchasing rules specific to a subsection of the purchasing entity 200, or even purchasing rules specific to an individual purchaser. The customer interface 120 may be, for example, a web interface or a mobile application.

[0059] The central processing unit 115 of the central database configuration 110 can create transaction IDs used in transactions. These transaction IDs can be created one at a time or in batches, and they can be created based on predefined rules or in response to requests from purchasing entities 200. Transaction IDs can even be created before any purchasing rules are defined. Transaction IDs may require activation before use.

[0060] For each transaction ID, information about the intended buyer may be added as metadata in one or more data fields within the central database configuration 110. The intended buyer may be defined, for example, as any individual buyer within a purchasing group 250. A purchasing group 250 may include one or more specific individuals buyers, but may also be defined, for example, as a subsection of purchasing entity 200, or as purchasing entity 200 as a whole. Not all individuals buyers within a purchasing group 250 are employed by purchasing entity 200—a purchasing group 250 may include, for example, consultants or subcontractors to purchasing entity 200.

[0061] Based on metadata relating to the purchasing group 250, the central processing unit 115 of the central database configuration 110 can identify which purchasing rules apply to this particular transaction ID and add these purchasing rules as metadata linked to the transaction ID in one or more data fields within the central database configuration 110. While the purchasing rules are always identical for all purchasing individuals within the purchasing group 250, the purchasing group 250 can be dynamically modified if different purchasing rules are required for different purchasing individuals within the group. In such cases, a new purchasing group 250 is simply formed for the purchasing individuals who require different purchasing rules.

[0062] Other types of information related to the transaction may also be added as metadata linked to the transaction ID in one or more data fields within the central database configuration 110. Other entities other than the purchasing entity 200 may also have access to the central database configuration 110 and add metadata linked to the transaction ID. The addition of metadata to the central database configuration 110 by a third-party entity 150, preferably using a specific third-party interface 160, is shown in Figure 2. The third-party interface 160 may be, for example, a web interface or a mobile application.

[0063] Such a third-party entity 150 may, for example, be a client of purchasing entity 200, and for its benefit, purchasing entity 200 makes a purchase for further billing purposes to the client. In such a case, the metadata could be, for example, an authorization to bear the cost of the purchase. In this case, it would be advantageous if all the information necessary for billing the client were added as metadata linked to the transaction ID, thereby simplifying or even automating the billing process to the client.

[0064] Another example of such a third-party entity 150 could be an organization that provides information about blacklisted suppliers or suppliers that do not comply with certain regulatory requirements. If such an organization adds this information as metadata to all transaction IDs, the purchasing rules may define that purchases from suppliers / merchants defined by this metadata are never permitted.

[0065] A further example of such a third-party entity 150 is a merchant / supplier 300. If the merchant / supplier 300 has access to the central database configuration 110 and can add metadata linked to transaction IDs, the merchant / supplier 300 may add, for example, an electronic receipt as metadata linked to a transaction ID. The merchant / supplier 300 may use a third-party interface 160, or a specific interface for the merchant / supplier 300. Such an interface may be, for example, a web interface or a mobile application. However, if the merchant / supplier 300 does not have access to the central database configuration 110, the electronic receipt may also be added by another party, for example, by an individual buyer within a purchasing group 250.

[0066] Individual buyers within the purchasing group 250 may also communicate with the central database configuration 110 to retrieve information and / or add metadata. For example, if purchasing entity 200 wishes to allow company payment cards to be used for personal purchases, individual buyers may have the option to tag purchases as personal and, for example, have the cost automatically deducted from their next paycheck. Individual buyers within the purchasing group 250 may use the third-party interface 160 or a specific interface for the purchasing group 250. Such an interface may be, for example, a web interface or a mobile application.

[0067] Purchasing rules may, for example, require purchasing individuals to add certain metadata to transaction IDs either before or after a purchase, in order to simplify management within Purchasing Entity 200. Purchasing individuals may be required to add, for example, accounts, cost centers, projects, or objects as metadata linked to transaction IDs. Further requirements may then be applied to specific types of purchases based on the metadata added by the purchasing individual. For example, if a purchase relates to a representation such as a restaurant visit with a client, the purchasing individual may be required to add the names of those present as metadata linked to the transaction ID. If a purchase relates to a business trip, the purchasing individual may be required to specify the destination and / or purpose of the trip. This enables automated accounting processing of invoices within Purchasing Entity 200. Purchasing rules may require that this metadata be added for a purchase to be approved. If purchasing rules require that this metadata be added, purchasing individuals may be warned, even before they attempt to make a purchase, that the purchase will be rejected if this metadata is not added. In this case, such a warning is preferably communicated to the individual purchaser, for example, via SMS, email, or a mobile application.

[0068] However, certain information items cannot be added before a purchase is approved. A purchasing individual may be required to add a receipt as metadata linked to the transaction ID, for example, by taking a picture of the receipt using a mobile application. In such a situation, the purchase has already been made and therefore cannot be rejected, but future purchases for this purchasing individual may be blocked until the required metadata has been added to all previous transactions. This blocking may be done manually by the purchasing entity 200. However, the purchase rules may specify that all further purchases will be automatically blocked after a certain period of time or after a certain number of purchases if this has not been done.

[0069] Purchasing rules may also specify the methods by which purchases can be made from a particular supplier / merchant. For example, they might specify that, for cost reasons, only web-based purchases are permitted from a particular supplier, and in this case, attempts to make purchases at physical stores will be rejected. Information regarding the reason for the rejection would, in this case, preferably be communicated to the individual purchaser, for example, via SMS, email, or a mobile application.

[0070] Metadata linked to transaction IDs can be transferred to the purchase authorization database module 130. It is not necessary to transfer all metadata to the purchase authorization database module 130, as long as the purchase rules and all applicable metadata are transferred. However, in one embodiment, all information in the central database configuration 110 is mirrored to the purchase authorization database module 130. In this embodiment, the purchase authorization database module 130 may even be part of the central database configuration 110.

[0071] When the purchase authorization database module 130 receives metadata linked to a transaction ID, a purchase authorization request may be sent from the transaction authorization module 405. The purchase authorization request includes transaction information, which is typically identical to the transaction authorization information that is sent from the merchant bank to the cardholder bank 500 via the payment card network when a payment card is used for payment, and received by the transaction authorization module 405. An example of such transaction authorization information is shown in Figure 6. The transaction information in the purchase authorization request does not necessarily have to include all of the transaction authorization information, as long as it includes the amount, along with enough information to link it to the desired transaction ID. If the purchase authorization request does not include a transaction ID, it therefore must include some other transaction information item that enables the purchase authorization database module 130 to link the purchase to a transaction ID, such as transaction information that identifies the purchase group 250. If one or more specific payment cards are assigned to the purchase group 250, this transaction information may be, for example, the payment card number or a token for the payment card number. The authorization processing means 135 of the purchase authorization database module 130 may then simply assign the purchase to the next available transaction ID for this purchase group 250.

[0072] The authorization processing means 135 of the purchase authorization database module 130 then reviews whether the requested purchase satisfies the purchase rules linked to the transaction ID, i.e., the purchase rules applicable to the purchase group 250. In addition to the examples given above, purchase rules may relate to, for example, a maximum amount for each purchase, a maximum total amount, adherence to a budget, or restrictions on where or when purchases may be made (for example, overseas purchases or weekend purchases may be blocked). If the purchase authorization request includes merchant information such as, for example, the merchant's name or merchant category and / or a code to identify the merchant, the purchase rules may also relate to specific merchants that are permitted or blocked for the purchase group 250. This allows the purchasing entity 200 to block purchases from selected suppliers / merchants and / or merchant categories, and / or to permit purchases only from selected suppliers / merchants and / or merchant categories. Purchasing entity 200 may, for example, use this functionality to block purchases from liquor stores such as Systembolaget, or to allow purchases only from specific grocery chains such as ICA and / or Coop, or from specific types of affiliated stores such as grocery stores.

[0073] For example, a large supplier / franchisee that supplies multiple different product categories, such as Walmart or IKEA, can be a party to the purchasing management system 100 and communicate directly with the central database configuration 110 and / or the purchasing authorization database module 130. This allows purchasing rules to include rules regarding which product categories (or individual products) are permitted to be purchased. In an embodiment, the supplier / franchisee may upload the part numbers of their products to the central database configuration 100 so that the purchasing entity 200 can see which products are permitted to be purchased by a particular purchasing group 250. At the time of purchase, the supplier / franchisee may, in this case, communicate directly with the central database configuration 110 and / or the purchasing authorization database module 130 to check whether the purchase of the product currently being purchased is permitted according to the purchasing rules of the purchasing group 250. If the purchasing rules of the purchasing group 250 do not permit the purchase of the product in question, the supplier / franchisee will not allow the purchase to be made. This check is performed in addition to the purchasing approval request described above.

[0074] Therefore, the authorization processing means 135 of the purchase authorization database module 130 approves or rejects the purchase authorization request based on whether the requested purchase satisfies the purchase rules linked to the transaction ID in the purchase authorization database module 130. The authorization processing means 135 of the purchase authorization database module 130 also adds the transaction information received from the transaction authorization module 405 as metadata linked to the transaction ID in the purchase authorization database module 130, and transfers this transaction information to the central database configuration 110, where it is also added as metadata linked to the transaction ID. This can be done either before or after the approval / rejection is sent to the transaction authorization module 405.

[0075] Transaction information is preferably "translated" or converted into another data format, preferably a data format defined by the purchasing entity 200, by a function within the central database configuration 110. This is further explained below with reference to Figure 5.

[0076] Based on the approval / rejection received from the authorization processing means 135 of the purchase authorization database module 130, the transaction authorization module 405 approves or rejects the transaction in conjunction with general transaction authorization performed by checking, for example, card data, account balance, limit, and behavior. If the authorization processing means 135 of the purchase authorization database module 130 rejects the transaction, the transaction authorization module 405 rejects the transaction even if general transaction authorization checks indicate that it is acceptable. Similarly, if general transaction authorization checks indicate that the transaction is not acceptable, the transaction authorization module 405 rejects the transaction even if the authorization processing means 135 of the purchase authorization database module 130 approves the purchase. In such situations, since the transaction would be rejected anyway, the transaction authorization module 405 may not even send the purchase authorization request to the purchase authorization database module 130.

[0077] If general transaction authorization is performed in the transaction authorization module 405 before the purchase approval request is sent to the purchase authorization database module 130, the authorization processing means 135 of the purchase authorization database module 130 may be able to determine whether the transaction authorization module 405 approves or rejects the transaction when the authorization processing means 135 of the purchase authorization database module 130 decides whether to approve or reject the purchase approval request. Alternatively, the transaction authorization module 405 may transfer this information to the purchase authorization database module 130. Information regarding whether the transaction was approved or rejected by the transaction authorization module 405 may be added in the purchase authorization database module 130 as metadata linked to the transaction ID.

[0078] Other types of information may also be added to the purchase authorization database module 130 as metadata linked to the transaction ID. The cardholder bank 500 and / or the transaction authorization module 405 may provide the purchase authorization database module 130 with information about suspected fraud, transaction status, or other similar types of information, thereby allowing this information to be transferred to the central database configuration 110.

[0079] When the central database configuration 110 receives transaction information as metadata linked to a transaction ID, the central processing means 115 of the central database configuration 110 may transfer the transaction information to the purchasing entity 200, preferably in a data format defined by the purchasing entity 200. This allows the transaction information to be automatically incorporated into the purchasing entity 200's economic system and / or other management systems. In this way, the purchasing entity can follow up on all transactions well before any invoices are received from suppliers / merchants. This allows the purchasing entity 200 to keep track of its budget at all times and adapt its purchasing rules accordingly.

[0080] Purchasing rules can be adapted for various reasons. If a subsection of a purchasing entity 200 is considered a purchasing group 250, and it is desired to adapt the purchasing rules for a particular purchasing individual within this subsection to, for example, add more restrictions for that individual (or even block all purchases), then a new purchasing group 250 can be created for that individual with more restrictive purchasing rules than the rest of the subsection. Thus, both purchasing groups 250 and purchasing rules can be dynamically updated by the purchasing entity 200.

[0081] Purchasing entity 200 does not necessarily define an actual purchasing group in the system. Instead, purchasing entity 200 may define purchasing rules at multiple hierarchical levels, for example. Some rules may be general to the entire organization, while others may be specific to certain individuals or groups of individuals. In the context of this application, purchasing group 250 is a group of one or more purchasing individuals to whom the same purchasing rules apply.

[0082] The data format of a configurable dynamic data field in the central database configuration 110, which enables the linking of metadata to a transaction ID, may, in an embodiment, be set by the purchasing entity 200, thereby allowing the purchasing entity 200 to define the desired metadata and the data format of this metadata. This allows metadata relating to cost centers, accounts, and other billing processing information to be linked to the transaction ID in the central database configuration 110 in a format desired by the purchasing entity 200. This allows the purchasing entity 200 to define the metadata it wishes to receive and the format in which it wishes to receive it in an electronic invoice, thereby allowing this metadata to be retrieved from the central database configuration 110 and added to the electronic invoice. Such an electronic invoice may be sent, for example, from the cardholder bank 500, from the central database configuration 110, or from a third party. If the invoice for a transaction performed using System 100 is an electronic invoice containing metadata specified by the purchasing entity 200, this enables automated handling of the invoice by the purchasing entity 200, thereby significantly reducing the administrative workload.

[0083] This configuration of configurable dynamic data fields can be very specific, for example, with different configurations of different data fields for different purchasing groups 250, but it can also be very general. For example, a purchasing entity using a particular economy or management system such as SAP, Visma, Oracle, or Microsoft Dynamics may configure dynamic data fields according to a standard setup for users of that particular economy or management system. In this case, the configuration of the data format may simply be a specification of the economy or management system to be used.

[0084] The present invention, for example, may use a payment card to execute a payment. In this case, information about the purchasing individual may be transferred from a central database configuration 110 to a payment card issuer 600, as shown in Figure 3. This transfer may occur directly between the central database configuration 110 and the payment card issuer 600, or it may be performed via a payment card management module 510 which may be located within the cardholder bank 500. The payment card issuer 600 may be linked to the cardholder bank 500, but it may be a separate payment card issuer 600.

[0085] To link a payment made with a payment card to the individual making the purchase, information about the payment card is preferably transferred from the payment card issuer 600 to the central database configuration 110, either directly or via a payment card management module 510 which may be located within the cardholder bank 500. This information is preferably not the actual credit card number, as there may be limitations regarding whether it is permitted to store it in the central database configuration 110 as metadata linked to a transaction ID. This information may instead be, for example, a token of the credit card number.

[0086] Figure 4 is an illustrative flowchart of the purchasing management method in the purchasing management system 100 described in Figure 3. The flow is as follows:

[0087] Step 410: The purchasing entity 200 sets up its purchasing rules in the central database configuration 110 and optionally configures the data format of the metadata for each data field defined by the purchasing entity 200 (this can be done at any point before step 460, and the metadata can be added by the purchasing entity 200 at any point in the flow).

[0088] Step 415: The central database configuration 110 orders a card account for the purchasing entity 200 from the cardholder bank 500. Alternatively, the purchasing entity already has a corporate settlement card with a card account at the cardholder bank 500.

[0089] Step 420: The cardholder bank 500 orders a payment card from the payment card issuer 600 (at least for physical payment cards). If the purchasing entity already has corporate payment cards, these may be configured to interact with the purchasing management system 100 instead as an add-on service.

[0090] Step 425: Additional information such as card personalization, logos, or similar may be provided from the central database configuration 110 to the payment card issuer 600 (at least in the case of physical payment cards). Payment cards may also be ordered directly from the central database configuration 110 by the payment card issuer 600.

[0091] Step 430: The payment card may be sent from the payment card issuer 600 to the purchasing individual 250 (at least in the case of a physical payment card) (the purchasing individual 200 may be involved in the distribution).

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

[0093] Step 440: (In embodiments where a separate purchase authorization database module 130 is used) The transaction ID and its linked metadata (purchase rules, etc.) are transferred from the central database configuration 110 to the purchase authorization database module 130.

[0094] Step 445: The individual buyer makes a purchase from 300 affiliated stores / suppliers.

[0095] Step 450: The merchant bank 550 receives purchase information from the merchant / supplier 300.

[0096] Step 455: The merchant bank 550 requests the cardholder bank 500 to authorize the transaction via the payment card network operated by the payment provider 400 (e.g., MasterCard, VISA, or American Express).

[0097] Step 460: The transaction authorization module 405 (which is operated by the payment provider 400 and is therefore located within the payment card network) requests purchase authorization from the purchase authorization database module 130 (or, in embodiments where a separate purchase authorization database module 130 is not used, directly to the central database configuration 110).

[0098] Step 465: The purchase authorization database module 130 (or central database configuration 110) sends the purchase authorization to the transaction authorization module 405.

[0099] Step 470: The transaction authorization module 405 requests transaction authorization from the cardholder bank 500 (this may be done before steps 460 and 465).

[0100] Step 475: The cardholder bank 500 sends the transaction authorization to the merchant bank 550 (either directly or via the transaction authorization module 405).

[0101] Step 480: The merchant bank 550 sends the transaction authorization to the merchant / supplier 300.

[0102] Step 485: The purchase authorization database module 130 transfers transaction information relating to the approved purchase to the central database configuration 110 (this can be done at any point after step 460 and is only required in embodiments where a separate purchase authorization database module 130 is used).

[0103] Step 490: The central database configuration 110 transfers transaction information to the purchasing entity 200.

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

[0105] Figure 5 schematically shows a portion of a purchasing management system 100 according to one or more embodiments described herein. The central database configuration 110 preferably uses dynamic configuration of data fields, i.e., “metadata carriers,” which enable metadata to be linked to transaction IDs, thereby allowing the purchasing entity 200 to define desired metadata and the format for this metadata. As described above in relation to Figures 1-3, the central database configuration 110 may interact and communicate with many different parties, such as the purchasing entity 200, purchasing individuals or purchasing groups 250, merchants / suppliers 300, cardholder banks 500, payment card issuers 600, and various other third-party entities 150. In order for the central database configuration 110 to collect data from and transmit data between these parties, the central database configuration 110 needs to have the functionality to “translate” or convert, for example in the form of “adapters,” the data formats used by each of these different parties into a single data format, preferably a data format defined by the purchasing entity 200. The central database configuration 110 needs to have specific adapters 205, 255, 305, 505, 605, and 155 for each party 200, 250, 300, 500, 600, and 150, since different parties generally use different data formats (if there are several different third parties 150, several different adapters 155 are generally required). This makes it possible for the purchasing entity 200 to define the metadata it wishes to receive from different parties, and the data format of this metadata.

[0106] [Example Embodiments] The following example illustrates one embodiment of a purchasing management system 100 that provides an EASI Purchase Management System (EPMS) to a customer (purchasing entity 200) in cooperation with a payment service provider, where the purchasing management service provider EASI operates a central database configuration 110 and provides EASI Authorization Control (EAC) as an add-on to its payment services. The EAC database may be hosted by the payment service provider (either alone or in cooperation with the purchasing management service provider EASI), or it may be hosted entirely by the purchasing management service provider EASI.

[0107] The purchasing entity 200 adds / integrates EASI services into its economic or management system (e.g., SAP, Visma, Oracle, or Microsoft Dynamics). The purchasing entity 200 defines purchasing groups 250 and purchasing rules (i.e., a dynamic rules framework for the customer) in the EPMS via a customer interface 120 to a central database configuration 110. The purchasing entity 200 may also provide a configuration of the data format for dynamic code strings of metadata it wishes to import into its system.

[0108] Without EASI services, traditional transaction authorization inquiries / requests would be sent from the acquiring bank to the payment service provider, such as the cardholder bank, via the payment card network at the time of purchase. The inquiries would follow defined requirements and protocols, including technical verification (PAN and expiration date, CVV, PIN), operational verification (account and card status, available balance), and fraud verification (fraud rules), which correspond to the aforementioned checks regarding card data, account balance, limits, and behavior, for example. The payment service provider would respond with yes / no to the question of whether there are funds in the account for the purchase.

[0109] The EPMS and EAC add-ons trigger a second query to the EAC database in the form of a purchase authorization request sent from the transaction authorization module 405 operated by the payment service provider to the EAC database. This is a type of query that has not been previously performed according to prior art. The EASI platform runs purchase authorization control in real time against the customer's own dynamically pre-configured rule framework and receives go / no-go responses against the customer's own purchase rules. This is an EASI service that enables customers to run their own purchase rules at an individual level on each card in each transaction at the time of purchase.

[0110] Through the EASI service, customers can predefine the code strings of data fields for metadata to be posted to their economic or management system (e.g., SAP, Visma, Oracle, or Microsoft Dynamics), where the EASI service populates the metadata before, during, and after the actual purchase, according to customer requirements. The definition can be set to any desired grouping level, i.e., company, unit, group, individual, external, or similar. The EASI service automatically posts the populated metadata to the customer's economic or management system in real time, matching it to the desired, needed, or requested data according to customer preferences in each transaction, according to customer requirements. This is digitized automated data enrichment delivered by innovation.

[0111] By having purchasing management service provider EASI work with payment service providers, EASI services can be made available to all issuing banks worldwide without the need for each issuing bank to set up an EAC database. This service is globally scalable from day one through purchasing management service provider EASI, something the industry could not offer before EASI services.

[0112] EASI services can be associated with a single global card, where payment service providers add EASI services to their platform for their B2B offerings and corporate payments. Through Card as a Service (CaaS) providers such as FIS Global, Marqeta, Nexi, and others, EASI services can be easily added to existing cards, and together with economic or management system providers such as SAP, Visma, Oracle, or Microsoft Dynamics, EASI services can also be added as an option to their customer bases.

[0113] [Suitcase] To further illustrate the present invention, the following use case is provided. Purchasing entity A includes subsections Service, Development, Sales, and Administration. Through a customer interface 120 to a central database configuration 110, A defines its purchasing policies and rules and orders payment cards from its bank for all of its purchasing individuals. Some of the purchasing individuals have individual payment cards, while others have joint payment cards.

[0114] Company A defines its subsection, Service, as the Purchasing Group Service, where the same purchasing rules apply to all personnel. Since Service personnel must be able to travel extensively and on short notice to provide immediate service to malfunctioning equipment, all purchasing individuals within the Purchasing Group Service have personal payment cards, and the Purchasing Rules for the Purchasing Group Service have very few restrictions. However, Company A continuously follows up on all purchases against the Service budget and may adapt purchasing rules over time due to budgetary constraints.

[0115] Company A defines its subsection, Development, as a purchasing group, Development, with far more restrictions. Development personnel include both Company A employees and consultants. Development personnel are not permitted to make any purchases that have not been prior-approved by the Development manager. Some of the Development personnel have personal payment cards, but there are also several joint payment cards for the purchasing group, Development.

[0116] Company A defines its subsection, Sales, as two distinct purchasing groups: LocalSales and WorldwideSales. LocalSales typically does not travel abroad, and therefore, purchasing rules may be limited to domestic purchases. WorldwideSales, on the other hand, travels extensively and therefore may have far fewer restrictions in its purchasing rules. However, purchasing rules may stipulate, for example, that prior approval is required if a hotel is selected that is not on the list of hotels and hotel chains for which Company A has already negotiated rates. All sales personnel have personal payment cards.

[0117] Company A defines its subsection, Administration, as the Purchasing Group Administration. Administration personnel must be able to make small purchases of office supplies and lunches, and therefore, purchasing rules may be restricted, for example, with respect to the amount and suppliers. The Purchasing Group Administration has a joint settlement card.

[0118] When a Service employee attempts to make a purchase using a payment card, the merchant bank sends a transaction authorization request via the payment card network, for example, containing transaction authorization information as shown in Figure 6. The transaction authorization module 405 receives the transaction authorization request and performs several checks, for example, on card data, account balance, limits, and behavior. If the transaction authorization module 405 decides to approve the transaction based on these checks, it sends a purchase authorization request to the purchase authorization database 130, where transaction IDs are stored along with their linked metadata.

[0119] Since all Service employees have the same purchasing rules, the purchasing authorization database 130 may assign a purchase to the next available transaction ID in the database tagged for the purchasing group Service. In this case, the fact that a purchase relates to the purchasing group Service may be determined, for example, using the payment card number. However, a specific transaction ID may have already been selected by a Service employee, and that employee may have already added metadata linked to this transaction ID. Since the purchasing rules of Service personnel are stored as metadata linked to transaction IDs, the purchasing authorization database 130 makes decisions about a purchase authorization request by approving or rejecting it based on whether the requested purchase satisfies the Service purchasing rules. Since the Service purchasing rules have very few restrictions, most purchases are permitted. The purchasing authorization database 130 stores the transaction information as metadata linked to transaction IDs and transfers this metadata to the central database configuration 110. The central database configuration 110 then transfers the transaction information to Company A, so that the purchasing information can be automatically incorporated into Company A's economic and other management systems.

[0120] A similar flow is followed when development personnel make purchases. However, development personnel are not permitted to make any purchases that have not been pre-approved by the development manager, so pre-approval of purchases is required. Development personnel wishing to make a purchase obtain a transaction ID using a designated interface for purchasing group 250 (e.g., a web interface or mobile application) and submit the requested metadata related to this purchase to the central database configuration 110 through that interface. An action for pre-approving this purchase is then defined for the development manager. This may simply be an action defined within the system, or a reminder may be automatically sent to the manager, for example, via SMS or email. Once the development manager approves the purchase, the purchasing rule allows it.

[0121] The same flow follows when sales personnel make purchases. As with service personnel, the WorldwideSales purchasing group has very few restrictions. However, if, for example, a representation becomes a little too extravagant, it may be desirable to change the purchasing rules for individuals or groups of individuals within WorldwideSales. Then, a new purchasing group may be defined with more restrictions on the cost of representations, for example, thereby changing the previous WorldwideSales purchasing group into two groups, for example, WorldwideSalesStandard and WorldwideSalesRestricted.

[0122] A similar flow follows when administrative personnel make purchases. However, administrative personnel have much stricter purchasing rules, such as restrictions on acceptable suppliers / merchants. Transaction information transmitted from the transaction authorization module 405 also includes merchant information such as the merchant's name, or merchant category and / or a code to identify the merchant, so that the purchase authorization database 130 can compare the merchant information with acceptable merchants and / or merchant categories according to the purchasing rules. Administrative personnel may be restricted to certain suppliers / merchants, such as ICA and / or Coop, or to certain merchant types, such as grocery stores. For example, Mastercard's merchant category classification uses MCC code 5661 for "shoe stores," and Visa's merchant category classification uses MCC code 5499 for "general grocery stores - convenience stores and specialty markets." This code is included in the merchant identification code in the transaction authorization information. When administrative personnel purchase groceries at a grocery store, many different VAT levels may apply to different types of goods. Different VAT levels for different items in a purchase can then be automatically stored as metadata linked to the transaction ID to simplify management within the purchasing entity 200.

[0123] [Method Embodiments] Figure 7 schematically illustrates a purchasing control method 700 according to one or more embodiments described herein. Method 700 may include the following:

[0124] Step 710: Enter the purchasing rules to be applied to the purchasing group 250 through the customer interface 120 to the central database configuration 110, which includes data fields for linking metadata to the transaction ID.

[0125] Step 720: Add the selected purchasing group 250 as metadata linked to the first transaction ID in one or more first data fields within the central database configuration 110.

[0126] Step 725: Add the purchasing rules applicable to purchasing group 250 as metadata linked to the first transaction ID in one or more second data fields within the central database configuration 110.

[0127] Step 730: Transfer the metadata linked to the first transaction ID from the data field in the central database configuration 110 to the purchase authorization database module 130. This step is unnecessary in embodiments where the system 100 does not have a separate purchase authorization database module 130, and the central database configuration 110 communicates directly with the transaction authorization module 405 instead.

[0128] Step 740: In the transaction authorization module 405, receive the first transaction authorization request linked to the first transaction ID. The first transaction authorization request contains transaction authorization information.

[0129] Step 750: Prompt the purchase authorization request from the transaction authorization module 405 to the purchase authorization database module 130 (or directly to the central database configuration 110 in embodiments where the system 100 does not have a separate purchase authorization database module 130). The purchase authorization request is generated in the transaction authorization module 405 based on information received via the settlement card network and includes transaction information, including at least the purchase amount.

[0130] Step 760: Make a decision about the purchase approval request by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID.

[0131] Step 765: Respond to the transaction authorization module 405 by approving or rejecting the purchase authorization request.

[0132] Step 770: From the transaction authorization module 405, respond to the first transaction authorization request linked to the first transaction ID.

[0133] Step 780: Add the transaction information received from the transaction authorization module 405 to the purchase authorization database module 130 as metadata linked to the first transaction ID.

[0134] Step 785: Transfer the transaction information linked to the first transaction ID to the central database configuration 110. This step is unnecessary in embodiments where the system 100 does not have a separate purchase authorization database module 130, and therefore the central database configuration 110 communicates directly with the transaction authorization module 405 instead.

[0135] Step 790: Transfer the transaction information linked to the first transaction ID to the purchasing entity 200, thereby enabling the purchasing information to be automatically imported into at least one management system of the purchasing entity 200.

[0136] According to the present invention, the payment card number identifies the payment service provider and also identifies to the payment card network and / or payment service provider that the payment card is part of a purchasing management system. Therefore, the payment card number automatically triggers the generation of a purchase authorization request, which enables direct "hard blocking" of purchases at the time of purchase, based on purchasing rules defined by the purchasing entity.

[0137] In some embodiments, the purchase authorization database module 130 may be operated by the same entity as the central database configuration 110, and in some embodiments, it may even be part of the central database configuration 110.

[0138] In other embodiments, the purchase authorization database module 130 may be operated by a bank or other type of payment service provider (e.g., Apple, Google, Klarna, PayPal, Amazon, or Alibaba) or a transaction provider (e.g., FIS Global or Nexi).

[0139] The transaction authorization module 405 is preferably operated by a payment provider 400 that operates a payment card network (e.g., MasterCard, VISA, or American Express, etc.) and is therefore located within the payment card network. Since the payment provider 400 operates the payment card network, it has access to all transaction information transmitted within the payment card network. When the transaction authorization module 405 is operated by a payment provider 400 that operates a payment card network, checks typically performed by the payment provider 400 (e.g., those relating to card data, limits, and behavior) can be performed in the transaction authorization module 405 without even contacting the cardholder bank 500.

[0140] In this embodiment, the purchase authorization module 130 is also operated by the payment provider 400, and possibly together with the provider of the central database configuration 110. However, the purchase authorization module 130 may alternatively be operated by a third party and communicate directly with the transaction authorization module 405 in the payment card network. In either case, purchase authorization based on purchase rules may be performed between the transaction authorization module 405 and the purchase authorization module 130 without even contacting the cardholder bank 500, if desired. In this case, the cardholder bank 500 is not contacted until all checks except a final check of the account balance have been performed. However, it is also possible for the cardholder bank 500 to perform a check of the account balance before the purchase authorization module 130 performs purchase authorization based on purchase rules.

[0141] In this embodiment, the data fields in the central database configuration 110 are configurable, and input 710 also includes inputting the configuration of the metadata data format for each data field defined for the purchasing group 250.

[0142] In this embodiment, the purchasing group 250 includes at least one purchasing individual. This allows purchasing rules to be defined for and applied to one or more specific purchasing individuals, or to be defined for a subsection of a purchasing entity that includes one or more purchasing individuals.

[0143] In this embodiment, the purchasing group 250 includes all of the purchasing entities 200. This allows the purchasing entities to define general purchasing rules for all of them.

[0144] In this embodiment, the purchasing rules are general purchasing rules for a subsection of the purchasing entity 200, and adding the purchasing rules applicable to the purchasing group 250 as metadata linked to the first transaction ID in the central database configuration 110 725 involves determining which subsection the purchasing group 250 belongs to.

[0145] In the embodiment, transaction information includes, for example, merchant information such as the merchant's name, or merchant category and / or a code to identify the merchant, and the decision regarding the purchase authorization request by approving or rejecting the purchase authorization request 760 is further based on the merchant information. This allows the purchasing entity 200 to block purchases from selected suppliers / merchants and / or merchant categories, and / or to allow purchases only from selected suppliers / merchants and / or merchant categories. The purchasing entity 200 can also block purchases in a certain city, region, country, currency or similar, and / or to allow purchases only in a certain city, region, country, currency or similar.

[0146] In one embodiment, the purchasing rule specifies that certain metadata must be added in the central database configuration 110 linked to the transaction ID before a purchase is made, and the decision 760 regarding the purchase approval request includes rejecting the purchase approval request if this metadata is not present in the purchase authorization database module 130 linked to the transaction ID.

[0147] In this embodiment, transferring metadata linked to the first transaction ID from the central database configuration 110 to the purchase authorization database module 130 (730), and transferring transaction information linked to the first transaction ID to the central database configuration 110 (785), includes synchronizing the central database configuration 110 and the purchase authorization database module 130 so that they become mirror versions of each other.

[0148] In one embodiment, the central database configuration 110 is configured to communicate with a number of different parties 200, 250, 300, 500, 600, and 150, and includes adapters 205, 255, 305, 505, 605, and 155 that convert the data format used by each of these different parties into a single data format, preferably a data format defined by the purchasing entity 200.

[0149] Method 700 may further include the following:

[0150] Step 705: Transfer information from the central database configuration 110 to the payment card issuer 600, either directly or via a payment card management module 510 which may be located within the cardholder bank 500, thereby enabling the payment card issuer 600 to issue payment cards to the purchasing entity 200.

[0151] The above disclosure is not intended to limit the invention to the exact form disclosed or a particular field of use. In light of this disclosure, it is assumed that various alternative embodiments and / or modifications to the invention are possible, whether expressly described or implied herein. In this disclosure, one embodiment of the invention using a payment card has been described. However, the term “payment card” as used herein encompasses all payment means used for payments via payment card networks such as MasterCard, VISA, or American Express. This includes physical payment cards, electronic payment cards, virtual payment cards, smartphones, or other devices used with payment services such as Apple Pay, Google Pay, or Samsung Pay, and includes, for example, the use of QR, EAN, or PIN codes. Furthermore, although the described embodiments use a purchase authorization database module 130 separate from the central database configuration 110, the purchase authorization database module 130 may instead be embodied within the central database configuration 110, thereby allowing the transaction authorization module 405 to directly interact with the central database configuration 110. Accordingly, the scope of the invention is defined solely by the claims.

[0152] Furthermore, not all steps of the claim must be performed in the enumerated order. For example, purchasing rules do not need to be entered into the central database configuration 110 before the creation of a transaction ID. Moreover, if purchasing entity 200 amends a purchasing rule and enters the new purchasing rule into the central database configuration 110, the metadata associated with the purchasing rule linked to the transaction ID in the central database configuration 110 may be updated and transferred to the purchasing authorization database module 130 until the purchasing authorization request for that transaction ID is approved or rejected. In another example, transaction information may be added as metadata linked to the transaction ID either before or after the approval / rejection of the purchasing authorization request. All technically meaningful order of steps is encompassed by the claim.

Claims

1. A purchasing management system (100) comprising a central database configuration (110), a customer interface (120) to the central database configuration (110) including data fields for linking metadata to transaction IDs, and a purchasing authorization database module (130), wherein the purchasing authorization database module (130) is operated by a payment provider (400) operating a payment card network and is configured to communicate with a transaction authorization module (405) located within the payment card network. The central database configuration (110) is configured to receive purchasing rules applicable to purchasing groups (250) from purchasing entities (200) through the customer interface (120), and comprises a central processing means (115), the central processing means (115) is Adding the selected purchasing group (250) as metadata linked to the first transaction ID in one or more first data fields within the central database configuration (110); Adding the purchasing rules applicable to the purchasing group (250) as metadata linked to the first transaction ID in one or more second data fields within the central database configuration (110); and Transferring metadata linked to the first transaction ID from the data field to the purchase authorization database module (130), It is configured to do the following: The purchase authorization database module (130) is configured to receive purchase authorization requests from the transaction authorization module (405), the purchase authorization requests are generated in the transaction authorization module (405) based on information received via the payment card network, and include transaction information including at least the purchase amount, linked to the first transaction ID, wherein the purchase authorization database module (130) includes authorization processing means (135), and the authorization processing means (135) is, The purchase approval request is determined by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the purchase approval database module (130); Responding to the transaction authorization module (405) by approving or rejecting the purchase approval request; Adding the transaction information received from the transaction authorization module (405) as metadata linked to the first transaction ID in the purchase authorization database module (130); and Transferring the transaction information linked to the first transaction ID to the central database configuration (110), It is configured to perform, The central processing means (115) of the central database configuration (110) is further configured to transfer the transaction information linked to the first transaction ID to the purchasing entity (200), thereby enabling the information relating to the purchase to be automatically incorporated into at least one management system of the purchasing entity (200). Purchasing management system (100).

2. A central database configuration (110) operated by a payment provider (400) operating a payment card network and configured to communicate with a transaction authorization module (405) located within the payment card network; and A customer interface (120) to the central database configuration (110) which includes a data field for linking metadata to a transaction ID, Equipped with, The central database configuration (110) includes a central processing means (115), and the central processing means (115) is Receiving purchasing rules applicable to the purchasing group (250) from the purchasing entity (200) through the customer interface (120); Adding the selected purchasing group (250) as metadata linked to the first transaction ID in one or more first data fields within the central database configuration (110); Adding the purchasing rules applicable to the purchasing group (250) as metadata linked to the first transaction ID in one or more second data fields within the central database configuration (110); The transaction authorization module (405) receives a purchase authorization request, the purchase authorization request is generated in the transaction authorization module (405) based on information received via the payment card network, and includes transaction information, at least the purchase amount, which is linked to the first transaction ID. It is configured to do the following: The central database configuration (110) includes an authorization processing means (135), and the authorization processing means (135) is The purchase approval request is determined by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the central database configuration (110); Responding to the transaction authorization module (405) with the approval or rejection of the purchase approval request; and The transaction information received from the transaction authorization module (405) is added to the central database configuration (110) as metadata linked to the first transaction ID. It is configured to do the following: The central processing means (115) of the central database configuration (110) is further configured to transfer the transaction information linked to the first transaction ID to the purchasing entity (200), thereby enabling the information relating to the purchase to be automatically incorporated into at least one management system of the purchasing entity (200). Purchasing management system (100).

3. The system (100) according to claim 1 or 2, wherein the data fields in the central database configuration (110) are configurable, and the central database configuration (110) is configured to receive from the purchasing entity (200) a configuration of the data format of the metadata for each data field defined for the purchasing group (250).

4. The system (100) according to any one of claims 1 to 3, wherein the purchasing rule is a purchasing rule that applies to a purchasing group (250) including at least one individual purchaser.

5. The system (100) according to any one of claims 1 to 4, wherein the purchasing rule is a purchasing rule that applies to a purchasing group (250) including the entire purchasing entity (200).

6. The system (100) according to any one of claims 1 to 4, wherein the purchasing rule is a general purchasing rule for a subsection of the purchasing entity (200), and the central processing means (115) of the central database configuration (110) is configured to add the purchasing rule applicable to the purchasing group (250) as metadata linked to the first transaction ID in the central database configuration (110) based on a determination of which subsection the purchasing group (250) belongs to.

7. The system (100) according to any one of claims 1 to 6, wherein the transaction information includes merchant information, and the authorization processing means (135) is configured to make decisions regarding the purchase authorization request by approving or rejecting the purchase authorization request based on the merchant information.

8. The system (100) according to any one of claims 1 to 7, wherein the purchasing rule specifies that certain metadata must be added in the central database configuration (110) linked to the transaction ID before the purchase is made, and the authorization processing means (135) is configured to reject the purchase authorization request if the metadata is not present in the central database configuration (110) linked to the transaction ID.

9. The system (100) according to any one of claims 1 to 8, wherein the central database configuration (110) is configured to communicate with a plurality of different parties (200, 250, 300, 500, 600, 150), and includes adapters (205, 255, 305, 505, 605, 155) that convert the data format used by each of these different parties (200, 250, 300, 500, 600, 150) into a single data format, preferably a data format defined by the purchasing entity (200).

10. The step involves inputting (710) purchasing rules to be applied to a purchasing group (250) through a customer interface (120) to a central database configuration (110) that includes data fields for linking metadata to a transaction ID; The step of adding (720) the selected purchasing group (250) as metadata linked to the first transaction ID in one or more first data fields within the central database configuration (110); The step of adding (725) the purchasing rules applicable to the purchasing group (250) as metadata linked to the first transaction ID in one or more second data fields within the central database configuration (110); The step of transferring (730) the metadata linked to the first transaction ID from the data field in the central database configuration (110) to the purchase authorization database module (130); In a transaction authorization module (405) operated by a payment provider operating a payment card network and therefore located within the payment card network, the first transaction authorization request linked to the first transaction ID is received (740), the first transaction authorization request includes transaction authorization information; In the step of transmitting a purchase authorization request (750) from the transaction authorization module (405) to the purchase authorization database module (130), the purchase authorization request is generated in the transaction authorization module (405) based on information received via the payment card network and includes transaction information including at least the purchase amount; A step in which the purchase approval request is determined (760) by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the purchase approval database module (130); The step of responding (765) to the transaction authorization module (405) with the approval or rejection of the purchase approval request; The transaction authorization module (405) responds (770) to the first transaction authorization request linked to the first transaction ID; The step of adding (780) the transaction information received from the transaction authorization module (405) as metadata linked to the first transaction ID in the purchase authorization database module (130); The step of transferring (785) the transaction information linked to the first transaction ID to the central database configuration (110); and The step of transferring (790) the transaction information linked to the first transaction ID to the purchasing entity (200), thereby enabling the information relating to the purchase to be automatically incorporated into at least one management system of the purchasing entity (200), A purchasing management method (700) comprising the following:

11. The step involves inputting (710) purchasing rules to be applied to a purchasing group (250) through a customer interface (120) to a central database configuration (110) that includes data fields for linking metadata to a transaction ID; The step of adding (720) the selected purchasing group (250) as metadata linked to the first transaction ID in one or more first data fields within the central database configuration (110); The step of adding (725) the purchasing rules applicable to the purchasing group (250) as metadata linked to the first transaction ID in one or more second data fields within the central database configuration (110); In a transaction authorization module (405) operated by a payment provider operating a payment card network and therefore located within the payment card network, the first transaction authorization request linked to the first transaction ID is received (740), the first transaction authorization request includes transaction authorization information; In the step of transmitting (750) a purchase authorization request from the transaction authorization module (405) to the central database configuration (110), the purchase authorization request is generated in the transaction authorization module (405) based on information received via the payment card network and includes transaction information including at least the purchase amount; A step in which a decision is made (760) regarding the purchase approval request by approving or rejecting the purchase approval request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID in the central database configuration (110); The step of responding (765) to the transaction authorization module (405) with the approval or rejection of the purchase approval request; The transaction authorization module (405) responds (770) to the first transaction authorization request linked to the first transaction ID; The step of adding (780) the transaction information received from the transaction authorization module (405) as metadata linked to the first transaction ID in the central database configuration (110); and, The step of transferring (790) the transaction information linked to the first transaction ID to the purchasing entity (200), thereby enabling the information relating to the purchase to be automatically incorporated into at least one management system of the purchasing entity (200), A purchasing management method (700) comprising the following:

12. The method according to claim 10 or 11 (700), wherein the data fields in the central database configuration (110) are configurable, and the input step also includes inputting a configuration of the data format of the metadata for each data field defined for the purchasing group (250).

13. The method according to any one of claims 10 to 12, wherein the purchasing group (250) includes at least one purchasing individual.

14. The method (700) according to any one of claims 10 to 13, wherein the purchasing group (250) includes the entire purchasing entity (200).

15. The method (700) according to any one of claims 10 to 13, wherein the purchasing rule is a general purchasing rule for a subsection of the purchasing entity (200), and the step of adding the purchasing rule applicable to the purchasing group (250) as metadata linked to the first transaction ID in the central database configuration (110) is a step of determining which subsection the purchasing group (250) belongs to.

16. The method according to any one of claims 10 to 15 (700), wherein the transaction information includes merchant information, and the step of making the decision (760) regarding the purchase approval request by approving or rejecting the purchase approval request is further based on the merchant information.

17. The method (700) according to any one of claims 10 to 16, wherein the purchasing rule specifies that certain metadata must be added in the central database configuration (110) linked to the transaction ID before the purchase is made, and the step of making the decision (760) regarding the purchase approval request includes a step of rejecting the purchase approval request if the metadata does not exist in the central database configuration (110) linked to the transaction ID.

18. The method (700) according to any one of claims 10 to 17, wherein the central database configuration is configured to communicate with a plurality of different parties (200, 250, 300, 500, 600, 150), and includes adapters (205, 255, 305, 505, 605, 155) that convert the data format used by each of these different parties (200, 250, 300, 500, 600, 150) into a single data format, preferably a data format defined by the purchasing entity (200).

Images