<story><title>Accounting for developers part III – building a lending marketplace</title><url>https://www.moderntreasury.com/journal/accounting-for-developers-part-iii</url></story><parent_chain><item><author>skipants</author><text>I still don&amp;#x27;t understand why they encourage double-entry accounting for tech. In my experience entries like:&lt;p&gt;| amount | payer_id | payee_id |&lt;p&gt;|  100   |    1     |    2     |&lt;p&gt;are more than sufficient. He uses Square, Uber, and Airbnb as examples in &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.moderntreasury.com&amp;#x2F;journal&amp;#x2F;accounting-for-developers-part-i&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.moderntreasury.com&amp;#x2F;journal&amp;#x2F;accounting-for-develo...&lt;/a&gt; but, as far as I can tell, only Square uses double-entry.&lt;p&gt;Double entry accounting was for when people were hand-writing a ledger and it helped avoid mistakes. It makes no sense in code and it just makes your DB queries more complicated.</text></item></parent_chain><comment><author>zie</author><text>What happens if you need to split that $100 from payer_id 1 into 2 payer_id 2&amp;#x27;s?&lt;p&gt;I.e. that $100 is actually:&lt;p&gt;$99 from 1 to 2 and $1(let&amp;#x27;s say in taxes) to payer_id 3.&lt;p&gt;The easy answer is, make it 2 transaction, $99 to 2 and $1 to 3, but then you can&amp;#x27;t tell that the $1 in taxes is from the $99 transaction.  That leads to headaches when you need to balance your taxes.</text></comment>
<story><title>Accounting for developers part III – building a lending marketplace</title><url>https://www.moderntreasury.com/journal/accounting-for-developers-part-iii</url></story><parent_chain><item><author>skipants</author><text>I still don&amp;#x27;t understand why they encourage double-entry accounting for tech. In my experience entries like:&lt;p&gt;| amount | payer_id | payee_id |&lt;p&gt;|  100   |    1     |    2     |&lt;p&gt;are more than sufficient. He uses Square, Uber, and Airbnb as examples in &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.moderntreasury.com&amp;#x2F;journal&amp;#x2F;accounting-for-developers-part-i&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.moderntreasury.com&amp;#x2F;journal&amp;#x2F;accounting-for-develo...&lt;/a&gt; but, as far as I can tell, only Square uses double-entry.&lt;p&gt;Double entry accounting was for when people were hand-writing a ledger and it helped avoid mistakes. It makes no sense in code and it just makes your DB queries more complicated.</text></item></parent_chain><comment><author>WorldMaker</author><text>One good technical reason to prefer double entry and relating to the &amp;quot;it helped avoid mistakes [in hand-writing ledgers]&amp;quot; is that double entry patterns encourage better database transaction discipline and provide helpful debugging clues when database transactions half-finish and accidentally commit rather than rollback. Atomic database transactions with single row inserts of accounting transactions are &lt;i&gt;obviously&lt;/i&gt; simpler to build, but it also means you are less likely to test multi-row database transactions such as scenarios where you need to make sure an accounting transaction lands in an atomic commit with say a purchasing invoice row. Double entry accounting, especially when different types of accounts may be in different tables forces your codebase to use good database transactions and sometimes more thorough testing of your commit versus rollback code paths.&lt;p&gt;Also, in my experience double-entry tables are often much easier to DB query because the tables &amp;quot;naturally&amp;quot; look exactly like the ledgers accountants expect to see in reports. The math in aggregate queries is often just SUM and nothing else, no complicated case logic for &amp;quot;different transaction types&amp;quot; or complicated pivots from transactions to account views and back.</text></comment>