Accounting systems: a rant and a quest

By Jonathan Corbet
May 8, 2012

Attentive long-time readers of LWN may remember that this business is based entirely on free software with one distressing exception: our business accounting is still done using the proprietary "QuickBooks Pro" package. QuickBooks does not lack for aggravations, but the task of replacing it has never quite attained a high enough priority for something to actually happen. Good replacements in the free software community are hard to come by, accounting is boring, our accountant deals easily (and cheaply) with QuickBooks files, and the existing solution, for the most part, simply works. Or, at least, it used to simply work.

The monthly accounting ritual involves importing a lot of data from the web site into the accounting application; in particular, subscription sales need to be properly fed in so that we can minimize our taxes on the income in the proper American tradition. This process normally works just fine, but, recently, it failed, saying: "Cannot import, not enough disk space or too many records exist." Naturally, in QuickBooks style, it failed partway through the import process, leaving a corrupted accounting file behind. But QuickBooks users usually learn to make backups frequently and can take such things in stride.

The inability to feed data into the system is a little harder to take in stride, though, especially once some investigation proved that disk space is not in short supply and the failure is elsewhere. It didn't take much time searching to turn up an interesting, unadvertised QuickBooks antifeature: there is a software-imposed limit of 14,500 "list items," which include products offered by the company, vendors, customers, and more. Once that limit is hit, QuickBooks will not allow any more items to be entered; the only supported way out is to upgrade to the "enterprise" version, which can currently be done for a special offer price of only $2400.

In other words: Intuit sells a program that is intended to become an integral part of a business's core processes, perhaps even functioning as a point-of-sale system. This program will, without warning, simply cease to function once the business accumulates an arbitrary number of entries. The only way for that business to get a working accounting system back is to "upgrade" to a new version that costs ten times as much. One can only conclude that this proprietary software package has not been written with its users' needs as the top priority. Instead, it contains a hidden trap to force them into more expensive offerings at a time when they may have little alternative. Who would have ever thought proprietary programs could be that way?

Here at LWN, we had no particularly urgent need to get things working again; other businesses may well not have the luxury of enough time to find an acceptable way out of this situation. It is, thus, unsurprising that there are entire businesses being built around this little surprise from Intuit. Needless to say, there is little enthusiasm in the LWN head office for the purchase of an expensive and proprietary "enterprise" accounting system. In the short term, a workaround has been found: sacrifice most of our accounting history to bring the record count to a level where the program will consent to function as advertised. That has other interesting side effects, like mysteriously changing the balances of reconciled accounts from previous years, but it does take the immediate pressure off. For now, we can continue to do our books.

But a clear message has been delivered here: it is about time that we at LWN read some pages from our own publication and realize that a dependence on proprietary software poses a real risk to our business. A company that is willing to put one such hostile surprise into an important application will put in others and, without the source, there is no way anybody can look for them or remove them if they are found. QuickBooks is too risky to continue to use.

It is, in other words, time to make the move to a free accounting program.

When we have looked at the available tools in the past, the results have always been a little disappointing. There is no shortage of software that can maintain a chart of accounts and a set of double-ledger books. But there has been, in the past, a relative scarcity of useful accounting tools for small businesses. Instead, what's out there is:

Various personal finance utilities, including GnuCash, KMyMoney, and others. For basic accounting they work well, but they fall short of a business's needs.
Massive enterprise-oriented toolkits that can be used to build systems implementing accounting, inventory-tracking, point-of-sale, customer relationship management, supply-chain management, human resources, and invoicing, with add-on modules for bill collection, weather prediction, automated trading, and bread baking. These systems have names like ADempiere, Compiere, OpenERP, LedgerSMB, and Apache OFBiz. The target users for these projects appear to be consultants and businesses with full-time people dedicated to keeping the system running. To a business like LWN, they tend to look like a box with hundreds of nearly identical parts and a little note saying "some assembly required."

What is missing in the middle is a package for a business with no special accounting needs, but which needs to be able to automate data entry, generate tax forms at the end of the year, and interface with an accountant so it can get its taxes done. Given how incredibly exciting small-business accounting is, it's surprising that so few developers have felt a burning need to scratch that particular itch. There is no accounting for taste, it seems.

That said, it has been a few years since we last made a serious effort to learn about free software accounting alternatives; clearly the time has come for another pass. So we'll be doing it, with an eye toward, hopefully, making the transition at the end of the calendar year. That gives us several months to forget about the problem while still allowing a few months of panic at the end, so the schedule should be plausible.

Stay tuned for updates, it should be an interesting ride. But we are pretty well determined not to find out what other surprises our proprietary accounting system may have in store for us. In 2012, it should be possible to run a small, simple business on free software and never have to wonder when the accounting system will stop functioning and demand more money. We intend to prove it.

Accounting systems: a rant and a quest

Posted May 8, 2012 20:37 UTC (Tue) by bernat (subscriber, #51658) [Link] (1 responses)

GNUcash has official Python bindings. Shouldn't be a good way to interface with the web site ?

Accounting systems: a rant and a quest

Posted May 17, 2012 10:27 UTC (Thu) by ajmacleod (guest, #1729) [Link]

I have never interfaced it with anything, but we have used GNUCash for many years to run a small business and are pretty happy with it.

When we started up we bought the basic Sage package (our only Windows-based software) and started using it - within two weeks it had infuriated me enough that it was dumped for GNUCash which has steadily continued to improve.

All our day-to-day small business needs are well covered; we keep customer records, do invoicing, reconcile with bank (initially using electronic bank data but soon found it just as easy to do manually).

At the end of the year I just run a few reports to get figures for the various income / expenditure categories required and send these to an accountant who uses them to fill in the necessary returns.

Yes, it would be nice if there was a more user-friendly way of customizing invoice layouts, but really other than that I really can't think of much to complain about - for a few years now it has been very stable indeed.

What exactly does LWN do that GNUCash can't comfortably deal with?

I should say that I handle payroll mostly outside of GNUCash, using a fairly simple LO spreadsheet for payslips; fortunately in the UK the government provides software to handle the payroll taxes which amazingly is available for Linux too.

Accounting systems: a rant and a quest

Posted May 8, 2012 20:47 UTC (Tue) by cantsin_ (guest, #74889) [Link] (5 responses)

I run a small business also. We pretty much settled on Quickbooks as the only viable accounting software, and it's such a pain, since it requires me to maintain a virtual Windows environment just to do our bookkeeping. (Windows isn't installed on any other box we have.)

I really, *really* would like to learn about open source small-business accounting tools out there too. Like the article alludes to, there's a lot of activity on the personal finance software side but seemingly little on the small-business front. I do have to say, though, I'm somewhat relieved that I'm not the only one with this problem...

And at the same time, I'm not really surprised with the dearth of good open source accounting solutions. Quickbooks is the 800lb gorilla -- I don't think any of our small-to-medium sized clients use anything else. It's "good enough" for virtually all cases, so Intuit has a huge moat around that particular business.

Accounting systems: a rant and a quest

Posted May 8, 2012 21:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Heh.

Russian accounting giant (1C Enterprise) has just entered the US market. So hopefully Quickbooks would get competition soon.

Accounting systems: a rant and a quest

Posted May 9, 2012 8:48 UTC (Wed) by dgm (subscriber, #49227) [Link] (3 responses)

One of the reasons that no small business accounting package exists is that, in general, small business owners do not have much time for coding, while the people that have the time and energy lack any knowledge of what those things are supposed to do.

So, one productive thing that you could do to help yourselves is write a good specification of what features an adequate and free Quickbooks competitor needs, and how they should work. Maybe someone will pick it up and convert it into working code.

Accounting systems: a rant and a quest

Posted May 9, 2012 9:49 UTC (Wed) by jamesh (guest, #1159) [Link] (1 responses)

Well, the other thing many of the proprietary systems give you is a machine readable version of the tax code. Depending on the type of business, this could easily justify the subscription costs.

Unfortunately, this data is fairly localised and there can be large penalties if the data is wrong. So it isn't clear that a community project could take over this role.

If the free accounting systems had a standard interface for this type of data, it could provide a business opportunity for companies who were willing to provide the data though.

Accounting systems: a rant and a quest

Posted May 10, 2012 14:48 UTC (Thu) by dgm (subscriber, #49227) [Link]

Even if the details (tax code) is strongly local (both in space and time), a general engine open for extension via plugins should be possible. The explanation about how C1 works by Cyberax seems a good starting point.

Accounting systems: a rant and a quest

Posted May 13, 2012 10:40 UTC (Sun) by ortalo (guest, #4654) [Link]

+1 for writing a documented specification on your case please.

Personnally, I've been using KMymoney for a while for family money and, well, it definitely proved very helpful.
I am sure this software, or another one, would definitely benefit from being given/asked for a wider but achievable target.

Accounting systems: a rant and a quest

Posted May 8, 2012 20:59 UTC (Tue) by djc (subscriber, #56880) [Link] (4 responses)

The SFLC seems to use something called ledger. Perhaps it's interesting? Here's something I dug out of Google...

http://www.softwarefreedom.org/blog/2011/sep/07/accountin...

A few notes on ledger

Posted May 9, 2012 0:16 UTC (Wed) by cworth (subscriber, #27653) [Link] (3 responses)

I've been using ledger for my personal finances for quite some time.

I love that it has a plain-text input syntax, (so I manage all of my
ledger data files with git, and use the One True Editor as the primary
interface for data input).

The simple command-line interface has always proved sufficient to me
for quickly looping over the data file and generating whatever balance
or register reports I've needed.

That said, I don't have any visibility into what the detailed needs of
small businesses are which our esteemed editor can't seem to find in
the various "basic accounting" packages. Two things mentioned in the
article are to "generate tax forms" and "interface with an
accountant". I don't know that ledger has much in the way of specific
support for either task.

So I would guess that ledger in its current form might fall short like
many other software programs. But the fact that ledger has a real
"Unix way" about it, (focusing on the small task of defining a
human-readable data syntax, and generating reports from it), might
just make a great basis on which to build more sophisticated
data-entry and reporting interfaces.

Presumably SFLC, (unlike me), actually deals with interfacing their
ledger data with professional accountants. So those folks might have
some useful insight.

A few notes on ledger

Posted May 9, 2012 11:55 UTC (Wed) by emk (subscriber, #1128) [Link] (2 responses)

There's several "Ledger" pacakges floating around. This is the text-based one:

https://github.com/jwiegley/ledger/wiki

I actually use Ledger for a consulting business, together with Emacs ledger-mode and FreshBooks for invoicing. For taxes, I just make sure that my expense categories correspond to those used by the IRS, run a report, and copy about 20 numbers over to the tax forms.

If I want to review something with my accountant, I just sit down and read the text file with him. Of course, everything is kept in version control, and I can add comments in the main ledger file.

The Ruby scripts download CSV data from my bank and Freshbooks, and convert it into raw ledger files.

Curiously, the whole system is actually pretty quick and painless — I spend a few hours each quarter on bookkeeping, and I can automate any annoyances with a 20-line script that munges text files. You'd think a GUI would be easier, but really, there's a lot to be said for plain text once you want to automate something. And it's nice to have a big comment at the top of the ledger explaining the relevant IRS rules.

So +1 for Ledger, despite the retro approach.

A few notes on ledger

Posted May 11, 2012 18:37 UTC (Fri) by daglwn (guest, #65432) [Link]

ledger-mode? I'm sold! Thanks to all of you for making us aware of ledger!

A few notes on ledger

Posted May 17, 2012 0:24 UTC (Thu) by dmarti (subscriber, #11625) [Link]

+1 Insightful.

A web developer and designer could probably get 200 grand from Kickstarter to develop a robust open source small-business accounting system, then put a slick web API and front end on ledger and git and make the best accounting software in the world. (Not that the competition is great or anything.)

Accounting systems: a rant and a quest

Posted May 8, 2012 21:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

<rant mode>
Developers of GnuCash and other accounting programs clearly have zero knowledge of good existing accounting systems. But they can be forgiven, since there are NO good accounting systems on the US market.

That's right. Even QuickBooks is crap, it's a highly polished crap, but still crap. It's not configurable and its API is a PITA. It's also unreliable and slow.

A good accounting system should provide:
1) Way to construct custom forms and easily link them to entries in the accounting system.
2) A _temporal_ database for entries. I.e. it should be possible to do things like: "how had our accounts looked at 3:00PM June 11, 2011?", taking into account backdated documents and corrections.
3) A set of standard forms (which is actually the easiest part) with a way to construct new ones.
4) Easy way to integrate with logistics and warehouse management.
</rant mode>

Accounting systems: a rant and a quest

Posted May 8, 2012 22:36 UTC (Tue) by cantsin_ (guest, #74889) [Link] (5 responses)

I'm definitely not going to argue against your assertion that "Quickbooks is crap", but I have to ask: which particular software (US-centric or otherwise) would you consider great for small-business accounting?

Accounting systems: a rant and a quest

Posted May 9, 2012 2:08 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

In the xUSSR countries 1C Enterprise rules completely. Most needs of a typical small business can be automated almost completely. And it's also fairly easy to extend for specific purposes - a trained 1C developer can add typical business-related functionality as fast as you can make a spec.

Now, it's not ideal of course. The IDE in 1C is atrocious, its internal language is dumb, it's hard to scale 1C applications, etc. But the core ideas in its design are pretty good.

Accounting systems: a rant and a quest

Posted May 9, 2012 8:52 UTC (Wed) by dgm (subscriber, #49227) [Link] (3 responses)

Could you explain those ideas and design in some detail?

Accounting systems: a rant and a quest

Posted May 9, 2012 17:16 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

In short, it's built around the idea of 'documents'. Each operation has an associated document.

For example, each sale would result in a 'Receipt for customer' document. A document can have linked documents (a receipt would typically be linked to a shipping order, for example). Documents are generally immutable and are not changed once created.

The second fundamental idea are 'registers'. They represent a temporal database which accumulates the changes that are made when documents are created. I.e. you can have a register tracking your bank account balance and when you write a check it would be decreased by the check's amount. However, since registries are temporal, you can actually view your balance at any point in time.

Including the future.

Which very useful for things like warehouse management for things like: "Assuming I don't get any new orders and my current shipping orders are completed in time, how much widgets would I have in store on Monday next week?".

Also, it's useful for backdated documents (which happen all the time in small business) - you can enter a document in the past and 1C would recalculate all the reports/documents that are affected by the corresponding changes in registers.

Then there's an easy ability to create forms bound to documents/registers (a bit like MS Access but more powerful) and design reports.

A system like this is actually not that hard to create. But the amount of details you need to know is staggering.

For instance, a lot of 'ledger' software has a built-in CRMs (it's only logical). But only very few of them have a temporal CRM which becomes crucial quite soon when you start dealing with customers changing their company names and/or addresses and you need to reproduce historical documents.

Accounting systems: a rant and a quest

Posted May 9, 2012 17:50 UTC (Wed) by zlynx (guest, #2285) [Link] (1 responses)

From your description it really sounds like a system based on a functional programming language. Lists of immutable objects operated on by functions that accept a "time t" parameter and lazy evaluation.

I love the idea of a database that can be queried "as of time t". I seem to remember that PostgreSQL used to support that as a neat trick of MVCC (version 4 or 5?) but on larger tables with heavy use the transaction IDs rolled over too quickly.

Accounting systems: a rant and a quest

Posted May 9, 2012 18:04 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, it has the same ideas as functional programming. But such kind of logic must be implemented on the application level, it's not appropriate at the database level.

Accounting systems: a rant and a quest

Posted May 8, 2012 21:29 UTC (Tue) by boog (subscriber, #30882) [Link] (1 responses)

You may wish to add Tryton to the list of (larger) packages to examine. Python/Postgres suggests a minimum of good taste and it claims to be modular. The mailing lists etc display high apparent levels of activity. (But, of course, I haven't tried it.)

http://www.tryton.org/en/

"That gives us several months to forget about the problem while still allowing a few months of panic at the end, so the schedule should be plausible."

DANGER! DATES ON CALENDAR ARE CLOSER THAN THEY APPEAR! :-)

I'm reminded of the birth of git. How hard can it be to generate a report from some database data?

Accounting systems: a rant and a quest

Posted May 9, 2012 0:35 UTC (Wed) by neilbrown (subscriber, #359) [Link]

> I'm reminded of the birth of git. How hard can it be to generate a report from some database data?

Surely just a couple of awk scripts with a php front end :-)

So what we need as the first follow-up article is detailed specifications of exactly what a small business *needs* in an accounting package. Then the many time-rich LWN readers can start a number of competing projects to implement a system meeting those needs in the hope of being featured in a subsequent article. And then .... profit!

Accounting systems: a rant and a quest

Posted May 8, 2012 21:59 UTC (Tue) by dankohn (guest, #6006) [Link] (3 responses)

While switching to an open source solution might avoid lock in and would certainly provide journalistic fodder, you might consider these two solutions if you just want a bandaid solution:

Switch to QuickBooks Online (this would also allow you to avoid Windows/WINE)
https://qboe.custhelp.com/app/answers/detail/a_id/1089

Buy this 3rd party app for $75
http://www.quickbooks14500.com/

Accounting systems: a rant and a quest

Posted May 8, 2012 22:17 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

Strangely enough, we're not inclined to trust Intuit to hold all of our company accounting data in some online database. Even if we were, at least some years ago, QB Online was still Windows-only - would only work on IE. Perhaps they have fixed that.

Quickbooks14500.com was linked in the article. It's not the temporary solution we took, but the end effect is the same: trash your history, allowing list entries to be used for other purposes.

Accounting systems: a rant and a quest

Posted May 11, 2012 12:40 UTC (Fri) by jeremiah (subscriber, #1221) [Link]

As an fyi. Im a small buisness owner and work in a linux only world. I used to use gnu cash but switched to qb online about two years ago. Ut works fine on linux once you click past the giant number of warnings that it doesnt. I felt that i didnt want to host my own financial data and that it wasnt worth the worry to do so. I currently have no need to interface with it so lack of locality doesnt bother me. My day job on the other hand has required me to be involved in the writing of two distinct accounting systems that handle millions per month. I think what happens is that if you dont use qb you just write your own once you hit a certain level. You only need a very specific amount of data and just a few reports to pull it off. Then at the end of the quarter you print your report and hand it to your accountant. No auto tax forms thata what your accountant is for. Just the numbers he needs and the list of accounts and balances. I think accounting systems have a hard time being generic. When they are they tend to look like gnu cash or any other ledger system. Which makes most people uncomfortable. Does qb really bring that much to the table? Ill bet your accountant is still going to charge you the same. Hes going to verify your transactions with the accountant view anyway. Which puts qb in ledger mode.

Accounting systems: a rant and a quest

Posted May 9, 2012 8:08 UTC (Wed) by DG (subscriber, #16978) [Link]

When we looked at QB Online it didn't appear that there was a friendly import process - i.e. it was effectively changing system and as painful as moving to any other platform.

In the end we moved to Kashflow which is working well for us. Unfortunately there appeared to be no viable FLOSS equivalents.

Accounting systems: a rant and a quest

Posted May 8, 2012 22:02 UTC (Tue) by geuder (subscriber, #62854) [Link]

Accounting software is either country specfic or it needs heavy localization because of different accounting practices and laws.

However, it sounds unbelievable that there is nothing suitable for the US market. For the 60 times smaller Finnish market there is Pupesoft.

I have no experience with the system or with business accounting in general. I have met 1 happy Pupesoft user and one non-user who recommeded to localize some international/American(?) system instead. Unfortunately I don't recall the name.

Accounting systems: a rant and a quest

Posted May 8, 2012 22:14 UTC (Tue) by job (guest, #670) [Link]

I've have had some experience with above mentioned LedgerSMB, but keeping track of data is what a computer is best at and you could probably just as easily script your own software (just as I keep some sh and TeX scripts around that generate my invoices). What you really need as a small business owner are codified accounting rules. Your software needs to know that this year there is a special tax break on people below age x so the value y should be calculated in a different way for them. Those are specific to both year and locale of course. When you're very small and want that done with software there's not much choice.

Accounting systems: a rant and a quest

Posted May 8, 2012 23:03 UTC (Tue) by copsewood (subscriber, #199) [Link]

I've seen account-based community currency packages used for business accounts a while ago. Not sure whether this approach is likely a very good fit to LWN.NET business needs, but double entry bookkeeping has more than one purpose I guess. Those developing CC software tend to prefer this to be Free Software/Open Source as a matter of principle. Money should be accountable to the community which uses it.

E.G.1 CCLite
E.G.2 Pylets

No harm using one of these engines and developing input forms and output reports to match the API. Possibly the Timebanks have similar software, so there might be a few other viable packages out there of a similar nature.

Alternatives

Posted May 8, 2012 23:57 UTC (Tue) by ldo (guest, #40946) [Link]

A quick apt-cache search ledger on my Debian Unstable system turned up some interesting-looking possibilities.

Accounting systems: a rant and a quest

Posted May 9, 2012 0:03 UTC (Wed) by dskoll (subscriber, #1630) [Link] (6 responses)

We use LedgerSMB, but we cheat... our accountant re-enters everything into his proprietary system when it comes time to filing official tax returns.

LedgerSMB has another gotcha: We are on 1.2.x and as far as I can see, there is simply no upgrade path to the current 1.3.x. I've tried the upgrade several times and each time it has failed miserably. Also, 1.3.x relies on PostgreSQL to manage users: The application user is expected to be exactly the same as the database user. I understand the LedgerSMB team's motivation (put all the user management in the database and you can ensure one and only one place for permission checking), but it's a real PITA for us to run that way.

LDAP users?

Posted May 9, 2012 4:38 UTC (Wed) by ringerc (subscriber, #3071) [Link] (4 responses)

PostgreSQL supports getting its user information from an LDAP service, or having the users entirely internal to the DB with no relationship to system users.

If the app provides a basic tool to create/drop/alter Pg users, this should be no hassle at all to manage and no different to using users defined in application tables. I'm guessing they haven't.

LDAP users?

Posted May 9, 2012 13:11 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

Yes, I know that. But just because I want to let people log in to an accounting application, that doesn't mean I trust those same people with the psql command-line. Conflating database users with application users is not a good idea, IMO.

LDAP users?

Posted May 10, 2012 2:29 UTC (Thu) by ringerc (subscriber, #3071) [Link] (2 responses)

Good point. I was assuming they'd moved to a design where all rights and permissions checking was done in the DB, such that a command-line user couldn't do anything more than a GUI user can. That's often done with appropriate trigger functions or where they aren't flexible enough the use of SECURITY DEFINER stored procs + access restricted tables.

If they're using DB-level users but not doing strict access control and checking in the DB, so a user can still wreak havoc with DB command-line access, that's not cool.

LDAP users?

Posted May 10, 2012 16:02 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

Hmm, I don't really know... I haven't been able to upgrade to 1.3. :(

Even if permission-checking is good, you can still do a lot more damage a lot more quickly with psql than the web interface. For example, you might be able to do a mass update in psql in the blink of an eye where the Web interface will slow you down before you can do too much damage. :)

LedgerSMB... GAAAAAHHH!!!

Posted May 10, 2012 21:03 UTC (Thu) by dskoll (subscriber, #1630) [Link]

So I took another crack at upgrading from LedgerSMB 1.2.x to 1.3.16.

Total, utter failure.

The "setup.pl" script keeps asking for a login/password and rejecting whatever I give. Tracing through a hundred twisty perl scripts, all alike, I got nowhere.

I give up. At this point, we're frozen in amber at 1.2.21. My choices now are to do a clean installation of 1.3.16 at the end of the fiscal year and start fresh, pay someone (anyone out there?) to upgrade us, or switch away from LedgerSMB.

Accounting systems: a rant and a quest

Posted May 10, 2012 0:04 UTC (Thu) by glikely (subscriber, #39601) [Link]

I had a really bad experience with the 1.2.x series of LedgerSMB when I was running my business on it about 4 years ago. Invoices couldn't be reprinted accurately if the sales tax rate changed, and it didn't handle foreign currencies well. My accountant really wasn't happy when I couldn't produce an general ledger report and trial balance that added up to the same values. I haven't looked at the 1.3.x series, so things may be better now.

I switched from that to Postbooks which has worked extremely well. I particularly like that the database logic is implemented as Postgresql stored procedures which means it is safe to use other applications to manipulate the data (like to import transactions). I back the whole thing up with a plain-text dump of the database stored in a git tree. Most importantly, I've not had a complaint from my accountant since. :-)

Accounting systems: Grow your own?

Posted May 9, 2012 1:00 UTC (Wed) by drh (guest, #65025) [Link] (3 responses)

The accounting needs of SQLite.org are likely much simpler than those of LWN.net. Nevertheless, it seems worth mentioning that we've gotten along fine here since 1995 using a database with a very simple schema and a handful of CGI scripts written in TCL. This system keeps track of client contact information, invoicing, various bank accounts, payroll and expenses, and then it generates a general ledger, income statement, and balance sheet which we print out and take to our accountant once a year at tax time. The key descriptor of the system is "simple". There are no graphics. Just some <form> and <table> elements mixed with a few SQL statements. The whole thing took about one day to hack together nearly two decades ago, and apart from minor adjustments now and then (ex: conversion from PostgreSQL to SQLite sometime around 2002) it has served us well with a minimum of fuss.

Beware of "shiny". And do not underestimate the power of CGI + scripting language + SQL.

Accounting systems: Grow your own?

Posted May 9, 2012 2:24 UTC (Wed) by piggy (guest, #18693) [Link] (1 responses)

Riffing on this theme, why not throw together a small pool of money and hire someone to deliver the system you need? Publish the result and voila! Scratch a personal itch doesn't have to mean you code it yourself.

Accounting systems: Grow your own?

Posted May 17, 2012 9:09 UTC (Thu) by kragil (guest, #34373) [Link]

Good idea, but who is doing the Kickstarter or Indiegogo for it?

Accounting systems: Grow your own?

Posted May 12, 2012 9:40 UTC (Sat) by juliank (guest, #45896) [Link]

Or you just need to get Linus have to do some accounting; I'm sure he'll write a software then.

Accounting systems: a rant and a quest

Posted May 9, 2012 5:36 UTC (Wed) by jcm (subscriber, #18262) [Link] (9 responses)

Jon, I know it'll do wonders for my image ;) but...let me caution you against going for an entirely free (of charge) solution in the process of going to an Open Source accounting solution. You not only really want an open alternative, but you need to (I would say - but my opinion only) get it from a company that is willing to stand by the numbers through indemnification or at least be accountable (no pun intended). My concern is that otherwise you'll run the risk of getting into hot water later with various end of year filings. So, I wouldn't expect an open solution to necessarily cost less (and in fact, I'd expect it to cost a lot more - simply due to the relatively smaller market for a new offering).

Accounting systems: a rant and a quest

Posted May 10, 2012 8:15 UTC (Thu) by cmccabe (guest, #60281) [Link] (8 responses)

> Jon, I know it'll do wonders for my image ;) but...let me caution you
> against going for an entirely free (of charge) solution in the process of
> going to an Open Source accounting solution. You not only really want an
> open alternative, but you need to (I would say - but my opinion only) get
> it from a company that is willing to stand by the numbers through
> indemnification or at least be accountable (no pun intended). My concern
> is that otherwise you'll run the risk of getting into hot water later with
> various end of year filings. So, I wouldn't expect an open solution to
> necessarily cost less (and in fact, I'd expect it to cost a lot more -
> simply due to the relatively smaller market for a new offering).

Well, if you check out the QuickBooks EULA, you quickly find that it includes this little gem:

> TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
> PASSWARE OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT,
> OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION,
> DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF
> BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE
> OF OR INABILITY TO USE THE SOFTWARE PRODUCT OR THE PROVISION OF OR FAILURE
> TO PROVIDE SUPPORT SERVICES, EVEN IF PASSWARE HAS BEEN ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGES. IN ANY CASE, PASSWARE'S ENTIRE LIABILITY
> UNDER ANY PROVISION OF THIS SLA SHALL BE LIMITED TO THE GREATER OF THE
> AMOUNT ACTUALLY PAID BY YOU FOR THE SOFTWARE PRODUCT OR U.S.$5.00.

So if you paid $50 for the software, that's the exact amount QuickBooks will owe you if it turns out to corrupt your files, cause the IRS to audit you, and kick your dog. See for yourself at http://www.software112.com/products/quickbooks-key+eula.html

The moral of the story is that you don't get enterprise-level support by buying shrink-wrapped software. You get enterprise-level support by paying enterprise-level prices.

Accounting systems: a rant and a quest

Posted May 10, 2012 12:14 UTC (Thu) by ekj (guest, #1524) [Link] (7 responses)

Indeed. And this sort of FUD is depressingly common. You typically don't get a vendor to take responsibility for *anything* other than perhaps the purchase-price of the software, no matter what license you buy.

Even a $10000/year license for Visma Global, will not give you a single cent from Visma if their software causes you to violate some tax-code or other law.

Yet you hear all the time that "you need proprietary software to be safe", when the reality is that paying trough the nose for proprietary stuff guarantees no such things.

Accounting systems: a rant and a quest

Posted May 10, 2012 17:24 UTC (Thu) by jcm (subscriber, #18262) [Link] (6 responses)

Note, I wasn't saying at any point that you need proprietary software, just some commercial entity to take responsibility. I really dislike in the Open Source space how "making money" is equated with "proprietary" (and therefore wrong). The reality is, if you download $whatever version of $foo from git and build it, you can keep all the pieces when it breaks. I truly believe for this kind of stuff, you need to go to a vendor to get a release that has been through QE and at least is backed up with commercial support. Nowhere did I say that means proprietary, unless the idea of going to a vendor is now intrinsically Evil Bad and Wrong :)

Accounting systems: a rant and a quest

Posted May 10, 2012 19:29 UTC (Thu) by ekj (guest, #1524) [Link]

Whereas if you shell out for Quickbooks, when it terminally breaks you get to keep all the pieces, but they may refund you your original purchase-price.

Software-contracts where somebody actually promises to fix things if they break, costs *MUCH* more than off-the-shelf software. Typically orders of magnitude more.

Accounting systems: a rant and a quest

Posted May 13, 2012 18:56 UTC (Sun) by cmccabe (guest, #60281) [Link]

I think I can sort of see the case you're making, although I don't like the way you phrased it.

Accounting and tax software needs to be very bug-free, due to how mission-critical it is for enterprises. Commercial vendors have an incentive to make their software bug-free because otherwise their reputations are tarnished. What kind of similar incentive can we produce for open source developers of accounting and tax software?

If Red Hat or someone else were to offer a commercial support contract for some open source accounting software, Red Hat would have an obvious financial incentive to keep things working. However, support contracts only really make sense for big companies, not for small organizations like LWN.net. This would also tend to drive the developers towards implementing complex features needed by large organizations, not simple things needed by a smaller operation.

Joel Sposky wrote a pretty interesting article about the pricing of software over here: http://www.joelonsoftware.com/articles/CamelsandRubberDuc.... Software offered with a proper support contract clearly falls into what he would call the expensive category.

In the end, I think that we could probably create a good open-source accounting package. It would have to be extensively unit tested, and the development paradigm might have to be a little more restrained than the usual rapid-release strategy. It might also be a good idea for some organization to hold a trademark on the actual name, sort of like how Mozilla holds the trademark to Firefox.

In contrast, I have a hard time imagining open source tax software coming to pass any time soon. It's just not a very rewarding thing to develop-- it doesn't scratch anyone's itch, and the rules change every year in subtle and complex ways. Perhaps the best thing we can hope for is that there will be an open standard for storing tax data. Unfortunately, the IRS's e-file standard seems to fall far short in this regard.

Accounting systems: a rant and a quest

Posted May 17, 2012 4:00 UTC (Thu) by fest3er (guest, #60379) [Link] (3 responses)

Actually, you need to take responsibility for your accounting data yourself. It is inexcusable to blindly enter information into a system and blindly trust the results that come out. And unthinkable to then expect someone else to take the blame. Any good accountant will look at the data in at least three different way to ensure that it is correct: double-entry bookkeeping view, financial accounting view, and financial management view, and in at least three different dimensions, such as by income/expense, by account, and by person. The sums of all dimensions better add up the same. She'll know very quickly whether or not the software is correct.

Money is the lifeblood of every business; without it, the business dies. The purpose of accounting is to know where your money is coming from and where it is going. And, at times, how fast the flow is changing. Satisfying the tax man is secondary.

The basis of any accounting system must be the Generally Accepted Accounting Principles (GAAP). While there are localized variances, GAAP is almost as universally used as is the Uniform Commercial Code (UCC).

I've worked, on and off, for a small accountant for 15 years. He spent the previous 17 years building a fairly complete accounting system (general ledger for client data, time & billing for his work with clients, phone logging, lead tracking, etc.) His programmer essentially wrote 2½ programs a week for 17 years, on average; she did use sound practices, such as code-reuse and good structures. But it's still ISAM-based, business BASIC, one-letter variable names, and almost uncommented (to be expected; disk space was at a premium then: it started on an early BASIC system, moved to a DG NOVA, and finally to Unibasic on SCO UNIX).

If I were to build a small business accounting system, I'd start with his and re-implement it using modern languages and a modern UI. And the first premise of the database system would be as already mentioned: every record inserted must include a record insertion date/time, the record this one retired (or null if it's new), a record retirement date/time, the record that retired this one (or null if it's current) and who did each deed. Nothing is ever deleted from the database or updated in it: 'DELETE' and 'UPDATE' don't exist. Call it 40 bytes per record; in 100M records, that's all of 4GB: mice nuts compared to the bit trail you'd get. And accounting is all about traceability.

Accounting systems: a rant and a quest

Posted May 20, 2012 19:31 UTC (Sun) by renszarv (guest, #84721) [Link] (2 responses)

btw, your requirements are contradicting. If no UPDATE-s are allowed, how/when the 'record retirement date` is modified in that record ? :)

Accounting systems: a rant and a quest

Posted May 20, 2012 21:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

You don't.

Instead you create a _new_ record pointing to the old record as the predecessor. So that all new documents from that point on would use the retiree's record, not the old ones.

Accounting systems: a rant and a quest

Posted May 21, 2012 5:32 UTC (Mon) by jackb (guest, #41909) [Link]

A bitemporal data model works like that. Information is only added to the database, never deleted or changed.

building a nice front end to one of the "enterprise" projects

Posted May 9, 2012 9:23 UTC (Wed) by yodermk (subscriber, #3803) [Link]

I don't currently run a business but may someday so have an interest in seeing this problem solved, and in fact I was thinking about it recently.

Would it be feasible to write a nice front end, probably with PySide and QML or something similar, to the likes of SMBLedger or ApacheOFB? It could come as close as possible to the Quickbooks interface and only provide the functionality needed by small businesses. A script could be provided to set up any necessary server software.

If so, for anyone who has compared these backends, which one would be the best starting point? I may take a look at them myself...

Accounting systems: a rant and a quest

Posted May 9, 2012 11:05 UTC (Wed) by SiliconSlick (guest, #39955) [Link]

Given how incredibly exciting small-business accounting is, it's surprising that so few developers have felt a burning need to scratch that particular itch. There is no accounting for taste, it seems.

:) LOL... well put and nicely said (and vice-versa). :)

SS (with no taste for developing accounting software since running away from it 30 years ago)

Accounting systems: a rant and a quest

Posted May 9, 2012 13:31 UTC (Wed) by stuffa (guest, #74112) [Link] (2 responses)

I understand your quest for Opensource, We took a different direction and selected a cloud based solution. This is working well for us.
Its cheap, doesn't rely on windows, is accessible from anywhere (you are not tied to a particular PC).

Accounting systems: a rant and a quest

Posted May 9, 2012 13:53 UTC (Wed) by gioele (subscriber, #61675) [Link] (1 responses)

> Its cheap, doesn't rely on windows, is accessible from anywhere (you are not tied to a particular PC).

But are you tied to a particular file format? Can you export your data and back it up offline or import into another program?

Accounting systems: a rant and a quest

Posted May 18, 2012 20:25 UTC (Fri) by steffen780 (guest, #68142) [Link]

Even before that, what if the cloud provider goes bust, has some major technical issue, or one of a billion other problems a day before you have to file paperwork with the government to fulfil a deadline that causes serious legal and/or financial fallout if you don't?

Accounting systems: a rant and a quest

Posted May 9, 2012 15:48 UTC (Wed) by FileAwayLtd (guest, #82140) [Link] (3 responses)

Quasar Accounting - the current version is not open source but the previous version (1.4.7) is. We've been using it for about 5 years now, with Postgresql as the back-end (you can use various back-ends).

http://www.linuxcanada.com

(I'm not associated with them).

I have the 1.4.7. code if you cannot find it on their site.

Accounting systems: a rant and a quest

Posted May 9, 2012 18:44 UTC (Wed) by charlieb (guest, #23340) [Link] (2 responses)

> Quasar Accounting

The lack of current entries, and predominance of spam, in their mailing list archives, is not encouraging.

Accounting systems: a rant and a quest

Posted May 10, 2012 0:33 UTC (Thu) by menders (guest, #80486) [Link]

I have searched their website and can not find this mailing list archive you speak of. I could find an ancient archive of their now old and defunct BBS.

Accounting systems: a rant and a quest

Posted May 11, 2012 12:04 UTC (Fri) by FileAwayLtd (guest, #82140) [Link]

Why would you need a lot of current entries in a mature accounting system with good documentation?

What, no request?

Posted May 9, 2012 17:19 UTC (Wed) by man_ls (guest, #15091) [Link]

Somehow I read in the title "a rant and a request"; I thought our esteemed editor had finally swallowed his pride and was coming to the LWN.net community (many surely with similar needs) to ask for help. In the comments there are already many suggestions and a few home-grown solutions. In the spirit if NIH syndrome fans I would think that there is a scratch to itch, there is a business need and the will to solve it. Bigger projects have grown from less promising prospects.

Extra points for doing it the Unix way: building a basic text-based accounting system first, then layering a ruleset manager on it (which can be fed with byzantine tax system changes) and finally communicating with a GUI or a web application. If I read the comments right, the basic framework might be reused from one of the "ledger" packages.

Don't rule out the big players prematurely (OpenERP etc.)

Posted May 9, 2012 22:32 UTC (Wed) by debacle (subscriber, #7114) [Link] (2 responses)

I'm not sure, whether you should rule out the "big" players. I'm aware of a small software company (around five or six people) using a hosted version of OpenERP happily. Just because the software targets much larger enterprises, it doesn't mean it's not efficient for smaller ones. Oh, and it's written in Python :~)

Don't rule out the big players prematurely (OpenERP etc.)

Posted May 10, 2012 8:57 UTC (Thu) by Seegras (guest, #20463) [Link]

We're running OpenERP for a small business.

And we're moderately content with it. It has quirks, and it's often complicated.

What I really don't like are the upgrades. As it happens, OpenERP is a collection of plugins. Every plugin defines the database-fields in it's forms, which are inserted/generated upon installation of the plugin. Which means dozens of plugins modify the same tables.

This makes migrating, even to a never version of openerp, really unpleasant.

Don't rule out the big players prematurely (OpenERP etc.)

Posted May 10, 2012 15:14 UTC (Thu) by jebba (guest, #4439) [Link]

We use OpenERP and are happy with it. LWN could use it and just not install the warehouse, manufacturing and other modules it doesn't need. Just use the accounting module and keep it minimal.

OpenERP is python/postgres too....

Question about the Quickbooks upgrade

Posted May 10, 2012 2:51 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]

Have you asked Intuit what happens when you've upgraded to the $2400 version, and then you hit, say, 145,000 items? :-/

Accounting systems: a rant and a quest

Posted May 10, 2012 9:02 UTC (Thu) by tonyblackwell (guest, #43641) [Link]

Our small business was using QB0809 (Australia), our only MS enviro product, until last week when 2 different accountants complained they had put all their corrections into the accountant copy we sent them, then noticed they were unable to either save these or generate a return accountant file to send back. One of them discovered in discussion with Reckon that this was a well-known (to Reckon) bug in that version of QB and couldn't be fixed, except by upgrade...

To their credit, QB are sending us the next year's version, but 2 accounting firms have wasted a lot trying to debug this, with its pass-on effect.

I'm a _very_ enthusiastic supporter of the hunt for a good open-source alternative.

Accounting systems: a rant and a quest

Posted May 10, 2012 9:55 UTC (Thu) by ceplm (subscriber, #41334) [Link]

GnuCash after its guille-inflicted near death experience (how many volunteers you find maintaining Scheme-based accounting package? The answer has been proven to be zero) has now Python API and some efforts to include some small-business oriented features. Certainly from all options discussed it seems to me the most realistic option, much better than starting with awk scripts and PostgreSQL.

Accounting systems: a rant and a quest

Posted May 10, 2012 15:48 UTC (Thu) by cdmiller (guest, #2813) [Link]

Ironic to see this on the same page as "Who owns your data?"...

Accounting systems: a rant and a quest

Posted May 12, 2012 10:25 UTC (Sat) by yoe (guest, #25743) [Link] (1 responses)

I run a small business too. My solution to this problem is simple: text files, email software, and a very good accountant.

Yes, that probably means we pay them a little more for data entry. But I'd rather pay an accountant whom I trust a little something more than that I'd pay some money to a piece of software that might have this kind of sillyness in it.

Let the accountant deal with that.

Accounting systems: a rant and a quest

Posted May 30, 2012 9:45 UTC (Wed) by cthart (guest, #4457) [Link]

I went down the same route: I created a shared folder in a DropBox account and gave my accountant full access to that.

* I scan all received documents (the ones that don't already come electronically as PDF).

* Periodically I export my bank statement from my online banking.

My accountant's hourly rate is less than mine so I let her do all the work -- including submissions to the tax office.

Accounting systems: a rant and a quest

Posted May 12, 2012 16:53 UTC (Sat) by jengelh (guest, #33263) [Link]

By now, Villariba would have already silently patched the JNZ/JZ with a JMP/NOP.

Accounting systems: a rant and a quest

Posted May 15, 2012 14:17 UTC (Tue) by drh (guest, #65025) [Link]

Jonathan, can you suggest a list of requirements that an accounting system would need to fulfill in order to be useful to LWN?

Accounting systems: a rant and a quest

Posted May 17, 2012 1:52 UTC (Thu) by welinder (guest, #4699) [Link]

Intuit's tax software has at least one similar gotcha: no number
used -- including in temporary calculations -- can exceed 2^31-1 cents.
Calculations just aren't right, if that happens.

Now if your income is anywhere near 2^31-1 cents, you can afford the
business version. But there are other ways to get there without being
someone's rich uncle.

Anyway, the short term solution was: (1) return said tax program
to Costco, and (2) sign up for a free trial version of their
professional tax software -- full version preloaded with $100
which, roughly, is fees for about five tax returns. (And (3) get
a tax accountant who knows what he's doing.)

There might be a similar trial program for you to use.

Accounting systems: a rant and a quest

Posted May 30, 2012 21:53 UTC (Wed) by tuxino (guest, #84530) [Link] (6 responses)

Very interesting topic.

apt-cache search ledger gives some interesting strings, which I've not seen mentioned so far.

frontaccounting
hledger
sql-ledger

Frontaccounting doesn't look bad to my (very) untrained eye.
From the FAQ:
"FA is PHP 4 and PHP 5 compatible and should run on MySQL 4.0 - 5.X.X Server"
They've got an online demo too,.

hledger looks bare but its main disadvantage IMHO is its data format (formatted text files, IIUC) and the fact that it's written in haskell.

sql-ledger seems quite featureful. Postgresql and perl are a plus to my eyes, but obviously that's irrelevant :)

Just my 2 cents.

Accounting systems: a rant and a quest

Posted May 31, 2012 0:29 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (5 responses)

> hledger looks bare but its main disadvantage IMHO is its data format (formatted text files, IIUC) and the fact that it's written in haskell.

If those are the main _dis_advantages, it must be very nearly perfect. You're essentially saying that the disadvantages are that its storage is resilient and future-proof and that it's written in a language which is resistant against programming errors.

Personally, I'd list the user interface and security issues as the disadvantages, both due to its nature as an HTML-based webapp.

Accounting systems: a rant and a quest

Posted May 31, 2012 7:17 UTC (Thu) by tuxino (guest, #84530) [Link] (2 responses)

I forgot to put a simley somewhere...

Haskell is a problem _for me_ simply because I don't know it :-)
Seriously, though, I was thinking about the popularity of the language the ERP is written in and the ease of finding a developer to customize and maintain it.
This is probably a moot point, though, as the software publisher would probably be glad to receive money for this type of work :)

Text files don't seem to me like the best storage format for accounting data. RDBMS with ACID compliance where written for a reason, weren't they ? :)

Accounting systems: a rant and a quest

Posted May 31, 2012 15:09 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

> Text files don't seem to me like the best storage format for accounting data. RDBMS with ACID compliance where written for a reason, weren't they ? :)

Well, I was thinking that it's a lot easier to recover data from plain text file if something happens to go wrong. However, ACID compliance is also important, particularly if there are multiple users. Perhaps an RDBMS for active storage, and plain text for backups?

Accounting systems: a rant and a quest

Posted Jun 1, 2012 12:04 UTC (Fri) by tuxino (guest, #84530) [Link]

That's what happens, in a way, when you schedule a database dump as part of a backup strategy.

Oh, and let's not forget things like foreign key constraints, stored procedures, views and other goodies, which are quite helpful when implementing accounting systems or any other similar application.

Accounting systems: a rant and a quest

Posted May 31, 2012 19:42 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

The web interface is optional. It is written using Yesod as well, so any security issue that couldn't be fixed by sticking a .htaccess-obeying server in front of it would surprise me (compile time XSS security, CSRF for free, compile-checked links, etc.). There is also the command line interface (which I use with Vim for editing). It's also data-file compatible with ledger itself.

Accounting systems: a rant and a quest

Posted May 31, 2012 20:13 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> The web interface is optional.

Oh, that's good. I saw the demo on their web site and assumed that HTML was the primary/only interface.

> It's also data-file compatible with ledger itself.

And here is a good reason for using plain text files: an RDBMS storage backend would have been unlikely to interoperate with other programs. Note that it couldn't be shared, of course, but the programs would need to agree on a precise database schema where text files, given an extensible syntax, offer more flexibility.

Accounting systems: a rant and a quest

Posted Aug 19, 2012 23:53 UTC (Sun) by pyrite (guest, #86316) [Link]

Here is a short and sweet awk script some one wrote. You could modify it, for instance if you wanted the ledger in detail rather than the ledger balances.

The web page is:https://bbs.archlinux.org/viewtopic.php?id=106721

The output is just the trial balance for the accounts. So in the example output below the newt worth is q/Opening Balances: + i/ accounts + e/ accounts. If you wanted to clear the income and expenses to q/Opening Balances: you could just add the journal entries. Any how you could use the simplicity to develop your own.

$ bal ledger.sample
a/Checking: 15.00
a/Checking*: -40.00
a/Savings: 620.00
e/Food: 85.00
i/Paycheck: -120.00
l/Credit Card: -35.00
q/Opening Balances: -525.00

Also, Awk scrips could be a great way to transfer your stuff to quicken's software in column separated variable format.

Accounting systems: a rant and a quest

Posted May 18, 2014 8:35 UTC (Sun) by beemsoft (guest, #97128) [Link]

How is the quest going? Maybe the following open source project is interesting for you: TechyTax is a web-based tax tool for small companies. It calculates VAT returns and generates fiscal overviews. No accounting knowledge is required. The goal of this project is to make the tax process as easy as possible for small companies.

Accounting systems: a rant and a quest

Posted May 6, 2015 1:41 UTC (Wed) by jlinkels (guest, #92141) [Link] (1 responses)

I wonder what the current status is for your search for an accounting system.

I can recommend the accounting program *I* use because that is the best. Seriously, But of course I say that with reason.

I have been trying OpenErp, used it for 2 years. It has a number of very serious bugs. But bugs in provious versions are not confirmed anymore. Only in the current version. As you know, upgrading in OpenERP is a nightmare or a paid job. So if you stick with the old version there is no bug fixing. If you go through the effort of upgrading you are replacing known bugs by unknown bugs. And by the time you learned the new bugs, the next version is current and your new bugs are too old to be fixed. WIth serious errors I mean a balance which is unbalanced, etc. If the tax Dept. ever decides to audit my books over those years I am bankrupt.

SQL-ledger is more the spirit of real FOSS. But it doesn't do inventory. And I am not sure about multi-currency. Anyway it felt rather basic and lacked some functions I needed.

XTuple is a nightmare. Even the simplest things are extremely complicated. Correcting a wrong booking is so complicated you can't correct it without making other errors which have to be corrected, which causes you to make errors... Community support is almost non-existent. Very bad, everything is coded in PostgreSQL. Restoring a backup version takes 15 minutes on an i7 machine.

Then I found FrontAccounting. It comes close to Quickbooks in functionality. It uses MySQL. It is fairly simple. You can understand and hack the database. 30 tables or so. It has an undo function which voids a transaction, but leaves a trail. It has inventory and multi-currency. It has good reporting. It is flexible. Multi-language. Community support is good. Making a test copy is easy. Restoring previous versions or previous data is a breeze.

Frontaccounting is close to perfect for any small business.

jlinkels

Accounting systems: a rant and a quest

Posted Apr 21, 2016 7:06 UTC (Thu) by Ravioli (guest, #108349) [Link]

Here is an other idea.

Open a new set of books! Close your books at a year or quarter and carry forward the balances. Then you don't have a limit any more.

This is what people did in the time of paper journals and ledgers. Your accountant knows how to do it! The beauty is you and your accountant do not have to change software.

You might do this retro-actively at a previous date. Separate the transactions by that date. Clear all expenses and revenues to retained earnings, capital account. Carry all the balances forward to a new set of books. Then add all the journal transactions at that date or after.

I don't know why your accountant did not suggest it, maybe to young?