Accounting in 2016 – Still a manual and tedious process
bjoernkw.com
bjoernkw.com
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.
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.
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.
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.
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.
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.
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.
- 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)
It's 100% free, unlimited users on the cloud: https://www.odoo.com/page/accounting
Odoo Community is open source: it includes most accounting features but not the payments and bank interfaces.
disclaimer: I am the founder of Odoo
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)
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?
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...
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.
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.
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!
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.
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%.
Famous last words. As long as you define 100% to be residual errors at human level.
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.
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?
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:
http://www.aarongreenspan.com/writing/20131118.hsgacstatemen...
And all I wanted were my line items.
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.