WO2003069505A1

WO2003069505A1 - Computerised accounting system for performing double entry accounting operations

Info

Publication number: WO2003069505A1
Application number: PCT/AU2003/000194
Authority: WO
Inventors: Shun-Yau Tang; Jason Tin-Shing Tang
Original assignee: Shun-Yau Tang; Jason Tin-Shing Tang
Priority date: 2002-02-18
Filing date: 2003-02-14
Publication date: 2003-08-21

Abstract

A double entry computerised accounting system, including: an accounts database for storing accounts data; an input module for accepting inputted accounts data; wherein the input module includes an accounts simulator, the simulator presenting a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

Description

Computerised Accounting System for Performing Double Entry

Accounting Operations

Field of the Invention The present invention relates to a computerised accounting system for performing double entry accounting operations.

Background to the Invention

Conventional computerised accounting systems tend to be computerised replicas of conventional manual accounting systems. The two main types of computerised accounting systems are Batch Processing and Real-time processing. Figure 1 illustrates a block diagram of a computerised accounting system which follows both a real-time and a batch processing approach. These existing computerised accounting systems can be functionally analysed to have a master database linked to three subsystems: A data entry subsystem utilises a document template to enter transaction data. The user must rely on their knowledge of double entry accounting to be able to accurately enter data into the system. A transaction processing subsystem uses the verified data supplied from data entry subsystem to perform updating of the latest data onto a master database. A report generation subsystem allows for the generation of financial reports detailing the updated data.

When performing double-entry operations with the existing computerised accounting systems, selecting proper accounts for entering transaction data requires that , a user be adequately trained in accounting. A further disadvantage is these systems of the prior art are relatively difficult to operate due to the notations and rules of debit and credit entries of double-entry operations. Making decisions to select the correct account, whether that be either a debit or credit entry, relies primarily on a user's knowledge in double- entry accounting. The financial performance and position of a business therefore can be affected depending on how the user enters the data. For example, whether an insurance payment is entered as either an expense or an asset. It is therefore common for mistakes to occur despite the total debits and total credits being balanced. This is particularly so where the user is not adequately trained in conventional accounting and double entry techniques.

With the computerised accounting systems of the prior art, it is not possible for the user to immediately see the changes affected by the data which has been recently entered. The inputted data (after commonly known verification) is processed and saved with previously entered/stored data on a master database without additional cross-checking or verification. The subsequent effects on financial statements and accounts are therefore neither known nor available until the inputted data is entered and finalised by the user and then processed and saved on the master database.

United States Patent Application 20010044762 in the name Nault proposes a financial statement module. The financial statement module is provided in which information concerning transactions is stored in order to produce small files and to be able to store a large quantity of transaction information. Using the distinction and processing to the two types of balances appearing in the financial statement, the module can produce any type of financial statements, independently of the type of business, report, accounting system or information. The generator can produce a detail for a financial statement item, for an account balance, for a document, and build any transactions report. This document discloses software that provides an editor/generator which produces various presentations for different views and purposes. The application concentrates on the building of final statements after generation of an adjusted trial balance report by other accounting software.

It is an object of the present invention to overcome or alleviate one or more disadvantages present in the prior art.

Summary of Invention

In a first aspect of the present invention, there is provided a double entry computerised accounting system, including:

(a) an accounts database for storing accounts data; (b) an input module for accepting inputted accounts data; wherein the input module includes an accounts simulator, the simulator presenting a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

Preferably, a user is presented with a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database to allow the user to visually verify the accuracy of the inputted data as it is being entered and before it is transferred to the accounts database.

In one particular form, the input module operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database.

The simulator may, optionally, prevent transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.The input module may include a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator. The user may enter inputted accounts data directly into either the document template or the accounts simulator.

In one form of the present invention, the input module includes replication data being a replication of at least part of the accounts database, wherein the simulator may access the replication data to provide the simulation display. In an additional form, the invention includes a data rectification module which receives inputted data from the input module and determines whether any of the inputted data includes, or is based on, the replicated data that is different from current data in the server's accounts database and if so, corrects the replicated and/or inputted data based on the current data. Each item of data entered may be classified into one of two categories of: (a) owned worth representing an item having an assets accumulating nature; and (b) claimed worth representing an item having a liabilities accumulating nature or an equivalent assets decreasing nature. Preferably, the inputted accounts data is only transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth. Each owned or claimed worth may, optionally, be linked with one or more analysis accounts. The input module may also be located on a user's computer with the accounting database being physically located either on, at a location remote from, or both concurrently on and remote from the user's computer.

In a preferred form, the input module utilises a combination of indexed cells together with positive indicators and negative indicators in substitution for conventional debit and credit notations. The positive indicator is preferably a plus (+) sign. The negative indicator is preferably a negative (-) sign.

In a second aspect of the present invention, there is provided a computerised accounting input module for entering accounts data into an accounts database, the accounting input module including: an accounts simulator; wherein the accounts simulator presents a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

Preferably, a user is presented with a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database. This allows the user to visually verify the accuracy of the data being entered as it is being entered and before it is transferred to the accounts database.

Preferably, the accounts simulator operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database. The accounts simulator may operate to prevent transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.

The module of the present invention may further include a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator.

A user may enter inputted accounts data directly into either the document template or the accounts simulator.

The module optionally includes replication data being a replication of at least part of the accounts database wherein the simulator may access the replication data to provide the simulation display.

In one further form of the invention, each item of data entered is classified into one of two categories of: (a) owned worth representing an item having assets accumulating nature; and (b) claimed worth representing an item having a liabilities accumulating nature or an equivalent assets decreasing nature.

The inputted accounts data may only be transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth. Preferably, each claimed worth is linked with one or more analysis account.

In a further preferred form of the invention, the module is located on a user's computer with the accounts database being physically located either on, at a location remote from, or both concurrently on and remote from the user's computer.

In a preferred form, the accounts simulator utilises a combination of indexed cells together with positive and negative indicators in substitution for conventional debit and credit notations. The positive indicator is preferably a positive (+) sign. The negative indicator is preferably a negative (-) sign.. In a third aspect of the present invention, there is provided Double entry accounting software, including: an accounts database component for storing accounts data; an input module for accepting inputted accounts data; wherein the input module includes an accounts simulator, the simulator presenting a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

Preferably, a user will have a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database. This allows the user to visually verify the accuracy of the data being entered as it is being entered and before it is transferred to the accounts database.

Preferably, the input module operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database. The simulator may prevent transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.

The input module may also include a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator. The user may enter inputted accounts data directly into either the document template or the accounts simulator.

In one particularly preferred form of the invention, the input module includes replication data being a replication of at least part of the accounts database, wherein the simulator may access the replication data to provide the simulation display. Additionally or alternatively, the invention includes a data rectification component which receives data from the input module and determines whether any of the inputted data includes, or is based on, any replication data that is different from current data in the server's accounts database and if so, corrects the replication data based on the current data. Each item of data entered may be classified into one of two categories of: (a) owned worth representing an item having an assets accumulating nature; and (b) claimed worth representing an item having a liabilities accumulating nature or an equivalent assets decreasing nature. Preferably, the inputted accounts data is only be transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth.

Each owned or claimed worth may also be linked with one or more analysis accounts.

In another form of the present invention, the input module is located on a user's computer with the accounting database being physically located either on, at a location remote from, or both concurrently on and from the user's computer.

In a preferred form, the input module utilises a combination of indexed cells together with positive and negative indicators in substitution for conventional debit and credit notations. The positive indicator is preferably a positive sign (+). The negative indicator is preferably a negative sign (-).

Brief Description of Drawings

The invention will now be described in further detail by reference to the enclosed drawings illustrating an example form of the prior art and the invention. It is to be understood that the particularity of the drawings does not supersede the generality of the preceding description of the invention. In the drawings:

Figure 1 is a flow chart illustrating a model for computerised accounting systems (with either real-time or batch processing) of the prior art.

Figure 2 is a flow chart illustrating a model for computerised accounting systems in a single use environment according to an embodiment of the present invention. Figure 3 is a display of Multi-Section Editor according to a further embodiment of the present invention.

Figure 4 is a series of diagrams illustrating a relational menus design for entering data to an Analysis account according to a still further embodiment of the present invention.

Figure 5 is a series of diagrams illustrating a relational menus design for entering data to a Worth account according to an embodiment of the present invention.

Figure 6 is a conversion table illustrating the relationships between increase/ decrease of Owned/ Claimed against conventional debit/credit entries according to an embodiment of the present invention.

Figure 7 is a credit sales display according to an embodiment of the present invention.

Figure 8 is a general journal display according to an embodiment of the present invention.

Figure 9 is an alternative of a general journal display partly using debit and credit notations according to an embodiment of the present invention.

Figure 10 is a display of Menu Editor for editing Analysis, Worth and the association between Analysis accounts and Worth accounts according to an embodiment of the present invention.

Figure 11 is a display for a template of Worth Accounts Report (e.g. Balance Sheet) according to an embodiment of the present invention.

Figure 12 is a display for a template of Analysis Accounts Report (eg. Income Statement) according to an embodiment of the present invention. Figure 13 is a flow chart illustrating a model for computerised accounting systems in a networked multi-use environment according to one embodiment of the present invention.

Figure 14 is a chart illustrating the traffic flow in an Internet-based accounting system according to one embodiment of the present invention.

Detailed Description

A transaction in double-entry accounting creates at least one debit entry and at least one corresponding credit entry such that the total sum of debit entries and total sum of credit entries is equal. In the computerised accounting system of the present invention, a data entry of a transaction may be either manually entered by a user or alternatively the data entry may be automatically effected by other compatible accounting software. Each data entry of a transaction can be grouped into one of two levels being either: Source or Final.

A source level data entry is typically based on source documents and is termed Analysis. A final level data entry is typically generated by the software and is termed Worth. An account may therefore be either an Analysis account where it presents an aggregation of data entries for the same Analysis, or a Worth account where it presents an aggregation of data entries for the same Worth.

Each data entry entered into the double-entry accounting system of the present invention may be classified as either Owned Worth for its assets-accumulating nature, or as Claimed Worth type for its liabilities-accumulating nature.

The value of a data entry may also be classified as either positive or negative depending on whether it will, respectively, increase or decrease the value of a Worth. The Worth may be either an Owned Worth or a Claimed Worth.

A Worth is the accumulation of a plurality of Analysis accounts that are associated directly with the Worth. Since a Worth must be assets- or liabilities- accumulating, an associated Analysis of a Worth is normally of assets- or liabilities-accumulating nature, such as 'product' Analysis associated with 'inventory' Worth. Some Analysis accounts are of income- or expense- generating nature, such as 'sales' Analysis and 'cost of sales' Analysis associated with 'earnings' Worth.

A balance sheet is derived by a complete list of a plurality of Worth accounts (for example: inventory, capital, earnings and machinery value) of which each Worth is assigned by default to have a positive value. A balance sheet organises the plurality of Worth into two groups: Owned which represents assets and Claimed which represents liabilities. Based on the conventional double-entry accounting principle, the total assigned value of Owned Worth must equal to the total assigned value of Claimed Worth.

The accounting system of the present invention processes all data into financial reports. There are many types of financial reports including financial statements, progress reports and analysis reports. Some of the most important financial statements are the income statements and balance sheets, these assist in providing a summary of the financial performance of a business.

The invention includes a Data Entry Sub-system, Report Generation Subsystem and Transaction Processing Sub-system. The interaction between these various subsystems and their respective internal components is shown in Figure 2. The Data Entry Sub-system consists of a Master Database and a Multi- Section Editor (Editor). The Master Database includes an Accounts Database which is a part, a total, a partial replication or a total replication of Master Database. Therefore, the Accounts Database may be physically separate from Master Database such that in a networked environment, the Accounts Database can be physically located either on the user's computer, or at a location remote from the user's computer, or both concurrently on and at a location remote from the user's computer. The Editor includes a Menu, Document Template and Double-Entry Simulator.

The invention provides an intuitive screen as an interface for the Data Entry Subsystem to allow the user to enter data, the Editor is presented on a Graphical User Interface (GUI) which simultaneously displays several inter- related screen sections of the computerised accounting system of the present invention. The GUI displays the Double-Entry Simulator and a Document Template. The Document Template may be selected from a plurality of Document Templates. The GUI may also include a Menu.

The Document Simulator is a subset of the Editor, the Editor in turn being linked to the Accounts Database. The GUI can be displayed either as a single or as multiple interconnected screens. Presentation of the GUI as a single screen is particularly suitable for us in a desktop computing environment. The multiple screen approach is suitable for mobile computing environments.

The Menu preferably has at least three sub-sections: Document, Report and Preference. A user may select from the Menu in order to activate any one of the sections. Selection of the Document brings up the Document Templates allowing the user to enter data. Selection of the Report brings up one or more reports which allow the user to query the master database and present the information in the form of a report. Selection of the Preferences allows the user to modify system settings.

When a user activates any one of the Documents, the Editor will simultaneously display the currently active Document and the Simulator on the GUI. The user may then enter data through either the Document or the Simulator.

The various sub-sections of Editor may be presented to the user in a variety of different combinations. The combination of currently selected Document, Simulator and Menu is shown illustrated in Figure 3. The Document may be, for example, an Invoice, Journal, Company details or Product details.

The Simulator is concurrently displayed with the active Document to allow the user to enter or edit data entries. Data entries may be entered either through a currently active Document or through the associated Simulator (or through both Document and Simulator). This data can be inputted either by a user manually or generated by the software automatically. The system of the present invention may generate a Report. The Report may, for example, be a Cash Register, Debtor Analysis, Income Statement, Balance Sheet, or an Inventory Analysis. The Preference option allows any change of settings for the Simulator, a Document, a report template, access control, change of password.

When selecting a Document for data entry, the transaction data showing on the Document and the Simulator are simultaneously linked and immediately synchronised for displaying and editing data.

In the conventional computerised accounting systems, financial statements are based on an established concept of five major groups: Assets, Liabilities, Revenues, Expenses and Equity. These groups and their interactions within an accounting system often produce confusion among users of accounting software. In contrast, one embodiment of the present invention emphasises only two groups of Worth: Owned, and Claimed. The two groups are analogous to assets and liabilities. This embodiment of the invention treats every Analysis as part of either an assets accumulating Worth in the Owned group or as a liabilities-accumulating Worth in the Claimed group. Each Analysis is categorised depending on whether it increases or decreases the value of its associated Worth. The associated Worth has a positive value by default.

A positive Analysis entry increases the value of its associated Worth while a negative Analysis decreases the value of its associated Worth. The approach of using two groups of Worth accounts can be utilised for producing a variety of financial reports and statements as these reports and statements utilise the same set of Worth accounts and each Worth account's plurality of associated Analysis account. Hence, in this embodiment of the present invention, the user needs only to visually select an appropriate account from two groups of Worth accounts to enter data.

In one further embodiment of the present invention, the Simulator is presented on screen using a spreadsheet format. Each cell is assigned a coordinate index of combination letter and/or number to indicate a particular cell on the spreadsheet for each individual cell position. Each indexed cell is designed to accept and display the inputted data. The inputted data may be entered as a absolute value or alternatively it can be assigned a positive or negative value. This can be done by using the keyboard, using the mouse and highlighting the cell or by choosing an option from a selection list or menu. All the assets- and liability accumulating accounts are grouped into two separate balance-verifying columns. These two balance-verifying columns contain the Worth account from Balance Sheet. This provides for the simulation of incremental changes in financial performance and position as it is affected by the data entered by the user. A Worth column on the left-hand side of the user's screen is termed "Owned", this is used for assets while another column on the right-hand side of the user's screen is termed "Claimed" to represent liabilities. Each Worth account in the columns has a pre-defined association linking to a plurality of Analysis accounts associated with the Worth.

In one embodiment, a pair of Analysis and Worth items are displayed on the right-hand side of the users screen. Claimed Worth items are each located in the same row of the spreadsheet. If the same Worth is affected by more than one Analysis account, each Analysis account is displayed individually in a separate row with the Worth appearing more than once in a plurality of rows. Alternatively, if two or more entries involve the same Analysis and the same Worth, only one Analysis using a combined value and only one Worth using a combined value will be displayed. When the user chooses to process the data entered, the software will automatically verify that the total amount for the plurality of Worth matches the corresponding column. The Worth may be selected by using a selection list 'Worth?' which can be a drop-down or pop-up menu for one or more Worth accounts. The selection lists of 'Worth?', '+ / - ?' and 'Analysis?' are each designed using a relational menus. This screen design is shown in Figure 4 which illustrates a user entering data into an Analysis account. Figure 5 illustrates a user entering data into a Worth account.

These relational menus include two balance-verifying columns together with four other columns for selection of increments and accounts. A user may only enter data through the Analysis accounts. When data is entered into the Analysis account, the data is simultaneously displayed on both the Analysis and the Worth accounts in each of the Analysis and Worth columns. When the Analysis accounts associated with a Worth are displayed in an Analysis column, the column also displays the Worth account as a Virtual Analysis account in order so that the user may enter data to the Worth using the Analysis column.

A Virtual Analysis displays an Analysis selection list together with other Analysis associated with a particular Worth. When user selects to display a Virtual Analysis, it is assigned with an indexed cell in the Analysis column to be displayed with the same account name as the Worth account. The user will be presented with a list of all the Analysis accounts (including a Virtual Analysis account) which are concurrently available for a user's selection. The user may then select a '+' or a '-' sign, the Virtual Analysis with the same name as the associated Worth account is then displayed with either '+' or '-' sign.

When using a Virtual Analysis to enter data to a Worth, the entry is defined as a single entry. A transaction must involve at least two entries in different Worth accounts. These Worth entries may be entered on the Owned or Claimed side, or on both sides. The Virtual Analysis is particularly useful for establishing a list of opening balances on the balance sheet for a brand new business.

With either the Simulator or a Document, the user need only enter the absolute value without a "+" or "-" sign. If a positive sign is selected with a selected Analysis, the Analysis is stored as positive value. If a negative sign is selected with a selected Analysis, the Analysis is stored as a negative value. These values are stored temporarily on the computer RAM/hard disk.

A positive value of Analysis increases the value of either Owned or Claimed Worth. A negative value of Analysis decreases the value of the Owned or Claimed Worth. The signed value of a Worth is defined as positive by default. A negative signed value of Worth represents a decrease of Worth, and a positive signed value of Worth represents an increase of Worth. When the user enters an absolute value, a pair entries consisting of a Worth and an Analysis are stored temporarily in the computer RAM/disk. Each entry is stored with a prefix and the entered as an absolute value. The coordinate of each indexed cell displays either the value or signed value. The prefix consists of three elements: (a) Owned or Claimed; (b) Worth or Analysis account; and (c) either "-" or "+" sign depending on whether the value is positive or negative. The coordinate may be a combination of letter and number (for example, A1).

Figure 4 illustrates a user entering data into an analysis account. In Figure 4, selecting from the Claimed column, then the 'Earnings' Worth, then the + sign for increase. Entering 115000 under the 'Sales' Analysis will generate a 'Sales CA+115000 @A9' on 'Sales' Analysis account and an 'Earnings CW+115000 @A7' on 'Earnings' Worth account in the balance-verifying column.

With reference to Figure 5, selecting from the Claimed column, then the 'Creditors' from Owned Worth, then the "-" sign to indicate a decrease, and finally the 'Creditors' Virtual Analysis to enter 1500. This will generate a 'Creditors CW-1500 @A7' on 'Creditors' Worth account in the balance-verifying columns.

For every transaction, the software automatically checks to ensure that the incremental changes of Worth accounts on both Owned and Claimed columns are matched the in the balance-verifying columns by showing the running balance as zero. When a user confirms that they wish to proceed with a transaction, the verified data (such as the above 'Sales CA+115000 @A9' , 'Earnings CW+115000 @A7' and 'Creditors CW-1500 @A7') is transferred to the Transaction Processing subsystem for further processing.

A conversion table as per Figure 6 illustrates that the prefix of OW+, OW-, OA+, OA-, CW+, CW-, CA+, or CA- may be converted by the present invention into an equivalent debit or credit notation in the traditional double-entry convention.

When displaying a signed value of individual Analysis or Worth, a positive value is displayed either with or without a positive sign adjoining to its absolute value. Displaying a negative value of an Analysis or Worth may be presented in one format on the Simulator and in a different format on the Document. With the Simulator, the negative value of an Analysis may be displayed without a positive or negative sign. However, the negative value of a Worth is displayed with a negative sign being based on the selection of negative for decreasing of assets or liabilities. In a document, whether a negative value is displayed depends on the individual documents.

Since data entries may be entered either manually by the user or automatically by the software through the integration of the Simulator and the Document. The potential incremental changes displayed on screen are therefore partly automatically generated by the accounting software or in response to the transaction data entered by the user. For an Analysis or Worth entry shared commonly by both the Document and the Simulator, the data of the Analysis or Worth is displayed on both the Document and the Simulator simultaneously.

This common data is displayed with the aide of the interactive capability between the Document and the Simulator provided by the present invention.

Where any data is common to two or more sections, the data entered on one section is automatically displayed on the other sections as required. This allows for entry of common data through either the Document or the Simulator.

There are two types of Document: Default and Non-Default. Where a user prefers to use the Document for entering data then he/she may choose to use a default Document such as an invoice. After selecting a default Document, a set of Worth and associated Analysis are immediately pre-selected and displayed to accept data entries. The pre-selection for an individual default Document is pre-defined and may be modified by the user.

The present invention allows a user to use the Simulator for non-standard modifications thereby overcoming a problem present with many known systems where the Document has a default setting linked to many accounts that cannot be modified when encountering special requirements. The default Document of the present invention can accept any ad hoc modifications to simulate and display the special requirements of individual transaction, in order for the transaction processing subsystem to update data according to these modifications. The flexibility to accept these modifications is particularly useful for more advanced users.

The currently pre-selected Analysis and Worth on the Double-Entry Simulator can be manually modified with extra Analysis and Worth being additionally selected by a user as required. A hybrid system combining both cash-based and accrual-based transactions required by some non-profit organizations such as government can be operated according to the present invention. Data entered on the Document may automatically create relevant data entries on the Simulator.

An entry of quantity on an invoice Document will create one entry for each quantity. An entry on the Simulator may create four entries including Owned Analysis product, Owned Worth inventory, Claimed Analysis cost of sales and Claimed Worth earnings. The 'product #' or product number is actually an Analysis number. Another entry or selection of price on the invoice Document will create four entries on the Document including product price, amount for the product, ex-GST (Goods and Services Tax) amount, and total amount for the invoice. It will also create four entries on the Simulator including Claimed Analysis sales, Claimed Worth earnings, Owned Analysis customer, and Owned Worth debtors. A selection of GST code on the Document will create four entries on the Document including GST rate, GST amount, GST total and total amount for the invoice. It will also create four entries on the Simulator including Claimed Analysis ATO-GST (Australian Taxation Office- Goods and Services Tax), Claimed Worth Accrual GST, Owned Analysis customer, and Owned Worth debtors.

The Worth inventory has two different Analysis accounts - Computer and Printer, each Analysis account is shown individually in a separate row and the Worth inventor will be displayed twice with different indexed cells in two rows. Given that the two entries for different products involve the same 'Cost of sales' Analysis and the same 'Earnings' Worth, they are preferably displayed in two rows, using different indexed cells each time for the same 'Cost of sales' or 'earnings' account. Alternatively, they can be combined and shown in the one row by combining them into one Analysis account and one Worth account.

A plurality of default Analysis and Worth generated on the Simulator may be automatically "popped up" to display against other information entered on the Document. This allows users to check the effects on Analysis and Worth as they make entries on the Document. It also allows the user to ensure that the total signed value of Worth accounts fulfils the double-entry accounting principle. According to the principle of "What you see, is what is you get" (WYSIWYG), the entries displayed on the Simulator simulate and/or equate the incremental changes that are updated permanently on the master database.

When using a non-default Document such as a general journal as shown in Figure 8. A user enters data preferably on the Simulator and alternatively on the Document. Modifications can be made on either the Document or the Simulator. When a user wishes to enter data into the general journal, it is particularly preferable to use a non-default Document and the concept of Owned and Claimed as per the present invention.

The selection of a "+" or "-" sign on Worth and Analysis in the Owned or Claimed group on the Simulator directly activates and displays simultaneously on the non-default Document, a synchronised Owned or Claimed Analysis with either a positive or negative value. This approach not only simplifies the traditional approach of handling debit and credit entries, but also provides an easy to understand a clear picture of a business' financial performance and position. In a non-default Document, none of the Worth or the associated Analysis on either the Document or the Simulator is pre-selected or displayed. A user may enter data through the Simulator including two major and sequential steps: Selection and Entry.

In the Selection step (which may involve one or more actions), a user initially selects from the appropriate Worth (with an initial value of zero amount) a selection list 'Worth?' of Worth accounts. The user then selects from two groups of Worth accounts for Owned Worth and Claimed Worth. The decision depends on whether the data is related to assets- or liabilities-accumulating. The user then selects from a "+ " or "-" from the selection list. The decision is made depending on whether the data to be entered increases or decreases the value of the already selected Worth. The user then selects from a selection list 'Analysis?', an appropriate Analysis from a plurality of Analysis accounts that has a pre-defined association directly with the selected Worth. A Worth account, like inventory, may have an identical set of Analysis accounts for selecting either positive or negative sign. However, for the Analysis associated with a Worth (such as earnings or machinery value), the Analysis accounts are typically two different sets: One set of Analysis accounts has a positive value (eg. sales, machinery costs, etc.) indicated by the user selecting a positive sign, the other set of Analysis accounts is of a negative value (eg. cost of sales, depreciation, etc.) indicated by the user selecting a negative sign. The above approach of the present invention utilises visual aides to simplify the decision making process and present a user friendly interface for the entry of data. This makes it faster and easier for the user to enter data, it also minimises the possibility of errors resulting in a more accurate accounts.

The linking and organising all Analysis and Worth accounts into interrelated selection lists assists in facilitating efficient operation of the selection step.

In one embodiment of the present invention, there are provided multiple Analysis' in the selection list 'Analysis?' for each Worth. The individual Analysis may have either a positive value or negative value. An increase in value for either an assets or liabilities accumulating items is shown as a positive value. A decrease is shown as a negative value. The user may enter the absolute value of an Analysis without entering the corresponding positive or negative value. The combination of a positive or negative sign and the entered absolute value for an Analysis associated with a Worth generates the Worth's signed value. This is always equal to the increased or decreased amount of the Analysis.

The accounting software of the prior art utilises a bottom-up approach. A transaction is commenced by selecting a source level account for data entry (for example, sales and customer). The majority of data entered by the user (at either a source or final level) into the ledgers (such as debitors and inventory) are completely hidden from the user. The present invention, in one embodiment, utilises a top-down approach. When performing data entry, a user is required to firstly select a final level Worth (such as earnings) from a selection list 'Worth?'. The user then chooses from a either a positive or negative icon from a selection list to decide whether the Worth is positive or negative. After selecting from the selection list, the user will be presented with a corresponding list of source level Analysis options. For example, the sales Analysis will appear on the selection list 'Analysis?' when the user selects the positive sign. The cost of sale Analysis will likewise appear when the user selects the negative sign. Finally, an Analysis is selected from the 'Analysis?' selection list and then data is entered to the selected Analysis.

In the Entry step (which may involve one or more actions), the user initially enters an absolute value of transaction data into the selected Analysis of the Simulator. The data is then immediately displayed on the selected Analysis. In some cases, the user may then select one or more flags that represent the sub- categories (such as departments or product groups) of the selected Analysis, or change the positive or negative sign as appropriate. The selected Analysis is then displayed simultaneously on the associated Worth in the middle columns. The signed values together of both Analysis and Worth then temporarily stored in the computer RAM/Disk and displayed simultaneously on both the Document and the Simulator.

The data stored on the computer RAM/Disk may be edited before the user elects to permanently save the data onto the master database. The user may edit by entering further information into the Document. The account number shown is either an Analysis account number or a Worth account number.

When the user enters a negative 'Wages" Analysis associated with the "Earnings" worth, the user will be presented with one set of two entries. These will include Claimed Analysis 'Wages' and Claimed Worth 'Earnings' both of which will be displayed on the Simulator and the Document. The Simulator will temporarily be out of balance at this point and the user will be required to enter further data until the Simulator is balanced. Next selection and entry of the positive 'Wages" Analysis associated with "Accruals" Worth will have anther set of entries such as Claimed Analysis 'Wages' and Claimed Worth 'Accruals' which will be displayed on both the Simulator and the general journal Document. This will balance the Simulator.

The data entry subsystem of the present invention simulates and instantly displays the four entries on the Document by representing them as both a pair of adjusting entries and a pair of closing entries. The four entries are then updated and processed on the master database together.

The data entry approach adopted in prior accounting systems displays each pair of adjusting entries separately. That is, without indicating the status of the corresponding pair. The approach of the present invention in displaying each pair together provides the user with a complete picture of both pairs of entries simultaneously.

Figure 9 illustrates an alternative embodiment where conventional debit and credit notations are used on the Document.

Each selected list for either Worth account or Analysis account is chosen from one of the interrelated lists from the Accounts Database. A selection list can be built and defined by utilising the Preference Menu. The selection list of Analysis can be linked to either a positive or negative sign depending upon the nature of an individual Worth. A particular Worth may be the same for items such as inventory, alternatively, it may be different for items such as sales and cost of sales. The total signed value for a Worth group is the combined values in each group.

The signed values of each Owned or Claimed column are then added. The Simulator maintains a running total for each column of Worth to verify the double entry balancing. The running total of each Worth group is derived by combining the signed value of all the Worth in the same column. The invention allows the user to visually inspect the running balance sheet between the two groups of Worth as he/she is entering the data. The running balance is displayed to immediately indicate to the user when there is an error such that the entered data does not fulfil the double-entry accounting principle. The user's selection of earnings Worth to offset the incremental changes from other Worth is particularly useful in making the running balance zero or detecting errors. When the user is satisfied with the integrity of the data, they can then choose to save the data displayed on the screen. The data will then be saved and transferred to the master database. The master database will only accept this data if the running balance is zero. If the balance is not zero, the software will reject the data and require that the user check the data to ensure that all necessary corrections are made. The present invention allows the user to visualise the potential incremental changes affected the each current transaction, this gives the user a better chance to detect and correct any errors.

One embodiment of the invention treats earnings as a Worth account associated with a plurality of Analysis accounts. These include different streams of revenue (with positive values) and different types of expenses (with negative values).

For the Worth of fixed assets, the current values (for example, machinery value) are derived by combining the positive value Analysis (for example, machinery costs which represents an increase in the value of assets) and the negative value Analysis (for example, depreciation which represents a decrease of assets). The machinery costs and the depreciation are two separate Analysis accounts that are directly associated with the 'machinery value' Worth.

When a user clicks the 'HERE' button (as shown in Figures 3, 7 to 9) on their screen the information from the Simulator will be permanently saved in the master database. All the entered transaction data will be verified by the software to ensure that the total amount of Owned group for assets and the total amount of Claim group for liabilities are equal thereby ensuring that the running balance is zero. The transaction data entries are then finalised into two total amounts with the two groups of Worth being matched and equal. If the two groups of Worth are not equal then the user is advised and prompted to check for any corrections and if necessary to re-enter the data.

The present invention ensures that the total amount in the Owned group of Worth accounts is at all times equal to the total amount in the Claimed group of Worth accounts.

It has previously been difficult to correctly update debit and credit entries. In the present invention, the concept and knowledge of 'debit or credit entry' are not required in order for the user to enter data. This greatly reduces the chance of selecting a wrong account. The software related to the Double-Entry Simulator embodied by the present invention utilises a double-entry protocol that is fully compatible with conventional double-entry accounting principles. Hence, with the present invention, the concept and terminology of performing debit and credit entries can be completely abandoned.

A chart of accounts in the prior art computerised accounting systems refer to indexed accounts in the general ledger with each being assigned a unique number or code. A user classifies accounts and assigns account codes covering the accounts on both income statement and balance sheet. The user is not required to set up any associations between a conventional chart of accounts and other unrelated lists of accounts for items such as inventory and debtors in the software's master database. A conventional chart of accounts approach for general ledger uses a highly structured coding scheme to systematically organise the accounts by the codes for generating financial statements in the Report Generation Subsystem. It also provides support for entering data in the Data Entry Subsystem. Experience and knowledge are required for the planning, organising, establishing, adding, deleting and changing of accounts in a conventional chart of accounts for general ledger. A chart of accounts for the general ledger is set up by grouping all accounts for general ledger into basically five groups: Assets, Liabilities, Equity, Revenues, and Expenses. In the present invention, there is provided an Accounts Database which consists of a plurality of lists of accounts for items such as general ledger, debtors and inventory. These items are preferably managed by a relational database management system which sets up uniquely assigned codes which are linked by relational associations. The data between lists of the present invention can therefore be organised and manipulated by the interrelations and the master database to provide expandable information.

Due to the interrelated structure of the Accounts Database in the invention, displaying and editing additional information such as price, cost, quantity, location of each Worth or Analysis on screen can be easily achieved.

The Accounts Database may be either integrated with the master database in a LAN environment, or separated from the master database in a WAN or Internet environment. Many suitable database system approaches including flat file, relational, SQL, object-relational, database server and database client may be used for the Accounts Database and/or the master database. All accounts including their codes and information may have associations in a master database. The association relationships are shown on screen using a plurality of selection lists such as pop-up or drop-down menus. The use of relational selection lists replaces the structure of a conventional chart of accounts and codes that are no longer absolutely required with the present invention.

In the existing systems, both machinery costs and accumulated depreciation of machinery may be included in the conventional chart of accounts as two separate assets accounts. A negative value is assigned to the depreciation account. The machinery value is defined as a heading for reporting purpose. In one embodiment of the present invention, there is provided a table of Worth accounts for Owned, another table of Worth accounts for Claimed. Only the machinery value Worth is included in the table of Worth accounts for Worth Owned (equivalent to assets); the machinery costs is an Analysis of positive value and the depreciation of machinery is another Analysis of negative value. These two Analysis accounts are included separately in two selection lists of Analysis accounts which are associated directly with the machinery value Worth. Similarly, the earnings Worth may have an associated Analysis which includes some of positive value and some of negative value from two separate selection lists of Analysis accounts associated with earnings Worth. One embodiment of the present invention integrates all accounts in the lists of accounts with a hierarchy structure by using a plurality of selection lists that are designed to facilitate selecting accounts and entering data. These lists of accounts are preferably arranged into separate columns using a spreadsheet format with indexed cells.

Figure 10 illustrates a Menu Editor having dialog boxes for creating and editing Analysis, Worth and the associations between Analysis accounts and Worth accounts. A Worth account (for example, Inventory) typically has more than one Analysis account (for example, Computer and Printer). An Analysis account (for example, Wages) may have two parts that are each associated with more than one Worth account. The Wages Analysis has a positive part for an increase of an Accruals Worth and a negative part for a decrease of an Earnings Worth. The individual association of these two parts of the same Analysis account must be specifically linked to different Worth accounts set up by a user. The Owned Worth account may be created by first selecting an existing Owned Worth account from the 'Worth?' selection list, clicking the 'Insert' button, following the prompt displayed in an empty cell at the bottom of the Owned Worth selection list column. The prompt will request that the user enter a new account name. The user may then click the 'Save' button to confirm the desired new account. Each individual account is assigned a unique account code either by a user or by the software. Establishing an association between Wages Analysis and Accruals Worth can be effected by first selecting the Wages Analysis account from the 'Analysis?' selection list and then by clicking the association arrow '<--' to display the selected Wages Analysis in the Association table. The user then selects the Accruals Worth account from the 'Worth?' selection list and clicks the association arrow '— >' to display the Accruals Worth in the Association table. It is then necessary to select the '+' from the '+, - or +&-' list to indicate the type of association, and then to click the 'Save' button to confirm the desired association. The selection of '+, - or +&-' is determined by whether the Analysis will to increase, decrease, or both increase/ decrease the value of the selected Worth. Viewing the association of an Analysis (or Worth) account can be affected by first selecting the Analysis (or Worth) account, and then clicking the 'View' button to allow the software to automatically display all the associated Worth (or Analysis) accounts on the Association table, of which each pair of Analysis and Worth accounts will have its associated '+', '-' or '+&-' sign displayed. Each selection list may be set up to display the accounts in a sorted order such as alphabetically ascending. The accounts in the same Worth or Analysis selection list can be subdivided into several subgroups to facilitate display and selection process. This subgroup approach for establishing associations between Analysis and Worth accounts allows a conventional chart of accounts and other conventional lists of accounts for such as debtors and inventory to be incorporated, integrated and displayed on the Menu Editor. The establishment of associations between Analysis and Worth accounts in the present invention provides an intelligent approach to guide a user to choose from only the accounts that have predefined associations, this greatly reduces the chances of choosing wrong accounts to enter data.

In the present invention, producing financial statements including income statement and balance sheet can be managed in the same way as other financial reports by utilising a report generation subsystem. A sample Analysis Account Report or income statement is shown in Figure 11. A sample Worth Accounts Report or balance sheet is shown in Figure 12.

Reports including financial statements may be produced through a report generator utilising the present invention. Different formats of balance sheet and income statement can be produced accordingly for the needs of various stakeholders.

In a networked environment as illustrated in Figure 13, the Accounts Database (which is a part, a total, a partial replication or a total replication of the Master Database) on a client machine is separated from the master database and its accounts database on the server machine. This distributed computing arrangement is particularly suitable for Internet-based accounting systems. For Internet-based and browser-enabled operations, the Editor and the Accounts Database on client machine are initially updated from the server and downloaded onto the client machine. The Accounts Database may also include the templates for inquiry portion, excluding the reporting data. Because the data displayed on the Simulator is not the actual transaction data on master database, the client machine for the Editor and the Accounts Database can therefore work with some data for price, cost and inventory that can be cached on the web browser and if required stored on the client machine. The software system then can provide off-line operations when the Internet connection is temporarily disconnected during the editing and updating of data. When displaying data entries on screen in an off-line situation, the Simulator on a client machine can still use the cached or stored data on the client machine to provide the approximate values. The entered data will be updated on the accounts data when the Internet connection is re-established. This configuration, as shown in Figure 14, assists in reducing the amount of Internet traffic between the server machine. Where both the client machine and the server machine have the capability to forward a query and report from one database on one machine to another database on another machine, a database proxy architecture can be used through a proxy software to provide on-the-fly data compression and encryption for the query and report over the Internet. This improves the processing capability and reduces the amount of time consumed by the server machine.

In a networked and multi-user environment (such as when Internet-based operations are involved), it may not be possible to display the exact values of actual changes to be saved on the server's master database including its accounts database for such as 'Cost of goods sold' and 'Earnings'. When they are displayed during Data Entry subsystem, they are automatically generated by the software according to data entered by the user, and directly affected by the latest data such as 'Product cost' that have been very recently saved on the server's master database including its accounts database, and the client's accounts database. These two accounts databases are simultaneously updated and synchronised, particularly in an Internet-based accounting environment. Any changes of "Product cost' on the server's master database and its accounts database due to the entered data from other users by certain transactions such as purchase price on supplier invoice can cause the 'Product cost' data on the client's accounts database to become outdated at the user's machine. This occurs because the exact value of 'Product cost' to be saved on master database can only be calculated by the Transaction Processing Subsystem. In some cases, the Simulator may display the values of 'Product cost', 'Cost of goods sold' and 'Earnings' only with approximate values on screen. Before saving any data on the master database on server machine, the verified data displayed on the screen is inputted and classified into two types: Exact and Approximate. The Exact type shows the exact values (either manually entered by a user or automatically generated by the software). The Approximate type uses the approximate values that are automatically generated and derived by the software. The Transaction Processing subsystem on server machine then will operate a Data Rectification process to replace the approximate values with their exact values that are derived from the most updated data on master database. This Data Rectification process can be done simply by verifying that whether or not the latest data of the same variable, say 'Product cost', on the two accounts databases located separately on both the server and client machines are different. The approximate values that were derived from 'Product cost' on client's accounts database will be also saved together with their exact values that are based on the current 'Product cost' on master database and its accounts database. And the 'Product cost' on client's accounts database will be also automatically updated accordingly. During the Report Generation subsystem process, only exact values will be used to generate financial reports. It is to be understood that various additions, alternations and/or modifications may be made to the contents previously described without departing from the ambit of the invention.

Claims

Claims defining the present invention are as follows:

1. A double entry computerised accounting system, including: (a) an accounts database for storing accounts data; (b) an input module for accepting inputted accounts data; wherein the input module includes an accounts simulator, the simulator presenting a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

2. A computerised accounting system according to claim 1 , wherein a user is presented with a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database to allow the user to visually verify the accuracy of the inputted data as it is being entered and before it is transferred to the accounts database.

3. A computerised accounting system according to any one of claims 1 to 2, wherein the input module operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database.

4. A computerised accounting system according to any one of claims 1 to 3, wherein the simulator prevents transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.

5. A computerised accounting system according to any one of the preceding claims, wherein the input module includes a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator.

6. A computerised accounting system according to any one of claims 1 to 5, wherein a user may enter inputted accounts data directly into either the document template or the accounts simulator.

7. A computerised accounting system according to any one of the preceding claims, wherein the input module includes replication data being a replication of at least part of the accounts database, wherein the simulator may access the replication data to provide the simulation display.

8. A computerised accounting system according to any one of claims 1 to 7, including a data rectification module which receives data from the input module and determines whether any of the inputted data includes or is based on any replication data that is different from current data in the accounts database and if so, corrects the replication data based on the current data.

9. A computerised accounting system according to any one of the preceding claims wherein each item of data entered is classified into one of two categories of:

(a) owned worth representing an item having an assets accumulating nature; and

(b) claimed worth representing an item having a liabilities accumulating nature, which is equivalent to an assets decreasing nature.

10. A computerised accounting system according to any one of claims 1 to 9, wherein the inputted accounts data may only be transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth.

11. A computerised accounting system according to any one of claims 1 to 10 , wherein each owned or claimed worth is linked with one or more analysis accounts.

12. A computerised accounting system according to any one of the preceding claims, wherein the input module is located on a user's computer and the accounting database is physically located : a. on the user's computer, b. at a location remote from the user's computer, or c. both concurrently on the user's computer and at a location remote from the user's computer.

13. A computerised accounting system according to any one of the preceding claims, wherein the input module utilises a combination of indexed cells together with positive indicators and negative indicators in substitution for conventional debit and credit notations.

14. A computerised accounting input module for entering accounts data into an accounts database, the accounting input module including an accounts simulator; wherein the accounts simulator presents a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

15. A computerised accounting input module according to claim 14, wherein a user is presented with a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database to allow the user to visually verify the accuracy of the inputted data as it is being entered and before it is transferred to the accounts database.

16. A computerised accounting input module according to any one of claims 14 to 15, wherein the accounts simulator operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database.

17. A computerised accounting input module according to any one of claims 14 to 16, wherein the accounts simulator prevents transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.

18. A computerised accounting input module according to any one of claims 14 to 17, further including a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator.

19. A computerised accounting input module according to any one of claims 14 to 18, wherein a user may enter inputted accounts data directly into either the document template or the accounts simulator.

20. A computerised accounting input module according to any one of claims 14 to 19, wherein the module includes replication data being a replication of at least part of the accounts database, wherein the simulator may access the replication data to provide the simulation display.

21. A computerised accounting input module according to any one of claims 14 to 20, wherein each item of data entered is classified into one of two categories of:

(a) owned worth representing an item having an assets accumulating nature; and

22. A computerised accounting input module according to any one of claims 14 to 21 , wherein the inputted accounts data may only be transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth.

23. A computerised accounting input module according to any one of claims 14 to 22, wherein each owned or claimed worth is linked with one or more analysis accounts.

24. A computerised accounting input module according to any one of claims 14 to 23, wherein the input module is located on a user's computer and the accounting database is physically located either: a. on the user's computer, b. at a location remote from the user's computer, or c. both concurrently on the user's computer and at a location remote from the user's computer.

25. A computerised accounting input module according to any one of claims 14 to 24, wherein the accounts simulator utilises a combination of indexed cells together with positive indicators and negative indicators in substitution for conventional debit and credit notations.

26. Double entry accounting software, including:

(a) an accounts database component for storing accounts data; an input module for accepting inputted accounts data; wherein the input module includes an accounts simulator, the simulator presenting a graphical display that simulates the data, displaying changes that the inputted data will have on the stored accounts data before the inputted data is transferred to the accounts database.

27. Double entry accounting software according to claim 26, wherein a user is presented with a simultaneous display of the changes that will occur when the inputted data is merged with the data on the accounts database to allow the user to visually verify the accuracy of the inputted data as it is being entered and before it is transferred to the accounts database.

28 Double entry accounting software according to any one of claims 26 to 27, where the input module operates to check the inputted accounts data, before transfer to the accounts database, to ensure that the accounts database will be balanced when the inputted data is transferred to the accounts database.

29. Double entry accounting software according to any one of claims 26 to

28, wherein the simulator prevents transfer of the inputted accounts data to the accounts database where transfer of the inputted accounts data to the accounts database would result in the accounts database not being balanced.

30. Double entry accounting software according to any one of claims 26 to

29, wherein the input module includes a document template to receive inputted accounts data; the document template being dynamically linked to the accounts simulator.

31. Double entry accounting software according to any one of claims 26 to

30, wherein a user may enter inputted accounts data directly into either the document template or the accounts simulator.

32. Double entry accounting software according to any one of claims 26 to

31 , wherein the input module includes replication data being a replication of at least part of the accounts database wherein the simulator may access the replication data to provide the simulation display.

33. Double entry accounting software according to any one of claims 26 to 32 , including a data rectification component which receives data from the input module and determines whether any of the inputted data includes or is based on the replication data that is different from current data in the accounts database and if so, corrects the replication data based on the current data.

34. Double entry accounting software according to any one of claims 26 to

33, wherein each item of data entered is classified into one of two categories of:

(a) owned worth representing an item having an assets accumulating nature; and (b) claimed worth representing an item having a liabilities accumulating nature, which is equivalent to an assets decreasing nature.

35. Double entry accounting software according to any one of claims 26 to

34, wherein the inputted accounts data may only be transferred to the accounts database when the total amount of claimed worth is equal to the total amount of owned worth.

36. Double entry accounting software according to any one of claims 26 to 35, wherein each owned or claimed worth is linked with one or more analysis accounts.

37. Double entry accounting software according to any one of claims 26 to 36, wherein the input module is located on a user's computer and the accounting database is physically located: a. on the user's computer, b. at a location remote from the user's computer, or c. both concurrently on the user's computer and at a location remote from the user's computer.

38. Double entry accounting software according to any one of the claims 26 to 37, wherein the input module utilises a combination of indexed cells together with positive indicators and negative indicators in substitution for conventional debit and credit notations.

39. A computerised double entry accounting system, substantially as herein described, with reference to any one or more of figures 2 to 14.

40. A computerised accounting input module for entering accounts data into an accounts database, substantially as herein described, with reference to any one or more of figures 2 to 14.

41. Double entry accounting software, substantially as herein described, with reference to any one or more of figures 2 to 14.