Accounting Primer
First.....Prev.....Next.....Last
There are two major sections to this topic. If you have a good understanding of accounting or find the primer is telling you how to "suck eggs" skip down to the Transaction and Accounts section. The first section should give users with minimal accounting background an appreciation of "double-entry bookkeeping" as it pertains to this trust account. It is not a strict accountant's view of things and I may even tell some lies for the purpose of simplicity.
If you are trying to come to grips with accounting I suggest you print this accounting primer topic then work through them on paper, preferably without distraction if you can, working the examples as you go yourself. You may find printing the Account Matrix in the main Transactions topic topic useful too.
The term "double-entry" means that there are two sides to every transaction where money changes hands, namely where the money came from and where it went to. Both sides of every transaction must record the same amount of money. The recording of these entries is done by grouping like transactions into "accounts" or "ledgers" which usually have meaningful names like Landlord ledger, Management Fee account and so on.
The terms account or ledger are more or less interchangeable and are like the word "sheep", in that just a single account/ledger, or a group of like accounts/ledgers, or all the accounts/ledgers in the system may be called a "general ledger" or "the accounts" or "the books". If anything ledger leans a little more towards including the detailed transactions.
Now to double entry. Consider your own situation when you receive wages. Within the banking system money is taken out of your employer's account, one side, and put into your account, the second side of the transaction.
When you write a cheque to pay the phone bill, money is taken out of your account and put into your telephone supplier's account. During the time the cheque is in the post, being handled by the supplier's accounts department and then banked, you still have the money in your account. You can't pay another bill with it, or spend it, because it is earmarked as belonging to your supplier. Until the banking system finally takes it out of your account the payment is termed as being "unpresented". When your bank balance is reduced by the amount being paid the cheque is termed "presented".
The two examples above are simple transactions with one item on each side of the transaction. You can also have transactions which have two or more items on either or both sides. These are sometimes termed "multi-legged" transactions.
Again back to your situation. You decide to take the family to the local A and P Show or Disneyland equivalent. You know the only acceptable currency there is cash so you hit the ATM and withdraw $200 and put it in your wallet. During the day you note what you spend on the entry fee, sideshows, candy floss, food and drink. If you then did a "book" on your expenditure you could show the accounts something like this :-
The key point here is that the transactions on both sides are equal. If you only spent $170 you would have a $30 balance left which is equal to the difference between the two sides. Restated, any difference between the money flowing into, and out of, an account is the balance held in that account.
Relating the above to a landlord. He receives $200 in rent from a tenant, some fees and GST are deducted, money is spent on repairs, water rates, insurance etc totalling $170 which are deducted too, leaving a balance of $30 at the end of the month. This is what we would send off to him as a payment which is also deducted from his account which then has a zero balance.
As you can see the landlord's account has transactions on one side (In) that equate to the total on the other side (Out).
Now, as far as our records go his trust account balance is zero but the "real" (BNZ) bank trust account still shows the money in the bank until the cheque is presented. This is an important concept for later when you reconcile the trust account, because until the cheque is presented we must make adjustments to take unpresented items into account.
Summary of Key Points 1
.....1. Double-entry requires two records for each transaction.
.....2. Each side of the record may have a different number of items - multi-legged.
.....3. Each side of the record must total the same amount of money
.....4. The difference between the money flowing into and out of an account is the balance held.
.....5. "Unpresented" is the term applied to what appears to be "loose" money floating around caused by delays in receipts and payments affecting the real bank account.
Now, you may say items 3 and 4 in the Summary of Key Points above are contradictory based on what I've said earlier and to some extent you're right. But it's because I've only told you half the story. For the accounting to be complete we have to record all the steps in the loop and each step must be a two sided double-entry record.
Using our landlord example above let's complete the loop. We will ignore any processing delays, assume everything happens on one day, we only have one landlord and start with no money in the bank.
On the physical side of things, the tenant pays us $200 rent, we race across the road and deposit it immediately. We get those bills to pay, we hand the cheques to the suppliers who also cash them instantly.
Now for the record keeping. But first two important concepts.
Concept 1
From V3.17.0.0 where "Tenant Held" is introduced, this concept (as described in the struck-out text below) does not apply and the tenants accounts can hold money which makes up part of the system bank account balance. Within a tenant account rent, debt, letting fee and bond pass through to other accounts. While the tenant has no vacate date rent, debt and letting fee may be overpaid, but bond cannot be overpaid, see XXXX . Any rent, debt or letting fee overpaid as a result of the vacate date being entered is transferred to Tenant Held. Any new receipts will "pay off" rent, debt, letting fee or bond amount still unpaid and transfer any remainder to Tenant Held.
Although the tenant is the prime source of money, within the record keeping, there is no account which holds any of the tenant's money, ever. The reason being that the tenant is paying for "services rendered". He is buying time in the property from the landlord, he is repaying the landlord for expenses the landlord's account has paid on his behalf (e.g. water rates), he is paying you a letting fee, he is lodging money with the bond authority through your trust account and the bond centre shows this money in their account. We certainly record that the tenant pays the money but deposit it directly into the correct system account, landlord, M/Fees, L/Fees GST or Bond. We simultaneously record the amount of time the rent paid purchases and the amount of debt repaid.
Concept 2
For an accounting system to be complete all the accounts in the entire system are added together and the "Ins and Out" must be equal. Rather than add all the individual "ins" and "outs" the normal way of checking is to use the balances in each account. Thus the balance in system bank account should be equal to the total of the balances in the other accounts.
(end of Concepts)
The system bank account is our record of what should be happening in our account at the real bank across the road. They of course don't see all the little bits that go to make up our deposits etc. which we have to record. In a perfect, no delays world, the balance in our system bank will equal that in the real bank. In these remaining simple examples we are only looking at the two "sides" of each double entry transaction.
When we receive the tenant's rent, the entries are :-
The system immediately collects our management fee and the GST payable. Because of our double entry rules we just can't just whip it out of the landlord's account we have to put it somewhere too, so it goes into the management and GST control accounts. The landlord balance get reduced and the control account balances increased.
At this point Concept 2 applies. We have the rent money in the system bank, {200} equalling the sum of the balances held in the landlord's {182}, M/Fees {16} and GST {2} accounts.
Note none of these last three entries have any effect on the system bank account because all we are doing is redistributing the rent received around other accounts from the landlord's account.
When the bills come in we have to take the money from the landlord's account and give it to the supplier. We have three bills to pay for repairs, water rates and insurance each of which is paid by cheque and entered as a simple transaction. Important. The Aspect Property Manager (and the real world) does not handle them this way, this is for simplicity of presentation.
What ?? This is where Concept 2 kicks in again. Think about it. We have to pay the repairman with some money from the landlord's account (Side 1). When the supplier cashes the cheque it reduces the amount of money in the real bank which our system bank is supposed to "mirror". So we must reduce our system bank by the amount of the cheque too (Side2).
We repeat the exercise for the water rates and insurance.
Now the system bank contains the original rent money {200} less the three cheques {54 + 26 + 72 = 152} we have issued and what is left is equal to the sum of the balances left in the landlord's account {30} plus the M/Fees {16} and GST {2} accounts.
If we now popped across the road to the bank asked for our balance, (because the original rules said the suppliers cheques were cashed by the bank instantly), we should find it containing the same value, that is the sum of the landlord, M/Fees and GST account balances {30 + 16 + 2 = 48}.
If we now issued the landlord a cheque for his balance {30} we would reduce both his account and the system bank account by the same amount leaving just the M/Fees {16} and GST {2} accounts containing balances and the system bank {18} being the sum of those two.
If our landlord put the cheque in his pocket and forgot about it for a week or two when we compared our system bank balance {18} with the balance in the "real" bank {48} we would find a difference equal to that unpresented cheque {30}. When reconciling the system bank balance to the "real" bank account balance we must take this {30} into account. Reconciliation is a subject on its own and may be found here.
Summary of Key Points 2
.....1. Although the tenant provides the physical money coming into the system it all "belongs" to someone else, the landlord to buy some rental time or repay debt, you in the form of management and letting fees, the tax man as GST, the bond centre as money being held in trust against damage etc.
.....2. A single transaction usually affects a number of accounts.
.....3. The system bank account records the flow of money into and out of the system BUT NOT movement of money between accounts within the system. Basically to effect the system bank we must be recording either the receipt or payment of money which will cause our real bank account balance to increase or decrease.
.....4. The system bank account mirrors, but in more detail, what should be happening in the real bank account.
.....5. Comparing the system bank account balance to the real bank balance is termed reconciliation and must take into account any unpresented items, both payments we have made which have not been banked and cash and cheque receipts we have entered into the Aspect Property Manager but have not yet banked.
The Curve Ball
Up to this point, and with accounting systems in general, I have been saying that the value in the system bank must equal the value in the sum of the balances in the other accounts. This means looking at the system bank's value of 12,345.67 then adding up a number of other accounts and seeing they are the same, that is they all add to 12,345.67.
For reasons that date back to when the first manual double-entry system was devised, it was determined that if an account existed in which deposits into the bank were entered as negative values (and withdrawals as positive values), then by adding all the account balances, including the system bank, if the result is zero the system is in balance. That is instead of saying, if 12,345.67 equals 12,345.67 the system is in balance; we can say if, negative12,345.67 plus (positive)12,345.67 = 0 the system is in balance.
Harking back to our earlier rent entry and forgetting fees etc but applying this "new" idea we have:-
This means if we add the balances in both accounts they will add to zero, which means the system is in balance.
You may think it is stupid but it is not going to change, so just accept that a negative value in the system bank is good news a positive value is bad. The simplest way to cope with this is to (generally) ignore the sign on the bank account and realise that if you receive money the number will get bigger, if you pay a landlord or supplier etc the number will decrease.
Transactions and Accounts
Now to the real stuff. In this section we examine each type of transaction which can occur in the Aspect Property Manager and the accounts they affect.
In the first table below a simple tenant rent receipt is traced through just the accounts affected by the transaction, the landlord is paid and the fees and GST transferred to your trading account. The table format used and comments should enable you to see the whole process and related maths relatively easily.
Following the first table every type of transaction in the system is traced through the accounts and for consistency all the system accounts are shown whether they are used or not. To keep the help width within the bounds of an A4 page for printing a different layout has been used and the first table is repeated in the new format.
Refer to the Account Matrix in the main Transactions topic which shows these same transactions and accounts in a matrix and is a "terse" version of this "verbose" version.
In the following scenarios all accounts are shown on the left. No entry means the account is not used. Remember that there is never a monetary balance in the tenant's account, only a record of what has passed through the account which is shown as rent paid to purchase a rent period, debt repayment, letting fees and bond receipts.
In the following scenarios all accounts are shown on the left. No entry means the account is not used. In these examples the tenant Held Amount has not been used. There is only a record of what has passed through the account on its way another account such as rent paid, or debt being paid by for water usage, or the letting fees and bond paid.
The values in the examples are based on Fees of 8% and GST at 12.5%.
That covers all the transactions you will find in the system and the double entries which each of them generates. In all cases you only have to enter "one side" of the transaction and the system does the other side for you. The last three, Bond Transfer, Tenant Debt and Rent Inv are "single sided notations" and do not require double entry because they do not move money into, out of, or between the system's accounts.
Reversals follow exactly the same procedures, the only difference being the sign is reversed. A rent reversal takes money out of the landlord's, management fee and GST accounts with a negative value and out of the bank with a positive value.
When you are trying to figure out what goes where with a transaction, start on the basis of having zero balances in all the accounts. Sketch up something like the first table in this topic containing only those accounts affected. Each account requires two columns one "In" and one "Out".
Every entry you make must have two sides which have equal and opposite values. One side of the transaction will normally be only in one account but the other side most often has "bits" in several accounts. Those "bits" must add to the same number as the first side and be in the opposite column.
Remember the Tenant's account never gets involved. It is merely a "pass-through" account, although the tenant's indebtedness or Paid To date may be altered by the transaction. See Concept 1 above.
For the more technically minded if you adopt a spreadsheet approach each "transaction row" should add across to zero, any difference in the addition of the column pairs is the balance in each account, and the balances should add to zero too.
If you have access to someone with good accounting knowledge talk to them too.