Existing software-based personal finance systems (hereafter abbreviated as PFS) tend to lack data portability, customizability, support for self-hosting, mobile-friendliness, or some combination thereof, and are often used as an indirect form of advertising or to otherwise promote paid third-party services.
- ledger / hledger
- Firefly III
- Mint
- Simple (defunct)
- Monarch Money
- KMyMoney
- GnuCash
These are the high-level concepts that would likely be table stakes for any prospective user of a PFS.
An account is effectively a label, similar to a variable in programming parlance, that represents a money source (e.g. income, checking or savings accounts, credit cards) or destination (e.g. expenses, assets, liabilities, equity). It need not necessarily correspond to an account with a financial institution.
Accounts can be collectively arranged as a list or a hierarchy. The latter makes it possible to view the state of spending at various levels of depth (e.g. Expenses, Entertainment, Movies).
A posting is a record of money being deposited into or withdrawn from a single account. It can have an associated currency and date for when the deposit or withdrawal cleared the account.
A transaction is a group of two or more postings for which the amounts sum to zero, generally representing a transfer or exchange of funds between two or more accounts (e.g. using a debit card to pay for an expense).
Transactions can have a description explaining what the transaction is for or why it is occurring (e.g. for an expense, where the money is being spent, or what is being purchased) and a date of when the transaction occurred.
A ledger is a record of multiple transactions that occur over time.
Ledgers can function as a way of grouping or namespacing transactions. This can be used to determine who should have access to view or change these transactions (where ledgers are shared between multiple users) or to support multi-tenancy (where tenants are individual households, businesses, or other independent organizations).
Reconciliation is the process of comparing two groups of transactions, generally one from a local ledger and the other from a financial institution, to surface any inconsistencies that require correction for the two to be consistent with each other.
Electronic reconciliation can be accomplished using CSV exports from financial institutions or third-party services like Plaid to access financial institution data securely.
Below is a suggested high-level feature roadmap for a hypothetical new PFS.
- User registration, authentication, and invitation support
- Ledger management
- Account management
- Transaction management including quick/easy manual entry of transactions
- Audit trails for ledgers, accounts, transactions, and users
- Access control for ledgers, accounts, and transactions
- Search (including accounts, transactions, and ideally users and ledgers)
- Reconciliation support (using CSV files) with UI to optimize for common corrections
- Support for credit account limits and available credit and utilization reporting
- Plaid integration to provide a more seamless import of data from financial institutions
- Data import/export (e.g. CSV, Ledger, SQLite)
- Support for recurring transactions and/or templates of groups of transactions (e.g. for easily paying a group of bills at once)
- Support for credit account interest rates
- Projected interest cost reports
- Calculator for paying down credit account balances with strategies to minimize interest or maximize available credit within minimal credit lines
- Support for multiple currencies and currency exchange
- Calculator for impact of financial events on retirement timelines
While there are any number of languages that would work suitably for this project, given the skill set of those who have expressed interest in participating, the programming language used is assumed to be PHP.
That said, it should be possible to mimic the development approach described in the remainder of this document in any modern language.
API Platform presents itself as a possible choice. It uses Symfony and Doctrine, supports OpenAPI (more on that below), and its client scaffolding supports using Quasar.
That said, Laravel and its ecosystem of supporting libraries and services, as well as its larger community of developers, could expedite initial development and release as well.
Ideally, this project will support multiple potential database servers, initially some more commonly used and supported by libraries (e.g. PostgreSQL, SQLite, MySQL/MariaDB) and potentially graduating to others in the longer term (e.g. Oracle, SQL Server, Elasticsearch / OpenSearch).
While these may not strictly be necessary, they may make so aspects of currency handling within the domain / business logic easier to implement.
- https://github.com/whitecube/php-prices
- https://github.com/brick/money
- https://github.com/moneyphp/money
These will only apply if the related architectural elements end up being included in the released product.
This library would model the domain / business logic of overall application independent of any potential usage in a backend service or otherwise. It would be distributed as a Composer package that could be used in other projects.
This API would expose functionality from the library as a backend web service. It would handle data persistence and retrieval. The client-facing API would be based on an OpenAPI specification. This specification would be used to validate requests and responses, generate API documentation and source code for API clients (including those for other languages), and so forth.
The frontend would be a responsive mobile-friendly PWA that provides a user interface for interacting with the API. It would also serve as an example implementation for any other prospective frontends for the API.
A previous iteration of a similar project was nicknamed Dibby, an expansion of the acronym DBY which stood for "Dollar Bills, Y'all."
One alternative name is Prophit (a play on the word profit with the conventional "ph" phenome used in PHP-based projects), though that may be too close in pronunciation to the name of the existing Prophecy project.