FIELD

[0001] The present disclosure generally relates to the field of computing platforms and interfaces.

INTRODUCTION

[0002] Embodiments described herein relate to cash management platforms and an automated computing platform for processing cash related data to generate interfaces for cash management.

SUMMARY

[0003] In accordance with an aspect, there is provided a system for generating an interactive interface for a cash management platform. The system has a server having non-transitory computer readable storage medium with executable instructions for causing one or more processors to configure a cash flow forecasting tool to process input data from a plurality of financial systems to align data formatting across the plurality of financial systems and to compute cash flow prediction data based on the processed input data, the cash flow prediction data indicating expected receipt dates, expected payment dates, and available cash for a plurality of time points. The system has an interface application to display visual elements indicating the cash flow prediction data, the interface application configured to receive data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points, transmit the data manipulation commands to the server. Upon detecting the data manipulation commands, the one or more processors configured to compute updated cash flow prediction data based on the data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points. The interface application updates to display updated visual elements based on updated cash flow prediction data, the interface application configured to receive additional data manipulation commands.

[0004] In some embodiments, the interface application is configured to receive the data manipulation commands for a time period, the one or more processors configured to compute updated cash flow prediction data based on the data manipulation commands for the time period, wherein the interface application updates to display updated visual elements based on updated cash flow prediction data for the time period.

[0005] In some embodiments, the interface application is configured to receive the data manipulation commands to select an invoice from the input data, the one or more processors configured to compute updated cash flow prediction data based on the data manipulation commands for the selected invoice, wherein the interface application updates to display updated visual elements based on updated cash flow prediction data for the selected invoice.

[0006] In some embodiments, the one or more processors configure a payment tool to compute payment transaction data based on the cash flow prediction data and compute transaction commands using the payment transaction data to trigger payments to vendor systems, wherein the interface application updates to display additional visual elements corresponding to the payment transaction data and receives additional data manipulation commands for the one or more processors to compute updated payment data, wherein the interface application updates to display updated additional visual elements based on the updated payment data.

[0007] In some embodiments, the one or more processors configure an automated receivables tool to receive payment data, wherein the cash flow forecasting tool computes updated cash flow prediction data based on the received payment data, the interface application to display updated visual elements based on the updated cash flow prediction data.

[0008] In some embodiments, the one or more processors configure a scenario library having a plurality of scenario records, wherein the cash flow forecasting tool computes the cash flow prediction data using at least one of the scenario records.

[0009] In some embodiments, the one or more processors configure the scenario library to receive a command to edit a scenario record from the interface application.

[0010] In some embodiments, the interface application depicts cash inflow transaction data as bars above a zero line and cash outflow transaction data as bars below the zero line.

[0011] In some embodiments, the interface application depicts transaction data based on the cash flow prediction data, the transaction data can be plotted on a graph based on time and amount. [0012] In accordance with an aspect, there is provided a non-transitory computer readable medium storing computer executable program code, which when executed by a processor, causes the processor to generate an interactive interface for a cash management platform by: processing input data from a plurality of financial systems to align data formatting across the plurality of financial systems and to compute cash flow prediction data based on the processed input data, the cash flow prediction data indicating expected receipt dates, expected payment dates, and available cash for a plurality of time points; displaying, at an interface application, visual elements indicating the cash flow prediction data, the interface application configured to receive data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points, and transmit the data manipulation commands; computing updated cash flow prediction data based on the data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points; and updating, the interface application, to display updated visual elements based on the updated cash flow prediction data.

[0013] In some embodiments, the code causes the processor to receive, at the interface application, the data manipulation commands for a time period, the one or more processors configured to compute updated cash flow prediction data based on the data manipulation commands for the time period, wherein the interface application updates to display updated visual elements based on the updated cash flow prediction data for the time period.

[0014] In some embodiments, the code causes the processor to receive the data manipulation commands to select an invoice from the input data, the one or more processors configured to compute updated cash flow prediction data based on the data manipulation commands for the selected invoice, wherein the interface application updates to display updated visual elements based on updated cash flow prediction data for the selected invoice.

[0015] In some embodiments, the code causes the processor to compute payment transaction data based on the cash flow prediction data and compute transaction commands using the payment transaction data to trigger payments to vendor systems, wherein the interface application updates to display additional visual elements corresponding to the payment transaction data and receives additional data manipulation commands for the one or more processors to compute updated payment data, wherein the interface application updates to display updated additional visual elements based on the updated payment data. [0016] In some embodiments, the code causes the processor to receive payment data, wherein the cash flow forecasting tool computes updated cash flow prediction data based on the received payment data, the interface application to display updated visual elements based on the updated cash flow prediction data.

[0017] In some embodiments, the code causes the processor to configure a scenario library having a plurality of scenario records, wherein the cash flow forecasting tool computes the cash flow prediction data using at least one of the scenario records.

[0018] In some embodiments, the code causes the processor to configure the scenario library to receive a command to edit a scenario record from the interface application.

[0019] In some embodiments, the code causes the processor to update the interface application to depict cash inflow transaction data as bars above a zero line and cash outflow transaction data as bars below the zero line.

[0020] In some embodiments, the code causes the processor to update the interface application to depict transaction data based on the cash flow prediction data, the transaction data can be plotted on a graph based on time and amount.

[0021] In another aspect, there is provided a method for generating an interactive interface for a cash management platform. The method involves: computing, at a processor, cash flow prediction data based on input data from a plurality of financial systems, the cash flow prediction data indicating expected receipt dates, expected payment dates, and available cash for a plurality of time points; displaying, at an interface application, visual elements indicating the cash flow prediction data, the interface application configured to receive data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points, and transmit the data manipulation commands; computing, at the processor, updated cash flow prediction data based on the data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points; and updating, the interface application, to display updated visual elements based on the updated cash flow prediction data, the interface application configured to receive additional data manipulation commands.

[0022] In some embodiments, the method involves receiving, at the interface application, the data manipulation commands for a time period, computing updated cash flow prediction data based on the data manipulation commands for the time period, and updating the interface application to display updated visual elements based on updated cash flow prediction data for the time period.

[0023] In accordance with an aspect, there is provided a cash management platform that can include a cash flow forecasting tool, payment tool, receivables tool, report tool, mapping tool, scenario library, and other functions. The platform connects to an interface application that depicts visual elements mapping to back end data. The interface application can receive commands for the platform to manipulate and update the back end data. The visual elements can link to the back end data via mappings, for example. The interface application then depicts updated visual elements based on the commands.

[0024] In accordance with an aspect, there is provided a system for cash management. The system has a server having non-transitory computer readable storage medium with executable instructions for causing one or more processors to configure a cash flow forecasting tool to process input data from a plurality of financial systems and compute cash flow prediction data for future bank account data based on the processed input data. The system has an interface application to display visual elements indicating the cash flow prediction data, the interface application configured to receive data manipulation commands, transmit the data manipulation commands to the server, and display updated visual elements based on updated cash flow prediction data. The one or more processors are configured to compute the updated cash flow prediction data based on the data manipulation commands.

[0025] In some embodiments, the one or more processors configure a payment tool to compute payment transaction data based on the cash flow prediction data and compute transaction commands using the payment transaction data to trigger payments to vendor systems.

[0026] In some embodiments, the one or more processors configure an automated receivables tool to receive payment data, wherein the cash flow forecasting tool computes updated cash flow prediction data based on the received payment data, the interface application to display updated visual elements based on the updated cash flow prediction data.

[0027] In some embodiments, the one or more processors configure a scenario library having a plurality of scenario records, wherein the cash flow forecasting tool computes the cash flow prediction data using at least one of the scenario records. [0028] In some embodiments, the one or more processors configure the scenario library to receive a command to edit a scenario record from the interface application.

[0029] In some embodiments, the interface application depicts cash inflow transaction data as bars above a zero line and cash outflow transaction data as bars below the zero line.

[0030] In some embodiments, the interface application depicts transaction data based on the cash flow prediction data, the transaction data can be plotted on a graph based on time and amount.

[0031] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0032] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0033] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.

DESCRIPTION OF THE FIGURES

[0034] Figure 1 is a diagram of a system for cash flow management.

[0035] Figure 2 is an example interface application for the cash management platform.

[0036] Figure 3 shows an example table for a traditional method.

[0037] Figure 4 shows example flowchart diagrams comparing a traditional approach to a new approach.

[0038] Figure 5 depicts example flowchart diagrams of an old approach compared to a new approach.

[0039] Figure 6 is a flowchart diagram of an example workflow. [0040] Figure 7 illustrates an example flowchart diagram for a workflow to set up a company record.

[0041] Figure 8 illustrates an example flowchart diagram for a workflow to create a scenario for an existing company record.

[0042] Figure 9 illustrates an example flowchart diagram for a workflow to edit a scenario in an existing company record.

[0043] Figures 10A, 10B, 10C, 10D, 10E, 10F illustrate an example data model for the platform.

[0044] Figures 11 A, 11 B, 11 C, 11 E, 11 F illustrate an example data model for the platform.

DETAILED DESCRIPTION

[0045] Embodiments of methods, systems, and apparatus are described through reference to the drawings.

[0046] Cash management platforms can assist businesses to manage cash. Cash may not be managed appropriately due to lack of knowledge (do not know they should manage it), lack of ability (do not know how to manage it/their advisors do not know how to manage it) or lack of time (cash flow forecasting, key to cash management, is a complex space as it is dynamic and granular, requiring a lot of manipulation and maintenance).

[0047] Embodiments described herein can automatically facilitate cash management, reduce time required to setup and maintain cash flow forecasts, provide a user interface where users do not realize they are manipulating a powerful forecasting system (that will be flexible/editable if desired by more astute users), and provide automated workflows that match work accounting/business situations.

[0048] Embodiments described herein can integrate with other business accounting systems to advance the level of automation.

[0049] Figure 1 is a diagram of a cash management platform 100 and an example physical environment. [0050] The platform 100 can include an I/O Unit 102, a processor 104, communication interface 106, and data storage 110. The processor 104 can execute instructions in memory 108 to implement aspects of processes described herein. The processor 104 can execute instructions in memory 108 to configure cash flow forecasting tool 120, payment tool 122, receivables tool 124, report tool 126, mapping tool 128, scenario library 132, and other functions described herein. The platform 100 may be software (e.g., code segments compiled into machine code), hardware, embedded firmware, or a combination of software and hardware, according to various embodiments.

[0051] The platform 100 can have one or more processors 104 to configure the cash flow forecasting tool 120 to process input data from a plurality of financial systems and compute cash flow prediction data for future bank account data. The platform 100 connects to the interface application 130 to display visual elements indicating the cash flow prediction data. The interface application 130 is configured to receive data manipulation commands, transmit the data manipulation commands to the platform 100, and display updated visual elements based on updated cash flow prediction data. The cash flow forecasting tool 120 can compute the updated cash flow prediction data based on the data manipulation commands.

[0052] In some embodiments, the one or more processors 104 configure a payment tool 122 to compute payment transaction data based on the cash flow prediction data and compute transaction commands using the payment transaction data to trigger payments to vendor systems.

[0053] In some embodiments, the one or more processors 104 configure an automated receivables tool 124 to receive payment data. The cash flow forecasting tool 120 computes updated cash flow prediction data based on the received payment data. The interface application 130 can display updated visual elements based on the updated cash flow prediction data.

[0054] In some embodiments, the one or more processors 104 configure a scenario library 132 for managing scenario records. The cash flow forecasting tool 120 computes the cash flow prediction data using at least one of the scenario records. In some embodiments, the one or more processors 104 configure the scenario library 132 to receive a command to edit a scenario record from the interface application 130. [0055] The platform 100 can also be used for treasury management (consolidating a number of bank accounts in multiple currencies for a single cash position viewpoint).

[0056] The cash management platform 100 can have a cash flow forecasting tool 120. This can involve the automatic generation of predictions of future bank account data (e.g. 3 to 6 months in advance) to help determine business strategy (e.g. who to pay, who to collect from, timing)

[0057] The cash management platform can have an automated payment tool 122. This can involve the automatic generation of predictions of future cash balance data. This can provide optics on who can be paid and when. The platform 100 can then automate the workflow between multiple parties for a streamlined payment process.

[0058] The cash management platform can have an automated receivables tool 124. The platform 100 can collect funds from customers through pre-authorized debits (PADs). Payments can be automatically made as per company terms, helping alleviate late payments.

[0059] The cash management platform can have a report tool 126 that automatically generate reports based on the data generated. The reports can be dynamic and custom for different data views and customers.

[0060] The cash management platform can use the report tool 126 for budgeting and planning. The platform 100 can extend features of cash flow forecasting for a longer forecast horizon (e.g. from 3 to 6 months to years) to generate future data for budgeting and planning. This can provide target data for companies.

[0061] The cash management platform 100 can provide an interface application 130 with visual elements based on data generated by the cash flow forecasting tool 120. The cash management platform 100 can provide an automated payment tool 122 with different payment routines. The cash management platform 100 can provide a scenario library 132 as a tool that can assist in rapid development of forecasts.

Cash flow forecasting interface

[0062] Embodiments described herein can provide dynamic and complex forecasting. An example can relate to forecasting realistic receipt dates (in the case of AR) and payment dates (in the case of AP) out 2 to 4 months. The cash flow forecasting tool 120 can be configured for generating forecast data for spending and revenues (and related receipt and payment dates). The process is highly iterative and the data can be become outdated quickly (as you likely received some cash, someone changed their terms, you have changed spending expectations in the short term, etc.) so can involve continuous generate of the forecasting data. The forecasting data can be used to generate visual elements for interface application 130. The platform 100 can generate data (expectations) for future receipts, payments, revenue, spending, and so on.

[0063] The platform 100 generates, controls and dynamically updates an interface application 130 to improve the presentation of the information and format. For example, the interface application 130 can indicate visual elements for cash inflows or outflows that created a given cash flow situation. The interface application 130 can provide insight into reasoning behind forecasting data. Was the primary reason that day, a day before a week before? Was it more than one reason?

[0064] The platform 100 uses cash flow forecasting tool 120 to generate future cash position data that can dictate strategy and decision making data. The platform 100 can then forecast a range of items required, and the underlying logic of the platform 100 can be configured and customized for users to fit their desires.

[0065] The interface application 130 can include a graph portion that can map to individual invoices over time. The interface application 130 can include another graph portion that can indicate a cumulative cash position line graph, for example, showing the addition/subtraction of each individual invoice to the bank accounts being forecast over time.

[0066] The I/O unit 102 can enable the platform 100 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, and/or with one or more output devices such as a display screen and a speaker.

[0067] The processor 104 can be, for example, any type of general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, or any combination thereof.

[0068] Memory 108 may include a suitable combination of any type of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like. Data storage devices 110 can include memory 108, databases 112 (e.g. graph database), and persistent storage 114.

[0069] The communication interface 106 can enable the platform 100 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network 140 (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

[0070] The platform 100 can be operable to register and authenticate users (using a login, unique identifier, and password for example) prior to providing access to applications, a local network, network resources, other networks and network security devices. The platform 100 can connect to different machines, entities 150, and/or data sources 160 (linked to databases 170).

[0071] The data storage 110 may be configured to store information associated with or created by the platform 100, such as for example data relating cash flow, payments, receivables, scenarios, invoices, and so on. The data storage 610 may be a distributed storage system, for example. The data storage 110 can implement databases, for example. Storage 110 and/or persistent storage 114 may be provided using various types of storage technologies, such as solid state drives, hard disk drives, flash memory, and may be stored in various formats, such as relational databases, non-relational databases, flat files, spreadsheets, extended markup files, and so on.

[0072] Figure 2 is an example interface application 130 for the cash management platform 100.

[0073] The interface application 130 includes visual elements for a line graph to indicate a cumulative total of cash inflows/outflows over time. The example shows a broken line graph but it can also be smooth line graph. [0074] The interface application 130 includes visual elements for a bar graph. A user can click and hold on a bar and move left or right to affect change in the forecast. Once done, this will update the line graph above to show the user how their change affected cash position.

[0075] In some embodiments, the interface application 130 depicts cash inflow transaction data as bars above a zero line and cash outflow transaction data as bars below the zero line. In some embodiments, the interface application 130 depicts transaction data based on the cash flow prediction data, the transaction data can be plotted on a graph based on time and amount.

[0076] The interface application 130 includes visual elements for a time zoom. This shows all past data in the accounting system as well as future forecasted data in a different color. The user can use this tool to pan on different time frames or zoom in and out on the time scale itself.

[0077] The interface application 130 includes visual elements for scenarios. The user can make changes to data and create different scenarios in doing so. The scenarios can be managed by scenario tool 132. After updating or creating scenarios, more lines can show in area A, providing an easy visual comparison for how changes made to the scenario impact cash flow relative to the normal/case.

[0078] The interface application 130 provides a complete vision of all transactions in the past and future may mapping to a complex dataset. For example, a large "bar" in the past or future (area B) that significantly changed the line graph in area A is likely the "cause" of cash flow issues. Upon detection of the anomaly/outlier, the user can drag and drop the bar to change its timing, or click to edit its amount (if necessary). The manipulation is direct. In other systems, after finding the anomaly in a line graph or other format, the user then has to click through to another page/state in order to edit. Again, this might be uncomfortable for less savvy users, or just too time consuming for others.

Automated payment routine

[0079] The manual process in the accounting world can involve getting your accounting system current, forecasting your cash position, and determining if you have enough money to make payments. If you had enough to make payments, you would then: create a list of outstanding accounts payable (AP), compare to amount available to spend, allot funds to outstanding AP, with consideration for priority vendors and/or "squeaky wheels", and potentially send this list out for approval. After receiving approval, you would then create payments from the accounting system or payment system. If cheques you would need the payments signed, then you would need to manually process the cheques through the postal system (i.e. stuff envelopes, place stamps, put in mailbox, etc.) If electronic payments, you likely need these approved by appropriate personnel

[0080] The cash flow forecasting tool 120 can automatically determine how much money is available at any point for spending (by maintaining a reserve at all points in the future, or at a minimum a zero cash position balance). The automated payment tool 122 can automatically trigger payments based on the cash flow data.

[0081] The manual method involves multiple people and multiple steps that take time and are error prone. The automated process would be more efficient and use electronic messages, for example. By creating a consistent framework within which this process is handled, potential errors would be greatly reduced or eliminated. The platform 100 can also have the ability to provide additional flexibility not possible before (i.e. pay multiple methods through one single system instead of paying electronically online and/or cheque process) and creates a seamless interface for all methods of payment.

Scenario library

[0082] In forecasting cash flow, users typically have to build step by step. Take the case of adding an employee. The user has to add a salary expense, but likely also additional benefits, increased ongoing office costs, potentially increased computer hardware spending, and so on.

[0083] The platform 100 can have a build feature where users do this once, but can save the sequence of changes as a template. The template can be part of the scenario library 132, for example. Then, in the future, they can use the interface application 130 to drag and drop or “single click” this template into a forecast as they see fit. This would greatly reduce the time it would take to create forecasts as modelling can be repetitive. Additionally, it can greatly reduce errors as a large sequence of steps can be easily forgotten by a user in the future. This can make future forecasts more accurate.

[0084] The platform 100 can include servers, hosting hardware, and network infrastructure. The platform 100 can include an application stack. The platform 100 can have an application programming interface (API). The platform 100 can also implement a serverless Architecture, with function based hosting. [0085] The platform 100 can implement the following data flow. The platform 100 can import data from different data sets and systems. The platform 100 can calculate an average daily rate (ADR) for example.

[0086] The platform 100 can create a base case with calculations and forecasting. The platform 100 can override any outstanding invoices with projected ADR/ADP dates, instead of due date. The platform 100 can calculate a running total of the bank account totals. The platform 100 can calculate potential recurring transactions. This can involve filtering down companies with multiple transactions within a time period. This can involve computing a standard deviation of days apart between similar transactions by value within that dataset. If enough similar transactions are found, then the platform 100 can create forecasted transactions ahead in time.

[0087] The platform 100 can calculate categorized monthly averages and create forecasted transactions ahead in time for any remaining transactions not already forecasted.

[0088] All of this calculated and imported data can be modified to extend the base case across the company, or to create scenarios which inherit the base case calculations (and any alterations that it may contain).

[0089] Figure 7 illustrates an example flowchart diagram for a workflow to set up a company record. The process involves the sign in stage. The interface application 130 can display an “add company” button to trigger the workflow. The process involves a company set up stage. The interface application 130 receives input data for company details such as name and description. The interface application 130 receives a selection of the company data source. The interface application 130 receives a command to connect to a accounting system. The interface application 130 receives the input data for provision to platform 100. The platform 100 creates a company record in stores this company record. The platform 100 sets up cash and credit accounts using the data from the company data sources. The interface application 130 receives a command to select cash accounts. The interface application 130 receives a command to select credit accounts. The interface application 130 provides the selections to platform 100. Platform 100 generates forecasting data. The interface application 130 displays visual elements indicating the company forecasting data at a forecast dashboard.

[0090] Figure 8 illustrates an example flowchart diagram for a workflow to create a scenario for an existing company record. The process involves a sign in stage. The interface application 130 can display a select company button to trigger the workflow. The interface application 130 can display a forecast dashboard that has a view or visual elements for a base case cash flow. The interface application 130 can display a create new scenario button to trigger the workflow. The interface application 130 receives input data for scenario details such as name, description, colour, and so on. The interface application 130 provides the input data to platform 100 to create the scenario. The platform 100 creates and stores the scenario using the input data. The platform 100 can generate forecasting data based on the scenario. The interface application 130 can update the forecast dashboard with visual elements to indicate the scenario with the base case forecast data.

[0091] Figure 9 illustrates an example flowchart diagram for a workflow to edit a scenario in an existing company record. The interface application 130 can display select scenario button to trigger the workflow. The interface application 130 can display different scenario related buttons to trigger different actions. For example, the interface application 130 can display a you scenario details button, add scenario details button, edit scenario details button, duplicate scenario button, delete scenario button, toggle scenario visibility button (on/off), and so on. Activation of the buttons can trigger different scenario related workflows. For example, selection of the add scenario details button can trigger a workflow to add a scenario for accounts receivables or to add a scenario for accounts payables. As another example, selection of the edit scenario details button can trigger workflow to edit a scenario for accounts receivables or to edit a scenario for accounts payables. The buttons indicate different ways that a scenario can be edited.

[0092] Figures 10A, 10B, 10C, 10D, 10E, 10F illustrate an example data model for the platform 100. The database model indicates different classes or data objects. A class or data object can be associated with different attributes. The attributes can be primary keys are foreign keys for example. The keys can link different instances or records of classes or objects. For example there can be a session class that has different attributes such as session keys, expiration date, session data, and so on. The session class can be used to generate base succession objects for example.

[0093] There can be classes or data objects relating to accounting data. For example there can be a credit note class that has different attributes such as identifier, company, contact, organization, applied date, credit note identifier, credit note number, credit note status, credit no type, currency code, currency rate, fully paid date, import source, issue date, last modified date, remaining credit date, subtotal, total, total tax, and so on. The company, contact, or organization can provide one or more keys for example. There can be an organization class that has different attributes such as identifier, company, organization, base currency, country code, created date, default tax, financial year end date, financial year and month, import source, is demo company, legal name, line of business, name, organization ID, organization type, time zone, version. The company or organization can provide one or more keys. There can be a scenario alteration class that has different attributes such as identifier, organization, scenario, user, added row, company name, creative, forecasted row, key, modified, removed row, total, transaction date, UUID, and so on. The organization and scenario can provide one or more keys. There can be a credentials class that has different attributes such as identifier, company, organization, callback URI, connection start, consumer key, consumer secret, import source, authorization expires at, authorization token, token secret, realm ID, verified, and so on. The company an organization can provide one or more keys.

[0094] Other example classes relating to accounting data are an import administrator class, payment class, scenario class, invoices class, bank transactions class, contacts class, accounts class. The payment class can have different attributes such as identifier, account, company, contact, invoice, organization, currency rate, import source, is reconciled, last modified date, payment amount, payment date, payment identifier, payment status, payment type, and so on. The scenario class can have different attributes such as identifier, company, organization, base case, colour, created, modified, name, UUID, visible, and so on. The invoice class can have different attributes such as identifier, bank account, company, contact, organization, amount credited, amount due, amount paid, currency code, currency rate, due date, fully paid date, import source, invoice identifier, invoice number, invoice status, invoice type, issue date, last modified date, subtotal, total, total discount, total tax, and so on. The bank transaction class can have different attributes such as identifier, bank account, company, contact, organization, currency code, currency rate, import source, is reconciled, last modified date, subtotal, total, total tax, transaction date, transaction identifier, transaction status, transaction type, and so on.

[0095] The contacts class can have different attributes such as identifier, company, organization, ADP in days, ADP override, ADR in days, ADR override, average amount paid, average amount paid override, average amount received, average amount override, company name, contact identifier, import source, is customer, is supplier, UUID, and so on. The accounts class can have different attributes such as identifier, company, organization, account code, account description, account identifier, account name, account status, account type, bank account number, bank account type, calculated total, class type, currency code, enable payments, import source, import use, last modified date, system account name, tax type, UUID, and so on.

[0096] There can be classes relating to order data. Examples include an order class and plan class. The order class can have different attributes such as identifier, organization, plan, user, created, modified, reference, total, and so on. The plan class can have different attributes such as identifier, active, creative, features, modified, name, price, and so on.

[0097] There can be classes that relate to company data. Examples include a company user class and company class. The company user class can have different attributes identifier, company, organization, user, access granted, access removed, created, modified, permission, and so on. The company class can have different attributes such as identifier, organization, active, country, currency, data source, description, name, time zone, UUID, year-end day, year- end month, and so on.

[0098] There can be that classes relate to user data. Examples include user organization class, user class, organization class, abstract user class, time stamped model class, base user class, and permission class. The user organization class can have attributes such as identifier, invited by, organization, user, created, invited, level, modified, and so on. The user class can have different attributes such as identifier, organization, avatar, date join, email, first name, is active, is staff, is superuser, last login, last name, level, name, password, phone, time zone, and so on. The user class can be linked to a tenant model the organization class can have different attributes such as identifier, customer, account type, created, modified, name, subdomain, website, and so on. The abstract user class can have different attributes such as date join, email, first name, is active, is staff, is superuser, last login, last name, password, username, and so on.

[0099] There can be classes that relate to authorization account data. Examples include email confirmation class, email address class, social token class, social account class, social application class, and so on. There can also be a REST token authentication class. The email confirmation class can have different attributes such as identifier, email address, created, key, sent, and so on. The email address class can have different attributes such as identifier, user, email, or primary, verified, and so on. The social token class can have different attributes such as identifier, account, application, expires at, token, token secret, and so on. The social account class can have different attributes such as identifier, user, date join, extract data, last login, provider, UID, and so on. The social app class can have attributes such as identifier, client identifier, key, name, provider, secret, and so on.

[00100] The different classes can have groups and permissions associated with them that can be defined through group classes and permission classes. The group class can have different attributes and the permission class can have different attributes.

[00101] There can be classes that relate to payment data. Examples include refund class, charge class, invoice class, invoice item class, payout class, dispute class, subscription class, card class, source class, bank account class, event trigger class, plan class, customer class, transfer class, account class, event class, product class, coupon class, payment method class, file upload class, and so on.

[00102] The refund class can have different attributes such as identifier, charge, amount, created, currency, description, created date, updated date, failure reason, live mode, metadata, reason, receipt number, status, and so on. The charge class can have different attributes such as identifier, account, customer, dispute, invoice, source, transfer, amount, amount refunded, captured, created, currency, description, created date, updated date, failure code, failure message, fee, fee details, fraud details, fraudulent, live mode, metadata, outcome, paid, receipt email, receipt number, receipt scent, refunded, shipping, source identifier, source type, statement descriptor, status, transfer group, and so on. The invoice item class can have different attributes such as identifier, customer, invoice, plan, subscription, amount, created, currency, date, description, discount double, created, updated, live mode, metadata, period, period start, period end, proration, quantity, and so on. The invoice class can have different attributes such as identifier, charge, customer, ascription, amount due, amount paid, amount free painting, application fee, attempt account, billing, closed, created, currency, date, description, created date, updated date, due date, ending balance, forgiven, hosted invoice URL, invoice PDF, live mode, metadata, next payment attempt, number, paid, period, period start, period end, receipt number, starting balance, statement descriptor, subscription proration date, subtotal, tax, tax percent, total, delivered at, and so on. The dispute class can have different attributes such as identifier, amount, created, currency, description, created date, updated date, evidence, evidence details, is charge refundable, live mode, metadata, reason, status, and so on. The subscription class can have different attributes such as identifier, customer, plan, application fee percent, billing, billing cycle, cancel, created date, current period, days until do, description, created date, updated date, ended at, live mode, metadata, quantity, start, status, tax percent, trial, and so on. The card class can have different attributes such as identifier, customer, address city, address country, address, address date, brand, country, created date, the check, description, created date, updated date, dynamic last, expiration, fingerprint, funding, live mode, metadata, name, tokenization method, and so on. The source class can have different attributes such as identifier, customer, amount, client secret, code verification, created, currency, description, created date, updated date, flow, live mode, metadata, owner, receiver, redirect, source data, statement descriptor, status, type, usage, and so on. The bank account class can have different attributes such as identifier, account, customer, account holder name, account holder type, bank name, country, created date, currency, description, created date, updated date, fingerprint, live mode, metadata, routing number, status, and so on. The transfer class can have different attributes such as identifier, amount, amount reverse, created, currency, date, description, destination, destination payment, destination type, created date, updated date, failure code, failure message, the, fee details, live mode, metadata, reversed, source transaction, source type, statement descriptor, status, transfer group, and so on. The plan class can have different attributes such as identifier, product, aggregate usage, amount, billing scheme, created, currency, description, created date, updated date, interval, live mode, metadata, name, nickname, statement descriptor, tears, transform usage, trial, usage type, and so on. The customer class can of different attributes such as identifier, coupon, default source, subscriber, account balance, business ID, coupon and, coupon start, created, currency, date purged, delinquent, description, created date, updated date, email, live mode, metadata, shipping, and so on. The account class can have different attributes such as identifier, business logo, business name, business URL, charges enabled, country, created, debit negative balances, decline charge, default currency, description, details submitted, display name, created date, updated date, email, legal entity, live mode, metadata, payout schedule, payout statement descriptor, payouts enabled, product description, statement descriptor, support email, time zone, acceptance, type, verification, and so on.

[00103] The event class can have different attributes such as identifier, API version, created, data, description, created date, updated date, key, live mode, metadata, request identifier, type, and so on. The product class can have different attributes such as identifier, active, attributes, caption, created, deactivate, description, created date, updated date, images, live mode, metadata, name, package dimensions, shippable, statement descriptor, type, unit label, URL, and so on. The object class can have different attributes such as created, description, created date, updated date, live mode, metadata, and so on. The coupon class can have different attributes such as identifier, amount, created, currency, description, created date, updated date, duration, live mode, max redemptions, metadata, percentage off, redeem by, times redeemed, and so on. The payment method class can have attributes such as identifier, type, and so on. The file upload class can have different attributes such as identifier, created, description, created date, updated date, filename, live mode, metadata, purpose, size, type, URL, and so on.

[00104] Classes can have common attributes. The common attributes can serve as keys to link instances of classes together. An instance of a class can be referred to as a record for example. The different fields of the record can correspond to the different attributes of the class. The fields or attributes of one record can act as a key to link the record to another record with corresponding fields or attributes. The lines and dots shown connecting different classes can indicate links by keys, for example.

[00105] Figures 11 A, 11 B, 11 C, 11 E, 11 F illustrate an example data model for the platform 100. There can be classes relating to order data. Examples include an order class and plan class. There can be classes that relate to company data. Examples include a company user class and company class. There can be classes that relate to accounting data. There can be that classes relate to user data. Examples include user organization class, user class, organization class, abstract user class, time stamped model class, base user class, and permission class. The model indicates links between attributes of different classes. The model can be used by mapping tool 128 to generate visual elements using the back end data stored as different instances of classes. The example database model shown in Figures 11 A, 11 B, 11 C, 11 E, 11 F has similar classes or objects as shown in Figures 10A, 10B, 10C, 10D, 10E, 10F. The classes or objects can have similar attributes as described in relation to Figures 10A, 10B, 10C, 10D, 10E, 10F.

[00106] Similar to Figures 10A, 10B, 10C, 10D, 10E, 10F, the classes shown in Figures 11 A, 11 B, 11 C, 11 E, 11 F can have common attributes. The common attributes can serve as keys to link instances of classes together. An instance of a class can be referred to as a record for example. The different fields of the record can correspond to the different attributes of the class. The fields or attributes of one record can act as a key to link the record to another record with corresponding fields or attributes. The lines and dots shown connecting different classes can indicate links by key attributes (e.g. foreign keys), for example. [00107] The platform 100 can receive data from a plurality of financial systems to align data formatting across the plurality of financial systems. The platform 100 processes the data using the data models. The data can be modelled using the different classes and attributes. The classes enable data from different data sets to be integrated based on common models. The processed data can be used to compute cash flow prediction data based on the processed input data. The cash flow prediction data can indicate expected receipt dates, expected payment dates, and available cash for a plurality of time points.

[00108] The platform 100 implements improved interfaces for the display of visual elements indicating the cash flow prediction data. The user interacts with the interface to receive data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points. The interface transmits the data manipulation commands to the server to regenerate the interface with updated visual elements. Upon detecting the data manipulation commands, the system computes updated cash flow prediction data based on the data manipulation commands for at least one of the receipt dates, the payment dates or the available cash for the plurality of time points. The interface application updates to display updated visual elements based on updated cash flow prediction data. The interface application is configured to receive additional data manipulation commands to keep regenerating visual elements.

[00109] The platform 100 combines cash flow forecasting tool 120 with automated payment tool 122 to generate predictions and automatically trigger payments based on the prediction data. This can consider queries such as "if I pay this bill, will I have enough for that one?".

[00110] The platform 100 can use data computed by the cash flow forecasting tool 120 and automates other functions that stem from the predictions.

[00111] The scenario library 132 can be used to define scenario templates and generate scenario instances from the templates. The scenarios can be used to generate data for forecasting.

[00112] The platform 100 can check recent transactions and ensure there are not duplicates in the system for computing the forecast data. The platform 100 can update AR and AP listings and roll the forecast data forward. Different scenarios can be run against this data. A user can manipulate data and make changes to the data using the interface application 130. [00113] The platform 100 can compute cash flow forecast data and then compute data for, what that allows for an AP run, and what AP can be allotted in that run instantaneously. Once an AP run is determined, the platform 100 can automatically create payments as part of the workflow.

[00114] The interface application 130 generates visual elements for graphs with bars that can be linked with date and amount. The interface application 130 can generates visual elements for invoices along with a heat map based on amount, displayed over time, for example.

[00115] The user can directly manipulate the data using the graphic interface. The interface application 130 can allow the bar to expand vertically to change to the invoice amount, for example. The interface application 130 can trigger the display of call out boxes on hovering over the bars. The interface application 130 can be used for invoice financing and other alternative financing, quick payments, utilize interface with other reporting forecasting manipulations, for example. The interface application 130 can have profit and loss budget bars that can represent expenses and revenues, for example. The interface application 130 can have a line graph that can represent a metric such as net income or EBITDA. The interface application 130 can have balance sheet budget bars that can indicate asset purchases, loan payments, loan draw, etc. and line graph that can indicate net assets or another metric.

[00116] The platform 100 can implement cash flow forecasting and computes a recommended AP run that then ties into other parties for processing.

[00117] The following provides example use cases.

[00118] The platform 100 can use the cash flow forecasting tool and interface application 130 for data manipulation. This can be used for small business users and advisors (bookkeeper/accountant). The use case for the interface application 130 can use cash flow forecast data and enables the user to manipulate the data. For example, a user needs to determine if/when their cash flow is low in the next 60 day period (low meaning below zero, meaning the company has no cash/money). Within this time frame the cash balance might not fall below zero, and the user needs to manipulate (time shift/move) the largest payable invoice in order to ensure a positive cash balance (i.e. they need to delay payment to keep money in the bank). [00119] Figure 3 shows an example table for a traditional method. The data is shown in a tabular or list format. Granular cash flow forecasts (i.e. forecasts you want to see by the day) can be represented as line by line data tables, listing out the cash flows in and cash flows out. The reason for this is that weekly and monthly tables typically aggregate data, at which point it is hard to discern what is improving or degrading cash position specifically. To build out the data table the user has to either go through paper records or electronic records to create a starting point that is a total cash position at time 0. This is the sum of all bank accounts and/or all related credit accounts (credit cards, lines of credit, etc.) that affects the users cash position at any point in time. The user manually develop/estimate a list of transactions that will occur in the future, including the following examples: known receipts (e.g. existing AR in the system that is assured to be collected, with an estimated collection date); known payments (e.g. existing AP in the system that is assured to be paid, with an estimated payment date); estimated receipts (e.g. AR related transactions (sales) or financing/equity transactions (loan disbursements, equity raises, etc.) that are expected to occur in the future, with an estimated amount and collection date); and estimated payments (e.g. AP related transactions (expenses, capital purchases) or financing/equity transactions (loan repayments, dividends, etc.) that are expected to occur in the future, with an estimated amount and collection date). The user then manually lists these items out chronologically and creates a running total of the cash starting point with the transactions as they occur. This information can tell the user what their estimated cash position can be in the future based on their known and estimated information. As the complexity and volume of the accounting data increases, the likelihood of error using this traditional method of cash forecasting dramatically increases, as does the time involved with developing it and maintaining it. A manual process can determine where the users bank balance goes below zero. If there is no chart associated to the forecast, the user will have scan the list of data to see where their cash balance goes below zero. With a time period narrowed down for the cash balance going below zero, the user will then have to scan the listing back in time to see what large payable invoices occurred. The user will have to make note of these invoices and select the largest one that isn't a prioritized payment (i.e. payroll, rent, items that cannot be delayed due to importance on your operations).

[00120] We can assume that this one invoice is enough to change future cash balances to positive if delayed past our 60 day timeframe/window. To move this item out of the forecast, the user will have to: manually enter a new date in the time cell; cut and paste the line into the appropriate time frame (or sort the table by date); and delete the line out of the table altogether. Then the user will have to ensure that all of their formulae for the entire table are correct to ensure the correct calculations/results are being worked towards. In the case of deleting the line, the user can then have to somehow remember to pay that item at some point in the future (not insurmountable by re-running the entire report). The user can re-assess either their cash balance data to ensure the cash balance is indeed where they want it to be (i.e. above zero), or they will have to re-assess their graph to do the same.

[00121] Embodiments described herein provide an improved process and interface. As noted, Figure 2 shows an example interface application 130 according to some embodiments. The interface application 130 has a line graph at the top of our page illustrating the ending cash balance of each day (section A) and a bar graph below this denoting each individual invoice affecting the cash balance/line graph (section B).

[00122] To build out the forecast the user opens the interface application 130. In the background, the interface application 130 will interact with the platform 100 to integrate with the users’ accounting system data. The platform 100 can scan their current financial information to determine the starting cash position of the business. The platform 100 can scan their past financial information to determine realistic expectations of collection times for known receipts (i.e. customer A pays in 37 days on average, it is reasonable to expect any AR in the system to then be paid in 37 days of the invoice date). The platform 100 can estimate recurring receipts. Where there is a trend of an AR item occurring in a frequent timing pattern, the platform 100 can predict this to continue in the future (i.e. monthly recurring sales contract with customer B)

[00123] The platform 100 can estimate recurring payments. Where this is a trend of an AP or expenditure item occurring in a frequent timing patter, the platform 100 can predict this to continue in the future (i.e. monthly recurring wages, rent, loan payments, etc.).

[00124] The platform 100 can determine realistic expectations of collections times for known payments. The platform 100 can ultimately manipulate this (i.e. move payment dates around) in order to optimize cash position however, so the initial run is simply a starting point.

[00125] The platform 100 can then combine this information graphically to update visual elements of interface application 130. Every transaction can displayed graphically/visually (as a bar in our current method, though this could be a number of different formats). For example, cash inflow transactions can be bars above the zero line in graph B. Cash outflow transactions can be bars below the zero line in graph B. Transactions can be plotted in graph B based upon time (e.g. the horizontal position of the bar will be dictated by its real/expected transaction date) and amount (e.g. the vertical height of the bar will be dictated by the dollar value of the transaction).

[00126] The vertical scale can change based on total transactions being viewed in the time period selected so that all bars can display. The horizontal scale can be selected by the user, and the rest of the graphs (both A and B) can adjust in scale/proportion automatically.

[00127] With each transaction plotted in proportion to time and amount, graph A can then automatically aggregate the daily totals of the transactions, and display a line graph of these transactions on a cumulative basis. Combining this information with the starting cash position information, graph A becomes a line graph of the users daily cash position at any point in the time period being viewed. To see when the cash balance is below zero the user scans graph A. They have their reference point. The user then can to find the largest payable invoice in graph B (i.e. those bars below the zero line - which will be more prominent in future iterations). From here the user can click and hold the largest invoice that is not a prioritized payment (i.e. payroll, rent, items that cannot be delayed due to importance on your operations). In some embodiments, the interface application 130 can lock priority payments in the graph or create different visual elements for priority payments so that the priority payments are easy to discern. Users will be able to see all relevant invoice data in graph B, including invoice amount, invoice date, vendor/supplier name and invoice number (via a callout box/pop up box when a user hovers over the data). The user can then drag and drop the invoice to a future date so that graph A remains positive in the specified time frame.

[00128] Figure 4 shows example flowchart diagrams comparing a traditional approach to a new approach.

[00129] Embodiments described herein can implement a process with fewer steps and direct interaction with the data (in terms of data manipulation). This can result in fewer areas for human error (less data manipulation required). The process inherently easier for users to understand a graph versus a data table. The process can be easier for user to see outliers (large dollar amount invoices) on a graph versus a data table. The speed of which the steps can be carried out can also be faster.

[00130] An example use case for the interface application 130 can determine if/when their cash flow is low in the next 60 day period (low meaning below zero, meaning the company has no cash/money). We will say that within this time frame the cash balance does fall below zero, and the user needs to manipulate (time shift/move) the largest payable invoice in order to ensure a positive cash balance (i.e. they need to delay payment to keep money in the bank).

[00131] As shown in Figure 2, the interface application 130 can integrate data into a single view and update data with clicks to trigger data manipulation. The interface application 130 can display transactional information individually and graphically, for example. To build out the forecast in the platform 100, the user simply opens the interface application 130. In the background, the interface application 130 can integrate with the users accounting system and scan their current financial information to determine the starting cash position of the business. The platform 100 can scan their past financial information to determine realistic expectations of collection times for known receipts, estimate recurring receipts, estimate recurring payments, and determine realistic expectations of collections times for known payments. The platform 100 can manipulate this data (i.e. move payment dates around) in order to optimize cash position however, so the initial run is simply a starting point. The platform 100 will then combine this information graphically. Every transaction can displayed graphically/visually (as a bar in the example shown, though this could be a number of different formats). Cash inflow transactions can be bars above the zero line in graph B. Cash outflow transactions can be bars below the zero line in graph B.

[00132] Transactions can be plotted in graph B based upon time (e.g. the horizontal position of the bar will be dictated by its real/expected transaction date) and amount (e.g. the vertical height of the bar will be dictated by the dollar value of the transaction). In terms of scale note that the vertical scale can change based on total transactions being viewed in the time period selected so that all bars can display. The horizontal scale can be selected by the user, and the rest of the graphs (both A and B) can adjust in scale/proportion automatically.

[00133] With each transaction plotted in proportion to time and amount, graph A can then automatically aggregate the daily totals of the transactions, and display a line graph of these transactions on a cumulative basis. Combining this information with the starting cash position information, graph A becomes a line graph of the users daily cash position at any point in the time period being viewed. [00134] To see when the cash balance is below zero the user scans graph A. They have their reference point. The user then needs to find the largest payable invoice in graph B (i.e. those bars below the zero line which can be more prominent visual elements, for example).

[00135] From here the user can use an input device to click and hold the largest invoice that is not a prioritized payment (i.e. payroll, rent, items that cannot be delayed due to importance on your operations). As noted, priority payments can be locked in the graph or create a different visual for people so priority payments are easy to discern. In some embodiments, all relevant invoice data can be shown in graph B, including invoice amount, invoice date, vendor/supplier name and invoice number (via a callout box/pop up box when a user hovers over the data). The user can then drag and drop the invoice to a future date so that graph A remains positive in the specified time frame.

[00136] Figure 5 depicts example flowchart diagrams of an old approach compared to a new approach.

[00137] Embodiments described herein use fewer steps required as the process is slightly more direct (in terms of data manipulation). As an example, to manipulate an existing sales invoice expected date (date in which it is forecast/predicted to be received). Embodiments can use a method that is more direct in terms of time shifting, you simply drag and drop and see the change. Over the course of multiple invoice changes, the time savings for end users can be significant. The more complex the data set, the more time savings our method would provide.

[00138] An example use case relates to an automated payment routine. This use case covers a typical "pay run" for a small business. Essentially bills need to be paid, so it is a question of carrying this out.

[00139] Traditionally small businesses assess what is in their bank account and pay bills accordingly. They likely determine how to pay by adding up their current bank balances, and they likely determine who to pay predominantly based off the age of outstanding bills or subjectively by which vendor is complaining the most. Once determined, someone on the team carries out physically issuing the payments, getting signatures, mailing as appropriate, etc.

[00140] Figure 6 is a flowchart diagram of an example workflow. There can be issues with the workflow. For example, there can be no visibility on the future bank balance in the process. If the current bank balance is $10,000 as an example, $5,000 is processed in payments from the workflow, but $6,000 of payments is automatically withdrawn tomorrow (i.e. rent, payroll, any other auto debits), the company does not have enough funds to complete the auto debit.

[00141] There is typically no structure in assessing who to pay. Quite often small business owners pay the "squeaky wheel" first. This might not be the best person to pay however, if funds are limited and there are other vendors who are higher in priority (i.e. payroll, government remittances, etc.).

[00142] Creating payments is manual. There are multiple steps in this process depending on how a payment is made, especially in the case of cheques. This is time consuming, and therefore inefficient and costly.

[00143] The workflow can become complex as duties are segregated. For instance, the controller could assess the cash position, they then pass the information to the AP clerk to assess who to pay, a pay run is then determined and passed back to the controller for approval, which is then passed back to the AP clerk to create payments from, which are then passed back to the controller and management for final signature/approval. This continual change of hands creates further inefficiencies and room for human error. Another workflow may include higher level cash flow analysis functions provided to mid-management, office admin tasks are assigned to an administrator, and management approves the final product. A lot of processes cross hands, a lot of tasks (and time), and a lot of opportunity for human error.

[00144] Embodiments described herein use an automated workflow to assess the cash position (cash flow forecast) and enable a user to interact with the data using data manipulation commands. The commands are used to update the interface. Embodiments described herein use an automated workflow to assess payables and this process is done once within the platform 100, where the user sets up their vendor priorities. The platform 100 then automates this process each time a pay run is desired, and it determines how to pay vendors at that time using the information and the cash available as determined by forecasting data. Embodiments described herein use an automated workflow to implement payments. The user needs to setup banking information for vendors once within the system. After that, all payments can be fully automated after the AP assessment is done. This can greatly reduce time and effort spent on this overall process resulting in significant employee cost savings within businesses (or reallocation of efforts to value adding efforts). [00145] The discussion provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.

[00146] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[00147] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[00148] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[00149] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments. [00150] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. [00151] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.

[00152] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. [00153] As can be understood, the examples described above and illustrated are intended to be exemplary only.