LedgerSMB: a Perl double-entry accounting and ERP system that runs on Postgres

This is a full ERP, not a bookkeeping tool

LedgerSMB is described as a free web-based double-entry accounting system, and the feature list is longer than that label suggests. It covers quotations, ordering, invoicing, projects, timecards, inventory management, shipping, and more. The repository topics agree, with accounting, double-entry-accounting, general-ledger, billing, bookkeeping, quotations, orders, purchasing, payments, inventory, inventory-management, manufacturing, material-cards, fixed-asset, projects, time-tracking, and web-app all in the list. The intended user is a small and medium business, and the README's own framing is small and medium business accounting and ERP. What makes it more than a ledger is the flow around it. A quotation becomes an order becomes an invoice, and the documents carry PDF attachments through the built-in e-mail function to customers or to vendors as requests for quotation, from anywhere in the world with the browser-based UI.

PostgreSQL is the store, and the scale claim is specific

The data is stored in the enterprise-strength PostgreSQL open source database system, and the README states the system is known to operate smoothly for businesses with thousands of transactions per week. That number is worth holding on to when you read the rest of the project. The server requirements for the 1.14 current development version are Perl 5.38 or newer, PostgreSQL 14 or newer, and a web server such as nginx, Apache HTTPd, lighttpd, or Varnish, and the README notes the web server is only required for production installs, since a simpler setup can be used for evaluation. The system requirements for the 1.13 stable version live on a separate branch, so the two version lines have different dependency floors, which is a detail to check before you pick a release. The Perl requirement is the more important one to plan around, since the primary language of the repository is Perl and the application layer sits on it.

The Docker quick start is explicitly an evaluation path

The quick start assumes Docker and docker-compose are installed, and the README's own warning about unofficial or AI-generated Docker Compose examples is unusually direct. The two commands it gives are:

 $ wget https://raw.githubusercontent.com/ledgersmb/ledgersmb-docker/1.13/docker-compose.yml
 $ docker-compose up -d

This creates both the LedgerSMB image and a database image with a persistent database. Then comes the caveat that matters most, because the README says the setup is not sufficient for production purposes since it lacks secure connections to protect users' passwords. It also says the setup does not use a web server like nginx or Apache, and that setups which do include one will yield a faster user experience due to much faster page load times and web request responses, so for production setups you should consider adding a web server to the installation. The comment about unofficial compose files is a good signal about how many broken deployments circulate, and it is the reason to use the file from the ledgersmb-docker repository at the version the README points to.

Two URLs separate company setup from day to day login

Once the containers are up, the README names two entry points and the difference between them is a permission boundary. `http://localhost:5762/setup.pl` is for creation and privileged management of company databases, and `http://localhost:5762/login.pl` is the normal login for the application. The port is 5762 rather than the usual defaults, which matters if you are running several evaluation instances or a local stack. The README also points at a preparation for first use guide, which is the sensible next read after setup, since the system expects an administrator to create a company database before any user can log in. For from-tarball installation the README points to a version-specific instructions page, so an evaluation with Docker and a production install with a tarball are two separate paths with two separate documents.

Customer-facing documents are template driven and multi-format

One of the more distinctive aspects of LedgerSMB for a business software package is that the output is meant to be customisable without touching code. Customer visible output is fully customizable in templates, allowing easy and fast customization, and the supported output formats are PDF, CSV, HTML, ODF, and more. For a small business, the practical consequence is that a quotation, an order confirmation, or an invoice can carry the branding and layout the business actually wants, and the same template mechanism covers the document a customer receives by e-mail. The set of supported formats also means the same source data can be exported into whatever format a downstream process expects, which is the kind of thing that matters when the accounting data has to satisfy a bookkeeper, a customer, and a customs process at once.

The Makefile shows a project with real build infrastructure

The repository root Makefile lists the targets, and the list reads like a summary of the project's engineering practice. There is a `dist` target that builds the release distribution archive, `js` that builds the minified JavaScript blob served to clients, `jsdev` that builds the JS assets with the Vue debugger enabled, and `jslint` that runs eslint on the JS code, with FIX=1 reformatting. There are documentation targets for schema documentation in PDF, SVG, and PNG, for POD documentation, for API documentation, and a `pot` target that builds the LedgerSMB.pot translation lexicon. The test targets are layered too, with `test` running the tests in `t/`, `devtest` adding the development tests in `xt/`, `jstest` running the UI tests, and `testdb` creating a test database with a user and config. A `serve` target runs webpack serve. The Makefile also honours a `Makefile.local` include and switches the Yarn install to `--immutable` when CI is set.

Where LedgerSMB is the wrong choice

There are three limits, and none of them is a bug. The first is the Perl requirement, which is a genuine operational constraint for teams whose platform skills are elsewhere, and the second is the deployment shape, because a Perl web application on PostgreSQL behind a reverse proxy is a stack you have to be able to maintain and upgrade. The third is the licensing and edition story, where the repository is reported as carrying a custom licence that GitHub cannot classify, while the README badge shows GPLv2, and the release tags carry a `-pro` suffix that suggests a distinction between community and commercial editions that the README does not explain. That last point is the one to resolve first, because a business evaluating accounting software needs to know which edition it would be running and under what terms, and the README links to ledgersmb.org for that rather than stating it. Everything else about the project, from the pinned dependency versions to the CI, CodeQL, and coverage badges, suggests a well-run codebase with a community behind it.

Editorial conclusion

LedgerSMB fits a small or medium business that wants double-entry accounting with real ERP functions, runs its own PostgreSQL, and has someone who can maintain a Perl deployment. It is the wrong choice for a company that needs a hosted product with a support contract, or one that has moved its application stack away from Perl, and it is the wrong choice if you plan to run the Docker Compose setup as-is in production, because the README says plainly that it lacks secure connections for user passwords. Before you adopt it, read the system requirements for the 1.14 development version against the 1.13 stable branch, and plan on putting nginx or Apache in front of it rather than exposing the container directly.

Frequently asked questions

Official sources

1. Issues
2. ledgersmb/LedgerSMB on GitHub
3. Project website
4. README
5. Releases