I’ve read that the development of double entry book keeping was very important, enabling less error in accounting, then driving significant gains in commerce. But reading this didn’t explain exactly why. Is it just the simple sum rule that ensured errors in transcription would (usually) quickly be caught? I’d guess automated accounting services today would be less prone to such errors — does that mean double entry is no longer as important as it once was?
In addition to error checking, the process of double-entry bookkeeping also provides a way to get different views into the state of a business: balance sheets, P&L statements, transaction histories, and so on. A lot of the mechanics of doing it manually—journals, ledgers, day books, trial balances, etc.—are less important now that computers can slice-and-dice at the push of a button, but the fundamental idea of a business transaction as a set of balanced money movements between different accounts is still a useful way to structure financial data.
(“Double entry” is also something of a misnomer; it’s really “N-entry” accounting, where all N entries that make up a transaction have to balance out to make sure you know where the money came from and where it went to. It’s just that for simple transactions the minimum number of entries that makes sense is 2.)
It depends on what you count as a "transaction". Some of my real transactions get recorded as multiple "virtual" transactions on the books, to make sure the money has visited all the relevant places for later summary purposes.
Example: I buy something with my salary. Two real transactions. However, on the books it goes in as income, it is moved to the household income, it goes into the cash reserve, then moves through the appropriate budget category before the actual expenditure is recorded as it happens.
Yes, but in practice split transactions are common, where you will have 1 credit and 2 debit entries in a transaction. For example, if you work from home and pay rent out of one account, the you may want to claim back tax on the office portion of your rent:
1. Credit $1000 Cash account,
2. Debit $600 Personal Rent account and
3. Debit £400 Office Rent account, considered a tax-deductible Expense account.
Sum of credits = Sum of debits, but now you can account for different tax treatments.
That’s two credit entries in the cash account: one for 600$ and one for 400$.
The fact that you have an equal amounts of entries in debit and credit accounts is literally the point of double entry bookkeeping. If you could use consolidated entry, it would be a nightmare to cross check when you are looking for errors. If you were using a ledger rather than a piece of software, it would be so much more obvious.
I disagree with this. This might be fair and technically correct on paper, but we don't use paper anymore. Transactions with more than two line items are by far the most common method of recording transactions. In fact, I'd probably go so far as to say that the method you suggest isn't used at all in practice, especially since most transactions need some sort of recording of sales tax.
In the example of $1000 paid in rent, the technically correct method is actually worse for usability. If $1000 left the bank account and two transactions totalling $1000 were recording, how can you match the ledger to the bank account? Or if there are bank charges paid on a transaction (Paid $1000 with $5 in bank charges).
> If $1000 left the bank account and two transactions totalling $1000 were recording, how can you match the ledger to the bank account?
The ledger already matches the bank account. You have 1000$ leaving it in two lines. Charges will likely be accounted separately anyway if they exist.
You probably mean the bank statement. If that’s the case, the answer is you do what is called reconciliation and sum the accounting entries. Reconciliation will be more complicated anyway because you will have entries in your accounting for a month which might be on a different bank statement entirely due to outstanding checks and deposits and bank processing delays.
I'm aware of how reconciliation works. I'm actually an accountant by trade. $1000 is a trivial transaction of course, but reconciliation becomes challenging when its thousands of transactions per month of differing amounts. If anything, transactions not matching the bank statement is a good way of increasing your audit fees as the auditor struggles to make sense of what your accounting system has recorded.
> I disagree with this. This might be fair and technically correct on paper, but we don't use paper anymore.
here's a simple case you may have encountered yourself: you order a shopping cart of a fair amount of stuff (not even that much) from Amazon, and click purchase. Later you're wondering about an Amazon charge on your credit card so you look in your emails from Amazon and you log into your account on Amazon, and you can't match the charges on your card with any of your shopping transactions with Amazon, the numbers bear no resemblance to one another. Amazon is not bookkeeping in a way that's at all useful to you. Since you are the consumer of the data, they're not fulfilling their accounting obligation which is clear presentation of the record.
I have no doubt that their calculations are correct, but just as computers can free us from the burden of adding up numbers correctly, computers can also do other tasks we find burdensome, like double entry bookkeeping. When as a programmer I used to resist writing code that seemed inelegant, my old boss used to remind me that the computer was the drudge, a mere servant to the whims of the various humans using it. If Amazon wants to rejigger your shopping carts with respect to backorders and shipping, they could easily do it in a way that allowed you to reconcile your statements simply.
This is indeed the right answer. I sometimes try to use simpler accounting mechanics than double entry (usually because the person I'm doing it for requests it) but it doesn't take long until I want to run a query against the data that becomes complicated under simpler systems but just falls out of the data under double entry.
Yes! I was both tech lead and EM on a multi billion dollar double entry accounting system for years. It was completely unnecessary and overall a drag to keep the double entry system. You end up inventing a ton of random accounting procedure to account for the “other side” of transactions that just don’t need another side. You invent accounts that do nothing and mean nothing just for scorekeeping. If you trust computers to do basic arithmetic and if you trust ACID databases, double entry accounting is outdated and unnecessary.
I'm not an accounting expert by any means but I've been around long enough to see far too many examples of single entry accounting systems that have gone completely off the rails and nobody knows why because meaningful data (i.e. "$M moved from X to Y on date Z by process P") is not captured and difficult or impossible to recreate.
Sure, computers can do basic math and ACID usually works out but that doesn't account for human-level errors. Subtle things like getting an idempotence check wrong can lead to cascading errors that are really hard to see and fix when you just have one view into the numbers.
Double entry forces you to account for both sides of the transaction. Where did the money for groceries come from? Checking account. What the hell is this $200k spend? Office equipment. That money from Bob, was that a gift (income) or a loan (liability)?
So why not model exactly those account transfers? Because it's not always that simple. How do you translate this?
You could say Checking -> Gift Card -> Coffee, or Checking -> {Gift Card, Coffee}. Does it actually matter? Probably not, so that's a pointless choice leading to false precision. If you did need to specify which one it was you'd put them in separate transactions (and you'd probably structure the actual spends from the assets accordingly).
Maybe contra accounts are an outdated concept. Ok, don't use them and directly reduce the balance of the account. You also don't need a separate account for every little thing, we certainly had misc accounts in every day of books I've seen. But you at least have to be able to say whether something is income, expense, asset, liability.
for the readers, contra accounts keep track of expected adjustments, particularly "opposites", So when you sell items you also expect a percentage to be returned later by dissatisfied customers. If you book all sales revenues as they occur, that will show an "untrue" number, so you book expected returns into a contra account so you can see what your actual revenues are expected to be. Then later when you have accurate information on returns you use those values to unwind the expected values you put in.
Accounting is all about providing accurate information to various "stakeholders" who might be looking at the books.
None of this is mutually exclusive to a single entry system. Tracking where money is coming and going can be done any number of ways that is not double entry bookkeeping.
These are also examples of cash basis accounting which is much simpler. When you get into accrual basis and revenue recognition especially is where the double entry stuff (IMO) just starts to break down. Meaningless accounts get invented just for the sake of having something to balance against, and your entries are no longer tied to actual money changing hands.
I would argue that, categorically, tracking the balances of external entities isn't useful or meaningful, at least for personal finance. (I don't know enough about business finance to form an opinion.)
I'm considering "external entities" here to mean accounts that aren't yours. A bank account or a credit card or a mortgage are yours, in the sense that it matters to you in some way what their balances are. Most expenses (by number of transactions, maybe not by total amount) are not that.
To offer a concrete example, I pay my ISP about $80 per month for an internet connection. Double entry accounting would have me move money into an "account" representing my ISP, so I can answer the question of how much money I've paid them over the whole time I've used them. That isn't a question I have ever needed to ask, nor do I expect to, but if I do, it would be answerable with a single query over a single-entry transaction list. Until then, the extra effort spent on double-entry accounting would be entirely wasted.
edit: I missed the context that the person you replied to was working on a very business-sounding accounting thing. I'll leave this here in case it inspires more relevant examples.
Double entry accounting doesn't require you to track expenses related to your ISP. All it requires is an expense account. Whether you decide to open sub-accounts in order to track some expenses specifically, it's entirely up to you.
This way you can see your expenses on an “expenses” account regardless of where they came from. No need to scan for multiple sources, because they all end up on a single account. This is a beauty of accounting, you define not how, but what. You bought a tv?
debit: My stuff / tv
credit: Bank / account
sum: $1000
Your tv broke?
debit: Expenses / Breakage
credit: My stuff / tv
sum: <a remaining cost of
tv, depending on
amortization scheme>
With single entry you either cannot do that, or have to scan all tables and invent a special field that represents type of an operation, in this case isExpense or shard tables by that criterion.
This requires you to know up front which expenses you want to track, though. If you don't, and you change your mind later, you get to do that table scan anyway, so you may as well actually record the metadata that makes it possible.
edit: I read what you're describing here as a single entry system if you just read "expense account" as "expense type"; double entry would be if you physically recorded each of those in two places. It's entirely possible we're arguing about semantics.
I don't care how much I'm spending at a particular restaurant[1], but I do care about how much I'm spending on food I cook myself vs eating out/ordering in so I've got Expenses:Groceries and Expenses:Eating Out. And sometimes batteries make it into my grocery bill because I was there and you know what, it's really not an issue for me.
You get to keep track of what matters to you and what doesn't, you can dump into Expenses:Misc
[1] others would, and so would have separate accounts for specific restaurants
> That isn't a question I have ever needed to ask, nor do I expect to, but if I do, it would be answerable with a single query over a single-entry transaction list.
How would you pick out just the transactions that were to your ISP? Unless you want to manually review the transaction log, you need something consistent you can refer to in your query: like an account name (or a transaction description, but that feels easier to accidentally be inconsistent with).
Technically you could bunch up all payments to service providers under a "services" account, or just a "household expenses" account, or even a general "money gone" account.
However, I have often found that when I do that, inevitably someone asks, "so how much of our expenditures this year were for the internet connection?" and then it would have been really useful to have that ISP account.
Double entry accounting as a representation is a domain specific language for the people working in the field and as such is very useful.
However, you might ask, is it also the right primitives to express accounting IT systems or could we think of a better domain model, and then derive the double entry ledgers from that?
This is an important and profound question.
If you would like to dive in, I suggest looking at the REA (resources, events, agents) model, a set of abstractions and patterns for expressing accounting in business systems.
The Model-Driven Design Using Business Patterns book by Hruby et al. is a great starting point. [1][2]
Also, the POETS (Process-Oriented Event-driven Transaction System) research from DIKU (Copenhagen University) is super interesting, offering some ideas for next-generation ERP systems.[3]
[3]
Fritz Henglein, Ken Friis Larsen, Jakob Grue Simonsen, Christian Stefansen. POETS: Process-Oriented Event-driven Transaction System. Journal of Logic and Algebraic Programming (JLAP), Invited submission to special Issue on Contract-Oriented Software, 78(5):381-401, 2009.
Jesper Andersen, Ebbe Elsborg, Fritz Henglein, Jakob Grue Simonsen, Christian Stefansen. Compositional specification of commercial contracts. International Journal on Software Tools for Technology Transfer (STTT), 8(6):485-516, November 2006.
There are more papers from DIKU on this, see e.g. prof. Henglein’s publication list :
I don't understand why a 'tech lead' would have to invent an accounting procedure. Accounting procedures are the responsibility of accountants, not of engineers who lack basic training in accounting.
It also rings strange to me. Either this project had an accounting clusterfuck, or a company outsourced this to gp team which has not developed an intuition for how to make those loose ends tight.
I'm a CPA and I recommend my extremely small businesses clients use a single entry excel system. If they use debit for everything they can download the bank transactions in csv. Then use a deep downlist to categorize the transactions. Then a pivot table to display the year end or quarterly income statement. I usually send them the Excel with the pivot table and dropdown list.
Ahhhh, right, my best-loved “we are drowning and have no idea why, can you look at our 40 xls and few html tables” type of client.
Excel and single-entry in general allows one to ignore questions about their financial structure, make decisions that lead to massive analytic information losses and bury a relatively good business in a deep grave of multiple “idk” levels of knowledge. They only become aware of it when it stops scaling (but competition does, for some reason) or a market goes down for a while (but competition doesn’t care, for some reason). Digging them out is a hard and tearful task.
the problem with being a larger entity is there may be legal requirements around your accounting system.
In many EU countries, if your turnover (total amount of money flowing through your business) is over a certain amount, or if you are incorporated (rather than sole proprietor) you have a legal requirement for double-entry accounting, and in some places a legal requirement to have an external firm do your accounting.
Yes, but once you are using Power BI you have lost the friendly interface the op described for categorising transactions, ie it is not a simple spreadseet any more.
Can you be more specific? I'v been working with accounting systems for some time also and there are no transactions in double entry accounting which "just don't need the other side".
You could also have a db view that returns a virtual double entry version, as a test that it passes muster with that. This checks for programmatic errors causing money to appear or disappear.
"does that mean double entry is no longer as important as it once was?"
What are the alternatives? Sure, you could do single entry accounting (making an entry corresponding to each cash movement, but then you'd need a separate system to keep track of
- money the business owes
- money the business is owed
- inventory
- other assets
I don't know much of the history, but I can say:
- I've found it helpful to compare to look at the income statement alongside the opening and closing balance sheets. I've even found errors this way.
- AFAIK all business accounting systems are based on double-entry accounting, so the existence of these systems can't obviate the need for double-entry accounting.
If you have a cash business where you hold almost no inventory, e.g. if you're a baker who buys flour at the beginning of each day, and close your shop when you've sold out of bread, you might not care about tracking assets, accounts payable etc.
Even in an SME I would also need a system for accruals and prepayments as well.
Simple example
I need to know my profit this month. I have added up my cashbook for the month and it contains an entry for 3 months of rent in advance for my office. It is September and that is the rent for October, November, December. How do I get it out of my profit calculation for September and split into the correct months? This is important, my bonus is based on profit. My bank loan covenants are based on profit. My equity split with my investors is too, as is my tax payable. In double entry I would move this into my prepayments account and move it back in 3 tranches.
REA accounting is one of the alternatives [1]. It is used in some managerial accounting systems. I would imagine you could make it generate a set of double entry records to make regulating authorities for financial accounting happy, but you'd have to extend it a bit to add the unnecessary properties.
That is not really what the accounting standards are for. The people that need to be kept happy are the users of the accounts. The standards are there to stop me misleading, or defrauding them.
Here is a list of some users of my accounts:
Managers: need to know how their business unit is performing so they can take action
Shareholders: need to know how the directors are managing their money
Banks: I borrow money from them, and they want to see that I can pay it back
Tax authorities: I collect sales tax for them. I collect payroll taxes for them. I have to pay taxes on my profit
Creditors: I need suppliers to advance me credit. They need to work out the risk of giving it to me.
Employees: before I joined the company I wanted to know it was solvent
Imagine how I could manipulate them if there wasn't a standard way of communicating the accounts.
I think the biggest and also least attributable benefit of it was it enabled the Venicians of Venice (iirc?) to create money, outside of what hard currency allowed at a time and with it opened the world of financing.
By create money I mean the same way your bank today creates money anytime it finds a willing and credit worthy borrower.
Double entry book keeping basically invented the concept of ledger money which is pretty much the “money” we use today. It enabled elasticity of the money supply where elasticity was lacking.
The importance is in the "accountability" of accounting. By forcing each entry to cross accounts, you make each account reconcilable with the others. "Books" are no longer independent because they can be cross-checked. Where books are departments that makes departments responsible for justifying each entry in a way that is visible across accounts, to the cent. It's a validation layer. With double entry you can't cook just one book, you have to cook all the books.
I have a remote shop that takes cash and credit card payments. If i just ran a cash book like some on here are suggesting how would I know my sales for a day? I could wait until the money hits my bank account and categorise it, but then how much of that money is sales tax not sales? How much did the goods they sold cost me? Did they put all of the cash in the bank or did they steal some. Did the credit card merchant pay me everything due?
Imagine the customers have credit terms with you? Now when do you know your sales, when they pay? What if they don't pay?
Double entry has answers to all of those questions.
This is what is sold in theory. Practice is wildly different. Reconciling across departments looks absolutely nothing like what you’ve described and does not go to the cent or even close. As long as in you’re in the ballpark of reconciling and can reasonably explain the sql queries and reports that got you to a number within an okay range of error you’re good to go.
This is absolutely not my experience at all. Books that don’t balance to the cent suggest a problem that needs to be resolved.
Electronic books that don’t balance to the cent are defective.
I’ve certainly seen lax accounting and reconciliation practices in businesses such as those you describe but it’s absolutely not been the norm in my experience.
Individual books, yes (though I am still very dubious of the value in doing this given the guarantees that modern computers/databases offer). I'm talking specifically about cross-department reconciliation where different departments are keeping their own books and have their own data pipelines/etc. They absolutely still have to be reconciled, but there is no expectation of an exact match from the SEC or internal/external auditors.
I agree, mostly. You have to understand the implications of a few cents' difference. One cent (or even one dollar) could be the effect of rounding. Or it could be a single typo. Or it could be multiple errors involving larger transactions with opposite signs.
you get different amounts of money coming in at different times (investors, loans, revenue from sales) and you have different amounts of money flowing out at different times (paying workers, paying for supplies, equipment...)
double entry bookkeeping not only "checksums" these quantities for errors, but also gives you different snapshots of your business, how much money do you owe in the short term, how much in the long term, on average what's the profit margin, how much tax do you owe this year.
other people can also look at your accounts and check up on random sample pieces of information to ensure it's not all made up.
It creates a clear picture where the raw data is somewhat murky, which enhances trust on many levels.
I think there is more to it than meets the eye perhaps.
It is the way to understand human activity as a set of transfers beween accounts. All the money must go somewhere, perhaps spent perhaps saved in a different currency. All these different types of transactions including startup of the business that occur within can all be modeled with the "simple" concept of 2-entry system. It is a general way to track human co-operation numerically.
The kind of errors that double-entry accounting prevents aren't just arithmetic errors, but also conceptual errors. Double-entry accounting ensures that the accounting identity, which states that Assets = Liabilities + Equity, is true at all times, and it does that by requiring that all individual transactions are balanced.
It allowed people to be quantified with a single number, 'he owes X amount of dollars', 'he has X amount of dollars'.
During the dark ages, and early middle ages, people didn't have much money. Instead there were complex relationships based on obligations 'loans', IOUs, real estate transactions to hide usury, dozens of different currencies with different exchange rates. Determining wealth was a complex affair.
On a completely different tangent, Leonardo da Vinci probably illustrated the first book about double entry book keeping. He was interested in math and knew the author, most likely traded his artistic skills for math lessons.
In terms of error detection, one of the principal tools in double entry is the Trial Balance. A trial balance lists all of your accounts in your ledger, with debits and credits in opposing columns, sums them all, and the two columns totals should match. If they do then all entries are at least complete. If they don't then you have lost records along the way. By correctly assigning debit or credit normal to each account type you ensure there is always a credit for every debit and vice versa.
I wrote a simple double entry bookkeeping program for myself, and I wanted to use as accurate terminology as possible. My native language is Swedish, and we have a word for the task of categorizing statements into accounts. Basically, when you look at a recipt and tell "this is for inventory, then I will use account X." In the past, you then wrote that down with a pen in a kind of inverted-T table that you had stamped on the receipt.
The Swedish word for that activity is "kontera", loosely translated to "accounting". But in English that is the word for the entire activity of keeping books up to date. Is there a word for the specialized task of identifying the accounts?
Edit: Wikipedia has articles for this word in Swedish, Danish and German. But no other languages. Puzzling.
it's not wrong, but kontera is the very specific act of assigning a transaction to the proper account, with none of the general meaning of classify. Kontera sort of implies the act and transaction, the "commit".
Yes, I probably explained it a little too simplistic. Describing it as the commit is quite accurate I think. In my program I came up with the verb "book" for this, as book a transaction, but I have no idea if it is correct in the English-speaking world.
Doible entry system is useful and reliable when you mainatain system for large business. If you have 100s of vendors and need to track balance between these vendors, then double entry system helps you to keep your account in check. The basic rule of having sum of different amounts in a transaction should be zero is simple and powerful in resolving conflicts.
It's also useful in the smallest of businesses. It allows for a more mature thinking about your finances and how to leverage them beyond cash=profit. It's very difficult to scale beyond a micro entity with single entry bookkeeping, for example you cannot produce a balance sheet with single entry.
Double entry accounting is useful any time you have limited amounts of a resource and want insight into how it is used. You don't need to apply it as strictly as accountants do -- very general categories and a random sample of transactions is fine for most types of analysis.
The important part is that every unit of resource comes from somewhere and goes to somewhere. As long as you fulfill that property, you get powerful querying capabilities.
Most recently I've used it to compare various means of acquiring more RAM for an operation (cloud offerings, incremental purchase, leasing large amounts, etc). One of the other benefits is that I can mix both "terabytes of memory" and "thousands of euros" in the same book, and exchange rates between the two also fall out of the equations.
I want to love the plain text accounting tools. I used them for over a year on all my finances. They’re incredibly expressive and exact, and they play well with vim and git.
The trouble is ingesting transactions. You do your best—save receipts, try to note things in your phone. Then some auto-pay thing blindsides you. Or, that separate tip charge from Uber Eats. Yes, you can capture all of these things, but it will require hours of weekly time investment to counteract financial entropy.
I ended up just buying Banktivity. I do miss the perfection offered by plain text accounting. I miss nothing now because they’ve contracted with teams that write scrapers and API clients for banks I would have otherwise had to write myself. Reconciliation is now the work of minutes. It’s not perfect, but everything is a tradeoff.
I find there's a balance to be struck between convenience and granularity. If I insisted on categorising every transaction into very specific categories it would be far too much of a pain for me. So, for example, I have a big expense account called "Eating and Drinking Out". Ideally it would be great if I knew specifically what I was spending on coffee, on lunch, on beer, etc, but it would just be too much work. Likewise, I don't track my cash - I just have an expense account called "Cash Withdrawals" (unless I am withdrawing a large amount of money for a specific purpose, which I usually remember so am able to allocate it to a more specific account).
In the normal course I try to update my GnuCash once a week, which takes about half an hour on a Sunday. However I've been quite bad lately and today I'll be trying to input over a month of transactions which I'm not looking forward to...
In addition to this, I've started sampling days. Instead of recording transactions for every day, I can do something like every fifth day. This reduces precision, but it's still within a range acceptable for my purposes.
(Though it's important that it's either a systematic sample (every n days) or a random one (throw a dice each day, if it's 5 or higher, record that day). The days you pick have to be uncorrelated with the types of expenses those days, or your results will be biased.)
I feel this pain every time I go to reconcile transactions for the week/month. At the same time, I'm not ready to trade the exposure I get to every penny of my income/expenses that manually typing entries gives me. It's just not the same as reviewing a ledger - the act of typing, reviewing, and reconciling has really boosted my confidence in how I currently manage my finances.
I used ledger for 2019–2020 and by the end of it I had scripts to pull just about everything automatically, whether via OFX, Plaid, CSV, or PDF. It became a drag when I realized that I’m starting a new job, I’m opening new accounts, &c., and all my tooling would have to be constantly changing.
Now two years later I’m porting my details into Beancount (the tool whose documentation is linked), and I’ve changed my approach to one that seems much more sustainable: once a month, download statements and enter them in with some templates to assist. Maybe I use a CSV parser for credit cards and other high-frequency accounts, but for what I want out of plaintext accounting, I don’t need hours of weekly time to keep decent finances, but perhaps an evening a month.
If you don’t mind me asking, what’s your use case or motivation for having sub-weekly updates to your financial picture?
Developers understanding double entry well is critical to avoid what I call "programmers reinvent accounting principles". I stumble across this all the time as a major blocker trying to tightly integrate modern SaaS in to enterprise IT stacks.
Ledgers are typically debit-normal from the perspective of the asset-holder. As a bank, your asset is my liability and vice versa, i.e. your mortgage (liability) is my asset (receivable), so it can make sense to model movement of funds as credit-normal to ease the construction of financial statements from the perspective of the bank.
By convention:
- Asset & Equity accounts are increased by Debits, decreased by Credits.
- Liabilities, Expenses & Income are increased by Credits, decreased by Debits.
Whichever convention you choose, consider that an Asset account like cash (Current Account) has to be funded from somewhere: either from a Owner Equity (investment in the business) or a Liability like a loan, so funds will flow from Equity -> Cash, i.e. credit Equity & debit Cash. To repay the loan, the flow is reversed: Cash -> Loan, i.e. credit Cash & debit Loan.
Thus holds the accounting equation that:
Assets = Liabilities + Equity
(I build double-entry accounting ledgers for a living.)
Agree about most of your text with one note:
Expenses are always Debits, thus they increased by Debits. Consider buying a can of CocaCola by cash:
- you give your cash — its amount decreases, that is you credit your Assets:Cash account
— money flow goes to Expenses account, let's assume Expenses:Food.
In terminology of beancount this transaction will look like this:
From the perspective of the asset-holder, expenses are increased by Debits, yes - unless you're a bank and want to account for both parties with a single set of ledger entries.
For example, if you are a bank and I am your customer, then when I spend some of my money to buy your products, my Expense is your Income. My cash asset is your liability.
At scale, it can be convenient to construct statements for both parties by regarding the same entries as credit-normal. Alternatively you have to mirror all entries in a 99%-similar ledger, but reversed.
Does it matter who holds an asset when determining whether to debit or credit an expense? I would think the question is who is making the expense, not who holds an asset, which may or may not be used to pay the expense.
In any case, unless you are talking from multiple perspectives, which would be unnecessarily confusing, expenses and income have opposite signs.
One interesting challenge I've been hearing a lot lately in accounting tech is that some accounts become a hotspot and slow down overall transactions. For example, you might take a commission on all transactions and you track that commission in a company-related account.
I'm curious how folks using a generic SQL or document database solve this.
What's the best tool to get started keeping track of our finances using double entry accounting?
Ideally, I'd love a tool that lets me import data from my credit card and/or bank accounts through something like Plaid rather than having to manually enter every transaction I make.
Beancount, software written by the author of the parent piece, is a terrific "plain text" double entry accounting system. I've used it for more than a decade on both personal finances and non-profit treasury projects. It was many tools in its ecosystem for reformatting (single entry) transactions into double entry.
GnuCash is a decent tool. I use it for my simple personal finances and it's good enough. I don't know if its import/export will suit your needs, but I think it's worth a try.
I chose Xero for a nonprofit whose books I keep. I had heard negative things about QuickBooks Online, but I also have qualms with Intuit over their tax shenanigans.
I do think Xero tends to overprioritize acquisition at the expense of providing a complete product to its users. Too many times, I have found some quirk or half-assed feature that Xero refuses to fix. That said, I have no doubt Intuit is worse at this.
If Your needs are simple, Xero works. But the moment you reach even slightly less than simple, you're going to need to work around quirks very quickly.
I was using Quickbooks Self Employed and must recommend to stay far away. Besides there being no way to migrate to the other Quickbooks services, the xls report export feature was broken for me and gave me incorrect amounts. After some time explaining the situation to a support person I was told the bug was an ongoing issue with some user accounts, and the support person had to manually calculate and edit cells in the xls document. It blows my mind that such an important feature can be so broken. There was no forthcoming information about the bug and I had no other way to send a report to my accountant.
I don't hate Quickbooks; I love it. But I hate Intuit.
I've been using QB both personally and professionally for over 15 years, it has just about every feature a small to medium sized business could want, and it's a default in the sense that you can go to just about any tax professional who prepares business tax returns and they will have no problem using your QB data, often by working with a copy of your actual company file, and providing year-end journal entries for you to reflect various tax adjustments.
The current problem is that Intuit is forcing everyone to subscription-only, even for the desktop product, and they've nearly doubled the annual license fee, mostly to try to force people to QB Online.
I'm an accountant, I run a finance team at an sme. I don't know much about tax at all. I certainly don't know 'tax code(s)' My accounts are fairly large, span 4 companies and several companies. My primary role is to keep the company solvant, and score keep for the shareholders and management team. My tax reporting is infrequent, outsourced to specialists, and not my primary concern. I look at the cash flow forecast every day. I look at tax once a year.
You don’t deal with salaries or collected VAT at all?
That sounds unusual to me but I’m European. My parents own a moderately sized SME which involves multiple branches and a holding. While monitoring cash flow and dealing with invoices and payables take the lion share of their accounting, taxes related activities still take a significant amount of times.
This massively diminishes the value of the decision making process of the accountant and bookkeeper.
I'm not aware of any SMB finance software that will, for example:
- Know whether to post a transaction as COGS, OpEx, or CapEx.
- Be able to decide if a transaction should be journals across a 24 month period or taken in a single hit.
- Judge the length of depreciation for a particular piece of plant
- Attribute unclear bank receipts to due invoices for reconciliation.
That's just a handful of examples. The software ENABLES the finance team to make their decisions and provides them intelligence, but they still do a huge amount of the decision making. The decisions bookkeepers and accountants are taken are largely individual business specific, and based on the accounting principles of that business.
Frankly if the decisions are taken well and the software is good, then the tax element can become one of the easiest components where the computer CAN just get on with it, along with the tax specialists
I think there’s some truth to this but there’s also the need to set up books well and to implement important practices like reconciliation. For example the way accounts are grouped together can be important, eg to be able to see COGS and EBITDA.
Mostly what I see is that an in house accountant does the books and an external accountant does the tax. But that might not be the case in all jurisdictions.
All of that said, I’ve seen a lot of P&Ls and balance sheets over the years and most of them are so overcomplicated that it’s difficult to understand the business fundamentals. I’m not sure if that’s because accountants make things complicated, but I suspect it’s because accountants aren’t asked to be involved when they should be.
