Password sign-in and in-app onboarding are in Preview. Google and Microsoft sign-in with roles is Shipped and keeps working alongside them.
The one-time setup link
A new installation has no users yet, so the first person in has to prove they hold a secret. That secret is a setup token carried in a link, and it works once.
- Open the setup link privately. A Windows install opens it for you on first launch; a hosted instance gets it from the operator; a source install builds it from
LEDGER_SETUP_TOKEN. - Enter your name, email, a password and the password again.
- Setup creates the owner and sends you to sign in. Sign in with the new account to continue to onboarding.
Passwords need 12 to 1024 characters, with at least 12 left after padding is trimmed. The exact password you type is hashed, never trimmed, with a random-salted scrypt hash.
An invalid or missing token returns a not-found page and cannot create an owner. Once any active owner exists, setup returns not-found for both visits and submissions. Until then, anyone holding the link can claim the installation, so avoid shared browsers and keep it out of proxy logs.
If you configured the token yourself, remove it after setup. If all owners are later deactivated, a token left in place would reopen setup.
Onboarding: four steps
An empty ledger cannot be viewed, so an owner who signs in with no entity yet is sent to onboarding. Anyone who is not an owner sees a waiting page until an owner finishes it.
| Step | You choose |
|---|---|
| 1. Your entity | A name; a kind (operating business, consulting or services practice, or holding company); a short code of 2 to 6 letters or digits that prefixes invoice numbers; and the month your fiscal year starts. Currency is US dollars only. |
| 2. Chart of accounts | A template for that kind of entity, with a preview of its account groups. You can add accounts later. |
| 3. Accounting periods | The current fiscal year is opened. Optionally also open last year, to import earlier transactions, and next year, so posting never stops at year end. |
| 4. Review | A summary. Create my books makes the entity, its accounts and its open months. |
The templates are General business, Consulting, Software subscriptions, Coaching and services, and Holding company. Each is a shared base business chart plus one specialization. Which ones you see depends on the kind of entity you chose.
Periods matter because you can only post into an open month. The review step lists every month that will open.
Onboarding creates no transactions and no balances. You bring those in next.
After onboarding
You land on Today with four suggested next steps. Do them in any order, or skip them.
- Import a bank CSV. Bring in your first transactions and categorize them. See Import bank data.
- Connect your agent. Let Claude, ChatGPT or Codex read the books and draft entries. See Connect your agent.
- Add API keys. Bank feeds, AI providers and payments, stored encrypted. See Bring your own API keys.
- Invite your accountant. Give them an accountant or viewer role.
You can add more entities later, and change entity details.
Users and roles
Only an owner can open Settings → Users. Granting access is the most powerful permission, so it stays with owners.
- Open Settings → Users as an owner.
- Add a person with their email, name, role and a temporary password, or reset an existing user's password.
- Deliver the temporary password privately.
- Give each person the least access that lets them do their job, and widen it only when the work needs it.
| Role | Can do |
|---|---|
| Viewer | Read the books and reports. Changes nothing. |
| Accountant | Everything a viewer can, plus posting, voiding, reconciling and closing periods, and other changes to financial records. |
| Owner | Everything an accountant can, plus managing users, roles and agent connections. |
Posted entries are immutable, so even an owner cannot quietly rewrite history. Roles decide who can act; the ledger decides what those actions can undo. Journal approvals add a second sign-off for entries that need one.
Give everyone their own sign-in. A shared login erases the record of who did what.
Sign-in limits
This version is honest about what it does not do yet.
- Failed sign-ins are limited to five attempts per email address and source IP in 15 minutes. The limit is stored in PostgreSQL, so restarts do not reset it.
- There is no forced password rotation and no self-service password change or recovery. An owner resets passwords.
- Resetting a password or deactivating a user ends every session they have on the next request, so a reset is enough to cut off a leaked password.
- Password sign-in never self-registers. It only admits an existing, active user.