The source route stopped before working billing was established
Free GST Billing Software installed its dependencies in our sandbox, then its build stopped with ReferenceError: crypto is not defined. A business considering a move from existing books still needs a working launch and verified outputs before it can judge the billing workflow.
The README describes local invoices, customer records, inventory and Indian GST exports. Those features make it a candidate for a controlled local evaluation. Our run did not establish that the application starts, prints correctly, restores records or produces files accepted by the GST portal.
What happened when we ran it
Our October 30, 2026 run began at 12:10 UTC and evaluated commit c40309e. Installation succeeded in 20 seconds, recording 579 dependencies and 354 MB on disk. Our source build failed after 20 seconds. It exited with code 1, and the overall test command also exited 1 after 1 second.
The build tail points to generateUID in serialize-javascript, with the loading path continuing through @rollup/plugin-terser. That identifies where execution stopped; it does not establish the underlying cause.
The test tail shows date-import checks followed by Passed: 50 Failed: 0. Playwright then reports that Node.js 18.20.8 is running and requires Node.js 20 or higher. The earlier summary is a partial result inside a failed command, not evidence that the full suite passed.
The sandbox configuration listed 3 CPUs, 8 GB RAM and image lab-node:22. The explicit runtime message establishes Playwright's reason for refusing to run. The image name does not override it or identify the operating-system version. The supplied results contain no supported-runtime retry, and the Playwright message does not explain the separate build exception.
Npm audit reported 0 known vulnerabilities. The checkout contained 182 files, approximately 44,131 source lines and 8.3 MB. The scan found a tests directory, no CI workflow files and no Dockerfile. These observations describe the measured checkout; they do not certify software safety or establish whether checks exist elsewhere.
Release launchers remain a separate evaluation
The README distinguishes the release ZIP from a source-code download and documents Windows, macOS and Linux launchers. Our failed source workflow does not establish that those launchers fail.
The supplied release metadata identifies v1.10.83 as published at 19:21 UTC on October 30, 2026, after our 12:10 UTC run. That release was not tested. The measured commit and the later release must remain separate when interpreting these findings.
The README says invoices, clients, products and settings are stored as local JSON files. It also describes automatic backups and optional Google Drive backup. Those are documented capabilities, not recovery results from our sandbox.
For a local trial, use disposable records. Create an invoice, record a payment, export the data and attempt restoration into a separate evaluation copy. Reconcile the restored balances and invoice outputs before transferring real books. We did not perform that exercise.
Keep the server off the public internet
The README says the server has no login and must not be put on the internet. That rules out this documented setup for a business requiring a publicly accessible billing service.
The supplied introduction also describes a server listening only on 127.0.0.1. We did not inspect a running server or verify access controls. Businesses needing shared access or employee permissions should establish those requirements against the selected release before adoption; this review does not verify them.
Check GST outputs before relying on them
The README describes generating GSTR-1 and GSTR-3B data for use on the GST portal. Its filing walkthrough calls for exporting GSTR-1 JSON for upload and copying the GSTR-3B summary into the portal. This documents an intended workflow for India. Our run did not validate tax calculations, statutory correctness or portal acceptance.
The supplied issue feed includes closed reports about product-import fields and a rejected GSTR-1 upload, along with open requests concerning Tally integration and Vyapar backup restoration. Issue closure does not verify a fix. A request also does not establish every supported or unsupported migration format. Test a small, reconciled sample of your own records before transferring history.
The README's international currency and tax-label descriptions likewise do not establish compliance outside India. Check the invoice requirements for the jurisdiction where the documents will be used.
Alternatives have different scope and lifecycle limits
The frappe/books repository says its Electron/Vue variant has reached end of life and is superseded by Frappe Books. Its README describes double-entry accounting and local SQLite storage for that old variant. Those details cannot be transferred to the successor, whose source was not supplied. The old repository is not a recommendation for a new installation.
ERPNext documents accounting, order management and manufacturing. Evaluate it when billing needs to connect to wider business operations. Its README describes managed hosting and self-hosting, and labels the disposable Docker demo as an evaluation environment. That demo is not the documented production deployment path. We did not run ERPNext or compare tax-output correctness between the applications.
What to establish before adopting it
The source run leaves setup incomplete, while the release launcher remains untested. Documentation coverage alone cannot establish operating reliability, and the supplied excerpts do not support a numerical documentation rating. Setup ease, community support quality and billing maturity also remain unassessed.
The next useful result is a successful launch of the exact version you intend to use, followed by a restored sample whose balances, invoices and required GST outputs you can reconcile.