I started using SQL-Ledger (SL) since the start of this business in 2001, and for the first 4 years as a service business, I had used only SL’s Account Receivable (AR) and Account Payable (AP) modules for time billings and payments. Then from 2005 and on, I increasingly utilized SL’s Inventory Control (IC) and its other modules as the business begun to take on inventories and employees. So I have been a SL user for 13 years, and in the community for about just as long. Couple months ago, I had received a message from a SL forum users asking for my thought on SL; hence, the reason for this writeup.
The latest release of SL included about 20 plus modules and I have only extensive experience with these: AR, AP, Customers, Vendors, Cash, HR, Order Entry, Shipping, GL, Goods & Services (IC), and Reports. The rest of the modules I have either light use or zero experience. The below are some of the pros and cons of SL from my experience. BTW, my experience with the paid support was good and the response was within 24 hours.
- Web base, free open source, has API, and allows code customization.
- Free (users forum) and paid supports available.
- Paid support cost is reasonable and it comes with documentation.
- Running on Postgresql is a plus as we were able to setup a replication cluster between the online production and SL systems via Slony to pass customer data, sales order, sale invoice, and on-hand inventory, real-time. Looking back the replication cluster was implemented in 2009 and it had been stable and rock solid.
- The LaTex PDF invoice is awesome and we were able to setup paperless invoice for our customers.
- Its database schema is fairly simple and easy to understand. We were able to connect it to Endicia and Fedex Ship Manage and offer scan and print shipping label for both the domestic and international shipments with all the required custom forms.
- The web base system allows our staffs to access SL for supply chain management remotely.
- Definitely streamlined our online retail business.
- Single developer project verses a collaboration of developers.
- Not very active user community, average response time, not a lot of users helping user, but the developer do step in.
- No work flow in the documentation (Version 2.4).
- It is not dummy proofed so you need to implement good work flow and employees training. For example, you would lose an invoice if you had created it from a sales order and forgot to post it before getting side tracked by a phone call.
- For a non-technical/accounting background user, the chance of a successful implementation without paid support is below average.
- It is not bugs free and for example it is terrible in handling reverse invoice on return as it will adjust the purchase, COGS, and sales accounts incorrectly. But there are workarounds for these issues.
- The HR/Payroll module felt incomplete, but outsourcing payroll to ADP and entering the payroll GL entries from the ADP reports was just as easy. Plus the ADP system can fill out those quarterly tax forms.
- Reconciliation is a tedious process so it gets time consuming as your business growth.
- Prior security concerns within the community (hence the fork of LedgerSMB). For us, we secure our server so SL has no open port to the public. Also, the replication cluster utilizes ssh and authentication to communicate.
- Not as easy to find a SL bookkeeper. We setup our chart of accounts per our accountant so we just give him our income statement and balance sheet and he was able to plug-n-chuck filing our taxes.
In summary, being open source and giving us the capability for customization was the primary reason that SL was the choice for our business. However, there can be a learning curve even for technical/accounting users. My advice is if you are not the type that would spend time on testing and understanding the internal of SL, then it would be a good idea to have a set budget for implementation, support, and may be even customization.