Comment by Izkata
1 year ago
Entry1: Account A: receives 1000 from Account B
Entry2: Account B: sends 1000 to Account A
And from GP:
> A consequence of that is you can check that the sum of all accounts is always 0.
Entry1 + Entry2 = 1000 + -1000 = 0
Amusingly, when I made my own personal money tracking program over a decade ago for my bank accounts, this was how I implemented transfers between them just because it was simpler to do. Years later when I heard this name, I also had trouble understanding it because I assumed I had done it the bad way and banks did somehow did something more in-depth.
So basically it's not really the transfer that's the base of the system, but the account? Ie each account gets its own entry, and because there are two parties in each transaction, we naturally get two entries?
There are not "parties" in an DE transaction.
The legal entity or entities involved - if any - would be described in the linked commercial document that explains the transaction, and the chart of accounts that describes the meaning of each account code.
There is no requirement for a transaction to have exactly two entries. The term "double-entry" is slightly misleading; it is only trying to express that both sides of the accounting equation are equal. When recording a sale, for example, it is more likely that three or more entries are journaled, due to the additional coded entries for sales tax, and those produced for separate line items for each SKU, shipping etc.
A better phrase is "two-sided accounting", which is also used, but less commonly than "double-entry".
I see, and would that transaction get four entries (two for the money, two for the tax), or three (two for the money, one for the tax)?
1 reply →
Our prof repeated always (literally translated to EN):
"For every debit there must be a credit"
or
"Every transaction has two sides"
1 reply →
I may have the terminology a bit off, but the core table in my implementation represents transactions. The columns are Account, Description, Type, Value, Date. Type is to distinguish transfers between my accounts and actually adding/spending money. SUM(Value) on just the transfers between my accounts adds to 0 just like the example above. SUM(Value) on everything tells me how much money I have across all my accounts.
What you have done is record credit and debit entries in the same column, distinguishing credits and debits by sign. This is a design choice in the data structure for DE systems. It's a tossup whether that's better than either of the alternatives.
In the case of moving money between regular bank accounts in the same institution, you regard that as a movement between two asset accounts, whilst the bank regards that as a movement between two liability accounts.
So their entries would have the same magnitude as yours, but inverted signs.
> It's a tossup whether that's better than either of the alternatives.
Which means you aren't even thinking of the "bad" single-entry version, which is what a lot of people here are stumbling over because apparently it's more natural: A "transfers" table with the columns FromAccount, ToAccount, Amount, were a single row represents both the "Entry" rows from mine above.