Riverbend Community Math Center - Dean Serenevy
We are a US not-for-profit (http://riverbendmath.org/) using SQL-Ledger and LedgerSMB since 2006 (I'm not sure exactly when we made the switch). We are a small organization: ~15 part-time employees; ~$150,000 annual revenues; 2 users of the ledger. We are still using 1.2.x because my trial transition to 1.3.x did not work out as smoothly as I had hoped. Thus, I have put the transition on hold until I can give it a few days attention. As an organization we believe in and use open source software almost entirely.
My wife and I had been using GnuCash for our personal finances, but when we started our Math Center in 2006 we went looking for something that would be able to grow with our organization. We chose LedgerSMB because it was open source, was an advanced "next level" accounting system, and used technologies I was familiar with (Perl, LaTeX).
We still only use only a portion of the system's functionality, but the list steadily grows each year. We are currently using:
- recurring transactions,
- (individual) check printing,
- Sales Orders + Invoicing (services only).
- We make heavy use of "Projects" (about 40 projects in two "levels": "Category - Subcategory") and
- some use of "Departments" ("restricted" and "unrestricted" funds - required tracking for non-profits).
Our use of projects has required that I write some separate perl scripts to generate my own Income Statements (by directly reading from DB). Additionally, we maintain 9 simple local patches on the core system which I consider a great feature of LedgerSMB (these local patches include: require non-blank project before posting; misc UI tweaks for our work flow; alter some form defaults; alter latex compilation; ...). Amazingly, I do not recall any occasion where an upgrade of LedgerSMB has broken our patches (of course, I expect that v1.3 will require reworking most of them).
Our auditor was impressed by the system and considered recommending it to other businesses that he knew of - though I did feel the need to warn him that setting up and maintaining the system required someone comfortable with at least some level of system administration.