Accounting Systems on Linux?

cuebei asks: "OK, Slashdotters - let's talk accounting systems for small-mid sized businesses. With the popularity of Linux servers running various e-business services such as web, directory, mail, commerce, etc, it only makes sense for Linux to become a more mainstream platform in the business world. One of the areas where I can foresee Linux being used extensively is in the area of accounting. Linux is both reliable and scalable, two key requirements for any accounting package. So who uses Linux for HR/Accounting? What options are out there? Open-source or commercial? If you were starting your own business and standardized on Linux as a platform, what accounting package would you use and why?"

SQL Ledger

GPL'd, web-based, double entry accounting system
for businesses. Full internationalization support
for several languages, currencies and chart of
accounts, written in Perl. Good stuff.
Webpage here [sql-ledger.com]

GNUCash is *not* a business accounting system.
It is a *personal* accounting system.

Re:SQL Ledger

Funny, I just had one of my clients want to test this out, so he gave me one of his servers to set this up on. He wanted me to install both SQL-Ledger [sql-ledger.com] and NOLA [noguska.com]. Preliminary results as far as a sysadmin is concerned:

SQL-Ledger: Rocks. VERY easy to set up, documentation is complete, and from what my client tells me, theres more modules available than most of the commercial stuff he's looked at. Its running on a Debian Potato system, and almost everything is stock (read: stable). All I added was a source install of pgsql, and added the couple of Perl modules via the CPAN perl shell. I think I had the entire thing runnin in less than an hour, from poppin in the 2.2r4 cd to firing up Moz on my other box.

NOLA: An absolute bitch to set up. Not only does all the documentation end in .doc (with .pdf's on the web...no text/html that I could find), but its EXTREMELY incomplete. It doesnt say what needs to be compiled with PHP (thats my biggest complaint - took me about 6 recompiles to figure out wtf it wanted in PHP). It dynamically generates most of its buttons via libgd, and they dont even look that good. Its got a lot of wizbang stuff, but they haven't worked on the actual use of it much. Not to mention it suggests using the absolute latest libs for things. I'd rather a production system not rely on the bleeding edge. I suggest staying away from it for a while till it matures.

Welp, there's my $0.02. Like I said..I'm the admin who's settin it all up...I haven't really used either of them, but a lot of times you can tell how good of a project it is by how easy it is to set up (ie: how good the documentation is).

Re:SQL Ledger

Disclaimer: I work for Noguska, the main company behind NOLA.

Installing solely from the source tarball is currently much more difficult than need be. We do however provide an iso image file in our downloads section with a complete installer for Apache/PHP/MySQL for both Windows and Linux/Unix servers.

Also, our UI is currently undergoing extensive changes, and things are changing nightly.

Thanks for checking it out!

Ease of Installation is important

I've not tried installing NOLA, but keep SQL-Ledger around. I'd say you're bang-on in assessing that it's important to have the technology be readily installed.

A prime problem with GnuCash vis-a-vis trying to get the "bleeding edge" functionality is that it is an absolute pain to get compiled. The functionality may be worth it, but if it's daunting to build, that's a problem.

In exactly the same manner, there are all sorts of projects out there to build some really cool JavaEnterprize-Foo-Beans- Coffee-Espresso-Transactional- EE goodness; if it takes someone who's an expert in all of:

• Apache;
  
• Some Server Extension;
  
• Some Java Framework Atop a Server Extension;
  
• Some Application Framework that doesn't do squat until all the above pieces are running perfectly along with an interface to an RDBMS
  

Excuse me if I don't jump up and down cheering at the vast complexity of this.

In contrast, SQL-Ledger is indeed quite straightforward to set up. A bit more manually-involved than I'd like, but certainly not badly so.

use what you are now - AccPac on Linux

I don't live in the US, and I never will. But from what I have heard, AccPac performs the same role (ubiquitous SME accounting software) that MYOB does in my own beautiful country, Australia.

AccPac have a Linux port. [accpac.com]
* It seems to be software you can get competant accountant with many years experience using, minimising training costs and staff overtime while necessary to move to a new system
* It has a fairly good reputation and large amounts of existing systems
* it can import data in a wide variety of formats from its competitors.

It's not Open Source, but it might be the best tool for the job, which should be any competant technical persons criteria for selecting software.

SQL Ledger and Security.

I've been using and localizing sql-ledger for a while now, and it's definitely a very extensible and easy-to-use package.

However, please Do Not use it as a remote administration / accounting tool that serves over the internet. Its place is inside the firewall.

The reasons is that it doesn't have a session control-related audits. Any user that types in http://hostname/sql-ledger/ir.pl?login=admin&path= bin/mozilla could get into the syste under the name 'admin', given the attacker knows the username "admin" (not hard), and regardless of that account's permission. indeed the same scheme is workable on any other .pl program.

You can apply This patch [autrijus.org] to fix it, if you don't worry about shared proxies.

And yes, this patch has been sent to the author. His comment was more along the line of accountants are not script kiddies, so we don't need to worry too much. That is probably reasonable, too.

Re:SQL Ledger and Security.

His comment was more along the line of accountants are not script kiddies, so we don't need to worry too much. That is probably reasonable, too.

Sorry, but I have to disagree. Accountants are worse than script kiddies. When they go bad they know exactly what they're looking for, and they know how to manipulate the data to hide any unusual transactions. Maybe the mythical bad accountant doesn't personally have the skillz to crack a system, but -- I assure you -- they are more than capable of finding a partner to help them.

I've been doing SAP R/3 security for a handful of years, and I could tell stories that would make every CFO in the world crap their pants.

You have to realize that we're talking about being able to manipulate real money. You can't treat it like monopoly money because it's just a bunch of numbers on a UI. You need to control (and be able to audit) access to an enterprise accounting system just like you would protect and audit access to a giant pile of dollar bills that is equivalent to your company's net worth. You've also got to realize that admin-style access to an accounting system means that you can make changes to things that happened in the past. So I could go back two months ago and insert a bogus purchase order for $99.00 (or any other small amount that misses the executive-approval-radar). Then, this month, I could pay it -- to that anonymous bank account I have. I could do this over and over with multiple fake purchase orders for months and months. And since no one could audit the transactions, they would only know that they were missing an ass-load of $99.00 transactions. (The real-world implementation is a bit more complicated, but you get the idea).

If your company has $500,000 of revenue a year, and the two accounting people are personal friends, you probably don't need to worry about embezzelment, fraud, fake purchase orders, etc. (I personally would worry about them, but I'm a paranoid security guy).

If your company is pulling in a few million dollars a year, and you hire random accounting people then, yes, you need to be able to audit their activities.

Accounting is not the driving software package!

In my experience (manufacturing, specifcially chemcial manufacturing), the accounting software is almost irrelevant. The trick is finding a suitable manufacturing package and then you just use whatever accounting package that works with it.

That being said I'd be ecstatic if there was good process manufacturing software available for Linux! But the gamut of features would be rather daunting- solid flexible modules for inventory with lot tracking, formulations, hazmat and environmental reporting as well as MSDS and labelling, production BOM, scheduling, heck throw in HR...and of course the mentioned accounting package.

Heh, give me all of this and our company switches to Linux!

Re:Accounting is not the driving software package!

I have to agree wholeheartedly with that comment. Having worked at a good sized manufacturing opperation (in the IT Group), I know enough to agree, also enough to know such a system is terribly complicated to implement, unless you have a good background in an existing application. We ran our system on an AS/400 using MAPICS. Do you have any idea what companies what pay for this stuff? It is insane! It is easy to get huge amounts of money allocated to an upgrade, because the software RUNS the business.

Seems to me like a webservices core may be able to be developed, which serves extermal user iterface modules. Maybe J2EE core (running in JBOSS), webservices exposed through Apache SOAP. You can then write interfaces in many different languages in different user interface, FAT GUI, thin jsp/php/perl. Ahh, I have real stuff to work on. Don't have time to keep thinking and rambling on about this.

-Pete

Accounting and HR on Linux? Yikes.

It might just be me, but in my former experience being a SysAdmin for several junior oil companies, one thing really stood out in the IT and infrastructure areas: These people were extra conservative.

Whereas the exploration group was running on really nice (for the time) new SGI machines, the production group was being more reserved with Sparc/SUN solutions and the accounting department was positively in the dark ages with an old AS/400 mainframe. It was considered quite radical when they migrated to a bunch of AIX boxes and they were terrified to do it.

Don't misunderstand me, I'd love to see the adoption of linux and open-source solutions in this arena, but I feel that this is likely an area that will meet with substantial resistance.

Web-based Accounting Packages

Lacking any traditional desktop software packages, you could always use web-based commercial products like QuickBooks for the Web [quickbooks.com] or Oracle Small Business Suite [oraclesmallbusiness.com].

BillMax

Our company uses BillMax, but my personal view is that the system was cobbled together without much thought on scalability and is missing a lot of features. We are currently porting the system over to an in-house PHP application.

I suggest staying away from BillMax unless you really want to adapt your company to it instead of the other way around (as it should be)

Anonymous for a reason.

Go all the way with ERP

An "accounting" package is not enough these days. Lets face it, developing relationships with customers is what it's all about. Which means that getting information in and out of your systems in the quickest possible manner is what will win in the face of competition. Enterprise Resource Planning systems from the likes of SAP and Oracle are what give big business the edge. Sure you don't have $250K to spend on solutions from these guys but Appgen [appgen.com], Compiere [compiere.org], and GNU Enterprise [gnuenterprise.org] are bringing these kind of systems to the masses. The most promising at the moment seems to be Compiere but it does require some up-front costs - (nothing a small business could'nt handle if they were planning on a Windows deployment anyway). Check them out!

Compliance

I know that there are several accounting packages out there that support Linux (Computron being one) but they are mostly expensive.

The one problem with an open-source accounting package is that accounting standards are constantly changing and the software would often have to be changed to reflect new standards. Anyone working on such a project would have to be well-versed in each of the new SFAS (Statements of Financial Accounting Standards) as they come out. That's not a fun project for a CPA let alone a layperson.

What about SAP ?

mySAP has been running on [sap.com]
Linux for quite some time now.
But perhaps that's nothing for small businesses ;-).

Re:What about SAP ?

Yes thats correct but you CANNOT compare SAP to open source - it runs on linux because they promote it as multi platform but it is so commercially protected and copyrighted that never in a million years could it be open source.

We are in phase 2 of an SAP Enterprise Implementations and FI, HR and CRM modules live, it's cost us approx $21million AU to get to this point and we run everything on SCO UNIX for stability - im sorry guys never in a million years would a company spend 17-20 million and then put it all on Linux to save some money.

HR / Corp Finance are governance and control systems and as such they are not the sort of thing a large corporate would ever consider replacing with open source products - even less likely when you consider the fights, schisms and almost religious wars fought amongst the cogniscenti. Companies need legally to have stable systems that work in these areas and a clear and responsible vendor who owns the system (someone to sue if it all goes down).

The area open source can thrive in is Small Business/ Home office - but i warn you that it means developing open source software for a windows platform as well as linux as you cannot simply expect everyone to use linux (lets be realistic here ok !)

SAP-DB as DBMS

I've pointed it out several times, and apparently those that decide what stories are "interesting" consisidered it not to be of any interest.

The one problem with SAP-DB at this point, from the "can we make it ubiquitous" perspective, is that it's a real pain to compile.

It was coded on mainframes, and the suite of compilation tools are based on that approach. Thus the code base (and compile process) is "cryptic upper-case 8 character names everywhere."

It's a desparate pain to try to compile it, so it has not quickly moved towards being ubiquitously available. Red Hat doesn't include it in trivially-installable manner in the manner of MySQL or PostgreSQL. Debian folk can't do apt-get install sapdb .

Give it some more time, and get some more public input, and it'll get more attention.

Of course, that would merely bring us to the point where it would start being an interesting "data storage" substrate for an accounting application. Then comes the 'real" work of determining what tables, fields, relationships, and such exist, and how to manage UIs...

KBooks

I'm building an application to work like quickbooks (for kde, as if you couldn't guess). I probably shouldn't post this because its completely unusable and I don't want to give anyone the wrong impression. :) But its on topic, and I figure its a good place to beg for helpers. If you'd like to help me, I'll hook you up with the GPL'd source when you drop me an email. Especially anyone that has the gumption to maintain the sourceforge front-end.

Nathan.

Ease-of-use!

One very very important thing that commercial vendors "get" is the fact that a user of such a package is probably NOT accountant, and needs extensive hand-holding when dealing with accounting matters which often have legal implications.

Commercial packages understand this. QB will offer to set up a chart of accounts based on 'interview'. QB will warn you if you are entering things that don't make sense from accounting standpoint.

Writing a ledger app is very easy. Writing an easy-to-use app which provides assistance at every step of the way is not.

This is probably the only case where I think that hand-holding is essential for a product, and why QB is still the only commercial software I use now.

Actually, now that I have acquired more familiarity with accounting concepts, I may migrate to SQL-Ledger, however, these are things that matter for me:

a) Payroll. Its a real pain to compute all the various taxes by hand. Its a real pain to track all changes to tax law for your state to be in full compliance. Now, if sql-ledger guys wanted to do payroll, they'd need to track law changes across all 50 states. Somehow, I don't think it'll ever happen.

b) Compliance (which relates to payroll). Certain reports (941,W2,940, state forms,etc) have to be _right_. Most of them are payroll-tax-related. The penalties are severe and "your honour/officer, my linux software made a mistake" does not cut it.

My Thoughts

If you were starting your own business and standardized on Linux as a platform, what accounting package would you use and why?

You want my honest opinion? (And I know I'm going to get flamed for saying this.) I wouldn't use Linux at all.

Don't get me wrong--I'm not anti-Linux by any means. Linux remains an important learning tool for CompSci students and others interested in learning about hacking together an operation system from scratch. But I can't recommend Linux for business use.

Here's my experience. I run a fairly successful business with a mid-sized accounting department. My employees have years of experience with Windows and Windows-based accounting software. It would simply not make sense to re-train them to use Linux.

The same goes for someone starting a business. Don't ignore basic business sense. There are more potential employees out there who are already trained with Windows. If you do decide to go with Linux, whether out of short-sighted greed or out of the desire to support some vaguely defined set of principles, prepare to spend righteously on your training budget. Linux still has a long ways to go, as far as usability.

--
I support a US first strike [slashdot.org]

The problem open-source accounting apps.

There are a couple of open source apps on slashdot, and Linux already runs commercial db products such as those based on Oracle,DB2 or Progress. The problem for an open source project is that every country has different mandatory and/or statutory accounting rules that need to be followed, so in order to gain the cross-national critical mass that an open source accounting project would need, it would have to recruit experienced accountancy/ERP/CRM programmers from a multitude of different countries, with a project leader from each country assuring that his/her countries requirements are not ignored. This could be the biggest sourceforge project of all time!

Appgen for Linux

DISCLAIMER: I'm not trying to sell this program, just sharing info on a product I am currently working with.

I've been setting up Appgen's beancounter software. Can't say much about it, because I'm currently installing, importing files, and configuring it (I'm working on a client/server version), but the client can run on Win**, Mac, Linux, and Unix (*BSD, Solaris, SCO. YMMV). The server program runs on *nix (even on things like AIX, RS/6000, AT&T, and NCR) and NT/2000. If you want to run it just on one workstation, you can do that too. The Linux server program is not the prettiest thing (vt100 based), but it takes up very little of your precious resources. The Linux client program for KDE and Gnome is *VERY* nice looking and easy to work with (though I don't know squat about accounting). It could convince people that Linux might just have a place on a non-tech's desktop. I was impressed and I'm not very easily impressed.

It's not open source in the GNU sense, but it does come with the full sources and a C tool kit. I didn't have to sign an NDA, so make of it what you will.

Check out http://www.appgen.com. They're a *very* Linux friendly company and actually have tech support that doesn't freak out when you say ,"Linux".

btw, It's not nearly as expensive as some beancounter programs I've seen out there.

Spend the Money

I spent a lot of time last year looking for open source accounting software. I'm not happy about it, but I would not recommend open source enterprise accounting to anyone who wants to keep their job/business.

Cost: Yes, commercial accounting systems are incredibly expensive. Unfortunately, fucking up your financials is far, far more expensive than investing money in good, supported software. Call a few lawyers and accountings who do auditing and ask for quotes on hourly rates if you're not sure. Bad accounting will ruin a business very, very quickly. [cbsnews.com]

Reliability: I believe in the basic cathedral/bazaar theory, but there just aren't enough people writing and using open source enterprise accounting packages for the theory to apply. Unless there are tens of thousands of users, I have to assume that there are bugs in the system and I don't know where they are. See costs, above.

Personnel: if I need to hire someone from a temp agency to sit at a workstation and do AR for a few days, I don't want to spend half the time I'm paying an outrageous fee training them on an obscure system or how to use their damn operating system. If I need to have someone set up the system (as I am not an accountant), and pay truly outrageous amounts for their time, I sure don't want to spend thousands of dollars getting them familiarized with the system. Especially when they will still be punting on decisions that can affect the system years later.

Everything that I've said isn't true if there's an open source solution that becomes widely used...but accounting is really the last area of your business where you want to be on the bleeding edge of software development. In other areas, the bleeding edge might give you a competitive advantage, but in accounting, you will just plain bleed.

Hansa

You may want to take a look at Hansa Financials [212.247.196.3], which is now available on Linux. We were looking at it a few years ago as a back-end to integrate with an e-commerc product (never happened).

The nice parts are that the system has a documented client/server protocol (which they call "Open TCP/IP" for no good reason). Can run on Windows, Mac and Linux. Fairly sensible licensing, from memory. Nice people.

From my limited experience (I'm no accountant), it did what you'd expect, but you saw a lot more of the database directly than you do with Sage Line 50 (the other package I know a bit about).

WyattERP

Check out the WyattERP [wyatt-erp.com] project. It is an Open Source ERP for Linux. There is already at least one medium-sized company that runs nothing but WyattERP for all its needs - from the receptionist to invoicing to HR.

Finally, a Slashdot topic I know too much about

I am a CPA in private practice, and for many years I sold accounting software to small and medium sized businesses. At the risk of trolling for flames, I would have to STRONGLY suggest that you not use Linux for accounting in a small to medium sized business environment. (Note: This is defined a company up to $50,000,000 U.S. in revenue) Why?

1. Unless you are blessed with outside accountants like me who read Slashdot and know the difference between Debian and Mandrake, your choice may create significant problems at month/year end when one of my many slightly to nearmost completely computer illiterate colleagues tries to either download/extract your data or wants you to generate a file that to import into either Excel or their audit/trial balance package. Reason: 99.9999% of tax programs/CPA audit software/CPA trial balance software is written in Windows, and all of it takes an Excel file. (Hint: Not being able to do this quickly/easily = higher costs (annually)).

2. Your CFO/controller will have a lot easier time finding people who can work in the Windows environment to do the basic grunt work of entering invoices, bills, and time so the system can print checks (including your own paycheck). In some 15 years in public accounting, highly computer literate, easily trained, low cost clerks are about as easy to find as naturally occurring penguins in the Sahara. Not everybody runs (or wants to run Linux). Most everybody knows Windows, and your clerks will also know some Excel and at least one or two Windows accounting packages.

3. As much value as I see in open source, I would have a very hard time accepting an open source accounting solution as a CPA auditing a set of books. Unless the company is one of the Generals (Foods, Tire, Motors) or equivalent and possesses the internal programming staff and the full time accounting staff to verify that the stuff works right, it's not worth the risk to be a beta site and discover the bugs. Folks, were talking about real money here, and most of my colleagues would be real skittish about any system that "somebody downloaded from the Internet" (It's bad enough to do that with established, old-line accounting sofware companies, and I've got the scars to prove it.) And if you can't convince us that the books aren't bogus (intentionally or otherwise), good luck with the banker.

In short, yes, accountants are conservative and prefer things that we KNOW will work consistently and correctly all of the time. We also like things that have a low total cost of ownership, and unfortunately, Linux and accounting packages don't have it right now. My "as close as I'm gonna get to a professional recommendation without sending a bill" is live with an off-the-shelf, low cost, Windows (there, I've said it) package such as DacEasy, Best BusinessWorks, or Peachtree. Just promise me no QuickBooks, OK?

Accounting's only part of it - you need middleware

As others have pointed out, SQL ledger is really quite nice but you need to be able to "plug it in" to the other business applications that are being used.

So you either write SQL ledger modules for *everything* or you use some sort of middleware. I have a short document which describes why you need middleware:
http://www.yelm.freeserve.co.uk/middleware/

There's lots of very expensive and proprietary middleware systems from such companies as IBM and WebMethods. Something open would be handy.