SYSTEMS AND METHODS FOR ENCODING DATA IN AN ELECTRONIC TRANSACTION

Abstract

Methods and systems are described for providing data with a payment transaction. A dataset for inclusion with a payment transaction is received. The dataset is encoded, and at least one free text field of a payment transaction interface is populated with the encoded dataset. Once the free text field(s) are populated with the encoded dataset, the payment transaction is performed.

Claims

1. A method for providing data with a payment transaction, the method comprising: utilizing at least one processor to execute computer code that performs the steps of: receiving a dataset for inclusion with a payment transaction; encoding received dataset; populating at least one free text field of a payment transaction interface with the encoded dataset; and performing the payment transaction.

2. The method of claim 1, wherein at least a portion of the dataset is extracted from a form.

3. The method of claim 1, wherein the received dataset is encoded using binary-to-text encoding.

4. The method of claim 1, wherein the encoding of the received dataset is performed in accordance with one of a plurality of protocols, wherein the protocols are stored as data encoded in one or more payment transactions.

5. (canceled)

6. The method of claim 1, wherein the payment transaction includes control information, the control information including one or more of: a protocol type identifier identifying a protocol for encoding and/or decoding the dataset, and a transaction type identifier for identifying the payment transaction as including an encoded dataset.

7. (canceled)

8. The method of claim 1, wherein the encoded dataset is provided in more than one payment transaction.

9. The method of claim 1, including recording incoming and outgoing payment transactions including encoding datasets, wherein records produced from the incoming and outgoing payment transactions act as a database.

10. The method of claim 9, wherein at least one of the records resulting from the payment transaction includes an index key for identifying the payment transaction when the dataset in the payment transaction is broken into header and record tables.

11. The method of claim 1, including populating a digital tax return form, and providing details of the populated tax return form as at least part of the dataset to be encoded for inclusion in a payment transaction for the value of tax owing with the return.

12. The method of claim 1, including inputting requisite information to complete a request for a donation tax credit, making a first payment transaction to an approved charitable organization, wherein making the first payment transaction initiates a second payment transaction to a taxation authority, wherein the encoded dataset of the second payment transaction includes the requisite information to complete a request for a donation tax credit.

13. The method of claim 1, wherein the method includes making a first payment transaction to an account relating to a deposit accruing interest, and making a second payment transaction to a taxation authority, wherein the encoded dataset of the second payment transaction includes requisite information to complete a withholding tax certificate.

14. The method of claim 1, wherein the method includes making a first payment transaction to an account of an employee, wherein the first payment transaction is payment of income to the employee, and making a second payment transaction to a taxation authority, wherein the encoded dataset of the second payment transaction includes requisite information to complete documentation requirements relating to withholding tax on income payments.

15. The method of claim 1, wherein the payment transaction establishes one or more accounting codes to be applied to other payment transactions.

16. The method of claim 15, wherein the payment transaction applies an accounting code to an earlier payment transaction to produce an accounting coded record, wherein the encoded dataset of the payment transaction includes one or more of: data identifying the earlier transaction, and data uniquely identifying the accounting coded record.

17. (canceled)

18. The method of claim 1, wherein the payment transaction applies a tax treatment to an earlier payment transaction to produce a tax treatment record.

19. The method of claim 1, wherein the payment transaction provides an accounting journal entry.

20. The method of claim 1, wherein the payment transaction applies a customised note to an earlier payment transaction.

21. The method of claim 1, wherein the encoded dataset includes instructions for enriching a transaction line item of an online banking interface, wherein the instructions for enriching the transaction line item include one or more of: identification of at least one visual element for the transaction line item, identification of at least one graphical element for display in the transaction line item, and identification of text for display in the transaction line item.

22-28. (canceled)

29. A system for providing data with a payment transaction, the system comprising: at least one processor; and a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor, the computer readable program code comprising: computer readable program code that receives a dataset for inclusion with a payment transaction; computer readable program code that encodes the received dataset; computer readable program code that populates at least one free text field of a payment transaction interface with the encoded dataset; and computer readable program code that performs the payment transaction.

30. A computer program product for providing data with a payment transaction, the computer program product comprising a computer readable storage medium having computer readable program code embodied therewith, the computer readable program code comprising: computer readable program code that receives a dataset for inclusion with a payment transaction; computer readable program code that encodes the received dataset; computer readable program code that populates at least one free text field of a payment transaction interface with the encoded dataset; and computer readable program code that performs the payment transaction.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The detailed description of the drawings refers to the accompanying figures in which:

[0052] FIG. 1 is a schematic illustration of an exemplary computing system in which embodiments of the present disclosure may be implemented;

[0053] FIG. 2 is a schematic illustration of an exemplary architecture in which embodiments of the present disclosure may be implemented;

[0054] FIG. 3 is a flow diagram of an exemplary method for providing data with a payment transaction;

[0055] FIG. 4-1 is an exemplary user interface for payment of goods and services tax;

[0056] FIG. 4-2 is an exemplary user interface for data collection for inclusion in the payment of goods and services tax;

[0057] FIG. 4-3 is an exemplary entity relationship diagram within the system;

[0058] FIG. 5 is an exemplary user interface for payment of payroll;

[0059] FIG. 6 is an exemplary user interface for payment of donations;

[0060] FIG. 7 illustrates exemplary enriched transaction line items of an online banking interface;

[0061] FIG. 8 is an exemplary user interface for account code creation and modification;

[0062] FIG. 9 is an exemplary user interface for application of accounting codes;

[0063] FIG. 10 is another exemplary entity relationship diagram within the system;

[0064] FIG. 11 is another exemplary entity relationship diagram within the system;

[0065] FIG. 12 is an exemplary user interface for journal entry creation;

[0066] FIG. 13 is another exemplary entity relationship diagram within the system;

[0067] FIG. 14-1 is an exemplary user interface for accessing stored documents;

[0068] FIG. 14-2 is a first example of a stored document, and

[0069] FIG. 14-3 is a second example of a stored document.

DETAILED DESCRIPTION OF THE DRAWINGS

[0070] FIG. 1. presents a schematic diagram of a system 100 depicting various computing devices that can be used alone or together in accordance with exemplary embodiments of the disclosure. The system 100 includes a payment transaction data service 102, illustrated in this exemplary embodiment as being implemented in a server—for example one or more dedicated server devices, or a cloud based server architecture.

[0071] By way of example, the server(s) implementing the service 102 may have processing facilities represented by processors 104, memory 106, and other components typically present in such computing environments. In the exemplary embodiment illustrated the memory 106 stores information accessible by processors 104, the information including instructions 108 that may be executed by the processors 104 and data 110 that may be retrieved, manipulated or stored by the processors 104. The memory 106 may be of any suitable means known in the art, capable of storing information in a manner accessible by the processors, including a computer-readable medium, or other medium that stores data that may be read with the aid of an electronic device. The processors 104 may be any suitable device known to a person skilled in the art. Although the processors 104 and memory 106 are illustrated as being within a single unit, it should be appreciated that this is not intended to be limiting, and that the functionality of each as herein described may be performed by multiple processors and memories, that may or may not be remote from each other.

[0072] The instructions 108 may include any set of instructions suitable for execution by the processors 104. For example, the instructions 108 may be stored as computer code on the computer-readable medium. The instructions may be stored in any suitable computer language or format. Data 110 may be retrieved, stored or modified by processors 104 in accordance with the instructions 108. The data 110 may also be formatted in any suitable computer readable format. Again, while the data is illustrated as being contained at a single location, it should be appreciated that this is not intended to be limiting—the data may be stored in multiple memories or locations. The data 110 may include databases 112.

[0073] The service 102 may communicate with external devices and services, via a network 116 potentially comprising various configurations and protocols including the Internet, intranets, virtual private networks, wide area networks, local networks, private networks using communication protocols proprietary to one or more companies—whether wired or wireless, or a combination thereof. The service 102 may communicate with user devices via the network 116, for example smartphone 118a, tablet computer 118b, or personal computer 118c to provide access to functionality and data of the service 102. The service 102 may further communicate with external services 120a-n.

[0074] FIG. 2 illustrates an exemplary system architecture 200 for implementation of the service 102. The architecture 200 includes a user interface(s) accessed by client devices 202 (for example smartphone 118a, tablet computer 118b, or personal computer 118c) to enable user access to online banking services provided by the systems of the user's banking provider 204. By way of example, in various embodiments the user interface may be provided by way of: a native application, a web application, or a hybrid application.

[0075] The service 102 provides means for encoding a dataset and populating the free text fields of payment transactions initiated by users of the online banking service—as will be described further below. In an exemplary embodiment the encoding and decoding is performed in accordance with one of a plurality of protocols, with payment transactions including a protocol type identifier which identifies the protocol to be used in processing the payment transaction and decoding the encoded dataset.

[0076] The bank system 204 includes a transaction encoding/decoding module 206, configured to encode and decode transactions in accordance with the present disclosure. As part of its function, the encoding/decoding module 206 calls on a local protocol file database 208 to return a protocol for a particular transaction based on the protocol type identifier. If the protocol type identifier is not found in the local protocol file database 208, the transaction encoding/decoding module 206 may call on a master protocol host 210. It is envisaged that the master protocol host 210 may be provided as an external service, improving ease of access by various banking providers (and other systems utilising the protocols) to provide means for consistent formatting of the data across multiple platforms. In an exemplary embodiment the master protocol host 210 may include a protocol server 212 managing access to a master protocol file database 214. As an alternative to providing an external protocol host, the protocols themselves may be stored as data encoded in one or more payment transactions in a dedicated bank account.

[0077] The banking system 204 further includes a transaction processing module 216 interfacing with the transaction encoding/decoding module 206 to manage incoming and outgoing transactions (including internal transactions). The transaction processing module 216 interfaces with a local transaction database 218 to manage storage and retrieval of data associated with the user related transactions, and potentially clearing system and external transaction processing services 220 for processing of external transactions.

[0078] FIG. 3 illustrates a method 300 for providing data with a payment transaction. In a first step 302, a dataset is received for inclusion with a payment transaction initiated via a payment transaction interface of the online banking service of the banking system 204. In a second step 304, the received dataset is encoded. In a third step 306, at least one free text field of a payment transaction interface is populated with the encoded dataset. In a fourth step 308, the payment transaction is performed. It should be appreciated that a corresponding method may be performed for processing a received payment transaction including text fields populated by an encoded dataset in accordance with the method 300.

[0079] Exemplary embodiments in which the method 300 may be implemented are described herein. These embodiments will be described in the context of New Zealand banking transaction standards (more particularly, the BACHO record format), in which three free text fields are provided, each allowing 12 characters (i.e. a total of 36 characters per transaction)—commonly referred to as the “Particulars”, “Code” and “Reference” fields. However, it should be appreciated that the disclosure of the present application may be readily applied to other transaction standards in which a different number of free text fields and/or number of characters are defined. Further, the exemplary embodiments will be described as utilising a Base64 encoding method. While Base64 is considered to be well suited to use with formats such as BACHO, it will be appreciated that this is not intended to be limiting to all embodiments of the present disclosure.

[0080] FIG. 4-1 and FIG. 4-2 illustrate an exemplary embodiment in which the payment transaction relates to a tax return—more particularly a goods & services tax (GST) return requiring completion of accompanying documentation. It is envisaged that the encoded dataset of the payment transaction may include requisite information to complete a tax return. It should be appreciated that the data to be included for the purposes of completing the documentation will be largely dependent on the requirements of the jurisdiction in question. The present embodiment is described in the context of current New Zealand requirements, and reference may be made to the New Zealand taxation authority: the Inland Revenue Department (IRD).

[0081] Exemplary data fields to be included with the payment transaction are outlined in Table 1 below:

TABLE-US-00001 TABLE 1 Field Name Field Type Field Length Field Description TransactionDate Numeric 8 The date of the bank transaction containing the GST Payment Return in the format 20180726 (YYYYMMDD) PayerName Alphanumeric 74 The name of the GST payer PayerAccountNum Alphanumeric 16 Payer's bank account number PaymentAmount Decimal 14 The GST payment amount IRDNumber Numeric 9 Payer's IRD Number, a validated eight or nine digit number PeriodEndDate Numeric 8 The end date of the period that the GST return and payment are for, in the format (YYYYMMDD) RefundDue Boolean 1 If a refund is due, then TRUE else FALSE. If TRUE, then PaymentAmount will be 0.01 NilReturn Boolean 1 If is a Nil Return then TRUE else FALSE FinalReturn Boolean 1 If is a Final Return then TRUE else FALSE Income Decimal 14 Total income for the GST period Expense Decimal 14 Total expense for the GST period ZeroRated Decimal 14 Total zero rated for the GST period CreditAdjustment Decimal 14 Total credit adjustments for the GST period DebitAdjustment Decimal 14 Total debit adjustments for the GST period

[0082] In this exemplary embodiment, control information to be provided with the payment transaction includes a form identifier used to identify the appropriate protocol for encoding and decoding of the text fields. In an exemplary embodiment the form identifier may include: [0083] Transaction code: a unique three-digit identifier used by banks to identify distinct types of transactions, with a unique 3-digit ID will be introduced to identify transactions as utilising the present disclosure; [0084] Payee name: the name of the entity with which the protocol is associated; [0085] Type: the type of protocol; [0086] Version: the version of the protocol, which each protocol type potentially having a plurality of versions.

[0087] In such an embodiment the form identifier may be formatted as: [TransactionCode]_[PayeeName]_[Type]_[Version].

[0088] In exemplary embodiments, a record resulting from a payment transaction may include an index key for identifying the transaction when the data in a single transaction is broken into header and record tables. By way of example, the index key may include: [0089] Transaction date: the date of the transaction, more particularly formatted as YYYYMMDD. [0090] Payer account number: the bank account number of the payer—for example a 16-digit number made up of the following, all padded with leading zeros: [Bank(2)][Branch(4)][Number(7)][Suffix(3)]; [0091] Type: the type of protocol; [0092] Version: the version of the protocol, [0093] Count (“Nth”): the Nth number of GST Payment Returns made by the same bank account and IRD number on the same day—for example, starting at zero and incrementing with each subsequent return. [0094] IRD Number: the IRD Number of the payer—for example, a 9-digit number padded with leading zeros. [0095] PeriodEndDate—The period end date of the return, formatted as YYYYMMDD.

[0096] In such an embodiment the index key may be formatted as: [Transaction Date]_[PayerAccountNum]_[Type]_[Version]_[Nth]_[IRDNumber]_[PeriodEndDate].

[0097] In an exemplary embodiment, encoding flags may be provided to identify whether optional data fields have been populated, and if not these these bits of data may be utilized for other information.

[0098] When fields, such as monetary fields, are required to accommodate a wide range of values to cater for varying scales (for example: $0.00-$9,999,999.00), the bits required for the maximum value may be unused for lower values. It is envisaged that a plurality of bands across the range may be provided (each having a known number of bits), and identified depending on the value to be recorded.

[0099] Known GST tax payments made using online banking require, as per IR 584, the payee name and bank account number, amount, the IRD number of the person or organisation the payment is for (to be entered into the ‘Particulars’ field), and a code entered into the ‘Code’ field (for example, ‘GST’ followed by the period end date for this payment). Referring to FIG. 4-1, an online banking service provides a GST payment interface 400 according to an exemplary embodiment of the present disclosure. The GST payment interface 400 includes a GST number field 402, GST period end date selector 404, payment amount field 406, payer particulars field 408a, payee particulars field 408b, payer code field 410a, payee code field 410b, payer reference field 412a, and payee reference field 412b.

[0100] The GST payment interface 400 also includes a tax return submission selector 414, selection of which opens a data entry form 416 illustrated in FIG. 4-2. The data entry form 416 includes a total sales and income field 418, and zero rated supplies field 420, for entry of data by the user. From this data, a GST on sales and income field 422 may be automatically populated. The data entry form 416 further includes a debit adjustments field 424 for entry of data by the user.

[0101] The data entry form 416 includes a total purchases and expenses field 426 for entry of data by the user, from which a GST on purchases and expenses field 428 may be automatically populated. The data entry form 416 further includes a credit adjustments field 430 for entry of data by the user.

[0102] The data entry form 416 automatically populates a total GST field 432 based on the entered data. A nil return selector 434 and final return selector 436 are also provided, together with a declaration checkbox 438.

[0103] Selection of the declaration checkbox 438 initiates encoding of the data. A protocol for the GST payment determines the arrangement of the various data elements, encoding of the data using Base64 encoding, and population of the payee particulars field 408b, payee code field 410b, and payee reference field 412b with the encoded data. The payment amount field 406 is also populated based on the calculated GST amount. Where the user is eligible for a refund, a nominal transaction amount (for example, $0.01) is used in order to transmit the tax return to the IRD.

[0104] Exemplary transaction lines for the payments appearing in the user's bank accounts are shown in the table below:

TABLE-US-00002 TABLE 2 Date Name Particulars Code Reference Amount DD/MM/YYYY INLAND [IRD GST [period −[value of REVENUE number] end date] payment of tax owed] DD/MM/YYYY INLAND [IRD GST [period CR. REQ. −0.01 REVENUE number] end date]

[0105] The reference “CR. REQ” of the second entry indicates that the payment relates to a request for tax credit or refund. Corresponding transaction lines for the payments appearing in the IRD's bank accounts are shown in the table below:

TABLE-US-00003 TABLE 3 Date Name Particulars Code Reference Amount DD/MM/YYYY [NAME OF [First portion [Second [Third portion [value of PAYER] of encoded portion of of encoded payment of data] encoded data] data] tax owed] DD/MM/YYYY [NAME OF [First portion [Second [Third portion 0.01 PAYER] of encoded portion of of encoded data] encoded data] data]

[0106] Further data can be extracted from the encoded data in the payee particulars, code and reference fields (along with the other transaction data) by way of query views as represented in FIG. 4-3, which shows transaction data consolidated into an entity relationship diagram 450.

[0107] By utilising the present disclosure, a tax return may be submitted and paid in the same process. It is envisaged that this may reduce the administrative burden on the payer (or their representative) in completing the return, as well as reducing the resource required by the taxation agency to complete reconciliation processes. Further, records of the tax return and associated payment are stored at the same location—and these records are duplicated between the parties involved.

[0108] FIG. 5 illustrates an exemplary embodiment in which the payment transaction relates to withholding tax on income payments to employees—i.e. pay-as-you-earn (PAYE). An online banking service provides a payroll payment interface 500 according to an exemplary embodiment of the present disclosure. The payroll payment interface 500 includes a payment section 502, including employer selector 504a and employee selector 504b, and a IRD number field 506 automatically populated with the IRD number of the selected employee. Payer text fields 508a and payee text fields 508b are also provided.

[0109] The payroll payment interface 500 also includes a PAYE submission selector 510, selection of which opens a data entry form 512, and a PAYE payment section 514 having payer text fields 516a and payee text fields 516b. The data entry form 512 includes a gross earnings field 518, a tax code selector 520 (where selection of a student loan related code triggers display of a field for entry of student loan deductions), a PAYE field 522, superannuation or voluntary saving contribution selector 524, an earnings not liable for ACC earners' levy field 526, a lump sum acknowledgement selector 528, a child support deductions field 530, a child support code selector 532, a calculated PAYE owing field 534, an employer contribution selector 536, a start date field 538, and a finish date field 540. The data entry form 512 also includes a declaration checkbox 542.

[0110] Selection of the declaration checkbox 542 initiates encoding of the data. A protocol for the PAYE payment determines the arrangement of the various data elements, encoding of the data using Base64 encoding, and population of the payer text fields 516a and payee text fields 516b with the encoded data. The payer text fields 508a and payee text fields 508b for the payment to the employee may also be populated with at least a portion of the encoded data. In submitting payment to the employee, a corresponding payment for the PAYE component is also made to the IRD.

[0111] FIG. 6 illustrates an exemplary embodiment in which the payment transaction relates to a payment to an approved charitable organisation, and includes a request for a donation tax credit (also known as a charitable contribution deduction) from a taxation authority. An online banking service provides a donation payment interface 600 according to an exemplary embodiment of the present disclosure. The donation payment interface 600 includes a payer selection field 602. The record of each available payer may include information required to complete a request for a donation tax credit.

[0112] The donation payment interface 600 includes a donee selection field 604, providing means for selecting a donee which is registered with the taxation authority. The donation payment interface 600 also provides a tax credit request selector 606, such that a payment transaction is made to the taxation authority using a nominal payment value on making a donation to the donee. The payment transaction made to the taxation authority includes text fields populated with encoded data in accordance with the present disclosure, sufficient to complete the documentation associated with such a request.

[0113] Exemplary transaction lines for the payments appearing in the user's bank accounts are shown in the table below:

TABLE-US-00004 TABLE 4 Date Name Particulars Code Reference Amount DD/MM/YYYY [Donee] [IRD [Donee [value of −[value of number] identifier] donation] payment to donee] DD/MM/YYYY INLAND [IRD [Donee [value of −0.01 REVENUE number] identifier] donation]

[0114] A corresponding transaction line for the payment appearing in the donee's bank accounts is shown in the table below:

TABLE-US-00005 TABLE 5 Date Name Particulars Code Reference Amount DD/MM/YYYY [NAME OF [IRD [Donee [value of [value of PAYER] number] identifier] donation] payment to donee]

[0115] A corresponding transaction line for the payment appearing in the IRD's bank accounts is shown in the table below:

TABLE-US-00006 TABLE 6 Date Name Particulars Code Reference Amount DD/MM/YYYY [NAME OF [IRD [Donee [value of 0.01 PAYER] number] identifier] donation]

[0116] In an exemplary embodiment, the present disclosure may be applied to payment of withholding tax on interest to a taxation authority. Payment of interest subject to a withholding tax includes a first payment transaction to an account relating to a deposit accruing interest (e.g. a user's bank account), and a second payment transaction to a taxation authority (e.g. IRD), with encoded dataset of at least the second payment transaction including requisite information to complete a withholding tax withholding certificate. Exemplary transaction lines for the payments appearing in the user's bank account are shown in the table below:

TABLE-US-00007 TABLE 7 Date Name Particulars Code Reference Debit Credit DD/MM/YYYY [BANK] CR. [DDMMYYYY] [value of INT TO interest] DD/MM/YYYY INLAND IRD: INTEREST [value of REVENUE TAX ON RWT on interest]

[0117] FIG. 7 illustrates an exemplary embodiment of the present disclosure in which encoded datasets are used to enrich transaction line items of an online banking interface (typically displayed in a plain text format). By way of example, a first transaction line item 700 relating to a direct debit from an insurance company includes a logo 702 identifying the insurer, a policy identification section 704 in which the policy number and term are provided, and a policy detail section 706 in which additional details regarding the policy are provided. As a further example a second transaction line item 708 relating to a direct debit from a power company includes a logo 710 identifying the power company, an invoice identification section 712 in which details such as invoice number and period may be provided, and a graphical representation 714 of power consumption over the relevant period. As a further example, a third transaction line item 716 relating to a direct debit from a telecommunications company includes a logo 718 identifying the company, a customer identification section 720 in which the customer number is provided, and an invoice detail section 722 in which additional details regarding the charges incurred are provided.

[0118] FIG. 8 illustrates an exemplary account code interface 800, for creation and modification of accounting codes to be applied to transactions on the user's bank account. The account code interface 800 includes a new code name entry field 802, a profit and loss selector 804, a sales tax selector 806, and a code entry confirmation button 808. Existing codes 810 may be modified using selectors 812 and 814. The account code is recorded within the user's bank account using one or more nominal payment transactions populated with encoded data for the account code.

[0119] In exemplary embodiments, a standardised transaction identifier may used within the system such that a transaction can be identified by its contents rather than by a local identifier. In an exemplary embodiment, creation of a transaction identifier may include determining an Apply Date Index by: i) selecting all transactions on the same date, ii) ordering by ascending date and time, iii) ordering by ascending “[Name] & [Particulars] & [Code] & [Reference]”, iv) ordering by amount, v) finding the zero-based index of the transaction within the resulting list, and vi) returning the index as a 2-character hexadecimal value. The Apply Date Index may then be used with the date of the transaction to form the transaction identifier, which may be used to identify coding applied to each transaction.

[0120] Application of an accounting code may be performed using one or more nominal payment transactions. A plurality of coding types may be used, including (but not limited to): code apply, code split, tax code apply, journal, and note.

[0121] Referring to FIG. 9, an exemplary code application interface 900 may be provided within the online banking service, displaying an assigned accounting code 902 for each line item. Selection of an accounting code 902 displays a code apply control function 904, with which an accounting code may be applied to a transaction (or modified from a previously applied code). An apply code record is generated in the form of a nominal transaction, having a code application identifier which is incremented for each application of an accounting code to the parent transaction—creating a permanent audit trail. It is noted that the code apply type is used where the accounting code is to be applied to the whole parent transaction amount, while the code split type is used to apply an accounting code to a portion of the parent transaction amount. FIG. 10 illustrates the transaction data consolidated into an entity relationship diagram 1000, when applying a code or codes to a transaction.

[0122] The tax code apply type may be used when a tax correction is required, coding an income tax or sales tax payment to a different tax period or to a different registered tax number. FIG. 11 illustrates the transaction data consolidated into an entity relationship diagram 1100, when applying a code or codes to a transaction associated with a tax payment.

[0123] Referring to FIG. 12, an exemplary journal entry creation interface 1200 may be provided within the online banking service, using a nominal payment transaction of the present disclosure to provide an accounting journal entry. The journal entry creation interface 1200 includes a debit code selector 1202, and a credit code selector 1204 for selection of the accounting codes the journal entry is to apply to. A debit field 1206 is provided, with credit field 1208 automatically populated based on the value entered into the debit field 1206. FIG. 13 illustrates the transaction data consolidated into an entity relationship diagram 1300, when creating a journal.

[0124] It should be appreciated that the inclusion of encoded data in payment transactions as described herein may be used to record a range of data within the system. Further examples include customised notes, and account information which might be referenced (for example, identification of a bank account).

[0125] The various transactions form a single table within the online banking service, where each row has fields utilised by the system of the present disclosure to store encoded data. The decoded information, within the row, may form the header and/or records of a relational database as illustrated. This data may also have a relationship to the decoded data within one or many other transactions in the same user's transaction table. Thus, from a single table (or vertical database) with a constrained record set, a more complex relational database can be formed.

[0126] In examples, the vertical database formed by the collection of encoded transactions may also be described as a non-relational NoSQL document store database. The contents of each encoded transaction forms the data for an individual document, the definition of which is described by a predefined protocol. An encoded identification within the encoded free text fields, and the supporting transaction fields, form the data required to identify the predefined protocol. Each encoded transaction record may have a different protocol. Therefore, a table of encoded transactions (once decoded) will form a collection of documents with varying definitions. As a result, the collection of documents forms a non-relational NoSQL document store database.

[0127] Referring to FIG. 14-1, an exemplary online banking user interface 1400 has a first transaction line 1402-1 and second transaction line 1402-2. Each of the first transaction line 1402-1 and second transaction line 1402-2 have encoded data ([encoded data1], [encoded data2], [encoded data3]) in the “Particulars”, “Code”, and “Reference” free text fields. Each of the first transaction line 1402-1 and second transaction line 1402-2 also includes a selectable document viewing icon 1404-1 and 1404-2 respectively, selection of which displays a document associated with the transaction line.

[0128] In this example, the first transaction line 1402-1 relates to the user's payment of local council charges for water utilities. On decoding of the data, a protocol for processing of the data is identified, and used to produce a receipt 1420 for the transaction (as shown in FIG. 14-2). In addition to values of particulars encoded into the data (for example: an account number, and values for the various charge details), the decoded data may identify artifacts to be utilised in generating the document (for example, document templates). Further, external APIs may be called to obtain additional data. For example, the encoded data may include a numerical Delivery Point Identifier associated with a specific delivery address, and a postal service API may be called with the Delivery Point Identifier to obtain full address details.

[0129] The second transaction line 1402-2 relates to payment of dividends to the user from a securities management service. On decoding of the data, a protocol for processing of the data is identified, and used to produce a dividend statement 1450 for the transaction (as shown in FIG. 14-3). In addition to values of particulars encoded into the data (for example: an IRD number, a holding value, a payment rate, and a withholding tax rate), the decoded data may identify artifacts to be utilised in generating the document (for example, document templates). Further, the protocol may define processing steps such as calculation of the dividend amount based on the holding value and payment rate, and calculation of withholding tax and net dividend. Further, external APIs may be called to obtain additional data. For example, the encoded data may include a numerical Delivery Point Identifier associated with a specific delivery address, and a postal service API may be called with the Delivery Point Identifier to obtain full address details.

[0130] For a firmware and/or software (also known as a computer program) implementation, the techniques of the present disclosure may be implemented as instructions (for example, procedures, functions, and so on) that perform the functions described. It should be appreciated that the present disclosure is not described with reference to any particular programming languages, and that a variety of programming languages could be used to implement the present invention. The firmware and/or software codes may be stored in a memory, or embodied in any other processor readable medium, and executed by a processor or processors. The memory may be implemented within the processor or external to the processor. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a digital signal processor (DSP) and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. The processors may function in conjunction with servers, whether cloud based or dedicated, and network connections as known in the art.

[0131] In various embodiments, one or more cloud computing environments may be used to create, and/or deploy, and/or operate at least part of the software system that can be any form of cloud computing environment, for example: a public cloud, a private cloud, a virtual private network (VPN), a subnet, a Virtual Private Cloud (VPC), or any other cloud-based infrastructure known in the art. It should be appreciated that a service may utilize, and interface with, multiple cloud computing environments.

[0132] The steps of a method, process, or algorithm described in connection with the present disclosure may be embodied directly in hardware, in a software module executed by one or more processors, or in a combination of the two. The various steps or acts in a method or process may be performed in the order shown, or may be performed in another order. Additionally, one or more process or method steps may be omitted or one or more process or method steps may be added to the methods and processes. An additional step, block, or action may be added in the beginning, end, or intervening existing elements of the methods and processes.

[0133] Reference throughout this specification to “one embodiment” or “an embodiment” (or the like) means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” or the like in various places throughout this specification are not necessarily all referring to the same embodiment.

[0134] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in at least one embodiment. In the foregoing description, numerous specific details are provided to give a thorough understanding of the exemplary embodiments. One skilled in the relevant art may well recognize, however, that embodiments of the disclosure can be practiced without at least one of the specific details thereof, or can be practiced with other methods, components, materials, et cetera. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

[0135] The illustrated embodiments of the disclosure will be best understood by reference to the figures. The foregoing description is intended only by way of example and simply illustrates certain selected exemplary embodiments of the disclosure. It should be noted that the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, apparatuses, methods and computer program products according to various embodiments of the disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises at least one executable instruction for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0136] Throughout this specification, the word “comprise” or “include”, or variations thereof such as “comprises”, “includes”, “comprising” or “including” will be understood to imply the inclusion of a stated element, integer or step, or group of elements integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps, that is to say, in the sense of “including, but not limited to”.

[0137] Embodiments described herein may also be said broadly to consist in the parts, elements and features referred to or indicated in the specification of the application, individually or collectively, in any or all combinations of two or more of said parts, elements or features.

[0138] Where in the foregoing description reference has been made to integers or components having known equivalents thereof, those integers are herein incorporated as if individually set forth.

[0139] It should be noted that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be made without departing from the scope of the disclosure and without diminishing its attendant advantages. It is therefore intended that such changes and modifications be included within the present disclosure.