Design studyEnterprise SoftwareVery Hard

Enterprise Finance Workspace

An enterprise finance platform architecture for AP, AR, GL, cash, reporting, admin controls, saved views, audit logs, and role-based workspaces.

Unbuilt. This is a system design worked out on paper, not a product. Nothing described here exists.

Overview

A dense enterprise finance workspace that treats AP, AR, GL, cash, reporting, admin, notifications, saved views, and audit logs as parts of one coherent platform rather than scattered modules.

Problem

Finance teams need speed, auditability, role-based access, exports, drilldowns, and saved workflows. A pretty dashboard is not enough if accountants cannot move through repetitive work quickly and safely.

Who it is for

Finance operators working AP, AR, GL, and cash workflows
Finance managers reviewing reports and exceptions
Admins managing roles, permissions, departments, and users
Auditors reviewing historical actions and data changes

MVP scope

Dense workspace UI with modules, tables, filters, command palette, saved views, and drilldowns
Service-layer architecture for AP, AR, GL, Cash, Reporting, Admin, Notifications, and Audit
Organization-scoped records
Role-based permissions
Saved view metadata and report configurations
Audit logs for important actions
Import/export actions for core tables

Non-goals

Do not build a full accounting engine in the first pass
Do not support every ERP integration initially
Do not make visual polish more important than workflow speed
Do not hardcode UI mock data once the service layer exists

Components

Workspace shell with module navigation and command palette
Accounts Payable module
Accounts Receivable module
General Ledger module
Cash module
Reporting module
Admin, Notifications, and Audit Logs modules
Shared service layer and repository/data access layer
Saved views and user preferences service

Architecture

Frontend: dense workspace UI with modules, tables, filters, command palette, saved views, drilldowns, and export actions.
Backend: service-layer architecture with domain modules for AP, AR, GL, Cash, Reporting, Admin, Notifications, and Audit.
Database: Postgres/Supabase with organization-scoped records, role-based permissions, audit trails, saved view metadata, and report configurations.
Auth: organization membership plus RBAC permissions enforced in both UI and backend.
Workers: background jobs for imports, exports, report generation, notification delivery, and audit processing.
External APIs: future ERP, bank feed, document, and email integrations.

Data model

Organization: id, name, plan, createdAt
User: id, organizationId, email, name, status
Role: id, organizationId, name
Permission: id, key, description
Vendor: id, organizationId, name, status
Customer: id, organizationId, name, status
Invoice: id, organizationId, vendorId, customerId, amount, dueDate, status
Payment: id, organizationId, invoiceId, amount, postedAt, method
JournalEntry: id, organizationId, date, memo, status
Account: id, organizationId, code, name, type
Department: id, organizationId, name
SavedView: id, organizationId, userId, module, filters, columns, sort
AuditLog: id, organizationId, actorId, action, entityType, entityId, diff, createdAt
ReportDefinition: id, organizationId, name, module, config
Notification: id, organizationId, userId, type, payload, readAt

API design

GET /api/modules/:module/records - list module records with filters
POST /api/ap/invoices - create AP invoice
POST /api/ar/invoices - create AR invoice
POST /api/gl/journal-entries - create journal entry
GET /api/reports/:id/run - run a report definition
POST /api/saved-views - save a table/filter view
GET /api/audit-logs - search audit history
POST /api/imports - start a CSV import job
POST /api/exports - start an export job

Technical challenges

Permission modeling across modules and actions
Dense UX without clutter
Auditability and immutable financial event history
Report performance on large tables
Multi-tenant data isolation
Saved views and user preferences
Import/export workflows with validation and rollback

Tradeoffs

Use shared module patterns so AP, AR, GL, Cash, and Reporting do not become separate apps.
Prefer server-side filtering/pagination for finance tables instead of loading everything client-side.
Make saved views first-class because power users repeat the same workflows daily.
Keep service methods explicit even when it creates more files, because financial behavior should be traceable.

Security

RBAC with route, action, and record-level checks.
Row-level security or strict organization scoping in every query.
Audit logs for creates, updates, deletes, imports, exports, approvals, and permission changes.
Immutable financial event history where possible.
Export permission checks and export audit records.
Avoid leaking one organization's data through filters, saved views, or report configs.

Scaling path

Start with core modules and shared UI/data patterns.
Add background import/export and report workers.
Add materialized report tables for expensive reports.
Add workflow approvals and notifications.
Add external integrations and API access.
Add tenant-level performance isolation if organization size diverges.

Observability

Audit logs visible to admins and stored immutably.
Metrics for slow filters, slow reports, import failures, export counts, and permission denials.
Trace IDs from UI actions through service-layer calls.
Dashboards for report queue health and notification delivery.

If it went further

Approval workflows
Bank feed imports
ERP integrations
Advanced report builder
Scheduled exports
Anomaly detection for finance records