// Aspect 01
Connects to bank accounts in the United States and Canada through three data providers: Plaid, MX, and Finicity. Crypto accounts are connected through Coinbase only.
Coverage outside North America is not supported. There is no native support for European banks, UK banks, or accounts in any country outside the US and Canada. Crypto wallets and exchanges other than Coinbase cannot be connected.
Canadian institution support depends on Plaid's Canadian coverage, which is more limited than its US coverage. Some Canadian banks, brokerages, and credit cards are not available or sync inconsistently.
Connects to financial institutions across multiple regions through specialized providers chosen for each region:
A single user can hold accounts from multiple regions in the same finerd account simultaneously.
// Aspect 02
Each user has a primary currency, either USD or CAD. According to Monarch's own help documentation, the product does not differentiate between currencies internally and does not perform currency conversion.
Mixing accounts in different currencies is not recommended by Monarch because totals are calculated by adding raw numbers regardless of currency. A user with a CAD account showing 10,000 and a USD account showing 10,000 would see a total of 20,000 with no conversion applied, which does not represent actual purchasing power or net worth.
For users whose finances are entirely in one currency (USD or CAD), this limitation is invisible.
Each user has a primary currency. Accounts and transactions can be in any currency. The product handles multi-currency in three ways:
For reports and the user's net worth view, balances are converted to the primary currency. Current exchange rates are used for current balances, and historical exchange rates are used for historical monthly balance snapshots, so net worth at any point in time is calculated against the rates that actually applied on that date. The original native-currency balances remain visible alongside the converted totals.
For users whose finances are entirely in one currency, the experience is the same as in Monarch. Multi-currency features simply do not appear unless an account in another currency is added.
// Aspect 03
Account balances on synced accounts are pulled directly from the bank through the data provider. The displayed balance is whatever the bank reports.
Users can import historical balances by uploading a CSV file with date and amount columns. Monarch supports this for both synced and manual accounts, and can fill in years of missing history. However, imported historical balances are not reconciled against transactions: the balance system and the transaction system are independent. A missing or duplicate transaction does not affect the displayed balance, and the discrepancy cannot be detected by the app.
Transaction imports follow a separate flow with its own CSV format. On synced accounts, importing transactions does not change the displayed balance. On manual accounts, the user can choose to adjust the balance after importing transactions, but the two are still managed separately rather than being tied to one another.
Account balances are calculated from the underlying transactions using double-entry bookkeeping. Each transaction debits one account and credits another, so the calculated balance always reflects the recorded movement of money.
The bank-reported balance is also stored and compared against the calculated balance. If the two diverge (for example because a transaction failed to sync or was duplicated), the discrepancy is flagged on the account and the user can investigate. Missing or duplicate transactions become visible rather than silent.
Users can also import historical balances. Unlike in Monarch, imported balances are compared against finerd's calculated balances, so any discrepancy between the imported history and the transaction ledger is surfaced for review.
To make backfilling easier, users can upload bank statements (PDF or other common formats) and finerd's AI extracts the dates and balances automatically. This removes the need to manually prepare a CSV from a bank's exported data.
// Aspect 04
Transactions are categorized automatically. When a user is unsatisfied with how a category was assigned, they can build a rule to fix similar cases going forward.
Rules match on merchant name (exact match or contains), amount (with operators like equal to, greater than, less than, or a range), category, and account. When a rule matches, it can rename the merchant, change the category, add tags, mark the transaction as needing review, hide the transaction, or link it to a goal. Rules run on new posted transactions in the order they are listed in settings; users can reorder them by dragging.
Rules apply to incoming transactions automatically. Past transactions can be re-evaluated against rules, but only if the user explicitly applies the rule retroactively from the rule editor.
Transactions are categorized automatically using AI that considers the merchant, amount, description, the user's previous categorization choices, and information from the data provider. The system learns from the user over time without requiring rules.
Because amount is part of the signal, the AI distinguishes contextually similar transactions that a rule-based system would treat the same. For example, at the same gas station merchant, a small amount is more likely to be coffee or groceries from the convenience store, while a larger amount is more likely to be fuel. The AI categorizes them differently based on the spending pattern rather than requiring the user to build separate rules.
When a user changes a category on a transaction, the AI applies the same change to similar past transactions across the user's history automatically. The user does not need to write or maintain rules.
// Aspect 05
Monarch has its own internal merchant library and assigns merchants to transactions automatically. The library is not exposed to users for browsing or searching.
When Monarch's library does not recognize a merchant on a user's transaction, the only way for the user to fix it is to create a custom merchant manually by typing the name. There is no way to pick from a list of merchants the user has not previously used. The user-facing merchant pool is effectively limited to merchants the user has already encountered or typed in.
finerd has a global merchant library shared across all users. For synced transactions, the merchant is handled automatically. For manually created transactions, the user can choose a merchant from the global library rather than typing it from scratch.
The user can use merchant enrichment to fill in or improve a merchant: enter the merchant name, city, country, industry, website, or social link, and finerd's AI fetches the real merchant information (display name, logo, industry, location) automatically.
// Aspect 06
Transfers between the user's own accounts (for example moving money from checking to savings) are handled as a separate "transfer" category. They appear in the transaction list but are excluded from cash flow analysis.
Because transfers are hidden from cash flow, the user cannot see how money moves between their own accounts in reports.
Transfers are recorded as From-account / To-account, debiting the source and crediting the destination. They move balances on both sides and appear in the cash flow report as actual money movement.
To the user, transfers appear as a single seamless event: From Account A → To Account B. The user does not interact with intermediate steps. Under the hood, finerd uses Money On The Way pair accounts to keep both account balances accurate during the settlement window for transfers that take time to settle (for example, a credit card payment that leaves a checking account immediately but takes several days to appear on the credit card).
Mechanism (for reference, not visible in the user's main flow): the transfer is split into two legs that pass through a Money On The Way account.
Once the transfer completes on both ends, the Money On The Way account balance returns to zero. If money gets stuck (one side charged, the other side never received the funds), the Money On The Way account stays non-zero and shows up in the user's transaction list and account list, surfacing the problem so the user can investigate. As long as transfers complete normally, the user only sees Account A → Account B.
Users can see how money flows between their checking, savings, brokerage, business account, and any other accounts as part of regular reporting.
// Aspect 07
Pending transactions can be edited (categorization, notes, merchant), but when the transaction posts and the bank sends the final version, Monarch overwrites the user's pending edits with the posted transaction's data.
This means any work done on a pending transaction is lost when it posts, and the user must re-edit the transaction after it appears in the posted state.
Pending transactions can be edited freely. When the transaction posts and the data provider sends the final version, finerd merges the posted data with the user's pending edits rather than overwriting them. Categorization, merchant, notes, and tags applied while pending are preserved.
If the posted amount differs from the pending amount, finerd creates a separate journal entry for the difference, so the user can see and decide what to do. For example, a user enters a pending charge of $100 from Amex Platinum, categorized as Eating Out:
The user can then change the Uncategorised allocation to Amex Platinum, and the transaction becomes a clean $105 from Amex Platinum to Eating Out. Nothing is silently corrected: the difference is always visible until the user resolves it.
Users can also create pending transactions manually, even on synced accounts. For example, a user splitting a restaurant bill with friends right at the table can create the transaction immediately, snap the receipt, and split the cost using debt accounts before the charge has even posted to their card. When the posted transaction syncs from the bank later, finerd matches it to the manually created pending transaction, so the user does not end up with duplicates and the balance stays accurate the whole time. The user does not have to wait for the bank to act.
// Aspect 08
A user can split a transaction into two or more separate transactions. After splitting, the original transaction is preserved as a parent record, but the user-facing transaction list shows the split parts as their own line items. When viewing one of the split parts, a banner appears noting that the transaction is part of a split, with a button to open the original split details (for example: "This transaction is a split, the original transaction on the account statement was from Playtomic on 1 May 2026 with a total of $70.00").
The split is between categories or amounts, but the structure is fragmentation of one transaction into many. Reconciliation against a bank statement requires matching the bank's single transaction to the sum of the split parts.
A user can split a transaction by allocating it across multiple destinations: expense or income categories, debt accounts, asset accounts, or any other account in the user's space. The original transaction stays as a single record in the transaction list, with the split details stored within it.
This makes splits much more powerful than a category breakdown. For example, a $3,000 mortgage payment can be split as follows:
The result on the user's net worth: increases by $2,500. The property asset rose by $1,000 and the loan liability dropped by $1,500. Only the $500 insurance portion appears as an expense in reports. Reconciliation against the bank is straightforward because the bank still sees one $3,000 transaction and finerd shows one $3,000 transaction; the split is internal allocation, not fragmentation of the record.
// Aspect 09
Each transaction has a single editable date plus a separately stored original date. When the user changes the transaction date, Monarch keeps the original date on the record and shows it inside the transaction details, but the original date is informational only: reports, balances, and transaction list sorting all use the edited date. Users cannot sort or filter transactions by the original date.
Each transaction has three independent date concepts:
finerd's reports run on the transaction date (the pending date), not the posted date. Balances used for reporting are pending balances, not the bank's reported "current" balance. This means reports always reflect the user's view of when activity happened, while reconciliation against the bank still works because the posted date is preserved.
Users can sort and filter transactions by transaction date, by posted date, or by accrual month. Each of the three concepts is a first-class field, not just stored data, so the user can choose which view to look at the transaction list through.
// Aspect 10
Users can change the date on a transaction (or on each part of a split) to make it appear in a different month for reporting purposes. The effect is similar to assigning an accrual month, but it overwrites the original transaction date. To see when the transaction actually occurred, the user has to open the transaction and view the original date stored separately.
All Monarch reports use the date the user assigned, not the original transaction date. There is no concept of a separate cash basis report that shows the original timing alongside an accrual basis report that shows the user's assigned timing.
Each transaction (income or expense) can be assigned an accrual month or a range of months that differs from the actual transaction date. The original transaction date remains intact and visible. A $1,200 annual subscription paid in January can be assigned to spread across all twelve months of the year, or to land in any chosen month, without changing the date the money actually moved.
This works in both directions: a freelancer who invoices in March but does the work in February can record the income against February. A user who prepays rent in December for January can record the expense against January. In both cases, the original transaction date is preserved separately from the accrual assignment.
// Aspect 11
All reports use the transaction dates the user has assigned (which may have been edited from the original posting date). There is no separate cash basis report that shows the original transaction timing alongside an accrual basis report. Reports are a single view tied to whatever date is on each transaction.
finerd splits reports between cash basis and accrual basis according to what each report is meant to show:
This separation means the user gets accurate answers from both perspectives: smoothed financial picture for spending analysis, and unmodified money movement for cash flow and net worth.
// Aspect 12
Individual transactions can be hidden from reports. Hiding removes a transaction from the transactions list, cash flow, reports, and budget calculations.
Per Monarch's documentation, hiding a transaction does not affect account balances or net worth. On synced accounts this is because balances are pulled from the bank, not calculated from transactions, so hiding a transaction has nothing to recalculate. On manual accounts, where the user maintains the balance directly, the user controls the balance separately from whether transactions are hidden.
Transactions cannot be hidden from reports. Reports always reconcile against the full ledger using double-entry bookkeeping, so every transaction is part of the totals.
Adjustments that a user might want to "hide" are instead recorded as their actual nature. For example, a work expense the user paid out of pocket and will be reimbursed for can be handled in two ways:
In both approaches, every transaction stays in the ledger and reports remain consistent with actual money movement. Nothing is hidden; the structure handles the reimbursement correctly.
// Aspect 13
One shared account with one owner. Both partners see all accounts and all transactions. There is no way to keep an account or transaction private from a partner inside the app.
Tags allow accounts to be marked as "mine," "yours," or "shared," but tags do not hide anything. Both partners can still see all tagged accounts.
Each partner has their own private space. Sharing is configured at two levels: per account, and per individual transaction. A user can keep an account fully private but choose to share specific transactions from it (for example, keep the personal credit card private but share the Walmart grocery run on it). Configurations include:
Money sent to a partner is recorded against a Family Member Account that represents the partner inside the user's space. By default, this account is off balance: a transfer to it does not affect the user's net worth, because the money is going to someone considered part of the household rather than leaving the household.
If a partner shares one of their actual accounts (for example, a joint checking account), it appears in the user's space as a joint account and contributes to the user's net worth normally. If the partner only shares individual transactions but no accounts, those shared transactions appear sourced from the Family Member Account, keeping it visible without exposing the underlying private account.
Each partner has their own independent category list. Partners do not need to align on what categories exist or what to call them. One partner can track tennis equipment, racing fees, and tournament travel as separate hobby categories; the other partner, who isn't involved in tennis, doesn't need any of those. This applies to joint accounts too: every transaction on a shared account is categorized using each partner's own categories. The AI organizes each partner's view of the same transaction independently, using that partner's category structure and history. The same transaction can land in different categories on each partner's side without any conflict, because each partner sees their own version.
Because each partner's data lives in their own space, separation does not create data loss or migration. Each partner keeps their own financial history.
// Aspect 14
The cash flow report is income minus expenses. Transfers between accounts are excluded. The report can be visualized as a Sankey diagram.
The cash flow report shows all directions of money movement in a single view: income (by category), expenses (by category), debt activity (money sent to or received from people), investment activity (money moved into or out of stock and crypto accounts, treated as external transfers because investments sit outside cash), initial balances, balance corrections, and net change in cash for the period. The intent is one report that captures everything that affected the user's cash during the selected timeframe.
Transfers are not surfaced as a separate noisy line. If a transfer between two of the user's accounts completes successfully (the Money On The Way pair account balance returns to zero), the cash flow report does not show it: the money moved from one of the user's accounts to another, the user already has it, and reporting the transfer would only add noise.
If a transfer is not fully completed (one side charged, the other not yet received), it shows up in cash flow because the user's overall money picture is genuinely affected. Similarly, if the user filters cash flow by a specific account (or set of accounts), transfers leaving that account toward an unfiltered account do appear, because from the filtered view the money did leave the scope.
Every flow type in the report is expandable. The user can ungroup any inflow or outflow:
Sankey diagram view is available, with the same expandable structure: the user can drill into any flow on the diagram to see what it is composed of.
// Aspect 15
Net worth in Monarch follows the standard accounting formula: Net Worth = Total Assets − Total Liabilities. The total is shown over time and can be filtered by account.
Net worth is the sum of bank-reported balances at each point in time. The historical net worth chart reflects whatever each bank reported on each day, not a calculation reconstructed from the underlying transaction ledger.
Account taxonomy. Monarch organizes accounts into four top-level categories:
For manual accounts, users can create entries under specific asset and liability types:
Automatic valuation for property and vehicles. Monarch can automatically update the value of real estate via Zillow's Zestimate (refreshed weekly) and vehicles via VinAudit using the user's VIN (refreshed monthly, around the 27th). The user adds a property by entering an address and selecting it from Zillow's results, or a vehicle by entering its VIN. Both connections are US-only and not supported in Canada. Properties and vehicles outside the US can still be tracked manually.
Net worth is the total value of everything the user owns (assets) minus everything they owe (liabilities). It represents the user's true financial position: what they would have left if they sold everything and paid off all debts. Net worth is the single number that shows whether the user is building real wealth or just staying busy. Cash flow tells the user whether money is coming in. Net worth tells them whether their financial position is actually improving over time.
Formula: Net Worth = Total Assets − Total Liabilities. A positive number means the user owns more than they owe. A negative number means debt exceeds what they own.
In finerd, net worth is calculated automatically from the transaction ledger. Historical net worth is reconstructed from the underlying money flow rather than relying on bank-reported balances at each point in time. Both current and historical exchange rates are applied appropriately so multi-currency net worth reflects the rates that actually applied on each date. The total is broken down by account so the user can see exactly which accounts contribute to net worth changes month over month.
Account taxonomy. finerd organizes accounts into seven main categories:
The Property category breaks down further into specific types: real estate, vehicle, furniture, electronics, valuable items, and other property. This means users can track meaningful physical assets at a level of detail Monarch's Vehicles + Valuables + Other Assets structure doesn't reach.
Loyalty programs and points are not represented as assets or liabilities on the net worth statement. They appear in their own reports at the time the user spends them.
Why this matters: tracking net worth lets the user see whether their financial position is improving or declining over time, whether their business is building equity or just generating income, and whether debt is growing faster than assets. Without tracking net worth, a user can feel profitable and busy while their financial position quietly weakens.
// Aspect 16
Not available. Spending is reported at the household level without a breakdown of who paid for what.
Expenses are grouped into three contribution buckets: mine (the user's personal expenses), ours that I paid, and ours that the partner paid. Within each bucket, spending is organized by category and subcategory, the same way the rest of finerd structures expenses. Users can see, for example, "ours that I paid → Groceries → Costco" alongside "ours that partner paid → Groceries → Whole Foods" without manually compiling per-partner totals.
This is useful for couples settling up, for analyzing household contribution patterns, or for tracking whether one partner consistently covers a specific category.
// Aspect 17
Not available.
Shows how every balance on an account changed over the selected period. For accounts that hold a single currency, this is the cash balance over time. For accounts that hold multiple balances (a brokerage like Questrade with USD cash, CAD cash, plus individual stock positions like AAPL, GLD.ARCX, VTI.ARCX, ICLN.XNAS, etc.), every balance line is tracked independently. The user sees the starting balance, the change, and the ending balance for each one.
Below the balance summary, the report lists every transaction that affected the account in the period, with date, merchant, From / To accounts, the change applied, and the running balance after each transaction. This makes it possible to audit a specific account, find when a balance went wrong, or follow the pattern of activity on a single account over time.
// Aspect 18
Not tracked. Loyalty points (airline miles, hotel points, credit card rewards) live outside the app.
Loyalty programs are tracked as first-class assets alongside cash and credit. Points balances appear in the asset list. The Loyalty Points Flow report shows balance changes, earnings, and redemptions over time.
finerd calculates the monetary value of points using CPP (cents per point) for all major programs. The CPP figures come from established third-party sources such as The Points Guy and other major points-valuation publishers, so users see a realistic estimate of what their points are worth in actual money rather than a raw point count.
Users can override the default CPP for any program with their own value if they have a different redemption strategy. Once a CPP is set, finerd converts the points balance to the user's primary currency amount and includes it in net worth alongside cash, investments, and other assets.
// Aspect 19
Not tracked.
The Credit Card Economics report (also called the Loyalty Points Game) compares the real cost of running a credit card and points-redemption strategy against the actual value extracted, so the user can see whether their points game is profitable.
The report is split into inflows (value the user got) and outflows (cost of getting it). The bottom line is the net result.
Inflow:
Outflow:
Bottom line: Points game net result (fallback). Inflow minus outflow. A positive number means the user's points strategy is paying off relative to the alternative of using a flat-rate card and paying cash. A negative number means the strategy is costing more than it returns. The example shows -$2,519 in 2024 and $4,492 in 2025: the user moved from losing money to winning money on the points game year over year.
This is the only personal finance app that reports on credit card economics this way. Spreadsheets and dedicated points-tracking tools (AwardWallet, Frequent Miler) cover parts of it, but none of them sit inside a personal finance app where the underlying transactions, fees, and credits are already being categorized.
// Aspect 20
Not tracked as a first-class concept. The closest workaround is to assign expense categories to incoming repayments, so that an income transaction reduces a previous expense category and nets to zero in reports. This works for one-off cases but breaks down when debts are ongoing.
For example, if a user lends $200 to a friend and gets $200 back two weeks later, both transactions can be categorized so the original expense and the repayment net out. But Monarch has no per-friend running balance, no view of "how much does this friend owe me right now," and no shared ledger that the friend can also see. The model also assumes the user knows in advance whether something will be repaid; for ongoing arrangements (a roommate, a recurring travel partner, a parent helping with bills), the workaround becomes unreliable.
First-class shared debts between people, similar to Splitwise but built directly into a personal finance app. Money lent or borrowed is recorded as a debt rather than expense or income, with a running balance per person and settle-up tracking.
Each friend, family member, or partner gets their own debt account inside the user's space. Related transactions accumulate against that account, so the user can see at any time exactly how much each person owes them or how much they owe each person. The debt balance updates with every shared expense and every settlement.
Friends and partners can be invited into a shared settle-up sheet that they can also see. They can use it to check their balance and pay back without back-and-forth messages or screenshots. When the debt is settled, the settlement transaction nets out the running balance and reports stay clean because the settlement is not income or expense.
// Aspect 21
Monarch has receipt scanning in its mobile app. Users upload a photo of a receipt three ways: from the sidebar menu, from the transactions page via the + icon, or by sharing directly from the phone's photo library. Monarch automatically matches the receipt to the right transaction, attaches it, and adds detailed notes about what was purchased.
Receipt scanning can also split a generic transaction into multiple properly categorized line items. For example, a single $147.83 Costco charge can be broken down into groceries, household supplies, and electronics, each categorized separately, based on what was actually on the receipt.
If a match is not found immediately, Monarch keeps searching as new transactions sync. Receipt scanning can also create new transactions from a receipt when no transaction exists yet. All scanned receipts are tagged "Receipt Import" so users can filter for them.
finerd's bill handling covers receipts, paper bills, and digital bills through three input paths.
Receipt and paper-bill scanning: users take a photo of any receipt or bill from the mobile app. The image is processed automatically. finerd extracts the merchant, the date, the total, and every line item, then matches the receipt to the corresponding transaction in the user's account. If no transaction has arrived yet, finerd holds the receipt and matches it once the transaction syncs from the bank. If a transaction is generic (for example, a single Costco charge for $147.83), the receipt scanner can break it down into properly categorized line items: groceries, household supplies, electronics, and so on, each with its own category and amount.
Email-synced bills: finerd connects to the user's email and parses bills automatically as they arrive. Subscription receipts, utility bills, online purchases, and any other digital bill that comes in by email is processed without the user uploading anything. The parsed bill is matched to its transaction the same way as a scanned receipt.
Item-level categorization and transaction linking work the same way across all three input paths. Bills are linked to their transactions, line items inherit categories, and the receipt or bill image is stored alongside the transaction for reference.
// Aspect 22
A Chrome plugin parses orders from Amazon and Target, capturing item-level details and linking them to transactions. Other marketplaces are not supported.
Connected email parses receipts and orders from any marketplace that sends email confirmations. There is no per-marketplace integration to install; if the receipt arrives by email, it can be parsed.
Users who do not want to connect their primary email can instead forward individual receipts to a private finerd email address and finerd processes them automatically. They can also set up automatic forwarding rules in their email client so that purchase confirmations are forwarded to finerd as they arrive, without granting full inbox access.
// Aspect 23
Users can import historical transactions from a CSV file. The CSV must follow Monarch's required format: specific column headers, specific date format, debits as negative numbers (with a "-" prefix or in parentheses), credits as plain positive numbers, and three required columns at minimum (date, amount, merchant or description) with the option to include category, tags, and notes.
The format requirement means that exporting transactions from a bank or another finance app rarely produces a Monarch-ready file. Users typically have to reformat their CSVs (rename columns, change date formats, convert sign conventions) before importing. For users with years of transactions across multiple banks, each export needs to be reshaped to match Monarch's expectations, which is significant manual work.
Imports cannot be undone. To remove imported transactions, users have to bulk-delete them or delete the account and start over.
Users can import historical transactions from any CSV file without reformatting. finerd's AI reads the file, recognizes which columns are dates, amounts, merchants, descriptions, categories, and so on, and maps them automatically. Different sign conventions, date formats, and column orders are handled by the AI, not by the user.
This means a user with years of transactions across multiple banks can drop each bank's exported CSV directly into finerd, with no reshaping. The same applies to spreadsheets the user has been maintaining manually: whatever format the user invented, the AI parses it.
// Aspect 24
Monarch automatically detects recurring transactions when new transactions sync from connected accounts and surfaces them on a dedicated Recurring page. Detection works at the merchant level: a recurring merchant covers all charges from that merchant.
The Recurring page offers a calendar view and a list view, both available on web and mobile. In the calendar, items are color-coded: green with a checkmark for a recurring transaction paid as expected, yellow for one paid at a different amount than expected. The list groups items into "Upcoming" and "Complete" sections. Past-due recurring merchants that were not paid are hidden from the calendar view and appear only in the merchants list.
Bill Sync (a separate feature for credit cards and loans) can pull statement balances and minimum payments due via US credit bureau data. Bill Sync is not available for Canadian customers.
finerd offers a recurring calendar on both web and mobile. The calendar shows every recurring transaction the user has, including subscriptions, bills, paychecks, transfers, and any other transaction that repeats on a regular schedule. Users can view the calendar by month and navigate forward or backward in time.
Detection is AI-driven and operates at the transaction level rather than the merchant level. A user can mark a specific transaction as recurring without affecting other transactions from the same merchant. For example, an Uber One subscription is recognized as recurring without flagging individual Uber rides as part of it. The system distinguishes between "the same merchant" and "the same recurring charge."
finerd parses Apple and Google subscription receipt emails, so subscriptions billed through the App Store or Google Play are identified by the actual underlying service (Spotify, Netflix, ChatGPT, etc.) rather than appearing as a generic "Apple" or "Google" charge on the user's card. Users see what they are actually subscribed to, not just who processed the payment.
For each recurring item, finerd surfaces three values:
Users can manually add a recurring item from scratch (for example, a paper bill or a payment that does not auto-detect), edit the planned amount on any item, change the frequency, or cancel a recurring item when the user no longer expects it.
// Aspect 25
Available in Monarch's Premium tier. The forecasting setup uses existing Monarch data: household members, income, expenses, and account balances are confirmed at the start, and the user picks which household members are part of the plan. The flow is positioned as fast and easy to set up, intended for experimenting with numbers and building intuition rather than for deep multi-scenario planning.
The forecast helps users plan toward major milestones (retirement, a first home, early retirement) using their existing connected accounts. Because it is built on the same data that powers the rest of Monarch, the forecast stays in sync with current account balances and recent transactions.
Included in the standard $15/mo plan. By default, finerd produces a single linear forecast based on the user's actual income and expense history, projected forward across the chosen horizon. The user starts with one projection that reflects their current trajectory, with no scenario setup required.
Within this default projection, the user can explore the forecast at month, quarter, or year granularity. Horizon options include the next 4, next 12, or full timeline (in months, quarters, or years).
Scenarios (optional). Users who want to compare alternative paths can create additional scenarios alongside the default projection. Examples: "what if I move to Spain," "what if I earn 30% more starting next year," "what if I retire at 50 versus 60." Each scenario is independent and can be edited, duplicated, or deleted. Scenarios are an option for users who want to model decisions, not a required setup step.
Inputs and controls available in the default projection and in scenarios:
// Aspect 26
Monarch offers two budgeting modes: Category and Flex. Flex is the default.
In Category budgeting, every expense category gets a planned amount and the user tracks spending at the category level. Monarch suggests starting amounts based on the past 6-month average and the user can override each one.
In Flex budgeting, categories are organized into three buckets: Fixed (predictable monthly costs that don't change much, like rent or utilities), Non-monthly (predictable but infrequent costs like annual insurance or quarterly utility bills), and Flex (variable spending where individual category budgets are replaced by one combined number). The user budgets Fixed and Non-monthly categories specifically, then everything else flows through the Flex bucket as a single tracking number.
Rollovers can be enabled per category, carrying any remaining amount into the next month's budget. Rollovers are essential for Non-monthly categories (for example, saving $50 each month toward a quarterly $200 utility bill) and optional for others. Categories can also have a starting balance to seed the rollover with money already saved.
Cash-flow based: the budget is set as income = expenses + savings each month, rather than tracking money against current account balances.
finerd does not offer category-based budgeting with planned amounts and spending caps. The product takes a different position on what budgeting should do.
finerd's stated approach: financial success is about growing wealth and living with intention, not stressing over rigid budgets. Traditional budgeting turns money management into a chore, creating guilt with arbitrary spending limits. Real life is unpredictable; some months are packed with celebrations, spontaneous plans, or new subscriptions that add real value. Budgets demand constant manual updates to fit reality, which makes money feel like a burden.
Instead, finerd centers spending analysis: understanding where money goes, identifying waste like forgotten subscriptions, and aligning spending with priorities. This is the role normally played by budgeting in other apps. Decisions about whether to spend more or less in a category come from looking at history and short-term forecasts, not from a category cap that triggers guilt or alerts.
// Aspect 27
Monarch has a dedicated Goals feature for setting savings targets and tracking progress against them. Users create goals from the Goals page (Save Up Goals for accumulating money toward something like a vacation, down payment, emergency fund, or retirement; Pay Down Goals for tracking debt payoff).
Each Save Up goal has a target amount, a target date, and a planned monthly contribution. Goals show statuses (on track, ahead, at risk) based on progress against the target date. Users can set whether spending reduces goal progress (on for goals to refill like an emergency fund, off for one-time spending goals like a vacation).
Funding goals. Users can move money in and out of goals through fund allocations (a direct contribution or withdrawal) or by linking specific income and transfer transactions to a goal. Spending from a goal is supported by linking expense transactions, even when the purchase is on a credit card and the saved money lives in a different account; reconciliation moves the money correctly between accounts.
Account assignment. Goals draw from connected and manual accounts. An account can be fully allocated to a single goal (the entire balance counts toward that goal, useful for investment or asset accounts where balances change due to market activity), or partially allocated and shared across multiple goals.
Retirement and education goals support target dates, projected timelines, and recommended monthly contributions. Monarch factors in expected growth rates per account, using compound interest to project whether the user is on track. One Retirement goal per household.
Pay Down Goals. Liability accounts are recognized automatically. Users add the APR and minimum or planned monthly payment to see a debt payoff projection per account, including principal and interest over time, and an estimated debt-free date.
Goals 3.0 (in beta) reorganizes goal mechanics around fund allocations and adds an "Available for goals" view showing how much of each account is allocated versus available.
finerd does not currently offer a Goals feature. Users who want to plan toward a target use the Forecasting tool to model the trajectory (see Forecasting above) rather than tracking a goal-specific savings progress bar.
// Aspect 28
Monarch tracks investments alongside the rest of the user's finances. Investment accounts can be connected automatically through the data providers, or set up manually. The Investments page has two main sections: Holdings and Allocation.
Holdings. Lists every security the user owns, grouped by type, institution, or account. Each holding shows its price, quantity, and total value. The user can drill into any holding for charts and account-level breakdowns. A performance graph compares the portfolio's return against benchmarks such as the S&P 500. Performance is calculated using a time-weighted return method, where the weighting reflects the size of each position (larger holdings move the total return more).
Allocation. Breaks the portfolio down by asset class (mutual funds, ETFs, individual stocks, fixed income, cryptocurrency, and so on).
Manual holdings. Users can add individual securities and quantities to a manual investment account, or to an investment account that's already connected if some holdings are missing. Manual holdings are matched against Monarch's securities database (powered by FMP). When the security is supported, the price updates daily and the account balance reflects current market value automatically. When FMP does not cover a ticker, pricing and performance may be inaccurate. A manual holding's underlying security cannot be changed once created; to fix an error, the user adds the correct holding and deletes the wrong one.
Supported security types include publicly-traded US stocks, ETFs, mutual funds, fixed income (treasuries, CDs, bonds), forex, derivatives (options), and cryptocurrencies.
Investment Transactions (currently a Monarch Labs feature, opt-in via Settings → Preferences → Monarch Labs) show buy/sell transaction details inside supported accounts. Manual entry of dividends or transaction history is not currently supported on manual holdings.
Monarch separates the Investments page summary (calculated as quantity × closing price) from the Accounts page balance (received directly from the data provider). These can differ when some holdings are not public, when holdings sync incomplete or with the wrong quantity, or when part of the account balance comes from cash holdings the institution does not always report.
finerd tracks investments either as connected investment accounts (through Plaid, the same way bank accounts are connected) or as manual holdings (individual stocks, ETFs, or crypto coins added by the user as separate assets). The two approaches behave the same way once set up: which one a user picks is a matter of preference. If the user prefers to enter holdings by hand, the experience is essentially the same as a synced account; if they prefer to connect their brokerage, finerd handles the data automatically.
Holding prices update daily, the same as in Monarch, so net worth always reflects current market value. Multi-currency conversion applies on top of pricing: a Canadian-listed stock priced in CAD is converted to the user's primary currency for the net worth view, with current exchange rates for current values and historical rates for historical snapshots.
Performance and portfolio analysis covered:
finerd does not include benchmark comparisons against indices like the S&P 500. The product handles individual portfolio performance and integration into the broader financial picture, not benchmark-relative analysis.
Supported assets include publicly-traded stocks and ETFs, crypto coins, and any asset the user manually defines (for private investments, equity grants without public tickers, or assets not covered by automated pricing).
// Aspect 29
Monarch has a dedicated Equity Tracking feature for company equity compensation. Supported grant types include ISOs (Incentive Stock Options), NSOs (Non-qualified Stock Options), RSUs (Restricted Stock Units), and RSAs (Restricted Stock Awards). The feature is designed primarily for private-company equity or grants that cannot be synced through a brokerage; for public-company equity already in a connected brokerage, users associate the equity account with the brokerage to avoid double-counting.
Adding a grant. Users can upload grant documents (PDF, PNG, JPG) for automatic analysis, or enter grant details manually. Grants appear in a dedicated Equity section on the Accounts page.
Vesting visualization. Each equity account shows a bar chart breaking holdings into Vested, Exercised, Early Exercised, and Unvested categories over time, so users can see when future shares become available.
Net worth calculation. The value shown in net worth is vested shares × current share price for RSUs and RSAs. For options (ISO/NSO), the value is the spread: (current price − strike price) × vested shares. As the company raises new funding or updates its valuation, the user updates the share price manually and the equity account reflects the new value.
Users can exclude an equity account balance from net worth if they want to track vesting visualization without affecting their current financial picture.
finerd does not have a dedicated equity tracking feature for ISOs, NSOs, RSUs, or RSAs with vesting schedules. Users who want to include vested equity in their net worth can add it as a manual asset under Stock & Crypto (entering the share count and current price), but vesting schedules, automatic spread calculation for options, and vested-vs-unvested breakdowns are not modeled. For users with significant equity compensation that needs proper vesting tracking, Monarch's Equity Tracking is more capable.
// Aspect 30
Available as a $200/year add-on. The user can mark accounts and transactions as belonging to a business, then filter the existing personal-finance reports by business or household. Schedule C output is available for US tax filing. Personal and business categories share a single category list.
Available as a separate business space at $50/mo. The business space has its own categories, its own reports, and is treated by the AI as a separate context from personal finance.
Reports include real business statements: Profit & Loss, Balance Sheet (which now includes tracking of unrealized gains on holdings), and Cash Flow. FX rates are tracked when the business operates in multiple currencies. Other people (a bookkeeper, an accountant, a co-founder) can be invited into the business space.
Cross-allocation: when a personal expense is paid from a business account, or a business expense is paid from a personal card, the transaction can be split and re-categorized so that it lands correctly in both spaces simultaneously.
// Aspect 31
Monarch has a built-in AI Assistant available throughout the app via an orange sparkle icon in the left sidebar. The Assistant runs on a single AI model chosen by Monarch and operates only inside Monarch's interface.
What it can do: answer natural-language questions about the user's finances based on data already in Monarch (spending patterns, cash flow, changes in net worth), and explain how to use Monarch's own features (create a report, adjust a budget). The user can optionally provide household context in Member settings (household size, dependents, income) to make the Assistant's responses more personalized.
Practical limitations users have noted: the Assistant tends to produce generic and obvious advice ("you spent more on dining this month, consider eating out less"), which limits its usefulness for users with sophisticated financial questions. It is positioned as a guide to the data and the product, not as a substantive financial advisor.
finerd does not have a built-in AI chat. Instead, finerd connects to external AI clients through an MCP (Model Context Protocol) connector. As of now, the connector works with Claude. Users open Claude (the desktop app, the web client, or Claude Code), enable the finerd connector, and then ask Claude any question about their finances. Claude reads the user's accounts, transactions, balances, and reports as live context and answers using the same reasoning capabilities Claude has for any other task.
Why this approach: a built-in chat is bound to whatever model the company integrated and to whatever prompt scaffolding the team wrote. As frontier AI models improve (Claude, GPT, Gemini, others), users of built-in chat features wait for the company to upgrade. Users of an MCP connector get the upgrade automatically as soon as their AI client adopts the new model. The connector also lets the user use whatever client they already pay for, rather than another in-app chat to manage.
Because Claude can render interactive components, finerd's connector returns more than text answers. Real interactive outputs the connector produces:
The pattern: the user asks any question in plain language, Claude pulls the relevant data from finerd, reasons over it with general AI capabilities (web search, math, code), and returns a structured answer with charts, tables, sliders, or actions taken on the user's account. The substance of the answer comes from Claude's reasoning, not from a constrained set of pre-built finerd reports. This is why the answers don't feel like the generic advice users complain about with built-in finance chats.
// Aspect 32
Monarch has a Bill Split feature for splitting group bills, available in the mobile app on iOS and Android. The feature is accessed from the left navigation in the mobile app and is not available on web.
Flow: the user snaps a photo of the bill and Monarch itemizes it, including tax and tip. The user shares a link or QR code with the rest of the table. Each person claims their items, sees what they owe, and settles up.
finerd's bill split is built directly into the receipt scanning flow. When the user snaps a bill, finerd asks whether to record a regular transaction or split the bill. If the user picks split, finerd parses the receipt into individual line items, taxes, and other charges. The user can edit anything before sharing: change quantity, amount, item names, or add charges that aren't on the receipt (a friend left cash, someone paid for part of the table separately).
The user shares a link or QR code with the table. Each person opens the link, taps the items they had, and adds themselves to the bill without needing to download the app or sign up. Items shared by the table (a pizza, a bottle of wine) can be split across multiple people: any participant can mark an item as shared and assign it to N people, which converts it internally into N portions that each person claims one of.
After claiming items, each guest reaches a payment screen showing how to pay the user. The user defines their own payment options ahead of time and can list as many as they want: Venmo, PayPal, Cash App, Zelle, Revolut, e-transfer email, or any other method. Each option can be tagged with a username/handle and a currency, so a guest with multiple payment apps can pick the option that matches the currency they're paying in. The intent is zero back-and-forth communication: the guest sees what they owe, picks how to pay, and pays.
If a guest cannot or does not claim their items, the user (or any other participant) can claim items on their behalf, so the bill always closes out fully.
On the user's side, finerd automatically creates a single split transaction reflecting the actual split. For example, dinner with two friends where the user paid $120 total, the user's share is $35, friend A's is $40, friend B's is $45. finerd records: $35 from the user's bank account to Eating Out, $40 to friend A's debt account, $45 to friend B's debt account. The debts feed into the dedicated debts-between-people view (see Debts between people above), so each friend's running balance updates without the user manually creating debt transactions.
// Aspect 33
$14.99/month or $99.99/year for the standard plan. The Premium tier with forecasting and advanced investment analysis is $200/year. The business add-on is also $200/year.
$14.99/month for the personal plan, which includes forecasting and all personal-finance features. The business space is a separate $29.99/month subscription for users who need real business accounting on top of personal finance.
Comparison reflects publicly available information about Monarch and current capabilities of finerd as of 2026. Pricing and features change. Verify current pricing on each product's site before deciding.
