Technical Field

[0001] Various embodiments generally relate to systems, methods and computer- readable media, for managing entity user data.

Background

[0002] Businesses rely on a complex ecosystem of technology, processes and Enterprise Resource Planning (ERP) systems to manage their invoices and to make and receive payments nearly every day. The number of electronic payment transactions processed every day continues to grow with the increasing number of entities engaging in financial transactions. Almost all ERP systems in the world today are created in silos. While the biggest companies are easily and uniquely identified, the smaller companies such as the buyers and/or suppliers exist as duplicate entities across these ERP systems. These duplicate entities continue to exist even at a time of tighter integration of one or more ERP systems across multiple companies. As a result, transactions that occurred across these duplicate entities continue to be recorded separately and this anomaly further adds inefficiencies and distortion on data analytic efforts performed on these transactions. These duplicate entities certainly present another set of challenges when they are recorded through different systems into a blockchain ledger.

[0003] Existing enterprise applications have focused on streamlining internal processes without incorporating external data from suppliers and markets. With the recent development of private and public online marketplaces, which generate a wealth of potentially useful external data, it has been discovered that enterprise applications now have the opportunity to access critical external data from these sources and integrate this data with the internal data of enterprise systems. Unfortunately, internal supply chain data from a variety of custom databases and Enterprise Resource Planning (ERP) applications has remained fragmented across multiple systems, and the relevant external data are frequently dispersed and difficult to access. Thus, existing applications currently do not have the tools to access or integrate external data with internal data. Currently, many different types of entity resolution methodologies exist but all rely on the process known as identify and deduplication process that are performed way after the creation of such entities in the downstream systems. Accordingly, it would be desirable to address some of the problems highlighted above.

Summary of the Invention

[0004] Throughout this document, unless otherwise indicated to the contrary, the terms “comprising”, “consisting of’, and the like, are to be construed as non-exhaustive, or in other words, as meaning “including, but not limited to”.

[0005] In accordance with a first embodiment of the invention, there is provided an account management platform for connecting an entity user and a new user on the platform comprising: one or more processors; a memory device coupled to the one or more processors; the account management platform stored in the memory device and configured to be executed by the one or more processors, the account management platform comprising instructions for: receiving, by an access module, a request for access to the account management platform; determining, by the access module, whether the request is made by the entity user associated with a first ERP platform or the new user associated with a second ERP platform, wherein the first ERP platform and the second ERP platform are incompatible with each other; sending an invitation to the new user if the access module determines that the request is made by the new user; receiving, by the access module, a request from the new user to access the account management platform; receiving, by the access module, entity profile data including at least an identifying information, determining, by the access module, whether the entity profile data corresponds with an entity profile data criteria, storing the entity profde data in the memory device of the processor, wherein each entity profile includes at least an identifying information; creating a new entity user account based on the entity profile data and sending an authentication credential to the new entity user; generating, by the processing server, a hash value for the entity profile data and; storing, in the memory of the processing server, the generated hash value in a digital ledger.

[0006] Preferably, the step of determining whether the entity profile data corresponds with the entity profile data criteria comprises comparing the entity profile data with the entity profile data stored in the memory of the processors.

[0007] Preferably, the hash value is generated via the application of one or more hashing algorithms to the identifying information.

[0008] Preferably, the identifying information comprises at least one or more of the following attributes: an entity name, identification number, Unique Entity Number (UEN), street address, telephone number.

[0009] Preferably, the authentication credential including at least a user id and password for accessing the platform.

[0010] Preferably, the entity profile data criteria comprises the identifying information associated with the entity profile registered with a government authority.

[0011] Prefeably, the step of determining whether the entity profile data corresponds with the entity profile data criteria further includes comparing the identifying information associated with the entity profile data with the identifying information associated with the entity profile registered with a government authority.

[0012] In accordance with a second embodiment of the invention, there is provided an account management system for connecting an entity user and a new user on the system, implemented as machine executable instructions stored on a set of at least one non-transitory computer readable medium, each operatively connected to an associated processor, the system comprising: an access module configured for granting access to the system to the entity user associated with a first ERP platform and the new user associated with a second ERP platform, wherein the first ERP platform and the second ERP platform are incompatible with each other; a data integration module configured to receive master data from the access module, the master data being associated with a first entity profile data associated with the entity user or a second entity profile data associated with the new user, wherein the data integration module is configured to translate the master data into a translated data such that the translated data is compatible with the first ERP platform and the second ERP platform; and a digital ledger configured to store the master data into a memory of the processor.

[0013] Preferably, the translated data comprises a first translated entity profile data associated with the entity user and a second translated entity profile data associated with the new user.

[0014] Preferably, the first entity profile data associated with the entity user comprises identifying information.

[0015] Preferably, the second entity profile data associated with the new user comprises identifying information.

[0016] Preferably, the identifying information comprises at least one or more of the following attributes: an entity name, identification number, Unique Entity Number (UEN), street address, telephone number.

[0017] Preferably, the master data stored in the digital ledger comprises a first hash value based on the first entity profile data associated with the entity user and a second hash value based on the second entity profile data associated with the new user.

[0018] Preferably, the system further comprises an order to cash module configured to receive payment for fulfilment of an order for an entity user. [0019] Preferably, the translated data facilitates supply chain management transactions between the entity user and the new user.

[0020] Preferably, the digital leger is a blockchain.

[0021] Preferably, the system further comprises an identity and access management module configured to delegate roles and responsibilities to the entity user and the new user.

[0022] Preferably, the master data further comprises any one or more of the following: purchase requisition data, purchase orders, invoices, transaction data.

Brief Description of the Drawings

[0023] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. The dimensions of the various features or elements may be arbitrarily expanded or reduced for clarity. In the following description, various embodiments of the invention are described with reference to the following drawings, in which:

[0024] FIG. 1 illustrates a high-level block diagram of a typical system architecture of Enterprise Resource Planning (ERP) Systems;

[0025] FIG. 2 is a block diagram illustrating a high-level system architecture for an account management platform according to various embodiments;

[0026] FIG. 3 is a block diagram illustrating a processing server of the account management platform according to various embodiments;

[0027] FIG. 4 is a flow diagram illustrating an example process for providing access management to the account management platform for the registration and configuration of a new user; [0028] FIG. 5 is a flow diagram illustrating an example process for inviting a new user to the account management platform through an entity user who wishes to transact with the new user; and

[0029] FIG. 6 is a flow diagram illustrating a process for registration of a Purchase Order according to various embodiments.

Detailed Description

[0030] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the invention. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0031] In this context, the system and method as described in this description may include a memory which is for example used in the processing carried out in the image processing device. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

[0032] In the specification the term “comprising” shall be understood to have a broad meaning similar to the term “including” and will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps. This definition also applies to variations on the term “comprising” such as “comprise” and “comprises”. [0033] In order that the invention may be readily understood and put into practical effect, particular embodiments will now be described by way of examples and not limitations, and with reference to the figures. It will be understood that any property described herein for a specific system may also hold for any system described herein. It will be understood that any property described herein for a specific method may also hold for any method described herein. Furthermore, it will be understood that for any system or method described herein, not necessarily all the components or steps described must be enclosed in the system or method, but only some (but not all) components or steps may be enclosed.

[0034] The term “coupled” (or “connected”) herein may be understood as electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

[0035] The terms module, layer, and application are used interchangeably herein.

[0036] To achieve the stated features, advantages and objects, a system and method of an embodiment of the invention makes use of computer hardware and software to provide entities with an account management platform that allows entities that are tied to different B2B solution providers or platforms, to connect and associate with another for the purpose of recording, transacting and settling payments and transactions. FIG. 1 shows a typical high-level system architecture of current ERP systems used by entities for payment transactions between entities. For example, a company ABC buys goods and/or services from companies 123 and 1011. Companies 123 and 1011 will be recorded and created in company ABC’s ERP system. At the same time, company 456 also buys from companies ABC, 123, and XYZ. The entity profiles of companies ABC, 123, and XYZ again exists as entities in company 456’ s ERP system. Any attempt to integrate between these companies (ABC with 456, or 123 with 456) will be plagued with identity discrepancies and/or duplications. In the sections below, we will define our solutions. Identify discrepancies and/or duplications refer to one entity (for example, a seller/vendor) having to maintain a different login account provided by another entity (for example, a buyer). Each entity can be utilizing different systems/ERPs to get into each of these systems to respond to the purchased orders sent to it. The seller/vendor will need to synchronize all these disparate transactions across different buyers and/or systems.

[0037] By using the account management platform, different entities, both purchasers and suppliers to one another, can connect and associate with one another through the account management platform. This provides the advantage of various entities, both purchasers and suppliers, to use only one account management platform that can perform entity resolution. This solves a business process problem and increase productivity. Current systems focus on deduplication process to establish a single entity. This process is highly complicated and often times fail at resolution. The present invention attacks the issue at the earliest source of data creation and ensures a unique global entity profile at the very start of community creation. The present invention also provides the advantage of having a proof of truth that is pushed to a Blockchain.

[0038] Various embodiments are provided for systems, and various embodiments are provided for methods. It will be understood that basic properties of the systems also hold for the methods and vice versa. Therefore, for sake of brevity, duplicate description of such properties may be omitted.

[0039] FIG. 2 illustrates a system 100 for managing entity accounts managed by one or more administrators to a plurality of entities that may provide services for one or more entities and its users. The system 100 includes a processing server 101. The processing server 101, discussed in more detail below, may be configured to operate an account management platform. The account management platform may be a platform designed to provide a plurality of different services to various entities. Such services may include allowing different entities to transact with one another, regardless of different B2B solution providers used by the entities, registration of procurement status for purchase orders, or processing or recording business-to-business (B2B) payments and transactions, or different ERP systems.

[0040] In the system 100, the processing server 101 may be configured to utilize data related to the services provided on the account management platform. The data may be stored locally in the processing server 101 and/or externally, such as in a data warehouse 110. A data warehouse 110 may be an external server, server farm, cloud storage, or other mechanism used for the external storage of data that may be accessed by the processing server or other computer system through a suitable form of communication. For example, the processing server 101 may utilize cloud storage of the data warehouse that is accessed via the internet. In some cases, the data warehouse may be managed, operated, and/or owned by the same entity that manages, operates, and/or owns the processing server. In other cases, the data warehouse may be managed, operated and/or owned by a third party.

[0041] The system 100 may include at least one platform administrator 120. The platform administrator 120 may be an authorized user of the account management platform that is configured to perform administrative functions on the account management platform, including the creation and management of entities, users, and permission, the addition and modification of other data, the creation and management of digital ledgers, etc.. The platform administrator 120 may be an employee of the entity that owns and/or operates the processing server 101. The platform administrator 120 may access the account management platform using a suitable computing device, such as a desktop computer, laptop, notebook computer, tablet computer, smartphone, etc. The processing server may have a user interface that is accessible via a computing device, such as a web page, application program, or application programming interface, etc., which may be used to access functions provided by the account management platform.

[0042] Entity Users 130,140 or a new user 150 may access the account management platform, which will be explained hereinafter. An entity user 130, 140 may be a business, company, individual, etc., which currently use the account management platform to avail itself of one or more services. In some cases, a new user 150 user may be created in the account management platform at the request of an entity user. For example, an entity user that is already registered on the platform and uses the account management platform may be a supplier of goods or services. When a new user 150 or a buyer that is not registered on the platform enters into an agreement to buy goods from the entity user 130, the entity user may (for example, directly or through the platform administrator) have the new user 150 or buyer added to the account management platform. For example, this can be done by requesting the platform administrator to send an email to the new user 150 to register itself as an entity user with the account management platform.

[0043] FIG. 3 shows a block diagram illustrating an embodiment of an account management platform 200 on a processing server. The account management platform 200 includes an access module 205, a data integration layer 201, an Identity and Access Management layer 202 that are configured to receive data from entity users 130, 140 or new users 150-180 over one or more data communications network (not shown). As explained previously, the account management platform may include a data warehousellO which may include one or more databases to store user entity data and transaction data, or other data.

[0044] The access module 205 allows entity users 130, 140 and new users 150-180 to gain access or to set up their respective accounts in the account management platform 200. For example, the access module 205 may include registration or account setup procedures to create a new account for a new user 150-180 on the account management platform 200. The access module 205 may also include authentication procedures (for example a login ID and a password) to determine the identity of the user or entity and the entity’s profile (for example, the associated organization or company, level of access, etc.) before granting access to the platform. Once the new user 150-180 has been granted access to the platform, the status of the new user 150 becomes that of an entity user 130, 140 and the new user may configure the account for customized access. For example, if the new user is a supplier, the supplier may create or update the supplier account or provide updated product or service information.

[0045] In general, the entity user 130, 140 gains access to the account management platform through the access module 205. The access module 205 may include security measures, such as authentication (for example, providing user ID and password), to identify the user by accessing the entity profile data stored in the data warehouse 110. User accounts may also be created through the access module 205. The system administrator may provide access to the entity user via emailing a registration link to the access module 205. Once an account has been created, the entity user may access the account management platform through the access module 205.

[0046] The account management platform 200 may have a plurality of entity users 130, 140 registered on the account management platform. When a new user 150-180 sets up an account on the account management platform, it will have to provide identifying information which will be stored as an entity profile. The entity profile may be a set of information or data that is unique to a related entity user and/or entity profile. The data elements of the entity profile are called attributes. For example, an entity profile may store the following attributes: a name of an entity, identification number, Unique Entity Number (UEN), street address, telephone number, or a combination of data values that when combined, is unique to the entity. The platform administrator 120 may verify the identifying information of the entity profile. For example, such verification may be done by identifying records associated with the entity, such as incorporation records registered with a governmental jurisdiction and compare such records with proof provided by each entity. Once such information is verified, the platform administrator proceeds to generate a set of authentication credentials such as a username or password to the entity. The services provided by the account management platform may then be accessed by the entity users.

[0047] The account management platform 200 includes a data integration layer 201 which may be configured to receive data received by the access module 205. The data may include entity profile data or other data from data warehouses, platform administrators, entity users, external entity data sources, data providers, or other systems via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, Internet or the like. In some instances, the data integration layer may receive electronically transmitted data signals, where data may be superimposed or otherwise encoded on the data signal and decoded, parsed, read or otherwise obtained via receipt of the data signal by the data integration layer. In some embodiments, the data integration layer includes extract modules, transform modules and load modules (not shown). The data integration layer performs the extract and transform functions of the ETL (i.e. Extract, Transform, Load) process, respectively. The extraction process of the data integration layer is preferably initiated by the load module, by the extract module. For example, the data integration layer may initiate the process of calling for retrieval of a master data from an external entity data source. In some embodiments, the external entity data source may be from a ERP system of an external entity that is incompatible with the ERP systems of the entity users. It should be noted that, in accordance with preferred embodiments, the extract, transform and load modules preferably function as integrated ETL tools. The data integration layer ensures that different or incompatible systems will be able to work with the account management platform 200 as the data integration layer ensures that all data transmitted and/or received between any third party system will work with the account management platform 200. The extract modules, transform modules and load modules within the data integration layer provides the translation of master data to ensure interoperability between these incompatible systems and the account management platform.

[0048] The account management platform 200 may interface with the processing server 100 via a communication network. A central processing unit or processor (not shown) executes instructions contained in the account management platform 200, stored in storage devices (not shown). A processor may provide the central processing unit (CPU) functions of a computing device on one or more integrated circuits. As used herein, the term ‘processor’ broadly refers to and is not limited to single or multi-core general purpose processor, a special purpose processor, a conventional processor, a graphical processing unit, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit, a system on a chip (SOC), and/or a state machine.

[0049] As used herein, entity users and external entity data sources may exchange information via any data communications network, such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, and/or Internet Protocol (IP) network such as the Internet, an Intranet or an extranet. Each device, module or component within the system may be connected over a network or may be directly connected. A person skilled in the art will recognize that the terms ‘network’, ‘computer network’ and ‘online’ may be used interchangeably and do not imply a particular network embodiment. In general, any type of network may be used to implement the online or computer networked embodiment of the present invention. The network may be maintained by a server or a combination of servers or the network may be serverless. Additionally, any type of protocol (for example, HTTP, FTP, ICMP, UDP, WAP, SIP, H.323, NDMP, TCP/IP) may be used to communicate across the network. The devices as described herein may communicate via one or more such communication networks.

[0050] In some embodiments, the account management platform may be configured to maintain a digital ledger for storage of entity user data. In some embodiments, a single digital ledger may be used to store all data associated with the entity user. For example, one digital ledger may be used to store all data for all entities of the account management platform, where the unique identifier for an entity may be used to identify data values associated with that entity. In some embodiments, each entity may have a separate digital ledger. The account management platform may be configured to generate data values for user data. [0051] In some embodiments, the digital ledger used to store entity user data may be a blockchain configured to store the associated data. A blockchain may comprise a plurality of blocks, wherein each block comprises at least a block header and one or more data values. Each block header may include a timestamp as well as a reference value referring to the block header of the previous block added to the blockchain and a reference value referring to the one or more data values included in the respective block. In some embodiments, the reference value may be a hash value generated via the application of one or more hashing algorithms to the respective data. For instance, the reference value to a previous block header may be a hash value generated via hashing of the block header of the previous block. As such, the blockchain may be immutable, as a change in any data value would result in a change to the has value included in the respective block’s block header, also resulting in a change in the hash value of the subsequent block’s block header, which would carry through the remaining blocks in the blockchain, thus preventing modification to any data values or data in the blockchain. In the accounting management platform 200, the data values may include entity profiles, purchase requisitions, purchase orders, invoices, transaction data, and other data stored in the ledger as discussed herein.

[0052] The account management platform includes an Identity and Access Management layer. The Identity and Access Management layer comprises an identity management module (not shown) and an access management module (not shown). The account management platform couples the identity management and access management modules by facilitating delegation of roles and rights, and providing workflow-enabled management of end user entity profiles. The identity management module of the layer manages end user entity user profiles, while the access management module manages access to resources or to various modules within the account management platform. The access management module also provides means for defining and managing authentication and authorization policies for the various modules. The Identity and Access Management layer comprises the aforesaid modules that define the entity profiles and the assets the entity profiles have access to. It is part of a security protocol to define Access Policy and control. In some embodiments, the Identity and Access Management layer includes means for providing and managing entity profiles, and means for defining and managing authentication and authorization policies. In one embodiment, entity profiles and authentication or authorization information is administered through administrative users. Administrative users are assigned administration rights, thus conferring to them the rights and responsibilities of managing policy and entity profiles for specific modules. Although the Identity and Access Management layer is shown as a single layer on Fig. 3, in some embodiments, the account management platform may only include an identity management module or an access management module that are separate modules. However, the functions of each of the identity management module and the access management module, if existing as separate modules, are as described above.

[0053] The account management platform includes various modules for entity users to access the various modules to perform supply chain management functions. For example, the account management platform may include, but is not limited to, a financing module 212, a procure-to-pay module, an order to cash module and a mobile application module. The aforesaid modules facilitate transactions between multiple buyers and suppliers. The financing module 212 provides financing functions for entity users. This allows entity users (for example, suppliers or vendors) to have access to financing resources provided by external partner funders who may or may not be entity users. The entity users may also access a procure-to-pay module 210. The procure-to-pay module 210 provides procurement functions that ensures the traceability and improved productivity by automating some of the time-consuming procurement process and workflow. The order to cash module 214 provides functions to the entity users to process purchase orders to receiving payment for the fulfillment of the order for the vendor/seller. The mobile application module allows some of the workflow on the platform to be available with a mobile app such as to allow entity users the ability to view outstanding invoices or approving a purchase requests through a mobile app in order to increase productivity. [0054] FIG. 4 is a flow diagram illustrating an example process for providing access management to the account management platform for the registration and configuration of a new user. At step 510, a new user may receive an invitation via email, on their computing device, to open an account with the account management platform. The new user will be brought to a suitable interface or the access module of the account management platform 200, via the suitable interface over a data communication network. The access module will request for the new user to provide identifying information of its entity. The identifying information provided by the new user is stored as entity profile data and may include name of entity, Unique Entity Number (UEN), entity address, telephone number, contact information, or combination of data values that when combined, is unique to the entity. The access module may also request for proof of identity of the new user, such as proof of entity address. At step 530, the access module processes the entity profile data provided by the new user and assesses if the entity profile data is unique. The access module may have an entity administrator 120 that processes the entity profile data and determines if the entity profile data is unique. For example, the access module may compare the entity profile with existing entity profile data within the data warehouse or with external entity data sources. If the entity profile data is deemed to be unique, at step 540, the access module accepts the request and proceeds to create an entity user account for the new user at step 550. The access module may generate a set of authentication credentials, such as user name and password, and assign them to the new user. In the event that the access module determines that there is a similar entity profile data that exists within the data warehouse or from external data sources and there are some differences, the access module may proceed to inform the new user of the differences and to seek confirmation from the new user on the difference. For example, the access module may identify records associated with the new user, such as incorporation records registered with a government organization and compare such records with proof provided by the entity. If the new user confirms that its entity profile data is incorrect, the access module proceeds to update the entity profile data with the updated entity profile data at step 536. If the entity profile data is not deemed to be unique, the access module proceeds to reject the new user and to end the process at step 535.

[0055] Once the entity user account is created, and at step 560, the entity profile data associated with the new user may be stored in a database and/or a digital ledger. A digital ledger may be a data file that is configured to store data that may be access by the account management platform (either locally or via data warehouse). In some embodiments, the digital ledger may be rewritable, such that data stored in the digital ledger may be modified. In other embodiments, data stored in the digital ledger may be immutable, such as data stored in a blockchain ledger. At step 570, the access module proceeds to send a confirmation email to the new user with the authentication credentials.

[0056] FIG. 5 is a flow diagram illustrating an example process for inviting a new user to the account management platform through an entity user who wishes to transact with the new user. The process flow is similar to the process as exemplified by the process of FIG. 4. An entity user that is currently a user of the account management platform may wish to transact with a new business partner. For example, the entity user may be a buyer, and wishes to purchase new equipment from a supplier. The entity user may send a connection request, at step 610, to the new business partner through the user interface of the account management platform. At step 620, the access module will determine if the new business partner is an entity user of the account management platform. If the new partner is not an entity user, at step 630, the access module request the entity user to provide an email contact address of the new partner, and proceeds to send an invitation email to the new partner to join the account management platform. If the new business partner accepts the invitation and connects with the account management platform, this will kickstart the new user registration process at step 510 as shown in FIG. 4.

[0057] If the new business partner is already an entity user of the account management platform, at step 640, the access module will process the request by the existing entity user that wishes to transact with the new business partner according to the specific type of supply chain transactions as requested. Once the access module accepts the request, the entity user proceeds to access the various modules within the platform that will seek to connect with the other entity user. The transaction data that is transacted between the first entity user (for example, the buyer) and the second entity user (for example, the supplier) will be updated and stored in the database and a digital ledger. In some embodiments, the digital ledger may be the same ledger used to store the entity profile data. In some embodiments, the transaction data may be stored directly in the ledger. In some embodiments, the platform may generate a hash value of the specific transaction data, which may be stored in the digital ledger in place of the actual transaction data. The hash value may be generated by applying one or more hashing algorithms to the formatted transaction data or data associated therewith, such as the identification number and a timestamp of the approval time of the transaction data. The approved and formatted transaction data may be stored in an immutable format in the digital ledger. This provides auditability of the transaction data by each of the entities, since the hash value is unique and any modification made to the transaction data would result in a different hash value, thereby enabling each entity to prove the transaction as it was approved at the time of the approval.

[0058] FIG. 6 is a flow diagram illustrating a process for registration of a Purchase Order according to various embodiments. When an entity user accesses the account management platform to perform transactions, the entity user may be using an Enterprise Resource Planning (ERP) system that is incompatible with the account management platform. The account management platform ensures that regardless of the ERP system that the entity user is utilizing, the account management platform will be able to extract the data from an incompatible ERP system and to utilize the data in the the account management platform. For example, in step 400, an entity user may access the account management platform and master data from an external entity data source of the entity user can be extracted by the account management platform when the entity user performs a transaction or request on the account management platform. The master data may be entity profile data such as the following: name of an entity, identification number, Unique Entity Number (UEN), tax code, street address, telephone number, or a combination of data values that when combined, is unique to the entity. The master data is usually present and maintained in the entity user’s ERP and/or accounting system.

[0059] The data integration layer 201 may be configured to receive master data received by the access module 205. As mentioned previously, the master data may include entity profile data from external entity data sources of the entity user and is received by the access module 205 via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, Internet or the like. In some embodiments, the data integration layer includes extract modules, transform modules and load modules (not shown). The data integration layer performs the extract and transform functions of the ETL (i.e. Extract, Transform, Load) process, respectively. The extraction process of the data integration layer is preferably initiated by the load module, by the extract module. For example, the data integration layer may initiate the process of calling for retrieval of master data from the external entity data source of the entity user. In some embodiments, the external entity data source may be from an ERP system of an entity user that is incompatible with the ERP systems of other entity users. It should be noted that, in accordance with preferred embodiments, the extract, transform and load modules preferably function as integrated ETL tools. The data integration layer ensures that different or incompatible systems will be able to work with the account management platform 200 as the data integration layer ensures that all master data transmitted and/or received between any third party system will work with the account management platform 200. At step 410, the extract module, transform module and load module within the data integration layer translates the master data to the account management platform to ensure interoperability between incompatible systems and the account management platform.

[0060] The data integration layer 201 ensures that there is no duplicate data entry and no duplicate data created on the account management platform 200. At Step 420, the translated master data is used by the account management platform to raise a purchase requisition request by the entity user at step 430. If authorization is required, the procurement module notifies the designated authorizing entity of the requisition to obtain approval or authorization at step 440. If the purchase requisition is denied, the procurement module sends a notification back to the entity user of the decision. If the requisition is approved, the entity user is notified and the purchase requisition is converted into a purchase order at step 460. The purchase order is sent to the entity user at step 460 via the data integration layer at step 470 in the proper format designated by the entity user for sending to the appropriate supplier. At step 470, the data integration layer ensure that the master data contained in the purchase order continues to be maintained in the system of origin or the external entity data source of the entity user for as long as the entity user uses the external entity data source. Steps 460-480 shows master data being sent back to the external entity data source of the entity user to allow the consistency of data at the external entity data source. Figure 6 depicts the integration between an external entity data source such as an external ERP system that integrates with the account management platform. As mentioned earlier, the master data is maintained in the external entity data source and thus it shows the direction of the integration being from the external entity data source to the account management platform. Steps 460-480 shows that the issuance of Purchase Order being done at the account management platform and the Purchase Order sent back to the external entity data source so that the master data between the two systems are synchronized in order to continue to function properly.

[0061] While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.