Accounting Module — Overview

What this is

This PR ("Feat/accounting module", branch feat/accounting-module) adds a full double-entry accounting engine to Dentolize, plus three closely-related modules that were built alongside it: Salary Hub (payroll), HR & Leave management, and a generic Categories system that replaces several legacy per-clinic settings lists.

Before this PR, Dentolize tracked money operationally — invoices, payments, expenses, treasuries — but had no general ledger. A clinic's "accounting" was whatever their bookkeeper could reconstruct from those operational records. This PR gives every clinic a real chart of accounts, a general ledger that automatically posts a balanced journal entry for nearly everything that happens in the app (an invoice, a payment, a stock consumption, a doctor's commission, a currency conversion), and the standard close-the-books workflow on top of it: trial balance, financial statements, fiscal period locking, and year-end close.

It is delivered end-to-end: a new Prisma schema (dozens of new models), a new backend posting engine (packages/server/src/accounting/), and two independently-built, full-featured front ends — a native React web app (packages/clinic-web/src/components/dashboard/accounting/) and a React Native mobile app (packages/clinic-mobile/src/components/dashboard/More/accounting/) — both wired into a new FEATURE_ACCOUNTING_MODULE feature flag.

Who this is for

• Clinic owners and accountants get a real chart of accounts, journal entries, financial statements, tax tracking, fixed-asset depreciation, and bank reconciliation — without needing a separate accounting product.
• Doctors and staff are affected indirectly: their commissions, salaries, and leave are now tracked through the same engine (Salary Hub / HR), and every payslip or payout traces back to a journal entry.
• HR/office managers get leave request/approval, holiday calendars, and work schedules — a module that shipped in the same PR because payroll needed it (leave and attendance feed salary calculations).

The four pieces of this PR

1. Accounting — chart of accounts, account-role mapping, journal entries (manual and automated), general ledger, financial statements, tax, fixed assets, bank reconciliation, responsibility centers and cost allocation, fiscal periods, multi-currency. See Setup & Foundations through Tax, Inventory Valuation & Healthcare Reports.
2. Salary Hub — payroll runs, commission policies, doctor payouts, salary profiles. See Salary Hub & Payroll.
3. HR & Leave — leave types, holidays, leave requests/approvals, work schedules. See HR & Leave Management.
4. Categories & platform plumbing — a generic tagging system that replaces several legacy JSON config fields, a remote feature-flag system, and list/filter framework upgrades that support all of the above. See Categories, Feature Flags & List Framework.

How it's gated

The whole accounting section — the sidebar entry, every /accounting/* and /hr/* route on web, and the "Accounting" tile on mobile — is hidden unless the tenant's company has the FEATURE_ACCOUNTING_MODULE remote feature flag active (packages/clinic-mobile/src/context/featureFlagContext.js, packages/clinic-web-canary's FeatureFlagsProvider). This is a UI-only gate: the backend posting engine runs regardless, so once a clinic is flagged in, all of its historical operational activity (invoices, payments, expenses already in the system) can post retroactively into the ledger. Within the module, individual screens are further gated by fine-grained permissions (VIEW_GL, POST_JOURNAL, MANAGE_COA, and about a dozen more — see each feature page and the Glossary).

What this PR is honest about

The module is large and, per our own review of the code (not the PR description), not uniformly finished. Some pieces are fully wired end-to-end on both mobile and web; others are web-only, mobile-only, or have a data model and a form but no working feature behind them yet. We call these out explicitly in each feature page and summarize them for testers in For Quality — the goal of this documentation is to describe what the code actually does today, not what the module is eventually meant to become.

Where to go next

• New to the module? Start with the Walkthrough — real screenshots from a working sandbox.
• Building or reviewing the feature? Each Feature breakdown page has a Business view and a Technical view with exact file references.
• Preparing to talk about it externally, support it, train on it, or test it? See the By team pages.