Reaching the ledger inside Budget & Expense Tracker Monee

Monee keeps every transaction on the device itself, then syncs copies through the user's own cloud account. There is no central Monee server holding the ledger and no email sign-up to gate it — the developer, Stephan, states plainly on the product site that the data belongs to the user (per monee-app.com). For an integrator that single architectural fact decides almost everything: the data is right there with the consenting owner, and the work is about reading their copy cleanly rather than negotiating with a backend.

So the lead path here is the app's own data export, with on-device extraction filling the gaps the flat export leaves behind. Below is what the app holds, the authorized ways to reach it, the code shape we hand over, and how the engagement runs.

Reaching the data without a backend to call

Three authorized paths apply to an app whose data sits with the user. They are not mutually exclusive; we usually combine the first two.

1. The built-in export

Monee ships an export feature — the listing says you can export your financial data whenever you need it. That file is the cleanest consented surface: the user runs the export, hands us the output, and we parse it. It is transaction-level and stable across app updates because it is a deliberate output format. The trade-off is breadth — flat exports tend to flatten relationships like which person a shared entry belongs to.

2. On-device store extraction

To recover what the export flattens — account membership, recurring-rule definitions, per-person splits — we read the local store directly under the owner's authorization. This is documented format analysis of the app's own on-disk representation, done on a device the user controls. It is richer than the export and needs a re-check when the app ships a storage change, which we plan for in maintenance.

3. The synced copy in the user's cloud

Because Monee syncs through the user's own cloud account rather than a vendor database, a consenting user can authorize access to that synced representation across their devices. This route suits a multi-device household where the freshest ledger is whichever device last wrote. It carries the same shape as the on-device store, so the parser is shared.

For most buyers the working answer is the export for its stability, with on-device extraction layered on to capture the group and recurring fields the export drops. We would only reach for the cloud-sync copy when no single device holds the complete picture. Which combination fits gets settled against your actual data during onboarding.

What Monee actually stores

Every row below comes from a feature named in the app's own listing. None of it is account-aggregation from a bank — it is what the user entered, organized.

Reading an exported Monee ledger

A short, illustrative pass over an export — field names here are confirmed against the app's on-screen records during the build, not lifted from any published spec. The point is the normalization, not the exact column headers, which we verify against your file.

# Illustrative: turn a Monee export into normalized ledger rows.
from decimal import Decimal
import csv

def load_monee_export(path):
    out = []
    with open(path, newline="", encoding="utf-8") as fh:
        for r in csv.DictReader(fh):
            amt = Decimal(r["amount"])
            out.append({
                "posted_on": r["date"],                       # transaction date
                "direction": "income" if amt > 0 else "expense",
                "amount":   str(abs(amt)),
                "currency": r.get("currency", "EUR"),         # any currency worldwide
                "category": r["category"],                    # user's own category
                "account":  r.get("account"),                 # one of the user's accounts
                "person":   r.get("person") or None,          # who the entry involves
                "note":     r.get("note", ""),                # optional short note
            })
    return out

# Records the flat export omits (shared-account membership, recurring
# rule definitions) are merged in from the on-device store, keyed by
# account id, before the rows above are emitted.
      

A normalized shape for the records

Whatever route we use, the output is the same documented schema, so downstream code never depends on which surface a field came from.

{
  "transaction": {
    "id": "string",
    "posted_on": "2026-05-31",
    "direction": "expense | income",
    "amount": "12.40",
    "currency": "EUR",
    "category": { "name": "Groceries", "user_defined": true },
    "account":  { "id": "string", "shared": true },
    "person":   "string | null",
    "recurring_rule_id": "string | null"
  },
  "recurring_rule": {
    "id": "string",
    "amount": "9.99",
    "cadence": "monthly",
    "next_run": "2026-07-01"
  }
}
      

The package you receive

Everything is scoped to Monee's real surfaces, not a generic finance template:

• An OpenAPI/Swagger specification describing the normalized transaction, category, account and recurring-rule resources above.
• A protocol and format report covering the export columns and the on-device store layout, including how shared-account membership is recovered.
• Runnable source for the parser and the extraction step, in Python or Node.js, with a sample dataset.
• Automated tests over multi-currency rows, income-versus-expense sign handling, and recurring-rule linkage.
• Interface documentation a non-author can follow, plus a short data-retention and consent note matched to GDPR.

If you take the hosted option instead of source, the same normalization runs behind an endpoint you call.

Consent and GDPR for a no-account app

Monee publishes a privacy notice under GDPR Article 13 (per monee-app.com/privacy) and runs with no registration, no ads and no tracking. Because there is no central account, the lawful basis for our work is the data subject's own authorization over their own records — the user is the controller of their ledger and consents to having it read and converted. We keep that consent on record, log what was accessed, minimize to the fields the project needs, and work under an NDA where you ask for one. Personal categories and free-text notes can carry sensitive detail, so we treat the note field as optional and redactable in any shared sample. This is how the studio operates rather than a checklist you clear first; access to a consenting account or its export is arranged with you as part of the build.

Engineering details we plan around

Two specifics on this app shape the build, and we handle both:

• Shared accounts span people. Monee lets a user create unlimited accounts and invite others, then filter transactions by the people involved. We model accounts as multi-member and attribute each entry to a person, so a household ledger reconciles correctly instead of collapsing two members into one column.
• Recurring rules are not the same as posted entries. A recurring expense is a rule that spawns entries on a cadence. We extract the rule and the entries separately and link them, so forecasting reads the rule while history reads the actual posts — and a user editing one occurrence does not corrupt the series.
• Period and currency are configurable. The month start is user-set and a previous balance can be carried into the current period, while any currency is allowed per entry. We read the period setting and keep each amount in its source currency, applying reporting-currency conversion as a separate, optional layer.

When the app ships a storage or export change, we re-run the format checks as part of maintenance rather than letting a quiet schema drift break the sync.

Screens we mapped against

The extraction was checked against the app's published screenshots — the entry flow, category breakdowns and analysis views that name the fields we normalize. Open any to enlarge.

Where Monee sits among trackers

These are real same-category apps; an integrator weighing a unified personal-finance pipeline usually meets several of them. Named for context, not ranked.

• Monefy — manual-entry expense tracker with instant charts; CSV-style export that third-party tools already import.
• Monekin — open budget manager holding accounts, categories and transfers in a local store.
• Cashew — free, open-source budget app with categorized transactions and goals.
• Actual Budget — open-source, local-first envelope budgeting with a syncable data file.
• MoneyWallet — open-source expense manager with multi-wallet and export support.
• My Expenses — long-running Android tracker with strong CSV/QIF export.
• Ivy Wallet — open-source money manager that imports Monefy-format data.
• Money Lover — spending manager offering CSV and Excel export of transactions.
• Dime: Budget & Expense Tracker — privacy-leaning tracker with categories and recurring entries.
• Monarch Money — aggregation-based budgeting with manual-import support for transaction history.

Integrator questions about Monee

Monee has no login or central account — what are we actually connecting to?

The device-local store and the file Monee produces from its built-in export, plus the copy that syncs through the user's own cloud account. Because the ledger belongs to the user, their authorization is the basis for reading it; there is no third-party servicer in the loop.

Does Monee's export carry the people and shared-account fields, or only the amounts?

The export is transaction-level: date, amount, currency, category and note. Group membership and per-person attribution from shared accounts often live in the on-device store rather than the flat export, so we map both surfaces and reconcile them.

Can self-created categories and any-currency amounts survive normalization?

Yes. Categories are kept verbatim with a mapping table so the user's own labels are preserved, and each amount keeps its original currency code; FX normalization to a single reporting currency is optional and applied on top, not in place of, the source value.

How do recurring expenses and income come through?

Monee stores a recurring rule (amount, cadence, start) separately from the individual entries it generates. We extract the rule and the posted entries, and link each entry back to its rule so forecasts and one-off edits stay distinguishable.

What we checked, and when

This mapping was built in June 2026 from the app's own listings and product site: the Google Play listing and App Store listing for the feature and field set, the Monee product site for the local-first sync model, and the GDPR Article 13 privacy notice for the data-protection posture. Compiled by the OpenBanking Studio integration desk · June 2026.

Delivery runs one to two weeks against a consenting account's export. You can take the work as runnable source code from $300, paid only after delivery once it does what you need — or call our hosted endpoints and pay per call with nothing upfront. Either way, tell us the app and what you want from its data and we handle the access and compliance with you: start a Monee integration.