WO2020174440A1

WO2020174440A1 - Transaction data processing and document and data management method and system

Info

Publication number: WO2020174440A1
Application number: PCT/IB2020/051689
Authority: WO
Inventors: Natalie Killassy; Kirstie Clare KILLASSY
Original assignee: Sixth Cent (Pty) Ltd
Priority date: 2019-02-27
Filing date: 2020-02-27
Publication date: 2020-09-03
Also published as: ZA202107403B

Abstract

The invention relates, in a first aspect, to a method of processing transaction data which includes defining an original set of rules to interpret data from a plurality of current transaction data sources to, by means of an original set of reports, reflect aspects of data from the current transaction data sources; and to create modified sets of rules which are used to process, in parallel with the original set or rules, the transaction data, including historical transaction data, to create for each of the applied sets of rules an associated set of reports; to select and define an updated current set of rules with an associated updated current set of reports.

Description

TRANSACTION DATA PROCESSING AND DOCUMENT AND DATA MANAGEMENT

METHOD AND SYSTEM

FIELD OF THE INVENTION

This invention relates to a method and system for processing transaction data and managing documents and data, enabling people to more easily, more flexibly and more accurately transact and to guide them to making informed decisions and taking appropriate actions based on this.

BACKGROUND TO THE INVENTION

Conventional data processing and data management systems rely on the use of data sourced from various sources and on interpreting, to various degrees, such data at various time intervals. A major part of such data processing and management systems is the interpretation of financial data, which is traditionally obtained from conventional accounting systems.

Conventional accounting systems rely, in part, on importing bank account statements followed by a manual process of allocating transactions to accounts in the general ledger of the accounting system. Transactions sourced from other source documents are similarly categorised and recorded in these accounting records.

This is a tedious manual process. The frequency with which this is done depends on a business’ operational requirements and its transaction volume.

An inherent structural limitation with such accounting systems is their necessary rigidity. Accounting systems have to rigid to be reliable. Any deviation from such conventional rigidity is viewed as an exception which has to be justified to the company’s auditor, at least once a year with an annual audit.

Exceptions from this rigidity are typically viewed with suspicion and increase the costs of an audit. Too many exceptions may lead to a qualified audit, which is detrimental for the business. In respect of such changes, by way of example, if a business manager wishes to view data of fuel purchases by sales staff on city level but the company’s accounting system has already been setup to allocate fuel purchase transactions on a national or provincial level, then the information obtainable from the company’s accounting system won’t be able to answer the manager’s query. To view the information in the accounting system itself in this manner, the general ledger setup of the accounting system has to be changed. This includes the addition of new accounts reflecting the various cities in which the company’s sales staff is active and closing of the old national or provisional fuel accounts, or making them group-accounts under which the new city-accounts all fall as sub-accounts. Only once the new accounts have been set up can transactions be allocated to them. Accounts from previous years, for which the books of accounting have already been closed cannot be changed anymore.

To view the historical data therefore requires a separate and extremely tedious process of manually allocating transactions to reflect the data the business manager now wishes to see.

This is a type of change in an accounting system that is ideally not done often, and ideally only at the commencement of a new financial year. This means if the business manager decides to make this change at any time during (and not at the start of) a financial year, the change to the accounting system most likely has to wait until the end of the financial year. In the interim, someone in the finance department will have to manually produce the information the manager wishes to view.

A further complication stemming from the manner in which conventional accounting systems function is that accounting, and more accurately the reporting on the accounted transactions, is typically done on a monthly basis. Transactions are allocated for an entire month, after which the books of account are closed for the month and monthly reports are produced. Based on these monthly reports financial and business decisions are then taken.

This becomes monthly exercise, which inherently means financial and business decisions are taken with dated information, which may be up to a month old. Even in systems where information is processed more regularly, the nature of the process of accounting for data from bank statements and reconciling the relevant accounts (in the accounting system) with such bank statements dictates that the results will never be live, and in most instances will at least be several days old. This delay the process of updating financial data to, for example, sales teams. In an era where so much information is always available and updates to it are available live, or very near to live, the systems and methods used for the allocation of transactions is not optimised.

By way of further example, a company may be in the business of manufacturing and selling widgets to retailers. The widgets are manufactured from raw materials which must be ordered from suppliers located in several other countries. The ordering of each raw material has an associated lead time and associated payment terms from its supplier. The manufacture of the product also has an internal lead time, which is affected by the availability of the various required raw materials for its manufacture, and production that may already be scheduled.

When the company’s sales team makes a sale and accepts an order, it has to have relevant and accurate information at hand to know which order volume it can accept (i.e. what is possible to manufacture) and which delivery date it can promise. Failure to deliver ordered product on an agreed delivery date can lead to penalties and/or cancelled orders. This is a continuous process of managing capacity with demand and interpreting the financial impact of the balance between these sometimes-competing interests.

Payment for the order will typically be at the earliest upon delivery, and more typically only after delivery. That means the company has to fund the purchase of the raw materials and fund the labour cost to manufacture the product before it can be invoice for and receive payment for an order. This means a company often has to carry those costs for several months.

Therefore, when a sales team accepts an order, it places a financial obligation on the company to fund this cost - this affects cashflow. Sales teams therefore must have sufficiently accurate and live information at hand for it to understand the financial implications of making a sale. This is counter intuitive to how sales teams operate. They are normally driven by sales figures and incentivised to simply maximise sales. Data relating to manufacturing capacity and the financial suitability of concluding a specific sales deal is therefore crucial to making the correct decision at such time.

It is quite possible that at a specific time a sales team may plunge a business into a cashflow problem, which very costly financing costs implications, by concluding a sales deal on terms that may otherwise have not been a problem. The same deal can be a good deal one day and bad deal the next day, and the other way around. This limitation does not only extend to sales teams but permeates all facets of any business. To properly and effectively manage any business, the business manager must balance the various interactive elements of the business to ensure that, in its simplest form“production” (goods or services) matches demand and capacity, and that the financing of its“production” to meet demand is not unduly costly.

The inflexibility of conventional accounting systems (described above), which are integral to business management systems, means that the information that such business management systems can provide is delayed and inflexible and in many instances such information becomes almost irrelevant. It forces business managers to operate on the basis of estimates and assumptions.

Associated with the above problems is the increasing complexity of transacting in the modern era. Governments are enacting and enforcing ever-stricter regulatory requirements on citizens and businesses, which are at best difficult to keep up and comply with.

When people are exposed to this for the first time, they often find it difficult to grasp the complexity of these requirements and often fail to comply with it. This is often simply for being unaware of the regulatory requirements or being unfamiliar with the greater ‘financial or business system’, its requirements and about how to comply with it.

This not only manifest itself in terms of financial reporting obligations, and the difficulty of maintaining accurate records as set out above, but also in respect of young people making the transition to adulthood in business, and generally. They are subjected to a world of which they usually know very little and very often where they are left to their own devices.

Additionally, a generation of older people that moved out of active employment before more stringent regulatory requirements subsequently came into force, also find it difficult to comply with such requirements when they have to engage this‘financial or business system’. They were not accustomed to it at the time they were actively employed, so they simply don’t know what to so. They are also faced with technologies that are unfamiliar to them, but which have become commonplace in the marketplace.

Essentially, the world has become an unfamiliar and daunting place for many people to live and transact in. In many instances, older people have to rely on their adult children or grandchildren to assist them with complying with regulatory requirements. Furthermore, in addition to having to comply with various regulatory obligations, young people that are moving into adulthood are inexperienced in engaging in transactions and unfamiliar with the impact that day-to-day transactions have on their nett financial position. Unscrupulous service providers are aware of this, and actively exploit it. This often ties your adults into services and costs they don’t really require, or at a much higher cost than they would have been able to secure somewhere else.

Considering the above difficulties to use conventional business management systems, even for established business people, and the added difficulty for new entrants to the business environment, there is a need for a method and system for processing transaction data and managing document and data, to enable people to more easily, more flexibly and more accurately transact and to guide them to informed decisions and actions.

OBJECTIVE OF THE INVENTION

It is an objective of the invention to provide a method and system for processing transaction data and for managing documents and data which at least partly overcomes the abovementioned problems.

SUMMARY OF THE INVENTION

In accordance with this invention there is provided a method of processing transaction data which includes:

defining an original set of rules to interpret data from a plurality of current transaction data sources;

defining an original set of reports to reflect aspects of data resulting from application of the original set of rules to data from the current transaction data sources;

receiving data from a plurality of current transaction data sources and processing the data into categories by applying the original set of rules to the data;

generating at least one report from the original set of reports which reflects the processed data;

creating one or more modified set of rules and modified set of reports to reflect updated user requirements; processing, in parallel with the original set or rules, the transaction data, including historical transaction data, with at least one of the modified sets of rules to create for each of the applied sets of rules an associated set of reports;

selecting from the original set of rules and modified set of rules a new set of rules, and defining the new set of rules as an updated current set of rules with an associated updated current set of reports; and

updating the transaction data sources, and to the extent this impacts on them accordingly also updating the then current set of rules and the then current set of reports.

There is further provided for the current set of rules to be created and updated according to actions of users of the method, which is preferably to be augmented through any one or more of machine learning, artificial intelligence, and crowdsourcing.

According to a further aspect of this invention there is provided for the method to include processing transaction data which includes:

providing data input means to a processor of a first financial institution to input transaction data to make a payment from a funding account to a beneficiary,

providing a transaction data field for input of an invoice number and an associated payment amount,

including the invoice number data and associated payment amount in data relating to the transaction,

providing an interface between the first financial institution processor and a second financial institution processor nominated for receipt of the payment;

making payment of the payment amount from the first financial institution to the second financial institution;

providing an interface between the second financial institution processor and the beneficiary financial system,

transmitting the transaction data from the second financial institution processor to the beneficiary financial system,

processing the transaction data by the beneficiary financial system to associate the transaction with an invoice associated with the invoice number, and

updating the beneficiary financial records to reflect the payment against the associated invoice once after completion of the transaction.

There is further provided for the method to include providing a transaction data field for input of a plurality of invoice numbers each with an associated payment amount, for batching the invoice numbers to form a single transaction, and for including all the invoice numbers each with its associated payment amount in the transaction data.

According to a further aspect of the invention there is provided for the method to include providing an interface between a payer financial system and financial institution transaction processor,

for the step of including the invoice number data and payment amount in data relating to the transaction to include selecting the invoice from a schedule of unpaid debtor invoices in the payer financial system and confirming payment of the associated invoice amount or including an alternative payment amount for payment towards to the invoice, and

transmitting the payment data from the payer financial system to the financial institution transaction processor through the interface between them.

There is still further provided for the method to include providing a transaction data field for input of an expense account number,

including the expense account number in the transaction data transmitted by the financial institution transaction processor to the payer financial system through the interface between them,

processing the transaction data by the payer financial system to associate the transaction with the expense account associated with the expense account number, and updating the payer financial records to reflect the payment against the invoice once the transaction has been completed.

According to a still further of the invention there is provided for the method to provide selection means to distinguish between private and business beneficiaries, and for the inclusion of the transaction data field where the beneficiary is a business, with input requiring completion of the transaction data field before the transaction will be processed.

According to an alternative aspect of the invention, there is provided a method of processing transaction data which includes:

generating an invoice from a beneficiary’s financial system in respect of a transaction with a payer;

transmitting the invoice from the beneficiary to the payer;

transmitting data relating to the transaction to a key generator; generating a unique key associated with the transaction by the key generator, and transmitting the key to the beneficiary’s financial system and the payer’s financial system for association with the transaction;

making payment in respect of the invoice using the key as payment reference;

transmitting an account statement from the beneficiary’s financial institution processor to the beneficiary financial system including data relating to the payment associated with the key; and

processing the account statement into the beneficiary’s financial system to update the status of the transaction in the seller’s financial system, using the key as a unique identifier of the transaction.

There is further provided for the transaction data to be transmitted to the key generator by the beneficiary or the payer, and for the key to be transmitted by the key generator to the payer for association with the invoice prior to transmission to the payer, or for the key generator to transmit the key to the beneficiary for association with the invoice.

According to a further aspect of the invention there is provided for the method to include managing documents and data, comprising the steps of providing a network accessible server with an associated processor and database, a plurality of network accessible communication devices, and a plurality of service providers at least partly interfaced with the server;

the method further including the step of a person subscribing to the system as a customer by submitting identification and contact details to the server for storage in the database in association with an account associated with the customer;

presenting the customer with data input fields requesting at least one of the customer’s:

• age,

• education level,

• current employment details,

• salary,

• budget information, including full income and monthly and annual expenses, asset list including any one or more of vehicles, property, and movable assets, and

• subscription services, including medical aid, insurance including one or both of life insurance and short-term insurance, investments including any one or more of property, stocks, investment policies, and the like;

with the processor determining from the data input at least a customer’s nett financial position, record in the database in association with the customer’s account his future obligations, including financial and administrative obligations, and transmitting to a customer’s communication device a reminder in respect of his future obligations.

There is further provided for:

• the budget information to include the customer’s income, monthly and annual expenses, and an asset list, including any of vehicles, property, and movables property;

• the subscription services to include any one or more of:

o medical aid;

o insurance, including life insurance and short-term insurance; and

o investments including property, stocks, and investment policies.

There is further provided for the customer’s identification and contact details to be verified, including by the customer submitting at least copies of documents carrying identification and contact details of the customer to the system, and more preferably by a verification agent submitting verified copies of documents bearing identification and contact details of the customer to the server.

There is still further provided for the verification agent to comprise an associated service provider, and for verified copies of the documents bearing identification and contact details relating to the customer to be transmitted to the server by the verification agent by means of the network for storage in the database in association with the customer’s account.

There is still further for the system to distribute verified copies of the documents bearing identification and contact details relating to the customer to all service providers that the customer has registered in association with its account, preferably immediately after such documents have been uploaded to the system.

There is further provided for the communication devices to comprise mobile communication devices, including smart phones, smart devices, tablets and the like, and network accessible computers.

According to a further aspect of the invention there is provided a system for processing transaction data which includes:

providing a processor with associated storage means and associated communication means, defining an original set of rules and storing the rules on the storage means for use by the processor to interpret data from a plurality of current transaction sources;

defining an original set of reports and storing the report definitions on the storage means for the processor to create reports to reflect aspects of data resulting from application of the original set of rules to data from the current transaction source;

receiving data, through the communication means, from a plurality of current transaction sources and processing the data into categories by applying the set of rules to the data;

generating, by means of the processor, at least one report from the original set of reports which reflects the processed data;

the processor being configured to enable the creation of one or more modified set of rules, and modified set of reports to reflect updated user requirements, in parallel with the original set or rules and original set of reports;

the processor being configured to process the transaction data, including historical transaction data, with each of the modified sets of rules to create for each set of rules its associated set of reports;

the processor being configured to enable selection of a new set of rules and a new set reports from the modified set of rules and the modified set of reports, and to implement the selected modified set of rules and the modified set of reports as an updated set of rules and updated set of report; and

updating the transaction sources, and to the extent this impacts on them also accordingly updating the then current set of rules and the then current set of reports.

These and other features of the invention are described in more detail below.

BRIEF DESCRIPTION OF THE DRAWING

Preferred embodiments of the invention are described by way of example only and with reference to the accompanying drawings in which:

Figure 1 is a diagrammatic representation of a preferred embodiment of the invention;

Figure 2 is a diagrammatic representation of a further aspect of the invention;

Figure 3 is a diagrammatic representation of a further aspect of the invention; and

Figure 4 is a diagrammatic representation of a further aspect of the invention. DETAILED DESCRIPTION OF THE INVENTION

A preferred embodiment of the invention, shown in Figure 1 , relates to a method (1) and system for processing transaction data, which includes a server configured to receive and process transaction data from a plurality of transaction sources. The server has associated storage means to store processed data and reports.

In respect of the method (1) of the invention, one of the most important transaction sources is an entity’s (a user of the method of the invention) bank statements. In this respect, bank statements are not limited to printed statements which are mailed periodically to a bank account holder, but more accurately to the online and live bank statements which are held by the bank, and to which the account holder has access through an online portal.

This online portal allows authenticated and authorised access to the transactional details of the relevant bank account. The server which operates the processor used in the method (1) gains authenticated and authorised access to such data at the instance of the account holder. The server interprets the data by“reading” it and applying a set of rules to the transactional data and storing at least temporarily on the server the outcome of the application of the set of rules to the transactional data.

The server may download and store copies of the bank statements as original source documents (2) for future reference and further use. The importance of this will become clear further on.

The set of rules (3) is created by the user of the system, and these rules (3) defines at the outset how transactional data is categorised (4). The rules are created by the user, but are augmented through any one or more of machine learning, artificial intelligence, and crowdsourcing. The aim of this is for the system to learn the intent of the various transactions, and to correctly reflect that, and not to just be result orientated by blindly allocating a transaction to an account.

The categorisation using the rules allows, for example, transactions at a fuel station, to be categorised as fuel purchases. It can also include further categories such as local detail or supplier detail for the specific transaction. This provides several layers of detail in respect of any type of transaction.

The user of the method (1) also defines a set of reports (5) which are generated when required using data processed according to the set of rules. Such reports may for example include a cashflow forecast, and a cashflow forecast warning. Importantly, the reports may also include conventional books of account (6) required for regulatory purposes by the auditors of the user’s company.

The system thus allows the user, in creating the set of rules and set of reports, to design a system tree according to his business reporting requirements (hashed in any way). Further, this allows for the system tree to be changed in any period of a financial year or years, by editing the category name or reallocating a category to a new or alternative category. The rules will automatically be updated and processed accordingly. The fluid system allows a business to review financial analysis from various perspectives. Often this analysis work is done by financial consultants and very costly.

In addition to data from the financial statements to which the processor on the server applies the set of rules, the server is also provided with data from additional data sources (2). This could include data relating to debtor invoices generated and creditor invoices paid, stock levels, order book details, currency exchange rates, and the like.

The system also provides a life and accurate view of the business’ liability commitment, which includes shareholder loan repayments, asset balloon payments, etc. This feature monitors the liquidity and commitment payment dates on an ongoing basis. In this context,‘commitment’ includes any contractual agreement, such as financing agreements, shareholders agreements, dividends, etc. By creating categories that differentiate between balance sheet items such asset payments, liabilities and by determining depreciation, the system allows EBITA (earnings before interest, taxes, and amortization) calculations to be available at any time.

The system further monitors and calculates statutory payments e.g. company tax. The system is accessible by multiple users at the same time. This provides for collaboration between users, by allowing users or multiple users (data capturers, Investors, shareholders, auditors) access at the same time, to view business activities with just in time information.

The system also monitors the task requirements of users in real time. It has a notification feature that allows a notification to be sent to various teams/managers, to update them on the progress of data processing.

Associated with the notifications is the dashboard view that the system provides on an associated output device, such as a display screen of a computer or a mobile communication device. Financial report notifications can be sent on a schedule to responsible persons, and access to the reports can be user-defined.

The system also provides a so-called‘Expense Claims Category’, which allows an employee to allocate and monitor their expense claims from a company. The balance in the category will be zero on settlement of expense claims.

In its simplest form the method provides an upfront view, through the reports (5), to a business manager of the impact that decisions have on its business. For example, a decision to accept an order to manufacture and deliver a set of widgets on a specific date, places (as discussed above) a financial obligation on the business. It has to fund the production of the widgets.

The decision on accepting specific terms associated with such an order, which may have an impact on the cashflow of the business, must therefore ideally be made with as much as possible relevant information in hand.

This could include data gleamed from all relevant data sources (2), including bank statements relating to upcoming financial obligations, data relating to delays in receiving payments from previously completed orders, data relating to delays in shipping times due to unforeseen events such as natural disasters, exchange rate fluctuations, and so forth.

In this instance, with a view on accepting a specific order, the processor receives data from the various sources, processes it, and calculates a cashflow forecast based on the expected delivery date of the order and relevant data provided by the rest of the transaction sources available to the server. It may be that the level of raw material on hand is so low, and the delays in ordering additional raw material so long, that it will not be possible to complete the order on standard terms without incurring a loss.

The processor may calculate that it will be possible to complete the order if delivery of the raw material is expedited but it will note the increased cost for that and will indicate the impact on the cashflow. That may reveal that a seemingly profitable order is, under the circumstances, not profitable. The business owner can then negotiate suitable terms with his customer to ensure timely delivery without foregoing the profit (or at least not all of it) the business would have made on the order.

This analysis has to be live and it has to be flexible. The analysis of the current position may reveal that a prospective deal is not profitable. That may lead the business owner to query what can be done to render it profitable. For this the business owner may need to reconsider how he handles certain aspects of his business.

This could include, for example, that certain levels of stock or raw materials be maintained at higher levels. It could possibly include that certain orders for certain customers be handled by different manufacturing divisions of the business.

To determine the impact of this, certain costs of and profits in the business may have to be allocated in its accounting system to different areas. For example, if production is shifted to another factory it has an impact on transportation costs, the profitability of the factories involved, capacity to manufacture, overtime for labour, etc. Such a reallocation cannot be done easily in a conventional accounting system, especially if it is only for a‘what-if exercise. The business owner will have to embark on a separate cost-benefit analysis that is time consuming and typically not live when completed. Also, very importantly, the accounting system will only change future allocations of transactions since its point of departure is that the its prior allocations were accurate at the time and cannot be changed.

Using the present method and system that deploys it, the answer is as close as changing a few rules and applying these modified to the same set of source data (2) through a parallel set of rules (3A). This change in rules (3A) reworks historical data (2) and presents, for example, the cashflow forecast (5A) based on reworked historical data and categorisation for future data based on the‘what-if (3A) scenario.

The business owner may apply multiple set of modified rules (3A, 3B, etc) on the same set of transaction data, all at the same time, to consider the impact on his business. This is done without affecting what is at that time the current set of rules (3).

If any of the‘what-if scenarios indicate a positive change (from the business’ perspective), represented by the forecast based on the updated rules (5A or 5B), the business owner may decide to accept the order based on the revised organisational structure, and manage his business accordingly and implement the relevant revised set of rules (3A or 3B) to reflect the revised situation.

The use of the‘what-if aspect allows the business owner to view what his current position would have been if the business had been operated differently. A modified set of rules (3A, 3B, etc) is applied to historical source data, which reveals what eh position would be in the present, but also selectively at a date in the past. Similarly, using available information on future commitments (by and for the business) the system projects the position in future

This provides the system with a‘time machine’ like feature, both back in time and ahead in time.

Essentially the invention provides a flexible system that is dynamic yet tracked which is very complimentary to traditional accounting systems and facilities business decisions based on ‘information known at the time’ rather than‘signed off financials’.

This effectively allows the business owner to accurately test, with current and live data, how business changes will affect his business without yet changing how he handles the business’ data.

The system also allows a user to easily reconcile (7) the reports (and in effect the set of rules) back to the source data, since the source data (2) is not changed and the reports are always based on the course data (2) and not on an intermediate set of fixed account allocations (accounting records) as is the case with conventional accounting systems.

This reliance on original source data instead of an intermediate set of processed data allows the system to more accurately reveal fraud. Since original source documents are relied upon, it is not possible for someone to hide fraud in accounting records by allocating an unauthorised withdrawal to an account. Such misallocation may only be revealed if during an audit by chance the auditor selects that transaction for deeper analysis, or in the unlikely event that the original documents are reviewed after having been processed according to the accounting allocations (i.e. into the general ledger accounts).

A further aspect of the system of the present invention relates to fraudulent debit payments. With its defined rules, and as set out above, the system will detect fraudulent debit payments. These payments can be allocated to a specific category, investigated, and claimed. This category balance should be zero once settled.

This is a significant limitation of conventional systems that may be replaced by the system of the invention. Conventional systems process source data according to a general ledge setup, and once the source data has been processed in this manner, the source data only serves as reference material of the accounting allocations in the event of a query. All further work is done on the processed source data, and not ever again on the original source data (unless there is an exception, and a deep investigation is conducted into the original processing of source data).

The categorisation of source data into categories, by the system of the invention, should not be confused with the allocation of processed data, by conventional accounting systems, into general ledger accounts. The result of the categorisation used by the present invention is a set of reports that are based directly on original source data. When the reports are generated again, the original source data is again used as the basis for the reports. The categorisation is an intermediate non-permanent step. With conventional accounting system to allocation to accounts is permanent, and any attempt to change it requires special journal entries and explanations.

The system of the invention, at all times, relies upon original source data for its reports. Every time a report is generated the original source data is queried. By not relying on the intermediate set of fixed account allocations as the basis for its reports, the system remains accurate, reliable, relevant and accountable.

The system uses sources of truth (e.g. bank statements, budgets, and more) and sources of assumption (e.g. projections), computed on a structure that is tailored to business requirements (categories) by means of derived knowledge/understanding in the form of rules. This allows a user to visualise the information by time/category and generate alerts proactively rather than to belatedly report passively.

By way of another example, on a more individual level and more specifically, the system may also involve transmitting to sales people up to date business information on their mobile devices. This may be updated with current orders (i.e. the existing order book) and the impact that a proposed order will have on the business. This will allow sales people to conclude not only deals in terms of volume, but also to focus on the beneficial effect on the business of the deals that they conclude.

The system may, for example, based on projected negative cashflow, prevent a salesperson from concluding a deal on specific terms. It may instead suggest to the salesperson to offer the customer a revised deal with for example a discount, which is still more beneficial to the business by it avoiding the projected negative cashflow position.

As mentioned above, the method includes the application of rules to interpret source data. One particular aspect of this relates to processing transaction data relating to payments and receipts associated with businesses, in particular where large volumes of payments are processed. In these embodiments the beneficiaries of the payments are also the vendors that provided the services and issued the invoices.

One implementation (1 1) of the invention in respect of this aspect, as shown in Figure 2, involves a vendor (12), the vendor’s financial software (12A), a payer (13), the payer’s bank (14) and its banking system software (14A), the vendor’s bank (15) and its banking system software (15A).

The process to effect payment of an invoice and accurately record it against the vendor’s (12) and payer’s (13) records commences with the payer’s (13) decision to make the payment against the invoice. For this purpose, it is assumed that the payer is in receipt of the relevant invoice and its relevant details. The payer (13) uses the payer’s banking system software (14A) to pay the invoice. The payer (13) accesses (16) his banking profile on the payer’s banking system software (14A) and selects the payment option.

The payer’s banking system software (14A) provides the payer (13) with data input means to the system software (14A) to input transaction data to make a payment for the invoice from a funding account held with the bank (14) by the payer (13). The transaction data includes a data field for the vendor invoice number and the associated payment amount to be input.

The processor associated with the banking system software (14A) processes the payment to effect it, and the transaction data which includes the beneficiary invoice number and the associated payment amount is associated with the transaction in the form of transaction data.

The payment amount is paid (17) to the vendor’s account number, held by the vendor (22) at its bank (15). This may be same the same bank as that of the payer (13).

A further embodiment (20) of this aspect of the invention is shown in Figure 3, and involves a vendor (22), the vendor’s financial management (22A), a payer (23), the payer financial management system (23A), the payer’s bank (24) and its banking system software (24A), the vendor’s bank (25) and its banking system software (25A).

In this embodiment (20) the process to effect payment of an invoice and accurately record it against the vendor’s (22) and payer’s (23) records commences with the vendor (22) issuing the invoice to the payer (23).

The vendor’s financial management system (22k) is securely connected by means of an interface (21) with the payer financial management system (23A). The invoice is transmitted from the vendor (22) to the payer (23) using this interface.

Upon deciding to pay the invoice, the payer (23) marks the invoice for payment in its financial management system (23A). The payer’s financial management system (23A) securely connects with the payer’s bank system software using a secure interface (26). Via this secure interface (26) the instruction to pay the invoice is issued to the payer’s bank system software (24A). The instruction includes transaction data that accompanies the transaction, which transaction data includes the invoice number. The processor associated with the banking system software (24A) processes the payment to effect it, and the transaction data which includes the beneficiary invoice number and the associated payment amount is associated with the transaction in the form of transaction data.

The payment amount is paid (27) to the vendor’s account number, held by the vendor (22) at its bank (25).

The vendor financial management system (22k) is connected to the vendor banking system (22k) by means of a secure interface (28). This allows the transaction data to be transmitted by the vendor banking system software (25A) to the vendor financial management system (22k). A processor associated with the vendor financial management system (22k) associates the transaction with an invoice associated with the invoice number and updates the vendor financial records to reflect the payment against the associated invoice once after completion of the transaction.

Once the payment has been received by the vendor banking system software (25A), it confirms receipt thereof to the payer baking system software using the secure interface (27). The latter confirms payment to the payer financial management system software (23A), using the secure interface (26) between them, which allows the payer’s financial management system software (23A) to be updated correctly to reflect that the specific invoice is paid.

In this manner the payment of the invoice is accurately input to the system and accurately reported to all parties involved. The respective financial management system software of the payer and vendor are updated as soon as transaction is processed, which means the vendor and payer have up to date accurate information in hand, all the time.

An advantage that this aspect of the implementation of the invention has over the previous embodiment is that the invoice number does not have to be input manually into the banking financial system - it is selected from a list of unpaid invoices by means of computer input from a graphical user interface device as a computer mouse or keyboard.

Alternatively, a payer can elect to pay a batch of invoices and the associated details of each will be added by means of the payer’s financial system software. Each invoice is captured from the outset with the correct data, such as its unique invoice number, and this data is transmitted to the payer’s banking system software (24A) and from there to the vendor’s banking system software (25A) when the payment instruction is given and the payment made, respectively.

A loop is thus created between the vendor, its bank and the payer. Information is exchanged through secure interfaces between the parties which allows payments to be accurately identified and the associated financial systems accurately updated and in as close to real time as is currently possible. This allows for example sales team to receive updated sales and target data.

The system on the beneficiary’s side includes the set of rules, to enable handling of transactions such as those falling in the scope of the embodiments described above. The set of rules allows the creation of rules templates, with rules that are executed in a predetermined order.

The implementing system of the invention provides an interface for a user, in the above embodiments the vendor (12 or 22), to define rules for the system. It allows a user to create rules to ease later input of similar rules. It also provides means, through the interface, for a user to change the order of execution of rules by dragging icons or text displayed on a display screen and which are associated with rules to different positions on the display screen.

With execution of a rule the system processor‘learns’ how transactions are allocated, which over time reduces the number of unallocated or uncategorised transactions.

The system is also configured to allow users of the system to import custom profile packs, for example a ‘plumber pack’, a ‘grocery pack’, and so forth. Each of these packs includes predefined categories and rules relevant to the specific type of business. This saves the user (vendor) time in having to create his own rules. This incorporates the crowed sourcing element of the creation of the rules - the acquired knowledge from one user is made available though updates to other users in the same type of business, for the benefit of all users.

Although the system is configured to use data that is integrated into the process and transmitted between parties to the process, as described above, the implementation of intelligent analysis of transaction data which does not include such integrated transaction identifiers, allows a financial system to extract the requisite information from transaction data even in the absence of such integrated identifiers.

The ability of the system to learn from how data it receives is processed, and from corrections made to incorrect categorisations it has done or suggested, allows it to become increasingly accurate.

The implementation of further aspect of the invention is depicted in Figure 4. In this embodiment (30) the payer (31) and beneficiary (32) use a 3^rd party key generator (33) to create a unique key (34) in association with a transaction or invoice. The key (34) is associated with the invoice, and when the payment is made the associated key (34) is used as payment reference, which allows it to be correctly allocated in the financial systems of both the payer (31) and beneficiary (32).

In an implementation of this embodiment the beneficiary (the party that issues the invoice, for example a seller) (32) requests the key (34), and in a second implementation thereof the payer (the party that receives the invoice for payment, for example a purchaser) requests the key.

For the first implementation, and as shown in Figure 4:

• the beneficiary (32) generates an invoice (or equivalent) (35) using its financial

system (36);

• The beneficiary (32) uses the key generator (33) to generate a unique 'key' (34)

associated with one or more supporting documents (typically invoices). This is stored in the cloud and is globally unique;

• The beneficiary (32) then supplies the payer (31) with invoice(s) ;

• The payer (31) obtains the key (34) from the cloud-based system (either push or pull mechanism) (33);

• The payer (31) makes payment on the invoice (35), by instructing (37)its bank (39), using its payment software (38), to attend to the payment and using the key (34) as the payment reference;

• The payer’s bank (39) transfers the payment amount, with the key (34) as reference, to the beneficiary’s bank (40);

• The beneficiary (32) receives and processes its bank statement (41) from its bank (40) into its financial system (36), as a transaction source document. The key (34) is used to associate the transaction with the appropriate invoice(35) which is recorded in the beneficiary’s financial system (36); and

• The payer’s (31) financial system (38) is accordingly updated.

As an alternative to the above flow, a payer can also register a key. In such an instance the steps would include:

• A beneficiary generates an invoice (or equivalent) on either existing vendor financial package or new system.

• The beneficiary then supplies purchaser with invoice(s) (via any channel, possibly including the new system).

• Payer obtains invoice(s) for which no key is yet associated. The payer uses new

system to generate a key for the invoice(s) associated with the intended payment and registers this securely in the cloud system.

• The Payer makes payment using own interface with bank but using key as the

reference.

• The payer is notified of key and will have access to it before payment reflects in bank statement. (Alternatively, the next step would look up the key as needed.)

• The beneficiary receives and processes bank statement into new system. The key is used to associate the transaction with the appropriate invoice(s) which is recorded in the new system.

• The beneficiary's financial package is updated.

This allows both parties to a transaction to utilise at its instance the key generator which enables it to accurately record the transaction in its financial records/system. Even if one of the parties don’t use the key generator system and service, the other can still initiate it and ensure that its records are more efficiently updated.

The invention also extends to a document and data management system aspect, which is complementary to the above implementation.

A preferred embodiment of a document and data management system aspect of the invention is deployed by means a network accessible server, which allows communication through a plurality of network connections, including the Internet and private networks. The Internet connection may be accessed by means of a variety of data connection types, including mobile data connection types such as Edge, GRPS, 3G, or LTE, fixed data line connections such ADSL or fibre connection, radio transmission data types, and any other suitable Internet connection.

The server includes an associated processor and a database. The database is stored on an associated computer readable storage device.

The system also includes a plurality of subscribers with network accessible devices, including computers, mobile communication smart devices such as smart phones, tablets, smart watches and the like. Notably, smart devices may communicate with the server by means of a mobile communication network or a wireless (Wi-Fi) connection to another type of Internet connection. It matters not the type of connection to the server but that the smart devices can connect to the server.

Also connected to the server are a plurality of service providers, which may include, without limitation:

• financial service providers such as banks,

• insurance companies or insurance agents, including personal, household and medical insurance,

• investment services providers,

• vehicle licence renewal centres,

• tax services,

• municipal services,

• any other governmental service, on national, provincial and local government level, and

• other service providers such as clubs and the like.

In use a person that desires to use the service provided by the system subscribes to it by accessing an online portal, in which the person can create a profile for use of the system. The online portal may conveniently be presented to a prospective customer through an interface on a mobile communication device by a mobile software application (also called an“app”) operating on it.

The mobile communication device will typically operate on the smart device of the customer’s choice (typically operating Android™ or iOS™ operating systems. The relevant software application provides a communication portal for the customer with the service. By means of the portal the customer’s name, identification number and contact and address details will be entered on the system.

This will require verification, which may be done in respect of the contact details (smart device telephone number and email address) in conventional manner by sending a link or a code to such device which needs to be entered into a data input field to confirm such details are accurate.

In respect of the verification of the identification and address details, required for anti-money laundering purposes (FICA), the system may allow a customer to have two levels of possible verification.

At a minimum, it requests from the customer to scan - using a mobile smart device’s camera - relevant documents and upload them to the system. This will include at least an identification document and proof of address. Along with this the customer is provided with data input fields to input, on his smart device, his name and address details in text format. This first step allows a customer to at least keep copies of these documents on his smart device. The customer is enabled to provide copies of the documents to a 3^rd party that requires this, which will have to consider for itself whether it complies with verification principles applicable to it. This may be done by forwarding copies to a 3^rd party from the software application on the mobile device by means of suitable communication software, for example email.

For a higher level of verification, the system acts to provide proof of its customers’ personal information, required in many financial transactions through anti-money laundering legislation (FICA, in South Africa). Since original documentation or verified copies thereof is required in terms of such legislation, it is envisaged that associated service providers will allow a customer to visit them once-off to submit and confirm these documents. The associated service providers may include commercial banks that in any event have to conduct the same process on new clients before opening accounts for them. In most instances the relevant information will already be available to such an institution, which will allow the information to be uploaded by such institution on request of the customer to the server, for storage on the database in association with the name of the customer.

At the outset in respect of such higher level of verification, the customer is allowed to input his name and address details to the system through a data input field. The customer then goes to an associated institution, such as his own personal bank, with the request to submit his FICA documents to the bank and the system. He produces, as he would normally do for the bank upon request, his original identification and proof of address documents. The bank verifies as it would do for its own purposes, the identity and address details and take copies of the customer’s identification and proof of address documents (the “verification documents”). Typically, the bank will store copies of the verification documents on its own database in association with the customer’s name, to confirm he complied with the FICA requirements.

Upon request from the customer, he presents them with a code that is provided to him on his smart device. The bank activates a link to the system, is provided with the data that the customer has input to the system. It confirms this corresponds with its records and transmits an electronic copy of the verified documents to the system. This verifies the customer to the system.

Once this is done, the customer’s verification documents is available on the system for the customer to provide to a 3^rd party on request. The verification documents are not stored on the customer’s smart device, for reasons which will become clear below.

If the customer subsequently has to produce his verification documents to a 3^rd party he simply provides such 3^rd party, by making use of the software application on his smart device, with a link to his verification documents. The 3^rd party operates the link which provides him, through the network (typically the Internet) with a bundle of documents which includes a coversheet indicating the name, identity and contact details of the customer, the date on which the data was verified, and the party (for example the bank’s name and address details) that verified the verification documents. In the same document, copies of the verified verification documents are provided. All of these documents may be electronically and visually watermarked to confirm when and by whom they were verified.

The 3^rd party is thus provided with copies of the documents that had already been certified, which typically should allow the 3^rd party, if its internal rules allow for this, to accept the information as verified.

This creates a central repository for submission of verification documents, verification thereof, and certification of copies being distributed from there as authentic copies of the documents submitted to the original verifier. This allows for verified personal information of customers to be supplied once to system and to be used by the customer, by associated service providers, and for 3^rd parties. The system may be configured for associated service providers to be provided automatic access to updated information that is presented to the system, to allow their own FICA systems to be kept up to date.

For example, a customer may join the system in 2017, and submit through his personal bank his verification documents, verified by the bank.

In 2018 the customer plans to move to another city. The address details of his 2017 verification documents will become outdated once he completes such move. The customer attends the office of an estate agent to execute a rental agreement in respect of the new address. The estate agent uses the system to obtain the then still valid 2017 verification documents of the customer, to enable him to conclude the rental agreement. Once signed the estate agent verifies the customer’s new address supported by the freshly executed rental agreement, and uploads it to the system.

The customer’s FICA information and supporting documents is thus instantaneously updated on the system - it now has his 2018 address details and his unchanged 2017 identification details. If the identification details changed, the estate agent would have submitted a verified copy of that as well.

The bank that originally uploaded the 2017 verification documents obtain a copy of the updated verification documents, which automatically places it records up to date. Similarly, each 3^rd party that is recorded by the customer as an interested party on the system immediately receives the updated verification documents, verified in similar manner to which it would have verified the documents. The old verification documents remain available on the system, providing over time a history of verification with supporting documents.

The benefit for the customer is that at any time he can forward a link to his verified verification documents to any 3^rd party that requires them. The benefit for 3^rd party institutions to join the system is that it does not have to do more than what it already has to do, and additionally it receives the benefit of updated verification done by other parties. Collectively this lessens the load on all participants of the system with increased verification benefiting all of them. By storing the verification documents and their history on the server’s database, the options for fraud are minimised. All a customer can do is provide a link to the data - essentially an authorisation and instruction for the system to provide the current verification data it has stored for the customer to a specified 3^rd party. The customer is not enabled to modify the information, other than by submitting updated copies which have to be verified again by a party that is authorised to do so.

With the verified personal information of the customer in place, the system allows it to use the functions provided by it, including forwarding to a 3^rd party a link to the verification documents.

The software application stores some data, mirrored from the server’s database, on the smart device’s memory. This allows for quick access of such data even when the device does not have an active connection to the server.

The customer provides, on request from the server presented to the customer as a data input field, basic information to profile the customer. This may include, in addition to the personal information (name, identity number and address) required to create an account with the system, for example the customer’s:

• age,

• education level,

• current employment details,

• salary,

• budget information, including full income and monthly and annual expenses,

• asset list (vehicles, property, movables), and

• subscribed services, including medical aid, insurance (life and short-term), investments (property, stocks, investment policies, etc).

The system accesses the customer transactional records with his financial institution at predeterminable intervals.

The processor collates this information and processes it to determine the customer’s nett financial position, noting his assets and liabilities, and record future and recurring obligations. The obligations may include payment of annual renewals or subscriptions, such as vehicle licence and television licence renewals, club subscription renewals and the like - essentially known future and recurring obligations that imposes one or both a financial and an administrative obligation on the customer. The processed information thus provides a summary of the customer’s nett financial position, and notes when future obligations are due.

It is also envisaged that the system will include integral connections to many of the service providers. This allows the system at the correct time, in advance of the due date to comply with a future or recurring obligation, to present the customer with a reminder that it will fall due. For service providers that have integral connections to the system, for example a vehicle licence renewal system, the customer can complete relevant detail in a data input field provided to it on its smart device, and submit that to the licence service to renew the licence. The data input field in this example is typically just the current mileage on the vehicle - the rest of the data is input once for the vehicle and remains consistent throughout its life.

Similarly, the system may be used to renew for example television licences or club subscriptions.

The system may also be used to prepare and submit tax returns, on time using the financial and other stored information on hand.

The system also compares the customer’s profile against a set of criteria stored in its database. Then criteria could include details relating to normal short-term insurance for someone of the customer’s age and financial position. If the customer’s live with his parents and uses public transport he may not need much in the form of short-term insurance. Similarly, if the customer is covered through his parents’ medical aid he does not need to pay for his own.

This allows the system to continuously review the customer’s overall nett financial position and coverage in respect of relevant aspects of his life and advise him of possible shortcomings.

If, for example, the customer is covered through his parents’ medial aid as a dependent then it is quite likely that coverage will cease when the customer reaches a specific age, such as 26 years. The system can determine this by noting that in terms of medical aid the customer, who may at that time be 25 years old, is still covered by his parents’ medical aid.

The system will determine with reference to standard terms of the specific medial aid that it is likely the coverage will cease when the customer reaches 26 years of age. It will thus advise the customer in advance of this to confirm whether his coverage will still be effective, and if not will suggest the customer obtains his own medical aid.

The system will be able, from the customer’s profile, to make a recommendation of the type of medical aid (for example a hospital plan only, or a combination hospital and savings account plan), that the customer may wish to acquire, commensurate with his profile.

The system is then able to provide the customer with links to associated medial aid service providers to enable smooth interaction with them. The customer is enabled, by means of the system, to transmit relevant profile data to one or more medial aid service providers to obtain cost estimates for the relevant medical aid.

Additionally, the customer may also use the system to provide an approximate cost implication of acquiring a specific asset, for example a vehicle. The asset and liability assessments conducted by financial institutions prior to financing an asset like a vehicle is done to comply with legislation and to manage the risk on the financial institution - these are not always aligned with the best interest of the customer.

Using the system, the customer can pose the question what the impact on his nett financial position will be if he leases purchases, with financing, a specific vehicle. The system can calculate the monthly repayment cost, typical insurance cost, annual licence renewal cost, annual maintenance cost, and fuel cost and factor that into the customer’s budget. If the result indicates the real total cost of the purchase on customer’s nett financial position is too great the system can advise the customer of this as being too expensive. This information is not always readily available from a financial institution that handles a sale since its incentive is to make the sale, not to protect the purchaser’s financial position.

The system may also be used by the customer to identify saving goals, for example a goal of purchasing a vehicle or going on an overseas holiday. It allows the customer to input a target amount and date to save towards, from which a monthly savings amount will be calculated. If this is inconsistent with the customer’s current budget, then the system will advise the customer accordingly. This will allow the customer to modify the savings term (i.e. buy the car or go on the holiday later) or the target amount (i.e. buy a cheaper car or go on a cheaper holiday), or both of these (i.e. buy a cheaper car or go on a cheaper holiday later). The system, being connected to commercial banks as associated service providers, enables the customer to obtain bank account transactional details of the customer which is processed to compare against the budget that has been prepared for the customer. This allows the system to identify new budget items and note over expenditure. It also identifies a surplus, which allows it to determine a preferred option for allocation of such expenditure - for example savings, increasing medical aid cover, obtaining life insurance and so forth.

The system allows its customers to appreciate at all times their financial positions, comply with regulatory and administrative requirements, and meet commitments to ensure that the customer does not fall foul of any of the many pitfalls of modern life.

Since the customer’s transactional records are available to the system the customer is enabled to provide interested parties - for example a bank providing finance - with an accurate transactional history. This effectively improves the customer’s credit rating and effectively provides the customer with such a rating. It is envisaged that the system will be able to determine a credit rating in a format acceptable to financial institutions. This is very beneficial to especially young adults who may not yet have a credit history and therefore no credit rating.

The method and system with its various features and capabilities described above allows a user to test modifications to his business model that is not readily available otherwise. The ability to create alternate (modified) sets of rules and to test them in parallel with a current rule set allows a user to test with live and relevant data how a change in the business model that he applies will impact on the position of the business. This information is not otherwise available and due to the potentially vast nature of all the transaction data sources and the complex relationship between them, and the effect of this on the business, the outcome of even a single change is not predictable.

With this method and system a user is able to test multiple alternative models in parallel and with a simple comparison of sets of reports (that the user can also define), he is able to gain an immediate insight in how a change in his business model will impact on the essential elements of the business.

This is possible because the underlying principle remains that the method is rules-based and it refers always back to original data sources, and not to data that had already been filtered and had been allocated to inflexible accounting system accounts. The additional features such as document and data management add further functionality to the method and system and enables the method and system to provide comprehensive input and guidance to a user thereof. This allows a business owner to remain up to date with the obligations of his business, and to have advance warning of when he has to execute certain steps to remain compliant.

It will be appreciated that modifications of the above-mentioned embodiments and options are possible without departing from the essence of the invention.

Claims

1. A method of processing transaction data which includes:

defining an original set of reports to reflect aspects of data resulting from application of the original set of rules to data from the current transaction data sources; receiving data from a plurality of current transaction data sources and processing the data into categories by applying the original set of rules to the data; generating at least one report from the original set of reports which reflect the processed data;

creating one or more modified set of rules and modified set of reports to reflect updated user requirements;

processing, in parallel with the original set or rules, the transaction data, including historical transaction data, with at least one of the modified sets of rules to create for each of the applied sets of rules an associated set of reports;

selecting from the original set of rules and modified set of rules a new set of rules, and defining the new set of rules as an updated current set of rules with an associated updated current set of reports;

and updating the transaction data sources, and to the extent this impacts on them accordingly also updating the then current set of rules and then current set of reports.

2. A method as claimed in claim 1 in which the current set of rules are created and updated according to actions of users of the method, which is preferably augmented through any one or more of machine learning, artificial intelligence, and crowdsourcing.

3. A method as claimed in claim 1 or 2 in which the processing of transaction data includes:

providing data input means to a processor of a first financial institution to input transaction data to make a payment from a funding account to a beneficiary;

providing a transaction data field for input of an invoice number and an associated payment amount;

including the invoice number data and associated payment amount in data relating to the transaction; providing an interface between the first financial institution processor and a second financial institution processor nominated for receipt of the payment;

providing an interface between the second financial institution processor and the beneficiary financial system;

transmitting the transaction data from the second financial institution processor to the beneficiary financial system;

processing the transaction data by the beneficiary financial system to associate the transaction with an invoice associated with the invoice number; and

4. A method as claimed in claim 3 which includes providing a transaction data field for input of a plurality of invoice numbers each with an associated payment amount, for batching the invoice numbers to form a single transaction, and for including all the invoice numbers each with its associated payment amount in the transaction data.

5. A method as claimed in claim 4 which includes:

providing an interface between a payer financial system and financial institution transaction processor;

for the step of including the invoice number data and payment amount in data relating to the transaction to include selecting the invoice from a schedule of unpaid debtor invoices in the payer financial system and confirming payment of the associated invoice amount or including an alternative payment amount for payment towards to the invoice; and

6. A method as claimed in claim 5 which includes providing a transaction data field for input of an expense account number;

including the expense account number in the transaction data transmitted by the financial institution transaction processor to the payer financial system through the interface between them; processing the transaction data by the payer financial system to associate the transaction with the expense account associated with the expense account number; and

updating the payer financial records to reflect the payment against the invoice once the transaction has been completed.

7. A method as claimed in claim 6 which includes provide selection means to distinguish between private and business beneficiaries, and for the inclusion of the transaction data field where the beneficiary is a business, with input requiring completion of the transaction data field before the transaction will be processed.

8. A method as claimed in claim 1 or 2 in which the step of processing transaction data includes:

transmitting the invoice from the beneficiary to the payer;

making payment in respect of the invoice using the key as payment reference; transmitting an account statement from the beneficiary’s financial institution processor to the beneficiary financial system including data relating to the payment associated with the key; and

9. A method as claimed in claim 8 in which the transaction data is transmitted to the key generator by the beneficiary or the payer, and the key is transmitted by the key generator to the payer for association with the invoice prior to transmission to the payer, or the key generator transmits the key to the beneficiary for association with the invoice.

10. A method as claimed in any one of claims 1 to 9 which includes managing documents and data, comprising the steps of providing a network accessible server with an associated processor and database, a plurality of network accessible communication devices, and a plurality of service providers at least partly interfaced with the server; a person subscribing to the system as a customer by submitting identification and contact details to the server for storage in the database in association with an account associated with the customer;

• age,

• education level,

• current employment details,

• salary,

with the processor determining from the data input at least a customer’s nett financial position, record in the database in association with the customer’s account his future obligations, including financial and administrative obligations, and

transmitting to a customer’s communication device a reminder in respect of his future obligations.

11. A method as claimed in claim 10 in which:

• the budget information includes the customer’s income, monthly and annual expenses, and an asset list, including any of vehicles, property, and movables property; and

• the subscription services includes any one or more of:

o medical aid;

o insurance, including life insurance and short-term insurance; and o investments including property, stocks, and investment policies.

12. A method as claimed in claim 10 or 11 which includes verification of the customer’s identification and contact details, including by the customer submitting at least copies of documents carrying identification and contact details of the customer to the system, and more preferably by a verification agent submitting verified copies of documents bearing identification and contact details of the customer to the server.

13. A method as claimed in claim 12 in which the verification agent comprises an associated service provider, and verified copies of the documents bearing identification and contact details relating to the customer are transmitted to the server by the verification agent by means of the network for storage in the database in association with the customer’s account.

14. A method as claimed in claim 13 in which the system distributes verified copies of the documents bearing identification and contact details relating to the customer to all service providers that the customer has registered in association with its account, preferably immediately after such documents have been uploaded to the system.

15. A method as claimed in claim 14 in which the communication devices comprise mobile communication devices, including smart phones, smart devices, tablets and the like, and network accessible computers.

16. A system for processing transaction data which includes:

providing a processor with associated storage means and associated communication means,

storing on the storage means, for execution by the processor, an original set of rules to interpret data from a plurality of current transaction sources;

storing on the storage means an original set of reports for the processor to create to reflect aspects of data resulting from application of the original set of rules to data from the current transaction source;

the processor being configured to enable the creation of one or more modified set of rules, and modified set of reports to reflect updated user requirements, in parallel with the original set or rules and original set of reports; the processor being configured to process the transaction data, including historical transaction data, with each of the modified sets of rules to create for each set of rules its associated set of reports;

17. A method of processing transaction data substantially as herein described, with reference to any one or more of Figures 1 to 3.

18. A method of managing documents and data substantially as herein described.

19. A system for processing transaction data substantially as herein described, with reference to any one or more of Figures 1 to 3.