3 ms·
A double-entry system is one where you can't change the balance of an account, you can only record transfers between accounts. This means it's impossible to for
by remram 2y ago
A double-entry system is one where you can't change the balance of an account, you can only record transfers between accounts. This means it's impossible to forget to update the other side of a transaction, it's a single step. A consequence of that is you can check that the sum of all accounts is always 0.
In practice you have virtual accounts like "cloud expenses" and "customer subscription" that only go up/down over time, to be the counter-party for transactions in/out of your company. So it's not impossible to mess up, but it eliminates a class of mistakes.
- stavros 2y agoHm, but what's the second entry? Do you not just add a single entry from X to Y?
- Izkata 2y agoEntry1: 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.
- stavros 2y agoSo 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?
- Izkata 2y agoI 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.
- inopinatus 2y agoThere 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".
- stavros 2y agoI 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)?
- inopinatus 2y agoNeither of those cases precisely. The vendor's transaction record for such a sale would include a debit to cash, a credit to revenue, and a credit to sales tax liability. The total amount of the credits would equal the cash debit.
- ta12653421 2y agoOur prof repeated always (literally translated to EN): "For every debit there must be a credit" or "Every transaction has two sides"
- inopinatus 2y agoThat’s more than a little reductive but I imagine your professor was hoping that at least the motivating concepts of two-sided accounting would seep in.
- inopinatus 2y agoWhat 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.
- Izkata 2y ago> 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.
- deleted 2y ago[deleted]
- remram 2y agoThe change to X and the change to Y are the two entries. In practice most systems allow for more than two entries in a single transaction (ex: take from bank account, give to salary, give to taxes) but always at least two, and always adding up to 0.