TAGGING SYSTEM
Field of the Invention
The invention concerns the processing of transactions between purchasers and suppliers of goods and services by providing transaction identifiers or tags and includes a method and computer system for balancing bank account records with appropriate accounting records.
Background The multiplicity of financial transactions associated with the purchase and provision of goods and services and the ever growing complexity of regulations and taxation regimes which accompany them has seen a concomitant need for means of tracking such transactions in ever greater detail. Customers of companies, such as utility suppliers, sometimes pay their invoices directly into the bank account of the company, such as cash payments made at a bank branch or using the service offered by other agencies such as Australia Post, chemists and newsagents. The bank or the agency then forwards a summary of the deposits to the utility supplier, who then credits each deposit amount to the appropriate customer account. These credits are recorded on the company accounting system on the assumption that the money has been deposited into their account.
Customers also pay invoices at branch offices of a company. These branch offices then deposit the payments as one total payment at their local bank. The individual credits are then recorded on the company accounting system.
Reference is made to WO 03/012716 in which a system is described for the reconciliation of internal records of deposits made by a merchant to a bank and the merchant's bank records of credit card transactions, but this system does not appear to allow for such reconciliation between deposits made in favour of a company by its customers as recorded by a receiving bank or other agency and the internal invoicing records generated within the company.
Within client companies, that is purchasers of goods and services from providers, a number of individuals may effect transactions on behalf of the company including purchases or the incurring of costs such as the making of phone calls for example. The management of such transactions for the purposes of control and accountability is both difficult and time consuming since current transaction systems do not allow for identifying or classifying tags or for the inclusion of unusual or additional data particularly directed at a company's internal management systems.
Summary of the Invention
According to a first aspect, the invention is a method of balancing bank account records with accounting records, the method comprising the steps of: ■ recording deposit information in the bank account records, including a unique 25 identifier, for a deposit into a bank account; recording credit information in the accounting records, including the unique identifier,' for a credit made to a customer account; and cross-matching deposits in the bank account records and credits in the accounting records, using the unique identifier, to automatically identify any deposit that does not have a corresponding credit in the accounting records, or a credit that does not have a corresponding deposit in the bank account records, wherein the unique identifier includes an indication of whether the deposit was a full payment, part payment, volunteered payment or a reversing adjustment.
According to a second aspect, the invention is a method of balancing bank account records with accounting records, the method comprising the steps of: recording deposit information in the bank account records, including a unique identifier, for a deposit into a bank account; recording credit information in the accounting records, including the unique identifier, for a credit made to a customer account; and
cross-matching deposits in the bank account records and credits in the accounting records, using the unique identifier, to automatically identify any deposit that does not have a corresponding credit in the accounting records, or a credit that does not have a corresponding deposit in the bank account records, wherein the unique identifier includes an indication of the method of payment that was used to make the deposit.
The method of payment may include payments through the Internet, direct with the bank account holder or through agencies of the bank account Holder.
The Unique identifier may. be a combination key. for example a combination of a customer code, invoice number, date of receipt and batch number. The unique identifier may include a common element for any deposit made by a particular customer which could create the basis for the automatic identification of invoices paid.
The contents of the unique identifier may be altered to suit the needs of the bank account holder or the customer making the deposit into the bank account.
Cross-matching may be performed on further types of recorded information, such as date of deposit and deposit amount.
The method may further comprise the generating of a report to display the results of the cross-matching, to be used by the bank account holder.
According to a third aspect, the invention is a computer system for facilitating the balancing of bank account records and accounting records of an entity, the computer system providing: a bank account data store to accept and store deposit information, including a unique identifier, for a deposit into a bank account of the entity; a customer account data store to accept and store credit information, including the unique identifier, for a credit made to a customer account in the accounting records of the entity; and a processor external to the entity to automatically cross-match credits
recorded in the customer account data store and deposits recorded in the bank account data store, using the unique identifier, to automatically identify any deposit that does not have a corresponding credit in the customer account data store, or a credit that does not have a corresponding deposit in the bank account data store.
Accordingly there is further provided in a preferred broad form of the invention a method for the processing and reconciling of sets of data; said method including the association of a unique identifier tag with each data item within said sets of data; comparing said sets of data by reference to said unique identifier tag.
In a further broad form of the invention there is provided a customer relationship management system wherein a provider of goods or services provides for the inclusion of a customer defined unique identifier tag on provider records associated with a transaction between said provider and said customer.
The unique identifier tag may be a code number selected by said customer.
The code number may include indicia categorizing said transaction.
The code number may include indicia adapted to identify an employee of said customer.
The code number may include indicia adapted to identify a device used by said employee to effect said transaction.
In a further broad form of the invention, there is provided a method for the processing of statements of transactions received for goods or services provided to an entity wherein said goods or services are acquired on behalf of said entity by individuals within said entity; said processing able to assign any of a selection of characteristics to individual ones of said transactions by means of a unique identifier tag associated with said individual ones of said transactions. Processing may be by means of computer software.
The characteristics may include taxation categories.
The characteristics may include budget categories.
In a further broad form of the invention there is provided a method
for the tracking of uses made by individuals within an organization of services provided by a service provider; said method including the assigning of a unique identifier with each of said uses of said services.
The service provider may render an account to said organization wherein said account is a record of each of said services provided associated with each assigned said unique identifier.
The unique identifier may be defined by said organization.
The unique identifier may include at least an identifying code for each said individual and an identifying code for each of said services. In a further broad form of the invention there is provided a system for the monitoring of a sequence of events by comparison of a first and a second set of data and wherein each of said events has an associated unique identifier data string independently generated for each of said first set and said second set of data. The unique identifier data string for each one of said events generated for said second set of data may be required to correspond to said unique identifier data string generated for said first set of data within a predefined tolerance range.
In this way, the cross-matching of deposits and credits can be out sourced by the entity. The processing can be performed on the original data stores either directly or through an interface. Alternatively, a data store may be duplicated so that crαss-matching is performed on the duplicate information. The processor may be provided by the bank and utilised by the entity through the bank. The processor may be utilised through a website that is hosted by the bank. The result of the cross-match may be communicated to the entity.
It is an advantage of at least one embodiment of the invention to allow a bank account holder/entity to balance individual deposits in their bank account with individual credits made in their accounting records so as to clear their cash book, in balancing their bank account, a bank account holder/entity is able to identify any deposit or credit that does not have a
corresponding balancing record. A credit or deposit that has been captured correctly in either the bank account records or accounting records is also more accurately identified.
It is a further advantage of at least one embodiment of the present invention to streamline and improve the accuracy of the system of payment processing, especially for very large entities. Use of a detailed
Unique Identifier will help to identify the causes and trends of errors in payment processing.
The wide spread use of a unique identifier when balancing bank and accounting records may facilitate the standardisation of banking information.
Brief Description of the Drawings
Fig. 1 is a flow chart of the balancing method; Fig. 2 is an example display of bank account records and customer account 25 transaction record that can be balanced using the invention; and
Fig. 3 is an example report that identifies those deposits or credits not having a corresponding balancing record. Fig. 4 is a representation of an example of interactions between a client of a bank acting as an agency and where payments are made to the bank by a number of customers of the agency.
Fig. S is a flow diagram of a service provider receiving unique identifier codes from various individuals and devices for inclusion with statements of the services provided.
Fi . 5A is an example of a data string for use of a telephone incorporating user and extension unique identifiers.
Fig. 5B is an example of a data string for use of a mobile telephone incorporating user and location unique identifiers. Fig. 6 is an example of a comparison of two independently generated strings of data related to a sequence of events.
Best Modes for Carrying Out the Invention
Broadly, at least some embodiments of the present invention give effect to the concept of intentionally modifying a data set or tracing and not losing from a data set a relatively simple unique identifier or tag within the data set at the point of initiation of the recording of data. This means the data system is designed to embed tags for individual "transactions" within the system with a key enabling ready later identification of that particular transaction and or as a member of a class of transactions to predigest data for the information processing settings relating to that data. The contexts or settings in which this invention may apply are multifarious.. In particular forms it is the "dogtag" concept applied to give the "name, rank and serial number" of the individual transactions rather than necessarily to a particular individual- A second aspect of the invention is the planned use of concatenated strings as keys to a data set. Matching concatenated strings make the reconciliation process computationally simple.
Preferred embodiments of the present invention provide for a system wherein transaction information between parties is additionally supplied with a tag or unique identifier which allows the transaction tq be subsequently subjected to more efficient and detailed processing. The tag may be comprised of a single code or include several additional data fields, either pre-defined or left open so as to allow of a variety of non-standard information. The example concerns balancing deposits in a bank account of a utility company with credits to individual customer accounts in its accounting system.
Referring first to Fig,. 1, an invoice generated by the utility company is communicated to a customer of the utility company 10. To make a payment in favour of the utility company, the customer may choose from a variety of locations to make the payment which includes a bank acting as agents for the utility company, a payment processing centre such as Australia Post or through a branch of the utility company. Each of these
locations has installed a computer program that enables the recording of the appropriate data for processing a payment. This payment may or may not be in response to an invoice. The payment can be made through a variety of methods such as through electronic transfer or over the counter. For example, in response to an invoice, a customer may choose to make a payment through a website hosted by the bank 12.. In order to process the payment, the web site requires the capture of certain information. This may include any combination of:
Invoice Number Customer Code
Premise Number
Meter Number
Switchboard Number
Switchboard Code Line Number Block Number
This information could be supplemented with further information provided by the bank including:
Date of Receipt Receipt Number
Batch Number
Lodgement Number
Payment Method
Payment Type (part, full, volunteer, reversal) Amount Received
Date Banked
Batch Number
Deposit Number
Entity Code Division Code
Location Code
Bank ID Code
Bank Account Number
The type of data captured can be varied to suit the needs of the utility company for example, any special codes contained within the invoice. The type of data captured may also be altered to suit the needs of the customer, such as the capture of a certain number of 'blank' fields that allow the customer to enter any variables which they might want captured, such as Manager Name or Position Number.
A combination of this captured information is used to record the tag or Unique Identifier for this payment 14. For example, the Unique Identifier could include a combination of the Customer Code, Invoice Number, Payment Type and Payment Method. A customer having a Customer Code A and paying through electronic transfer part of an invoice with an Invoice Number of 111 could be assigned a Unique Identifier IA111.1E. A second payment against the same invoice would then be numbered IA111.2E. Alternatively, full payment of the invoice could be assigned a Unique Identifier of IA111E. The common field of the Customer Code, in this example, would create the basis for the automatic detection of paid invoices of a particular customer. The ending letter "E" indicates that payment was received though electronic means. The preceding "I" indicates that the payment is in response to an invoice. Other preceding letters could be used to indicate different payment types,, For example, a preceding "V" could be used to indicate a voluntary payment. A preceding "R" could be used to indicate a reversing transaction such as a bounced cheque. A reversed transaction may take the original transaction's Unique Identifier plus a preceding letter "R".
The Unique Identifier is recorded within the bank account records, along with any other desired information from the pool of captured information, such as the Date of Receipt, and the Amount Received. Any information captured and transmitted to the utility company by the bank may of course be encrypted for security.
The bank account records are then processed by the utility company within its accounting records 16. A credit is made in the utility company's accounting records corresponding to every deposit made in its bank
account records. The Unique Identifier assigned to every deposit is also recorded in the corresponding credit along with any other desired information.
Software is utilised to cross-match the Unique Identifier recorded within the banking records, to those recorded on the utility company's accounting records 18. The software identifies any deposit that has not been recorded in the accounting system and any credit recorded in the accounting system without a corresponding deposit.
The software may be provided to the utility company by the bank and installed within their own computing system. Alternatively, the software may be offered to the utility company through a further website hosted by the bank. The website is then accessed by the utility company whenever cross-matching is desired. Alternatively, the software may be provided to the utility company through a payment processing centre that would provide the cross-matching service to the utility company as well as payment processing services based on billing data provided by the utility company. .
To perform cross-matching, the processing can be performed on the original bank account records or accounting records either directly or through an interface. Alternatively, the data may be duplicated so that the cross-matching is performed on duplicate information.
In this example, the utility company may subscribe to the software provided by the bank through a website. Using a website hosted by the bank, the cross matching may be performed by the bank's software on the original bank account data and the utility company's accounting records using an interface.
Cross-matching can be extended to be performed on any information that is captured by both the banking records and the accounting records. This may include any of the data fields itemised above, such as the Date of Receipt and Amount Received corresponding to each Unique Identifier. This extended cross-matching can ensure that a range of captured information has been captured correctly in either the utility company's bank records or accounting records.
The result of the cross-match is detailed in a report that is also produced by the software 20. The detail within the Unique Identifier and other captured information shown in the report will help the utility company more readily trace and identify errors within their records and trends in the cause of these errors.
Fig. 2 shows an example bank statement 30 displaying the contents of the bank account records. For example, transaction 32 is a record of a part payment made in response to an invoice for an amount of $60.00 on 1 November 2002, and was given a Unique Identifier of IA111.1E. The customer accounting transaction record 40 contains the information on each individual credit made to customer accounts. For example, transaction 42 is a corresponding record for the deposit 32. It shows that on 23 November 2002, the. utility company credited the customer account $60.00 as a result of the deposit 32. The bank records 30 and the customer account record 40 are cross- matched by the software to identify that transaction 34 with Unique Identifier VP000E has not been credited to a customer account and that deposit 44 with Unique Identifier IN102T does not have a corresponding deposit transaction. The cross-matching of Unique Identifiers can be performed by the following query:
SELECT [Accounting Information]. [Date of Receipt], [Accounting Information], [Receipt No], [Accounting Information]. [Batch No], [Accounting Information]. [Lodgement No], [Accounting lnformation].[Payment Type], [Accounting Information]. [Amount Received], [Accounting Information]. [Location Code], [Accounting Information]. [Bank Account No], [Bank details]. [Receipt No] FROM [Bank Details] LEFT JOIN [Accounting Information] ON [Accounting Information]. [Receipt No]=[Bank Details],. [Receipt No] WHERE ([Accounting Information]. [Receipt No] Is Null). AND
SELECT [Accounting Information]. [Date of Receipt], [Accounting Information]. [Receipt No], [Accounting Information]. [Batch No],
ll
[Accounting Information]. [Lodgement No], [Accounting Information], [Payment Type], [Accounting Information]. [Amount Received], [Accounting Information]. [Location Code], [Accounting Information]. [Bank Account No], [Bank details]. [Receipt No] FROM [Accounting Information] LEFT JOIN [Bank Details] ON [Accounting Information]. [Receipt No]= [Bank Details]. [Receipt No] WHERE ([Bank Details]. [Receipt No] Is Null)
The cross-matching query can be expanded to also identify that the amount of the deposit 38 has been captured incorrectly in the customer account transaction record 46.
The result of the query can be presented in the form of a report 50 as shown in Fig. 3.
It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. For example, when the invention is applied to the Internet the Unique Identifier could further include a combination of: an entity code which in Australia could be an ABN by default, or otherwise a number assigned by the bank; a two letter country code, such as those utilised in web addresses (i.e AU for Australia); a three letter international currency cod (i.e. AUD for Australian. dollars); an international time stamp such as standard time (Greenwich) to record the time the product or service is invoiced. In an Australian application Eastern Standard Time (Sydney) could be used; and a customer code, which could be identified through an entity code such as an ABN concatenated with the letter "p" to indicate that this is the purchaser or an e-mail address for an individual.
Optionally the code may include a further time stamps to indicate record the time the payment is made.
As a further example, payments may be made at a bank in favour of an agency, itself acting for a number of clients. A typical example as shown in figure 4 may be that of an estate agent 100 managing a number of rental properties on behalf of owners. In this case the agent 100 may assign 5 unique identifier codes 102 which includes a unique code for each of tenants 103 of a rented property as well as a common identifier for the agent. Any payment then made at a bank 104 by a tenant 103 must be made with the assigned unique identifier 105 and will generate a financial statement 106 for the agent which shows each deposit accompanied by the
10 appropriate renter and property code. Reconciliation of the agents internal records 107 and the statement 106 received from the bank may be effected by utilizing software as previously described.
The provisions of a tag or Unique Identifier code as described may be offered by various providers of goods and services as an aspect of a
15 Customer Relations Management strategy. Facilities which enable a customer to more readily track Individual transactions by means of a customer defined code are likely to enhance the reputation and customer loyalty of a company that provides them.
Such a code may for example be defined by a company purchasing
2 . goods or services to indicate various aspects of a transaction so that a subsequently received account may more readily be processed by the company's internal systems. Thus a code number for example may identify the individual employee who effected the purchase, or it may indicate the category of good or service. Again it may include an identifier assigning the
25 transaction to a particular taxation category or to a particular budget provision within the company. A code may again by way of example directly associate a transaction with a category within the customers accounting software package.
As a further example of an application of the present invention as
30 illustrated by the flow chart of figure 5, a company may have numerous employees making telephone calls and facsimile transmissions from a number of telephone extensions within the organization. In this example both the telephone extensions and facsimile stations may be given a unique
identifier internal company code. As well, employees using these facilities will have an assigned code. An example of a transmission strin comprising the identifiers and voice data is shown in figure 5A. The service provider, in this example a telephone company, then allows for the entry, prior to the making of a call or the transmission of a facsimile, the entry of a code incorporating the employee code and the device code which will then appear on bill statements issued to the company by the service provider.
Where some employees of a company are frequently dispersed in varying locations and use mobile phones, a call from a particular mobile phone may include as a tag both the unique identifier of the user and location data downloaded from a geographical information system (GIS). An example of a transmission string comprising the identifiers and voice data is shown in figure 5B.
In yet a further example of an application of the present invention, a transaction with a provider of goods or services effected by means of a smart card may be tagged by a unique identifier. In this example, a user of the card, that is the purchaser of the goods or services, will have the option at the point of sale to enter via an EFTPOS terminal or other smart card reader, an identifier code of his or her choosing. That identifier will then be retained in the memory of the smart card and also be attached to the record of the transaction produced by the provider* of the goods or services. The details of the transaction including the unique identifier may be downloaded from the smart card by the user as a print-out for example or directly to an accounting software package on the user's computer for subsequent reconciliation with the provider's record,.
In yet a further embodiment of the present invention a first set of data may itself be manipulated to form a unique identifier for the purpose of reconciliation with a second set of data where a predefined degree of correspondence is required between the two sets for a desired condition to be met. In this embodiment the data is made up of an ordered set of information items which are concatenated into a data string; in effect a unique identifier. The first and second sets of data are generated independently but are related to the same transaction or event and are
ordered according to a predefined format.
As an example of this embodiment as illustrated in figure 6, a first set of data may be comprised of a collection of information relating to the planned flight path of an aircraft. In this example the projected flight path may be defined according to regular time intervals associated with a number of flight parameters such as current heading, altitude, current geographical location and so forth. This data will be stored on a ground- based monitoring system as a time-based set of concatenated strings. As the actual flight progresses, the aircraft transmits. sequential data strings at the same regular time intervals and according to the same ordering as that of the lodged flight plan. Each string of this second "anticipated" data set may be compared with corresponding strings of the first subject to appropriate tolerances to allow for normal deviations. If correspondence is within these tolerances, the normal status of the aircraft is confirmed. However if the comparison falls outside of these tolerances an alarm will be generated for ground-control staff to take investigative action. Such departure from allowed correspondence may for example be deliberately generated by the aircrew on the aircraft in the case of an emergency situation by inserting additional code or voice data into the next transmitted string.
Some further examples of preferred embodiments are provided as follows:
Cash Book Reconciliation
The "dogtag" on a financial transaction gives tagged financial transactions for a day or week or a month within a payment and receipts system for an organisation such that the dogtag appears on "4 sides" of the record system. This serves to make the reconciliation of data a simple process.
The reason there are four sides to a two' sided ledger are that there are payments and receipts which are as it were side A1 and side B1. These are the initial records for transactions created within the accounting system. For many entries on the payments side "cheque numbers" already exist. These are likely to be the tags for the class of entries relating to cheques. Similar numbers, broadly "payment numbers" would be introduced to the system for payments that are not cheques (such as
electronic payments). For sales transactions, a receipt number or an invoice, number may serve as the dogtag for the particular transaction. These identity tags for the data pass through the merchant system: whether it be banks or card providers or electronic payment interfaces, and come back to the entities on one or both sides of the transaction,
Note it is not necessary for all entities to participate in dog tagging transactions for the system to flow smoothly. The data coming back to the initiating entity through the merchant system are sides A2 and B2 of the particular transactions. A can be matches with that particular A transaction and B can be matches with that particular B transaction.
The tags need not be numeric or alphanumeric or alpha only, they can consist of any identifier such as a colour code.
For audit purposes, it is necessary for a human and a computer type machine to be able to identify the coda. Here the phrase computer type machine is intended to include not only PCs and mainframes but also anything capable of processing data such as a smart card.
The matching mentioned above translates to automatic cash book reconciliation.
Automated Accounting
A related application of a dogtag is to a class of financial data. The information for this passed through the merchant system facilitates automatic accounting for businesses.
It will apply to small and medium businesses most particularly but larger entities may use it as a first-pass result set. These larger businesses often have tax or accounting policy driven rules, which need to be treated differently in different jurisdictions. They can nevertheless obtain simple reconciled management numbers practically right away. To particularise the example, viz: a small business may have 11 different classes of expenses that the business uses such as:
1. O fice Supplies
2. Car Supplies
3. Other Travel and Accommodation
4„ Tax free entertainment
5. Taxed entertainment
6. High turnover stock
7. Low turnover stock
8. Software
9. Capital, where individual items cost $500.00 or below
10. Capital, above $500.00
11. Other
Each person working for the business and authorised to make purchases is given a list in electronic or written form. Each time they make a purchase the code is passed through the merchant system (it could be on paper or through EFTPOS recording tool or over the internet) or if a smart card is used, it could also be recorded on a smart card in the making of the payment.
Income items might optionally use codes in the range of 20 to 30 or whatever was convenient. The use of tags for income is optional because where the transaction tags noted in Example 1 are used it should not really be necessary. For completeness and for small businesses in particular it is probably a worthwhile facility.
The effect of all this is that when the tags are downloaded either from the merchan system, the merchant system and the smart card or possibly i some instances fro the smart card alone, a full preliminary set of accounts exists. This set would satisfy most small and medium businesses.
For some government entities or consulting , firms or large companies, it may be necessary to allow 4 character or longer strings for classification. If 4 are used, the first two characters may relate to a program or client code and the next 2 an accounting classification code. This last is a "Belt and Braces" approach to the accounting for large organisations.
Where the transaction codes are used for Example 1, it is potentially
superfluous but in practise would be most useful.
Telephone Extensions through Switchboards
Transaction dogtags can also be useful in non-financial fields or partly financial fields.
In telephone calls, proceeding through a switch for a medium or large company there are typically more extensions than there are telephone lines out of the organisation, often many more.
When calls are made to a mobile phone for example, it can be difficult to identify the caller from the originating entity, if the call was missed.
Now, if the originating extension is associated with a tag to send to or from the switch and on to the recipient telephone, the caller can be identified. This means a missed call can be returned in the case of a missed call, the switchboard operator can be given the name and/or the extension number of the person in their organisation who made the call.
As these pieces of data are recorded they can also be fed into the billing system by the telephone company or within the switch itself. This can help in large companies,, Sometimes, management may Wish to know outbound call information, such as cost or who made what call when.
Tagging of the extension with the individual's name, their cost centre and their extension number would make a difficult problem into an easy process.
Note tagging could include geographical information system (GIS) location codes for mobile phones. If sent with call initiation information with the phone number to the telephone provider and potentially the police, suspect calls could be traced to the last best known location αf the mobile phone. This may therefore identify a caller's location with an accuracy comparable to a fixed line service.
The above described embodiments are to be considered in all respects as illustrative and not restrictive.