Business context
One application, several operational workflows.
The platform brings together multi-company cash-basis accounting, accounts payable and receivable, inventory, fleet and fuel, assets, CRM, and document workflows. It also supports employee military records using immutable, versioned data.
As the primary application engineer, I translate business requirements into the data model, APIs, access rules, and interface. The application uses Python and FastAPI with PostgreSQL, SQLAlchemy, and Alembic, alongside React and TanStack.
Finance
Cash-basis accounting, AP/AR, bank statements, transaction categories.
Operations
Inventory, fleet and fuel, asset records, CRM, and documents.
Control
Server-enforced access, audit trails, recovery, and versioned records.
Bank integration
Handle each bank’s differences explicitly.
Before automation, an employee had to visit each bank’s application and download statement files as part of the daily routine. We integrated PUMB, PrivatBank, and Monobank and used API retrieval wherever the bank made it available.
The important constraint was that banks do not provide identical formats or identifiers. I separated bank-specific parsing schemas from the shared finance workflows.
| Input condition | How it is handled |
|---|---|
| A native payment identifier is available | Use that identifier to detect duplicate transactions. |
| The bank does not supply that identifier | Use a configured combination of fields in the bank’s parsing schema. |
| Descriptions contain useful classification data | Apply configurable parsing rules to assign categories. |
| Automatic statement retrieval is unavailable | Retain statement-file import as a fallback. |
This approach makes differences between banks part of an explicit schema. It also lets description rules be refined as we encounter new transaction patterns.
Validation before commit
Show what the import will do.
During beta, users need to understand how the system interpreted their data. The preview exposes the planned result before an import is committed, so incorrect parsing or classification can be noticed at that stage.
Retrieve
Bank API, with statement files as a fallback
Identify
Native payment ID or a bank-specific combination of fields
Classify
Configurable rules for transaction descriptions
- Parsing & categories
- Duplicate matches
- Target accounts
- Record restorations
- Parsed values and categories: check how source data was read and where transactions were classified.
- Duplicate matches: see which incoming records match existing transactions.
- Target accounts: see where the imported payments will be assigned.
- Planned restorations: identify records that will be restored from previously deleted entries.
The preview/commit flow supports beta testing and serves as a fallback when automatic retrieval is unavailable. API integrations still remove routine downloads wherever they are supported.
Delivery & ownership
Architecture through release validation.
I own the application architecture and implementation, including versioned APIs, server-side permissions, generated documents, and data workflows. I work with DevOps and mentor a trainee while maintaining automated checks with Playwright and unittest.
beta
Multiple businesses and hundreds of monthly transactions. The platform is being validated with actual business workflows at this stage.
The practical improvement is straightforward: employees no longer need to download statements from every supported bank each day. Configurable rules also reduce repeated manual categorization. The preview remains available to inspect how data will be handled.
- Python
- FastAPI
- PostgreSQL
- SQLAlchemy
- Alembic
- React
- TanStack
- Playwright
- unittest