P/00/01 i Regulation 3.2 AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT (ORIGINAL) Name of Applicant: MYOB Technology Pty Ltd, ACN 086 760 269, of 12 Wesley Court, Burwood East, Victoria, 3151, Australia Actual Inventors: Chris KNIGHT Andrew Craig WINKLER Alison PATCHETT Raymond Anthony LANCELOT Kelly Anne TULK Belinda DAL LAGO Richard PUFFE Paul Joseph MONKS Address for Service: DAVIES COLLISON CAVE, Patent Attorneys, of I Nicholson Street, Melbourne, Victoria 3000, Australia Invention Title: An accounting system Details of Associated Provisional Application: 2008906465 The following statement is a full description of this invention, including the best method of performing it known to us:- C:\RPonbhDCC\MAG26205NX I DOC. 14/12/21X)9 AN ACCOUNTING SYSTEM FIELD 5 The present invention relates to accounting systems and methods. BACKGROUND Business and trading entities currently rely on technically complex computer systems to 10 manage their various accounts. Despite the sophistication and technical complexity of these accounting systems, most entities typically require a skilled practitioner, such as a trained accountant, and a considerable amount of time to correctly enter and process data in order for the accounting system to generate and provide financial data required by various other entities, such as government taxation offices and regulatory authorities. It is 15 particularly burdensome in time and cost for small businesses and micro-businesses to generate accurate accounts, determine taxation obligations and report on their accounts in a way that conforms to taxation regulations using existing accounting systems. The systems are technically limited in the processing they are able to perform, and in view 20 of these limitations, parties are prone to errors in accounting for their transactions, in determining their taxation obligations and in reporting their activities. The limitations in existing accounting systems also give rise to errors being made in determining tax liability in a current tax reporting period if account data are amended, e.g. by entering new transactions, that relate to previous tax reporting periods. 25 It is desired to address or ameliorate one or more limitations or disadvantages associated with the prior art, or to at least provide a useful alternative. 30 C:\NRPonbl\DCC\MAG\2620858_ .DOC-15/12/200)9 -2 SUMMARY In accordance with the present invention there is provided an accounting system, including: 5 a module for receiving transaction data representing at least one transaction; and a labelling module for associating label data representing a tax type with said transaction data based on a bank code or transaction text of the transaction data. The present invention also provides a data processing method performed by an accounting 10 system, including: receiving transaction data representing at least one transaction; and associating label data representing a tax type with said transaction data based on a bank code or text of the transaction data. 15 The present invention also provides an accounting system, including: a user input module for receiving tax reporting period data representing reporting dates of a tax reporting period; a data access module for accessing stored transaction data representing transactions and their transaction dates and transaction values, and used flag data representing whether 20 the transactions have been reported; a rules module for accessing rules data representing tax rules and their time limits and value limits for reporting tax liability; and a processing module for: determining transactions which are reportable in the tax reporting period 25 based on the used flag data and comparing the time limits with the reporting dates and the transaction dates, and comparing the value limits with the transaction values; and generating tax liability data representing a tax liability for the reportable transactions. 30 The present invention also provides a data processing method performed by an accounting system, including: CkNRPenbKlDCC\MAG2620$5H I DOC-14/12/2143/ -3 receiving tax reporting period data representing reporting dates of a tax reporting period; accessing stored transaction data representing transactions and their transaction dates and transaction values, and used flag data representing whether the transactions have 5 been reported; accessing rules data representing tax rules and their time limits and value limits for reporting tax liability; determining transactions which are reportable in the tax reporting period based on the used flag data and comparing the time limits with the reporting dates and the 10 transaction dates, and comparing the value limits with the transaction values; and generating tax liability data representing a tax liability for the reportable transactions. The present invention also provides an accounting system, including: 15 a user input module for receiving tax reporting period data representing reporting dates of a tax reporting period; a data access module for accessing stored transaction data, representing purchase transactions each with a transaction value, a transaction date, and a used flag representing whether the transaction has been reported; 20 a rules module for accessing rules data representing a capital value limit; and a processing module for: determining transactions which are reportable in the tax reporting period based on the used flag and by comparing the reporting dates with the transaction dates, determining transactions to be capital purchase transactions if the associated 25 transaction values are above the capital value limit, and generating capital purchase value data, representing a total capital purchase value for the tax reporting period, using the transaction values of the reportable capital purchase transactions. 30 The present invention also provides an accounting system, including: C-\NRPonblDCC\MAG\2620858 I.DOC.14/12/2009 i -4 a user input module for receiving tax reporting period data representing reporting dates of a tax reporting period; a data access module for accessing stored transaction data, representing purchase transactions each with a transaction value, a tax type, a transaction date, and a used flag 5 representing whether the transaction has been reported; a rules module for accessing rules data representing a capital value limit and a capital tax rate; and a processing module for: determining transactions which are reportable in the tax reporting period 10 based on the used flag and by comparing the reporting dates with the transaction dates, determining transactions to be capital purchase transactions if the associated transaction values are above the capital value limit, determining a tax value for the reportable capital purchase transactions based on each transaction value and the capital tax rate, if the tax type is a tax payable tax 15 type, and generating tax value data, representing a total purchase tax value for the tax reporting period using the tax values of the reportable capital purchase transactions. The present invention also provides a data processing method performed by an accounting 20 system, including: receiving tax reporting period data representing reporting dates of a tax reporting period; accessing stored transaction data, representing purchase transactions each with a transaction value, a transaction date, and a used flag representing whether the transaction 25 has been reported; accessing rules data representing a capital value limit; determining transactions which are reportable in the tax reporting period based on the used flag and by comparing the reporting dates with the transaction dates; determining transactions to be capital purchase transactions if the associated 30 transaction values are above the capital value limit; and C-\NRPonbr\DCC\MAG\262MN5 I DOC. 14/2/2IIX -5 generating capital purchase value data, representing a total capital purchase value for the tax reporting period, using the transaction values of the reportable capital purchase transactions. 5 The present invention also provides a data processing method performed by an accounting system, including: receiving tax reporting period data representing reporting dates of a tax reporting period; accessing stored transaction data, representing purchase transactions each with a 10 transaction value, a tax type, a transaction date, and a used flag representing whether the transaction has been reported; accessing rules data representing a capital value limit and a capital tax rate; determining transactions which are reportable in the tax reporting period based on the used flag and by comparing the reporting dates with the transaction dates; 15 determining transactions to be capital purchase transactions if the associated transaction values are above the capital value limit; determining a tax value for the reportable capital purchase transactions based on each transaction value and the capital tax rate, if the tax type is a tax payable tax type; and generating tax value data, representing a total purchase tax value for the tax 20 reporting period using the tax values of the reportable capital purchase transactions. The present invention also provides an accounting system, including: a user input module for receiving tax reporting period data representing a tax reporting period, from a user; 25 a data access module for accessing data representing a predetermined total sales value for the tax reporting period; and a processing module for generating export sales data representing an export sales value for the tax reporting period, based on multiplying the predetermined total sales value and an export percentage of total sales in the tax reporting period, represented by export 30 percentage data.
C NRPortbDCC\MAG\262085X I DOC. N/1I2/200) -6 The present invention also provides a data processing method performed by an accounting system, including: receiving tax reporting period data representing a tax reporting period, from a user; accessing data representing a predetermined total sales value for the tax reporting 5 period; and generating export sales data representing an export sales value for the tax reporting period, based on multiplying the predetermined total sales value and an export percentage of total sales in the tax reporting period, represented by export percentage data. 10 In embodiments, the label data, also referred to as transaction label data, associates a tax type against the transaction data. The bank code is a transaction code, also referred to as a "tran code", applied internally by the financial institution (such as a bank or a credit union) to the transaction data it sends. The bank code or the transaction text has a relationship to the tax type. The tax type may be "tax payable" or "tax free". Where goods-and-services 15 tax (GST) is payable, the tax type will indicate that the transaction is GST liable, is not GST liable, or does not require reporting to the relevant tax authorities, such as the Australian Taxation Office. GST is also referred to as a value-added tax (VAT) or a consumption tax. The accounting system can generate report data representing a tax liability value based on a transaction value and the tax type. The tax liability value can be 20 the amount of GST payable or redeemable associated with a transaction (e.g. a sale or purchase) represented by the transaction data. In embodiments, transaction values are referred to as transaction amounts. The tax reporting period can be a Business Activity Statement (BAS) period. The tax liability can 25 relate to a GST liability. In embodiments, the processing module can determine the capital purchase tax liability based on a tax rate (e.g. a GST rate) represented in the rules data. The capital value limit can be for example a Capital Purchase limit of $3,000. 30 C \NRPonbrDCC\MAG\262058_ I DOC-14/12/2009 -7 In embodiments, the export percentage data can be received by the user input module by the user directly entering an export sales amount. The export percentage data can be accessed by the data access module from prior tax period data representing an export sales percentage of a prior tax period. The export percentage of total sales can relate to a "G2 5 Export Sales" field in a BAS, and the "G2 Export Sales" field may equal "GI Total Sales" x "G2 %". In embodiments, an accounting system is configured to perform at least one of the methods described above. Computer-readable storage can have stored thereon program instructions 10 for executing at least one of the methods. BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the present invention are hereinafter further described, by way 15 of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of an accounting system, including webserver machines, application server machines and database machines; Figure 2 is a block diagram of components of the webserver machines; Figure 3 is a block diagram of components of the application server machines; 20 Figure 4 is a block diagram of components of the database machines; Figure 5 is a block diagram of modules of an application server component of the application server machines; Figure 6 is a flow chart of a registration process provided by the accounting system; 25 Figure 7 is a flow chart of a buying process provided by the accounting system; Figure 8 is a flow chart of a selling process provided by the accounting system; Figure 9 is a flow chart of a labelling process provided by the accounting system; Figure 10 is a flow chart of an alerting process provided by the accounting system; Figure 11 is a flow chart of a business activity statement (BAS) generation process 30 provided by the accounting system; C \NRPortbr\DCC\MAG\2620X58 I DOC-14/I21209 -8 Figure 12 is a flow chart of an adjustment monitoring process performed by the accounting system; Figure 13 is a flow chart of an inflow business activity statement (BAS) data generation process provided by the accounting system; 5 Figure 14 is a flow chart of an outflow business activity statement (BAS) data generation process provided by the accounting system; Figure 15 is a block diagram of application pages provided by the accounting system; Figures 16 to 25 are screen shots of a graphical user interface (GUI) provided by 10 the accounting system; Figure 26 is a schematic diagram of an exemplary server machine of the accounting system; and Figure 27 is a schematic diagram of an exemplary user computer system of the accounting system. 15 DETAILED DESCRIPTION System Overview 20 An accounting system 100, as shown in Figure 1, includes a server system 102 that provides accounting services and accounting processes for a remote user device 104, such as a personal computing device (personal computer, laptop computer, personal digital assistant, smart telephone, etc.) of a user, via a data network 106 such as the Internet. 25 The server system 102 transmits and receives data to and from the user device 104 through a first firewall 108, which includes communications components, anti-virus components, world-wide web (WWW) content filtering components, anti-spain components, traffic shaping components, virtual private network (VPN) components, and application specific integrated circuit (ASIC) acceleration. The first firewall 108 provides data protection 30 between the server system 102 and the data network 106.
C WRPonbl\)CC\MAG\2620x59 -. DOC.14/12/1XI -9 The server system 102 includes a web layer with webserver machines 110, in communication with the data network 106 via the first firewall 108 and a demilitarised zone (DMZ) switch 112. The webserver machines 110 are data processing and communications machines with high data processing speeds, high memory access speeds, 5 high data memory capacities, high-speed disks, and a plurality of storage disks to provide for redundancy. The webserver machines 110 provide a graphical user interface (GUI) to the user device 104 over the data network 106 by transforming data arrangements of the server system 102 and transmitting them to the user device 104, and receiving data from the user device 104 and transforming it in the server system 102. The DMZ switch 112 10 provides for data communication between the webserver machines 110, the first firewall 108 and a second firewall 116. The server system 102 includes an application layer with application server machines 114 connected to the DMZ switch 112 of the web layer by the second firewall 116 and a core 15 switch 118. The second firewall 116 has equivalent components to those of the first firewall 108. The core switch 118 provides for data communication between the application server machines 114 and the webserver machines 110, and a closed network 120 of the accounting system 100, as shown in Figure 1. The application server machines 114 include computing machines equivalent in hardware to the webserver machines 110. 20 The server system 102 includes a database layer with database machines 122 in communication with the webserver machines 110 and the application server machines 114 via a third firewall 124 and a production switch 126, as shown in Figure 1. The third firewall 124 has equivalent components to those of the first firewall 108. The production 25 switch 126 also provides for data communication between the database machines 122 and at least one Directory Controller (DC) computer 127 with an Active Domain (AD) service for hierarchically managing data in the server system 102. The database machines 122 are configured in a database cluster. The database machines 122 are generally equivalent to the webserver machines 110 in their hardware characteristics, except the database 30 machines 122 have a higher disk capacity, based on a larger number of disk drives, and a greater level of disk redundancy.
C:\NRPobrl\DCC\MAGu6208581 .DOC.14/12/200Y - 10 The closed network 120 provides for data communication between the server system 102 and administrative sub-systems including administrator customer-relationship management (CRM) machines 128, administrative devices 130 and administrator transaction machines 5 132, as shown in Figure 1. The administrator CRM machines 128 include CRM components 134 for receiving, storing and sending CRM data associated with registered users of the accounting system 100; registered users register using the registration process 500 described below. The administrative devices 130 provide administrative access to the components of the accounting system 100, and in particular the components of the server 10 system 102, to send administrative commands for configuration of the server system 102, and receive reporting data on the performance of the server system 102, which allows for administrative control and monitoring of the accounting system 100 by an administrator (such as MYOB Limited). 15 The administrator transaction machines 132 include transaction components 138 for receiving transaction data from one or more banks 136 which are financial institutions, such as a bank or a credit union, which process transactions for one or more users of the accounting system 100. The banks 136 are in communication with the server system 102 via the administrator transaction machines 132 and the closed network 120, as shown in 20 Figure 1. The banks 136 are also in communication with a transaction network 140 for exchanging transaction data between the banks 136 and one or more merchant facilities, and/or other banking and financial institutions that send and received transaction data. The transaction network 140 includes one or more credit card networks (e.g. VISA or MasterCard), election funds transfer networks (e.g. Bill Pay or Bpay or Post Bill Pay or 25 GiroPOST, or interbank money transfer) and/or internal networks of the banks 136. The transaction data represent transactions, such as sales transactions or purchase transactions, which are manually entered into the accounting system 100 by the user using the user device 104 (e.g. by a user typing data into a keyboard, or up-loading a spreadsheet 30 of transactions), and by the banks 136 (e.g. by transmitting transaction data from the transaction network 140 into the server system 102). The transaction data is generated by C \NRPonb\DCCMAG2620M5X_ DOC-14/I 2/20)9 - 11 the user making purchases, or buying, or by making sales, or selling. The transaction data is stored by the server system 102 and associated with the user via their user data record. The stored transaction data are transformed by the server system 102 in accordance with processing rules to provide accounting services, including the generation of accounting 5 reports, to the user device 104. The webserver machines 110, as shown in Figure 2, include an external web user interface (UI) server 202, an internal web service server 204 and an internal web UI server 206. The external web UI server 202 includes an external web UI component 208 which generates 10 data for sending to the user device 104, including for generation of the GUI, and receives data from the user device 104 in the form of user selections etc. The internal web service server 204 includes an internal web service component 210, which provides web services for communicating with the CRM components 134 and the transaction components 138. The internal web UI server 206 includes an internal web UI component 212 which 15 generates data to provide a web interface to the administrative devices 130 over the closed network 120, provides reporting data to the administrative devices 130, and receives administrator selection data, representing selections and control management decisions of the administrator, from the administrative devices 130, for administration of the server system 102. 20 The application machines 114, as shown in Figure 3, include a main application server 302, a scheduled job server 304 and an analysis server 306. The main application server 302 includes an application server component 308 which defines a plurality of modules, which in turn provide much of the accounting functionality of the accounting system 100, 25 as described further below. The application server component 308 is in communication with the components of the webserver machines 110, the database machines 122, the administrator CRM machines 128, the administrator transaction machines 132 and the other components of the application machines 114. The scheduled job server 304 includes a scheduled job agent component 310 which provides scheduling data which is 30 transformed to effect time-sensitive processes for performance of scheduled operations, such as monthly bill payments, by the accounting system 100. The analysis server 306 C \NRPobl\DCC\MAG\262055 1DOC-14/12/21xr - 12 includes an analysis services component 312 which operates as an on-line analytical processing (OLAP) engine for accessing performance and usage data stored in a server system 102, and for generating analytical reports based on this data, in particular based on administrative selections, for provision of analytical reports to the administrative devices 5 130. The database machines 122, as shown in Figure 4, include a main database server 402 and a reporting database server 406. The main database server 402 provides a main database 404 that receives, stores and makes accessible accounting data of the accounting system 10 100, and in particular the transaction data received from the banks 136 and the user device 104 and stored as "stored transaction data". The reporting database server 406 provides a reporting database 408 which receives, stores and provides access to reporting data, such as system usage data, relating to the operation of the server system 102 for analysis by the analysis server 306. 15 The application server component 308, as shown in Figure 5, includes a plurality of accounting modules 500, including a receiver module 502 with a user input module 504 and a bank input module 506, a rules module 508, a data access module 510, a labelling module 512, a reporting module 514, a processing module 516, and an output module 518. 20 The accounting modules 500 of the application server component 308 operate to provide the main accounting processes of the accounting system 100, described below. Registration Process 25 In a registration process 600 of the accounting system 100, as shown in Figure 6, the server system 102 generates a user data record for a new user by data communication between the user device 104, the server system 102 and the banks 136. In the registration process 600, the server system 102 receives data from the user device 104 and establishes the corresponding user data record which allows the registered user access to the server system 30 102, provides components of the user data record to the banks 136 so that they can generate a bank account with electronic funds transfer (EFT) services, associated with the C:\NRPoibNlDCC\1AG\2V62 5X I DOC- 14/12121)119 - 13 user data record, a merchant code in merchant code data associated with the user data record, a credit/debit card associated with the bank account, and account data relating to the transaction network 140. 5 The registration process 600 commences with the user device 104, under control of user selections, transmitting account request data to the server system 102, and in particular the external web UI server 202, requesting generation of the user data record representing a user account: in accordance with user interface data provided by the external web UI server 202, the user device 104 also sends identifying data to the server system 102 (step 10 602). The identifying data represents a username (which may be a business name), a user contact address, a user contact email address, a user contact telephone number, a user business type (e.g. a partnership, etc.), and the business' annual turnover value. The identifying data relates at least in part to tax treatment under taxation laws such as the size or a tax number of the user business. The user input module 504 of the receiver module 15 502 of the server system 102 receives the user request and the identifying data, and the processing module 516 validates at least some of the values in the identifying data using online data sources accessible by the data access module 510 using the data network 106, such as validating the business name using a business name register such as the Australian Business Register (ABR) of the Australian Federal Government, or validating the business' 20 tax number, such as an Australian Business Number (ABN) (step 604). In the registration process 600, the user may also apply for trial access to the accounting system 100, by sending trial application data to the server system 102, which corresponds to the application data of step 602 (step 606), after which the server system 102 will partially validate the identifying data relating to the trial access, and approve trial access by creating 25 a trial user data record representing a trial user account (step 608), as shown in Figure 6. Following establishment of the user data record in step 604, the output module 518, of server system 102 transmits elements of the user data record and the identifying data to the banks 136, or at least a selected bank, which receives the sent data (step 610) and generates 30 account data relating to banking facilities of the banks 136, including a bank account (step 612), associated merchant facility accounts (e.g. electronic funds transfer (EFT) capability, CNRPonbl\DCC\MAG\2620N5h I DOC-1412/2009 - 14 credit card, BPay, etc) for the transaction network 140 (step 614), a credit card account (step 616), a debit card (step 618), and an electronic channel account (step 622). The form of the bank account is selected based on user selections represented by the account request data. The electronic channel account provides for control of and access to the user's bank 5 account by the server system 102. Following successful generation of data records representing the accounts, the banks 136 generate approval data for the user data record corresponding to the registration application and transmit the approval data to the server system 102 (step 624). The server system 102 receives the approval data and generates identity proof data representing proof-of-identity documentation for the user to complete 10 for establishing reasonable proof of the user's identity, and transmits this data to the user device 104 (step 626). The user device 104 receives the identity proof data from the server system 102 and generates the proof-of-identity documentation, which is printed by the user device 104 for establishing proof of the user's identity, e.g. by physically checking identity documents by the banks 136. Once the proof-of-identity documentation is completed, the 15 user sends data representing the completed proof of identity to the banks 136 (step 628). The banks 136 receive the completed proof of identity data (step 630) and issue, or transmit, the account data (step 632) representing the accounts established in steps 612 to 622, to the server system 102. The server system 102 updates the user data record with the bank accounts data from the banks 136, thereby establishing a fully functional user account 20 for the user (step 634), and transmits confirmation of registration data to the user device 104, which reports to the user (step 636). Following the registration process 600, the user has an associated user data record in the server system 102, which includes user login details, user password details, user contact 25 details and is associated with user bank accounts data of the banks 136, and identifying data. The identifying data is stored in the database machines 122 of the database layer of the server system 102, and at least portions are stored as CRM data in the administrator CRM machines 128, which store user code data associated with a customer account for the user. The user code data, representing the username and user password of the user, is 30 accessed by the data access module 510 and used to establish and maintain secure C RPorbl\DCC\MAG\262UV5, 1.DOC-/142/20M9 - 15 authenticated data transfer for a registered user between the user device 104, the server system 102, and the banks 136. Following the registration process 600, the accounting system 100 receives transaction 5 data relating to transactions associated with the registered user via the user device 104 or via the transaction network 140, stores the transaction data in association with the user data record in the database layer, and reports aspects of the transaction data to the user device 104 based on user selections. 10 Buying Process In a buying process 700, as shown in Figure 7, the user makes a purchase using the server system 102 and the transaction data relating to this purchase is subsequently received by the banks 136 via the transaction network 140, and recorded in association with the user 15 data record in the server system 102. The user device 104 transmits purchase selection data, including a vendor, a purchase method, a purchase time and date, an amount and banking details of the user (including details of the bank account established in step 612), to the server system 102 via the receiver module 502 (step 702). The purchase selection data is also referred to as "direct entry (DE) payment data", because the payment is made 20 directly using the accounting system 100, rather than at a vendor's premises or over the telephone. The server system 102, on receiving the purchase selection data and associated user code data identifying the user, generates purchase request data for the banks 136 using the 25 processing module 516, and sends it to the banks 136 using the output module 518 (step 704). The banks 136 and the transaction network 140 transmit the purchase request data to the bank of the vendor (step 706). The bank of the vendor acquires the purchase request data (step 708) and funds are cleared and transferred to the bank of the vendor (step 710). When the transfer of funds is complete, (i.e. the user's bank account has decreased by the 30 value of the transfer), statement data is generated and passed from the transaction network 140 and the banks 136 to the server system 102 (step 712). The statement data includes C NRPortb1DCC%1AGu62tX5S_1 DOC-14/12/20)9 - 16 transaction data and the bank account balance. The server system 102 receives the statement data via the internal web service server 204, and associates the transactions in the statement data with the user data record using user identifying data, such as the user bank account number, using the processing module 516, and stores the transaction data of 5 the statement data in the main database 404 with the stored transaction data associated with the user data record. The processing module 516 performs a labelling process 900, described below with reference to Figure 9, on the transaction data. 10 The reporting module 514 reports the statement data to the user device 104 together with associated labelling data and other relevant bank accounts data of the user data record (step 716). 15 The direct entry (DE) payments in the buying process include periodic purchases or future purchases, which are initiated by the user device 104 in step 702, for future time period(s). The future time period(s) are recognised by the user input module 504, which receives the purchase selection data, which transmits data to the processing module 516, which establishes a scheduled job subprocess in the scheduled job server 304. The scheduled job 20 server 304 then activates the payment-making step 704 when the time corresponding to the time period(s) in the purchase selection data matches a current time as determined by the scheduled job server 304. Examples of scheduled purchases include periodic bill payments, and funds payments at specific dates in the future, such as paying a monthly internet bill. 25 For non-DE payments, the buying process 700 may include payment steps made by the user not associated with the server system 102. The user may make a payment using their credit card at a merchant rather than making a payment through the server system 102. In this case, the buying process 700 commences with the banks 136 and the transaction 30 network 140 receiving the statement data from the vendor or the vendor bank with transaction data generated by the user and the vendor at the time of purchase. The C:\NRPortbl\DCC\MAG(,262(58i LDOC.14/12/2()9 - 17 alternative buying process may be initiated by the user paying with a credit card (e.g. at a vendor premises) or using electronic means to make a purchase from the vendor (e.g. over the Internet). The transaction in the statement data are associated with the user data record based on the user identifying data associated with one of the accounts established in steps 5 612,614,616 and 618. Selling Process In a selling process 800, as shown in Figure 8, the server system 102 receives invoice data 10 from the user device 104, prepares and transmits data representing an invoice to a customer of the user, receives transaction data representing a payment made by the customer, and matches the invoice data with the transaction data of the payment to associate the payment data with the user data record and the invoice data. 15 The user device 104 generates invoice data representing an invoice prepared by the user, and sends it to the server system 102 (step 802). The invoice data for each invoice is stored-for future reconciliation, auditing and reporting-by the data access module 510 in stored invoices data in the main database 404. The server system 102 receives the invoice data and generates further invoice data for the customer, including a unique 20 invoice code, data representing tax coding for a value added tax or a goods-and-services tax (VAT or GST), facilities for accepting payment cards (such as MasterCard or VISA), bank account details for accepting electronic funds transfer (EFT), BPay account details, associated with at least one of the user's accounts (step 804). The invoice data is transmitted to the customer, e.g. by electronic mail, postal mail, courier, facsimile etc., and 25 the customer makes a corresponding payment (step 806). If the payment is a non-cash payment, the customer's bank generates corresponding payment data once the payment is made, and sends this payment data in the form of transaction data to the transaction network 140 representing a payment made to the banks 136 (steps 808 and 810). The banks 136 receive the transaction data over the transaction network 140 as a clearing bank 30 (step 812), and report this payment to the server system 102, which receives the invoice payment data from the banks 136 using the bank input module 506 (step 814). The server C \NRPonbl\DCC\MAG\2625K- I DOC- 14/12/2(k)) - 18 system 102 matches the invoice payment data with the invoice data based on a unique invoice code using the labelling process 900 (step 816). The reporting module 514 generates commands for the banks 136 to credit the invoiced funds to the user's bank account based on the user's bank accounts data (step 816). The reporting module 514 also 5 reports receipt of the invoice payment data to the user device 104 by generating a statement, including payments made and outstanding payments data (step 820). Labelling Process 10 In the labelling process 900, as shown in Figure 9, the receiver module 502 receives transaction data representing newly recorded transactions, either via the user input module 504, for transactions entered via the user device 104, or via the bank input module 506, for transactions entered using the banks 136 (step 902). The transaction data includes a representation of the type of transaction which may be either "outflow" (for a payment 15 mode) or "inflow" (for monies received). The received transaction data include identifying data relating to the user, which allows the processing module 516 to identify the user data record, which allows the data access module 510 to access the stored transaction data, invoices data and payment request data in the main database 404 associated with the user account. 20 The data access module 510 accesses the invoices data representing outstanding invoices, the DE payment data representing previously selected DE payments, and rules data (step 904). The rules in the rules data represent associations between codes or keywords and labels. The codes include bank codes. The keywords include business keywords, 25 administrator keywords and community keywords. The business keywords are generated or selected by the user, each keyword being associated with a label also selected or generated by the user; the user generates the business keywords based on terms or words found in the transaction text of previous or current transaction data, and the label that the user would like to associate with this keyword. The administrator keywords and 30 associated labels are created by the administrator using the administrative devices 130, and represent terms or words which the administrator expects in the text of the transaction data, C:\NRPonbl\DCC\MIAG\2620858- .DOC- 14/12/21X9 - 19 and labels that the administrator believes should be associated with these keywords. The bank codes include tran codes of the banks 136, described in more detail below and the associated labels are selected by the administrator. The community keywords in a community database are generated by users of the accounting system 100: for example, a 5 word or term that is commonly used by users and is assigned the same or similar label in rules of users stored in the community database where it can be accessed by the data access module 510. The community database is accessed and maintained by the administrative devices 130. 10 The labels data associated with the codes and the keywords in the rules data represent different accounts and tax types. For example, label names include "rent", "car expenses", "insurance", and "label me". The tax type is used in GST liability determination in a Business Activity Statement (BAS) generation process 1100, described below with reference to Figure 11. The tax type may be "GST No", indicating that GST is not payable 15 on transactions with this label (i.e. in this account), "GST Yes" indicating GST is payable, and "GST No - Not Reportable" indicating this payment is not related to the GST accounting for this account. Transactions marked "GST No - Not Reportable" are typically transactions which should not appear on a GST Report, such as personal transaction carried out using the user's business systems (e.g. vehicle fuel for a personal holiday, or 20 personal gifts purchased on a business credit card). The labels data representing predefined labels, including name and tax type, are stored in a main database 404. The codes and administrator keywords and associated labels are sent from the administrative devices 130 to the main database 404 when the administrator 25 selects new codes or administrative keywords and associated labels. The community keywords and associated stored labels are generated in an automatic ongoing basis by the users and the administrator submitting their keywords data, labels data and voting data representing votes for the relevance of particular keywords for particular labels and the associated tax types. 30 C:\NRPonbl\DCCA1AGU620X58 LDOC. 14/12/2()9 - 20 The tran codes are defined and generated by the banks 136. The tran codes are unique sets of two numbers identifying each transaction. An example tran code includes a trans type and a numeric code, e.g. a trans type of "10", "20", and a numeric code of "21", "92", "3". Table I shows an example of tran code labels associated with the tran codes by the 5 administrator. Trans Numeric Description Label Name Type Code 10 21 Pension Personal 10 10 92 Student Allowance Personal 10 3 Salary or Wages Personal 10 72 Health Society Personal 20 132 Housing Loan Repayment Personal 20 65 Child Support Personal 20 432 Pension Personal 10 13 Bond Interest Interest Received 15 10 321 Credit Interest Interest Received 10 28 Dividend Dividend Received 20 231 Account Service Fee Bank Changes 20 23 Chq Fee Bank Changes 20 4 Tran Fee Overseas Bank Changes 20 4 American Express Credit Card 20 17 Diners Club Credit Card 20 333 Interest Charges Interest Paid 20 Ta ble 1 The keywords include terms, words and phrases which appear in the text of the transaction data from the banks 136. For example, credit card transactions over the transaction network 140 include a merchant identifier or name. For example, the keyword "Citylink" 25 is associated with the label "Travel" in the administrator keywords data. Alternatively, the business user, via user device 104, can generate business keywords data that overrules the administrator keywords data, e.g. by associating the keyword "Citylink" with the label "Personal". The keyword may be automatically generated in the buying process 700 or in the selling process 800: when the vendor name or customer name is input from the user 30 device 104, this name can be stored as a keyword.
C:\NRPonbl\DCC\MAG\2620858 I DOC.I 4/12/2lM) -21 In the labelling process 900, the processing module 516 identifies an invoice code, a DE payment, a code or a keyword in the received transaction data (step 906). If a label was preselected in a corresponding buying 700 or selling process 800, and the processing module 516 identifies a DE payment code or an invoice code in step 906 (step 907), the 5 labelling module 512 associates this preselected label with the transaction, and the data access module 510 associates the new transaction label data with the stored transaction data in the main database 404 (step 914). If no payment or invoice code is identified in step 907, the processing module 516 determines whether a code or predefined keyword from the business keywords data, the administrator codes data, the administrator keywords 10 data or the community keywords data is present in the received transaction data (step 908). The keyword identification in step 908 includes a keyword recognition process which determines a match despite spelling mistakes in the keywords data or the transaction data, changes of word location in the transaction data (e.g. "Telstra Bigpond" instead -of "Bigpond Telstra"), and identification of a keyword in text strings (e.g. identification of the 15 word "Bunnings" in the text string "Bunnings Bayswater"). If no code or keyword match is determined in step 908, the processing module 516 determines the type of the transaction based on whether the transaction is an outflow or inflow. The user will manually enter type data indicating whether a transaction is an 20 outflow (money out, or withdrawal on the bank statement) or inflow (money in, or deposit on the bank statement), whilst data received from the banks 136 includes type data indicating if the transaction was an outflow (withdrawal on bank statement) or an inflow (deposit on bank statement). If the processing module 516 determines that the received transaction data represent an outflowing transaction, the labelling module 512 generates 25 transaction label data for the transaction representing the name "Label Me" and the tax type-or GST type-of "GST No" (step 912), and the transaction data, including the generated transaction label data, is stored by the data access module 510 in the main database 404 in step 914. If it is determined in step 910 that the received transaction is an inflowing type, the labelling module 512 generates transaction label data representing the 30 name "Label Me" and the GST type "GST Yes" (step 916) and the data is stored in step 914. The default "Label Me" label is also referred to as a "mandatory label".
C:NRPotbl\DCC\MAG\26705K_ DOC.I4/12/2lN - 22 In the labelling process 900, steps 908, 910, 912 and 916 allow for "conservative" tax accounting by assuming a tax liability by default. Thus, if a tax report (such as a GST report or BAS) is completed with transactions labelled only by default (in steps 910, 912 5 and 916), the accounting system 100 generates the highest tax payable situation for transactions on the GST report: it is assumed that some of the outflows not labelled will be business related and had GST paid. Similarly, not all inflows into the user's business bank account will be revenue in nature and have a GST liability. This conservative approach allows the accounting system 100 to generate tax liability data that by default assumes 10 maximum tax liability. The user can reduce the initial generation of tax liability by manually overruling the default tax type data generated in steps 910, 912 and 916, as described hereinafter. If it is determined in step 908 that the received transaction data represent an identifiable 15 code or keyword, the processing module 516 determines whether the code or keyword is associated with an administrator-created label in the rules data. If the label was generated by the administrator, the processing module 516 determines the type of the transaction, in equivalent step to step 910 described above using first rules with codes, then rules with keywords (step 920). The type of transaction is determined to be an outflow or an inflow, 20 then the labelling module 512 generates transaction label data with the GST type defined in the corresponding rule for the outflow label or the inflow label respectively (steps 922 or 924). The GST type may be "GST Yes", "GST No", or "GST No - Not Reportable". The transaction label data is stored in step 914, as shown in Figure 9. 25 If it is determined in step 918 that the identified label does not relate to an administrator created label, but relates to a business label or community label, the type of transaction is determined based on the rules data (step 926), and the corresponding GST type in the business label or the community label is adopted (steps 928 and 930), and the transaction label data is stored in step 914, as shown in Figure 9. 30 C NRPonbl0CCMAG\2620858 LDOC-/14/22(9 -23 Once the transaction label data is generated and stored, the transaction data and label data for each transaction can be edited in a transaction and label editing process (step 932). In the transaction and label editing process, the user input module 504 receives a transaction record from the user device 104, and the labelling module 512 generates new transaction 5 label data in accordance with the selected new label and updates the corresponding transaction record. By editing the label of a transaction, the tax type can be altered, and a new label name, with a corresponding new tax type, can be selected to replace the default "Label Me" transactions or any existing transaction label. However, certain transaction label data cannot be altered in relation to the transaction data, for example a transaction 10 label associated with the tran code "10, 21", which is pension income in the administrator keywords data cannot have its GST type changed from the default value of "GST No - Not Reportable". Using the community keywords data allows the accounting system 100 to assign a label 15 based on the most popular or common label for the associated keyword in the community. For example, if the accounting system 100 encounters a rule associating a label and a keyword which is not an administrator rule or a user rule, the accounting system 100 will access the community rule database to determine if the community has encountered the rule and what labels have been used. If a matching rule is found, the labelling module 512 20 automatically assigns the most popular matching label. If the user does not have the same or similar label in their user keywords data, the labelling module 512 automatically labels the transaction with the most commonly used community label. The user will have the ability to amend the automatically assigned label, or to accept 25 the community assigned label, in which case the labelling module 512 generates the new label and assign it to the transaction. If the user already has the same rule in their business keywords, the labelling module 512 automatically labels the transaction with the user's label. 30 C:\NRPonbl\DCC\MA\2620X58 IDOC-14/12f20(9 -24 If the user already has a similar label in their business keywords rules, the labelling module 5 12 detects the similar label and then automatically assigns the label of the user to the transaction. The similarity is determined based on matching keywords in a semantic identifier or a word matching system. 5 For an example keyword, or Transaction Text of "NRMA", the community has labelled the transaction with the following labels: Label Occurrences 10 Motor Vehicle expenses 100 Car costs 40 Insurance 35 Car Stuff 10 Table 2 15 The labelling module 512 detects similar labels such as "Motor Vehicle" = "Car Expenses" = "Car Exp"= "Car costs", based rules in the community data. As "Motor Vehicle" has more occurrences than "Car Costs" etc, and is therefore the most common label, "Motor Vehicle" is the label selected. 20 The administrator can accept the rule in the community keyword data and include it in the administrator keyword data. Once a user accepts a rule of a community keyword and an associated transaction label, this becomes a business user rule. When a rule is accepted from the community keyword data, the community database may record a popularity or 25 approval vote associated with that rule, e.g. as shown in Table 2. The GST amount (i.e. in dollars) which is based on the tax type associated with the label and is included in the transaction data, can be edited at any stage by the user. If the user edits the GST amount or GST type in the transaction data of a particular transaction, the 30 labelling module 512 does not update the GST amount or GST type of the label. When the user edits the GST amount and GST type at the transaction data level, these remain CANRPortb\DCC\MAG\262ON58 LDOC.I /12/2(09 -25 unaltered if the user changes the label (which may change the GST type and GST amount). If the user amends GST Type and Amount at a transaction level, the labelling module 512 will not override these amendments. 5 Alerting Process In the alerting (or education alerting) process 1000, as shown in Figure 10, the processing module 516 determines whether the identified code or keyword in the rules data matches e alert keyword data in the e-alerts database of the main database 404 accessed by the data 10 access module 5 10 (step 1002). In step 1002, the e-alert may also be selected based on a transaction amount match (exact amount or range) relating to a transaction value in the received transaction data. If no match is determined in step 1002, the e-alerting process 1000 ends. If a match is determined in step 1002, the processing module 516 determines whether the e-alert data include a data flag field marking the e-alert to be "ignore" or 15 "used", representing that the e-alert is not relevant or has already been seen by the user (step 1004). Each e-alert data record in the e-alerts database contains educational information for the user of the accounting system 100, as generated by the administrator. The e-alert information typically relates to relevant tax information, for example whether a transaction typically relating to a particular keyword is GST free. Once the e-alert has 20 been displayed by the user device 104, the user may mark it "used", indicating it is not to be displayed again. Furthermore, certain e-alerts may not be relevant in certain jurisdictions, e.g. on a State-by-State basis, and thus are marked "ignore" for a user device 104 in a particular jurisdiction by the server system 102. If it is determined in step 1004 that the e-alert is not marked "ignore" or "used", the reporting module 514, via the external 25 web UI component 218, generates display data for the user device 104 to display the information data of the e-alert (step 1006). In the display information data step 1006, the information data may include a hyperlink to a website with further information about the topic identified by the keyword match and or the keyword match and transaction value match of step 1002. The information data of the e-alert may appear in the form of a pop 30 up box on the computer screen of the user device 104. The user device 104 may optionally receive user input, which is transmitted to the processing module 516 to change the status C-\NRPonb\DCCM1AG\262085XI DOC-14/12/20)9 -26 of the e-alert to, for example "used", or "ignore" via the data access module 510 (step 1008). An e-alert can contain an informative message and may also amend the GST amount or 5 GST type of a transaction. Some e-alerts are displayed once, after which the server system 102 changes the status to "used". Example Keyword(s) Example Information Data Sensis Advise user to include GST in first payment. 10 Advise that future payments should be recorded as GST Free. Telstra, Vodafone, Please check your taxation invoice to ensure AAPT, Optus Mobile the correct GST is recorded. 15 Vic Roads, RTA, Dept 1. Provide a message to the user advising that of Planning & this transaction typically does not attract the Infrastructure, full GST credit. Please check your taxation RegoACT invoice to ensure the correct GST is being recorded. 2. The system 102 amends the GST credit from the full amount to the correct amount. 20 Allianz, NIB, QPR Please check your taxation invoice to ensure Ltd, Comminsure the correct GST is recorded. 25 Table 3 Example transaction values for activating e-alerts include an amount range (e.g. $500 $550) or a specific amount (e.g. $55.34). The e-alerting process 1000 reduces errors which may occur when assigning GST status to a transaction. 30 C NRPorbhDCC\MAG\2620958_ DOC/-/12/2009 - 27 Business Activity Statement (BAS) Generation Process The BAS generation process 1100 generates data for a BAS report. Providing a BAS is a regulatory requirement on Australian businesses, required by the Australian Tax Office. 5 Each business registered for GST is required to supply the Australian Tax Office with data representing the GST collected when making sales, known as "IA GST On Sales", and the GST paid when making purchases, known as "lB GST On Purchases". The Australian Tax Office also requires that the BAS include data representing: (i) the total value of sales (which may or may not have GST) made by the 10 business during the tax reporting period (i.e. the quarter), referred to as "GI Total Sales"; (ii) the value of sales made outside Australia, known as "G2 Export Sales"; (iii) the value of sales made that do not attract GST, known as "G3 Other GST Free Sales"; 15 (iv) the value of outgoing expenditure generally relating to capital purchases, where capital items are defined in taxation law, known as "G10 Capital Purchases"; and (v) the value of outgoing expenditures generally relating to revenue, or non capital purchases, known as "G II Non-Capital Purchases". 20 The BAS generation process 1100 generates the above-mentioned data relating to inflow or sales values, outflow or purchase values, and related tax liabilities and assets. The BAS generation process 1100 commences, as shown in Figure 11, when the receiver module 502 of the application server component 308 receives BAS generation request data and tax 25 reporting period data representing a corresponding BAS period (the tax reporting period) which may be in the form of dates including start and end dates (step 1102). The BAS generation request data is sent from the user device 104 by a user. After the receiver module 502 receives the BAS generation request data in step 1102, the data access module 510 retrieves stored transaction data from the main database representing all transactions 30 that are not marked "used" in used flag data associated with the stored transaction data (step 1104) within the prescribed period start and end dates. The newly entered transaction CANRPortblDCC\AG\26208581 .DOC. 14/12/20W9 - 28 data from the user device 104 or the banks 136 does not have a "used" flag in the "used" flag data. A transaction record has its "used" flag removed if the transaction record is edited after it has been stored in the main database 404: for example, a user using the user device 104 may change the date represented in the transaction date data of the transaction 5 record, or may change the amount represented in the transaction value data, which will cause the labelling module 512 to remove the "used" flag in the "used" flag data of the transaction record. In the BAS generation process 1100, the processing module 516 receives transaction data 10 representing the non-"used" transactions, and determines whether the dates in the corresponding transaction date data are within a prior BAS period, i.e. should have already been reported in a previous tax report (step 1106). For each transaction determined to be from a prior BAS period in step 1106, the processing module 516 performs an adjustment monitoring process 1200 to determine whether the prior-period transaction is reportable in 15 the present BAS (step 1108). The processing module 516 then determines, for each reportable transaction in the non-"used" transaction data, whether the transaction is an inflow transaction or an outflow transaction based on the type data (step 11 12). For inflow transactions, the application server component 308 performs an inflow BAS data generation process 1300 to determine data for the reporting fields of the BAS relating to 20 inflow or sales transactions (step 1114). For outflow transactions, determined in step 1112, the application server component 308 performs an outflow BAS data generation process 1400 to determine data for the reporting fields of the BAS relating to outflow, capital or non-capital transactions for the reporting fields of the current BAS. Following generation of the inflow and outflow BAS data in steps 1114 and 1116, the reporting 25 module 514 generates BAS report data representing the present / current BAS and sends this data to the user device 104 via the external web UI component 208 to generate a BAS report display for the user (step 1118). The processing module 516, after the reportable transactions have been determined in steps 1106 and 1108, marks all reported transactions as "used" by updating the "used" flag field in the transaction record of the main database 30 404 using the data access module 510 (step 1120).
C:\NRPobl\DCC\MAG26205 1DOC-14/12/2t09 - 29 Adjustment Monitoring Process In the adjustment monitoring process 1200, the accounting system 100 provides a method of reconciling, auditing and alerting the user to the taxation impact, and in particular GST, 5 of transactions made prior to the current taxation reporting period, but not reported in the correct prior taxation report. Prior period transactions are identified by the transaction date data in the transaction record for the stored transaction, and through use of the "used" flag field in the transaction record. Newly stored transactions, and amended transactions, have the "used" flag removed. An example of amending the transaction record is a user 10 changing the GST type of a transaction from "GST Yes" to "GST No", or changing the amount of the GST. If a transaction is deleted, the transaction record is retained in the main database 404, the transaction value in the transaction value data is set to zero and the "used" flag is cleared in the "used" flag data. Taxation law allows certain transactions with dates outside the current taxation report period to be reported in the current reporting 15 statement, whereas other transactions, identified for example by a transaction value limit, must be reported separately, for example through lodging an amended taxation liability statement with the appropriate authorities (e.g. an amended BAS). The adjustment monitoring process 1200 commences, as shown in Figure 12, with the 20 rules module 508 accessing rules data representing taxation rules in the main database 404 (step 1202). These taxation rules include taxation law and guidelines of the Australian Taxation Office, for example that prior period transactions can be reported in the current BAS if the total GST credit (GST amount) value of these transactions is below a $5,000 limit set for micro or small businesses. Further example taxation or tax rules from the 25 Australian Taxation Office are shown in Table 4. 30 C:NRPortb\DCCMAG2620S5X DO-C-14/12/Zov -30 Annual Turnover of the Time Limits to Report Correction Limits Business (business size) on a BAS (value limits) Less than $20million Up to 18 months Less than $5,000 (18 mthly, 6 Qtrly, I pa 5 GST return) $20mill to less than Up to 3 months Less than $10,000 $100mill I00mill to less than Up to 3 months Less than $25,000 $500mill $500mill to less than billl Up to 3 months Less than $50,000 Over $1 bill Up to 3 months Less than $300,000 10 Table 4 In the adjustment monitoring process 1200, the processing module 516 determines which of the prior period transactions, determined in step 1106 of the BAS generation process 1100, are reportable, based on the tax rules (step 1204) and the identifying data of the user 15 data record, such as annual turnover or business size. The reportable transactions are returned to the BAS generation process 1100 (step 1206). For any non-reportable prior period transactions, as determined in step 1204, a reporting module 514 generates prior period transaction alert data to alert the user that the non-reportable prior period transactions need to be reported to the Australian Tax Office using an amended prior BAS, 20 prepared by a registered accountant (step 1208). The non-reportable prior period transaction alert data is transmitted by the reporting module 5 14 to the user device 104 via the external web UI component 208. Inflow BAS Data Generation Process 25 The inflow BAS data generation process 1300 commences, as shown in Figure 13, with the processing module 516 determining whether the inflow transaction has a GST type of "GST No - Not Reportable" (step 1302), in which case the transaction value is included in the "Not Reported" field of the GST report data by adding the value of this transaction to 30 the other transactions in this field (step 1304). If the inflow transaction does not have a GST type of "GST No - Not Reportable", as determined in step 1302, the transaction value C\NRPortbflDCCMAG\2620X5N I DOC- 14/12/21)9 -31 is included by the processing module 516 in the "G Total Sales" field of the GST report data by adding the GST-exclusive value of the transaction to the "GI Total Sales" field (step 1306). For the inflow transactions with the GST type not equal to "GST No - Not Reportable" as determined in step 1302, the processing module 516 determines whether 5 the GST type is "GST Yes" (step 1308), and if so includes the tax liability of this transaction in the "1A GST On Sales" field of the GST report data (step 1310). The tax liability is determined by a tax rate in the main database 404 provided by the administrator. If the GST type is determined to be "GST No" (i.e. not "GST Yes") in step 1308, the processing module 516 includes the transaction amount in the "G3 Other GST Free Sales" 10 field of the GST report data (step 1312). In the inflow BAS data generation process 1300, the data access module 510 determines whether a "G2 %" percentage value is available in previous BAS data (step 1313). The "G2 %" percentage value represents the percentage of total sales which were export sales 15 during the BAS period. If so, the data access module 510 accesses the percentage value of the "G2 %" field from the GST report data of the previous BAS (step 1314). If no "G2 %" percentage value is available in the previous BAS data, the user input module 504 receives a "G2 %" value from the user device 104 (steps 1320 and 1322). The processing module 516 generates a value for the "G2 Export Sales" field in the GST report data based on the 20 "G2 %" value from step 1314 or step 1322 and the "G Total Sales" field from step 1306, based on the following relationship (step 1316): "G2 Export Sales" = "G1 Total Sales" x "G2 %". If no "G2 %" percentage value is present in the GST report data of the prior period BAS 25 determined in step 1320, the user may use the user device 104 to enter the exact amount to be recorded in the "G2 Export Sales" field in the GST report data (step 1324). The "G2 Export Sales" Value for the transaction is included in the "G2 Export Sales" data for the present/current BAS based on the value from either step 1316 or step 1324. 30 C \NRPonbl\DCC\MAG\262UK58i DOC-14/12/2009 - 32 Outflow BAS Data Generation Process The outflow BAS data generation process 1400, as shown in Figure 14, commences with the processing module 516 determining whether the outflow transaction has a GST type 5 equal to "GST No - Not Reportable", in a step equivalent to the inflow transaction determination step 1302 (step 1402). If the transaction has a GST type of "GST No - Not Reportable" the processing module 516 includes the transaction in the "Not Reported" field of the GST report data (step 1404). If the outflow transaction has a GST type of "GST Yes" or "GST No", as determined in step 1402, the data access module 510 accesses G10 10 Limit Data in the main database 404 which represents a limit on the value of transactions which are determined to be capital purchases, the limit being selected by the administrator of the accounting system 100. For example, the G10 limit may be $1,000 or preferably $3,000 (step 1406). The processing module 516 determines whether the value of the transaction (GST inclusive) of the outflow transaction is less than the G10 Limit (step 15 1408), and if so includes the value of the transaction in the "Gi I Non-Capital Purchase" field of the GST report data (step 1410). If the outflow transaction amount exceeds the G10 Limit, as determined in step 1408, the processing module 516 includes the transaction value in the "G10 Capital Purchase" field of the GST report data (step 1412). 20 In the outflow BAS data generation process 1400, the processing module 516 determines whether the GST type of the outflow transaction is "GST Yes", and if so includes the tax credit in the "lB GST On Purchases" field of the GST report data (step 1414). The user, using the user device 104, may submit data to the user input module 504 to effect 25 a manual override of classification of the outflow transaction into the "G10 Capital Purchase" field or the "Gi I Non-Capital Purchase" field, causing the processing module 516 to reassign the transaction in the outflow BAS data generation process 1400 (step 1416). The server system 102 requests data from the user asking if the purchase is a business purchase or an equipment purchase. 30 CNRPonbl\DCC\MAG\262085X-I.DOC.14/12/20N)9 - 33 Application Pages In a graphical user interface (GUI) process, the external web UI component 208 generates display data for displaying a business user interface on the user device 104. The business 5 user interface includes a plurality of web pages, including application pages 1500, as shown in Figure 15, which display data on the user device 104 and receive input data from the user device 104 for receipt by the user input module 504. The application pages 1500 include pre-registering pages 1502, which are provided to the user device 104 if the user has not logged in or registered (i.e. no user code data has been received associated with the 10 user data record), and post-registering pages 1504, which are sent to the user device 104 when the user has registered and logged in. The pre-registering pages 1502 include: (i) a landing page 1506 which displays general information about the 15 accounting system 100 and is configured to accept user code data allowing a user to log in; (ii) a view demo page 1508 which displays a demonstration, including a demonstration video, of use of the account system 100; (iii) an application page 1510 for the server system 102 to display and receive 20 data during the registration process 600; and (iv) a contact us page 1512 for displaying contact information for the administrator and submitting feedback data to the administrative devices 130 via the server system 102. 25 As shown in Figure 15, the post-registering pages 1504 include: (i) a business home page 1514, such as a dashboard display 1600, as shown in Figure 16, for a logged-in user displaying a list of tasks to do, a bank account summary, a recent events summary, and an overdue invoices summary; 30 (ii) a business profile page 1516 for editing the business profile represented in the identifying data and the user data record; C WRPonblq)CC\MAG\2U205_I DOC-14112/2xy - 34 (iii) a manager user permissions page 1518 for managing the user's permissions and changing the passwords represented in the user code data; (iv) a usage report page 1520 for displaying the user's past usage of the accounting system; 5 (v) an auto-labelled and auto-matched page 1522 for displaying the number of received transactions and their matches to pre-existing invoices and labels, in the labelling process 900; (vi) a transactions list page 1524 for displaying a list of transactions represented by the separate transaction records in the stored transactions 10 data, listed by date (represented by the transaction date data), name (represented by the transaction name data), label (represented by the transaction label data), and if matched to a label, the label GST or value (represented by the transaction value data), and listed either as outgoing or incoming, for example as a transaction list display 1700 as shown in 15 Figure 17; (vii) an enter-cash transaction page 1524 for receiving input data relating to creating new cash transactions; (viii) a match transaction-to-invoice page 1528 for receiving user input allowing a transaction record to be manually matched to an invoice or manually 20 unmatched/removed; (ix) a bank statements page 1530 for viewing bank statements of transactions received from the banks 136 and relating to specific bank accounts or credit card accounts.; (x) a manage labels page 1532 for creating, editing, grouping and ungrouping 25 labels, for example the label list display 1900, as shown in Figure 19; (xi) a create/edit label group page 1534 for creating and/or editing label groups; (xii) a create/edit label display page 1536 for creating and/or editing labels; (xiii) an invoices list page 1538 for viewing a list of invoices represented by the 30 stored invoices data, including a display of the invoice date data and assigned invoice number data, customer contact data, invoice amount data, C:\NRPnbf\DCC\MAG\262UN5H-1 DOC-14/12/2009 - 35 amount owing data, due date data, data paid data and current status data, for example as the invoice list display 2000, as shown in Figure 20; (xiv) a create/edit invoice page 1540 for creating, editing and deleting invoices, updating the stored invoice data (by marking the status as paid, unpaid, 5 bad debt, etc.), including generating and editing recurring invoice data representing recurring invoices, for example as an invoice creator display 2100, as shown in Figure 21, including fields for accepting contact data for a customer, item code data, description data, tax type data, quantity data, price data and label data; 10 (xv) a change invoice payment terms page 1542 for changing the payment terms of an invoice; (xvi) a view invoice page 1544 for displaying an invoice, for example as an invoice display 2200, as shown in Figure 22, with a "mark as paid" control, a "mark as bad debt" control, a "delete" control, an "edit" control, 15 a "send/resend" control and a "print" control; (xvii) a print invoice page 1548 for printing a hard copy of an invoice or a digital document in a portable document format (PDF); (xviii) an items list page 1550, where an item is a good or service which the user sells and the item data includes the item name, item value which will be 20 included in the GST and the GST type, (e.g. the item may be a cup with a sale value of $2.25 with a GST type "Yes"); (xix) a create/edit item page 1552 for creating and/or editing the item data; (xx) a payments/transfers list page 1554 for displaying a list of payments relating to the purchase request data, including scheduled payments of the 25 scheduled job agent component 310 (such as DE payments); (xxi) a make payment page 1556 for entering payment request data using the server system 102 in the buying process 700; (xxii) a view payment page 1558 for viewing payment request data, including the direct entry (DE) payment data; 30 (xxiii) a transfer money page 1560 for making payments using an interbank transfer from the banks 136 in the buying process 700; C \NRPonbMl\CC\MAG\262)85 IDOC.14/12/2(X)9 -36 (xxiv) a contacts list page 1562 for viewing a list of contacts, including contact data relating to customers and vendors, for searching contacts, editing contacts, and viewing contacts, for example as a contact display 2300, as shown in Figure 23, with a list of names and display details of one of the 5 contacts; (xxv) a create/edit contact page 1564 for creating and/or editing contacts data; (xxvi) a view contact history page 1566 for viewing stored transaction data associated with a selected contact in the transaction records data; (xxvii) a create/edit contact-from-elsewhere page 1568 for importing contacts 10 data from alternative applications, such as email application databases; (xxviii) a reports list page 1570 for displaying a list of generated reports, or reports that can be generated; (xxix) a BAS report page 1572, for displaying tax report data, e.g. as a BAS summary display 2400, as shown in Figure 24, including summary data 15 relating to the values of G I Total Sales, G3 Other GST-Free Sales, G 11 Total Purchases, I A GST On Sales, I B GST On Purchases and a GST refund amount; and for displaying detailed data relating to the values of "GI Total Sales", "G3 Other GST-Free Sales", "G 11 Total Purchases", "IA GST On Sales", "lB GST On Purchases", a GST refund amount and 20 "GST No - Not Reportable", e.g. as a BAS details display 2500, as shown in Figure 25, including a list of transactions for the associated tax reporting period; (xxx) a business performance report page 1574 for receiving user input data and generating corresponding business performance/income, expense and 25 cashflow reports; (xxxi) an invoicing report page 1576 for displaying an invoicing report; (xxxii) a payments report page 1578 for displaying a payments report; (xxxiii) an item listing report page 1580 for displaying an item listing ; (xxxiv) a contact listing report page 1582 for displaying data representing details 30 held in the main database 404 corresponding to a contact; C:NRPonblDCC\MAG\6211X5_ DOC-14/12/21XN -37 (xxxv) a print report page 1584 for generating a hard copy or PDF document for one of the above-mentioned reports; (xxxvi) a community forums page 1584 for viewing community forums of the accounting system 100; 5 (xxxvii) a forum page 1588 for displaying information about a forum in the community forums; (xxxviii)a thread page 1590 for displaying a particular thread of a forum; and (xxxix) a post page 1592 for receiving user input from the user device 104 to generate post data to add to one of the threads. 10 Server Hardware and Software The webserver machines 110 and application server machines 114 are configured in load balanced clusters using a "bare-metal hypervisor" such as VMware's "ESX", that partitions 15 multiple physical server machines into multiple virtual machines, where each virtual machine represents a complete system with processes, memory, networking, storage and bios. The hypervisor enables the virtual machines to share physical resources, balance a load of intensive high priority processing, provide security functions, manage power usage, etc. 20 The database machines 122 are configured as a cluster of machines connected by the production switch 126, including a number of structured query language (SQL) server machines. 25 Each of the webserver machines 110, application server machines 114, and database machines 122 are in the form of a server machine 2600, such as an 32-bit or 64-bit Intel Architecture-based server system. As shown in Figure 26, the components and modules of the server machine 2600 are implemented in the form of programming instructions of one or more software modules 2602 stored on non-volatile (e.g., hard disk) storage 2604 30 associated with the server machine 2600.
C:\NRPonbl\DCC\MAG\262 5K I DOC-4 I 2/20X)9 -38 The software modules 2602 are generated based on computer code using Microsoft's ".NET" framework. The boundaries between the modules and components in the software modules 2602 are 5 exemplary and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Alternative embodiments may combine multiple instances of a particular module or submodule. The operations may be combined or the 10 functionality of the operations may be distributed in additional operations in accordance with the invention; alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a 15 gate array or full-custom application-specific integrated circuit (ASIC), or the like. The processes provided by the server machine 2600 may be embodied in a machine readable and/or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and/or transmitted to a computer 20 system memory to configure the computer system to perform the functions of the module. The server system 2600 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via I/O devices. A computer process 25 typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of 30 the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.
C \NRPortbI\DCCMiAG\2K2N5H 1.DOC-1412/2009 - 39 The server machine 2600 includes computer components such as random access memory (RAM) 2606, at least one processor 2608, and external interfaces 2610, 2612, 2614, all interconnected by a bus 2616. The external interfaces include a network interface 5 connector (NIC) 2612 which connects the server machine 2600 to a communications network 2620 such as the Internet. The server machine 2600 is configured to communicate with the other webserver machines 110, application server machines 114 and database machines 122 using data 10 communication protocols, including the Transmission Control Protocol (TCP) of the Internet Protocol Suite, the Hypertext Transfer Protocol (I-ITTP), HTTP over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection (also known as HTTPS) and the Reliable User Datagram Protocol (RDP) for management by the administrator. 15 The server machine 2600 includes a number of software modules 2626 to 2630, including an operating system 2624 such as UNIX, Linux or Microsoft Windows, webserver software 2626 from Apache (available at http://www.apache.org), scripting language support 2628 from PHP (available at http://www.php.net) or Microsoft ASP, and 20 structured query language (SQL) support 2630 such as MySQL (available from http://www.mysql.com), which allows data to be stored in and retrieved from an SQL database 2632. Together, the webserver 2626, scripting language 2628, and SQL modules 2630 provide 25 the server machine 2600 with the general ability to allow other computing devices on the network 2620 to access the server machine 2600 and in particular to provide data to and receive data from the database 2632. 30 CANRPob\DCC\1AG\2620NS_ I.DOC-14/12/200P) - 40 User Device Hardware and Software The user device 104 is a computer system 2700 such as a 32-bit or 64-bit Intel Architecture-based computer system, and the processes executed by the user device 104 5 are implemented in the form of programming instructions of one or more software modules 2702 stored on non-volatile (e.g., hard disk) storage 2704 associated with the computer system 2700, as shown in Figure 27. Alternatively, at least parts of the software modules 2702 could be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays 10 (FPGAs). The computer system 2700 includes computer components, such as random access memory (RAM) 2706, at least one processor 2708, and external interfaces 2710, 2712, 2714, all interconnected by a bus 2716. The external interfaces include universal serial bus 15 (USB) interfaces 2710, at least one of which is connected to a keyboard and a pointing device such as a mouse 2718, a network interface connector (NIC) 2712 which connects the system 300 to a communications network such as the Internet 2720, and a display adapter 2714, which is connected to a display device such as an LCD panel display 2722. 20 The system 2700 also includes a number of standard software modules 2726 to 2730, including an operating system 2724 such as Linux or Microsoft Windows XP, and browser software programs, such as Mozilla's "Firefox" or Microsoft's "Internet Explorer". Many modifications will be apparent to those skilled in the art without departing from the 25 scope of the present invention as herein described. The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived 30 from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.