Hm, but what's the second entry? Do you not just add a single entry from X to Y?

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)?

Neither 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.

Our prof repeated always (literally translated to EN):

"For every debit there must be a credit"

or

"Every transaction has two sides"

That’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.

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.

The 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.