|
|
|
|
|
by jsmith45
1406 days ago
|
|
My understanding was that historically double entry accounting very much had each entry stored separately (although tied together by some transaction identifier). You would normally add both at the same time, so one could consider it "one record" on that basis, but physically they were separate entries often in separate physical books. In computerized systems, having a single record in one place, and virtually constructing the ledgers from it is feasible. Under the constraints that all transactions debit from just one ledger, and credit to just one ledger, storing each transaction as tuple (id, amount, debited ledger, credited ledger) is feasible. Double entry does have the slight advantage of being possible to generalize to allow one transaction to debit from multiple ledgers or credit to multiple ledgers, as long as all the debited amounts sum to the same as all the credited amounts. It has a disadvantage in that the storage format does not guarantee validity, unlike the tuple method. |
|
Today, the "posting" can usually be done by a computer. There is some human creativity/regulation involved in deciding which specific accounts to credit/debit, but this can be noted in the "daybook entry" (more likely a database record somewhere than something literally written in a book) instead of being put off until the posting step.
The important characteristic is what the grandparent noted, that each transaction (in the daybook) tracks completely where each cent (or florin) came from and where it went. If a system of bookkeeping has this characteristic, I think it can be called double-entry, at least in spirit. A hard requirement that a transaction occur between exactly two accounts makes some kinds of events difficult (or impossible) to model, but is still conceptually the same.