There is a reason why it all seems so oddly ancient. Rule number 1 - if its not broken then don't fix it. Not the usual hn mindset I know, but you only need to be involved in one bad transition between finance systems to know that it can be a huge shtstorm. Big enough to kill a company. That is why everyone is running ancient mainframe era tech and everything feels like its 10 year behind silicon valley mindset.
Its all good & well on a small business scale to DIY and integrate things hacker style but beyond that the actual accounting problems become big enough that you don't want the latest flashy gimmick adding potential unknowns. Its kinda like you don't run nightly builds on your production server.
As for the formats & integration - yeah not great. What you're looking for is essentially EDI, but there isn't a market for it on that scale. Its also still fairly fragmented so only works on an enterprise scale (i.e. BMW tell all its suppliers they are to use X standard).
Unfortunately in my experience (auditor) the more people try to hack together a solution the worse the end result. I've had to tell a CFO that all of their numbers from top to bottom are bad because they custom rolled a key component and the people that did so missed a subtle accounting nuance. Cost them a fortune to fix it. So yeah by all means go automate data transfer but please don't attempt to implement any actual accounting logic. Its like a airline pilot attempting surgery (or a surgeon flying an airliner). Neither even realises they're making a mistake until its too late.
Building accounting systems is a lot like building distributed systems. It's not too hard to get something that looks like it's working, then blows up badly in production.
Not really. The bank stuff (where they are REALLY still running ancient mainframes) is not changing because its a bureaucracy and they're super risk averse. And every year the conclusion is the same - limp along for another year. Plus there are cases where the tech is so old that its essentially a black box at this stage.
On the authors scale - they're are few people that have the necessary odd combination of skills (accounting & programming). And those that do don't spend their time writing SME software...they work on enterprise scale stuff.
As for no incentive to fix it - trust me nobody likes paper invoices. Not even bookkeepers. Everyone's life would be easier if there was a widely adopted standardized system in place.
Accountants usualy don't write the legislation they have to follow. In that sense, they have no incentive one way or the other.
If you mean that the incentive is for companies to get legislation vague enough that it can be bent in different ways, I might agree, but even if they wanted to, it's really difficult to find a common way to account for both multinational biotech companies and individual stallholders in Chattanooga TN.
There is a lot of "meta" money in the money system, accountants, CPAs, forensics, bankers, clerks, etc. So automating that away is nominally an existential threat to their businesses.
Some folks (like Quicken in the US) use automated download as a way to insure upgrades (they periodically make it impossible for previous versions to work any more so that you have to upgrade or lose the capability). I got sick of that and wrote a csv ingester in perl.
But business has been transacted, literally, for thousands of years and there is so much variety there. I don't expect full automation until we have even better cognitive tools which can dynamically adapt to what ever is needed.
So that leaves you with a patch work of things and not a lot of incentive to unify them. It reminds me of the CAD framework initiative where engineers tried to unify the sharing of CAD data, except the CAD vendors figured out that lead to less "stickyness"[1] and started working against it. Banks are no different, there is nothing to distinguish bank "A" from bank "B" with respect to holding on to your money.
Payments and invoices are a bit different, working with the vendor, if you are a B2B business you can often negotiate something if you are B2C you are in a stronger position to simply insist that your customers use your automation tools.
[1] This term has been used to describe tools and techniques that make it hard to switch from one provider to another, thus maximizing your "customer lifetime value" often at the detriment of the customer.
What's that quote again, "never attribute to malice that which is adequately explained by stupidity"? CAD vendors might intentionally have designed "stickyness"[1] but banks and B2B transactions are pretty much standardized via EDI ANSI docs[2]. It's a legacy set of standardized protocols/documents that you have to deal with because DbC works badly, and corporate DbC works even worse when someone like SAP is influential in the decision process.
SAP has done a lot of bad things[3] but they pretty much standardized how business is done in most industries, whether you're a plastics injection molder in China, dealing oil out of Dubai, or the trader in Zurich making his fortune figuring out how to get that crude from Dubai and refined into some plastic polymer pellets to that Chinese plastics vendor (who'll sell those 50 cent widgets to you in a few months).
[1] We have the same thing in our industry, we just call it "vendor lock in". I sort of touched on how the "meta money" worse in fed contracts here (https://news.ycombinator.com/item?id=10807858). A CPA is basically a programmer maintaining legacy code (300 years of obscure tax code (they even call it the same thing)) feeding your input data (your quarter and/or years aggregate financial data) to produce output data (your 1040 or whatever). Edit: Havoc basically captured the whole "legacy" reasoning (a mentality of "they'll remember my potential failed project a lot more than they'll remember my potential re-implementation that will only slowly (but very substantially) accrue profits" is always in the back of your mind. There's a lot of politics when you reach the decision-making level and risk aversion is a necessary skill to adopt to keep yourself out of hot water.
[2] https://en.wikipedia.org/wiki/X12_Document_List#Financial_Se... or variants there of. Even other ERP's FI & Controlling (or AP/AR) will have some sort of 'Connector" that will enable you to talk to SAP in some fashion. You'll just be paying Epicor, Netsuite, or Oracle a few hundred k for the modules.
[3] Can't knock on it too much since I've profited directly from the convolution of SAP ECC 6, but I certainly I generated more value for the clients than I billed.
Strictly speaking, this is book keeping, which is the on-ramp to accounting proper.
The bulk of accounting, as I understand it, is not the relatively simple updating two accounts in a single transaction on a ledger.
It's deciding which accounts. Which ledger. And making a case for why.
Because the flipside of accounting is management accounting: those famous reports (income report, cashflow report, balance sheet) which markets and governments take such a close and legally meaningful interest in.
This is all correct except that financial accounting deals with external reporting and managerial accounting deals with internal reporting. But the distinction between bookkeeping and accounting is spot on IMO.
Pretty much, yeah. Managerial 101 builds on introductory financial reporting. The biggest difference between them are the intended users. While financial accounting is all about accurately stating your financial position for tax authorities, capital markets, banks, and other potential users, managerial accounting is internal. It's for managers and decision makers to give them the most accurate information possible. Because of this, there is no consistent standard used in managerial accounting like there is in financial accounting (GAAP or IFRS), but its largely similar I believe between different companies.
Bookkeeping is tactical and low-level while accounting is strategic and higher-level. A lot of the strategic possibilities come about because of the many ambiguities and options in tax areas, and because the "best" decision for a given question has to do with so many variables.
First time hearing about MT940 and SWIFT message format. As a Canadian, I'm used to seeing QBX/OBX/CSV as import/export formats (thanks to QuickBooks and Microsoft Money), and every accounting package I've worked with allows for CSV import though it's not quite as nice about it.
Odoo Accounting has nearly everything the OP wants:
- full API: https://www.odoo.com/documentation/9.0/api_integration.html
- direct integration with 24.000 banks for statements
- for non supported banks, has it supports bank formats, including cmat.053 in germany
- automate payments with SEPA (in Europe, or checks in U.S.)
- automate invoicing and follow-ups of payment by email or regular mail (docsaway integration)
- it supports Germany (SKR04)
Odoo has hundreds of business apps. Our cloud offer is free for one app. So, if you only use accounting it's free, but if you need more application: eCommerce, point of sale, inventory, etc. then you have to pay.
That's for the cloud offer, but you can also download Odoo.
We are mostly open source (https://github.com/odoo/odoo) but have an open core business model for on premise installations with a bit more features in Odoo Enterprise.
The offer is explained here: https://odoo.com/pricing (although I am not sure this page is clear; we are still thinking about how to improve it)
The pricing page is quite clear. But the pricing calculator linked, https://www.odoo.com/pricing-online does not seem to include the cloud offer you mention?
From there it looks like one needs to pay a base cost of €20,- / month / user before selecting apps. Then, the calculator doesn’t make me have the first app for free. What’s more, I can’t select accounting (€20,- / month) without also selecting invoicing (€10,- / month). So if I’d want an install with only accounting, instead of it being for free, it looks like it costs at least €50/month?
> Cool. So will there have to be a paying user or will the first user be free as well?
No, it's really free. Since the first user.
> Also, since the apps have different prices, will it be
> the cheapest or the most expensive app that comes for free?
You always start with one app, this one is free and also it dependencies. So, whatever you start with, it's free. (e.g. you get accounting+invoicing for free)
But if you want one app more (e.g. inventory), then you have to pay for all apps / users. It's not "one app free", it's a "free for one app" plan.
But if you want expense management as well, you will have to pay for everything. (use vendor bills which are in accounting app, instead of expenses, so that you stay in the free plan)
Thanks, for the feedback, we really need to improve the pricing page...
Cool. So will there have to be a paying user or will the first user be free as well?
Also, since the apps have different prices, will it be the cheapest or the most expensive app that comes for free? The former seems the most logical but it could lead to some unintended consequences. Like, I could be mainly interested in accounting (with its dependent invoicing module, the two of them together costing €30/month). I could get this for free. Say I‘d be interested in adding the expenses module as an upsell. After all, it’s only €10/month. And it has no dependencies. But if the cheapest modules is for free, the €10 upsell would actually cost me €30/month, and would be much less attractive.
I couldn't find any info on this on your page, but do you also support importing the data from Apples (or Googles) App Stores? I.e. all my sales information form there?
Part of the author's problem is that he's in Germany: a country in love with paper trails. You can't change your phone plan without writing a letter of request (not joking). Taxes require a level of documentation that in North America is only needed for an audit. No joke, MT personal and business tax return is a thick binder full of paper every year. The only solution is to pay a tax lawyer to prepare it for you.
Yes, there's a whole field of law that's just for filling out tax forms. And it's an enormous industry here.
Incidentally, the complexity is maintained by the tax lawyer lobby. There have been a few proposals to simplify the tax code, but it's hard to do when a third of the civil service and the single largest legal profession in the country oppose the idea.
Björn, nice read! Your description of the current state of accounting in Europe is very accurate. As a founder of an online accounting tool, I know a lot about the struggles you are having. The difference is: it’s my job to improve the lives of entrepreneurs and solve the problems you mention. This doesn’t make it less of a challenge though, I feel a lot of the same pain you are feeling!
The first steps for a automated accounting are already in place:
1. In Holland we are working towards a standard for exchanging invoice information based on the Universal Business Language XML standard. Both the market and the government are supporting SimplerInvoicing, the first invoices are already being exchanged at this time.
2. The European Union has introduced new regulations concerning your banking data. Within a few years, all European banks need to comply with PSD2, which means all your data should be accessible through an API. Unfortunately the banks in Holland are not very fast. Sometimes starting your own bank seems like the fastest solution to enable technical innovation, but the regulations in de European Union for starting a bank are even worse.
There are many more steps to make, but I strongly believe small startups like my own (MoneyBird) can make a change. Can’t wait to see what the future of accounting brings us!
Have you tried a human being as a solution? Software in the finance industry is growing exponentially, yet people are super confused - like confusing accounting with book keeping. What if you could outsource all your book keeping, accounting and reporting services to a serious firm for some dollars a month?
That's the usual approach and yes: I've tried it. Finding a good accountant who's up to that kind of task, responsive and not afraid of using modern software, is surprisingly difficult.
There are new entrants to the market such as Felix1 in Germany or Crunch in the UK though that promise this exact service.
Your suggestion certainly is a good one but I'm still wondering why accounting and book keeping requires so much human-machine interaction. I'm not talking about handling edge cases, exceptions or conflict resolution, things you need a human being for. You shouldn't need an accounting firm for entering incoming invoices or synchronizing your bank account statements.
Agreed, but I am going to guess that the biggest problem is not the human-machine interaction, but all the hedge cases that eventually happen and require a human to make a decision. Also, consider that an outsourced analyst will probably be cheaper than building and maintaining a full fledged software solution. What you need is a good accountant who is managing few analysts so that he can intervene only when needed, saving you lots of $$ that you would spend just to have him do book keeping.
Also, a human should advise and help you to move to another bank, one that has better interfaces with modern software solutions (like the one you use or Quickbooks or the many other around).
I tell you from my experience working in finance that you will never manage bank reconciliations automatically 100%.
"Why do many companies even seem to insist on paper invoices that add the additional nuisances of having to scan and file those documents?"
It's called Cashflow management. Maybe you're in a high margin high profit business. But the other 95% of all business owners are in a brutal competition for Cashflow. That means make paying out as hard as possible.
I work for a university, and they're pretty big on paper receipts for expenses, as well as money incoming. It's more about auditability, I think. To be able to say to the IRS, shareholders, the government and even internal management that the money spent in transaction ad9c538e was spent buying servers, and that five years ago those same servers were fully depreciated and sent off for ewaste / recycing, and here's the documentation to prove it.
Otherwise, you're potentially taking too much depreciation, opening the door to employee theft, and making managerial decisions based on poor data. Paper / letterhead is some kind of proof that can be followed up with. Even if an employee fakes a purchase, does Dell have a record of purchase order #2023420? They don't?
An electronic version of this stuff would be fairly useful, but is sort of a collective action problem: if vendors offers API nobody uses, was it worth the effort? How do you handle N vendors offering N different APIs? And how do they upgrade when they interact with hundreds of clients?
You can't automate exceptions and mistakes, which is what most companies spend a lot of time with. Also the industry has decades of proprietary crap build into it.
This is certainly one area the tech sector can tackle (maybe with smart contracts) but it's years away and requires a lot of effort in the financial space.
This has been my main interest for over a decade. I started down the rabbit hole after doing my books by hand throughout the late 1990s and early 2000s and hiring CPAs who strangely never asked any questions. I built a web-based accounting program to automate what I was doing in Excel, and eventually, my corporate taxes. Everything seemed to hinge on the availability of line item data; but getting line item data hinged on the payment processors allowing it to be transmitted and stored. That functionality still doesn't exist today in ACH or payment card formats.
So, being an entrepreneur, I set out to build a new network that would support the functionality, as well as better security features. And I did. But then the California Money Transmission Act intervened thanks to financial lobbyist Ezra Levine and his client, The Money Services Round Table; no other startups or VCs wanted to take on the issue in a coalition; and the California government wouldn't budge. So I sued the State (http://www.plainsite.org/dockets/8l0ickx4/california-norther...), and the judge was apparently so hopelessly confused that he sat on the State's motion to dismiss longer than any other non-stayed motion in Northern District of California history: about four years.
I lobbied in Sacramento in the meantime and got the law changed twice, to the point where it's essentially moot, but there's still 46 others, and via 18 U.S.C. § 1960 it's a federal crime to violate any state money transmission law.
While all of this has been going on, the big players have skillfully ignored the line item data problem and instead attempted to deploy EMV nationwide in the United States at the cost of billions of dollars. But there's no PIN functionality yet, just chips, which are hardly supported uniformly as many vendors balk at "certification" fees for technology that's already outdated relative to smartphones. And startups and their funders, including Y Combinator, have been in a race to see who can ignore (break) the most laws fastest, which has given regulators an excuse to claim that no one has come to them with real concerns.
Last Thursday the Office of the Comptroller of the Currency (OCC) put out a much-heralded white paper that, between the buzzwords, suggests it might be interested in addressing the outdated regulatory gridlock. See http://www.occ.gov/news-issuances/news-releases/2016/nr-occ-.... Comments are due in May. For now, I've written more detailed thoughts here:
So, I get that they're not giving you line items. What I don't get is why? Is there some competitive advantage or whatever that's causing the big players to lobby the government to prevent it?
It seems to me that, at some level, everyone already "has" their line items—just not in a convenient form, i.e. paper (or email) receipts.
Is there cost involved in getting them to people? Standardization? Legacy systems/formats/whatever in the way?
Thanks for your writeup by the way, I'm also in CA and learned a lot.
Legacy systems that are totally inflexible is the main problem. Much of this stuff was developed in the mid-1960s. Upgrades and standardization are not considered a "profit center" for an already very profitable industry, and the costs would be enormous. The EMV rollout has cost tens of billions and it doesn't even touch the formats.
I haven't seen ledger.cli mentioned yet in this thread: it's a command line accounting tool that's fully text based, which allows a programmer to easily add little scripts to parse weird MT940 / CSV files and allows you to use all the comforts of git in your workflow. Pretty steep learning curve if you don't know accounting well, but incredibly powerful once you have all your accounting chores automated away.
Its all good & well on a small business scale to DIY and integrate things hacker style but beyond that the actual accounting problems become big enough that you don't want the latest flashy gimmick adding potential unknowns. Its kinda like you don't run nightly builds on your production server.
As for the formats & integration - yeah not great. What you're looking for is essentially EDI, but there isn't a market for it on that scale. Its also still fairly fragmented so only works on an enterprise scale (i.e. BMW tell all its suppliers they are to use X standard).
Unfortunately in my experience (auditor) the more people try to hack together a solution the worse the end result. I've had to tell a CFO that all of their numbers from top to bottom are bad because they custom rolled a key component and the people that did so missed a subtle accounting nuance. Cost them a fortune to fix it. So yeah by all means go automate data transfer but please don't attempt to implement any actual accounting logic. Its like a airline pilot attempting surgery (or a surgeon flying an airliner). Neither even realises they're making a mistake until its too late.