"It's just a web app with a few extra fields"
We hear a version of this in almost every first call about a financial or compliance system — a retail chain wanting a real ledger instead of a spreadsheet, a construction firm needing progress billing, a clinic needing claims and payroll in one place, a school needing grant and tuition accounting that survives an audit. The instinct is to scope it like the last CRUD app: some tables, some forms, a dashboard, done in a few sprints.
It isn't the same build. Not because the UI is harder — most financial software has fewer, plainer screens than a consumer app. It's different because five things are non-negotiable in financial software that are optional everywhere else. Skip any of them and the system doesn't fail loudly. It fails quietly, months later, in front of an auditor or a very unhappy customer.
1. Money is not a float
A normal app can round a display number and move on. A ledger can't. Store currency as floating-point and small rounding errors compound across thousands of transactions until the books don't balance — and "the books don't balance" is not a bug ticket, it's a business emergency.
The fix is boring and mandatory: integer cents or a proper decimal type, never JavaScript floats, and every calculation — tax, discounts, splits, retention holdbacks — run through the same rounding rule everywhere in the codebase. We treat this as a linting rule, not a code review nitpick.
2. Nothing gets deleted
Normal apps soft-delete or hard-delete records constantly. Financial systems don't delete — they correct, and they keep the original. An append-only ledger means every entry is immutable once posted; a mistake gets reversed with a new, linked entry, not edited or removed. This is what makes a system audit-ready: an auditor can walk the full history of any dollar, not just today's state.
This single decision reshapes your data model. Tables need posted_at, reversed_by, and created_by on every financial row from day one — retrofitting immutability onto a schema that was built to allow edits is a rebuild, not a migration.
3. Every high-risk action needs a second set of eyes
A normal app's permission model is usually "can this role see this page." Financial software needs permission at the level of the individual action, and for anything with real money or real risk attached — voiding an invoice, approving a wire, overriding a claim denial, waiving a late fee — a second person has to approve it before it executes. That's maker-checker: one person proposes the action, someone else with the right role confirms it, and the system records both.
Retrofitting this later is painful because it isn't just a permissions table — it changes your API shape. Actions become two-step (propose then approve) instead of one-step, and that pattern has to be designed in from the start, not bolted onto an existing "one click to submit" flow.
4. Retries create duplicate money if you let them
Payment gateways, bank files, and insurance clearinghouses all retry. A normal app retries a failed request and nothing bad happens. A financial system that retries a payment call without an idempotency key can charge a customer twice, post a transaction twice, or double a subcontractor payout. Every external write needs a unique idempotency key, and every nightly job needs a reconciliation step that checks what actually happened against what your ledger thinks happened, and flags the gap instead of assuming success.
This is a common gap in systems that weren't built with idempotency in mind: the integration works fine in testing, and months into production, a vendor settlement doesn't reconcile and nobody can say why — because nothing flagged the retry that caused it.
5. Retention and uptime rules aren't yours to set
A normal app can pick its own backup policy. Financial and compliance software inherits rules from outside: roughly seven years of retained accounting records for most tax authorities, HIPAA's own six-year retention rule for compliance documentation like policies and authorizations (actual medical-record retention is set by state law, which varies and isn't preempted by HIPAA), and PCI DSS scope rules the moment card data touches your system, even in transit. Miss these and the cost isn't a bug fix — it's a finding in next year's audit, or a fine.
Uptime expectations shift too. A marketing site going down for an hour is embarrassing. Payroll not running on the day it's due, or a hospital's billing system being unreachable during intake, is a different category of problem — and it changes what you budget for monitoring, failover, and on-call coverage.
How this looks industry by industry
Retail — the pain point is usually reconciliation: POS sales, card processor settlements, and vendor payouts need to agree across dozens of locations, every day, automatically.
Construction — AIA-style progress billing and retention tracking mean the "invoice" isn't final until a project milestone is verified; the ledger has to model partial, conditional payment, not just paid/unpaid. We built exactly this for a multifamily and commercial builder — see the case study.
Healthcare — claims workflows, insurance adjudication, and clinical payroll all touch protected health information, so HIPAA-aware handling (access logging, minimum necessary access, encryption at rest) is a design constraint, not a checkbox added at the end.
Institutional — grant ledgers, donor restrictions, and departmental budgets need fund-level accounting: money tagged for one purpose can't silently cover another, and every dollar needs a reportable trail back to its source.
What this actually costs you
None of this is exotic engineering — it's disciplined, well-understood patterns applied consistently. But it does mean a financial module takes longer than a comparable CRUD feature and costs more per screen. In our experience, a single focused module — job costing, claims intake, a reconciliation dashboard — runs 10 to 16 weeks. A multi-module financial suite touching several of the above at once typically runs 5 to 9 months, with a usable first slice live inside the first 12 weeks.
If a vendor quotes financial or compliance software at the same rate as your marketing site, ask them directly how they handle immutable audit trails, dual approval, and reconciliation. If the answer is vague, that's the number that's wrong, not the effort you were expecting to pay for.
Bottom line
Financial software isn't harder because the screens are complicated. It's harder because the constraints are external — accounting rules, HIPAA, PCI, your own auditors — and none of them forgive shortcuts taken to hit a deadline. Build the ledger discipline in from the first schema, not after the first audit. Our financial & enterprise software team scopes exactly this kind of build — retail, construction, healthcare, and institutional — and can tell you within a week which of the patterns above your specific system actually needs.
