Appendix 1: Accounting Model

The following outlines how the trial balance can be produced from our 31 rows of Resource Accounting Model data.

Notice that two different types of rows, Transfers and Events, are shown in column C: To calculate the income statement we use only the events. To calculate Salary Revenue on our income statement for example, we scan column F looking for the Salary Revenue Account, 411. When we locate a matching row, we multiple the amount in column H by -1. Doing this for each income statement account will produce the same number shown on the Sample Trial Balance figure for April 30th.

Calculating the April 30th balance sheet amount is a bit more complicated because both the Event and Transfer rows must be taken into account, so we have to scan columns D and F. Each time we match a Balance Sheet account in column D, we simply accumulate the amount. If we match on column F, we must multiply the amount by -1 because we are taking the amount “From” this account. Doing this will again produce all the Balance Sheet amounts shown in the Figure 8 for April 30th.

Suppose we now move into May, and add new rows to those above. We noted earlier that using the journal entries as a way of calculating the financial statements meant we didn’t necessarily need to record closing entries. Is that still true of this new system? Can I calculate the trial balances as of May 1st? Yes, it is possible, but the formulas or processes become a bit more complex.

It requires evaluating the date column as well. The Income Statement by definition has a “from” and a “to” date, the period covered by the Income Statement. As we evaluate each row in performing the same calculations above, we check if the date on the row is greater than the first date, and less than or equal to the end date. If it is, we include it. If not, we skip it.

Again, calculating the Balance Sheet is similar except the Balance Sheet is as of a particular date, so we only have one date we use in our test. Again, we perform the same calculations as above, but only for rows prior to or equal to the balance sheet date are included.

The Net Worth account on the Balance Sheet requires additional work. Net Worth reflects the impact of the income statement on the Balance Sheet. To calculate Net Worth we not only follow the same procedure for the Balance Sheet that we have just described, but we also do the same thing for the Income Statement accounts. Whenever we see a Salary Revenue record prior to or equal to our Balance Sheet date, we add that amount to the Net Worth line as well. Thus the Net Worth account reflects the accumulated effect of all Income Sheet accounts over time.

Note that this simple system does not have the balancing control built into it that the double-entry system provides. If the amounts on the rows I have proposed are summed, they equal 108,899.60 which equals the sum of the corresponding rows from the double-entry system, proving that no recording errors have been made in creating my example. If the Events alone are summed, they equal Net Income as calculated under the double-entry approach; again showing no recording error in the entries I have made. If the Transfer events are summed, they equal 110,790.29. This is composed of the total offsets of 108,899.60 plus net income of 1,890.69. Because the balance sheet is a point in time statement (rather than showing activity over time like the Income Statement) these offsets have a net effect of zero upon the balance sheet. The following shows the detail:

FnUnrecordedRows

All this analysis was performed to prove that the system is in balance. In a double-entry system, the sum of all the journal entries is zero. Thus my system does not have this one type of internal check built into it. Again note that this check within a double-entry system does not ensure that completeness or accuracy of the entries, just that no rows have been dropped or amounts transposed. A different reconciliation mechanism would need to be constructed to provide a similar assurance for my proposed system. If that reconciliation method required recording all these additional entries, there would be no reduction in number of entries needed in my system.