What lives inside Monee, and how to move it into your own systems

Where Monee actually keeps the numbers

Monee does one thing on purpose: you type an amount, pick a self-made category, optionally add a note. No sign-up, no bank connection, no scraping of statements. That austerity is the point of the app and it shapes how its data is reached. There is no statement feed to consent to, because the app never touches a bank. What it does have is a clean, well-structured ledger that the owner can take with them.

Two routes carry that ledger out, and for an ingestion job we usually lead on the first.

Route A — ship a client around the native export

Monee exports to CSV and Excel from inside the app; one published walkthrough describes the export covering recent transactions. A small language client watches a drop folder or an inbox, parses each file, and writes normalized records into your store. This route is durable: it rides a user-facing feature the developer maintains, so it does not break when the app updates its internals. It is the spine of most Monee jobs and the one we would recommend first.

Route B — consented read of the Firebase sync

The interesting part is the shared household. An iPhone user invites an Android partner into one account, and both phones stay aligned. Apple's own CloudKit cannot do that across platforms, and the developer has said the stack runs on Firebase. So the shared ledger lives in a cloud document store. With the account holder's authorization, we read that collection directly through the Firebase client libraries — fresher than waiting on a manual export, and the right choice when you need near-live sync rather than a daily file. Access is arranged with you during onboarding, against a consenting account; we set it up, you authorize it.

Route C — protocol mapping as a fallback

If neither file export nor a direct Firebase grant fits the situation, we map the app's own traffic to its backend under your authorization and rebuild the read path from there. Slower to stand up, more sensitive to app changes, used only when the cleaner routes are closed.

What you can actually pull

Every row below comes from a feature the app describes for itself. Nothing here assumes a bank link the app does not have.

What lands in your repo

The deliverable is code that runs against Monee data on day one, not a slide deck about it.

• Runnable ingestion client in Python or Node.js: parses the CSV/Excel export, and — where authorized — reads the Firestore transaction collection, emitting normalized records.
• Normalized transaction schema plus the mapping layer from Monee's columns and category names onto it, currency-aware.
• A test harness with fixture exports, so a malformed or renamed column shows up as a failing assertion before it reaches your data store.
• Sync design — batch backfill versus a polling read of the shared-account collection — written for your freshness needs, idempotent on the transaction id.
• Webhook/handler stubs for downstream fan-out once a batch is ingested, if your pipeline needs them.
• Secondary: an OpenAPI description of the read surface we expose, a short auth-flow note covering the Firebase token chain, and data-retention guidance for holding personal finance records under GDPR.

A worked example against the export

Illustrative — field names are firmed up against a real export during the build. The shape below is what the ingestion client emits per Monee row, with the Firestore read shown as the live alternative to the file parse.

# Monee ingest — CSV export path, normalized + idempotent
from monee_ingest import parse_export, normalize, upsert

rows = parse_export("monee-export-2026-06.csv")   # amount, type, category, note, account, person, currency, date

for r in rows:
    txn = normalize(r, base_currency="EUR")
    # stable key: account + source row id, so a re-import updates in place
    upsert(key=f"{txn.account_id}:{txn.source_id}", record=txn)

# Live alternative (consented): read the shared-account collection directly
#   from firebase_admin import firestore
#   db = firestore.client()
#   q = db.collection("transactions").where("accountId","==",acct).order_by("updatedAt")
#   for doc in q.stream(): upsert(key=doc.id, record=normalize(doc.to_dict()))

# normalized record (illustrative)
# {
#   "source_id": "a91f...", "account_id": "home",
#   "type": "expense", "amount": "12.40", "currency": "EUR",
#   "category": "Groceries", "note": "market",
#   "person": "partner", "recurring": false,
#   "occurred_at": "2026-06-03T00:00:00Z"
# }
      

The record everything collapses to

Monee lets each entry use its own currency and ties entries to accounts and people. The target schema keeps all three as first-class fields rather than flattening them away, so the filters the app offers survive the move.

type MoneeTxn = {
  source_id: string        // document id or export row id — the idempotency key
  account_id: string       // which (possibly shared) account
  type: "income" | "expense"
  amount: string           // decimal as string; never a float
  currency: string         // per-entry, ISO 4217
  category: string         // user-defined label, mapped at ingest
  note?: string
  person?: string          // participant on a shared account
  recurring: boolean
  occurred_at: string      // ISO 8601
}
      

Consent and the GDPR footing

Monee never links a bank, so there is no AIS, open-banking, or account-aggregation scheme in play — those regimes govern bank-held data, which this app does not touch. The relevant regime is GDPR: the developer is based in Germany, and the app's privacy notice cites Art. 13 and names Firebase (a Google service) as a processor under a legitimate-interest basis. For any extraction, the footing we rely on is simpler and firmer than a statute — the account holder authorizing access to their own records.

We operate authorized and logged: access is granted by the user or the customer with rights to the data, consent and revocation are recorded, the pull is data-minimized to the fields you actually need, and an NDA is in place where the engagement calls for one. Because these are personal finance records, retention windows and deletion handling are part of the handover, not an afterthought.

Two things we handle that are specific to Monee

Shared accounts are the first. A single account can hold entries from several invited people across iOS and Android, so the same logical ledger arrives from more than one device. We treat the account as the unit of truth and carry the participant reference per transaction, which keeps the app's "filter by person" view intact downstream and avoids double-counting when two members both have the account open.

Per-entry currency is the second. The app lets any single transaction use any currency worldwide, so a household ledger can be genuinely mixed. We hold the original currency on the record and convert to your base only as a derived field, with the rate source pinned, rather than overwriting what the user entered. We also map Monee's custom month-start day onto your reporting period so totals line up with what the user sees in the app, not with a default calendar month.

Interface evidence

Screens from the store listing, used to confirm the surfaces named above. Tap to enlarge.

How this was checked

Checked on 7 June 2026 against the Play Store and App Store listings for the feature set and identifiers, the developer's own privacy notice for the GDPR and Firebase-processor details, and a published founder interview for the backend stack and audience figures. Where a number could not be independently confirmed — daily-active-user counts, the exact export window — it is attributed to its source and not asserted as flat fact.

Sources opened: Google Play listing, Apple App Store listing, Monee privacy notice (Art. 13 GDPR), founder interview on the stack.

OpenFinance Lab · integration engineering notes, 7 June 2026.

Apps in the same neighbourhood

If you are unifying several trackers behind one schema, these come up alongside Monee. Each holds a comparable personal-finance ledger, reached its own way.

• YNAB — zero-based budgeting with bank linking in supported markets; richer rule data, heavier auth.
• Monarch — aggregation-driven budgeting that pulls connected accounts; data arrives pre-categorized.
• Expensify — receipt-scanning and reimbursement flows; strong on per-expense detail and approvals.
• PocketGuard — links accounts and surfaces disposable income; recurring-bill detection is its signature.
• Spendee — multi-wallet budgeting with shared wallets, conceptually close to Monee's shared accounts.
• Cashew — privacy-leaning, customizable expense tracker; manual entry like Monee.
• Dime: Budget & Expense Tracker — on-device-first manual tracker with a similar no-friction entry model.
• Actual Budget — open-source, local-first envelope budgeting; export and sync are first-class.
• Money Manager — long-standing manual ledger with category analytics and CSV/Excel export.

Questions integrators ask

Does Monee keep data on a server we can reach, or is it all on the phone?

Cross-platform household sync — an iPhone user and an Android partner sharing one account — runs through a Firebase backend, by the developer's own account of the stack. So shared-account records exist server-side, not only on the handset. We ingest from the user's consented Firebase project or from the CSV/Excel the app exports, never by working around the sign-in.

How would a Python or Node service pull Monee transactions on a schedule?

We ship a small language client that watches for new CSV/Excel exports and, where the user authorizes it, reads the Firestore transaction collection directly. Each row is normalized to a flat transaction record keyed on its document id, so a re-read updates in place instead of duplicating. Cadence is yours: a nightly batch backfill or a tighter poll on the sync collection.

Monee has no bank link, so which rules cover pulling its data?

Because it never connects to a bank, no AIS or open-banking scheme applies. The developer is based in Germany and the app runs under GDPR, with Firebase named as a processor under a legitimate-interest basis in the privacy notice. The dependable basis for any extraction is the account holder's own authorization to their own records.

How do you handle Monee's unlimited accounts and the people-involved field?

We model the account as a first-class dimension, since a user can create unlimited accounts and invite others into them, and we carry the participant reference on each transaction so the filters Monee exposes — by type, by frequency, by person — survive the export. Currency is preserved per record because the app lets each entry use any currency.

Working with us

A first working ingest — runnable client, normalized schema, a test harness over real export fixtures — lands inside one to two weeks of a clear brief. You hand us the app name and what you want out of Monee; access and any consent or NDA paperwork are arranged with you as part of the job, not asked of you upfront. From there, source code is delivered from $300, billed only after you have it and it does what the brief said; or the same read surface runs as a hosted API where you pay per call with nothing upfront. Tell us which shape fits and what the data feeds — start a conversation here.