Overview
A role-based Angular ERP that transforms complex financial operations into structured, auditable workflows for enterprise teams and individual users.
Back
GOS Financial ERP
A multi-tenant financial ERP unifying lending, treasury, accounting, procurement, inventory, and approvals.
500+
Angular Components
70+
Domain Services
60+
Application Modules
Multi-tenant
Platform Model
The Problem
- Disconnected tools and spreadsheets created repeated data entry and inconsistent financial records
- Manual handoffs slowed approval, reconciliation, and transaction-status visibility
- Different organizations needed distinct workflows without fragmenting the shared product
- Complex financial activity required reliable permissions and auditable process histories
The Solution
- Built a unified Angular workspace spanning lending, treasury, accounting, procurement, inventory, assets, and expenses
- Created reusable approval infrastructure with configurable workflow groups and authorization levels
- Centralized authentication, loading, caching, and authorization behavior with guards and HTTP interceptors
- Supported client-specific deployments through environment configuration while preserving shared business logic
Architecture Overview
High-level architecture of the application.
Presentation Layer
Angular feature modules with PrimeNG, Angular Material, and reusable domain components
Reactive Layer
RxJS streams coordinating identity, navigation, dashboards, and application events
Data Layer
domain services using HttpClient, REST APIs, JWT, and centralized interceptors
Real-time Layer
SignalR and WebSocket events supporting notifications and live operational updates
Key Highlights
Configurable multi-level approval workflows
End-to-end lending and credit-risk operations
Integrated treasury and general-ledger workflows
Role, company, and module-based access controls
Multi-client environment configurations
Dashboards, reports, and Excel import/export
Challenges
- Balancing reusable UI patterns with the distinct validation and lifecycle rules of each financial domain
- Coordinating token expiry, authorization failures, loading state, return URLs, and session data consistently
- Keeping customer-specific deployment decisions out of shared business components
- Maintaining clear feature boundaries as the application grew beyond 500 components
Results
- Delivered one interface covering lending, treasury, accounting, procurement, inventory, assets, and expenses
- Established reusable approval infrastructure across financial and operational workflows
- Supported multiple client-specific production configurations from a shared application foundation
- Integrated real-time notifications with operational dashboards and report generation
What I Learned
- The strongest architectural boundaries followed business capabilities rather than individual screens
- Loading, error, permission, and approval states are core product behavior in financial software
- Products at this scale require continuous investment in lazy loading, typing, testing, and feature boundaries