Dentolize · Accounting Module Walkthrough
On this pageWhy this mattersScale of the changeRisk profileRecommended path

For Stakeholders

Why this matters

This PR moves Dentolize from "operational software that tracks money" to "the system of record for a clinic's books." That's a meaningfully different product category — it's the difference between a clinic needing a separate accounting tool alongside Dentolize and a clinic being able to run its entire back office (patient operations, payroll, HR, and now accounting) from one platform. It also bundles two adjacent modules the business needed anyway (payroll and leave management) into the same release, since they share the same underlying ledger.

Scale of the change

This is one of the largest single feature PRs in the codebase's history: roughly 40 new Prisma models and 20+ new enums, a dedicated backend accounting engine, and two independently built, full-featured front ends — a complete native web implementation and a complete native mobile implementation, not a shared component layer. Both were built out in this PR, screen by screen, covering chart of accounts, journal entries, financial statements, tax, fixed assets, bank reconciliation, and more, on both platforms.

Risk profile

Financial correctness risk is the primary concern, as with any new accounting system, and the core engine shows real engineering discipline: every posting enforces debits-equal-credits, fiscal periods can be locked to prevent back-dated tampering, there's a company-wide automated reconciliation check that continuously verifies the ledger against operational data, and a 7-year audit-retention policy is built in for tax-record compliance. The posting pipeline is also built to be resilient — operational actions (like recording a payment) don't get blocked by a ledger-posting hiccup; failed postings retry automatically from a durable queue.

That said, the module is not uniformly finished, and our review of the actual code (not the PR description) found a meaningful list of gaps — some cosmetic, a few that block a specific feature from working at all. The most significant:

  • The audit log covers far less than its own data model promises — most configuration changes (chart of accounts edits, account-role remapping, tax code changes, responsibility-center/allocation changes) leave no trace in the audit trail, only journal-entry actions (and now expense-claim actions) do.
  • A step-down cost-allocation feature (Allocation Rules) has no guard against a rule allocating a cost center's overhead back onto itself — worth resolving before a clinic discovers it by accident.
  • The mobile and web apps are not at feature parity. Several capabilities — the full journal approval workflow, report export, some healthcare/insurance reports, currency management — exist only on web.
  • A handful of data model fields were built for future capabilities (receipt attachments, applying a debit note against a specific bill, hourly leave requests) that have no working UI yet.

None of these are correctness bugs in what has shipped — the ledger balances, the reports reconcile, the closes are enforced. They're scope/completeness gaps in a very large module built in one pass. See For Quality for the full, itemized list, organized for test planning.

Given the size and the gaps above, we'd recommend treating the feature-flag gate (FEATURE_ACCOUNTING_MODULE) as load-bearing, not incidental: keep the rollout gradual and company-by-company rather than flipping it globally, prioritize closing the audit-log gap before wide release, and be explicit with early customers about the web/mobile capability difference so it doesn't land as a surprise in onboarding.